HTTPS証明書の切り替えはどのように機能しますか（suche.orgなど）？

20

Suche.orgが何であるかを知らない人にとっては、すべてのカテゴリのSSL Labsに対して完璧なA +評価を持っているWebサイトです：（Suche.org SSL Labsの結果）。Chromeで動作しないECC証明書に関する別のチケットを開くと、このWebサイトに気づき、レスポンダーの1人がそのサイトを例として使用しました。

私を混乱させているのはProtocol Support、レポートのセクションでは、WebサイトはTLSv1.2 のみを使用していると書かれていますが...

TLS 1.2 Yes
TLS 1.1 No
TLS 1.0 No
SSL 3   No
SSL 2   No

Handshake Simulationセクションの下には、シミュレートされた古いクライアントの一部が接続にTLSv1.0を使用していることが表示されるため、明らかにそうではありません。

Android 4.0.4   EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.1.1   EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.2.2   EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.3     EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.4.2   EC 384 (SHA256)     TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   ECDH secp521r1  FS

私のテストWebサイトでTLSv1.0を無効にすると...

# Apache example
SSLProtocol all -SSLv3 -SSLv2 -TLSv1

テストWebサイトでSSL Labsスキャンを実行すると、一部の古いクライアントで次の結果が得られます。

Android 4.0.4   Server closed connection
Android 4.1.1   Server closed connection
Android 4.2.2   Server closed connection
Android 4.3     Server closed connection
Android 4.4.2   EC 384 (SHA256)     TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS

TLSv1.2接続のみを同時に許可しながら、古いクライアントもサポートする方法はありますか？

ssl  haproxy 
— スコットクルックス
ソース
「HTTPS証明書切り替えロジック」など、タイトルをより一般的にする必要がありますか？
— gf_
1
@gf_いいね。できた
— スコットクルークス

回答:

17

@Jeffの回答でリンクされているスレッドで説明されているように、彼らはクライアントの能力をチェックし、それに応じて行動していると確信しています。。

これは詳細にように見える可能性がどのようにアイデアを得るために、見ていこれでは。HAProxy能力に応じて、さまざまなクライアントにさまざまな証明書を提供するために作成された実装を示しています。リンクの腐敗を防ぐために、私は完全なコピー/貼り付けを行いました。なぜなら、この質問は将来的に興味深いものになると思うからです。

SHA-1証明書は間もなくリリースされます。非常に古いクライアントがあり、しばらくの間SHA-1互換性を維持する必要がある場合を除き、できるだけ早くSHA-256証明書にアップグレードする必要があります。

このような状況にある場合、クライアントに強制的にアップグレード（困難）するか、何らかの形式の証明書選択ロジックを実装する必要があります。これを「証明書の切り替え」と呼びます。

最も決定的な選択方法は、signature_algorithms拡張でSHA256-RSA（0x0401）のサポートを明示的にアナウンスするTLS1.2 CLIENT HELLOを提示するクライアントにSHA-256証明書を提供することです。

署名アルゴリズム拡張

最新のWebブラウザーはこの拡張機能を送信します。ただし、signature_algorithms拡張機能のコンテンツを現在検査できるオープンソースのロードバランサーは知りません。将来的には来るかもしれませんが、現在のところ、証明書の切り替えを実現する最も簡単な方法は、HAProxy SNI ACLを使用することです：クライアントがSNI拡張を提示する場合、SHA-256証明書を提示するバックエンドにそれを向けます。拡張機能が表示されない場合、SSLv3または壊れたバージョンのTLSを話す古いクライアントであると想定し、SHA-1証明書を提示します。

これは、フロントエンドとバックエンドを連鎖させることでHAProxyで実現できます。

HAProxy証明書の切り替え

global
        ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128
-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-R
SA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

frontend https-in
        bind 0.0.0.0:443
        mode tcp
        tcp-request inspect-delay 5s
        tcp-request content accept if { req_ssl_hello_type 1 }
        use_backend jve_https if { req.ssl_sni -i jve.linuxwall.info }

        # fallback to backward compatible sha1
        default_backend jve_https_sha1

backend jve_https
        mode tcp
        server jve_https 127.0.0.1:1665
frontend jve_https
        bind 127.0.0.1:1665 ssl no-sslv3 no-tlsv10 crt /etc/haproxy/certs/jve_sha256.pem tfo
        mode http
        option forwardfor
        use_backend jve

backend jve_https_sha1
        mode tcp
        server jve_https 127.0.0.1:1667
frontend jve_https_sha1
        bind 127.0.0.1:1667 ssl crt /etc/haproxy/certs/jve_sha1.pem tfo ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
        mode http
        option forwardfor
        use_backend jve

backend jve
        rspadd Strict-Transport-Security:\ max-age=15768000
        server jve 172.16.0.6:80 maxconn 128

上記の設定は、「https-in」と呼ばれるフロントエンドで受信トラフィックを受信します。そのフロントエンドはTCPモードであり、SNI拡張の値についてクライアントから送られてくるCLIENT HELLOを検査します。その値が存在し、ターゲットサイトと一致する場合、「jve_https」という名前のバックエンドに接続を送信し、SHA256証明書が構成されてクライアントに提供される「jve_https」という名前のフロントエンドにリダイレクトします。

クライアントがSNIでクライアントハローの提示に失敗した場合、またはターゲットサイトと一致しないSNIを提示した場合、クライアントは「https_jve_sha1」バックエンドにリダイレクトされ、SHA1証明書が提供される対応するフロントエンドにリダイレクトされます。そのフロントエンドは、古いクライアントに対応するために古い暗号スイートもサポートしています。

両方のフロントエンドは最終的に、宛先Webサーバーにトラフィックを送信する「jve」という名前の単一のバックエンドにリダイレクトします。

これは非常に単純な構成であり、最終的にはより良いACLを使用して改善できます（HAproxyは定期的にニュースを追加します）が、基本的な証明書切り替え構成の場合、仕事は完了です！

— gf_
ソース
9

同様の質問がhttps://community.qualys.com/thread/16387で尋ねられました

私はこの答えが解決策だと思います：

suche.orgは賢い実装です。私の知る限り、クライアントの能力を照会し、疑いを取り除くために利用可能な最善のもののみを提供します。

— ジェフ
ソース
2
ただし、「クライアントの機能を照会する」というのは、正確な説明ではありません。他の誰かが独自の実装を行うのに十分な情報はほとんどありません。
— ワンブル
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.