Comment fonctionne le changement de certificat HTTPS (comme sur suche.org)?

Pour ceux qui ne savent pas ce que Suche.org est, c'est un site Web qui a une cote A + parfaite sur SSL Labs dans chaque catégorie: (résultat Suche.org SSL Labs ). J'ai pris connaissance de ce site Web lorsque j'ai ouvert un autre ticket concernant les certificats ECC ne fonctionnant pas dans Chrome , et l'un des répondants a utilisé le site comme exemple.

Ce qui m'embrouille, c'est que bien que la Protocol Supportsection du rapport indique que le site Web utilise uniquement TLSv1.2 ...

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

Ce n'est clairement pas le cas car sous la Handshake Simulationsection, il indique que certains des anciens clients simulés utilisent TLSv1.0 pour se connecter ...

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

C'est un peu frustrant car si je désactive TLSv1.0 sur mon site de test comme ça ...

# Apache example
SSLProtocol all -SSLv3 -SSLv2 -TLSv1

L'exécution de l'analyse SSL Labs sur mon site Web de test donne les résultats suivants pour certains des anciens clients:

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

Comment est-il possible d'autoriser simultanément uniquement les connexions TLSv1.2, tout en prenant également en charge les clients plus anciens?

Je suis sûr qu'ils vérifient les capacités du client et agissent en conséquence, comme expliqué dans le fil lié à dans la réponse de @Jeff .

Pour avoir une idée à quoi cela pourrait ressembler en détail, jetez un œil à ceci . Il montre une implémentation réalisée avec HAProxypour servir différents clients différents certificats, en fonction de leurs capacités. J'ai fait un copier / coller complet, pour éviter la pourriture des liens, et parce que je pense que cette question pourrait être intéressante à l'avenir:

Les certificats SHA-1 sont sur le point de disparaître, et vous devriez passer à un certificat SHA-256 dès que possible ... sauf si vous avez de très anciens clients et devez maintenir la compatibilité SHA-1 pendant un certain temps.

Si vous êtes dans cette situation, vous devez soit forcer vos clients à effectuer une mise à niveau (difficile), soit implémenter une certaine forme de logique de sélection de certificats: nous appelons cela "commutation de certificats".

La méthode de sélection la plus déterministe consiste à servir des certificats SHA-256 aux clients qui présentent un HELLO CLIENT TLS1.2 qui annonce explicitement leur prise en charge de SHA256-RSA (0x0401) dans l'extension signature_algorithms.

Les navigateurs Web modernes enverront cette extension. Cependant, je ne connais aucun équilibreur de charge open source capable actuellement d'inspecter le contenu de l'extension signature_algorithms. Cela peut arriver dans le futur, mais pour l'instant le moyen le plus simple de réaliser la commutation de certificats est d'utiliser les ACL HAProxy SNI: si un client présente l'extension SNI, dirigez-la vers un backend qui présente un certificat SHA-256. S'il ne présente pas l'extension, supposez qu'il s'agit d'un ancien client qui parle SSLv3 ou une version cassée de TLS, et présentez-lui un certificat SHA-1.

Ceci peut être réalisé dans HAProxy en chaînant le frontend et les backends:

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

La configuration ci-dessus reçoit le trafic entrant dans le frontend appelé "https-in". Cette interface est en mode TCP et inspecte le CLIENT HELLO provenant du client pour la valeur de l'extension SNI. Si cette valeur existe et correspond à notre site cible, elle envoie la connexion au backend nommé "jve_https", qui redirige vers un frontend également nommé "jve_https" où le certificat SHA256 est configuré et servi au client.

Si le client ne parvient pas à présenter un CLIENT BONJOUR avec SNI, ou présente un SNI qui ne correspond pas à notre site cible, il est redirigé vers le backend "https_jve_sha1", puis vers son frontend correspondant où un certificat SHA1 est servi. Cette interface prend également en charge une ancienne suite de chiffrement pour accueillir les clients plus âgés.

Les deux frontends finissent par rediriger vers un seul backend nommé "jve" qui envoie du trafic vers les serveurs Web de destination.

Il s'agit d'une configuration très simple, et éventuellement elle pourrait être améliorée en utilisant de meilleures ACL (HAproxy en ajoute régulièrement des nouvelles), mais pour une configuration de base de commutation de certificats, elle fait le travail!

Une question similaire a été posée sur https://community.qualys.com/thread/16387

Je pense que cette réponse est la solution:

suche.org est une implémentation intelligente. Pour autant que je sache, il interroge les capacités du client et n'offre ensuite que le meilleur disponible, pour dissiper tout doute.