Yandex अब आउटगोइंग और इनकमिंग मेल के एन्क्रिप्शन का समर्थन करता है

पिछले हफ्ते, हमने Yandex.Mail में STARTTLS का उपयोग करके क्रॉस-सर्वर SMTP कनेक्शन के लिए एन्क्रिप्शन शामिल किया, ईमेल प्राप्त करने और भेजने के लिए। अब हमारे मेल सिस्टम से अन्य सेवाओं के उपयोगकर्ताओं के लिए सभी पत्र जो इस तरह के एन्क्रिप्शन का समर्थन करते हैं (उदाहरण के लिए, जीमेल) एन्क्रिप्टेड रूप में प्रेषित होते हैं, और कोई भी उन्हें रास्ते में पढ़ने में सक्षम नहीं होगा। इस संबंध में, मैं उन प्रोटोकॉल के बारे में थोड़ी बात करूंगा जिनका उपयोग एन्क्रिप्टेड रूप में ईमेल भेजते समय किया जाता है।

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



शोधकर्ताओं ने अभी तक संक्षिप्त रूप से इंटरनेट प्रौद्योगिकीविदों के सच्चे प्रेम का कारण नहीं खोजा है। ARPANET के बाद से , सभी नेटवर्क, प्रोटोकॉल, मानक आदि। संक्षिप्त कहा जाना पसंद करते हैं। यह सरल और सरल शब्द-निर्माण विधि के वाक्यों की ओर जाता है: " SSHFP में RSA, DSA और ECDSA के साथ SHA-256 के उपयोग पर CZ.NIC द्वारा IETF ने RFC6594 प्रकाशित किया।" जैसा कि आप देख सकते हैं, क्रिप्टोग्राफी में विशेष रूप से कई ऐसे संक्षिप्त विवरण हैं।

एसएसएल और टीएलएस क्या हैं?

पिछली शताब्दी के नब्बे के दशक में, "इनक्यूबेटर्स" में से एक, जहां शैक्षणिक वातावरण से सभी प्रकार के दिलचस्प विचारों को वास्तविकता में सन्निहित किया गया था, नेटस्केप था। यह उसके कर्मचारी थे, जिन्होंने पिछले वर्ष से पहले शुरुआत में, कनेक्शन को एन्क्रिप्ट करने की संभावना का एहसास किया, प्रोटोकॉल प्रकाशित किया और इसे सिक्योर सॉकेट्स लेयर (एसएसएल) कहा। इसका पहला सार्वजनिक संस्करण SSL v2 था, जिसने बहुत सी कमजोरियों का पता लगाया । वर्तमान में उपलब्ध अंतिम SSL v3 द्वारा इसका अनुसरण किया गया था। नेटस्केप पर मूल विवरण एओएल द्वारा नेटस्केप के अवशोषण के समय गुमनामी में डूब गया, लेकिन 2011 में इसे RFC6101 के रूप में कहानी के लिए प्रकाशित किया गया था।

तब पहला मुफ्त एसएसएल कार्यान्वयन दिखाई दिया। उत्साही एरिक यंग ने बीएसडी जैसे लाइसेंस के तहत एसएससी लाइब्रेरी (इस बार टीम का संक्षिप्त नाम: एसएसएल + एरिक ए यंग) का प्रकाशन शुरू किया है। कुछ वर्षों में एसएसएलवाई सभी विशेषज्ञों के लिए जानी जाने वाली ओपनएसएसएल लाइब्रेरी में बदल जाएगी।

SSL v2 और v3 के बारे में जानना महत्वपूर्ण है सबसे पहले, ये प्रोटोकॉल विश्वसनीय वितरण और कनेक्शन (उदाहरण के लिए, टीसीपी) के साथ परिवहन प्रोटोकॉल के शीर्ष पर काम करने के लिए डिज़ाइन किए गए हैं। दूसरे, SSL v2 का अब उपयोग नहीं किया जा सकता है - यह आधिकारिक तौर पर बहुत असुरक्षित माना जाता है और वर्तमान परिवेश में केवल सुरक्षा का भ्रम दे सकता है।

SSL v3 के आधार पर, IETF के भीतर वैज्ञानिकों और इंजीनियरों की एक टीम ने ट्रांसपोर्ट लेयर सिक्योरिटी ( TLS) प्रोटोकॉल बनाया। वास्तव में, TLS v1.0 SSL v3 का एक छोटा (लेकिन असंगत) नया स्वरूप है, जिसमें इसकी सभी विशेषताएं शामिल हैं और कुछ विवरण शामिल हैं।

नब्बे के दशक के उत्तरार्ध और शून्य की शुरुआत एचटीटीपीएस के व्यापक उपयोग द्वारा चिह्नित की गई (और यह मुझे याद है, एसएसएल / टीएलएस - एन्क्रिप्टेड एचटीटीपी पर HTTP है), और, परिणामस्वरूप, दोनों रंगों के टोपियों में कंप्यूटर सुरक्षा विशेषज्ञों के इन प्रोटोकॉल पर ध्यान देना। परिणामस्वरूप, CBC मोड में ब्लॉक एन्क्रिप्शन एल्गोरिदम के साथ SSL v3 या TLS 1.0 (और SSL में अन्य ब्लॉक एल्गोरिथ्म मोड का उपयोग नहीं किया गया) का उपयोग करते समय कमजोरियों की एक पूरी कक्षा की खोज की गई थी। 2006 में - 7 साल बाद - टीएलएस 1.1 का एक अद्यतन संस्करण जारी किया गया था, जिससे इन कमजोरियों को दूर किया गया। हालांकि, इंजीनियरों को 2011 तक टीएलएस 1.1 को लागू करने के लिए कोई जल्दी नहीं थी, जब टीएलएस 1.0 का उपयोग करने वाले ब्राउज़रों पर एक जोरदार हमला हुआ, जिसे इंटरनेट पर सबसे ज्यादा गरजा। कई बैसाखियों को तुरंत आविष्कार किया गया था (उदाहरण के लिए, एक धारा सिफर पर स्विच करना), साथ ही टीएलएस 1.1+ के लिए सब कुछ अपग्रेड करने के लिए प्राथमिकताएं बढ़ाना।

2008 में, टीएलएस released 1.2 के नवीनतम संस्करण का विनिर्देश जारी किया गया था। इसमें बहुत सारे नवाचार दिखाई दिए। सबसे पहले, एईएस एन्क्रिप्शन एल्गोरिथ्म का उपयोग करने की क्षमता अनिवार्य हो गई है, और सीबीसी - जीसीएम के अलावा एक नया एन्क्रिप्शन मोड दिखाई दिया है। दूसरे, विरासत डेस और आईडिया एल्गोरिदम के समर्थन को बाहर रखा गया था। तीसरा, प्रोटोकॉल ने एमडी 5 हैश एल्गोरिथ्म पर आधारित एचएमएसी के उपयोग को छोड़ दिया और अधिक स्थिर SHA256 और SHA384 पर स्विच किया। चौथा, टीएलएस एक्सटेंशन तंत्र दिखाई दिया है, जो आपको प्रोटोकॉल को पूरी तरह से नया स्वरूप दिए बिना नई सुविधाओं को शामिल करने की अनुमति देता है। इन एक्सटेंशनों में से एक एसएनआई है , जिसका इस्तेमाल यैंडेक्स सेवाओं में सक्रिय रूप से किया जाता है। अंत में, ताकि सभी नवाचार बेकार न हों, प्रोटोकॉल में SSLv3 को डाउनग्रेड करने की संभावना को अप्रचलित घोषित किया गया था और अनुशंसित नहीं किया गया था।

इसलिए, संक्षेप में:

1. एसएसएल टीसीपी पर एक सुरक्षित कनेक्शन प्रोटोकॉल है। कोई नया एसएसएल संस्करण नहीं हैं। TLS version यह नया एसएसएल है, जिसमें नया वर्जन नंबरिंग है।
2. एक पुराना SSL v2 है। यह अनुपयोगी है - यदि यह समर्थित है, तो इसे अक्षम होना चाहिए। SSL v3 है, जो कई वर्षों से हर जगह समर्थित है। लेकिन इसमें ऐसी खामियां पाई गईं जो सुरक्षा को प्रतिकूल रूप से प्रभावित कर सकती हैं। TLS v1.0 है, यह SSL v3 भेद्यता को बरकरार रखता है, और इसका उपयोग केवल इन-लाइन एन्क्रिप्शन एल्गोरिथ्म RC4 (जिसे अलग से सैद्धांतिक रूप से कमजोर माना जाता है) के साथ करना बेहतर होगा। इसलिए, TLS v1.1 या v1.2 का उपयोग करना और RC4 सिफर को अक्षम करना सबसे अच्छा है।

ईमेल प्रोटोकॉल

हम विश्वासपूर्वक कह ​​सकते हैं कि ईमेल भेजने के लिए HTTP मुख्य उपयोगकर्ता प्रोटोकॉल है। यह असामान्य लग सकता है, लेकिन अधिकांश उपयोगकर्ता 2013 में अपने ईमेल पढ़ते हैं और भेजते हैं।



मेल प्रोग्राम, हालांकि पृष्ठभूमि में फीका है, अभी भी व्यापक रूप से उपयोग किया जाता है और तीन प्रोटोकॉल पर काम करते हैं: पुराने POP3, थोड़ा नया IMAP और सार्वभौमिक SMTP। मैंने पहले पीओपी 3 और आईएमएपी के इतिहास के बारे में थोड़ी बात की थी , और अब मैं एसएमटीपी के बारे में थोड़ी जानकारी दूंगा।

ई-मेल को सही मायने में पहला किलर लैपटॉप कंप्यूटर नेटवर्क कहा जाता है। आधुनिक SMTP (सिंपल मेल ट्रांसफर प्रोटोकॉल) की जड़ें अमेरिकी रक्षा विभाग के पैसे से अमेरिकी विश्वविद्यालयों के कंप्यूटरों के बीच फ़ाइलों को स्थानांतरित करने के पूर्व-टीसीपी / आईपी युग में ARPANET में बहुत गहराई से जाती हैं। ये भोले थे, व्यापक पारस्परिक विश्वास के अद्भुत समय, जब न केवल एन्क्रिप्शन, बल्कि सरल प्रमाणीकरण की भी आवश्यकता नहीं थी। वैसे, जो कुछ वर्षों बाद हमारे साथ हुआ, वह आपके स्वयं के स्पैम फ़ोल्डर में देखा जा सकता है।

देखें, 1981 के अंत में RFC 788 में इंटरनेट के लिए SMTP का पहला संस्करण (बड़े अक्षर के साथ!) निर्दिष्ट किया गया था। फिर भी, यह ARPANET में एक दशक से अधिक के ईमेल विकास का परिणाम था। और 1999 में लगभग 20 वर्षों के बाद, प्रमाणीकरण के लिए आधिकारिक मानक। है, जो एसएमटीपी में लॉगिन और पासवर्ड के लिए है। इस समय, किसी को भी किसी से जोड़ने के तुरंत बाद एसएमटीपी के माध्यम से मेल भेजना संभव था। यह मोड, निश्चित रूप से बड़ी संख्या में आशाओं के साथ नेटवर्क पर चौराहे संचार के लिए उपयुक्त था, इस मामले में, मेजबान किसी और के मेल के लिए रिले के रूप में सेवा कर सकते हैं। लेकिन प्रारंभिक भेजने, तथाकथित प्रस्तुतिकरण, बिना प्रमाणीकरण के स्पैम की उपस्थिति का कारण बना, और फिर SMTP AUTH के आविष्कार के लिए। वैसे, पुराने टाइमर अभी भी "POP3 से पहले SMTP" मोड को याद कर सकते हैं, जो SMTP के लिए एक प्रमाणीकरण बैसाखी के रूप में POP3 का उपयोग करता था।

जैसे ही पासवर्ड प्रोटोकॉल में दिखाई देते हैं, वे तुरंत एन्क्रिप्शन के बारे में सोचना शुरू कर देते हैं। 2002 में, टीएलएस मोड FC RFC3207 के लिए एक खुले SMTP सत्र के उन्नयन का समर्थन करने के लिए एक मानक जारी किया गया था। यह तथ्यपूर्ण स्थिति को ठीक करने और सुधारने का एक प्रयास था encryption एसएमटीपी एन्क्रिप्शन एक अलग पोर्ट 465 पर उस समय तक कई वर्षों तक उपयोग किया गया था।

STARTTLS संचालन योजना विशेष रुचि की है। यह किसी भी पाठ प्रोटोकॉल के लिए एक सार्वभौमिक विस्तार है। वास्तव में, यह SMTP, IMAP / POP3 के लिए वितरण और FTP के लिए थोड़ा प्राप्त किया है।



उस समय जब क्लाइंट और सर्वर पहले से स्थापित खुले कनेक्शन में समझते हैं कि दोनों ओर डेटा ट्रांसमिशन को एन्क्रिप्ट करने का एक अवसर और इच्छा है, क्लाइंट STARTTLS कमांड देता है और तुरंत TLS हैंडशेक शुरू करता है।



एन्क्रिप्शन शुरू होने से पहले टीएलएस के आपसी समर्थन को सत्यापित करने का केवल तरीका आवेदन प्रोटोकॉल पर निर्भर करता है। SMTP के मामले में, यह ESMTP विस्तार तंत्र के माध्यम से होता है of इस बारे में विवरण हैं।



मानक पोर्ट पर STARTTLS के माध्यम से SMTP एन्क्रिप्शन (25 और दूसरा 587 याद रखें, जो अक्सर भूल जाता है) या पोर्ट 465 पर तुरंत लोकप्रियता हासिल करना शुरू हो गया। TLS बहुत अनुमति देता है: प्रमाणपत्र प्रमाणीकरण और सर्वर प्रमाणीकरण: ये सभी रोचक, आवश्यक और उपलब्ध अनुपलब्ध सुविधाएँ हैं। अब, ऐसा लगता है, कोई मेल सिस्टम नहीं है जो एन्क्रिप्टेड कनेक्शन पर उपयोगकर्ताओं से मेल स्वीकार नहीं करता है। एक और चीज है चौराहा संचार।

SMTP केवल एक ईमेल वर्कहॉर्स नहीं है, बल्कि यह दो सिरों वाला घोड़ा है।

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

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

यांडेक्स मेल प्रोटोकॉल में एन्क्रिप्शन के लिए समर्थन

2009 में, IMAP के लॉन्च के साथ, हमने अपने POP3 इंटरफ़ेस में SSL / TLS समर्थन जोड़ा। लगभग उसी समय, ईमेल कार्यक्रमों से ईमेल प्राप्त करने के लिए SMTP में एन्क्रिप्शन दिखाई दिया। आज, 4 साल से अधिक समय के बाद, हमारे सर्वर अभी भी आपको मेल कार्यक्रमों से असुरक्षित कनेक्शन खोलने की अनुमति देते हैं, हालांकि हम उन्हें उपयोग करने की सलाह नहीं देते हैं और यहां तक ​​कि, यदि संभव हो तो, उन्हें दस्तावेज न करें।



Yandex.Mail मोबाइल एप्लिकेशन हमेशा SSL / TLS कनेक्शन का उपयोग करते हैं, और इसके अंदर XMPP प्रोटोकॉल का उपयोग करते हैं।

2011 में, हमने वेब इंटरफ़ेस mail.yandex.ru में HTTPS को सक्षम किया और इस प्रकार उपयोगकर्ता की जानकारी को क्लाउड पर स्थानांतरित करने के सभी मुख्य तरीकों को कवर किया। इस वर्ष, हमने मेल एक्सेस करते समय HTTPS को अनिवार्य कर दिया, और इस सप्ताह हमने असुरक्षित प्रोटोकॉल के माध्यम से इसे कनेक्ट करने के सभी अवसरों को अक्षम कर दिया। हमने प्रमाणीकरण प्रणाली - Yandex.Passport - में उपयोगकर्ता पासवर्ड की सुरक्षा करने का भी बड़ा काम किया और हम आपको इसके बारे में बताएंगे।



यह इस प्रकार है कि बाहरी दुनिया के साथ हमारे SMTP संचार सर्वर पर एन्क्रिप्टेड और नियमित ट्रैफ़िक का अनुपात अब जैसा दिखता है।




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

पुनश्च: एडवर्ड, नमस्ते! :)
PPS: एडवर्ड स्नोडेन काम नहीं करता है और उसे यैंडेक्स में कभी नौकरी नहीं मिली।