重複の可能性:
SSL が課すオーバーヘッドはどれくらいですか?
最近、SSL をサイト全体に実装すると、サーバーに 300 倍の負荷がかかるという開発者との会話がありました。これは本当に信用できるものですか？現在、すべてのページで SSL を使用しており、数千人のユーザーが毎日システムにアクセスしており、目立った遅延はありません。IIS 7 サーバーを使用しています。
彼の解決策は、ログイン資格情報の送信を保護するために、ログイン ページでのみ SSL を使用することでした。次に、それらをHTTPにリダイレクトします...これは良い習慣ですか?
HTTPS でコストがかかるのは、CPU (非対称暗号化操作の方がコストがかかる) とネットワーク ラウンド トリップ (ハンドシェイク自体だけでなく、証明書の失効を確認するため) の両方の点でハンドシェイクです。この後、対称暗号化を使用して暗号化が行われますが、これは最新の CPU に大きなオーバーヘッドを課すことはありません。ハンドシェイクによるオーバーヘッドを削減する方法があります (特に、サポートおよび構成されている場合は、セッションの再開を介して)。
多くの場合、静的コンテンツをクライアント側でもキャッシュできるように構成すると便利です (「 」を参照Cache-Control: public)。一部のブラウザは、デフォルトで HTTPS コンテンツをキャッシュしません。
HTTPS を使用しているときにサーバーの CPU 負荷を 300 増やすと、何かが適切に構成されていないように聞こえます。
彼の解決策は、ログイン資格情報の送信を保護するために、ログイン ページでのみ SSL を使用することでした。次に、それらをHTTPにリダイレクトします...これは良い習慣ですか?
多くのサイトがこれを行っています (StackOverflow を含む)。どの程度のセキュリティが必要かによって異なります。これを行うと、資格情報のみが保護されます。攻撃者はプレーンな HTTP で渡された Cookie (または同様の認証トークン) を盗聴し、それを使用して認証されたユーザーになりすますことができます。
HTTP から HTTPS に切り替える場合、またはその逆の場合は、細心の注意を払う必要があります。たとえば、ログイン ページからの認証トークンは、プレーンな HTTP に渡されると「侵害された」と見なされます。特に、その認証トークンを引き続き使用する後続の HTTPS 要求が正当なユーザーからのものであると想定することはできません (たとえば、「マイ アカウント」の詳細の編集などを許可しないでください)。
彼はそれを作り上げています。300 が怪しい丸数字だと思いましたか? 彼にそれを証明するように頼んでください。テストと測定。
確かに、サーバーにより多くの負荷がかかります。実際に問題がある場合は、そのほとんどをハードウェア暗号化アクセラレータまたはフロントエンド ボックスにオフロードできますが、私の経験では無視できます。詳しくはこちらをご覧ください。
ログイン後に HTTP に戻すという彼の提案は、トランスポート セキュリティが必要なサイト内のページがログイン ページだけである場合にのみ意味があります。これはありそうもないことです。
率直に言って、彼はこれについてあまり知らないようです。
私は約 15 年前に大規模な実験を行い、インターネット上で SSL の時間オーバーヘッドが約 30% であることを示しました。