अविश्वसनीय के लिए क्रिप्टो पत्राचार

सावधानी: इस पोस्ट के कारण व्यामोह का कम प्रकोप हो सकता है

नमस्ते! क्या आप सुरक्षित पत्राचार के लिए लोकप्रिय उत्पादों पर विश्वास नहीं करते हैं जिस तरह से मैं उन पर विश्वास नहीं करता हूं? उदाहरण के लिए, ब्राउज़र में क्रिप्टोकरेंसी क्लाइंट साइड पर एन्क्रिप्शन के साथ, या पी 2 क्रिप्टो मैसेंजर में?

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

प्रविष्टि

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

दुर्भाग्य से, लोग गलती करते हैं। उदाहरण के लिए, सेवा, "सुरक्षित चैट" और "क्रिप्टो चैट" अनुरोधों के लिए Google लिंक द्वारा पहला, जिसे क्रिप्टोकैट कहा जाता है। लगभग तीन महीने पहले, उनके कोड में एक त्रुटि का पता चला था - यादृच्छिक संख्या जनरेटर के अपर्याप्त रूप से अच्छे कार्यान्वयन के कारण, समूह संदेश जो 17 अक्टूबर 2011 और 15 जून 2013 के बीच प्रेषित किए गए थे, डिक्रिप्टोकैट को डिक्रिप्ट करना संभव हो गया। इसके अलावा, 2013 की शुरुआत में, वेराकोड ने उस कोड का ऑडिट किया, जिसने उसे "100/100 का सुरक्षा गुणवत्ता स्कोर" प्रदान किया, और यह इस अवधि के दौरान कोड का एकमात्र ऑडिट नहीं था।

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

OpenSSL के बारे में

ओपनएसएसएल एक खुला स्रोत पुस्तकालय है जो एसएसएल / टीएलएस प्रोटोकॉल को लागू करता है। वे हर बार HTTPS के माध्यम से साइट पर जाने के लिए उपयोग किए जाते हैं। इस बारे में हाल ही में एक लेख आया था।

यहां 10 वर्ष से अधिक के विश्लेषण में ओपनएसएसएल में पाई गई कमजोरियों की एक सूची है ।

ओपनएसएसएल का उपयोग करने वाले कार्यक्रमों की एक आंशिक सूची: अपाचे, नग्नेक्स, स्क्वीड, ओपनवीपीएन, ओपनश, एनटीपी, डीएचसीपी, कप, सिसालॉग-एनजी, एक्सगॉर-सर्वर, पीएचपी, पाइजन, रूबी, लिबेवेंट, नोडल, कर्ल, विंग, लिंक, लिनेक्स। सोसैट, होस्टैप्ड, wpa_supplicant, virtualbox, vmware-player, libreoffice, ffnpeg।

और टीएलएस के बारे में काफी कुछ। टीएलएस एक क्रिप्टोग्राफिक प्रोटोकॉल है जो आपको सुरक्षित कनेक्शन स्थापित करने की अनुमति देता है। अब इस प्रोटोकॉल के 3 संस्करण हैं: 1.0, 1.1 और 1.2। क्रमशः वर्णित हैं, क्रमशः rfc 2246 में , rfc 4346 और rfc 5246 । यह मजेदार है कि वे सभी 46 में समाप्त होते हैं। हम संस्करण 1.0 का उपयोग करेंगे क्योंकि यह 1999 में जारी किया गया था और इसमें कोई गंभीर भेद्यता नहीं पाई गई थी।

प्रोटोकॉल बहुत पेचीदा है। प्रक्रिया बहुत सरल है: पार्टियां सममित एन्क्रिप्शन के लिए एक कुंजी पर सहमत होती हैं और बाद में इसका उपयोग करती हैं। सभी संदेश एक गुप्त कुंजी ( HMAC ) के साथ हैश फ़ंक्शन के संयोजन द्वारा परिवर्तन / प्रतिस्थापन से सुरक्षित हैं। प्रोटोकॉल सर्वर और क्लाइंट के पारस्परिक प्रमाणीकरण के लिए भी प्रदान करता है

टीएलएस के पूर्ण कार्यान्वयन के अलावा, ओपनएसएसएल पुस्तकालय में कई क्रिप्टोग्राफिक और गणितीय एल्गोरिदम शामिल हैं और एक कंसोल इंटरफ़ेस है।


यह इस इंटरफ़ेस है जिसे हम अपने कार्य के लिए उपयोग करेंगे। चलो व्यापार के लिए नीचे उतरो।

सरल विकल्प

पहला वार्ताकार (एक "सफेद" आईपी के साथ, चलो इसे "सर्वर" कहते हैं):

 openssl s_server -accept 4433 -nocert -cipher ADH-AES256-SHA -tls1 -no_ticket 

दूसरा वार्ताकार, ग्राहक, प्रदर्शन करता है:

 openssl s_client -connect <host>:4433 -cipher ADH-AES256-SHA -tls1 -no_ticket 

हमने अभी क्या किया है? पहला कमांड हमने tls 1.0 सर्वर लॉन्च किया, और दूसरा - इससे जुड़ा। अब आप संवाद कर सकते हैं, सभी संदेशों को एईएस 256 एल्गोरिथ्म का उपयोग करके एन्क्रिप्ट किया गया है, एन्क्रिप्शन कुंजी को डिफी-हेलमैन (डीएच) एल्गोरिथ्म का उपयोग करके बातचीत की जाती है । यहां पांच मिनट का एक शानदार वीडियो है जो इसके सार को समझा रहा है। डीएच एल्गोरिथ्म आपको असुरक्षित संचार चैनल का उपयोग करके एक साझा गुप्त कुंजी प्राप्त करने की अनुमति देता है।

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

MITM से सुरक्षा

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

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

सर्वर पर हम निष्पादित करते हैं:

 openssl genrsa -out server.key 2048 openssl req -new -key server.key -batch -days 3650 -x509 -out server.crt 

ग्राहक पर:

 openssl genrsa -out client.key 2048 openssl req -new -key client.key -batch -days 3650 -x509 -out client.crt 

यहां, 2048 निजी कुंजी मॉड्यूल में बिट्स की संख्या है, 3650 दिनों में प्रमाणपत्र वैधता अवधि है।

फिर सर्वर को क्लाइंट को अपना सर्टिफिकेट (server.crt फाइल), और क्लाइंट (client.crt फाइल) को सर्वर में ट्रांसफर करना होगा। यह एक कमजोर बिंदु है, क्योंकि एक हमलावर स्थानांतरण के समय प्रमाण पत्र को बदल सकता है (यदि वह इसे पढ़ता है, तो ठीक है)। इसलिए, कई चैनलों (पास्टबिन, ईमेल, स्काइप, जैबर, एसएमएस, वॉइस ओवर फोन, रूसी पोस्ट, एक ब्लॉग पर बिल्ली के बच्चे की फोटो में स्टेग्नोग्राफ़ी, आदि) का उपयोग करके इसे प्रसारित करना बेहतर है। एक बार प्रमाण पत्र स्थानांतरित करें।

उसके बाद, TLS सर्वर बनाने की कमांड इस तरह दिखाई देगी:

 openssl s_server -accept 4433 -cert server.crt -key server.key -Verify 0 -CAfile client.crt -cipher DHE-RSA-AES256-SHA -tls1 -no_ticket 

सर्वर से कनेक्शन:

 openssl s_client -connect <host>:4433 -cert client.crt -key client.key -verify 0 -CAfile server.crt -cipher DHE-RSA-AES256-SHA -tls1 -no_ticket 

अब सर्वर और क्लाइंट एक दूसरे को प्रमाणित करने में सक्षम होंगे।

महत्वपूर्ण: यदि प्रमाणीकरण सफल नहीं था, तो न तो सर्वर और न ही क्लाइंट डिस्कनेक्ट होगा! वे केवल त्रुटि के बारे में लिखेंगे। दुर्भाग्य से, कोई कुंजी नहीं है जो इस व्यवहार को बदल देगी, इसलिए आपको कनेक्शन लॉग को ध्यान से देखने की आवश्यकता है। त्रुटि कुछ इस तरह दिखती है:

 verify error:num=18:self signed certificate 

हम मानते हैं कि हमने MITM समस्या को हल कर दिया है, यह समझना बाकी है कि समस्याओं का हल कैसे किया जाए 2) और 3)। यहां SSH प्रोटोकॉल हमारी मदद करेगा।

बचाव के लिए एस.एस.एच.

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

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

प्रोटोकॉल की एक विशेषता यह है कि यह आपको सुरक्षित सुरंग बनाने की अनुमति देता है। हम इसका फायदा उठाएंगे!

सर्वर पर हम निष्पादित करते हैं:

 ssh -c aes256-cbc -m hmac-sha1-96 -o KexAlgorithms=diffie-hellman-group-exchange-sha1 -R 4433:127.0.0.1:4433 user@sshhost nc -l -p 4433 -v 

यहां, मन की शांति के लिए, हम स्पष्ट रूप से एन्क्रिप्शन, कुंजी विनिमय और हैशिंग एल्गोरिदम निर्दिष्ट करते हैं। -R स्विच का मतलब है कि ssh सर्वर के 4433 पोर्ट के सभी कनेक्शन एन्क्रिप्टेड ssh टनल में जाएंगे और उसी पोर्ट पर ssh क्लाइंट में जाएंगे। यदि उपयोगकर्ता के पास शेल के रूप में स्थापित / sbin / nologin है, तो यह कभी-कभी -N स्विच का उपयोग करने में मदद करता है, जो ssh क्लाइंट को सर्वर पर किसी भी कमांड को निष्पादित नहीं करने के लिए कहता है, लेकिन केवल एक सुरंग बनाने के लिए।

ग्राहक हमारे प्रदर्शन पर:

 ssh -c aes256-cbc -m hmac-sha1-96 -o KexAlgorithms=diffie-hellman-group-exchange-sha1 -L 4433:127.0.0.1:4433 user@sshhost nc 127.0.0.1 4433 

अब, यदि क्लाइंट पोर्ट 4433 पर 127.0.0.1 पर खुद को कनेक्ट करता है, तो ssh क्लाइंट सुरक्षित टनल के माध्यम से रिमोट मशीन के 4433 पोर्ट के लिए कनेक्शन को प्रॉक्सी करेगा, और वहां से, डेटा एन्क्रिप्ट किया जाएगा और एक अन्य टनल से होकर सर्वर मशीन तक जाएगा।

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

क्या बुरा है? हम ssh सर्वर पर भरोसा नहीं कर सकते! सैद्धांतिक रूप से, वह डिक्रिप्टेड डेटा को अपने लॉग-इन के पुनः एन्क्रिप्शन के क्षण में लिख सकता है, जब वे एक सुरंग से दूसरी में गिरते हैं।

SSH + OpenSSL या हमें गहराई तक जाना होगा

अब SSH सुरंगों की श्रृंखला पर अपना TLS ट्रैफ़िक डालें। यदि आप ध्यान से देखते हैं, तो आदेशों का अंतिम क्रम निम्नानुसार होगा:

सर्वर पर:

 #          ,   -  openssl genrsa -out server.key 2048 openssl req -new -key server.key -batch -days 3650 -x509 -out server.crt [ server.crt ] ssh -c aes256-cbc -m hmac-sha1-96 -o KexAlgorithms=diffie-hellman-group-exchange-sha1 -R 4433:127.0.0.1:4433 user@sshhost openssl s_server -accept 4433 -cert server.crt -key server.key -Verify 0 -CAfile client.crt -cipher DHE-RSA-AES256-SHA -tls1 -no_ticket [ ] [         ] [] 

ग्राहक पर:

 #          ,   -  openssl genrsa -out client.key 2048 openssl req -new -key client.key -batch -days 3650 -x509 -out client.crt [ client.crt ] ssh -c aes256-cbc -m hmac-sha1-96 -o KexAlgorithms=diffie-hellman-group-exchange-sha1 -L 4433:127.0.0.1:4433 user@sshhost openssl s_client -connect localhost:4433 -cert client.crt -key client.key -verify 0 -CAfile server.crt -cipher DHE-RSA-AES256-SHA -tls1 -no_ticket [         ] [] 

Ssh क्लाइंट को कनेक्ट करने के बाद बैकग्राउंड में जाने के लिए, आप -N की कीज़ को इसमें निर्दिष्ट कर सकते हैं।

परिणाम

इसलिए, कोड की एक भी पंक्ति लिखे बिना और केवल मानक उपकरणों का उपयोग किए बिना, हमें एक असंगत का उपयोग करके पत्र-व्यवहार करने का अवसर मिला, जो सुनने में सक्षम होने वाले NAT'om कनेक्शन के लिए काम करने में सक्षम है, MITM हमलों और संदेशों को खराब कर रहा है। इसके अलावा, यह कॉन्फ़िगर करना अपेक्षाकृत सरल है - प्रत्येक वार्ताकार को केवल 4 कमांड और पहले कनेक्शन के लिए एक फ़ाइल स्थानांतरण और बाद के लोगों के लिए दो कमांड निष्पादित करने की आवश्यकता होती है। हां, किसी भी सर्वर तक एसएसएच एक्सेस की आवश्यकता है।

MiniFAQ

क्यू: वीपीएन क्यों नहीं?
एक: वीपीएन एक अच्छा समाधान है। लेकिन इसे कॉन्फ़िगर करना मुश्किल है, सर्वर पर रूट अधिकारों या सर्वर पर विश्वास की आवश्यकता है।

क्यू: क्यों नहीं GnuPG?
A: GnuPG भी एक अच्छा उपाय है। लेकिन अगर वांछित है, तो पहले से प्रसारित डेटा को एक निजी कुंजी (उदाहरण के लिए, एक साथ एक लैपटॉप) प्राप्त करके डिक्रिप्ट किया जा सकता है।

प्रश्न: आपको क्या लगता है कि ओपनएसएसएल में कोई कमजोरियां नहीं हैं?
A: मुझे यकीन है कि वे वहाँ हैं। OpenSSL मुझे व्यक्तिगत रूप से विश्वसनीय लगता है, इसलिए मैंने एक उदाहरण के रूप में इसके बारे में बात की। आप किसी अन्य कार्यान्वयन का उपयोग कर सकते हैं जिसे आप व्यक्तिगत रूप से भरोसा करते हैं।

प्रश्न: क्या आप वादा करते हैं कि टीमें सही हैं?
A: मैं वादा नहीं करता! मैं आपको जांच करने की सलाह देता हूं!

प्रश्न: आप क्रॉस-प्लेटफॉर्म के साथ कैसे कर रहे हैं?
एक: OpenSSL पार मंच है। SSH क्लाइंट अधिकांश OS के अंतर्गत मौजूद हैं।

प्रश्न: मुझे एक वेब इंटरफ़ेस चाहिए, एक कंसोल क्यों?
A: वेब इंटरफ़ेस के लिए कोड लिखना आवश्यक है। एक छोटा XSS भेद्यता महत्वपूर्ण डेटा खर्च कर सकता है। मेरा तर्क सरल है: कोई कोड नहीं - कोई त्रुटि नहीं।

Q: getaddrinfo: ओपनस्ले s_server कमांड चलाने पर नाम या सेवा ज्ञात नहीं है
A: आप शायद IPv6 बंद कर चुके हैं। अद्यतन खुलता है।

Q: जब getsl s_server कमांड चलाते हैं तो gethostbyname विफलता त्रुटि होती है
एक: फ़ाइल / आदि / होस्ट की जाँच करें। पते का पहला नाम 127.0.0.1 हल होना चाहिए।