पूडल: क्या सर्वर पर SSL V3 को अक्षम करना वास्तव में एक समाधान है?


39

मैं पूरे दिन पूडल भेद्यता के बारे में पढ़ रहा हूं और यह अब मैं थोड़ा उलझन में हूं बनाम सुरक्षा और राजस्व।

अगर मैं SSL V3 को सर्वर पर निष्क्रिय कर देता हूं (SSL V2 और V3 दोनों अपाचे के लिए अक्षम हो जाएगा) क्लाइंट (ब्राउज़र) जो किसी भी प्रोटोकॉल का समर्थन नहीं करते हैं, लेकिन SSL V3 सर्वर के साथ HTTPS को कनेक्ट करने में सक्षम नहीं होगा।

इसलिए यह ऐसी स्थिति है जहां क्लाइंट और सर्वर दोनों को टीएलएस 1.1 1.2 और इतने पर संवाद करना चाहिए

यदि उनमें से कोई भी SSL V3 का उपयोग करता है और दूसरा निम्न संस्करणों का समर्थन नहीं करता है तो क्या होता है? एसएसएल से कोई संबंध नहीं।

मैंने फ़ायरफ़ॉक्स में किए गए कुछ अपडेट देखे हैं, शायद उन्होंने SSL V3 को इसमें अक्षम कर दिया है कि हमें आमतौर पर विकल्पों में क्या करना है। यह सभी कनेक्शनों को निचले संस्करणों और टीएलएस के लिए मजबूर करेगा

लेकिन SSL V3 को अक्षम करना वास्तव में इस समस्या का हल है?


4
"इसका मतलब यह है कि यह निचले संस्करणों और टीएलएस के लिए सभी कनेक्शन को मजबूर करेगा"? SSLv1 और SSLv2 को लंबे समय से अक्षम किया गया है क्योंकि वे टूट गए हैं। SSLv3 को खत्म कर दिया गया है, लेकिन कई मामलों में विरासत सॉफ्टवेयर का समर्थन करने में सक्षम रहे। आप किस निचले संस्करण का उल्लेख कर रहे हैं? TLSv1.0, v1.1, v1.2, ... बाद के मानक हैं और इन्हें "उच्च संस्करण SSL" माना जा सकता है, केवल संस्करण संख्याएँ नाम परिवर्तन के साथ रीसेट की गई थीं।
हाकन लिंडक्विस्ट

नमस्ते, इसलिए मैंने अब तक जो समझा है, यदि मैं सर्वर पर SSL V3 और V2 को Red Hat द्वारा अनुशंसित के रूप में अक्षम करता हूं, तो सुरक्षित कनेक्शन TLS प्रोटोकॉल पर होगा। और अगर ब्राउज़र सर्वर के साथ टीएलएस पर कॉल कर रहे हैं तो सुरक्षित कनेक्शन में कोई समस्या नहीं होगी। मुझे अंतर b / w एसएसएल और टीएलएस संस्करणों के बारे में सटीक जानकारी नहीं है ..
sandeep.s85

जवाबों:


52

सबसे पहले, चीजों को थोड़ा स्पष्ट करें:

  • TLS ने एसएसएल को सुपरक्यूट किया। TLS 1.0 के बाद आया और यह SSL 3.0 का एक अद्यतन है।

    TLS 1.2> TLS 1.1> TLS 1.0> SSL 3.0> SSL 2.0> SSL 1.0

  • 3.0 से पहले के एसएसएल संस्करण कुछ समय के लिए गंभीर सुरक्षा कमजोरियों को जानते हैं और आधुनिक ग्राहकों और सर्वरों द्वारा अक्षम / समर्थित नहीं हैं। एसएसएल 3.0 की संभावना जल्द ही उसी तरह से जाएगी।

  • वर्तमान में उपयोग किए गए प्रोटोकॉल में, "पूडल" सबसे गंभीर रूप से SSL 3.0 को प्रभावित करता है, जहां शमन करने का कोई तरीका नहीं है। कुछ टीएलएस 1.0 और 1.1 कार्यान्वयन के खिलाफ एक समान हमला है जो कल्पना की अनुमति देता है - सुनिश्चित करें कि आपका सॉफ़्टवेयर अद्यतित है।


अब, कारण "पूडल" आधुनिक ग्राहकों और सर्वरों के साथ भी एक जोखिम है, जो ग्राहकों के एक कमबैक तंत्र के कार्यान्वयन के कारण है। सभी सर्वर नवीनतम संस्करणों का समर्थन नहीं करेंगे, इसलिए क्लाइंट प्रत्येक संस्करण को कम से कम हाल के (टीएलएस 1.2, टीएलएस 1.1, टीएलएस 1.0, एसएसएल 3.0) से क्रम में आजमाएंगे, जब तक कि यह पता न चले कि सर्वर समर्थन करता है। एन्क्रिप्टेड संचार शुरू होने से पहले ऐसा होता है, इसलिए एक मैन-इन-मिडिल (MITM) हमलावर ब्राउज़र को एक पुराने संस्करण में वापस गिरने के लिए मजबूर करने में सक्षम होता है, भले ही सर्वर एक उच्चतर का समर्थन करता हो। यह एक प्रोटोकॉल डाउनग्रेड हमले के रूप में जाना जाता है।

विशेष रूप से, "पूडल" के मामले में, जब तक कि क्लाइंट और सर्वर दोनों एसएसएल 3.0 का समर्थन करते हैं, एक MITM हमलावर इस प्रोटोकॉल के उपयोग को मजबूर करने में सक्षम है।

इसलिए जब आप SSL 3.0 को अक्षम करते हैं, तो इसके दो प्रभाव होते हैं:

  • उच्च संस्करण का समर्थन करने वाले ग्राहकों को कमजोर संस्करण में वापस आने के लिए नहीं देखा जा सकता ( TLS Fallback SCSV प्रोटोकॉल डाउनग्रेड हमले को रोकने के लिए एक नया प्रस्तावित तंत्र है, लेकिन सभी क्लाइंट और सर्वर अभी तक इसका समर्थन नहीं करते हैं)। यही कारण है कि आप SSL 3.0 को अक्षम करना चाहते हैं। आपके अधिकांश ग्राहक संभवतः इस श्रेणी में आते हैं, और यह फायदेमंद है।

  • ग्राहक जो टीएलएस का समर्थन नहीं करते हैं (जैसा कि दूसरों ने उल्लेख किया है, एक्सपी पर IE6 बहुत अधिक केवल एचटीटीपीएस के लिए उपयोग किया जाता है) एक एन्क्रिप्टेड कनेक्शन के माध्यम से बिल्कुल भी कनेक्ट करने में सक्षम नहीं होगा। यह संभवतः आपके उपयोगकर्ता नाम का एक छोटा हिस्सा है, और यह बहुमत की सुरक्षा का त्याग करने के लायक नहीं है जो इस अल्पसंख्यक को पूरा करने के लिए अप-टू-डेट हैं।


8
हाय बॉब, यह यहाँ ऐलिस है। कैसे माल्ट पुडल का उपयोग कर सकते हैं के बारे में आपकी व्याख्या की तरह।
बैटरीबाकअपयूनीट

+1 प्रोटोकॉल डाउनग्रेड हमले के बारे में नहीं जानता था।
developerwjk

1
अद्यतन: "...everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken, including many implementations which conform to current specifications." zdnet.com/article/poodle-not-fixed-some-tls-systems-vulnerable
BlueCacti

@GroundZero > लेकिन यह पता चला है कि कुछ टीएलएस कार्यान्वयन अभी भी ऐसा करने की क्षमता के बावजूद पेडिंग बाइट्स की जांच नहीं करते हैं। => विशेष रूप से, जबकि टीएलएस 1.0 और 1.1 कार्यान्वयन टूट सकते हैं (और कल्पना उन्हें इस तरह से टूटने की अनुमति देती है, जो अच्छा नहीं है), यह एसएसएल 3.0 के रूप में बुरा नहीं है जहां कल्पना ही टूट गई थी और कोई नहीं थी इसके अनुरूप काम करने के लिए एक अनुरूप कार्यान्वयन का रास्ता। इसके अलावा, सर्वर पर टीएलएस 1.0 और 1.1 का "टर्न ऑफ" एसएसएल 3.0 बंद करने की तुलना में बहुत कठिन समस्या है - आप अपने उपयोगकर्ताओं के कहीं अधिक अनुपात को प्रभावित करेंगे।
बॉब

ऐसा लगता है कि यह मुख्य रूप से सर्वर-साइड कार्यान्वयन है जो असुरक्षित हैं (?) - सर्वर पर अपने टीएलएस कार्यान्वयन को ठीक करें, और आपको ठीक होना चाहिए (?) [मैंने इस बात की पुष्टि करने के लिए पर्याप्त नहीं देखा कि ब्राउज़र और अन्य क्लाइंट अप्रभावित हैं , लेकिन आपके लिंक किए गए लेख और इसके स्रोत में शब्दों का सुझाव है कि]।
बॉब

27

आपका आकलन सही है। SSL 3 को अक्षम करने के बाद ग्राहकों को आपके सर्वर से जुड़ने के लिए नए प्रोटोकॉल का उपयोग करना होगा। SSL 3 प्रोटोकॉल त्रुटिपूर्ण है, और इसमें कोई "पैच" नहीं होगा। SSL 3 को अक्षम करना एकमात्र समाधान है।

इस समय कई साइटें SSL 3 को निष्क्रिय कर चुकी हैं, क्योंकि यह लगभग अपरिहार्य है कि पुराने ब्राउज़र के उपयोगकर्ताओं को अपग्रेड करने की आवश्यकता होगी। मान लें कि आप उपयोगकर्ता एजेंट स्ट्रिंग्स को लॉग कर रहे हैं, तो आप अपने लॉग की समीक्षा कर सकते हैं और SSL 3 को अक्षम करने के बारे में एक सूचित निर्णय ले सकते हैं। मुझे लगता है कि यह संभव है कि आपकी साइट के आगंतुकों का केवल एक छोटा प्रतिशत उन ब्राउज़र का उपयोग कर रहा है जो नए प्रोटोकॉल को संभालने में असमर्थ होंगे।

[fwiw - Cloudflare रिपोर्टें 1.12% उपयोगकर्ता SSL63 के आधार पर IE6 XP उपयोगकर्ता हैं]


1
जबकि यह सही है कि एसएसएलवी 3 त्रुटिपूर्ण है, और एसएसएल 3 को निष्क्रिय करने का एकमात्र वास्तविक समाधान है। पूडल हमले के लिए एक शमन भी है जिसे SSLv3 को अक्षम करने की आवश्यकता नहीं है, यदि आप TLS 1.0 क्लाइंट के लिए RC4 सिफर को स्वीकार कर सकते हैं, क्योंकि पूडल केवल CBC मोड सिफर (AES) को प्रभावित करता है। मैंने इसे यहाँ वर्णित किया है: serverfault.com/q/637848/249649
cypres

2
TLS_FALLBACK_SCSVहालांकि पुराने ग्राहकों के लिए हमले को कम नहीं किया जा रहा है। यह सिर्फ पुराने ग्राहकों को त्रुटिपूर्ण प्रोटोकॉल का उपयोग जारी रखने की अनुमति देता है, जबकि नए ग्राहकों के लिए अवांछनीय प्रोटोकॉल संस्करण को डाउनग्रेड करने से रोकता है। अंत में, किसी भी क्लाइंट के लिए SSLv3 को सक्षम करना संभावित रूप से हमलावरों को उनके ट्रैफ़िक को उजागर करना है।
इवान एंडरसन

RC4 पुराने ग्राहकों के लिए इस हमले को कम कर रहा है, एससीएसवी को नहीं। लेकिन हम RC4 का उपयोग नहीं करते हैं, यही कारण है कि मैं भी अगर संभव हो तो SSLv3 को अक्षम करने की सलाह देता है।
cypres

1
@cypres - Yes-- 'TLS_FALLBACK_SCSV' पुराने ग्राहकों की मदद नहीं करता है। मेरा तर्क है कि गंभीर कमजोरियों को दिखाने के लिए एक सिफर का उपयोग करना या तो सहायक नहीं है। हमें इसे "फ्लैग डे" बनाने की आवश्यकता है जो एसएसएल 3.0 को 'नेट' से हटाता है। ज़रूर-- अगर आपको पुराने उपकरण, एंबेडेड डिवाइस आदि मिले हैं, जो आपके उद्यम के अंदर टीएलएस का समर्थन नहीं करते हैं तो एसएसएल 3.0 चलाने के लिए स्वतंत्र महसूस करें। मुझे लगता है कि सार्वजनिक इंटरनेट पर SSL 3.0 का उपयोग करना जारी रखने के लिए किसी को भी प्रोत्साहित करना गैर-जिम्मेदाराना है।
इवान एंडरसन

आज मैंने फ़ायरफ़ॉक्स पर एसएसएल 3 को अक्षम कर दिया और केवल टीएलएस की अनुमति दी और मुझे इंटरनेट पर वेबसाइटों को ब्राउज़ करते समय उचित मात्रा में एसएसएल कनेक्शन मुद्दे दिखाई देते हैं। मैं सैकड़ों लिनक्स सर्वरों का समर्थन कर रहा हूं जहां sslv3 सक्षम है। मैं गलत हो सकता हूं लेकिन इस स्थिति का अंतिम समाधान तब तक है जब तक ओएस विक्रेता एक पैच जारी नहीं करते हैं ताकि क्लाइंट अंत पर कुछ भी न किया जाए। समस्या यह है कि आप प्रभाव का अनुमान नहीं लगा सकते हैं।
संदीप। S85

20

हां, SSL3 को अक्षम करने से यह ऐसा हो जाएगा कि जो उपयोगकर्ता TLS का समर्थन नहीं करते हैं वे आपकी वेबसाइट तक नहीं पहुंच सकते।

हालांकि, एक व्यावहारिक दृष्टिकोण से, उस श्रेणी में ब्राउज़रों को देखें। क्रोम और फ़ायरफ़ॉक्स दोनों टीएलएस का समर्थन करते हैं और यहां तक ​​कि इस बग के कारण SSL3 समर्थन को पूरी तरह से छोड़ने वाले हैं। IE ने IE7 के बाद से इसका समर्थन किया है। एकमात्र ब्राउज़र जिसका समर्थन नहीं है, लेकिन अभी भी वैश्विक स्तर पर उपयोग किया जाता है, IE6 है, और एकमात्र कारण जो अभी भी उपयोग किया जाता है वह है 2 कारण:

  1. एक्सपी के टूटे हुए संस्करण और क्रोम या फ़ायरफ़ॉक्स का उपयोग करने का कोई तरीका नहीं है;
  2. ब्राउज़र पसंद के संबंध में प्रतिबंधों के साथ कॉर्पोरेट या सरकार की नीति पर कोई भी।

इन दोनों मामलों में, IE6 का उपयोग किया जाता है क्योंकि यह डिफ़ॉल्ट विंडोज एक्सपी ब्राउज़र है जो मूल इंस्टॉल के साथ आता है। इसके अलावा, एकमात्र कारण यह है कि IE6 का अभी भी (छोटा) वैश्विक बाजार में हिस्सा है क्योंकि चीन में कई उपयोगकर्ता हैं।

तो, लंबी कहानी छोटी: यहाँ 3 प्रश्न हैं:

  1. क्या आपके पास एक महत्वपूर्ण चीनी यूजरबेस है?
  2. क्या आपकी वेबसाइट IE6 के लिए समर्थन प्रदान करती है, भले ही यह पुरातन और टूटी हुई हो?
  3. क्या आपकी वेबसाइट ब्राउज़र पसंद प्रतिबंधों के साथ सरकार या निगम द्वारा उपयोग किया जाने वाला उत्पाद है?

यदि इन 3 में से कोई भी सत्य है, तो आपको एक वैकल्पिक समाधान खोजना होगा। यदि सभी 3 झूठे हैं, तो इसे अक्षम करें और इसके साथ किया जाए। और अगर आपको वैकल्पिक समाधान की आवश्यकता है, तो क्या आप अपने यूजरबेस के उस छोटे से हिस्से को समझाने के लिए सबसे कठिन हैं जो अभी भी IE6 का उपयोग 13 साल पुराने ब्राउज़र से दूर जाने के लिए करता है।


7

आप अपने प्रश्न में " अपाचे " और " ब्राउज़र " का उल्लेख करते हैं, लेकिन शीर्षक अधिक सामान्य है।

जैसा कि इवान और अन्य बताते हैं, समस्या HTTPS के लिए सभी तरह की है। लेकिन कई अन्य प्रोटोकॉल हैं जो एक सर्वर एन्क्रिप्ट कर सकते हैं, और टीएलएस समर्थन उस क्लाइंट बेस के बीच बहुत खराब है (जैसा कि मुझे आज सुबह पता चला, जब आईएमएपी / एस सर्वर पर "कोई एसएसएल 3" को अनिवार्य नहीं किया गया)।

इसलिए मुझे डर है कि उत्तर " यह निर्भर करता है कि आप किन सेवाओं को एन्क्रिप्ट करते हैं, और आपके उपयोगकर्ता आधार में टीएलएस के लिए क्लाइंट का समर्थन है "।

संपादित करें : हाँ, यह मेरी बात थी, हालांकि मुझे खुशी है कि आप सहमत हैं। Sslv3 को बंद करना सेवा-दर-सेवा के आधार पर किया जाता है। उदाहरण के लिए, इसे dovecot पर बंद करने का तरीका है

ssl_cipher_list = ALL:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

में है dovecot.conf। बड़ी समस्या यह है कि अधिकांश ब्राउज़र sslv3 के नुकसान के प्रति सहिष्णु हैं, अन्य सेवाओं के ग्राहक बहुत अधिक सहिष्णु लगते हैं। मैंने आज सुबह अपने आधे उपयोगकर्ताओं को तोड़ दिया, जब मैंने उसे dovecot पर बंद कर दिया; Win7 पर K-9 मेल और आउटलुक चलाने वाले एंड्रॉइड फोन दो हैं जिन्हें मैं निश्चित रूप से जानता हूं, लेकिन मैं अपने लॉग से देख सकता हूं कि कुछ और भी थे।

SSLv3 को बंद करना अभी भी केवल एक वैध समाधान नहीं है, यह एकमात्र समाधान है; लेकिन यह चोट करने वाला है।

संपादित करें 2 : dave_thompson_085 के लिए धन्यवाद कि यह इंगित करने के लिए कि dovcot में SSLv3 सिफर को निष्क्रिय करने से न केवल SSLv3 प्रोटोकॉल निष्क्रिय हो जाता है, बल्कि TLSv1.0 और TLSv1.1 भी, क्योंकि उनके पास कोई ऐसा सिफर नहीं है जो पहले वाला प्रोटोकॉल नहीं करता है। Dovecot (कम से कम, पहले के संस्करण, जिनमें मैं शामिल हूं) को सिफरसुइट्स के बजाय प्रोटोकॉल को कॉन्फ़िगर करने की क्षमता की कमी लगती है। यह शायद समझाता है कि ऐसा करने से इतने सारे ग्राहक क्यों टूट गए।


1
मैंने अब यह भी पढ़ा है कि यह न केवल वेब सर्वर को प्रभावित करेगा, बल्कि एसएसएल यानी वेब सर्वर, एलडीएपी सर्वर, एसएसएच डेमॉन, पीओपी 3 सर्वर, एसएमटीपी सर्वर का उपयोग करने वाली सर्वर पर चलने वाली किसी भी सेवा का वेब सर्वर के लिए अपाचे में विन्यास है। mod_ssl config file SSLProtocol All -SSLv2 -SSLv3 के रूप में हमें अन्य सेवाओं पर भी ध्यान देने की आवश्यकता है कि कैसे हम ग्राहक / सर्वर को SSLv3 का उपयोग करने से रोकते हैं
sandeep.s85

सुरक्षा सलाहकार में वर्णित वास्तविक POODLE अटैक, हमलावर से नियंत्रण की कुछ क्षमता के साथ किए गए एक उचित राशि के अनुरोध पर निर्भर करता है। HTTPS और ब्राउज़र के संदर्भ में जो स्क्रिप्टिंग के लिए संभव है, लेकिन उदाहरण के लिए IMAPS के संदर्भ में, मुझे विश्वास नहीं है कि यह करने के लिए एक व्यावहारिक बात है। बोर्ड भर में एसएसएलवी 3 से छुटकारा पाना निश्चित रूप से आदर्श है, लेकिन मुझे यकीन नहीं है कि विशेष रूप से कुछ ऐसे अन्य मामलों के लिए प्रासंगिक है।
हाकन लिंडक्विस्ट

Håkan, जैसे-जैसे समय बीतता जा रहा है, मैं आपसे और अधिक सहमत होता जा रहा हूं।
MadHatter

3
अक्षम करना सिफर !SSLv3 openssl में वास्तव में TLSv1.2 को छोड़कर सभी प्रोटोकॉल है, जो अपने साथियों के लिए अच्छा नहीं हो सकता है अक्षम करता है। यही कारण है कि प्रोटोकॉल को अक्षम करना बेहतर है, लेकिन AFAICS केवल dovecot 2.1+ में है। देखें सुरक्षा .stackexchange.com/ questions/71872/…
dave_thompson_085

@ dave_thompson_085: जब आप "डिसेबल में ... डिस्सेल में" कहते हैं , तो क्या आप का अर्थ है " डिवॉकेट में अक्षम ... "? यदि ऐसा है, तो मैं आपसे सहमत हूं, और यदि आप अनुरोध के अनुसार स्पष्ट कर सकते हैं, तो मैं इस जानकारी के प्रकाश में अपना जवाब दूंगा।
MadHatter

6

SSLv3 को अक्षम करना सबसे अच्छा समाधान है, लेकिन मैं सहमत नहीं हूं कि यह एकमात्र समाधान है। जैसा कि CloudFlare वर्णन करता है, SSLv3 का उपयोग बहुत कम है , इसलिए अधिकांश व्यवस्थापक को इसे बंद करने में कोई समस्या नहीं होनी चाहिए।

यदि आपके पास SSLv3 के लिए एक विशिष्ट आवश्यकता है, तो शायद आपको Windows XP पर IE6 का समर्थन करने की आवश्यकता है, या आपको बहुत पुराने सॉफ़्टवेयर का समर्थन करने की आवश्यकता है, इसे कम करने का एक और तरीका है।

इसे कम करने, और SSLv3 रखने का तरीका, RC4 का उपयोग करना और TLS फ़ॉलबैक SCSV का समर्थन करना है, जो OpenSSL 1.0.1j द्वारा प्रदान किया गया है। Poodle में क्वालिस पोस्ट में , RC4 "कुछ असुरक्षित स्ट्रीम सिफर है जिसका नाम कोई भी उल्लेख नहीं करना चाहता है"।

यह वही है जो google mail.google.com पर करता है, और वे इसे ब्लॉग प्रविष्टि में भी वर्णित करते हैं: http://googleonlinesecurity.blogspot.se/2014/10/this-poodle-bites-exploiting-ssl-30.html


2
मुझे वास्तव में यकीन नहीं है कि जो बदतर है, वह सिस्टम को पुडल के लिए खुला छोड़ रहा है या आरसी 4 को डाउनशफ्टिंग कर रहा है ...
ब्रायन नोब्लुच

TLS 1.1+ का समर्थन करने वाले ग्राहक RC4 को डाउनशिफ्ट नहीं करते हैं। मैं कोई विशेषज्ञ नहीं हूं, लेकिन मेरा मानना ​​है कि पूडल बदतर है।
cypres

क्या RC4 अनिवार्य रूप से रॉ क्लियरटेक्स्ट के लिए नहीं खड़ा है?
हेगन वॉन एटिजन

1
निश्चित रूप से आप मजाक कर रहे हैं, लेकिन एक वैध बिंदु उठाएं। ऐसा नहीं है कि बुरी तरह से टूट गया है, यह सुरक्षा पर इस पर एक बहुत अच्छा जवाब है: Security.stackexchange.com/a/32498
cypres

2

वार्तालाप से एक विवरण गायब है, मूल प्रश्न के आधार पर इसे नोट करना एक अच्छा विचार हो सकता है। TLS 1.0 को SSL 3.1 भी कहा जाता है, इसलिए मूल पोस्टर, आपको अपने विन्यास को देखना चाहिए, क्या आप v3.0 या v3.1 चला रहे हैं


-3

अधिकांश चीजों के साथ, इसका जवाब "यह निर्भर करता है" है। किसी भी प्रकार के "सामान्य" उपयोग में एकमात्र ब्राउज़र जो टीएलएस का समर्थन नहीं करता है वह IE6 है। दुर्भाग्य से, विभिन्न रिपोर्टों का कहना है कि IE6 वैश्विक HTTP अनुरोधों के कुछ प्रतिशत के रूप में हो सकता है (देखें: http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html ) । अच्छी खबर है, अगर आपके उत्तर अमेरिका में, यह है कि यह अमेरिका में अपेक्षाकृत असामान्य है। सुरक्षित होने के लिए, आपको अपने www लॉग्स से उपयोगकर्ता एजेंट आँकड़ा देखना चाहिए। मेरे मामले में, वहाँ कुछ IE6 ua उंगली प्रिंट थे कि मुझे लगता है कि वे सभी परीक्षण उपकरण से थे।

आप अपनी वेबसाइट (एस) को ssllab के परीक्षक के साथ देख सकते हैं कि विभिन्न एजेंट कैसे प्रतिक्रिया करते हैं।

https://www.ssllabs.com/ssltest/

टीएल; डीआर - एसएसएलवी 3 मर चुका है; लंबे समय तक टीएलएस।


15
IE6 XP के साथ संगत अंतिम संस्करण नहीं है, यह वह संस्करण है जिसके साथ XP ने भेज दिया है। IE8 XP के साथ संगत अंतिम संस्करण है।
हाकन लिंडक्विस्ट

6
-1 की वजह से वास्तविक गलतियाँ IE6 का संकेत xp पर नवीनतम संस्करण है।
टॉमटॉम

may be as much as a few percent of global HTTP requests। मुझे उसके लिए एक स्रोत चाहिए। CloudFlare इसे उपयोग के बारे में कहता है: In other words, even on an out-of-date operating system, 98.88% Windows XP users connected using TLSv1.0+( blog.cloudflare.com/… )। जो विश्व स्तर पर "कुछ प्रतिशत" से कहीं कम है।
फकर

1
मुझे संदेह है कि क्लाउडफेयर के ग्राहक ज्यादातर बड़ी उत्तरी अमेरिकी कंपनियां हैं। मेरे द्वारा उद्धृत प्रतिमा netcraft से आई थी: news.netcraft.com/archives/2014/10/15/… "इसकी उम्र और विंडोज एक्सपी के लिए माइक्रोसॉफ्ट के समर्थन के बावजूद, IE6 लोकप्रिय बना हुआ है, दुनिया भर में वेब यात्राओं के 3.8% से अधिक के लिए लेखांकन , और चीन में 12.5%। यह भेद्यता IE6 और Windows XP के लिए मौत की घंटी बजा सकती है। "
जोशुआ हॉब्लिट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.