42

現在、Webアーキテクチャを新しい環境に移行しています。ほぼ完全に静的なサイトから、認証を必要とし、機密性の高いコンテンツを含む動的なサイトまで、数十の異なるサイトが含まれています。私たちのWebサーバー管理者は（開発チームからの入力なしで）すべてにSSLを強制することを新しい環境の標準にすることを決定しました。私はこの決定に同意しません。私が座ってそれについて話し合うときは、できるだけ多くの知識を持ちたいと思います。これが私がこれまでに持っているものです：

  • サイトごとに、SSL証明書には直接コストがかかります。dev、qa、およびprod環境があるため、各サイトに必要な3つの証明書です。
  • ほとんどのページでは、コンテンツは安全ではなく、SSLを強制すると、暗号化と復号化のためにサーバーでのページ要求に時間がかかります。
  • 私が理解していることから、ほとんどのブラウザはSSLされたページをキャッシュしないため、ページリクエストには時間がかかります
  • 古いブラウザでは、SSLを使用するとファイルのダウンロードに問題が発生します

ユーザーが認証中または機密データを要求しているときにSSLを強制することに問題はありません。ただし、すべてのサイトでデフォルトでSSLを強制するのは少し大変だと思います。

4

7 に答える 7

25

トーマスの答えに答えて：

サイトごとに、SSL証明書には直接コストがかかります。dev、qa、およびprod環境があるため、各サイトに必要な3つの証明書です。

ほとんど真実ではありません。有効な最新の証明書を使用して、SSLの背後にすべての開発者とQAを配置する必要はありません。おそらく、有効な証明書を備えた1つのステージングサイトが必要です。ただし、Apacheフロントエンド以外では、バックエンドはSSLが関係していることを認識してはなりません。開発者証明書を購入して、独自のテストや特別なテストを行っているわけではありません。

また、コストはわずかです。証明書の実際の費用よりも多くのお金を会話に費やしています。

ほとんどのページでは、コンテンツは安全ではなく、SSLを強制すると、暗号化と復号化のためにサーバーでのページ要求に時間がかかります。

少し。測定しましたか？インターネット速度の変動がSSL処理のコストよりも優先されるため、測定が難しい場合があります。

私が理解していることから、ほとんどのブラウザはSSLされたページをキャッシュしないため、ページリクエストには時間がかかります

繰り返しますが、これを測定しましたか？

古いブラウザでは、SSLを使用するとファイルのダウンロードに問題が発生します

本当に？この問題がある特定の「古いブラウザ」をサポートする予定はありますか？見つからず、誰かがこの問題を抱えている可能性があると考えている場合は、過剰に設計している可能性があります。ログをチェックして、顧客が実際に使用しているブラウザを確認してから、問題があるかどうかを判断します。

「どこでもSSL」はあまり良いアプローチではないことに同意します。SSL以外のポート80の「ようこそ」ページが少なくとも1つ必要だと思います。しかし、あなたの現在の一連の問題が確かな理由であるかどうかはわかりません。SSLが実際に実際のコストまたは実際のパフォーマンスの低下を伴うことを証明するには、かなり多くの測定が必要だと思います。

于 2010-02-01T14:15:51.367 に答える
23

2020年以降、すべてのサイトでSSLを使用する必要があります。

  • 証明書は、2016年からLet'sEncryptから無料で入手できます。
  • ChromeとFirefoxは、2018年以降、プレーンHTTPWebサイトを安全でないものとしてマークしています。
  • Googleは、2017年からプレーンHTTPウェブサイトにSEOペナルティを課しています。

価値が低く、信頼性が低く、読み取り専用の公開情報のみを公開するサイトは、引き続きHTTPを使用する必要があるが、HTTPSも使用する必要があると主張されることがあります。HTTPコンテンツでは、攻撃者がマルウェアやアドウェアを挿入したり、コンテンツにリダイレクトしたりする可能性があります。一部の主要なISPは、すべての顧客のHTTPページに広告を挿入します。これは、悪意のある広告がフィードに侵入した場合の潜在的な問題です。

「特定の免除なしで、SSLを介したすべて」という企業ポリシーが推奨されます。セキュリティ標準（PCI-DSS、ISO、big4監査など）は、機密情報を処理するシステムの暗号化を想定しており、その欠如は危険信号と見なされます。

また、 HTTP Strict Transport Securityの展開を検討して、ユーザーの入力からの最初の要求でさえexample.comHTTPS経由で送信されるようにする必要があります。

中間者攻撃は、特にWi-Fiネットワークだけでなく、ISPや国レベルでも現実の問題です。サイトがログインにSSLのみを使用し、暗号化されていないリンクを介してセッションCookieを返す場合、そのセッションCookieは盗まれるだけでなく、盗まれる可能性があります。明確なデモンストレーションについては、Firesheepを参照してください。

SSLは、セッション中または無期限に、ユーザーごとに安全にキャッシュできます。クライアントエンドのプロキシキャッシュは現在ではまれであり、その場合の最適化は重要ではありません。それらが存在する場合、それらは一般的に物事を間違え、SSLを介してそれらをバイパスすることは価値があります。

適切に実装されたSSLまたはSPDYは高速である可能性があります。サーバーのオーバーヘッドは高くなく、別のリバースプロキシマシンに簡単に移動できます。SSLCDNがあります。

開発者とテスター専用のサイトの実際の証明書を購入する必要はありません。証明書のコストは数十ドルと低く、非営利のサイトでもごくわずかです。

ネットワーク全体でデータを暗号化することは、多層防御の有用なレイヤーです。もちろん、それだけではサービスを安全にするだけでは不十分ですが、ある種の問題を解消し、低コストです。

読み取り専用データの場合でも、クライアントが本物のサイトを取得していることを知っていることには価値があります。たとえば、バイナリをダウンロードしている場合は、トロイの木馬を挿入したくないでしょう。

SSLを介する必要のあるページと、開発者の労力を必要としないページを安全に区別します。

特に協議なしに、標準を多様なシステムの拘束衣にすることが望ましいことはめったにありませんが、SSLのすべてに強力なデフォルトがあるはずです。

ケースバイケースの例外の良い例。SSLを提供する必要がありますが、リダイレクトを強制しないでください。

  • このサイトは大規模なバイナリダウンロード（音楽/ビデオ/ソフトウェアディストリビューション）を提供しているため、より多くのキャッシュとより高速なダウンロードを可能にすることが重要です（データを表示）-転送中にバイナリが変更されないことが重要であり、他の検証で多層防御を提供します

  • クライアントは古風なIEまたはSSLを適切に実行できない組み込みクライアントです-2020年には、そのようなクライアントは非常に古くなります（そしておそらく危険です）

  • サイトには非常に多くのリソースがあり、ロボットがHTTPSを介してインデックスを作成する必要があります--Google、およびおそらく他のボットは、すべてをHTTPSに強制すると問題なく動作します

どこでもSSLを使用する場合は、重要になった場合に最適化できる方法で、さらにいくつかのマシンリソースを使用します。SSLを使用しない場合は、セキュリティをケースバイケースで検討するためにより多くの開発者リソースを費やすか、アカウントの盗難が発生しやすくなります。

GoogleのAdamLangleyは2010年に次のように書いています。

私たちが世界に伝えたいポイントが1つあるとすれば、SSL/TLSはもはや計算コストが高くないということです。10年前は真実だったかもしれませんが、もはやそうではありません。ユーザーに対してHTTPSを有効にする余裕もあります。

今年（2010年）の1月、GmailはデフォルトですべてにHTTPSを使用するように切り替えました。以前はオプションとして導入されていましたが、現在ではすべてのユーザーがHTTPSを使用してブラウザとGoogleの間で常にメールを保護しています。これを行うために、追加のマシンや特別なハードウェアを導入する必要はありませんでした。実稼働フロントエンドマシンでは、SSL / TLSはCPU負荷の1％未満、接続あたり10KB未満のメモリ、およびネットワークオーバーヘッドの2％未満を占めます。 多くの人がSSLには多くのCPU時間がかかると信じており、上記の数値（初めて公開）がそれを払拭するのに役立つことを願っています。

于 2012-07-30T04:44:54.487 に答える
8

だから私はこの質問に対するいくつかの素晴らしい答えを見てきましたが、数日後、いくつか欠けているものがあることに気づきました。したがって、私が言及したいことがいくつかあります。

すべてにSSLを使用する理由

  • セキュリティ-SSL暗号化されているページが数ページしかない場合は、機密データが含まれているページを「スニッフィング」する方が簡単です。現在、SSLは非常に安全なので、これは心配する必要はありませんが、秘密鍵が危険にさらされた場合は、セキュリティの追加レイヤーを用意して、悪意のあるユーザーが侵入しにくくすることをお勧めします。ジューシーなもの。
  • 信頼性-検証済みの証明書があるサイトにアクセスすると、信頼しやすいと主張する人がいます。検証済みの証明書にはお金がかかるため、所有者が信頼のシンボルに投資したことを知っているサイトを信頼する方が簡単です。
  • 手間-SSLですべてを包括するのはとても簡単です。あなたがしなければならないのは、すべてのリソースリンクの最初で切り落とすだけhttp:で、あなたは元気です。
  • SEO構成-SEO構成を気にする必要はまったくありません。検索エンジンはインデックスhttp://を作成しhttps://、個別のエントリとして使用するため、一貫性を保つために（SEOとページの動作の両方で）、SSLをすべてに適用し、301リダイレクトを設定するだけで簡単に解決できるようです。
  • 一貫性-すべてを行うだけで、はるかに一貫性のあるWebサイトが得られますhttps://。SSLと非SSLのハイブリッドを実行しようとすると、多くのフレームワークが壊れます。これに加えて、URLに依存するプラグインとコードは、との間を行き来しようとすると本当に意味がhttpありhttpsます。
  • そのファジーな安全な感覚-認める必要があります。左上にある「ドメインの確認済み」と書かれた小さな緑色のバーは、とても良い感じです。

すべてをSSLにしないのはなぜですか

  • 速度-SSLは遅いです。もちろん、それほど多くはなく、ほとんどの場合、コストはごくわずかです。ただし、SSLは常に低速になることは避けられない事実です。
  • ブラウザの互換性-これはおそらく無視できる程度ですが、SSLを介してキャッシュしない本当に古いブラウザをサポートしたい場合は、ポート80を使用する必要があります。
  • プラグイン-多くのプラグインはSSLを介して正しく機能しないため、注意する必要があります。新しいプラグインを追加したい場合は、SSL設定を再構成するか、別のプラグインを探す必要があります。
  • プロフェッショナリズム-検証済みのSSLドメインを見るのは信頼できるように見えると主張する人もいますが、非常にアマチュアで怠惰なソリューションと見なす人もいます。実際、ブラウザの最大96％に対応する検証済みのSSL証明書を取得するのは、非常に簡単で安価です（約10ドルかかります）。
  • 面倒-つまり、すべてをSSLで送信する方が簡単だと言いましたが、同時に、すべてのリソースがロードされていることを確認する必要がありますhttps://（またはhttp:// -> //迅速な解決策を実行する必要があります）。大量のリンクがある場合は少し面倒な場合があり、SSLをサポートしていないサイトでユーザーが送信したコンテンツをホストしている場合は互換性がない場合もあります。そのような場合、ブラウザはあなたに泣き言を言います。「このページのコンテンツは安全ではありません」という通知を見たことがあれば、それがどれほど迷惑で、見た目がいかに悪いかがわかるでしょう。

つまり、実際には状況に応じたものですが、SSLを包括的に使用することは避けがちです。もちろん、もう少し構成が必要ですが、最終的にははるかに柔軟なシステムが得られます。個人的には、「プロフェッショナリズム」のすべてがでたらめだと思います（TwitterとGoogle SSLがすべて）。ただし、外部でホストされているコンテンツやユーザーが投稿したコンテンツがある場合は、通常、すべてをSSLで送信することは非常に悪い考えです。また、すべてのSSLを開始し、多くの問題に遭遇する可能性があります。

しかし、それは私だけです。：D

于 2012-07-16T14:48:07.787 に答える
5

SSLは、ネットワークレベルのキャッシュを禁止できます。これには回避策がありますが、同じネットワーク内の複数のコンピューターがページリソースを再ダウンロードする必要があることを意味する場合があります。これにより、両端のネットワーク負荷が増加する可能性があります。ブラウザレベルのキャッシュは、最近のブラウザでは問題になりません。

SSLは、いわゆる「仮想ドメイン」の使用を複雑にします。従来、SSL接続を形成するには、ブラウザとサーバーが同じドメイン名で動作している必要があります。これにより、サーバーが間違った証明書で応答するため、1つのIPで複数のSSL証明書をホストすることができなくなりました。サーバー名表示（SSLが使用するTLSプロトコルの拡張）の実装により、これに関する多くの問題が修正されました。

純粋なパフォーマンスでは、トンネリングされたデータの対称暗号化と整合性チェックはそれほど高価ではありません。サーバーがネットワーク速度で暗号化および復号化できない場合は、神独自の光ファイバーを使用しているか、それらのi486を交換することを検討する必要があります。ただし、「ハンドシェイク」と呼ばれるSSL接続の開始は少しコストがかかり、高負荷（1秒あたり数百以上の接続がある場合）でパフォーマンスのボトルネックになる可能性があります。幸い、特定のブラウザインスタンスはトンネルとSSLセッションを再利用するため、ユーザーが数十人しかない場合は問題ありません。

全体として、SSLをどこにでも配置することは、セキュリティに「温かいあいまいな感覚」を与える方法のように見えます。これは良くない。これは通常、無関係に集中することにより、管理者が実際のセキュリティ問題を無視する可能性が高くなることを意味します。また、システムの保守がより複雑になり、問題の診断と修正がより困難になります。管理者の観点からは、これにより、解雇と交換のコストが増加するため、作業がより安全になることに注意してください。

于 2010-02-01T15:34:13.973 に答える
3

トーマスの答えに対する別の応答では、特にそれが一番上にあるので。

また、さらに下の方で、ホワイトペーパーをSSLのベストプラクティスにリンクしました。

SSLは、ブラウザだけでなくプロキシサーバーからのキャッシュを防ぎます。すべてのWebページ要素は、メインサーバーから何度も送信される必要があります。これにより、ネットワークの負荷が増加します。

部分的にのみ真実です。SSLはプロキシキャッシュを防ぎますが、ブラウザキャッシュは防ぎません-この質問への回答も参照してください。私の意見では大きな問題ではありません。

SSLは、いわゆる「仮想ドメイン」の使用を防ぎます。[...]

これは部分的に真実です。ただし、証明書が1つしかない限り、仮想ドメインは正常に機能します。そうでない場合でも、サーバー名表示（SNI）は実行可能な代替手段である必要があります（または、Windows XPが地球の表面から外れたら）。

[パフォーマンス]ただし、「ハンドシェイク」と呼ばれるSSL接続の開始は、少しコストがかかり、>高負荷（1秒あたり数百以上の接続がある場合）でのパフォーマンスのボトルネックを意味する場合があります。幸い、特定のブラウザインスタンスはトンネルとSSLセッションを再利用するため、ユーザーが数十人しかない場合は問題ありません。

最新のハードウェアを使用している場合は、ハンドシェイクでもサーバー側でパフォーマンスの問題が発生することはありません。ハンドシェイクが「遅い」主な理由は、ネットワークパッケージをサーバーとブラウザ間で数回送受信する必要があるためです。計算能力はそれとはほとんど関係ありません。

別の言い方をすれば、SSL接続の設定は、データベースからデータをフェッチするPHPページをレンダリングするよりも桁違いに安価になります。

全体として、SSLをどこにでも配置することは、セキュリティに「温かいあいまいな感覚」を与える方法のように見えます。>これは良くありません。これは通常、無関係なことに集中することによって、

まったく真実ではありません。完全に公開されているコンテンツであるため、サイトにSSLはまったく必要ありません。または、何らかの理由（ユーザーログイン、保護領域）でSSLが必要です。その場合のベストプラクティスは、どこにでも配置することです。

ページの一部にのみSSLを使用すると、あらゆる種類のあいまいなリスクにさらされる可能性があります。また、他の方法でそれらを見つけて軽減することもできますが、すべてのページでSSLを有効にするよりも複雑で、エラーが発生しやすく、時間がかかります。

SSLに関するこのホワイトペーパーを見つけました。私はそれを作成した会社とは提携していませんが、SSLセットアップを展開するときに覚えておく必要のあるすべてのことの非常に簡潔な要約であることがわかりました。

言うまでもなく、セキュリティには複数のコンポーネントがあります。しかし、すでに最初の間違いを犯すことは良いスタートではありません。

于 2014-04-04T07:01:45.920 に答える
2

この最初に自問することは、SSLはあなたに何を買うのかということです。これにより、誰もアプリケーションもトラフィックを「スニッフィング」して、Webサーバーとブラウザーの間で何が起こっているかを確認できないという保証が得られます。コストはSSL証明書を購入する実際のコストであり、ダウンロード速度がわずかに向上する継続的なコストです。古いブラウザではSSL通信を介してファイルをダウンロードするのに問題があるとおっしゃっています。私はそれについて話すことができません、そして私はそれについてあまり気にしません。セキュリティの観点から、別の懸念があります。最新のファイアウォールはトラフィックを監視して、さまざまなハッキングの試みを探します。SSLはファイアウォールがその通信を監視するのを防ぐため、アプリケーション開発者/ Web管理者は、さまざまなハッキングの試みからアプリケーションとサイトを保護することにさらに注意を払う必要があります。短編小説、

于 2010-02-01T14:16:19.223 に答える
-1

すべてのサイトをSSLで送信する必要はないと思います。また、開発環境用の証明書を購入する必要はありません。開発用のSSL証明書が必要な場合は、簡単に生成でき、ほとんどの場合、その環境には十分です。もう1つの可能性は、ワイルドカード証明書を購入し、サブドメインの1つに開発サーバーを設定できることです。この方法では、両方の環境で同じ証明書を使用できますが、ワイルドカード証明書を購入するとお金の無駄になります（高価です）開発者に作業を依頼するだけです。SSLする必要のあるprodに複数のサブドメインがある場合は理にかなっています。

速度に関しては：はい、それは少し問題ですが、それほど重要ではありません。SSL応答はキャッシュされないため、SSL応答を使用するとサーバーの負荷が少し増加しますが、これは管理者が知っておくべき部分だと思います。

于 2010-02-01T14:17:17.233 に答える