मुझे पूरा यकीन है कि वे ग्राहक क्षमताओं की जाँच कर रहे हैं और तदनुसार कार्य कर रहे हैं, जैसा कि @Jeff के उत्तर में जुड़े धागे में बताया गया है ।
एक विचार प्राप्त करने के लिए कि यह विस्तार से कैसे दिख सकता है, इस पर एक नज़र डालें । यह HAProxyअलग-अलग ग्राहकों को उनकी क्षमताओं के आधार पर अलग-अलग समारोहों की सेवा के लिए किए गए कार्यान्वयन को दिखाता है। मैंने लिंक रोट को रोकने के लिए एक पूर्ण प्रतिलिपि / पेस्ट किया है, और क्योंकि मुझे लगता है कि यह प्रश्न भविष्य में रुचि का हो सकता है:
SHA-1 प्रमाणपत्र अपने रास्ते से बाहर हैं, और आपको जल्द से जल्द SHA-256 प्रमाणपत्र को अपग्रेड करना चाहिए ... जब तक कि आपके पास बहुत पुराने ग्राहक नहीं हैं और थोड़ी देर के लिए SHA-1 संगतता बनाए रखना चाहिए।
यदि आप इस स्थिति में हैं, तो आपको अपने ग्राहकों को प्रमाणपत्र चयन तर्क के कुछ प्रकार को अपग्रेड (मुश्किल) करने या लागू करने के लिए बाध्य करने की आवश्यकता है: हम कहते हैं कि "सर्टिफिकेट स्विचिंग"।
सबसे नियतात्मक चयन विधि ग्राहकों को SHA-256 प्रमाणपत्र प्रदान करना है जो TLS1.2 CLIENT HELLO को प्रस्तुत करता है जो हस्ताक्षर_ एल्गोरिथम एक्सटेंशन में SHA256-RSA (0x0401) के लिए स्पष्ट रूप से अपने समर्थन की घोषणा करता है।
आधुनिक वेब ब्राउज़र इस एक्सटेंशन को भेजेंगे। हालाँकि, मुझे किसी भी ओपन सोर्स लोड बैलेंसर के बारे में जानकारी नहीं है जो वर्तमान में सिग्नेचर_अलगोरिथम एक्सटेंशन की सामग्री का निरीक्षण करने में सक्षम है। यह भविष्य में आ सकता है, लेकिन अब प्रमाणित स्विचिंग प्राप्त करने का सबसे आसान तरीका है HAProxy SNI ACLs का उपयोग करना: यदि कोई ग्राहक SNI एक्सटेंशन प्रस्तुत करता है, तो उसे एक बैकएंड पर निर्देशित करें जो SHA-256 प्रमाणपत्र प्रस्तुत करता है। यदि यह एक्सटेंशन प्रस्तुत नहीं करता है, तो मान लें कि यह एक पुराना क्लाइंट है जो एसएसएलवी 3 या टीएलएस के कुछ टूटे हुए संस्करण को बोलता है, और इसे 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 मोड में है और SNI एक्सटेंशन के मान के लिए क्लाइंट से आने वाले CLIENT HELLO का निरीक्षण करता है। यदि वह मान मौजूद है और हमारी लक्षित साइट से मेल खाता है, तो यह "jve_https" नाम के बैकएंड से कनेक्शन भेजता है, जो "jve_https" नाम के एक फ्रंटेंड पर पुनर्निर्देशित करता है जहां SHA256 प्रमाणपत्र क्लाइंट को कॉन्फ़िगर और सेवा किया जाता है।
यदि ग्राहक SNI के साथ CLIENT HELLO प्रस्तुत करने में विफल रहता है, या एक SNI प्रस्तुत करता है जो हमारी लक्षित साइट से मेल नहीं खाता है, तो इसे "https_jve_sha1" बैकएंड पर रीडायरेक्ट किया जाता है, फिर इसके संबंधित फ्रंट में जहां SHA1 प्रमाणपत्र दिया जाता है। यह दृश्यपटल पुराने ग्राहकों को समायोजित करने के लिए एक पुराने सिफरसुइट का भी समर्थन करता है।
दोनों फ्रंट अंततः "jve" नामक एकल बैकएंड पर पुनर्निर्देशित करते हैं जो गंतव्य वेब सर्वर को ट्रैफ़िक भेजता है।
यह एक बहुत ही सरल कॉन्फ़िगरेशन है, और अंततः बेहतर ACL (HAproxy नियमित रूप से समाचार जोड़ता है) का उपयोग करके इसे बेहतर बनाया जा सकता है, लेकिन एक बुनियादी प्रमाणित स्विचिंग कॉन्फ़िगरेशन के लिए, यह काम पूरा कर लेता है!