🥇 HTTPS वरील संभाव्य हल्ले आणि त्यांच्यापासून स्वतःचे संरक्षण कसे करावे

अर्ध्या साइट्स HTTPS वापरते, आणि त्यांची संख्या सतत वाढत आहे. प्रोटोकॉल ट्रॅफिक व्यत्यय येण्याचा धोका कमी करतो, परंतु तसे प्रयत्न केलेले हल्ले दूर करत नाही. आम्ही त्यापैकी काहींबद्दल बोलू - POODLE, BEAST, DROWN आणि इतर - आणि आमच्या सामग्रीमध्ये संरक्षणाच्या पद्धती.

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

POODLE

हल्ल्याबद्दल प्रथमच POODLE 2014 मध्ये ओळखले गेले. SSL 3.0 प्रोटोकॉलमधील एक भेद्यता माहिती सुरक्षा तज्ञ बोडो मोलर आणि Google मधील सहकाऱ्यांनी शोधली.

त्याचे सार खालीलप्रमाणे आहे: हॅकर क्लायंटला कनेक्शन ब्रेक्सचे अनुकरण करून SSL 3.0 द्वारे कनेक्ट करण्यास भाग पाडतो. मग तो एनक्रिप्टेडमध्ये शोधतो CBC-ट्रॅफिक मोड विशेष टॅग संदेश. बनावट विनंत्यांच्या मालिकेचा वापर करून, आक्रमणकर्ता कुकीजसारख्या स्वारस्याच्या डेटाची सामग्री पुनर्रचना करण्यास सक्षम आहे.

SSL 3.0 हा कालबाह्य प्रोटोकॉल आहे. पण त्याच्या सुरक्षिततेचा प्रश्न अजूनही संबंधित आहे. सर्व्हरसह सुसंगतता समस्या टाळण्यासाठी क्लायंट त्याचा वापर करतात. काही डेटानुसार, 7 हजार सर्वात लोकप्रिय साइटपैकी जवळजवळ 100% अजूनही SSL 3.0 चे समर्थन करते. तसेच अस्तित्वात POODLE मध्ये बदल जे अधिक आधुनिक TLS 1.0 आणि TLS 1.1 ला लक्ष्य करतात. या वर्षी दिसू लागले नवीन Zombie POODLE आणि GOLDENDOODLE हल्ले जे TLS 1.2 संरक्षणाला बायपास करतात (ते अजूनही CBC एन्क्रिप्शनशी संबंधित आहेत).

स्वतःचे रक्षण कसे करावे. मूळ POODLE च्या बाबतीत, तुम्हाला SSL 3.0 समर्थन अक्षम करणे आवश्यक आहे. तथापि, या प्रकरणात सुसंगतता समस्या एक धोका आहे. पर्यायी उपाय TLS_FALLBACK_SCSV यंत्रणा असू शकते - हे सुनिश्चित करते की SSL 3.0 द्वारे डेटा एक्सचेंज फक्त जुन्या सिस्टमसह केले जाईल. हल्लेखोर यापुढे प्रोटोकॉल डाउनग्रेड सुरू करू शकणार नाहीत. Zombie POODLE आणि GOLDENDOODLE पासून संरक्षण करण्याचा एक मार्ग म्हणजे TLS 1.2-आधारित अनुप्रयोगांमध्ये CBC समर्थन अक्षम करणे. मुख्य उपाय TLS 1.3 मध्ये संक्रमण असेल - प्रोटोकॉलची नवीन आवृत्ती CBC एन्क्रिप्शन वापरत नाही. त्याऐवजी, अधिक टिकाऊ AES आणि ChaCha20 वापरले जातात.

बीस्ट

1.0 मध्ये सापडलेल्या SSL आणि TLS 2011 वरील पहिल्या हल्ल्यांपैकी एक. POODLE, BEAST सारखे वापरते सीबीसी एनक्रिप्शनची वैशिष्ट्ये. हल्लेखोर क्लायंट मशीनवर JavaScript एजंट किंवा Java ऍपलेट स्थापित करतात, जे TLS किंवा SSL वर डेटा प्रसारित करताना संदेशांची जागा घेतात. हल्लेखोरांना "डमी" पॅकेटमधील सामग्री माहित असल्याने, ते इनिशिएलायझेशन वेक्टर डिक्रिप्ट करण्यासाठी आणि प्रमाणीकरण कुकीजसारखे सर्व्हरवरील इतर संदेश वाचण्यासाठी त्यांचा वापर करू शकतात.

आजपर्यंत, BEAST असुरक्षा कायम आहे अनेक नेटवर्क साधने संवेदनाक्षम आहेत: स्थानिक इंटरनेट गेटवे संरक्षित करण्यासाठी प्रॉक्सी सर्व्हर आणि अनुप्रयोग.

स्वतःचे रक्षण कसे करावे. आक्रमणकर्त्याला डेटा डिक्रिप्ट करण्यासाठी नियमित विनंत्या पाठवणे आवश्यक आहे. VMware मध्ये शिफारस SSLSessionCacheTimeout चा कालावधी पाच मिनिटांपासून (डिफॉल्ट शिफारस) 30 सेकंदांपर्यंत कमी करा. हा दृष्टिकोन हल्लेखोरांना त्यांच्या योजना अंमलात आणणे अधिक कठीण करेल, जरी त्याचा कार्यक्षमतेवर काही नकारात्मक प्रभाव पडेल. याव्यतिरिक्त, तुम्हाला हे समजून घेणे आवश्यक आहे की BEAST असुरक्षा लवकरच स्वतःहून भूतकाळातील गोष्ट बनू शकते - 2020 पासून, सर्वात मोठे ब्राउझर थांबा TLS 1.0 आणि 1.1 साठी समर्थन. कोणत्याही परिस्थितीत, सर्व ब्राउझर वापरकर्त्यांपैकी 1,5% पेक्षा कमी या प्रोटोकॉलसह कार्य करतात.

बुडणे

हा क्रॉस-प्रोटोकॉल हल्ला आहे जो 2-बिट RSA की सह SSLv40 च्या अंमलबजावणीमध्ये बग्सचा फायदा घेतो. आक्रमणकर्ता लक्ष्याची शेकडो TLS कनेक्शन ऐकतो आणि त्याच खाजगी की वापरून SSLv2 सर्व्हरवर विशेष पॅकेट पाठवतो. वापरत आहे ब्लेचेनबॅकर हल्ला, हॅकर सुमारे हजार क्लायंट TLS सत्रांपैकी एक डिक्रिप्ट करू शकतो.

DROWN प्रथम 2016 मध्ये ओळखले गेले - नंतर ते झाले एक तृतीयांश सर्व्हर प्रभावित झाले आहेत जगामध्ये. आज त्याची प्रासंगिकता गमावलेली नाही. 150 हजार सर्वात लोकप्रिय साइट्सपैकी 2% अजूनही आहेत समर्थन SSLv2 आणि असुरक्षित एन्क्रिप्शन यंत्रणा.

स्वतःचे रक्षण कसे करावे. क्रिप्टोग्राफिक लायब्ररींच्या विकसकांद्वारे प्रस्तावित पॅचेस स्थापित करणे आवश्यक आहे जे SSLv2 समर्थन अक्षम करतात. उदाहरणार्थ, OpenSSL साठी असे दोन पॅच सादर केले गेले (2016 मध्ये हे अद्यतने होते 1.0.1s आणि 1.0.2g). तसेच, असुरक्षित प्रोटोकॉल अक्षम करण्यासाठी अद्यतने आणि सूचना प्रकाशित केल्या होत्या लाल टोपी, अपाचे, डेबियन.

"एखादे संसाधन डूब होण्यास असुरक्षित असू शकते जर त्याच्या की SSLv2 सह तृतीय-पक्ष सर्व्हरद्वारे वापरल्या गेल्या असतील, जसे की मेल सर्व्हर," विकास विभागाचे प्रमुख नमूद करतात IaaS प्रदाता 1cloud.ru सर्गेई बेल्किन. — अनेक सर्व्हर एक सामान्य SSL प्रमाणपत्र वापरत असल्यास ही परिस्थिती उद्भवते. या प्रकरणात, तुम्हाला सर्व मशीनवर SSLv2 समर्थन अक्षम करणे आवश्यक आहे."

तुम्‍ही तुमच्‍या सिस्‍टमला विशेष वापरून अपडेट करण्‍याची आवश्‍यकता आहे का ते तपासू शकता उपयुक्तता - हे माहिती सुरक्षा तज्ञांनी विकसित केले होते ज्यांनी DROWN शोधला. या प्रकारच्या हल्ल्यापासून संरक्षणाशी संबंधित शिफारशींबद्दल तुम्ही अधिक वाचू शकता OpenSSL वेबसाइटवर पोस्ट करा.

हृदयस्पर्शी

सॉफ्टवेअरमधील सर्वात मोठी भेद्यता आहे हृदयस्पर्शी. 2014 मध्ये OpenSSL लायब्ररीमध्ये याचा शोध लागला. बग घोषणेच्या वेळी, असुरक्षित वेबसाइट्सची संख्या अर्धा दशलक्ष अंदाजे होते - हे नेटवर्कवरील संरक्षित संसाधनांच्या अंदाजे 17% आहे.

लहान हार्टबीट TLS विस्तार मॉड्यूलद्वारे हल्ला लागू केला जातो. TLS प्रोटोकॉलसाठी डेटा सतत प्रसारित करणे आवश्यक आहे. प्रदीर्घ डाउनटाइमच्या बाबतीत, ब्रेक होतो आणि कनेक्शन पुन्हा स्थापित करावे लागते. समस्येचा सामना करण्यासाठी, सर्व्हर आणि क्लायंट कृत्रिमरित्या चॅनेलचा "आवाज" करतात (RFC 6520, p.5), यादृच्छिक लांबीचे पॅकेट प्रसारित करणे. जर ते संपूर्ण पॅकेटपेक्षा मोठे असेल, तर OpenSSL च्या असुरक्षित आवृत्त्या वाटप केलेल्या बफरच्या पलीकडे मेमरी वाचतात. या क्षेत्रामध्ये खाजगी एन्क्रिप्शन की आणि इतर कनेक्शनबद्दल माहितीसह कोणताही डेटा असू शकतो.

लायब्ररीच्या 1.0.1 आणि 1.0.1f च्या सर्व आवृत्त्यांमध्ये, तसेच अनेक ऑपरेटिंग सिस्टम्समध्ये भेद्यता उपस्थित होती - उबंटू 12.04.4 पर्यंत, सेंटोस 6.5 पेक्षा जुनी, OpenBSD 5.3 आणि इतर. संपूर्ण यादी आहे Heartbleed ला समर्पित वेबसाइटवर. जरी या असुरक्षिततेच्या विरूद्ध पॅच त्याच्या शोधानंतर लगेचच सोडले गेले असले तरी, समस्या आजही संबंधित आहे. 2017 मध्ये परत जवळपास 200 हजार साइट्सने काम केले, Heartbleed संवेदनाक्षम.

स्वतःचे रक्षण कसे करावे. हे आवश्यक आहे OpenSSL अद्यतनित करा आवृत्ती 1.0.1g किंवा उच्च पर्यंत. तुम्ही DOPENSSL_NO_HEARTBEATS पर्याय वापरून हार्टबीट विनंत्या व्यक्तिचलितपणे अक्षम देखील करू शकता. अद्यतनानंतर, माहिती सुरक्षा तज्ञ शिफारस SSL प्रमाणपत्रे पुन्हा जारी करा. एन्क्रिप्शन की वरील डेटा हॅकर्सच्या हातात गेल्यास पुनर्स्थित करणे आवश्यक आहे.

प्रमाणपत्र बदली

वैध SSL प्रमाणपत्रासह व्यवस्थापित नोड वापरकर्ता आणि सर्व्हर दरम्यान स्थापित केले आहे, सक्रियपणे रहदारी व्यत्यय आणत आहे. हा नोड वैध प्रमाणपत्र सादर करून कायदेशीर सर्व्हरची तोतयागिरी करतो आणि MITM हल्ला करणे शक्य होते.

मते संशोधन Mozilla, Google आणि बर्‍याच विद्यापीठांमधील संघ, नेटवर्कवरील सुमारे 11% सुरक्षित कनेक्‍शन लपवून ठेवतात. वापरकर्त्यांच्या संगणकांवर संशयास्पद रूट प्रमाणपत्रे स्थापित केल्यामुळे हा परिणाम आहे.

स्वतःचे रक्षण कसे करावे. विश्वसनीय सेवा वापरा SSL प्रदाता. तुम्ही सेवेचा वापर करून प्रमाणपत्रांची “गुणवत्ता” तपासू शकता प्रमाणपत्र पारदर्शकता (सीटी). क्लाउड प्रदाते इव्हस्ड्रॉपिंग शोधण्यात मदत करू शकतात; काही मोठ्या कंपन्या आधीच TLS कनेक्शनचे परीक्षण करण्यासाठी विशेष साधने ऑफर करतात.

संरक्षणाची दुसरी पद्धत नवीन असेल मानक ACME, जे SSL प्रमाणपत्रांची पावती स्वयंचलित करते. त्याच वेळी, ते साइटच्या मालकाची पडताळणी करण्यासाठी अतिरिक्त यंत्रणा जोडेल. याबद्दल अधिक आम्ही आमच्या मागील सामग्रीपैकी एकामध्ये लिहिले.

/फ्लिकर/ युरी सामोइलोव्ह / CC BY

HTTPS साठी संभावना

अनेक असुरक्षा असूनही, आयटी दिग्गज आणि माहिती सुरक्षा तज्ञांना प्रोटोकॉलच्या भविष्यावर विश्वास आहे. HTTPS च्या सक्रिय अंमलबजावणीसाठी वकिल WWW निर्माता टिम बर्नर्स-ली. त्यांच्या मते, कालांतराने TLS अधिक सुरक्षित होईल, ज्यामुळे कनेक्शनच्या सुरक्षिततेत लक्षणीय सुधारणा होईल. बर्नर्स-ली यांनी असे सुचवले भविष्यात दिसून येईल ओळख प्रमाणीकरणासाठी क्लायंट प्रमाणपत्रे. ते आक्रमणकर्त्यांपासून सर्व्हर संरक्षण सुधारण्यात मदत करतील.

मशीन लर्निंगचा वापर करून SSL/TLS तंत्रज्ञान विकसित करण्याचे देखील नियोजित आहे - दुर्भावनापूर्ण रहदारी फिल्टर करण्यासाठी स्मार्ट अल्गोरिदम जबाबदार असतील. HTTPS कनेक्शनसह, प्रशासकांकडे मालवेअरच्या विनंत्या शोधण्यासह, एन्क्रिप्टेड संदेशांची सामग्री शोधण्याचा कोणताही मार्ग नाही. आधीच आज, न्यूरल नेटवर्क 90% अचूकतेसह संभाव्य धोकादायक पॅकेट्स फिल्टर करण्यास सक्षम आहेत. (सादरीकरण स्लाइड 23).

निष्कर्ष

HTTPS वरील बहुतेक हल्ले हे प्रोटोकॉलमधील समस्यांशी संबंधित नसून कालबाह्य एन्क्रिप्शन यंत्रणेच्या समर्थनासाठी आहेत. IT उद्योग हळूहळू मागील पिढीचे प्रोटोकॉल सोडून देऊ लागला आहे आणि भेद्यता शोधण्यासाठी नवीन साधने देऊ करत आहे. भविष्यात, ही साधने अधिकाधिक बुद्धिमान होतील.

विषयावरील अतिरिक्त दुवे:

स्त्रोत: www.habr.com

HTTPS वरील संभाव्य हल्ले आणि त्यांच्यापासून संरक्षण कसे करावे