HTTPS पर संभावित हमले और उनके खिलाफ बचाव कैसे करें

आधी साइटें HTTPS का उपयोग करती हैं , और उनकी संख्या लगातार बढ़ रही है। प्रोटोकॉल ट्रैफ़िक अवरोधन के जोखिम को कम करता है, लेकिन प्रति सेकंड हमले के प्रयासों को रोकता नहीं है। उनमें से कुछ के बारे में - POODLE, BEAST, DROWN और अन्य - और सुरक्षा के तरीके, हम अपनी सामग्री में बताएंगे।


/ फ़्लिकर / स्वेन ग्रीम / सीसी बाय-एसए

POODLE

2014 में पहली बार POODLE हमला हुआ। SSL 3.0 प्रोटोकॉल में भेद्यता की खोज सुरक्षा विशेषज्ञ बोडो मोलर ने Google के सहयोगियों के साथ की थी।

इसका सार इस प्रकार है: एक हैकर क्लाइंट को डिस्कनेक्टेड संचार का अनुकरण करते हुए एसएसएल 3.0 कनेक्शन बनाने के लिए मजबूर करता है। फिर यह सीबीसी मोड में एन्क्रिप्ट किए गए ट्रैफ़िक में विशेष संदेश टैग की खोज करता है। नकली प्रश्नों की एक श्रृंखला का उपयोग करते हुए, एक हमलावर डेटा की सामग्री को फिर से संगठित कर सकता है जो उसे रुचि देता है, जैसे कि कुकीज़।

एसएसएल 3.0 एक अप्रचलित प्रोटोकॉल है। लेकिन इसकी सुरक्षा का सवाल अभी भी प्रासंगिक है। सर्वर संगतता समस्याओं से बचने के लिए ग्राहक इसका उपयोग करते हैं। कुछ रिपोर्टों के अनुसार, 100 हजार सबसे लोकप्रिय साइटों में से लगभग 7% अभी भी SSL 3.0 का समर्थन करते हैं । POODLE के संशोधन भी हैं , जिनका उद्देश्य अधिक आधुनिक TLS 1.0 और TLS 1.1 है। इस साल , नए ज़ोंबी POODLE और GOLDENDOODLE हमले दिखाई दिए हैं जो TLS 1.2 सुरक्षा को बायपास करते हैं (वे अभी भी C एन्क्रिप्शन के साथ जुड़े हैं)।

खुद की सुरक्षा कैसे करें। मूल POODLE के मामले में, आपको SSL 3.0 समर्थन को अक्षम करना होगा। हालाँकि, इस स्थिति में, संगतता समस्याओं का जोखिम है। एक वैकल्पिक समाधान TLS_FALLBACK_SCSV तंत्र हो सकता है - यह सुनिश्चित करता है कि SSL 3.0 पर डेटा विनिमय केवल पुराने सिस्टम के साथ ही किया जाएगा। हमलावर अब प्रोटोकॉल का डाउनग्रेड शुरू नहीं कर पाएंगे। ज़ोंबी प्रालि और गोल्डडेल के खिलाफ सुरक्षा का एक तरीका टीएलएस 1.2 पर आधारित अनुप्रयोगों में सीबीसी समर्थन को अक्षम करना है। कार्डिनल निर्णय टीएलएस 1.3 के लिए संक्रमण होगा - प्रोटोकॉल का नया संस्करण सीबीसी एन्क्रिप्शन का उपयोग नहीं करता है।

जानवर

एसएसएल और टीएलएस 1.0 पर बहुत पहले हमलों में से एक, 2011 में खोजा गया था। POODLE की तरह, BEAST CBC एन्क्रिप्शन सुविधाओं का उपयोग करता है। हमलावरों ने क्लाइंट मशीन पर एक जावास्क्रिप्ट एजेंट या जावा एपलेट तैनात किया है जो टीएलएस या एसएसएल के माध्यम से डेटा संचारित करते समय संदेशों को खराब करता है। चूंकि हमलावर "नकली" पैकेट की सामग्री को जानते हैं, इसलिए वे उन्हें आरंभीकरण वेक्टर को डिक्रिप्ट करने और सर्वर पर अन्य संदेशों को पढ़ने के लिए उपयोग कर सकते हैं, उदाहरण के लिए, प्रमाणीकरण के लिए कुकीज़।

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

खुद की सुरक्षा कैसे करें। हमलावर को डेटा को डिक्रिप्ट करने के लिए नियमित रूप से अनुरोध भेजने की आवश्यकता होती है। VMware, SSLSessionCacheTimeout की अवधि को पांच मिनट (डिफ़ॉल्ट अनुशंसा) से घटाकर 30 सेकंड करने की सलाह देता है। यह दृष्टिकोण हमलावरों के लिए योजनाओं के कार्यान्वयन को जटिल करेगा, हालांकि इसका उत्पादकता पर कुछ नकारात्मक प्रभाव पड़ेगा। इसके अलावा, आपको यह समझने की आवश्यकता है कि जल्द ही BEAST भेद्यता अपने स्वयं के समझौते की चीज बन सकती है - 2020 के बाद से, सबसे बड़े ब्राउज़रों ने टीएलएस 1.0 और 1.1 का समर्थन करना बंद कर दिया है । किसी भी स्थिति में, सभी ब्राउज़र के 1.5% से कम उपयोगकर्ता इन प्रोटोकॉल के साथ काम करते हैं।

डूबना

यह 40-बिट RSA कुंजी के साथ SSLv2 के कार्यान्वयन में त्रुटियों का उपयोग करके एक क्रॉस-प्रोटोकॉल हमला है। एक हमलावर एक लक्ष्य के सैकड़ों टीएलएस कनेक्शनों को सुनता है और एक ही निजी कुंजी का उपयोग करके एसएसवी 2 के साथ एक सर्वर पर विशेष पैकेट भेजता है। Bleichenbacher हमले का उपयोग करते हुए , एक हैकर एक हजार टीएलएस ग्राहक सत्रों में से एक को डिक्रिप्ट कर सकता है।

DROWN पहली बार 2016 में ज्ञात हुआ - फिर दुनिया के एक तिहाई सर्वर इसके संपर्क में आए । आज तक, यह प्रासंगिकता नहीं खोई है। 150,000 सबसे लोकप्रिय साइटों में से, 2% अभी भी SSLv2 और कमजोर एन्क्रिप्शन तंत्र का समर्थन करते हैं ।

खुद की सुरक्षा कैसे करें। क्रिप्टोग्राफिक लाइब्रेरी डेवलपर्स द्वारा प्रस्तावित पैच स्थापित करना आवश्यक है जो एसएसएलवी 2 समर्थन को अक्षम करते हैं। उदाहरण के लिए, ओपनएसएसएल के लिए इस तरह के दो पैच पेश किए गए थे (2016 में ये अपडेट 1.0.1 और 1.0.2 जी थे )। इसके अलावा, कमजोर प्रोटोकॉल को अक्षम करने के अपडेट और निर्देश रेड हैट , अपाचे , डेबियन में प्रकाशित किए गए थे।

IaaS प्रदाता 1cloud.ru के विकास विभाग के प्रमुख सर्गेई बेलकिन ने कहा, "यदि इसकी कुंजियों का उपयोग एसएसएलवी 2 के साथ तीसरे पक्ष के सर्वर द्वारा किया जाता है, उदाहरण के लिए, एक संसाधन सर्वर के लिए असुरक्षित हो सकता है,"। - यह स्थिति तब होती है जब कई सर्वर एक सामान्य एसएसएल प्रमाणपत्र का उपयोग करते हैं। इस स्थिति में, सभी मशीनों पर SSLv2 समर्थन को अक्षम करें। "

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

Heartbleed

सॉफ्टवेयर में सबसे बड़ी कमजोरियों में से एक हार्टबेल्ड है । यह ओपनएसएसएल पुस्तकालय में 2014 में खोजा गया था। त्रुटि की घोषणा के समय, असुरक्षित वेबसाइटों की संख्या आधा मिलियन अनुमानित की गई थी - नेटवर्क पर संरक्षित संसाधनों का लगभग 17%।

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

भेद्यता 1.0.1 और 1.0.1f के बीच लाइब्रेरी के सभी संस्करणों में मौजूद थी, साथ ही साथ कई ऑपरेटिंग सिस्टम - उबंटू में 12.04.4 तक, सेंटोस 6.5 से अधिक, ओपनबीएसडी 5.3 और अन्य। एक पूरी सूची हार्टलेबल वेबसाइट पर है । हालांकि इस भेद्यता के खिलाफ पैच इसकी खोज के लगभग तुरंत बाद जारी किए गए थे, समस्या अब तक प्रासंगिक बनी हुई है। 2017 में, लगभग 200 हजार साइट हार्टलेड से प्रभावित थीं।

खुद की सुरक्षा कैसे करें। आपको OpenSSL को संस्करण 1.0.1g या उच्चतर में अपग्रेड करना होगा। आप DOPENSSL_NO_HEARTBEATS विकल्प का उपयोग करके मैन्युअल रूप से हार्टबीट अनुरोधों को अक्षम कर सकते हैं। नवीनीकरण के बाद, सूचना सुरक्षा विशेषज्ञ एसएसएल प्रमाणपत्रों को फिर से जारी करने की सलाह देते हैं । यदि हैकर्स के पास अभी भी एन्क्रिप्शन कुंजियों का डेटा है, तो रिप्लेसमेंट की आवश्यकता है।

प्रमाण पत्र स्पूफिंग

उपयोगकर्ता और सर्वर के बीच एक वैध एसएसएल प्रमाण पत्र के साथ एक प्रबंधित नोड स्थापित है जो सक्रिय रूप से ट्रैफ़िक को स्वीकार करता है। यह नोड एक वैध सर्वर होने का दिखावा करता है, एक वैध प्रमाण पत्र प्रस्तुत करता है, और एक MITM हमले का संचालन करना संभव हो जाता है।

मोज़िला, Google और कई विश्वविद्यालयों की टीमों के एक अध्ययन के अनुसार, नेटवर्क पर लगभग 11% सुरक्षित कनेक्शन "टैप" किए जाते हैं। यह उपयोगकर्ताओं के कंप्यूटरों पर संदिग्ध रूट प्रमाणपत्र स्थापित करने का परिणाम है।

खुद की सुरक्षा कैसे करें। विश्वसनीय एसएसएल प्रदाताओं की सेवाओं का उपयोग करें। आप सर्टिफिकेट ट्रांसपेरेंसी (सीटी) सेवा का उपयोग करके प्रमाणपत्रों की "गुणवत्ता" की जांच कर सकते हैं। क्लाउड प्रदाता वायरटैप का पता लगाने में भी मदद कर सकते हैं - पहले से ही आज कुछ बड़ी कंपनियां टीएलएस कनेक्शन की निगरानी के लिए विशेष उपकरण प्रदान करती हैं।

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


/ फ़्लिकर / यूरी समोइलोव / सीसी बाय

HTTPS संभावनाएँ

कई कमजोरियों के बावजूद, आईटी दिग्गज और सूचना सुरक्षा विशेषज्ञ प्रोटोकॉल के भविष्य में आश्वस्त हैं। डब्ल्यूडब्ल्यूडब्ल्यू टिम बर्नर्स-ली का निर्माता HTTPS के सक्रिय कार्यान्वयन के लिए खड़ा है । उनके अनुसार, समय के साथ, टीएलएस अधिक सुरक्षित हो जाएगा, जिससे कनेक्शन की सुरक्षा में काफी वृद्धि होगी। बर्नर्स-ली ने यहां तक ​​सुझाव दिया कि भविष्य में प्रमाणीकरण के लिए ग्राहक प्रमाणपत्र होंगे । वे घुसपैठियों से सर्वर सुरक्षा में सुधार करने में मदद करेंगे।

मशीन लर्निंग की मदद से एसएसएल / टीएलएस तकनीक विकसित करने की भी योजना है - स्मार्ट एल्गोरिदम दुर्भावनापूर्ण ट्रैफ़िक को फ़िल्टर करने के लिए जिम्मेदार होगा। HTTPS कनेक्शन में, प्रशासकों के पास एन्क्रिप्टेड संदेशों की सामग्री का पता लगाने का कोई तरीका नहीं है, जिसमें मैलवेयर से अनुरोधों का पता लगाना भी शामिल है। पहले से ही, तंत्रिका नेटवर्क 90% की सटीकता के साथ संभावित खतरनाक पैकेट को फ़िल्टर करने में सक्षम हैं। ( स्लाइड 23 प्रस्तुतियां )।

निष्कर्ष

HTTPS पर हमलों के अधिकांश भाग प्रोटोकॉल में समस्याओं से संबंधित नहीं हैं, लेकिन पुराने एन्क्रिप्शन तंत्र का समर्थन करने के लिए हैं। आईटी उद्योग पिछली पीढ़ी के प्रोटोकॉल को समाप्त करने के लिए शुरुआत कर रहा है और कमजोरियों को खोजने के लिए नए उपकरण पेश कर रहा है। भविष्य में, ये उपकरण अधिक बुद्धिमान हो जाएंगे।

अतिरिक्त संबंधित लिंक:

• क्लाउड में विकास, सूचना सुरक्षा और व्यक्तिगत डेटा: 1क्लौड से पचा
• एसएसएल-डाइजेस्ट: हैबर पर सबसे अच्छा व्यावहारिक सामग्री और न केवल
• वीपीएन डाइजेस्ट: फैब-फाइंडिंग आर्टिकल्स ऑन हेबे और न केवल