SHA256署名のサポートは、TLS暗号スイートまたはClientHelloの他の部分（signature_algorithmが送信されない場合）から推定できますか？
（レガシー）ブラウザーとの最大の互換性を維持することを目的とするWebサイトは、SHA2署名付き証明書チェーンを、それらをサポートするユーザーエージェントに提供し、SHA1をサポートしないユーザーエージェントに提供することを望む場合があります。
TLS 1.2仕様（ https://www.ietf.org/rfc/rfc5246.txt ）は、新しいsignature_algorithm拡張を定義します。ブラウザは、SHA2のサポートを検出するために使用できます。たとえば、ブラウザに「SHA256/RSA」が含まれている場合、この特定のハッシュ/署名アルゴリズムのペアをサポートしていることをサーバーに伝えています。サーバーは互換性のあるチェーンを選択してそれを返すか、「SHA/RSA」のようなものにフォールバックできます。
ただし、この拡張機能に依存することには2つの主要な問題があります。
- RFC 5246は、それがオプションであることを指定しています（セクション7.4.1.4.1を参照）
クライアントがデフォルトのハッシュおよび署名アルゴリズム（このセクションにリストされている）のみをサポートしている場合、signature_algorithms拡張を省略できます（MAY）。クライアントがデフォルトのアルゴリズムをサポートしていない場合、または他のハッシュアルゴリズムと署名アルゴリズムをサポートしている場合（そして、サーバーから送信されたメッセージを確認するためにそれらを使用する意思がある場合（つまり、サーバー証明書とサーバーキー交換））、クライアントは、signature_algorithms拡張を送信する必要があります。受け入れることをいとわないアルゴリズムのリスト。
- 一部のブラウザ（Android 2.3-4.3）はSHA2をサポートしていますが、TLS 1.2はサポートしていません（ 機能マトリックス を参照）
- サーバー側のロジックが拡張機能を必要とする場合、SHA2を処理できるクライアントにSHA1証明書を「オーバーサーブ」する可能性があります。
上記の2つの欠点を踏まえて、SHA2サポートの検出に使用できるTLSハンドシェイクClientHelloメッセージの他の部分はありますか？
当初の考えでは、SHA256が暗号スイート（たとえば、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256の最後にあるSHA256）のPRF/MACフィールドに表示されるかどうかを確認することでしたが、これらもTLS 1.2以降でのみ存在するようです。
サポートされている署名アルゴリズムを確認できる唯一の信頼できる場所は、すでに検出されています。
- signature_algorithms拡張
- クライアントが提供するTLSバージョン。クライアントが少なくともこのTLSバージョンの最小要件を（うまくいけば）実装していることを示しています。
他のすべてが推測しています。提供された暗号と暗号の順序に基づいてクライアントをフィンガープリントしようとする場合があります（ SSLLabsクライアントテスト を参照）。 SNIなどの他の拡張機能の使用をフィンガープリントに追加する場合があります。そして、指紋をサポートされている署名にマッピングできます。
しかし、私はそのような信頼できないハッキングに対してはお勧めします。 Facebookのような多くの大きなサイトはすでにSHA-256に移行しており、これらはこれらの署名アルゴリズムをサポートしていないすべてのクライアントを破壊します。これにより、SHA-256をサポートするようにクライアントに大きな圧力がかかるはずです。