टेलीग्राम ने खुद को HTTPS के रूप में बदलना सीखा

टेलीग्राम क्लाइंट कोड को HTTPS (TLS + HTTP / 2.0) के रूप में छिपाने की क्षमता के साथ जोड़ा गया था।



इस सुविधा का उपयोग करने के लिए, उन्होंने एक नया गुप्त उपसर्ग जोड़ा - "ee" । इसके अलावा, उन्होंने प्रॉक्सी सर्वर एड्रेस में एक गुप्त को बेस 64 के रूप में, हेक्स के अलावा एनकोड करने की क्षमता को जोड़ा।

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

प्रागितिहास

1. टेलीग्राम ने शुरुआत में SOCKS प्रॉक्सी का समर्थन किया। इससे IP द्वारा सर्वर को अवरुद्ध करने में मदद मिली, लेकिन प्रोटोकॉल ट्रैफ़िक में ध्यान देने योग्य था, और पासवर्ड स्पष्ट पाठ में प्रेषित किया गया था।
2. लगभग एक साल पहले, उन्होंने नए MTProto प्रोटोकॉल पर काम करने वाले एक आधिकारिक प्रॉक्सी को जारी किया । SOCKS के विपरीत, MTProto में पासवर्ड स्पष्ट पाठ में प्रेषित नहीं किया गया था। प्रोटोकॉल में, उन्होंने किसी भी सर्विस हेडर से छुटकारा पा लिया जिसके द्वारा कोई भी यह समझ सकता है कि यह वास्तव में वह था। हमने प्रॉक्सी सर्वर उपयोगकर्ताओं को विज्ञापन प्रदर्शित करने की क्षमता भी जोड़ी है
3. यह पता चला कि MTProto प्रोटोकॉल को चलाने वाले परदे के पीछे पैकेट की लंबाई से पता लगाया जा सकता है। जब कोई कनेक्शन स्थापित किया जाता है, तो क्लाइंट और प्रॉक्सी सर्वर एक निश्चित लंबाई के पैकेट का आदान-प्रदान करते हैं, और ऑपरेशन के दौरान - एक ही लंबाई के पैकेट 4. यह सुविधा बड़े प्रदाताओं द्वारा मैसेंजर को ब्लॉक करने के लिए उपयोग की जाने लगी। टेलीग्राम डेवलपर्स ने प्रत्येक पैकेट में कई यादृच्छिक बाइट्स जोड़कर प्रोटोकॉल को संशोधित करके प्रतिक्रिया व्यक्त की। चूंकि परिवर्तन ने संगतता को तोड़ दिया, इसलिए मुझे विशेष "dd" उपसर्ग के साथ गुप्त प्रारूप को पूरक करना पड़ा, जिसका अर्थ है संशोधित प्रोटोकॉल का उपयोग करना:
   tg://proxy?server=178.62.232.110&port=3256&secret=dd00000000000000000000000000000000
4. जब चीन और ईरान में प्रॉक्सी सर्वर को अवरुद्ध करने की सुविधाओं का अध्ययन किया गया, तो यह पता चला कि पर्यवेक्षक पता लगाने के लिए रिप्ले हमलों का उपयोग करते हैं । पायथन, एरलांग और गो में प्रॉक्सी सर्वर के वैकल्पिक कार्यान्वयन में, इस प्रकार के हमले के खिलाफ आंशिक सुरक्षा प्रकट हुई है। इसके लिए, प्रॉक्सी सर्वर कनेक्शन स्थापित करने के प्रारंभिक चरण में प्रेषित डेटा को स्टोर करते हैं और उसी डेटा के साथ पुन: कनेक्ट करने की अनुमति नहीं देते हैं। दृष्टिकोण में बड़े परदे के पीछे की समस्या है, जैसे मेमोरी के लिए बड़ी मात्रा में RAM की आवश्यकता होती है
5. चीन और ईरान में, निम्नलिखित रणनीति का उपयोग किया जाता है: यदि प्रोटोकॉल अज्ञात है, तो बस मामले में, इसके काम की गति गंभीर रूप से कट जाती है। व्यवहार में, इसका मतलब है कि टेलीग्राम का उपयोग केवल पाठ संदेश भेजने के लिए किया जा सकता है, चित्रों और वीडियो के बिना। और चीन में वे लंबे समय तक ऐसा करना जानते थे, लेकिन ईरान में उन्होंने अपेक्षाकृत हाल ही में सीखा। रूस ने अभी तक सीखा नहीं है, लेकिन कानून पहले ही पारित हो चुका है । मैसेंजर डेवलपर्स द्वारा इस पृष्ठभूमि के खिलाफ कुछ लोकप्रिय प्रोटोकॉल के तहत ट्रैफ़िक को मास्क करने का प्रयास स्वाभाविक लगता है।

क्या बदल गया है?

टेलीग्राम क्लाइंट और प्रॉक्सी सर्वर के बीच प्रोटोकॉल में, टीसीपी पर एनकैप्सुलेशन की एक और परत जोड़ी गई थी। टीसीपी पर डेटा भेजने के बजाय, डेटा को निम्नलिखित टीएलएस प्रविष्टियों में लपेटा गया है:



काम की शुरुआत में, टीएलएस-हैंडशेक इम्यूलेशन चरण जोड़ा गया था। क्लाइंट से प्रॉक्सी सर्वर के पैकेज में निम्नलिखित संरचना है:



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

जब कोई क्लाइंट कनेक्ट होता है, तो प्रॉक्सी सर्वर ट्रांसमिट किए गए HMAC को चेक करता है। यदि यह गणना की गई रेखा से मेल खाता है, तो प्रॉक्सी निम्नलिखित संरचना के साथ एक पैकेट के साथ प्रतिक्रिया करता है:



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

कोशिश कहाँ करें?

प्रदर्शन के लिए, पायथन में प्रॉक्सी सर्वर को संशोधित किया गया था और उठाया गया था, जिससे आप नवीनतम टेलीग्राम डेस्कटॉप क्लाइंट से कनेक्ट कर सकते हैं और Wireshark का उपयोग करके प्रेषित ट्रैफ़िक देख सकते हैं:

 tg://proxy?server=178.62.232.110&port=3256&secret=7gAAAAAAAAAAAAAAAAAAAABnb29nbGUuY29t 

इसके अलावा, Erlang प्रॉक्सी सर्वर में TLS मास्किंग सपोर्ट जोड़ा गया है । सबसे अधिक संभावना है, निकट भविष्य में, इस कार्यक्षमता को प्रॉक्सी सर्वर के अन्य कार्यान्वयन में जोड़ा जाएगा।