การสลับใบรับรอง HTTPS ทำงานอย่างไร (เช่นบน suche.org)

สำหรับผู้ที่ไม่ทราบว่า Suche.org คืออะไรเป็นเว็บไซต์ที่มีคะแนน A + ที่สมบูรณ์แบบสำหรับ SSL Labs ในทุกหมวดหมู่: ( ผลลัพธ์ Suche.org SSL Labs ) ฉันตระหนักถึงเว็บไซต์นี้เมื่อฉันเปิดตั๋วอีกใบเกี่ยวกับใบรับรอง ECC ที่ไม่ทำงานใน Chromeและหนึ่งในผู้ตอบกลับใช้เว็บไซต์เป็นตัวอย่าง

สิ่งที่ทำให้ฉันสับสนคือแม้ว่า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การให้บริการลูกค้าที่แตกต่างกัน certs ขึ้นอยู่กับความสามารถ ฉันทำสำเนา / วางแบบเต็มเพื่อป้องกันไม่ให้ลิงค์เน่าและเพราะฉันคิดว่าคำถามนี้อาจเป็นที่สนใจในอนาคต:

ใบรับรอง SHA-1 กำลังจะหมดและคุณควรอัปเกรดเป็นใบรับรอง SHA-256 โดยเร็วที่สุด ... เว้นแต่คุณจะมีไคลเอนต์เก่ามากและต้องรักษาความเข้ากันได้ของ SHA-1 ชั่วครู่หนึ่ง

หากคุณอยู่ในสถานการณ์นี้คุณต้องบังคับให้ลูกค้าของคุณอัปเกรด (ยาก) หรือใช้ตรรกะการเลือกใบรับรองบางรูปแบบ: เราเรียกว่า "ใบรับรองการสลับ"

วิธีการเลือกที่กำหนดได้มากที่สุดคือการให้บริการใบรับรอง SHA-256 แก่ลูกค้าที่แสดง TLS1.2 HELLO ลูกค้าที่ประกาศอย่างชัดเจนถึงการสนับสนุน SHA256-RSA (0x0401) ในส่วนขยาย Signature_algorithms

เว็บเบราว์เซอร์สมัยใหม่จะส่งส่วนขยายนี้ อย่างไรก็ตามฉันไม่ทราบถึง open balancer load ใด ๆ ที่สามารถตรวจสอบเนื้อหาของ extension_algorithms อาจมาในอนาคต แต่ในตอนนี้วิธีที่ง่ายที่สุดในการบรรลุการสลับใบรับรองคือการใช้ HAProxy SNI ACLs: หากลูกค้าแสดงส่วนขยาย 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" ซึ่งเปลี่ยนเส้นทางไปยังส่วนหน้าชื่อ "jve_https" ซึ่งมีการกำหนดค่าใบรับรอง SHA256 และให้บริการกับลูกค้า

หากลูกค้าล้มเหลวในการแสดงไคลเอนต์ HELLO กับ SNI หรือแสดง SNI ที่ไม่ตรงกับไซต์เป้าหมายของเราไคลเอ็นต์จะถูกเปลี่ยนเส้นทางไปยังแบ็กเอนด์ "https_jve_sha1" จากนั้นไปยังส่วนหน้าที่สอดคล้องกันซึ่งมีการให้บริการใบรับรอง SHA1 ส่วนหน้านั้นยังสนับสนุน ciphersuite ที่เก่ากว่าเพื่อรองรับลูกค้าเก่า

ทั้งสองส่วนหน้าเปลี่ยนเส้นทางไปยังส่วนหลังเดียวที่ชื่อ "jve" ซึ่งจะส่งทราฟฟิกไปยังเว็บเซิร์ฟเวอร์ปลายทาง

นี่คือการกำหนดค่าที่ง่ายมากและในที่สุดมันก็สามารถปรับปรุงได้โดยใช้ ACL ที่ดีกว่า (HAproxy เพิ่มข่าวประจำ) แต่สำหรับการกำหนดค่าการเปลี่ยนใบรับรองขั้นพื้นฐานมันทำให้งานเสร็จสมบูรณ์!

คำถามที่คล้ายกันถูกถามที่https://community.qualys.com/thread/16387

ฉันคิดว่าคำตอบนี้เป็นทางออก:

suche.org เป็นการใช้งานที่ฉลาด เท่าที่ฉันเข้าใจมันจะทำการสอบถามความสามารถของลูกค้าและนำเสนอสิ่งที่ดีที่สุดเท่าที่จะทำได้เพื่อขจัดข้อสงสัยใด ๆ