web-dev-qa-db-ja.com

サイトにアクセスするときに使用されるSSL / TLSのバージョンを正確に決定するものは何ですか？

Chromeの小さな鍵のアイコンをクリックすると、問題のサイトはTLS v1を使用していると表示されます。opensslを使用して確認したところ、TLS1、SSL2、SSL3を使用してサイトにアクセスできました。 SSL2は安全ではないと私が理解しているところによると、これに基づいて、サイトは3つのいずれかを使用して攻撃を受ける可能性があります。

Webブラウザーから安全なサイトにアクセスするときに使用されるSSL/TLSのバージョンを決定するものは何ですか？

tlsweb-application
19
Abe Miessler

@Terryが言うように、クライアントsuggests、サーバーchooses。詳細があります：

  • 最初のクライアントメッセージの一般的な形式（ClientHello）は、サポートされている最も高いバージョンを示し、implicitlyは、以前のすべてのバージョンがサポートされていると主張しています-これは必ずしもそうではありません本当。たとえば、クライアントがTLS 1.2をサポートしている場合、「最大バージョン：1.2」を示します。ただし、サーバーは、クライアントが必ずしも使用したくない以前のバージョン（たとえば、TLS 1.0）の使用を選択する場合があります。

  • 現代のクライアントは数回試行する習慣をつけています。たとえば、クライアントは最初に「TLS 1.2」を示すClientHelloを送信し、何か（何か）が失敗した場合、「TLS 1.0」を示すClientHelloを使用して再試行します。クライアントがこれを行うのは、TLS 1.0を実行できるが、「TLS 1.2」を含むClientHelloメッセージを拒否できる、不十分に実装された非準拠のTLSサーバーがあるためです。

    面白い結果として、アクティブな攻撃者は、初期接続を強制的に閉じることにより、両方が新しいプロトコルバージョンをサポートしている場合でも、クライアントとサーバーに古いバージョン（TLS 1.0など）を使用させることができます。これは「バージョンロールバック攻撃」と呼ばれます。クライアントとサーバーが明らかに弱いプロトコルバージョンを使用することを受け入れない限り（そしてTLS 1.0がまだ十分に強力である限り）、重要ではありません。ただし、これは、クライアントがそのような「再試行」ポリシーを実装している限り（クライアントがそのような「再試行」を実装しなかった場合）、クライアントとサーバーが「可能な」最良のプロトコルバージョンを使用していることを保証できないことを意味します。ロールバック攻撃は阻止されますが、一部のWebサイトは到達不能に見えます）。

  • SSL 2.0のClientHelloメッセージの形式は非常に異なります。クライアントがSSL 2.0とそれ以降のバージョンの両方をサポートしたい場合、SSL 2.0形式に従う特別なClientHelloを送信し、「ところで、SSL 3.0とTLS 1.0も知っている」と指定する必要があります。 。これは RFC 2246の付録E で説明されています。最近のSSLクライアント（Webブラウザー）はこれを実行しません（IE 6.0はまだ実行していますが、IE 7.0はそうではありません）。

    RFC 4346 （TLS 1.1）は、このようなSSLv2形式のClientHelloメッセージが「段階的に廃止」され、回避する必要があることを指定します。 RFC 5246 （TLS 1.2）は、クライアントがSSL 2.0をサポートしてはならない（SHOULD NOT）、したがって、そのようなClientHelloメッセージを送信する理由はないはずであることをより明確に述べています。 RFC 6176 現在SSL2.0を完全に禁止。

    現在、RFCは法律ではありません。特定のRFCをサポートしていないため、刑務所に行くことはありません。ただし、RFCは依然としてガイダンスを提供しているため、近い将来（または遠く）の状況をどうにかして示しています。

実際には：

  • ほとんどのクライアントはSSLv3 + ClientHelloメッセージのみを送信し、サーバーがサポートしているように見えるものに応じて、SSL 3.0、TLS 1.0、TLS 1.1またはTLS 1.2に問題なく接続します（ただし、 "ポリシー、バージョンのダウングレードは、アクティブな攻撃者によって強制される可能性があります）。
  • 実際、一部のクライアントはSSL 3.0をサポートせず、TLS 1.0を必要とします。
  • 同様に、一部のクライアントはTLS 1.1または1.2をサポートしません。 Webブラウザーは近年更新され（BEAST攻撃による悪評の余波で）、ブラウザー以外のアプリケーションが積極的に維持されることはほとんどありません。
  • 多くのサーバーは、そのClientHelloメッセージがSSLv3 + ClientHelloを偽装している限り、SSLv2 ClientHello形式を受け入れます。
  • あなたのようないくつかのサーバーは、いくつかのSSL 2.0を実行して満足しています。これはRFC 6176に準拠しておらず、眉をひそめています（「SSLサーバーの格付け」を信じる人は、悪いスコアを示します）。ただし、クライアントが実際にSSL 2.0をサポートしていない限り、これは深刻なセキュリティ問題ではありません。クライアントがSSL 2.0をサポートしている場合でも、いくつかのロールバック防止策（RFC 2246に記載）を含める必要があるため、SSL 2.0へのロールバックは機能しません。

広報だけの場合でも、サーバーでSSL 2.0サポート（SSLv2 ClientHello形式ではなく、実際のSSL 2.0サポート）を非アクティブ化する必要があります。

22
Tom Leek

TLSハンドシェイクプロセスを確認する必要があります。

簡単にまとめると、クライアント（この場合はブラウザー）はClientHelloメッセージをサーバーに送信します。これには、サポートする最大TLSバージョンと、優先順にサポートする暗号スイートのリストが含まれています。次に、サーバーは、TLS接続に使用するTLSバージョンと暗号スイートを決定し、ServerHelloで応答することによりクライアントに通知します。理想的には、最も高いTLSバージョンと最も強力な暗号スイートを選択する必要がありますが、TLS仕様はこれを保証しません。サーバーは、クライアントから提供されたリストから自由に使用できます。

3
user10211

クライアントがSSL/TLSを使用してサーバーにデータを送信する場合、クライアントは最初にハンドシェイクを実行して、サーバーで自身を認証する必要があります。このハンドシェイクは「ClientHello」で始まります。クライアントは、クライアントがサポートするバージョンのSSLまたはTLS、サポートされている暗号、およびその他のセッションデータをサーバーに送信します。古いバージョンのSSL（バージョン2）では、このハンドシェイクパケットを傍受し、サポートされている暗号リストを変更して、弱い暗号のみを含めることができました。 SSLv3はハンドシェイクの最後の部分でハッシュを使用するため、これはもはや不可能です。クライアントとサーバーの両方がハッシュし、送信されたメッセージと受信されたメッセージを比較します。

最新のブラウザはすべて、SSLv3からTLSv1.2までをサポートしていますが、サーバーでサポートされている最も高いバージョンを使用します。仲介者はハンドシェイクで送信されたパケットを直接変更することはできませんが、仲介者は特定のパケットを傍受してドロップすることができます。ブラウザーをだましてサーバーがSSL/TLSの特定のバージョンをサポートしていないと思わせることにより、攻撃者は交渉されたバージョンをダウングレードできます。 Praetorian's の最近の投稿にアクセスすると、その方法を確認できます： Man-in-the-middle TLSプロトコルダウングレード攻撃

SSLv3から今すぐ離れる理由

SSLv3には、プロトコルのダウングレード攻撃を防止するための特別な緩和策が含まれていましたが、必ずしもSSLv3が理想的なプロトコルであるとは限りません。 SSLv3には重要な暗号の違いがあり、TLSv1.2が現在の標準である理由をさらに示す弱点をもたらす可能性があります。合意された暗号化と認証の暗号、および鍵交換メカニズムは、プロトコルのダウングレードテストで大きく異なりました。上記の例では、TLSv1.2は楕円曲線暗号（ECC）とAESのカウンターモードを使用していますが、SSLv3は古いRC4暗号とRSAを使用しています。

なぜこれが必要なのかと尋ねる人もいます。 2013年のブラックハットの講演で、アレックススタモスは暗号化の現状と将来について話しました。彼は、危険の1つは将来のある時点で古い暗号または鍵交換メカニズムを破る可能性にあると主張しました。 RSAの場合、暗号学者と数学者は因数分解の問題で大きな進歩を遂げました。 Diffie-Hellman（DH）は暗号セキュリティの離散対数問題に依存しており、離散ログの計算に使用される効率的なアルゴリズムは存在しませんが、離散対数アルゴリズムのランタイムはこの1年で大幅に減少しました。 Stamosが議論したように、RSAまたはDHが失敗すると、コード署名が破られ、SSL/TLSに対する攻撃が非常に蔓延するようになります。

要約すると、接続に対するアクティブな攻撃により、暗号化セキュリティが低下する可能性があります。クライアントとサーバーは、新しいバージョンのTLSのみをサポートすることで、これを防ぐことができます。さらに、クライアントは失敗したハンドシェイクに適切に応答する必要があります。現在、多くのブラウザはセキュリティよりも相互運用性を選択しており、これによりプロトコルのダウングレード攻撃が可能になります。これらの変更には、かなりの時間と労力が必要です。ブラウザは、ハンドシェイクの処理方法の側面を再実装する必要があります。下位互換性が失われる場合があります。ただし、最終的には、ECCをサポートする新しいバージョンのTLSを使用する必要があります。今すぐプッシュを作って、将来の攻撃を防いでみませんか？

2
Paul West Jauregui