Como funciona a comutação de certificados HTTPS (como em suche.org)?

Question

Para aqueles que não sabem o que é Suche.org, é um site que tem uma classificação A + perfeita em SSL Labs em todas as categorias: ( Resultado do Suche.org SSL Labs . Tomei conhecimento deste site quando abri outro ticket sobre Certificados ECC não funcionam no Chrome e um dos respondentes usou o site como exemplo.

O que me confunde é que, embora a seção Protocol Support do relatório diga que o site somente usa o TLSv1.2 ...

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

Isso claramente não é o caso, pois sob a seção Handshake Simulation , ele mostra que alguns dos clientes mais antigos simulados estão usando o TLSv1.0 para se conectar ...

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

Isso é um pouco frustrante, porque se eu desabilitar o TLSv1.0 no meu site de teste, assim ...

# Apache example
SSLProtocol all -SSLv3 -SSLv2 -TLSv1

A execução da verificação do SSL Labs no meu site de teste gera o seguinte para alguns dos clientes mais antigos:

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

Como é possível permitir simultaneamente apenas conexões TLSv1.2, mas também suportar clientes mais antigos?

    

Answer 1

Tenho certeza de que eles estão verificando os recursos do cliente e agem de acordo, conforme explicado no tópico vinculado a na resposta de @Jeff .

Para ter uma ideia de como isso pode parecer em detalhes, dê uma olhada neste . Ele mostra uma implementação feita com HAProxy para atender diferentes clientes em diferentes certs, dependendo de suas capacidades. Eu fiz uma cópia / colagem completa, para evitar a perda de links, e porque acho que essa pergunta poderia ser de interesse no futuro:

SHA-1 certificates are on their way out, and you should upgrade to a SHA-256 certificate as soon as possible... unless you have very old clients and must maintain SHA-1 compatibility for a while.

If you are in this situation, you need to either force your clients to upgrade (difficult) or implement some form of certificate selection logic: we call that "cert switching".

The most deterministic selection method is to serve SHA-256 certificates to clients that present a TLS1.2 CLIENT HELLO that explicitly announces their support for SHA256-RSA (0x0401) in the signature_algorithms extension.

Modernwebbrowserswillsendthisextension.However,Iamnotawareofanyopensourceloadbalancerthatiscurrentlyabletoinspectthecontentofthesignature_algorithmsextension.Itmaycomeinthefuture,butfornowtheeasiestwaytoachievecertswitchingistouseHAProxySNIACLs:ifaclientpresentstheSNIextension,directittoabackendthatpresentsaSHA-256certificate.Ifitdoesn'tpresenttheextension,assumethatit'sanoldclientthatspeaksSSLv3orsomebrokenversionofTLS,andpresentitaSHA-1cert.

ThiscanbeachievedinHAProxybychainingfrontendandbackends:

globalssl-default-bind-ciphersECDHE-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:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSKfrontendhttps-inbind0.0.0.0:443modetcptcp-requestinspect-delay5stcp-requestcontentacceptif{req_ssl_hello_type1}use_backendjve_httpsif{req.ssl_sni-ijve.linuxwall.info}#fallbacktobackwardcompatiblesha1default_backendjve_https_sha1backendjve_httpsmodetcpserverjve_https127.0.0.1:1665frontendjve_httpsbind127.0.0.1:1665sslno-sslv3no-tlsv10crt/etc/haproxy/certs/jve_sha256.pemtfomodehttpoptionforwardforuse_backendjvebackendjve_https_sha1modetcpserverjve_https127.0.0.1:1667frontendjve_https_sha1bind127.0.0.1:1667sslcrt/etc/haproxy/certs/jve_sha1.pemtfociphersECDHE-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-SHAmodehttpoptionforwardforuse_backendjvebackendjverspaddStrict-Transport-Security:\max-age=15768000serverjve172.16.0.6:80maxconn128

Theconfigurationabovereceivesinboundtrafficinthefrontendcalled"https-in". That frontend is in TCP mode and inspects the CLIENT HELLO coming from the client for the value of the SNI extension. If that value exists and matches our target site, it sends the connection to the backend named "jve_https", which redirects to a frontend also named "jve_https" where the SHA256 certificate is configured and served to the client.

If the client fails to present a CLIENT HELLO with SNI, or presents a SNI that doesn't match our target site, it is redirected to the "https_jve_sha1" backend, then to its corresponding frontend where a SHA1 certificate is served. That frontend also supports an older ciphersuite to accommodate older clients.

Both frontends eventually redirect to a single backend named "jve" which sends traffic to the destination web servers.

This is a very simple configuration, and eventually it could be improved using better ACLs (HAproxy regularly adds news ones), but for a basic cert switching configuration, it gets the job done!

    

Answer 2

Uma pergunta semelhante foi feita no link

Acho que esta resposta é a solução:

suche.org is a clever implementation. As far as I understand, it queries the client's capabilities and then only offers the best available, to take away any doubt.