एसएसएल और मैन-इन-द-मिड गलतफहमी

Question

मैंने इस समस्या से संबंधित दस्तावेज़ों के टन पढ़े हैं, लेकिन मुझे अभी भी सभी टुकड़े एक साथ नहीं मिल सकते हैं, इसलिए मैं कुछ प्रश्न पूछना चाहूंगा।

1. सबसे पहले मैं संक्षेप में प्रमाणीकरण प्रक्रिया का वर्णन करूंगा क्योंकि मैं इसे समझता हूं, क्योंकि मुझे उस संबंध में गलती हो सकती है: एक ग्राहक एक कनेक्शन शुरू करता है, जो एक सर्वर सार्वजनिक कुंजी, कुछ मेटाडेटा और एक के डिजिटल हस्ताक्षर के साथ प्रतिक्रिया करता है। विश्वसनीय प्राधिकारी। तब क्लाइंट निर्णय लेता है यदि वह सर्वर पर भरोसा करता है, तो सार्वजनिक कुंजी के साथ कुछ यादृच्छिक सत्र कुंजी को एन्क्रिप्ट करता है और इसे वापस भेजता है। यह सत्र कुंजी केवल सर्वर पर संग्रहीत निजी कुंजी के साथ डिक्रिप्ट की जा सकती है। सर्वर ऐसा करता है और फिर HTTPS सत्र शुरू होता है।

2. इसलिए, अगर मैं ऊपर सही हूं, तो सवाल यह है कि इस तरह के परिदृश्य में मानव-मध्य हमला कैसे हो सकता है? मेरा मतलब है, भले ही कोई व्यक्ति सार्वजनिक कुंजी के साथ सर्वर (जैसे www.server.com) प्रतिक्रिया को स्वीकार करता है और मेरे पास यह सोचने के लिए कुछ साधन हैं कि वह www.server.com है, वह अभी भी मेरे सत्र कुंजी को डिक्रिप्ट नहीं कर पाएगा निजी कुंजी के बिना।

3. पारस्परिक प्रमाणीकरण के बारे में बोलते हुए, क्या यह क्लाइंट पहचान के बारे में सर्वर विश्वास के बारे में है? मेरा मतलब है, ग्राहक पहले से ही सुनिश्चित हो सकता है कि वह सही सर्वर के साथ संचार कर रहा है, लेकिन अब सर्वर यह पता लगाना चाहता है कि ग्राहक कौन है, सही है?

4. और अंतिम प्रश्न पारस्परिक प्रमाणीकरण के विकल्प के बारे में है। यदि मैं वर्णित स्थिति में एक ग्राहक के रूप में कार्य करता हूं, तो क्या होगा अगर मैं एसएसएल सत्र स्थापित होने के बाद HTTP हेडर में एक लॉगिन / पासवर्ड भेजता हूं? जैसा कि मैंने इसे देखा, इस जानकारी को इंटरसेप्ट नहीं किया जा सकता क्योंकि कनेक्शन पहले से ही सुरक्षित है और सर्वर मेरी पहचान के लिए इस पर भरोसा कर सकता है। क्या मै गलत हु? पारस्परिक प्रमाणीकरण की तुलना में इस तरह के दृष्टिकोण के डाउनसाइड क्या हैं (केवल सुरक्षा मुद्दे महत्वपूर्ण हैं, कार्यान्वयन जटिलता नहीं)?

Answer 1

एसएसएल पर मैन-इन-द-बीच के हमले वास्तव में केवल तभी संभव हैं जब एसएसएल के किसी पूर्व शर्त को तोड़ दिया जाता है, यहां कुछ उदाहरण हैं;

• सर्वर कुंजी चोरी हो गई है - इसका मतलब है कि हमलावर सर्वर दिखाई दे सकता है, और क्लाइंट के लिए पता करने का कोई तरीका नहीं है।

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

• ग्राहक विश्वसनीय CA की अपनी सूची के विरुद्ध प्रमाणपत्र को सही ढंग से सत्यापित करने की जहमत नहीं उठाता - कोई भी CA बना सकता है। बिना किसी सत्यापन के, "बेन की कारें और प्रमाण पत्र" वेरीसाइन की तरह ही मान्य प्रतीत होंगे।

• क्लाइंट पर हमला किया गया है और एक नकली सीए को उसके विश्वसनीय रूट अधिकारियों में इंजेक्ट किया गया है - हमलावर को कोई भी ऐसा सर्टिफिकेट देने की अनुमति देता है जिसे वह पसंद करता है, और क्लाइंट उस पर भरोसा करेगा। मैलवेयर ऐसा करने के लिए जाता है उदाहरण के लिए आप नकली बैंकिंग साइटों पर पुनर्निर्देशित करते हैं।

विशेष रूप से # 2 बल्कि गंदा है, भले ही आप अत्यधिक विश्वसनीय प्रमाण पत्र के लिए भुगतान करते हैं, आपकी साइट किसी भी तरह से उस प्रमाण पत्र पर बंद नहीं होगी, आपको क्लाइंट के ब्राउज़र में सभी सीए पर भरोसा करना होगा क्योंकि उनमें से कोई भी एक नकली प्रमाण पत्र उत्पन्न कर सकता है। आपकी साइट जो बस के रूप में मान्य है। यह भी सर्वर या ग्राहक के लिए उपयोग की आवश्यकता नहीं है।

Comments

Sslstrip जैसे टूल भी हैं , जो http लिंक में https लिंक को पारदर्शी रूप से फिर से लिखने का प्रयास करेंगे।

— एमपॉन्टिलो

प्रमाणपत्र सत्यापन के बारे में एक और बात यह है कि क्लाइंट को होस्ट नाम सत्यापित करने की आवश्यकता है। यह जाँचने के लिए पर्याप्त नहीं है कि प्रमाण वास्तविक है, यह उस इकाई के लिए जारी किया जाना चाहिए जिससे आप बात करना चाहते हैं ( यहाँ और यहाँ देखें )। Sslstrip के रूप में, यह अंततः उपयोगकर्ता के लिए जाँच करने के लिए है कि वे दुर्भाग्य से SSL / TLS का उपयोग करना चाहते हैं (हालाँकि HSTS मदद कर सकता है)।

— ब्रूनो

क्या मैं एक क्रोम (या उस मामले के लिए कोई अन्य ब्राउज़र) प्लगइन लिख सकता हूं जो डेटा को इंटरसेप्ट करता है क्योंकि ब्राउज़र इसे एन्क्रिप्ट करता है?

— रोजी कासिम

एक और कारण "विश्वास का दुरुपयोग" है, जैसा कि TürkTrust मुद्दे में है।

— सेरेमसी

@ रिमूवर वास्तव में नहीं ... # 1 सर्वर पर निजी कुंजी है, जिसे वास्तविक सार्वजनिक कुंजी के साथ जोड़ा जाता है। इस परिदृश्य में आप वास्तविक सर्वर से बात करेंगे लेकिन कोई और बीच में आकर यातायात को डिक्रिप्ट कर सकता है। वे प्रमाणपत्र को संशोधित नहीं कर सकते। # 2 में एक "विश्वसनीय" सीए द्वारा जारी किया गया एक पूरी तरह से अलग प्रमाण पत्र भेजना शामिल है, जो ग्राहक के लिए वैध प्रतीत होगा। फिर हमलावर आपकी ओर से अनुरोधों को प्रॉक्सी कर सकता है और इस तरह से संदेश देख सकता है। दोनों में समझौता होता है लेकिन # 1 आपके नियंत्रण में है। # 2, दुर्भाग्य से, नहीं है।

— बेसिक

Answer 2

सबसे पहले मैं संक्षेप में प्रमाणिकता प्रक्रिया का वर्णन करूँगा क्योंकि मैं इसे समझता हूँ, शायद मैं उस कदम पर गलत हूँ। तो, एक ग्राहक एक कनेक्शन शुरू करता है और एक सर्वर सार्वजनिक कुंजी, कुछ मेटाडेटा और एक विश्वसनीय प्राधिकारी के डिजिटल हस्ताक्षर के साथ इसका जवाब देता है।

सर्वर X.509 प्रमाणपत्र श्रृंखला और अपनी निजी कुंजी के साथ हस्ताक्षरित एक डिजिटल हस्ताक्षर के साथ प्रतिक्रिया करता है।

तब क्लाइंट निर्णय लेता है यदि वह सर्वर पर भरोसा करता है

सही बात।

सार्वजनिक कुंजी के साथ कुछ यादृच्छिक सत्र कुंजी को एन्क्रिप्ट करता है और इसे वापस भेजता है।

नहीं। क्लाइंट और सर्वर एक आपसी सत्र कुंजी निर्माण प्रक्रिया में संलग्न हैं, जिससे सत्र कुंजी स्वयं कभी भी प्रसारित नहीं होती है।

यह सत्र कुंजी केवल सर्वर पर संग्रहीत निजी कुंजी के साथ डिक्रिप्ट की जा सकती है।

नहीं।

सर्वर ऐसा करता है

नहीं।

और फिर HTTPS सत्र शुरू होता है।

TLS / SSL सत्र शुरू होता है, लेकिन वहाँ अधिक कदम पहले कर रहे हैं।

इसलिए, यदि मैं ऊपर सही हूं, तो सवाल यह है कि इस तरह के परिदृश्य में मानव-मध्य हमला कैसे हो सकता है?

सर्वर के रूप में और SSL समापन बिंदु के रूप में कार्य करके। ग्राहक को किसी भी प्राधिकरण कदम को छोड़ना होगा। अधिकांश HTTPS सत्रों में केवल एकमात्र प्राधिकरण चरण होस्टनाम चेक है।

मेरा मतलब है कि भले ही कोई व्यक्ति सार्वजनिक कुंजी के साथ सर्वर (जैसे www.server.com) प्रतिक्रिया को स्वीकार करता है और फिर कुछ तरीकों से मुझे लगता है कि वह www.server.com है, वह अभी भी मेरे सत्र कुंजी को डिक्रिप्ट नहीं कर पाएगा निजी कुंजी के बिना।

ऊपर देखो। डिक्रिप्ट करने के लिए कोई सत्र कुंजी नहीं है। एसएसएल कनेक्शन स्वयं सुरक्षित है, यह वह है जो आप से बात कर रहे हैं वह सुरक्षित नहीं हो सकता है।

पारस्परिक प्रमाणीकरण के बारे में बोलते हुए, क्या यह क्लाइंट पहचान के बारे में सर्वर विश्वास के बारे में है? मेरा मतलब है कि ग्राहक पहले से ही सुनिश्चित हो सकता है कि वह सही सर्वर के साथ संचार कर रहा है, लेकिन अब सर्वर यह पता लगाना चाहता है कि ग्राहक कौन है, है ना?

सही बात।

और अंतिम प्रश्न पारस्परिक प्रमाणीकरण के विकल्प के बारे में है। यदि मैं वर्णित स्थिति में एक ग्राहक के रूप में कार्य करता हूं, तो क्या होगा अगर मैं एसएसएल सत्र स्थापित होने के बाद HTTP हेडर में एक लॉगिन / पासवर्ड भेजता हूं? जैसा कि मैं देख रहा हूं, इस जानकारी को इंटरसेप्ट नहीं किया जा सकता क्योंकि कनेक्शन पहले से ही सुरक्षित है और सर्वर मेरी पहचान के लिए इस पर भरोसा कर सकता है। क्या मै गलत हु?

नहीं।

पारस्परिक प्रमाणीकरण की तुलना में इस तरह के दृष्टिकोण के डाउनसाइड क्या हैं (केवल सुरक्षा मुद्दे महत्वपूर्ण हैं, कार्यान्वयन जटिलता नहीं)?

यह केवल उपयोगकर्ता नाम / पासवर्ड के रूप में सुरक्षित है, जो एक निजी कुंजी की तुलना में लीक करना बहुत आसान है।

Comments

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

— वादिम चेकरी

@VadimChekry पूर्व-मास्टर रहस्य सत्र कुंजी नहीं है। यह सत्र कुंजी उत्पन्न करने के लिए उपयोग किए गए डेटा के कई टुकड़ों में से एक है, स्वतंत्र रूप से दोनों सिरों पर। प्रक्रिया आरएफसी 2246. में वर्णन किया गया

— लोरने की मारकिस

@ क्रिस आप बहुत कम असुरक्षित हैं, हालांकि आईपी एड्रेस स्पूफिंग संभव है। स्वयं प्रमाण पत्र में सहकर्मी की पहचान की जांच करने के लिए कोई विकल्प नहीं है।

— लोर्ने

+1 यह काफी अच्छा जवाब है, अधिकांश भाग के लिए। हालांकि, कुछ बिंदुओं में एक-शब्द प्रतिक्रियाओं के साथ स्पष्टीकरण का अभाव है। यदि आप विस्तार करना चाहते हैं और / या उक्त बिंदुओं पर विस्तार कर सकते हैं, तो इसका एक निश्चित उत्तर दे सकते हैं (अर्थात इसके बजाय, "नहीं।" आप संक्षेप में उल्लेख कर सकते हैं कि वास्तव में क्या होता है।) मुख्य शरीर में। यह वास्तव में कुछ चीजें स्पष्ट करेगा। धन्यवाद।

— आवाज

@ tjt263 पहला 'नहीं' वास्तव में क्या होता है की व्याख्या प्रदान करता है। अगले दो 'नहीं' में उसी गलत धारणा का उल्लेख है जिसने पहले 'नहीं' का निर्माण किया था, और इसकी एक ही व्याख्या है। अगला और अंतिम 'नहीं' 'मैं गलत हूं' को संदर्भित करता है और यह ओपी से उद्धृत जानकारी को संदर्भित करता है। इसलिए यह कठिन है कि जो आप सोचते हैं वह वास्तव में यहां गायब है।

— लोर्न

Answer 3

क्लाइंट और सर्वर के बीच की सड़क पर कोई भी व्यक्ति https पर बीच में हमले कर सकता है। यदि आपको लगता है कि यह संभावना नहीं है या दुर्लभ है, तो विचार करें कि ऐसे व्यावसायिक उत्पाद हैं जो एक इंटरनेट गेटवे पर सभी ssl ट्रैफ़िक को व्यवस्थित रूप से डिक्रिप्ट, स्कैन और पुनः एन्क्रिप्ट करते हैं। । वे क्लाइंट को "वास्तविक" एसएसएल प्रमाण पत्र से कॉपी किए गए विवरण के साथ एक एसएलएल प्रमाण पत्र भेजकर काम करते हैं, लेकिन एक अलग प्रमाण पत्र श्रृंखला के साथ हस्ताक्षर किए गए। यदि यह श्रृंखला ब्राउज़र के किसी विश्वसनीय सीए के साथ समाप्त हो जाती है, तो यह MITM उपयोगकर्ता के लिए अदृश्य हो जाएगा। इन उत्पादों को मुख्य रूप से कंपनियों को "सुरक्षित" (पुलिस) कॉर्पोरेट नेटवर्क को बेचा जाता है, और इसका उपयोग उपयोगकर्ताओं के ज्ञान और आश्वासन के साथ किया जाना चाहिए। तकनीकी रूप से, हालांकि, ISPs या किसी अन्य नेटवर्क वाहक द्वारा उनके उपयोग को रोक नहीं है। (एनएसए को मान लेना सुरक्षित होगा में कम से कम एक विश्वसनीय रूट CA साइनिंग कुंजी है )।

यदि आप पृष्ठ की सेवा कर रहे हैं, तो आप एक HTTP शीर्ष लेख शामिल कर सकते हैं जो यह दर्शाता है कि पृष्ठ के साथ किस सार्वजनिक कुंजी पर हस्ताक्षर होना चाहिए। यह उपयोगकर्ताओं को उनके "सुरक्षित" कनेक्शन के MITM को सचेत करने में मदद कर सकता है, लेकिन यह एक विश्वास-पर-पहली-उपयोग तकनीक है। यदि बॉब के पास पहले से "वास्तविक" सार्वजनिक कुंजी पिन का रिकॉर्ड नहीं है, तो मॉलोरी सिर्फ दस्तावेज़ में पीपीके हेडर को फिर से लिखता है। इस तकनीक (एचपीकेपी) का उपयोग करने वाले वेब साइटों की सूची बेहद कम है। इसमें उनके क्रेडिट में Google और ड्रॉपबॉक्स शामिल हैं। आमतौर पर, एचटीकेपी का उपयोग करने वाले कुछ बड़े विश्वसनीय साइटों से एक https- इंटरसेप्टिंग गेटवे पृष्ठों के माध्यम से लहर जाएगा। यदि आप एक HPKP त्रुटि देखते हैं जब आपकी उम्मीद नहीं है, तो सावधान रहें।

पासवर्ड के बारे में, https कनेक्शन पर सबकुछ https द्वारा सुरक्षित किया जाता है, डोमेन नाम को छोड़कर, जिसे स्पष्ट होने की आवश्यकता होती है ताकि अनुरोध को रूट किया जा सके। सामान्य तौर पर, यह सलाह दी जाती है कि क्वेरी स्ट्रिंग में पासवर्ड न डालें, जहां वे लॉग, बुकमार्क आदि में घूम सकते हैं, लेकिन जब तक कि https समझौता नहीं किया जाता है, तब तक क्वेरी स्ट्रिंग दिखाई नहीं देता।

Comments

लेकिन इसका मतलब यह है कि यह MITM उपकरण (वह जो डिक्रिप्ट / स्कैन करता है और ट्रैफ़िक को फिर से एनक्रिप्ट करता है) को विश्वसनीय CA में से किसी एक तक पहुंच की आवश्यकता है? (सर्वर प्रमाणपत्र को "नकली" करने के लिए)। ऐसा कहते हैं। फिर कोई इसका पर्दाफाश करता है, यह जानकारी सार्वजनिक हो जाती है, और अध्यक्ष में कोई घोटाला हो जाएगा और सीए प्रमाण पत्र को सभी ब्राउज़रों से हटा दिया जाएगा? मेरा मतलब है, आदर्श रूप से ...

— jazzcat

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

— bbsimonbb

काम पर एक सहकर्मी सीमित समझ का उपयोग कर रहा था कि ये कॉर्पोरेट नेटवर्क MITM तकनीकें SSL को बाध्य करने के लिए Google के लिए एक बुरा विचार क्यों हैं - क्या वह वास्तव में शुद्धता का एक ढलान हो सकता है?

— EmixixTeen

क्षमा करें, मुझे सवाल समझ में नहीं आया!

— bbsimonbb

Answer 4

1. सही बात
2. इतना सही नहीं है। उस तरह के हमले में itermediate सर्वर को आपका अनुरोध मिलता है और वह आपकी ओर से गंतव्य को भेज देता है। और फिर परिणाम के साथ आप का जवाब। वास्तव में यह मानव-में-मध्य सर्वर है जो आपके साथ सुरक्षित संबंध बनाता है न कि वास्तविक सर्वर जिसका आप इरादा करते हैं। यही कारण है कि आप हमेशा प्रमाण पत्र की जाँच करें मान्य और विश्वसनीय है।
3. सही हो सकता है
4. यदि आप सुनिश्चित हैं कि सुरक्षित कनेक्शन पर भरोसा है, तो उपयोगकर्ता नाम / पासवर्ड भेजने के लिए सुरक्षित होगा।

Comments

2 के बारे में - मैं मान रहा हूं कि क्लाइंट कनेक्शन स्थापना की प्रक्रिया के दौरान सर्वर द्वारा भेजे गए मेटाडेटा की पूरी तरह से जांच कर रहा है और क्लाइंट को सभी प्रमाणपत्रों पर भरोसा नहीं है। तो क्या ऐसा परिदृश्य संभव नहीं होगा अगर - क) एक ग्राहक वह नहीं कर रहा है जो मैंने ऊपर कहा था, या ख) एक आदमी को बीच में कहीं विश्वसनीय सीए द्वारा हस्ताक्षरित प्रमाण पत्र मिला है?

— वादिम चेकरी

यह बहुत कम होता है कि मध्यवर्ती सर्वर वैध प्रमाण पत्र भेजता है, पिछले साल यह कोमोडो सीए के साथ खुश था अगर मुझे अच्छी तरह से याद है। लेकिन आम तौर पर अगर यह एक विश्वसनीय कनेक्शन है तो यह पूरी तरह से सुरक्षित है।

— बॉय्नक्स

Answer 5

सत्र कुंजी के बारे में भाग को छोड़कर आपने जो कुछ भी कहा है वह सही है। सीए की बात एक आदमी के बीच में हमले को हराने के लिए है - बाकी सब कुछ एसएसएल द्वारा ही किया जाता है। क्लाइंट प्रमाणीकरण उपयोगकर्ता नाम और पासवर्ड योजना का एक विकल्प है।