Perfect Forward Secrecyを構成する前に知っておくべきことは何ですか？
PFSは、誰かが私たちの秘密鍵を盗んだ場合に私たちの露出を 制限するその本来の能力 のため、私たちの監査部門で注目を集めています。
- これを実装する前に知っておくべき落とし穴やよくある間違いは何ですか？管理、実装固有、またはプラットフォーム固有のものはありますか？
- PFSでできることとできないことについて誤解はありますか？私たちの監査部門は現実のチェックが必要ですか？
- PFSの利点はアプリケーションによって制限されますか？ （ウェブvs smtpなど）
これらの懸念の一部は、 この回答 から生じます。これは、すべてのWebクライアントがPFSをサポートするわけではないことを意味するようです。サーバーでPFSを必須にする前に、非互換性について説明し、準備したいと思います。
- 私のOSベンダーまたはロードバランサー（SSLオフロード）が使用された暗号化のレポートをサポートすることを期待することは理にかなっていますか？使用統計を生成したいのですが。
SSLのPFSは、サーバーが新しいセッションごとにDiffie-Hellman鍵交換と署名を実行することを意味し、ハンドシェイクのCPUコストはサーバーは、PFS以外の暗号スイートと比較して約2倍になります。しかし、ハンドシェイクのCPUコストが無視できないことはめったにありません（複数の接続を開くクライアントは、対称暗号化のみを使用する省略されたハンドシェイクを使用し、基本的なPCは、単一のCPUで1秒あたり数百の完全なハンドシェイクを処理するのに十分なパワーを備えています芯）。コンテキスト内のベンチマークを作成することをお勧めします。
SSLを使用しても、RC4暗号化もサポートする定義済みのPFS対応の暗号スイートはありません。それとは別に、現在展開されているすべての非考古学的Webブラウザーは「DHE」暗号スイート（PFSを生成）を受け入れるため、相互運用性の問題はありません。問題はむしろRC4が必要かどうかです：鍵の侵害の恐れ（PFSが何らかの保護を追加することに対する恐怖）と、選択された暗号文攻撃（つまり、RC4の暗号スイートが影響を受けないように見えるBEAST）に対する恐れのバランスをとる必要があります。
OSまたはロードバランサーmightは暗号スイートの統計を報告しますが、私はそれには賭けません。 OpenSSL （コマンドライン実行可能ファイル、s_clientコマンド）。 Wireshark のような適切なプロトコルアナライザーを使用することもできます。これにより、特定の接続で使用されている暗号スイートがわかります（暗号スイート識別子は、ハンドシェイクなので、スニファーで簡単につかむことができます）。
相互運用性はこれまで、特にipsecの問題でした。 SSLは少し簡単ですが、すべてのクライアントがサポートしているわけではありません。トラフィックを確認したい場合は、おそらくSSLを使用していると想定して、スパンポートでtcpdumpを実行し、ハンドシェイクで受け入れられた暗号スイートを探すスクリプトを記述します。
これを実装する前に知っておくべき落とし穴やよくある間違いは何ですか？管理、実装固有、またはプラットフォーム固有のものはありますか？心に浮かぶそのいくつか。
前方秘密TLSで使用される鍵交換アルゴリズムは2つあります。 DHEおよびECDHE。幅広いクライアントと秘密を共有するには、両方をサポートする必要があります。 ECDHEはDHEよりもパフォーマンスが高く、Java 7（下記参照）との互換性のため）であるため、一般的に優先する必要があります。
前方機密を必須にすると、Windows XP上のInternet Explorer（すべてのバージョン）が除外されます。 XPのSSL/TLSスタックに組み込まれているウィンドウを使用するものについても同様です。
DHEの場合は、強力なdhパラメータを使用する必要があります。カスタム生成されたdhパラメータを少なくとも2048ビットの素数で使用する必要があります（dh素数のセキュリティは、同じ長さのRSAキーに相当します）。
DHE暗号スイートをネゴシエートし、1024ビットより大きいDHパラメータを使用すると、Java 6および7が機能しなくなります。これはECDHEをサポートしていないため、Java 6の場合は特に深刻な問題です。
サーバーでPFSを必須にする前に、非互換性について説明し、準備したいと思います。
1つのオプションは、転送秘密暗号スイートを優先するが必須ではないようにして、各接続に使用される暗号スイートをログに記録するようにサーバーを設定することです。次に、ログを確認し、前方秘密を義務付けた場合に失うクライアントの数を決定できます。
PFSでできることとできないことについて誤解はありますか？私たちの監査部門は現実のチェックが必要ですか？
基本的に、転送秘密は、キーを盗んでトラフィックを受動的に解読するのを防ぐことです。特に、転送の秘密がなければ、トラフィックを監視して保存し、後でキーを盗んだ人は、以前にキャプチャしたトラフィックに戻って復号化できます。
フォワードシークレシーが行わないことは、あなたのキーを盗んだ誰かがあなたを偽装してあなたになりすますことを防ぐことです（そして、真ん中の人として振る舞うか、サーバーを彼らのものに置き換えます）。
対称暗号化が破られている場合、転送秘密は役に立ちません。前方秘密鍵の交換に使用される暗号化も、潜在的に破られる可能性があります（上記のdhパラメータに関するコメントを参照）。
PFSの利点はアプリケーションによって制限されますか？ （ウェブvs smtpなど）
利点は同じですが、クライアントでのサポートがそれほど一般的ではない場合があります。