एक पारदर्शी एसएसएल प्रॉक्सी सेट करना

Question

मुझे पोर्ट 80 से गुजरने वाले ट्रैफ़िक का निरीक्षण करने के लिए 2 नेटवर्क कार्डों के साथ एक बॉक्स बॉक्स मिला है। एक कार्ड का उपयोग इंटरनेट से बाहर जाने के लिए किया जाता है, दूसरे को एक नेटवर्किंग स्विच से जोड़ा जाता है। बिंदु डिबगिंग उद्देश्यों के लिए उस स्विच पर झुके हुए सभी HTTP और HTTPS ट्रैफ़िक का निरीक्षण करने में सक्षम होने के लिए है।

मैंने iptables के लिए निम्नलिखित नियम लिखे हैं:

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

192.168.2.1:1337 को, मुझे रिकॉर्डिंग के लिए चार्ल्स ( http://www.charlesproxy.com/ ) का उपयोग करके पारदर्शी http प्रॉक्सी मिला है ।

पोर्ट 80 के लिए सब कुछ ठीक है, लेकिन जब मैं पोर्ट 1337 की ओर इशारा करते हुए पोर्ट 443 (एसएसएल) के लिए समान नियम जोड़ता हूं, तो मुझे चार्ल्स के माध्यम से अमान्य संदेश के बारे में एक त्रुटि मिलती है।

मैंने पहले चार्ल्स ( http://www.charlesproxy.com/documentation/proxying/ssl-proxying/ ) के साथ एक ही कंप्यूटर पर SSL प्रॉक्सी का उपयोग किया है , लेकिन किसी कारणवश इसे पारदर्शी तरीके से करने में असफल रहा है। कुछ संसाधन जो मैंने गुगले किए हैं वे कहते हैं कि यह संभव नहीं है - मैं इसे एक उत्तर के रूप में स्वीकार करने के लिए तैयार हूं यदि कोई समझा सकता है कि क्यों।

नोट के रूप में, मेरे पास वर्णित सेट तक पूरी पहुंच है, जिसमें सबनेट तक शामिल हैं - इसलिए मैं चार्ल्स द्वारा स्व-हस्ताक्षरित सेर्ट्स स्वीकार कर सकता हूं। सिद्धांत से समाधान के लिए चार्ल्स-विशिष्ट होना जरूरी नहीं है, कोई भी पारदर्शी प्रॉक्सी करेगा।

धन्यवाद!

संपादित करें: इसके साथ थोड़ा खेलने के बाद, मैं इसे एक विशिष्ट मेजबान के लिए काम करने में सक्षम था। जब मैं अपने iptables को संशोधित करता हूं (और रिवर्स प्रॉक्सी के लिए चार्ल्स में 1338 खोलता हूं):

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.2.1:1338
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 1338

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

मैं एक प्रतिक्रिया पाने में सक्षम हूं, लेकिन कोई गंतव्य होस्ट नहीं है। रिवर्स प्रॉक्सी में, अगर मैं केवल यह निर्दिष्ट करता हूं कि 1338 से सब कुछ एक विशिष्ट होस्ट के पास जाता है जिसे मैं हिट करना चाहता था, तो यह हैंड शेक ठीक से करता है और मैं संचार का निरीक्षण करने के लिए SSL प्रॉक्सी को चालू कर सकता हूं।

सेटअप आदर्श से कम है क्योंकि मैं नहीं चाहता कि 1338 से सब कुछ उस होस्ट को चला जाए - कोई भी विचार क्यों गंतव्य होस्ट छीन लिया जा रहा है?

एक बार फिर धन्यवाद

Comments

आप क्या विशिष्ट मुद्दे हैं? यह संभव है, क्योंकि आप उन प्रमाणपत्रों पर भरोसा कर रहे हैं जो इसे गतिशील रूप से उत्पन्न कर रहे हैं - यह एक MITM हो सकता है और संचार के सादे-पाठ को पकड़ सकता है, और कनेक्शन अभी भी ग्राहक द्वारा भरोसा किया जाना चाहिए।

— शेन झुंझलाना

मैंने अपनी पोस्ट को संपादित किया - मेरा मानना ​​है कि गंतव्य होस्ट छीन लिया जाता है

— बैडंक

Answer 1

आपके द्वारा देखे जा रहे समस्याएँ समान हैं जो एकल IP पते / पोर्ट (सर्वर नाम संकेतक का उपयोग किए बिना) पर कई प्रमाणपत्रों के उपयोग को रोकती हैं ।

सादे HTTP में, आपका पारदर्शी प्रॉक्सी बता सकता है कि कौन सा होस्ट क्लाइंट को Hostहेडर में देखकर कनेक्ट करना चाहता है ।

जब HTTPS MITM पारदर्शी प्रॉक्सी को अनुरोध मिलता है, तो यह पता नहीं चल सकता है कि क्लाइंट किस होस्ट का नाम पहली जगह में अनुरोध कर रहा था। (मुझे यकीन नहीं है कि यह इन नियमों के साथ आईपी पता प्राप्त कर सकता है, जिसने कम से कम इसे रिवर्स DNS लुकअप का उपयोग करके अनुमान लगाने की अनुमति दी हो सकती है, भले ही यह सामान्य मामले में काम करने की संभावना नहीं है।)

• अपेक्षित होस्ट नाम प्राप्त करने के लिए, MITM प्रॉक्सी को HostHTTP संदेश में हेडर पढ़ना होगा , जो एक सफल हैंडशेक के बाद ही हो सकता है।
• सफल हैंडशेक करने के लिए, MITM प्रॉक्सी को अपेक्षित होस्टनाम से मेल खाते हुए स्पूफ सर्टिफिकेट जेनरेट करना होता है।

परिणामस्वरूप, MITM प्रॉक्सी को यह पता नहीं चल सकता है कि कौन सा प्रमाणपत्र हैंडशेक से पहले जेनरेट करना है।

यह एक गैर-पारदर्शी MITM प्रॉक्सी के साथ काम कर सकता है, क्योंकि आप कम से कम HTTP CONNECTविधि के माध्यम से इच्छित होस्ट नाम प्राप्त करेंगे ।

Comments

यह मुझे बहुत धन्यवाद समझाया! मुझे लगता है कि मैं सही सवाल पूछना शुरू कर सकता हूं। हालांकि एक पारदर्शी एसएसएल प्रॉक्सी स्थापित करने के बारे में कोई कैसे जाएगा? हैंडशेक कैसा है?

— बैडंक

@badunk, मुझे नहीं लगता कि आप कर सकते हैं, जब तक कि आप क्लाइंट की ओर से सभी प्रमाणपत्र सत्यापन को अक्षम न करें।

— ब्रूनो

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

— ब्रूनो

mitmproxy एक HTTPS प्रॉक्सी है। आपको सभी प्रमाणपत्र सत्यापन को अक्षम करने की आवश्यकता नहीं है, लेकिन आपको mitmproxy प्रमाणपत्र स्थापित करना होगा क्योंकि इसका उपयोग सभी https कनेक्शन के लिए किया जाएगा।

— टायलर

Answer 2

इस विषय के बारे में कुछ बुनियादी जानकारी।

केवल कुछ डिवाइस हैं जो मुझे पता है कि इस कार्रवाई को सफलतापूर्वक खींच सकते हैं। हालाँकि वे वास्तव में आम जनता के लिए उपलब्ध नहीं हैं। मैं खुद एसएसएल ऑफलोडिंग के साथ एक फोर्टिनेट फोर्टजेट का उपयोग कर रहा हूं।

यह मूल रूप से क्या करता है; यह होस्ट में किए गए एसएसएल कनेक्शन को इंटरसेप्ट करता है और हार्डवेयर में कनेक्शन को डिक्रिप्ट करता है, फिर निरीक्षण करता है कि आप कहाँ जाना चाहते हैं और उस जानकारी के आधार पर फ़ायरवॉलिंग निर्णय लेता है।

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

इंटरनेट के उपयोग के बारे में कंपनी की नीतियों को लागू करने के लिए संगठनों में इस तरह के सेटअप का उपयोग किया जाता है। एक सक्रिय निर्देशिका का उपयोग करने के बाद से क्लाइंट को अपनी कंपनी को स्थापित करना आसान है, यह बड़े संगठनों के लिए कोई समस्या नहीं है।

SSL ट्रैफ़िक IS एन्क्रिप्टेड होने के बाद से आप मैन्युअल प्रॉक्सी बनाए बिना ही इसे कर सकते हैं। यह मूल रूप से एक MITM है, इसलिए किसी भी कानूनी मुद्दे को कवर करना महत्वपूर्ण है।

Answer 3

इस अन्य प्रश्न पर कुछ और सुझाव हैं जो आपने देखे होंगे: पारदर्शी SSL प्रॉक्सी मिथक और तथ्य । और यह लिंक है जो बताता है कि एक पारदर्शी एसएसएल प्रॉक्सी बनने के लिए स्क्वीड को कैसे कॉन्फ़िगर किया जाए। यह वह नहीं है जो आप खोज रहे हैं, लेकिन यह कम से कम आपको एक अंतर्दृष्टि दे सकता है कि क्या गलत हो सकता है।

Iptables के नियम ठीक लगते हैं, लेकिन मुझे कोई अंदाजा नहीं है कि अगर आप जिस प्रॉक्सी सॉफ्टवेयर का इस्तेमाल कर रहे हैं वह वही करने में सक्षम है जो आप करने की कोशिश कर रहे हैं। प्रलेखन निश्चित रूप से यह मामला होने का दावा करता है।

Answer 4

ब्रूनो के समाधान में जोड़ने के लिए, मैंने थोड़ी जांच की और साझा करना चाहा कि कैसे मुझे अभी तक एक और कम-से-आदर्श त्वरित फिक्स मिला।

उन iptables को सेट करने के बाद, मैं पोर्ट 1338 पर एक रिवर्स प्रॉक्सी लगा सकता हूं और इसे पोर्ट 1337 पर लोकलहोस्ट के पास भेज सकता हूं। चूंकि पोर्ट 1337 एक पारदर्शी http प्रॉक्सी है और डेटा डिक्रिप्ट हो गया है, यह होस्ट हेडर ले जाएगा और इसे गंतव्य बना देगा। मेज़बान।

मुख्य नकारात्मक पहलू यह है कि मैंने अनिवार्य रूप से http से http कनेक्शन को बदल दिया है - जो हमेशा हर सर्वर के साथ काम नहीं करता है (उस सुरक्षा छेद का उल्लेख नहीं करने के लिए जो मैं उस से उजागर कर रहा हूं)।

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

Comments

निश्चित रूप से मुझे समझ में नहीं आ रहा है, निश्चित रूप से, आप https://ग्राहक के दृष्टिकोण से उचित संबंध नहीं बना रहे हैं ?

— ब्रूनो