TLSと暗号化セキュリティの比較

Question

2つの異なるWebサイトの接続セキュリティを比較しようとしています。機密性の高い個人情報をこれらのWebサイトの1つに入力します。銀行業界のこの部分に精通していないため、それらのセキュリティに関する意見を探しています。私は両方のWebサイトで接続セキュリティを確認しましたが、1つは少し「時代遅れ」のようです。私は情報セキュリティのこの側面の専門家でもありませんが、一般的な理解はあります。

ウェブサイトA：TLS 1.0 AES、256ビット暗号化（高）; 1024ビット交換のDH

ウェブサイトB：TLS 1.2 AES、256ビット暗号化（高）; 2048ビット交換のRSA。

どちらのWebサイトも（明らかに）HTTPSを使用していますが、ブラウザのGoogle ChromeおよびFirefoxがWebサイトAに「安全でないスクリプト」を実行しようとしているとフラグを立てています。調べたところ、Javascriptをロードして安全でない接続を介してGoogleフォントをインポートします。

WebサイトBはTLS 1.2を使用しているため、より安全に見えますが、私の理解ではセキュリティも実装に関係しています。専門家であるふりはしませんが、RSA対 "DH"にも精通しています。また、「数字が大きい=良い」という誤りに陥りたくありません。ウェブサイトBも大手の信用機関の一部なので、私は彼らにもっと安心しています。

あなたが提供できるあらゆる助けをありがとう！

編集：ユーザーkaidentityの提案に従って、ssllabs.comで両方のサイトを実行しました。サイトAはC-を取得し、サイトBはA-を取得しました。他に何か追加するものがあれば、私はまだもっと聞きたい（そして学びたい）と思っています。

Z.T. · Accepted Answer

Googleの新しいバージョンChromeはDHEをサポートしていません。私は個人的に彼らの決定に同意しませんが、彼らは決定しました[1] 2048ビットのRSAと1024ビットのDHEを備えたサーバーの場合は悲しいことにあまりにも一般的すぎる（特に悲しいことに、多くの人がNSAはキー交換の高速ブルートフォーシングを有効にするように事前計算している）と信じている一般的な素数を使用しているDHEであり、DHEの最小強度を指定できないためハンドシェイク中に、セキュリティ面で最良の結果を得るには、DHEとのハンドシェイクを試行し、サーバーから提供されたパラメーターのサイズを確認し、それらを証明書のRSAキーのサイズと比較してから、続行するかどうかを決定します。または、DHEなしで再試行して、非PFS RSA鍵交換を取得しようとします（サーバー自体で無効にされて、DHEの使用を強制する可能性があります）。この「プロービング」ハンドシェイクにより、非常に多くの遅延が発生します（ドメインごとに暗号スイートをキャッシュした場合でも） IPアドレスペア）。したがって、DHEをサポートしないことを選択し、ECDHEに切り替えることを全員に推奨しました。 NIST P-256。

したがって、1024ビットDHEと単純な2048ビットRSA鍵交換の間で、Google Chromeは両方のケースで同じになりますが、他のクライアントでは、敵が1024 DHEをブルートフォースできる可能性をトレードオフする必要があります（一部現在考えているのはNSAできる）だけでなく、誰かがすべての暗号化されたトラフィックを記録し、証明書が期限切れになるのを待ってから、期限切れの証明書の秘密鍵を収集から取得し、記録されたすべてのトラフィックを復号化します。事後1年以上PFSを希望しますが、どちらの方法も悪いです。

私は両方のサイトに2048ビットのsha256証明書があり、そこには評判の良いCAからの正しいチェーンが付いているため、違いはありません。

両方がCBC暗号スイートを使用していて、クライアントが最新で、TLS 1.0がTLS 1.1よりも悪くならないようにするBEAST対策がある場合、それらはほぼ同じように悪いです。

TLS 1.2を使用するサイトBには、CBCの代わりにGCMを使用するオプションがあります。これは、TLSのMAC-then-encrypt構成が正しく実装するのが途方もなく難しいため、特に重要です[2] [3] [4]。サイトBはTLS_RSA_WITH_AES_256_CBC_SHA、TLS_RSA_WITH_AES_256_CBC_SHA256またはTLS_RSA_WITH_AES_256_GCM_SHA384？サイトBがGCMを使用している場合、サイトAよりも安全です。