すべてのサイトでデフォルトでSSLを使用する必要がありますか？
現在、Webアーキテクチャを新しい環境に移行中です。ほぼ完全に静的なサイトから、認証を必要とし機密コンテンツを含む動的なサイトまで、数十の異なるサイトが含まれています。私たちのWebサーバー管理者は（開発チームからの入力なしで）すべてにSSLを強制することを新しい環境の標準にすることを決定しました。私はこの決定に同意しません、そして私がそれを議論するために座るとき、できるだけ多くの知識を持ちたいです。これが私がこれまでに持っているものです：
- サイトごとに、SSL証明書には直接コストがかかります。 dev、qa、およびprod環境があるため、各サイトに必要な3つの証明書です。
- 大部分のページでは、コンテンツは安全ではなく、SSLを強制すると、暗号化と復号化のためにサーバーでのページ要求に時間がかかります。
- 私が理解していることから、ほとんどのブラウザはSSLされたページをキャッシュしないため、ページリクエストには時間がかかります
- 古いブラウザでは、SSLを使用するとファイルのダウンロードに問題が発生します
ユーザーが認証中または機密データを要求しているときにSSLを強制することに問題はありません。ただし、すべてのサイトでデフォルトでSSLを強制するのは少し大変だと思います。
SSLcanは、ネットワークレベルのキャッシュを禁止します。これには回避策がありますが、同じネットワーク内の複数のコンピューターがページリソースを再ダウンロードする必要があることを意味する場合があります。これにより、両端のネットワーク負荷が増加する可能性があります。最新のブラウザでは、ブラウザレベルのキャッシュは問題ではありません。
SSLは、いわゆる「仮想ドメイン」の使用を複雑にします。従来、SSL接続を形成するには、ブラウザとサーバーが同じドメイン名で動作している必要があります。これにより、サーバーが間違った証明書で応答するため、1つのIPで複数のSSL証明書をホストすることができなくなりました。 Server Name Indication （SSLが使用するTLSプロトコルの拡張）の実装により、これに関する多くの問題が修正されました。
純粋なパフォーマンスでは、トンネリングされたデータの対称暗号化と整合性チェックはそれほど高価ではありません。サーバーがネットワーク速度で暗号化および復号化できない場合は、神独自の光ファイバーを使用しているか、i486の交換を検討する必要があります。ただし、「ハンドシェイク」と呼ばれるSSL接続の開始は少しコストがかかり、高負荷（1秒あたり数百以上の接続がある場合）でパフォーマンスのボトルネックになる可能性があります。幸い、特定のブラウザインスタンスはトンネルとSSLセッションを再利用するため、ユーザーが数十人しかない場合は問題ありません。
全体として、SSLをどこにでも配置することは、セキュリティに「温かみのあるあいまいな感覚」を与える方法のように見えます。これは良くない。これは通常、無関係なことに集中することにより、管理者が実際のセキュリティ問題を無視する可能性が高くなることを意味します。また、システムの保守がより複雑になり、問題の診断と修正がより困難になります。管理者の観点からは、これにより、解雇と交換のコストが増加するため、ジョブがより安全になることに注意してください。
トーマスの答え への返信：
サイトごとに、SSL証明書には直接コストがかかります。 dev、qa、およびprod環境があるため、各サイトに必要な3つの証明書です。
ほとんど真実ではありません。有効な最新の証明書を使用して、SSLの背後にすべての開発者とQAを用意する必要はありません。おそらく、有効な証明書を持つ1つのステージングサイトが必要です。ただし、Apacheフロントエンド以外では、バックエンドはSSLが関係していることを認識してはなりません。開発証明書を購入して、独自のテストや特別なテストを行っているわけではありません。
また、コストはわずかです。証明書の実際の費用よりも多くのお金を会話に費やしています。
大部分のページでは、コンテンツは安全ではなく、SSLを強制すると、暗号化と復号化のためにサーバーでのページ要求に時間がかかります。
少し。測定しましたか？インターネット速度の変動がSSL処理のコストよりも優先されるため、測定が難しい場合があります。
私が理解していることから、ほとんどのブラウザはSSLされたページをキャッシュしないため、ページリクエストには時間がかかります
繰り返しますが、これを測定しましたか？
古いブラウザでは、SSLを使用するとファイルのダウンロードに問題が発生します
本当に？この問題がある特定の「古いブラウザ」をサポートする予定はありますか？ 1つが見つからず、誰かがどこかでこの問題を抱えている可能性があると考えている場合は、過剰に設計している可能性があります。ログをチェックして、顧客が実際に使用しているブラウザを確認し、問題があるかどうかを判断します。
「どこでもSSL」はあまり良いアプローチではないことに同意します。 SSL以外のポート80の「ようこそ」ページが少なくとも1つ必要だと思います。しかし、あなたの現在の一連の問題が確かな理由であるかどうかはわかりません。 SSLが実際に実際のコストまたは実際のパフォーマンスの低下を伴うと主張するには、かなり多くの測定が必要だと思います。
2012年の時点で、サイトは、個人を特定できる（PII）または商業的に重要な情報がある場合、またはログインの概念がある場合にのみSSLを使用する必要があります。
価値が低く、信頼性の低い読み取り専用の公開情報のみを公開するサイトは少し議論の余地がありますが、HTTPSを介してすべてを有効に提供できる可能性があります。攻撃者は、マルウェアやアドウェア、またはリダイレクトをHTTPコンテンツに挿入しようとする可能性があります。
「SSLを介したすべて、特定の免除なし」という企業ポリシーは合理的です。
また、 HTTP Strict Transport Security のデプロイも検討して、ユーザーがexample.comと入力した最初のリクエストでさえHTTPS経由で送信されるようにする必要があります。
Man-in-the-middle攻撃は、特にWi-Fiネットワークだけでなく、ISPおよび国レベルでも現実の問題です。 SSLを介してログインフェーズのみを実行し、暗号化されていないセッションCookieを渡すと、そのセッションCookieが盗まれます。明確なデモンストレーションについては、 Firesheep を参照してください。
SSLは、セッション中または無期限に、ユーザーごとに安全にキャッシュできます。クライアントエンドプロキシキャッシュは現在まれであり、その場合の最適化は重要ではありません。それらが存在する場合、それらは一般的に物事を間違え、SSLを介してそれらをバイパスすることは価値があります。
適切に実装されたSSLまたはSPDYは高速である可能性があります。サーバーのオーバーヘッドは高くなく、別のリバースプロキシマシンに簡単に移動できます。 SSLCDNがあります。
開発者とテスター専用のサイトの実際の証明書を購入する必要はありません。証明書のコストは数十ドルと低く、非営利のサイトでもごくわずかです。
ネットワーク全体でデータを暗号化することは、多層防御の有用なレイヤーです。もちろん、それだけではサービスを安全にするだけでは不十分ですが、ある種の問題を解消し、低コストです。
読み取り専用データの場合でも、クライアントが本物のサイトを取得していることを知っていることには価値があります。たとえば、バイナリをダウンロードしている場合は、トロイの木馬を挿入したくないでしょう。
SSLを介する必要があるページと、開発者の労力を必要としないページを安全に区別します。
特に協議なしに、標準を多様なシステムの拘束衣にすることは決して良いことではありません。しかし、特別な理由がない限り、サイトはすべてSSLを使用する必要があると言うのは、私には理にかなっています。ケースバイケースの例外の良い例。SSLを提供する必要がありますが、リダイレクトを強制しないでください。
- このサイトは大規模なバイナリダウンロード（音楽/ビデオ/ソフトウェア配布）を提供しているため、より多くのキャッシュとより高速なダウンロードを許可することが重要です（データを表示）
- クライアントは古風なIEまたはSSLを適切に実行できない組み込みクライアントです（繰り返しますが、実際に問題があることを示してください）
- サイトには非常に多くのリソースがあり、ロボットがHTTPSを介してインデックスを作成する必要があります
どこでもSSLを使用する場合は、重要になった場合に最適化できる方法で、さらにいくつかのマシンリソースを使用します。 SSLを使用しない場合は、セキュリティをケースバイケースで検討するためにより多くの開発者リソースを費やすか、アカウントの盗難が発生しやすくなります。
GoogleのAdam Langleyが2010年に書いた ：
私たちが世界に伝えたいポイントが1つあるとすれば、SSL/TLSはもはや計算コストが高くないということです。 10年前は真実だったかもしれませんが、もはやそうではありません。ユーザーに対してHTTPSを有効にする余裕もあります。
今年（2010年）の1月、GmailはデフォルトですべてにHTTPSを使用するように切り替えました。以前はオプションとして導入されていましたが、現在ではすべてのユーザーがHTTPSを使用して、ブラウザとGoogleの間で常にメールを保護しています。これを行うために、追加のマシンや特別なハードウェアを導入する必要はありませんでした。本番フロントエンドマシンでは、SSL/TLSはCPU負荷の1％未満、接続あたり10KB未満のメモリ、およびネットワークオーバーヘッドの2％未満を占めます。多くの人がSSLには多くのCPU時間がかかると信じており、上記の数値（初めて公開）がそれを払拭するのに役立つことを願っています。
だから私はこの質問に対するいくつかの素晴らしいの答えを見てきましたが、数日後、いくつかの欠落しているものがあることがわかりました。したがって、私が言及したいことがいくつかあります。
すべてにSSLを使用する理由
- セキュリティ-SSLで暗号化されているページが少ない場合は、機密データが含まれているページを「スニッフィング」する方が簡単です。現在、SSLは非常に安全なので、これは心配する必要はありませんが、秘密鍵が危険にさらされた場合は、セキュリティの追加レイヤーを用意して、悪意のあるユーザーが侵入しにくくすることをお勧めします。ジューシーなもの。
- 信頼性-検証済みの証明書があるサイトにアクセスすると、信頼しやすいと主張する人がいます。検証済みの証明書にはお金がかかるため、所有者が信頼のシンボルに投資したことを知っているサイトを信頼する方が簡単です。
- 面倒-SSLですべてを包括するのはとても簡単です。あなたがしなければならないのは、すべてのリソースリンクの始めにある
http:を切り落とすだけで、あなたは元気です。 - SEO構成-SEO構成を気にする必要はまったくありません。検索エンジンは
http://とhttps://を別々のエントリとしてインデックス付けすると聞いたので、一貫性を保つために（SEOとページの動作の両方で）、すべてをSSLで覆い、301リダイレクトを設定するだけでいいようです。簡単な解決策。 - 一貫性-すべてを
https://するだけで、はるかに一貫性のあるWebサイトが得られます。 SSLと非SSLのハイブリッドを実行しようとすると、多くのフレームワークが壊れます。これに加えて、URLに依存するプラグインとコードは、httpとhttpsの間を行き来しようとすると本当に意味があります。 - そのファジーセキュアフィーリング-認める必要があります。左上にある「ドメインの確認済み」と書かれた小さな緑色のバーは、とてもいい感じです。
SSLをすべて使用しない理由
- 速度-SSLは遅いです。もちろん、それほど多くはありません。ほとんどの場合、コストはごくわずかです。ただし、SSLは常に遅くなることは避けられない事実です。
- ブラウザの互換性-これはおそらく無視できることですが、サポートしたい場合は本当に SSL経由でキャッシュしない古いブラウザは、ポート80を使用する必要があります。
- プラグイン-多くのプラグインはSSLを介して正しく機能しないため、注意する必要があります。新しいプラグインを追加したい場合は、SSL設定を再構成するか、別のプラグインを探す必要があります。
- Professionalism-検証済みのSSLドメインを見るのは信頼できるように見えると主張する人もいれば、非常に素人で怠惰な解決策と見なす人もいます。実際、ブラウザの最大96％にヒットする検証済みのSSL証明書を取得するのは、本当に簡単で安価です（約10ドルかかります）。
- 面倒-つまり、すべてをSSLで送信する方が簡単だと言いましたが、同時に、すべてのリソースが
https://を介してロードされていることを確認する必要があります（またはhttp:// -> //クイックソリューション）。リンクがたくさんある場合は少し面倒な場合があり、SSLをサポートしていないサイトでユーザーが送信したコンテンツをホストしている場合は互換性がない場合もあります。そのような場合、あなたのブラウザはあなたに泣き言を言うでしょう。 「このページには安全でないコンテンツがあります」という通知を見たことがあれば、それがどれほど迷惑で、どれほど見栄えが悪いかがわかるでしょう。
つまり、実際には状況に応じたものですが、SSLを包括的に使用することは避けがちです。確かに、それはもう少し構成が必要ですが、最終的にははるかに柔軟なシステムが得られます。個人的には、「プロフェッショナリズム」のすべてがでたらめだと思います（TwitterとGoogle SSLがすべて）。ただし、外部でホストされているコンテンツやユーザーが投稿したコンテンツがある場合は、通常、すべてをSSLで送信することは非常に悪い考えです。また、すべてのSSLを開始し、多くの問題に遭遇する可能性があります。
しかし、それは私だけです。 ：D
トーマスの答えに対する別の応答では、特にそれが一番上にあるので。
また、さらに下にリンクしました SSLのベストプラクティスを含むホワイトペーパー 。
SSLは、ブラウザだけでなくプロキシサーバーからのキャッシュを防ぎます。すべてのWebページ要素は、メインサーバーから何度も送信される必要があります。これにより、ネットワークの負荷が増加します。
部分的にのみ真実です。 SSLはプロキシキャッシングを防ぎますが、notブラウザキャッシング この質問 の回答も参照してください。私の意見では大きな問題ではありません。
SSLは、いわゆる「仮想ドメイン」の使用を防ぎます。 [...]
これは部分的に真実です。ただし、証明書が1つしかない限り、仮想ドメインは正常に機能します。そうでない場合でも、 Server Name Indication（SNI） は実行可能な代替手段である必要があります（または、Windows XPが地球の表面から外れたら）。
[パフォーマンス]ただし、「ハンドシェイク」と呼ばれるSSL接続の開始は少しコストがかかり、>高負荷（1秒あたり数百以上の接続がある場合）でパフォーマンスのボトルネックになる可能性があります。幸い、特定のブラウザインスタンスはトンネルとSSLセッションを再利用するため、ユーザーが数十人しかない場合は問題ありません。
最新のハードウェアを使用している場合は、ハンドシェイクでもサーバー側でパフォーマンスの問題が発生することはありません。ハンドシェイクが「遅い」主な理由は、ネットワークパッケージをサーバーとブラウザ間で数回送受信する必要があるためです。計算能力はそれとはほとんど関係ありません。
別の言い方をすれば、SSL接続のセットアップは、データベースからデータをフェッチするPHPページをレンダリングするよりも桁違いに安価です。
全体として、SSLをどこにでも配置することは、セキュリティに「温かみのあるあいまいな感覚」を与える方法のように見えます。 >これは良くありません。これは通常、無関係なことに集中することによって、
NOT TRUE AT ALL。SSLは完全に公開されているため、サイトにSSLはまったく必要ありません。 。または、何らかの理由（ユーザーログイン、保護領域）でSSLが必要です。その場合、ベストプラクティスはどこにでもSSLを配置することです。
ページの一部にのみSSLを使用すると、あらゆる種類のあいまいなリスクにさらされる可能性があります。また、他の方法でそれらを見つけて軽減することもできますが、すべてのページでSSLを有効にするよりも複雑で、エラーが発生しやすく、時間がかかります。
このホワイトペーパー SSLを見つけました。私はそれを作成した会社とは提携していませんが、SSLセットアップを展開するときに覚えておく必要があるすべてのことの非常に簡潔な要約であることがわかりました。
言うまでもなく、セキュリティには複数のコンポーネントがあります。しかし、すでに最初の間違いを犯すことは良いスタートではありません。
この最初に自問することは、SSLはあなたに何を買うのかということです。これにより、誰もアプリケーションもトラフィックを「スニッフィング」して、Webサーバーとブラウザーの間で何が起こっているかを確認できないという保証が得られます。コストはSSL証明書を購入する実際のコストであり、ダウンロード速度をわずかに上げる継続的なコストです。古いブラウザではSSL通信を介してファイルをダウンロードするのに問題があるとおっしゃっています。私はそれについて話すことができません、そして私はそれについてあまり気にしません。セキュリティの観点から、別の懸念があります。最新のファイアウォールはトラフィックを監視して、さまざまなハッキングの試みを探します。 SSLはファイアウォールがその通信を監視するのを防ぐため、アプリケーション開発者/ Web管理者は、さまざまなハッキングの試みからアプリケーションとサイトを保護することにさらに注意を払う必要があります。簡単に言うと、本当に必要な通信のみを暗号化する必要があります。
すべてのサイトをSSLで送信する必要はないと思います。間違いなく、開発環境用の証明書を購入する必要はありません。開発用のSSL証明書が必要な場合は、簡単に生成でき、ほとんどの場合、その環境には十分です。もう1つの可能性は、ワイルドカード証明書を購入して、サブドメインの1つに開発サーバーを設定できることです。これにより、両方の環境で同じ証明書を使用できますが、ワイルドカード証明書を購入するとお金の無駄になります（高価です）開発者に作業を依頼するだけです。 SSLする必要のあるprodに複数のサブドメインがある場合は理にかなっています。
速度に関しては：はい、それは少し問題ですが、それほど重要ではありません。 SSL応答はキャッシュされないため、SSL応答を使用するとサーバーの負荷が少し増加しますが、これは管理者が知っておくべき部分だと思います。