すべてにHTTPSを使用しないのはなぜですか？
サーバーを設定していて、SSL証明書を持っている場合、購入/ログインだけでなくサイト全体にHTTPSを使用しないのはなぜですか？サイト全体を暗号化し、ユーザーを完全に保護する方が理にかなっていると思います。すべてが保護されるため、何を保護する必要があるかを決定するなどの問題を防ぐことができ、実際にはユーザーにとって不便ではありません。
サイトの一部にすでにHTTPSを使用している場合、サイト全体にHTTPSを使用したくないのはなぜですか？
これは関連する質問です： なぜhttpsはログインにのみ使用されるのですか？ 、しかし答えは満足のいくものではありません。答えは、サイト全体にhttpsを適用できなかったことを前提としています。
いくつかの理由が考えられます。
- 一部のブラウザーはSSLをサポートしない場合があります。
- SSLはパフォーマンスを多少低下させる可能性があります。ユーザーが大規模な公開ファイルをダウンロードしている場合、これらを暗号化するたびにシステムに負担がかかる場合があります。
HTTPSを使用する場合、他の理由（特にパフォーマンスに関連する）に加えて、IPアドレスごとに1つのドメインのみをホストできます*。
Server HTTPヘッダーにより、応答するドメインがサーバーに通知されるため、単一のサーバーがHTTPで複数のドメインをサポートできます。
HTTPSでは、サーバーは最初のTLSハンドシェイク中（HTTPが開始する前）にクライアントに証明書を提供する必要があります。これは、Serverヘッダーがまだ送信されていないため、どのドメインが要求され、どの証明書（www.foo.com、またはwww.bar.com）であるかをサーバーが知る方法がないことを意味します。 ）で応答します。
*脚注：技術的には、異なるポートでホストしている場合、複数のドメインをホストできますが、一般的にはオプションではありません。 SSL証明書にワイルドカードがある場合、複数のドメインをホストすることもできます。たとえば、foo.example.comとbar.example.comの両方を証明書* .example.comでホストできます。
SSL/TLSの使用頻度はほとんどありません。 セッション全体にはHTTPSを使用する必要があります。HTTP経由でセッションIDを送信することはできません。ログインにhttpsのみを使用している場合は、明らかに 2010年のOWASPトップ1 "A3：Broken Authentication and Session Management"に違反しています。
書留郵便で、改ざん防止用の不透明な封筒にすべてのカタツムリメールの投稿を送信してみませんか？郵便局の誰かが常にそれを個人的に管理しているので、だれもあなたのメールを覗き見していないことを確信できます。明らかに、答えは、一部のメールは費用の価値があるが、ほとんどのメールはそうではないということです。誰かが私の「刑務所から出てくれてうれしい！」と読んでも構わない。ジョーおじさんへのはがき。
暗号化は無料ではなく、常に役立つとは限りません。
セッション（ショッピング、銀行など）が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よりも多くのリソースを消費します。
サーバーとクライアントの両方にさらに多くを要求します。
どこでもHTTPSを使用する必要がありますが、次のものは失われます。
BREACHおよびCRIME攻撃のため、SSL圧縮またはSSLを介したHTTP圧縮は絶対に使用しないでください。そのため、応答にセッションまたはcsrf識別子が含まれる場合、圧縮は行われません。 Cookieのないドメインに静的リソース（images、js、css）を配置し、そこで圧縮を使用することにより、これを軽減できます。 HTMLミニファイも使用できます。
1つのSSL証明書、1つのIPアドレス。SNIを使用しない限り、すべてのブラウザー（古いAndroid、blackberry 6など）で機能しません。
SSLを使用しない外部コンテンツをページ上でホストしないでください。
ブラウザがHTTPページにアクセスすると、アウトバウンドHTTPリファラーヘッダーが失われますが、これは問題になる場合もあれば、そうでない場合もあります。
セッション全体が暗号化されている場合、プロキシレベル（ISPなど）で画像やjsなどの静的リソースのキャッシュを使用することはできません。
[〜＃〜] https [〜＃〜]は、[〜＃〜]で保護されたHTTPです。 ssl [〜＃〜]。サイトを維持して信頼させるには、有料の証明書を登録する必要があります。
サイトがユーザーと情報を交換する必要があり、暗号化によって情報を保護する場合は、HTTPSが必要です。
そうでない場合、HTTPSは必要ありませんが、必要に応じてHTTPSを使用できます。
ユーザーがテキストボックスなどのフォームアイテムにデータを入力し、何らかの理由でページを更新したり、サーバーが1秒間クラッシュした場合、ユーザーが入力したデータは失われますHTTPS。ただし、HTTPを使用して保持されます。
注：これがブラウザー固有のものかどうかはわかりませんが、Firefoxブラウザーでは確かに起こります。
IIS 8.0のWindows Server 2012は、IISの複数のSSL Webアプリケーションを1つのIPアドレスでホストできるサーバー名表示であるSNIを提供します。
WhirlWindの応答に加えて、SSL証明書のコストと適用可能性、アクセスの問題（可能性は低いですが、クライアントがSSLポート経由で通信できない可能性がある）などを考慮する必要があります。
SSLの使用は、保証されたセキュリティブランケットではありません。この種の保護は、魔法の弾丸に頼ろうとするのではなく、アプリケーションのアーキテクチャに組み込む必要があります。
明らかな理由はパフォーマンスです。すべてのデータは、送信前にサーバーで暗号化され、受信時にクライアントで復号化される必要があります。これは、機密データがない場合は時間の無駄です。また、サイトのキャッシュ量にも影響する場合があります。
また、すべてのアドレスがおなじみのhttps://ではなくhttp://を使用する場合、エンドユーザーを混乱させる可能性があります。また、この回答を参照してください。
httpsでは、サーバーがクライアントの要求と応答を暗号化および復号化する必要があります。サーバーが多数のクライアントにサービスを提供している場合、パフォーマンスへの影響は合計されます。これが、httpsの現在の実装のほとんどがパスワード認証のみに制限されている理由です。しかし、すべてのGmailがサイト全体にSSLを使用しているため、コンピューティングパワーが向上すると、これは変わる可能性があります。
私たちの会社のあるプロジェクトで、SSLメッセージが消費する帯域幅がプレーンメッセージよりもかなり大きいことがわかったと言われました。誰かが驚いた12倍のデータだと言ったと思います。私はこれを自分で確認していませんが、非常に高いように聞こえますが、各ページに何らかのヘッダーが追加され、ほとんどのページに少量のコンテンツがある場合、それはそれほど遠くないかもしれません。
そうは言っても、httpとhttpsを行き来して、どのページがどのページであるかを追跡するという面倒な作業は、私にとっては大変すぎるように思えます。それらを混ぜ合わせたサイトを構築しようとしたのは一度だけで、Javascriptで作成されたポップアップウィンドウのような複雑なものが間違ったプロトコルをアタッチしているなど、複雑なものにつまずいたときに計画を放棄することになりました。結局、サイト全体をhttpsにするだけでトラブルが少なくなりました。ログイン画面と支払い画面のみを保護する必要があり、それらがシンプルなページであるという単純なケースでは、ミックスアンドマッチは大した問題ではないでしょう。
クライアントの復号化の負担についてはあまり心配しません。通常、クライアントは、データを処理するのに必要な時間よりも多くの時間を、データがネットワーク上に届くのを待つことに費やします。ユーザーが日常的にギガビット/秒のインターネット接続を使用できるようになるまで、クライアントの処理能力はおそらくほとんど無関係です。ページを暗号化するためにサーバーが必要とするCPUパワーは別の問題です。数百または数千のユーザーに追いつくことができないという問題があるかもしれません。