web-dev-qa-db-ja.com

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

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

私を混乱させるのは、レポートのProtocol SupportセクションにウェブサイトonlyTLSv1.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接続のみを同時に許可しながら、古いクライアントもサポートする方法はありますか？

sslhaproxy
20
Scott Crooks

@ Jeffの回答で にリンクされたスレッドで説明されているように、クライアントの機能をチェックし、それに応じて動作していることは間違いありません。

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

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

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

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

signature algorithm extensions

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

これはHAProxyでフロントエンドとバックエンドをチェーンすることで実現できます。

HAProxy cert switching

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=モードであり、クライアントからのCLIENT HELLOを検査してSNI拡張の値を調べます。その値が存在し、ターゲットサイトと一致する場合、名前付きのバックエンドに接続を送信します「jve_https」。これは、「jve_https」という名前のフロントエンドにリダイレクトされ、SHA256証明書が構成され、クライアントに提供されます。

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

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

これは非常にシンプルな構成であり、最終的にはより良いACLを使用して改善できる可能性があります（HAproxyは定期的にニュースを追加します）。

17
gf_

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

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

suche.orgは賢い実装です。私が理解している限り、それはクライアントの機能を照会し、疑いを取り除くために利用可能な最高のものだけを提供します。

9
Jeff