Perfect Forward Secrecyを実装するWebサイトが増えないのはなぜですか？

Question

私が理解していることから、WebサーバーでPFSを有効にするために必要なことは、SSL/TLSハンドシェイクで使用される暗号スイートのリストに一時的な暗号スイート（鍵交換にDHEおよびECDHEを使用するもの）を追加することだけです。古いWebサービスと暗号ライブラリの一部がこれらの暗号スイートをサポートしていないことを知っています。それに加えて、最近のすべてのブラウザはPFSをサポートしています。 PFSを有効にしても、一部のユーザーがアップグレードできない場合やアップグレードを拒否した場合に備えて、互換性のない古いブラウザーが機能するのを防ぐことはできません。

それで、ここの問題は何ですか？ Perfect Forward Secrecyを実装するWebサイトが増えないのはなぜですか？

Tom Leek · Accepted Answer

実際、ほとんどのWebサイトdoは forward secrecy を実装しています。つまり、「DHE」（または「ECDHE」）暗号スイートの少なくとも1つです。ほとんどのSSL実装はそのままでそれらをサポートし、ほとんどのSSLサーバー証明書で十分です（DHE暗号スイートでは、サーバーのキーは署名に使用されます）が、ほとんどすべての人がRSAを使用しますそして、ほとんどすべてのRSA証明書は、署名の鍵の使用を許可します）。

ただし、ほとんどのSSL実装はcourteousでもあり、サーバーはクライアントの設定に従います。つまり、クライアントによってサポートされていると発表された暗号スイートのリスト（ClientHelloメッセージで）では、サーバーは通常、サーバー側でもサポートされている最初の暗号スイートを選択します。ほとんどのクライアントは非DHE暗号スイートを最初に置く傾向があるため、DHEスイートは未使用のままです。

DHE暗号スイートによって発生する追加コストはわずかであり、ほとんどの場合無視できます。

ハンドシェイクの計算コストは約2倍になります。つまり、基本的なサーバーは、使用可能なCPUに基づいて、3000ではなく1秒あたり1000回のフルハンドシェイクのみを実行できます。サーバーは通常、1台のPCで毎秒1000の新しいクライアントを誇るわけではないので、この制限は実際には本当の制限ではありません。
余分な帯域幅は小さく、DHE暗号スイートの使用によって引き起こされるオーバーヘッドは1キロバイト未満です。繰り返しになりますが、このオーバーヘッドは完全なハンドシェイク、つまりクライアントとサーバー間の最初の接続のみに対するものです。以降の接続では、「短縮ハンドシェイク」が使用されます。これはより効率的で、実際の暗号スイートによる影響はまったく受けません。

つまり、要約すると、前方機密はすでにそこにあります。クライアントとサーバーの従来の動作（優先順位）が原因で、技術的な理由はなく、イナーシャのみです。場合によっては、DHEが「非常に高価」で「パフォーマンスに大きな影響を与える可能性がある」という根拠のない噂に基づいて、開発者またはシステム管理者がDHEサポートを無効にします。ブラウザーとサーバーが非DHE暗号スイートを選択するのは、主にそれがデフォルトの動作であり、だれもそれについて何かをするのに十分な動機を感じていないためです。

完全にするために、そこにが追加の効果があります。 SSLにはRC4のDHE暗号スイートがありません（DHとRC4の間に互換性はありませんが、そのような標準の暗号スイートが定義されていない場合があります）。そのため、クライアントとサーバーはRC4暗号スイートを優先し、DHE暗号スイートの使用を間接的にしないことを意味しました。

Steffen Ullrich · Answer

DHEハンドシェイクは非常に高価であるため、サーバーのパフォーマンスに大きな影響を与える可能性があります。 ECDHEの方がはるかに優れています（最適化された実装ではオーバーヘッドが約15％しかない）が、それをサポートするライブラリが必要です。 OpenSSL、例えばほとんどのUNIXベースのWebサーバーの背後にあるライブラリで、1.0.1のサポートが追加されました。これは、有名なハートブリード攻撃を可能にするハートビート拡張を追加したバージョンです。そのため、サーバーがOpenSSLを必要とし、効果的なPFSを使用し、この深刻な攻撃からも免疫を取りたい場合は、数日前のOpenSSLバージョンを使用するか、バージョンにパッチを適用する必要があります。

したがって、結局のところ、PFSを追加するのが面倒すぎる多くのWebサイトが良いことかもしれません:)

David Holmes · Answer

サイトが転送秘密（Perfect Forward SecrecyまたはPFSとも呼ばれます）を実装しないいくつかの理由を次に示します。

定義により、TLS終端サーバーとクライアントのみが実際のペイロードを復号化できます。これは、暗号文を復号化する正当な理由があるかもしれない他のプロセスが会話からロックアウトされることを意味します。これを行うには多くの正当な理由があり、ここにいくつかの例があります。

PFSは、トラフィックを定期的にタップして復号化し、ステータスコードをチェックして、ネットワークを「アップ」または「ダウン」としてマークする可用性監視システムを破壊します。このため、データセンター全体が暗くなるのを見てきました。
「ssldump」などの診断ツールはPFSで動作しなくなりました。エンドユーザーが「ユーザー名とパスワードを入力すると、システムはログインしていると言っていますが、ログインしていません。何が起こっているのですか？」 PFSを使用すると、管理者は特定の接続をキャプチャしてから復号化して、内部のHTMLを確認することはできません。
WANアクセラレータは各セッションキーを取得し、スポークアンドハブ構成でオフィス全体のデータの重複排除を実行します。 WANアクセラレータにより、パフォーマンスが向上し、帯域幅が減少しました。本社に接続して同じ5Mb PDFファイル（新しい価格表など）をダウンロードするキャンパスオフィスの50人を想像してください。重複除外とは、PDFがホームオフィスから正確に1度転送され、キャンパスサイトからアクセスするすべての人がWANアクセラレータによってキャッシュされたローカルコピーを静かに受信することを意味しましたPFSはそれを破り、PDFを50回転送する必要があります。
SSLキーを共有する高可用性（HA）システムは、PFSによって破壊される可能性があります。遅いTLS接続でギガバイトのISOファイルをダウンロードしているときに、TLSサーバーが突然停止したとします。 HAシステムでは、別のTLSサーバーがセッションキーを計算し、接続をサイレントに「ピックアップ」してダウンロードを続行できます。 PFSは古いHAシステムを破壊する可能性があります。注：HA SSLサイトはめったにありませんが、存在しています。

顧客と一緒にすべての例を見てきました。はい、それぞれに方法がありますが、それらはすべて余分な作業を伴います。

サイト管理者またはTLSベンダーが修正と機能に優先順位を付けようとしているとき、彼らはフォワードシークレシー（国家国家のスパイからの保護）の宣伝された利点が現時点ではネットワークの変更または帯域幅の増加を正当化しないと判断する場合があります。

つまり、AlexaランクではなくIPアドレスで測定すると、ほとんどのインターネット（50％以上）はTLSをサポートします。