HTTPS sertifikası geçişi nasıl çalışır (suche.org'daki gibi)?

Suche.org'un ne olduğunu bilmeyenler için, her kategoride SSL Laboratuvarlarında mükemmel bir A + derecesi olan bir web sitesi: ( Suche.org SSL Labs sonucu ). Chrome'da çalışmayan ECC sertifikaları hakkında başka bir bilet açtığımda bu web sitesinin farkında oldum ve yanıt verenlerden biri siteyi örnek olarak kullandı.

Beni şaşırtan şey Protocol Support, raporun bölümünün web sitesinde sadece TLSv1.2 kullandığını söylemesine rağmen ...

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

Bu durum net değildir, çünkü bu Handshake Simulationbölüm altında , benzetilen eski istemcilerden bazılarının bağlanmak için TLSv1.0 kullandığını gösteriyor ...

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

Bu biraz sinir bozucu çünkü test sitemdeki TLSv1.0’ı devre dışı bırakırsam ...

# Apache example
SSLProtocol all -SSLv3 -SSLv2 -TLSv1

SSL Labs taramasını test web sitemde çalıştırmak, bazı eski istemciler için aşağıdakileri sağlıyor:

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

Eşzamanlı olarak sadece TLSv1.2 bağlantılarına izin vermek, eski müşterileri de desteklemek nasıl mümkün olabilir?

@Jeff'in cevabındaki konu başlığında açıklandığı gibi müşteri yeteneklerini kontrol ettiklerinden ve buna göre davrandıklarından eminim .

Bu ayrıntılı olarak aşağıdaki gibi görünebilir nasıl bir fikir edinmek için, bir göz şuna . HAProxyFarklı müşterilere yeteneklerine bağlı olarak farklı müşterilere hizmet etmek için yapılan bir uygulamayı gösterir . Bağlantı çürümesini önlemek için tam bir kopyala / yapıştır yaptım ve bu sorunun gelecekte ilgini çekebileceğini düşünüyorum:

SHA-1 sertifikaları çıkıyor ve en kısa zamanda bir SHA-256 sertifikasına geçmelisiniz ... çok eski istemcileriniz olmadıkça ve bir süredir SHA-1 uyumluluğunu sürdürmelisiniz.

Bu durumda, müşterilerinizi yükseltmeye (zor) ya da bir çeşit sertifika seçim mantığı uygulamaya zorlamanız gerekir: biz buna "sertifika değiştirme" diyoruz.

En deterministik seçim yöntemi, SHA256 sertifikalarını, signature_algorithms uzantısında SHA256-RSA (0x0401) için açıkça desteklerini açıklayan bir TLS1.2 CLIENT HELLO sunan müşterilere sunmaktır.

Modern web tarayıcıları bu uzantıyı gönderir. Bununla birlikte, şu anda signature_algorithms uzantısının içeriğini denetleyebilecek herhangi bir açık kaynaklı yük dengeleyicisinin farkında değilim. Gelecekte gelebilir, ancak şu an sertifika geçişi gerçekleştirmenin en kolay yolu HAProxy SNI ACL'leri kullanmaktır: eğer bir istemci SNI uzantısını sunuyorsa, bunu bir SHA-256 sertifikası sunan bir arka uca yönlendirin. Uzantıyı sunmuyorsa, SSLv3'ü veya TLS'nin bozuk bir sürümünü konuşan eski bir müşteri olduğunu ve bir SHA-1 sertifikası sunduğunu varsayalım.

Bu, HAProxy'de ön ve arka uçları zincirleyerek sağlanabilir:

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

Yukarıdaki yapılandırma, "https-in" adı verilen ön uçtan gelen trafiği alır. Bu ön uç TCP modundadır ve istemciden gelen İSTEMCİ HELLO'yu SNI uzantısının değerini kontrol eder. Bu değer varsa ve hedef sitemizle eşleşiyorsa, bağlantıyı "jve_https" adlı arka uca gönderir, bu da SHA256 sertifikasının yapılandırıldığı ve istemciye sunulduğu "jve_https" adlı bir uç uca yönlendirir.

Eğer müşteri SNI ile bir İSTEMCİ HELLO sunamıyorsa veya hedef sitemize uymayan bir SNI sunuyorsa, "https_jve_sha1" arka ucuna, daha sonra bir SHA1 sertifikasının sunulduğu ilgili ucuna yönlendirilir. Bu ön uç aynı zamanda daha eski müşterileri barındıracak eski şifreli bir suyu da destekliyor.

Her iki ön uç da sonunda, hedef web sunucularına trafik gönderen "jve" adlı tek bir arka uca yönlendirir.

Bu çok basit bir yapılandırmadır ve sonunda daha iyi ACL'ler kullanılarak geliştirilebilir (HAproxy düzenli olarak haber ekler), ancak temel bir sertifika değiştirme yapılandırması için işi halleder!

Benzer bir soru https://community.qualys.com/thread/16387 adresinde de sorulmuştur.

Bence bu cevap çözüm:

suche.org akıllıca bir uygulamadır. Anladığım kadarıyla, müşterinin yeteneklerini sorgular ve sonra herhangi bir şüpheyi ortadan kaldırmak için yalnızca elinden gelenin en iyisini sunar.