HTTPS 인증서 전환은 어떻게 작동합니까 (suche.org 에서처럼)?

(: Suche.org이 무엇인지 모르는 사람들을 위해, 그것은 모든 카테고리의 SSL 연구소에 완벽 A + 등급이있는 웹 사이트입니다 Suche.org SSL 연구소가 결과 ). Chrome 에서 작동하지 않는 ECC 인증서 에 대한 다른 티켓을 열었을 때이 웹 사이트를 알게되었고 응답자 중 한 명이 사이트를 예로 사용했습니다.

나를 혼란스럽게 Protocol Support하는 것은 보고서 의 섹션에 웹 사이트 가 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

테스트 웹 사이트에서 TLSv1.0을 비활성화하면 너무 실망 스럽습니다 ...

# Apache example
SSLProtocol all -SSLv3 -SSLv2 -TLSv1

테스트 웹 사이트에서 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 연결 만 동시에 허용하면서 이전 클라이언트도 지원하는 방법은 무엇입니까?

@Jeff의 답변에 링크 된 스레드에 설명 된 것처럼 클라이언트 기능을 확인하고 그에 따라 행동한다고 ​​확신합니다 .

이 자세히과 같이 수 있는지 아이디어를 얻으려면 모습이 이것을 . HAProxy기능에 따라 서로 다른 클라이언트에게 서로 다른 인증서를 제공하기 위해 만들어진 구현을 보여줍니다 . 링크 썩음을 방지하기 위해 전체 복사 / 붙여 넣기를 수행 했으며이 질문이 미래에 관심이있을 수 있다고 생각합니다.

SHA-1 인증서가 곧 나옵니다. 아주 오래된 클라이언트가없고 잠시 동안 SHA-1 호환성을 유지해야하는 경우가 아니면 가능한 한 빨리 SHA-256 인증서로 업그레이드해야합니다.

이러한 상황에 처한 경우 고객이 클라이언트를 강제로 업그레이드 (어려워)하거나 일종의 인증서 선택 논리를 구현해야합니다.이를 "인증서 전환"이라고합니다.

가장 결정적인 선택 방법은 signature_algorithms 확장에서 SHA256-RSA (0x0401)에 대한 지원을 명시 적으로 알리는 TLS1.2 CLIENT HELLO를 제공하는 클라이언트에 SHA-256 인증서를 제공하는 것입니다.

최신 웹 브라우저는이 확장을 보냅니다. 그러나 현재 signature_algorithms 확장의 내용을 검사 할 수있는 오픈 소스로드 밸런서를 알지 못합니다. 향후에는 인증서 전환을 달성하는 가장 쉬운 방법은 HAProxy SNI ACL을 사용하는 것입니다. 클라이언트가 SNI 확장을 제공하는 경우 SHA-256 인증서를 제공하는 백엔드로 지정하십시오. 확장이 없으면 SSLv3 또는 TLS의 손상된 버전을 사용하는 이전 클라이언트라고 가정하고 SHA-1 인증서를 제공하십시오.

이는 프론트 엔드와 백엔드를 연결하여 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 모드에 있으며 클라이언트에서 오는 CLIENT HELLO에서 SNI 확장의 값을 검사합니다. 해당 값이 존재하고 대상 사이트와 일치하면 "jve_https"라는 백엔드로 연결을 전송합니다.이 연결은 SHA256 인증서가 구성되어 클라이언트에 제공되는 "jve_https"라는 프런트 엔드로 리디렉션됩니다.

클라이언트가 SNI를 사용하여 CLIENT HELLO를 제시하지 않거나 대상 사이트와 일치하지 않는 SNI를 제시하면 "https_jve_sha1"백엔드로 경로 재 지정된 후 SHA1 인증서가 제공되는 해당 프론트 엔드로 경로 재 지정됩니다. 이 프론트 엔드는 또한 이전 클라이언트를 수용하기 위해 이전 암호 스위트를 지원합니다.

두 프런트 엔드는 결국 "jve"라는 단일 백엔드로 리디렉션되어 트래픽을 대상 웹 서버로 보냅니다.

이것은 매우 간단한 구성이며 결국 더 나은 ACL (HAproxy가 정기적으로 뉴스를 추가 함)을 사용하여 개선 할 수 있지만 기본 인증서 전환 구성의 경우 작업이 완료됩니다!

https://community.qualys.com/thread/16387 에서 비슷한 질문이 제기되었습니다.

이 답변이 해결책 이라고 생각 합니다 .

suche.org는 영리한 구현입니다. 내가 이해하는 한, 고객의 기능을 쿼리 한 다음 의심의 여지를 없애기 위해 최상의 기능 만 제공합니다.