すべてにHTTPSを使用しないのはなぜですか？

サーバーをセットアップしていて、SSL証明書がある場合、購入/ログインだけでなく、サイト全体にHTTPSを使用しないのはなぜですか？サイト全体を暗号化し、ユーザーを完全に保護するほうが理にかなっていると思います。これにより、すべてを保護するために何を保護する必要があるかを決定するなどの問題が回避され、ユーザーにとっては不便ではありません。

サイトの一部ですでにHTTPSを使用している場合、なぜそれをサイト全体で使用したくないのですか？

これは関連する質問です：httpsがログインにのみ使用されるのはなぜですか？、しかし答えは満足のいくものではありません。回答では、サイト全体にhttpsを適用できなかったと想定しています。

いくつかの理由が考えられます。

• 一部のブラウザはSSLをサポートしていない場合があります。
• SSLを使用すると、パフォーマンスが多少低下する場合があります。ユーザーが大きな公開ファイルをダウンロードしている場合、毎回これらを暗号化するシステムの負荷がかかる可能性があります。

HTTPSを使用する場合、他の理由（特にパフォーマンス関連）に加えて、IPアドレス*ごとに1つのドメインのみをホストできます。

サーバー HTTPヘッダーはサーバーに応答するドメインを通知するため、単一のサーバーがHTTPで複数のドメインをサポートできます。

HTTPSを使用する場合、サーバーは最初のTLSハンドシェイク（HTTPが開始する前）中にクライアントに証明書を提供する必要があります。これは、サーバーヘッダーがまだ送信されていないため、サーバーが要求されているドメインと応答する証明書（www.foo.comまたはwww.bar.com）をサーバーが認識する方法がないことを意味します。

*脚注：技術的には、複数のドメインを異なるポートでホストしている場合は、それらをホストできますが、これは通常はオプションではありません。SSL証明書にワイルドカードが含まれている場合は、複数のドメインをホストすることもできます。たとえば、証明書* .example.comでfoo.example.comとbar.example.comの両方をホストできます。

SSL / TLSはほとんど十分に使用されていません。HTTPSはセッション全体で使用する必要があります。いかなる場合も、セッションIDをHTTP経由で送信することはできません。ログインにhttpsのみを使用している場合は、2010年の「A3：壊れた認証とセッション管理」のOWASPトップ10に明らかに違反しています。

カタツムリメールのすべての投稿を改ざん防止の不透明な封筒に登録済みメールで送信してみませんか？郵便局の誰かが常に個人的な監護権を持っているので、誰もあなたのメールを覗き見していないことをかなり確信で​​きます。明らかに、答えは、一部のメールは費用に見合うだけの価値がありますが、ほとんどのメールはそうではないということです。誰かが私の「刑務所から出られてよかった！」と読んでも構わない。アンクルジョーへのポストカード。

暗号化は無料ではありませんし、常に役立つとは限りません。

セッション（ショッピング、バンキングなど）がHTTPSを使用して終了する場合、セッション全体をできるだけ早くHTTPSにしないようにする理由はありません。

私の意見では、要求または応答は中間のスヌーピングから保護する必要があるため、不可避的に必要な場合にのみHTTPSを使用する必要があります。例として、Yahoo！ホームページ。ログインしていても、ほとんどのやり取りはHTTPを介して行われます。HTTPS経由で認証し、自分の身元を証明するCookieを取得するため、ニュース記事を読むためにHTTPSは必要ありません。

システム負荷を超えた最大の理由は、名前ベースの仮想ホスティングが機能しなくなることです。SSLを使用すると、1つのサイト、つまり1つのIPアドレスになります。これはかなり高価で、管理も困難です。

高レイテンシリンクの場合、最初のTLSハンドシェイクでは、証明書チェーンの検証（中間証明書の送信を含む）、暗号スイートの合意、およびセッションの確立のために追加のラウンドトリップが必要です。セッションが確立されると、後続のリクエストはセッションキャッシングを利用してラウンドトリップの数を減らすことができますが、この最良の場合でも、通常のHTTP接続が必要とする以上のラウンドトリップがあります。暗号化操作が無料であったとしても、特にサイトがhttpパイプラインを利用していない場合は、低速のネットワークリンクでは無料で往復することはできません。ネットワークの適切に接続されたセグメント内のブロードバンドユーザーにとって、これは問題ではありません。国際的にビジネスを行っている場合、httpsを要求すると簡単に顕著な遅延が発生する可能性があります。

サーバーがセッション状態を保守するなど、さらに多くのメモリを必要とする可能性や、もちろんデータの暗号化操作など、追加の考慮事項があります。どんな小さなサイトでも、特定のサーバー機能と現在のハードウェアのコストのどちらも実際に心配する必要はありません。大規模なサイトであれば、同様の機能を提供するために、CPU / w AESオフロードまたはアドオンカードを簡単に購入できます。

これらすべての問題は、時間の経過とともにハードウェアとネットワークの機能が向上するにつれて、ますます問題にならないものになっています。ほとんどの場合、今日の具体的な違いはないと思います。

httpsトラフィックの管理上の制限（中間コンテンツフィルターなど）の運用上の考慮事項が存在する可能性があります。一部の企業環境では、情報漏えいを防ぐために境界でのデータ復号化が必要です...ホットスポットへの干渉、およびhttpsトランザクションにメッセージを挿入できないWebベースの類似のアクセスシステム。結局のところ、私の見解では、デフォルトでhttpsを使用しない理由はかなり小さいと思われます。

httpsは、通常のhttpよりもリソースを大量に消費します。

サーバーとクライアントの両方からより多くを要求します。

セッション全体が暗号化されている場合、ISPなどのプロキシレベルで画像やjsなどの静的リソースのキャッシュを使用することはできません。

すべての場所でHTTPSを使用する必要がありますが、次のものは失われます。

1. BREACHおよびCRIME攻撃のため、SSL圧縮またはSSLを介したHTTP圧縮を使用しないでください。したがって、応答にセッションまたはcsrf識別子が含まれている場合は圧縮されません。静的リソース（画像、js、css）をCookieのないドメインに置き、そこで圧縮を使用することで、これを軽減できます。HTMLの縮小も使用できます。

2. 1つのSSL証明書、1つのIPアドレス。ただし、SNIを使用しない限り、すべてのブラウザー（古いAndroid、Blackberry 6など）では機能しません。

3. SSLを経由しない外部コンテンツをページでホストしないでください。

4. ブラウザーがHTTPページにアクセスすると、アウトバウンドHTTPリファラーヘッダーが失われます。これは、問題のある場合とない場合があります。

まあ、明らかな理由はパフォーマンスです。すべてのデータは送信前にサーバーによって暗号化され、受信時にクライアントによって復号化される必要があるため、機密データがない場合は時間の無駄になります。また、サイトのキャッシュ量にも影響する可能性があります。

また、すべてのアドレスhttps://が使い慣れたアドレスではなく使用している場合、エンドユーザーを混乱させる可能性がありますhttp://。また、この回答を参照してください：

jsファイルを含めるときに常にhttpsを使用しないのはなぜですか？

httpsでは、サーバーがクライアントの要求と応答を暗号化および復号化する必要があります。サーバーが多数のクライアントにサービスを提供している場合、パフォーマンスへの影響が増大します。そのため、現在のほとんどのhttpsの実装は、パスワード認証のみに制限されています。しかし、すべてのGmailがサイト全体でSSLを使用しているため、コンピューティング能力が向上すると、これは変わる可能性があります。

WhirlWindの応答に加えて、SSL証明書のコストと適用性、アクセスの問題（クライアントがSSLポートを介して通信できない可能性は低いですが可能性があります）などを考慮する必要があります。

SSLの使用は、保証された包括的なセキュリティではありません。この種の保護は、魔法の弾丸に頼るのではなく、アプリケーションのアーキテクチャに組み込む必要があります。

私たちの会社の1つのプロジェクトで、SSLメッセージが占有する帯域幅がプレーンメッセージよりも大幅に大きいことがわかったと言われました。誰かがそれを12倍もの驚異的な量のデータだと言ったと思います。私はこれを自分で確認していませんが、非常に高そうですが、各ページにヘッダーのようなものが追加されていて、ほとんどのページに少量のコンテンツがある場合、それほど遠くないかもしれません。

そうは言っても、httpとhttpsの間を行き来する手間と、どのページが何であるかを追跡する手間は、私にはあまりにも努力のように思えます。私は一度だけそれらを混合したサイトを構築しようとしましたが、Javascriptによって作成されたポップアップウィンドウのような複雑なものに接続されて、間違ったプロトコルが接続されているなどの複雑なことにつまずくと、計画を放棄してしまいました。最終的には、サイト全体をhttpsにするだけで問題が少なくなります。保護する必要のあるログイン画面と支払い画面があり、それらが単純なページである単純なケースでは、混合して一致させることは大した問題ではないでしょう。

クライアントが復号化する負担についてはあまり気にしません。通常、クライアントは、データを処理するために必要な時間よりも、データがネットワーク経由で送信されるのを待つために多くの時間を費やします。ユーザーが日常的にギガビット/秒のインターネット接続を確立するまでは、クライアントの処理能力はおそらくまったく無関係です。サーバーがページを暗号化するために必要とするCPUパワーは、別の問題です。数百または数千のユーザーに対応できないという問題があるかもしれません。

もう1つの小さな点（たぶん誰かが確認できる）、ユーザーがテキストボックスなどのフォームアイテムにデータを入力し、何らかの理由でページを更新したり、サーバーが一瞬クラッシュしたりすると、ユーザーが入力したデータは失われますHTTPS。ただし、HTTPを使用して保持されます。

注：これがブラウザ固有のものかどうかはわかりませんが、Firefoxブラウザで発生します。

IIS 8.0を搭載したWindows Server 2012では、サーバー名の表示であるSNIが提供されるようになりました。これにより、IISの複数のSSL Webアプリケーションを1つのIPアドレスでホストできます。