अपाचे: MITM- हमलों को रोकने के लिए विश्वास की SSL श्रृंखला को मान्य करें?


11

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

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

इस प्रकार, मेरा प्रश्न सरल है: मैं सर्वर साइड पर विश्वास की श्रृंखला को कैसे मान्य कर सकता हूं? मैं यह सुनिश्चित करना चाहता हूं कि ग्राहक मेरे सर्वर के प्रमाणपत्र और विश्वास की केवल एक श्रृंखला का उपयोग करे। मुझे आश्चर्य है कि क्या यह अपाचे के एसएसएल कॉन्फ़िगरेशन द्वारा प्राप्त किया जा सकता है? यह सुविधाजनक होगा क्योंकि इसे कई अनुप्रयोगों में आसानी से लागू किया जा सकता है। यदि यह संभव नहीं है, तो क्या किसी को PHP में ऐसा करने का तरीका पता है? या आपके पास कोई और सुझाव है?


1
यह ठीक है अगर नियोक्ता कर्मचारियों को यातायात देखता है। आप नियोक्ता के संसाधनों (पीसी, नेटवर्क कनेक्शन, आदि) का उपयोग कर रहे हैं, ये आपके नहीं हैं। और अगर आपको चिंता है कि एम्प्लियर आपके बैंकिंग खाते में आपके द्वारा प्रेषित डेटा को देख सकता है - तो इसे घर पर करें, काम पर नहीं। और कॉर्पोरेट सुरक्षा नीति का उल्लंघन करने का प्रयास आपके खिलाफ अदालत के लिए एक विषय हो सकता है।
Crypt32

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

2
अधिकांश (मेरे अनुभव में) अमेरिकी सरकार के स्वामित्व वाली कार्यस्थलों में हर लॉगिन पर ये दो नोटिस शामिल हैं: "संचार का उपयोग करना, या इस पर संग्रहीत डेटा, यह निजी नहीं है, नियमित निगरानी, ​​अवरोधन और खोज के अधीन हैं, और इसका खुलासा या उपयोग किया जा सकता है। किसी भी USG अधिकृत उद्देश्य के लिए। इस IS में USG हितों की रक्षा के लिए सुरक्षा उपाय (जैसे, प्रमाणीकरण और अभिगम नियंत्रण) शामिल हैं - आपके व्यक्तिगत लाभ या गोपनीयता के लिए नहीं। " इन प्रणालियों का उपयोग अक्सर एक हस्ताक्षरित समझौते द्वारा कवर किया जाता है जो समान है। मुख्य विवरण है सिस्टम का मालिक आपके खिलाफ खुद की रक्षा कर रहा है।
रान्डेल

यह अमेरिका और यूरोप के बीच कई अंतरों में से एक है। ऊपर उल्लिखित @Randall अधिकांश यूरोपीय देशों में अवैध हैं।
ऐलेरोन79

मेरे द्वारा उद्धृत शब्द अधूरे हैं, अन्य शर्तों की सूची गतिविधियों को स्पष्ट रूप से मॉनिटर नहीं किया जाना है। मुझे ऐसा कोई संदर्भ नहीं मिला जो बताता है कि यूरोपीय नियोक्ता अपने कंप्यूटर का उपयोग करने की शर्त नहीं लगा सकते हैं (मैं एक कंपनी के लिए काम करता हूं, जो यूरोप में काम करती है, ऐसी निगरानी प्रक्रियाएं स्थापित करती है, हालांकि मैं उस विभाजन के लिए काम करता हूं जो व्यापार नहीं कर रहा है यूरोप), लेकिन ऐसे संदर्भ पा सकते हैं जो सुझाव देते हैं कि ऐसे शब्द अवैध नहीं हैं जब तक कि वे स्पष्ट और पारदर्शी न हों।
रान्डेल

जवाबों:


9

मुझे लगता है कि यह सवाल security.stackexchange.com के लिए अधिक उपयुक्त होगा जहां MITM के विषय पर कई प्रश्नों पर चर्चा की जाती है। लेकिन वैसे भी:

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

एसएसएल अवरोधन के मामले में सर्वर के नजरिए से टीएलएस क्लाइंट एसएसएल इंटरसेप्टिंग फायरवॉल / एवी है। इस प्रकार सर्वर साइड में समस्या यह पता लगाना है कि यह अपेक्षित क्लाइंट (ब्राउज़र) से बात कर रहा है या नहीं (फ़ायरवॉल / एवी)। ऐसा करने का सबसे सुरक्षित तरीका क्लाइंट प्रमाण पत्र का उपयोग क्लाइंट को प्रमाणित करने के लिए है - और वास्तव में अगर ग्राहक प्रमाणीकरण का उपयोग किया जाता है तो SSL अवरोधन काम नहीं करेगा, यानी TLS हैंडशेक विफल हो जाएगा क्योंकि MITM अपेक्षित क्लाइंट प्रमाणपत्र प्रदान करने में सक्षम नहीं है।

केवल, क्लाइंट प्रमाणपत्र का उपयोग शायद ही कभी किया जाता है। इसके अलावा, एक असफल टीएलएस हैंडशेक का मतलब यह नहीं होगा कि क्लाइंट एसएसएल अवरोधन के बिना सर्वर से संवाद कर सकता है, लेकिन क्लाइंट सर्वर के साथ बिल्कुल भी संवाद नहीं कर सकता है। एक वैकल्पिक तरीका यह होगा कि टीएलएस हैंडशेक के फिंगरप्रिंट के आधार पर टीएलएस क्लाइंट के प्रकार का पता लगाने के लिए टीएचएस हेंडशेक का उपयोग किया जाए, यानी कि सिफर्स के प्रकार और ऑर्डर, विशिष्ट एक्सटेंशन का उपयोग ... जबकि सिद्धांत में एसएसएल इंटरसेप्टिंग प्रॉक्सी मूल रूप से हो सकता है। ClientHello पूरी तरह से सबसे अधिक नहीं है। यह भी देखें का पता लगाने मैन-इन-द-मिडल HTTPS के लिए सर्वर साइड पर या खंड तृतीय टीएलएस कार्यान्वयन Heuristics में HTTPS का अवरोधन की सुरक्षा प्रभाव


14

मेरे लिए, ऐसा प्रतीत होता है कि नियोक्ता कर्मचारी के एसएसएल ट्रैफ़िक पर जासूसी करने के लिए अपनी बेहतर स्थिति का उपयोग करता है। मेरे लिए, यह SSL अविश्वास की पूरी अवधारणा का प्रतिपादन करता है

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

सुरक्षा के दृष्टिकोण से यह आपके कार्य केंद्र से समझौता किया जाता है जो विश्वास की श्रृंखला को तोड़ता है जो सामान्य परिस्थितियों में एक MITM को सफल होने से रोकता है।

मैं सर्वर साइड पर विश्वास की श्रृंखला को कैसे मान्य कर सकता हूं?

आप नहीं कर सकते। वह ग्राहक पक्ष है।

आपके उपयोग के मामले के आधार पर आप RFC 7469 HTTP सार्वजनिक कुंजी पिनिंग कर सकते हैं जिसमें आपने ग्राहक को एक अतिरिक्त हेडर अपने वास्तविक एसएसएल प्रमाणपत्रों की सूची (हैश) या CA के उपयोग के साथ भेजा था।


4
HPKP मदद नहीं करेगा क्योंकि यह ब्राउज़रों द्वारा नजरअंदाज कर दिया जाएगा यदि प्रमाण पत्र पर स्पष्ट रूप से जोड़ा गया सीए द्वारा हस्ताक्षरित है। यह विशेष रूप से एक विश्वसनीय पार्टी, यानी एक कॉर्पोरेट फ़ायरवॉल या एक स्थानीय डेस्कटॉप AV (कई एसएसएल अवरोधन करते हैं) द्वारा एसएसएल अवरोधन की अनुमति देने के लिए किया जाता है।
स्टीफेन उलरिच

2
आप वहां बिल्कुल सही हैं: RFC से correct2.6: "यह स्थानीय नीति के अनुसार कुछ होस्ट के लिए पिन सत्यापन को अक्षम करने की अनुमति देने के लिए स्वीकार्य है। उदाहरण के लिए, एक UA पिन किए गए होस्ट के लिए पिन सत्यापन को अक्षम कर सकता है जिनकी मान्य श्रृंखला श्रृंखला समाप्त हो गई है। UA (या अंतर्निहित प्लेटफ़ॉर्म) में निर्मित ट्रस्ट एंकर के बजाय एक उपयोगकर्ता-परिभाषित ट्रस्ट एंकर। "
HBruijn

3

यह गलत तरीका है। नहीं सर्वर विश्वास की श्रृंखला की जाँच करता है। यह क्लाइंट है। तो इस कारण से कंपनी इस तरह से उपयोग करती है कि कंपनी को सुरक्षित करने के लिए और कर्मचारी अपने काम के समय में क्या कर रहा है, इसकी जांच करें।


खैर, हां, मुझे पता है कि इसे अकेले सर्वर साइड पर नहीं रोका जा सकता है। हालाँकि, कुछ क्लाइंट-साइड JS भी धोखा दे सकता है। BTW, कर्मचारियों पर जासूसी ज्यादातर यूरोपीय देशों में अवैध है। एक वेबसाइट ऑपरेटर के रूप में मैं अपने ग्राहकों को मूर्ख बनाने से रोकना चाहता हूं, इसलिए मुझे आश्चर्य है कि अगर कोई तरीका है तो मैं विश्वास की श्रृंखला को सुरक्षित तरीके से मान्य कर सकता हूं।
एथिलोन79

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

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

3
यह संभव नहीं है। जब क्लाइंट पर रूट प्रमाणपत्र बदल दिया गया है, तो आपके पास इसे जांचने का कोई तरीका नहीं है। सर्वर चेक नहीं बनाता है, क्लाइंट चेक बनाता है।
beli3ver

3

आप COULD (तरह का), लेकिन असली सवाल यह है कि आप क्या करना चाहिए

लेकिन सावधान रहना, यह apache.conf में एक ध्वज को बदलने के रूप में सरल कहीं नहीं है।

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

  • आप जावास्क्रिप्ट में टीएलएस को फिर से लागू कर सकते हैं , और यदि ग्राहक जुड़ा हुआ है तो आपकी वेबसाइट का प्रमाण पत्र है, तो अपनी जाँच करें।

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

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

इसके अलावा, चूंकि टीएलएस MiTM परदे के पीछे काम करने वाले व्यवसाय भी आमतौर पर क्लाइंट कंप्यूटर को पूरी तरह से नियंत्रित करते हैं, वे आसानी से स्क्रीन और कीगलर स्थापित कर सकते हैं जो उपयोगकर्ता द्वारा देखी गई हर चीज का वीडियो रिकॉर्ड करता है, और उपयोगकर्ता प्रकारों के सभी कीस्ट्रोक्स (और माउस आंदोलनों) को रिकॉर्ड करता है। आप देख सकते हैं, जब हमलावर है ग्राहक, वहाँ उसे मूर्ख नहीं पूरी तरह से सुरक्षित तरीका है। यह वास्तव में सिर्फ एक सवाल है कि वे कितना परेशान करने जा रहे हैं ... और ऊपर दिए गए कुछ समाधान आपके लिए काफी अच्छे हो सकते हैं।


" आप जावास्क्रिप्ट में टीएलएस को फिर से लागू कर सकते हैं " कैसे? कहाँ पे?
जिज्ञासु

@curiousguy कि पाठ qouted एक लिंक है - इस पर क्लिक करें, और यह आपको एक और प्रश्न और उत्तर की ओर ले जाएगा, और अंत में
डिजिटलबाजार

तो, यह कब प्रयोग करने योग्य है? किस उद्देश्य के लिए?
जिज्ञासु

कई अन्य चीजों के बीच @curiousguy, विशेष रूप से इस सर्वरफॉल्ट प्रश्न में पूछे गए उद्देश्यों के लिए। जब आपके पास क्लाइंट पर अपना JS TLS चल रहा होता है, तो उस ग्राहक JS को यह पता चल जाता है कि ग्राहक किस TLS सर्वर से जुड़ा है (और यह सार्वजनिक कुंजी है)। तब आप उस सार्वजनिक कुंजी को अधिकृत सर्वर सार्वजनिक कुंजी (आपके JS में हार्डकोड) के साथ तुलना कर सकते हैं, और यदि आपको पता चलेगा कि क्या वे समान हैं। यदि वे समान नहीं हैं, तो आपका कनेक्शन MiTM द्वारा अपहरण कर लिया गया है।
मतिजा नलिस
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.