HTTPS

Question

के लिए सामान्य नाम की जांच को निष्क्रिय करने के सुरक्षा निहितार्थ मैं कुछ क्लाइंट कोड मैं HTTPS पर सुरक्षित संचार करने के लिए विरासत में मिला लिया है से अधिक जा रहा हूँ, और यह है कि यह सर्वर प्रमाणपत्र में आम नाम की जाँच नहीं कर रहा है (उदाहरण के लिए लगता है। ' अनुरोध किए जा रहे वास्तविक यूआरएल के खिलाफ सीएन = "example.com"। यह शायद जानबूझकर है, क्योंकि हमारे क्लाइंट ऐप को विभिन्न परिवेशों से बात करने की आवश्यकता है, इसलिए प्रारंभिक पोर्टल (उदाहरण के लिए example.com/main) से संपर्क करने के बाद और उपयोगकर्ता एक पर्यावरण चुनते हुए ऐप को एक विशिष्ट आईपी पर रीडायरेक्ट किया जाता है, इसलिए सभी भविष्य के अनुरोध कुछ दिखते हैं जैसे "http://127.0.0.1/page"

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

धन्यवाद

Answer 1

"कस्टम DNS सेटिंग्स" के साथ हमलावर एक ही बात करने के लिए एक DNS सर्वर का फायदा उठाने चाहिए (तुम्हारा या एक ग्राहक के) के रूप में बस को कॉपी करने का विरोध किया, एक आईपी वह नियंत्रित करने के लिए बात करने के लिए example.com प्रमाण पत्र। यदि संभव हो तो मैं example.com के सबडोमेन के रूप में सभी विशिष्ट ऐप्स बनाउंगा और सीएन को प्रमाणित करने में सक्षम होने के लिए वाइल्डकार्ड प्रमाणपत्र (* .example.com) का उपयोग करूंगा।

Answer 2

कोई और सिर्फ आपके प्रमाण पत्र की प्रतिलिपि नहीं बना सकता है और इसका उपयोग नहीं कर सकता क्योंकि उनके पास आपकी निजी कुंजी नहीं है।

आप चेक नहीं करते हैं कि प्रमाण पत्र के सीएन तो वे केवल अपने स्वयं के प्रमाणपत्र बना सकता है डोमेन नाम से मेल नहीं करता है (और यह एक विश्वस्त CA तो यह वैध लग रहा है द्वारा हस्ताक्षर किए हैं), तुम्हारा के स्थान पर इसका इस्तेमाल करते हैं , और मध्य हमले में एक आदमी प्रदर्शन करते हैं।

इसके अलावा, आपको यह जांचने की आवश्यकता है कि प्रमाण पत्र एक विश्वसनीय सीए से आता है। यह सुनिश्चित करने के लिए सीए का काम है कि आप केवल सीएन = के साथ प्रमाण पत्र प्राप्त कर सकते हैं यदि आप वास्तव में उस डोमेन को नियंत्रित करते हैं।

यदि आप इनमें से किसी भी चेक को छोड़ देते हैं तो आपको एमआईटीएम हमले का खतरा होता है।

एक अलग दृष्टिकोण है कि आप ग्राहक से अधिक पर्याप्त नियंत्रण है अगर काम करेंगे के लिए भी this answer देखें।

Answer 3

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

यदि आप ग्राहक कोड को नियंत्रित नहीं करते हैं, तो एक विश्वसनीय सीए द्वारा हस्ताक्षरित एक प्रमाणपत्र आपके लिए प्रतिस्थापित किया जा सकता है।

Answer 4

होस्टनाम सत्यापन (सीएन भाग की पुष्टि करने) की गारंटी देता है कि कनेक्शन (सर्वर) के दूसरे छोर डोमेन नाम आप पता बार में टाइप के साथ एक SSL प्रमाणपत्र मुद्दों कर रहा है। आम तौर पर एक हमलावर ऐसा प्रमाण पत्र प्राप्त करने में सक्षम नहीं होगा।

आप सत्यापित नहीं करते हैं होस्टनाम हिस्सा है, किसी को (किसी राउटर या प्रॉक्सी अनुरोध हालांकि गुजरता में से किसी पर बैठते) मध्यम हमले में एक आदमी कर सकता है। या कोई कुछ DNS हमलों का फायदा उठा सकता है।

Answer 5

$ 0.02: होस्ट नाम के लिए सीएन का उपयोग कर हटा दिया गया है, 509 विषय वैकल्पिक नाम के बजाय इस्तेमाल किया जाना चाहिए।

Answer 6

• प्रमाण पत्र स्वयं सत्यापित करना और इसे एक सीए प्रमाण पत्र में बंधे जा सकते हैं जिसे आप पहले से भरोसा करते हैं, यह जांचने की अनुमति देता है कि प्रमाण पत्र वास्तविक और मान्य है।
• सर्टिफिकेट में होस्ट नाम की जांच करने से आप यह जांचने की अनुमति देते हैं कि आप जिस सर्वर से बात करना चाहते हैं उसके साथ बात कर रहे हैं, बशर्ते आपने प्रमाण पत्र को वास्तव में सत्यापित किया हो। (। जाँच हो रही है कि दूरदराज के पक्ष वास्तव में एक है कि प्रमाण पत्र के लिए निजी कुंजी धारण SSL/TLS हैंडशेक के भीतर किया जाता है)

आप पासपोर्ट/आईडी लोगों के लिए जाँच के साथ एक सादृश्य चाहते हैं:

• प्रमाण पत्र सत्यापित करना यह जांचना है कि पासपोर्ट या आईडी का एक रूप वास्तविक है। आप तय कर सकते हैं कि आप किस प्रकार के आईडी को किसी व्यक्ति से स्वीकार करना चाहते हैं (जैसे पासपोर्ट, ड्राइविंग लाइसेंस, स्टाफ कार्ड, ...) और कौन से जारीकर्ता देशों को आप भरोसा करते हैं ताकि वे अपनी प्रामाणिकता को सत्यापित कर सकें।
• यह जांचकर कि रिमोट पार्टी निजी कुंजी रखने वाला व्यक्ति है, यह जांचने के समान है कि पासपोर्ट/आईडी पर चित्र आपके सामने व्यक्ति के चेहरे से मेल खाता है।
• होस्ट नाम की जांच करना पासपोर्ट की जांच करना है, जिस व्यक्ति का नाम वह है जिसे आप ढूंढ रहे हैं।

यदि आप होस्ट नाम की जांच नहीं करते हैं, तो वैध पासपोर्ट वाला कोई भी व्यक्ति जो आप वास्तविक मानते हैं, वह आपके पास आ सकता है और दावा कर सकता है कि वे वह हैं जिसे आप ढूंढ रहे हैं (नाम से)।

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

यह जांचकर कि पासपोर्ट में नाम उस व्यक्ति के नाम से मेल खाता है जिसे आप ढूंढ रहे हैं उसे सामान्य ज्ञान माना जाएगा; प्रमाण पत्र के लिए भी करो। ऐसा नहीं करने वाले किसी भी ऐसे प्रमाणपत्र की अनुमति देता है जिस पर आप भरोसा करते हैं कि आप किसी भी अन्य प्रमाण पत्र का प्रतिरूपण करने के लिए वास्तविक मानते हैं, जिससे संभावित रूप से एमआईटीएम हमले किए जाते हैं।

HTTPS होस्ट नाम सत्यापन नियम RFC 2818 Section 3.1 (हाल ही में "सर्वोत्तम प्रथाओं" spec, RFC 6125 में परिभाषित किए गए हैं, अभी तक बहुत अधिक लागू नहीं किए गए हैं)।

संक्षेप में, होस्ट का नाम विषय वैकल्पिक नाम DNS प्रविष्टि में होना चाहिए (हालांकि आप विषय डीएन के सीएन पर वापस आ सकते हैं जहां प्रमाण पत्र में कोई SAN नहीं है)। जब आप एक आईपी पता का उपयोग कर रहे हैं, तो आईपी पता SAN आईपी-एड्रेस एंट्री में होना चाहिए (हालांकि कुछ ब्राउज़र आपको विषय डीएन के सीएन में आईपी पते से दूर जाने देंगे)।