SSL का पुनर्निर्देशन केवल तभी करें जब ब्राउज़र SNI का समर्थन करता है

Question

मेरे पास mod_ssl के साथ Apache 2.2 और VirtualHosting के साथ समान IP / पोर्ट पर HTTPS में साइटों का एक समूह है, इसलिए क्लाइंट को उन वर्चुअल होस्ट से कनेक्ट करने के लिए SNI का समर्थन करना चाहिए।

मैं अपने सर्वर को निम्न तरीके से कॉन्फ़िगर करना चाहूंगा:

जब कोई उपयोगकर्ता www.dummysite.com और उसका ब्राउजर एसएनआई (सर्वर नेम इंडिकेशन) का समर्थन करता है , तो https://एचटीएसएस हेडर को भेजा जाता है, जहां किसी भी HTTP अनुरोध को पुनर्निर्देशित किया जाता है। लेकिन अगर ब्राउज़र SNI का समर्थन नहीं करता है, तो अनुरोध HTTP द्वारा परोसा जाता है।

उपरोक्त नियम, जैसा कि कहा गया है, वास्तव में उन लोगों के लिए एक पतन नियम है जो अभी भी पुराने ब्राउज़र चलाते हैं, क्योंकि मोज़िला और क्रोम को यह समस्या नहीं है, बस इन उपयोगकर्ताओं को साइट से बाहर जाने से बचने के लिए।

मैं Apache config स्तर पर यह पुनर्निर्देशन करना चाहूंगा, शायद उपयोगकर्ता एजेंट पर एक फ़िल्टर के साथ। मैं यह सुनिश्चित करने के अलावा कि कोई प्रत्यक्ष http: // संदर्भ मौजूद नहीं है (अन्यथा वे एक सुरक्षा चेतावनी देते हैं) को छोड़कर चल रहे अनुप्रयोगों को छूना पसंद नहीं करेंगे

[संपादित करें] (प्रश्न संपादित करते समय मैं प्रश्न भूल गया ): SNI- सक्षम उपयोगकर्ता एजेंटों की सूची को पुनर्निर्देशित करने के लिए क्या है?

Answer 1

चूंकि एसएनआई एसएसएल / टीएलएस हैंडशेक के दौरान होता है, इसलिए क्लाइंट के HTTP से कनेक्ट होने पर ब्राउज़र समर्थन का पता लगाना संभव नहीं है।

तो, तुम सही हो; एक उपयोगकर्ता-एजेंट फ़िल्टर ऐसा करने का एकमात्र तरीका है।

बड़ा सवाल यह है कि क्या आप उन ब्राउजरों के खिलाफ एक ब्लैकलिस्ट पर कार्रवाई करना चाहते हैं जिन्हें आप जानते हैं कि वे SNI के लिए नहीं सुनेंगे, या उन ब्राउजरों के श्वेतसूची जो इसका समर्थन करने के लिए जाने जाते हैं। अस्पष्ट या नए उपकरण साइट का उपयोग करने में असमर्थ होने पर डील-ब्रेकर की तरह प्रतीत होता है, इसलिए मैं कहूंगा कि श्वेतसूची बेहतर विकल्प हो सकता है।

आपके HTTP में <VirtualHost>:

# Internet Explorer 7, 8, 9, on Vista or newer
RewriteCond %{HTTP_USER_AGENT} MSIE\s7.*Windows\sNT\s6 [OR]
RewriteCond %{HTTP_USER_AGENT} MSIE\s8.*Windows\sNT\s6 [OR]
RewriteCond %{HTTP_USER_AGENT} MSIE\s9.*Windows\sNT\s6 [OR]
# Chrome on Windows, Mac, Linux
RewriteCond %{HTTP_USER_AGENT} Windows\sNT\s6.*Chrome [OR]
RewriteCond %{HTTP_USER_AGENT} Macintosh.*Chrome [OR]
RewriteCond %{HTTP_USER_AGENT} Linux.*Chrome [OR]
# Firefox - we'll just make the assumption that all versions in the wild support:
RewriteCond %{HTTP_USER_AGENT} Gecko.*Firefox
RewriteRule ^/(.*)$ https://ssl.hostname/$1 [R=301]

यहां ब्लैकलिस्ट विकल्प भी दिया गया है - ध्यान रखें कि यह एक ग्राहक को भेजने का जोखिम चलाता है जो एसएनआई-एसएनआई की आवश्यकता वाली साइट पर एसएनआई का उपयोग नहीं करता है, लेकिन दूसरी ओर, आईई 10 जैसे कुछ नए उपयोगकर्ताओं को दाईं ओर भेज देगा स्थान:

# IE 6
RewriteCond %{HTTP_USER_AGENT} !MSIE\s6
# Windows XP/2003
RewriteCond %{HTTP_USER_AGENT} !Windows\sNT\s5
# etc etc
RewriteRule ^/(.*)$ https://ssl.hostname/$1 [R=301]

वहाँ बहुत सारे ब्राउज़र हैं। मैं अभिव्यक्ति के साथ बहुत ढीली हो गई हूं और बहुत सारे ब्राउज़रों को कवर नहीं किया है - यह बनाए रखने के लिए काफी दुःस्वप्न में बदल सकता है।

जो भी विकल्प आप चुनते हैं .. शुभकामनाएँ!

Comments

महान! मैंने ओपेरा मोबाइल के साथ परीक्षण किया (जो एसएनआई अनुरूप है लेकिन सूची में नहीं है) और यह पुनर्निर्देशित नहीं करता है। मेरे फ़ायरफ़ॉक्स के साथ, यह पुनर्निर्देशित करता है!

— usr-local-

मैं इस समाधान को mod_setenvif httpd.apache.org/docs/2.2/mod/mod_setenvif.html से BrowserMatch निर्देश के साथ संशोधित करने का सुझाव देता हूं । वातावरण चर support_sni = y सेट करने के लिए BrowserMatch का उपयोग करें, फिर RewriteCond% {ENV: support_sni} = y लिखें। इस तरह, आप किसी भी अन्य RewriteRules के लिए SNI का पता लगाने वाले तर्क का पुन: उपयोग कर सकते हैं जो आपके पास हो सकता है।

— २००

@ 200_success अच्छा विचार!

— शेन झुंझलाना

Answer 2

मेरा समाधान यह है:

  # Test if SNI will work and if not redirect to too old browser page
  RewriteCond %{HTTPS} on
  RewriteCond %{SSL:SSL_TLS_SNI} =""
  RewriteRule ^ http://www.example.com/too-old-browser [L,R=307]

यदि एसएनआई के बिना एक पुराना ब्राउज़र https://www.example.com/ * का उपयोग करने की कोशिश करता है, तो वह पहले ब्राउज़र पर एक त्रुटि फेंक देगा, जिसे तब तक टाला नहीं जा सकता जब तक कि अपाचे गैर-एसएनआई ब्राउज़र का जवाब नहीं देता। यह किस साइट के लिए पूछ रहा है। फिर यह उस पृष्ठ पर रीडायरेक्ट करता है, जिसमें उपयोगकर्ता अपने ब्राउज़र को बहुत पुराना बताता है (जब तक उपयोगकर्ता क्लिक वेबसाइट पर जारी रहता है)।

और मेरे पास नए ब्राउज़र वाले उपयोगकर्ताओं के लिए

  #Test if new browser and if so redirect to https
  #new browser is not MSIE 5-8, not Android 0-3
  RewriteCond %{HTTPS} off
  RewriteCond %{HTTP_USER_AGENT} !MSIE\ [5-8]
  RewriteCond %{HTTP_USER_AGENT} !Android.*(Mobile)?\ [0-3]
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

यह पुराने ब्राउज़रों में से अधिकांश को बाहर करता है, जिसमें कुछ विस्टा पर एमएसआई 5-8 (9+ केवल विस्टा / 7 इतना एसएनआई का समर्थन करता है) शामिल है। यह 100% नहीं है (सिम्बियन को नजरअंदाज किया जाता है आदि) लेकिन बहुमत के लिए काम करना चाहिए। अल्पसंख्यक अभी भी प्रमाणपत्र त्रुटि को स्वीकार कर सकते हैं।

Answer 3

जहां तक ​​मुझे पता है कि वास्तव में ऐसा करने का एक अच्छा तरीका नहीं है - आप हेडर के आधार पर mod_rewrite नियम या इसी तरह के सशर्त रूप से उपयोग कर सकते हैं User-agent, लेकिन यह एक NON-SSL vhost पर होना चाहिए: यदि ब्राउज़र नहीं करता है एसएनआई का समर्थन करें और यह एक सुरक्षित ( https://) साइट पर जाता है जो पुराने स्कूल-अपाचे व्यवहार को प्राप्त करने वाला है "यहां पहला एसएसएल प्रमाणपत्र है जो मैंने उस आईपी पते से जुड़ा है - आशा है कि यह वही है जो आप चाहते थे!" - यदि वह प्रमाणपत्र नहीं है जो ब्राउज़र को उम्मीद थी कि आप होस्टनाम मिसमैच के बारे में एक त्रुटि संदेश देंगे।

इसका मूल रूप से मतलब है कि लोगों को एक गैर-एसएसएल अंतरालीय पृष्ठ को हिट करना होगा जो उन्हें पुनर्निर्देशित करेगा - संभवतः उनके अनुरोध में भेजे गए किसी भी डेटा को उजागर करना। यह एक डील ब्रेकर हो सकता है या नहीं भी हो सकता है (आप कहते हैं कि आप उन्हें किसी गैर-एसएसएल साइट पर भेजने जा रहे हैं, अगर वे एसएनआई का समर्थन नहीं करते हैं, तो मैं मानता हूं कि आप सुरक्षा के बारे में इतना ध्यान नहीं रखते। अगर मैं होता। एक ऐसी प्रणाली को डिजाइन करना, जिसमें एक एन्क्रिप्शन या ऑथेंटिकेशन लेयर के रूप में एसएसएल की आवश्यकता थी, मैं इसके बारे में थोड़ा अधिक आग्रह करूंगा ...)

हालांकि इनमें से कोई भी सुरक्षित साइट को बुकमार्क करने से किसी को नहीं रोकता है - और यदि वे एक साझा बुकमार्क सेवा का उपयोग करते हैं या अपने बुकमार्क को एक मशीन पर पुनर्स्थापित करते हैं, जहां वेब ब्राउज़र एसएनआई का समर्थन नहीं करता है तो वे संभावित-फॉर-एसएसएल-एरर्स मामले में वापस आ जाते हैं ।

Answer 4

मैं इसे तीन तरीकों में से एक को हल करने के लिए लुभाऊंगा:

1. RewriteRuleUser-Agentहेडर के आधार पर ।
2. लोड करें एक https: // URI <SCRIPT>एक गैर-डिफ़ॉल्ट VHost पर एक टैग में; यदि लोड सफल होता है, तो यह JS का एक सा है जो HTTPS के तहत पूरे पृष्ठ को पुनः लोड करता है।
3. मेरे आगंतुकों को सिखाएं कि हर जगह HTTPS की तरह कुछ का उपयोग करें यदि यह उनके लिए प्राथमिकता है, तो HTTPS को उन पृष्ठों पर बाध्य करें जहां इसकी आवश्यकता होनी चाहिए, और आशा है कि अंत में सब कुछ काम करेगा।

इनमें से, मैं व्यक्तिगत रूप से # 2 को सबसे अधिक पसंद करता हूं, लेकिन इसमें आपकी साइटों के कोड को संशोधित करना शामिल है।

Answer 5

बस किसी को इसकी जरूरत है।

यदि आपके पास कई मेजबान हैं और चाहते हैं कि सभी वर्चुअलहोस्टिंग में SSL-सक्षम हों (और आपने प्रत्येक के लिए एक प्रमाण पत्र खरीदा है) नया प्रयास करें mod_djechelon_ssl

$ cat /etc/apache2/mod_djechelon_ssl.conf 
RewriteEngine on
# Internet Explorer 7, 8, 9, on Vista or newer
RewriteCond %{HTTP_USER_AGENT} MSIE\s7.*Windows\sNT\s6 [OR]
RewriteCond %{HTTP_USER_AGENT} MSIE\s8.*Windows\sNT\s6 [OR]
RewriteCond %{HTTP_USER_AGENT} MSIE\s9.*Windows\sNT\s6 [OR]
# Chrome on Windows, Mac, Linux
RewriteCond %{HTTP_USER_AGENT} Windows\sNT\s6.*Chrome [OR]
RewriteCond %{HTTP_USER_AGENT} Macintosh.*Chrome [OR]
RewriteCond %{HTTP_USER_AGENT} Linux.*Chrome [OR]
# Firefox - we'll just make the assumption that all versions in the wild support:
RewriteCond %{HTTP_USER_AGENT} Gecko.*Firefox [OR]
#Safari iThing
RewriteCond %{HTTP_USER_AGENT} Mozilla.*iPhone.*Safari [OR]
RewriteCond %{HTTP_USER_AGENT} Mozilla.*iPod.*Safari [OR]
RewriteCond %{HTTP_USER_AGENT} Mozilla.*iPad.*Safari [OR]
RewriteRule ^/(.*)$ https://%{HTTP_HOST}/$1 [R=permanent,L]

उपयोग:

<VirtualHost ip:80>
ServerName www.yourhost.com

Include /path/to/mod_djechelon_ssl.conf

[plain old Apache directives]
</VirtualHost>

<VirtualHost ip:443>
ServerName www.yourhost.com

[SSL-related directives]

[Copy and paste directives from above host]
</VirtualHost>

Answer 6

जैसा कि मैंने यहां पोस्ट किया है , आप इसे आवश्यक करने से पहले केवल एसएनआई समर्थन के लिए परीक्षण कर सकते हैं । यही है, यदि आप इसका समर्थन नहीं करते हैं, तो आप SNI HTTPS पर उपयोगकर्ताओं को बाध्य नहीं कर सकते हैं और फिर वापस नहीं कर सकते हैं, क्योंकि उन्हें इस तरह से एक त्रुटि प्राप्त होगी (क्रोम से विंडोज एक्सपी पर) आगे बढ़ने के लिए कोई रास्ता नहीं है।

इसलिए (दुर्भाग्य से) उपयोगकर्ता को वास्तव में असुरक्षित HTTP कनेक्शन पर शुरू करना पड़ता है और उसके बाद ही नवीनीकृत किया जाता है यदि वे SNI का समर्थन करते हैं।

आप एसएनआई समर्थन का पता लगा सकते हैं:

1. दूरस्थ स्क्रिप्ट
   आपके सादे HTTP पृष्ठ से, <script>अपने गंतव्य SNI HTTPS सर्वर से लोड होती है और यदि स्क्रिप्ट लोड होती है और सही ढंग से चलती है, तो आप जानते हैं कि ब्राउज़र SNI का समर्थन करता है।

2. क्रॉस-डोमेन AJAX (CorS)
   विकल्प 1 के समान, आप HTTP पृष्ठ से HTTPS में क्रॉस-डोमेन AJAX अनुरोध करने का प्रयास कर सकते हैं, लेकिन ध्यान रखें कि CORS में केवल सीमित ब्राउज़र समर्थन है ।

3. उपयोगकर्ता-एजेंट को सूँघें
   यह शायद सबसे कम विश्वसनीय तरीका है, और आपको ब्राउज़रों (और ऑपरेटिंग सिस्टम) की एक ब्लैकलिस्ट होने के बीच यह तय करने की आवश्यकता होगी कि इसे समर्थन नहीं करना है, या ज्ञात सिस्टम का एक श्वेतसूची।

   हम जानते हैं कि विंडोज़ एक्सपी और नीचे आईई, क्रोम और ओपेरा के सभी संस्करण एसएनआई का समर्थन नहीं करते हैं। समर्थित ब्राउज़रों की पूरी सूची के लिए CanIUse.com देखें ।