TLS बनाम एंड-टू-एंड एन्क्रिप्शन: जो आपको जानना चाहिए

TLS (Transport Layer Security) डेटा को आपके डिवाइस और सर्वर के बीच यात्रा के दौरान एन्क्रिप्ट करता है, फिर आगमन पर डिक्रिप्ट करता है — यानी सर्वर ऑपरेटर आपकी फ़ाइलें plaintext में पढ़ सकता है। एंड-टू-एंड एन्क्रिप्शन (E2EE) कंटेंट को सेंडर के डिवाइस पर ऐसी की से एन्क्रिप्ट करता है जो केवल प्राप्तकर्ता के पास होती है, इसलिए सर्वर कभी अनएन्क्रिप्टेड डेटा नहीं देखता। फ़ाइल ट्रांसफर के लिए, TLS नेटवर्क ईव्सड्रॉपर से बचाता है लेकिन प्रोवाइडर से नहीं। E2EE दोनों से बचाता है। आपके ब्राउज़र का पैडलॉक आइकन यह नहीं बताता कि वास्तव में कौन सा लागू है।

TLS वास्तव में क्या सुरक्षित करता है

TLS 1.3, RFC 8446 में मानकीकृत, हर HTTPS कनेक्शन का प्रोटोकॉल है। यह X25519 जैसे कर्व के साथ ECDHE इस्तेमाल करके सेशन की नेगोशिएट करता है, X.509 सर्टिफिकेट से सर्वर ऑथेंटिकेट करता है, और आपके HTTP ट्रैफिक को AES-128-GCM या ChaCha20-Poly1305 में लपेटता है। कॉफी शॉप Wi-Fi हमलावर या आपके रिक्वेस्ट पढ़ने की कोशिश करने वाले ISP के खिलाफ यह उत्कृष्ट सुरक्षा है।

TLS क्या नहीं करता: यह लोड बैलेंसर पर टर्मिनेट होता है। जब आप एक सामान्य फ़ाइल-शेयरिंग सर्विस पर 3 GB वीडियो अपलोड करते हैं, तो TLS एज पर डिक्रिप्ट होता है, फिर plaintext फ़ाइल S3 बकेट, ट्रांसकोडिंग पाइपलाइन, शायद ML कंटेंट-स्कैनिंग जॉब, और अंततः प्राप्तकर्ता के डाउनलोड स्ट्रीम से गुज़रती है — जो एक नए TLS सेशन से दोबारा एन्क्रिप्ट होती है। सर्विस के पास हर स्टेप पर पूरी रीड एक्सेस है।

एंड-टू-एंड एन्क्रिप्शन कहाँ शुरू और खत्म होता है

असली E2EE एन्क्रिप्शन सीमा को सर्वर से एंडपॉइंट पर ले जाता है। सेंडर के ब्राउज़र या क्लाइंट पर, एक सिमेट्रिक की (आमतौर पर AES-256-GCM) मेमोरी में जेनरेट होती है। डिवाइस छोड़ने से पहले फ़ाइल चंक-दर-चंक एन्क्रिप्ट होती है। सिफरटेक्स्ट TLS पर सर्वर पर अपलोड होता है, जो अपारदर्शी blob स्टोर करता है। प्राप्तकर्ता को एक अलग चैनल के ज़रिए डिक्रिप्शन की मिलती है — अक्सर # सिंबल के बाद URL फ्रैगमेंट के रूप में, जिसे ब्राउज़र सर्वर को कभी ट्रांसमिट नहीं करते।

इस मॉडल में सर्वर एक डम्ब स्टोरेज लेयर है। पूर्ण सबपोना, डेटाबेस एक्सेस वाला शरारती कर्मचारी, या डिस्क स्नैपशॉट पढ़ने वाला क्लाउड प्रोवाइडर — सभी को केवल एन्क्रिप्टेड बाइट मिलेंगे। यही आर्किटेक्चर HexaTransfer इस्तेमाल करता है: प्रति-ट्रांसफर की के साथ AES-256-GCM, क्लाइंट-साइड डिराइव्ड और कभी ओरिजिन को ट्रांसमिट नहीं किया गया।

TLS-ओनली बनाम एंड-टू-एंड एन्क्रिप्शन की तुलना

| विशेषता | केवल TLS ट्रांसफर | एंड-टू-एंड एन्क्रिप्टेड | |---|---|---| | ट्रांजिट में सिफर | AES-128/256-GCM | AES-256-GCM (TLS के साथ) | | सर्वर plaintext देखता है | हाँ | नहीं | | की की लोकेशन | सर्वर-मैनेज्ड | सेंडर का डिवाइस | | सबपोना से सुरक्षा | कोई नहीं | मज़बूत | | प्रोवाइडर द्वारा कंटेंट स्कैनिंग | संभव | असंभव | | की खोने पर रिकवरी | प्रोवाइडर मदद कर सकता है | डेटा अनरिकवरेबल | | सामान्य सर्विसें | Google Drive, Dropbox | HexaTransfer, SwissTransfer E2EE मोड |

की एक्सचेंज वास्तव में कैसे होता है

E2EE का कठिन हिस्सा सिफर नहीं है — AES 25 साल से ठोस है। कठिन हिस्सा है सर्वर को देखे बिना सेंडर से प्राप्तकर्ता तक की पहुँचाना। फ़ाइल-ट्रांसफर सर्विसें आमतौर पर तीन पैटर्न में से एक इस्तेमाल करती हैं।

पहला है URL फ्रैगमेंट ट्रिक: लिंक https://hexatransfer.com/d/abc123#key=xyz जैसा दिखता है, जहाँ # के बाद सब कुछ ब्राउज़र में रहता है। JavaScript इसे लोकली पढ़ता है और डिक्रिप्ट करता है। दूसरा है पासवर्ड-बेस्ड एन्क्रिप्शन, जहाँ सेंडर पासफ्रेज़ चुनता है, PBKDF2 (RFC 8018) या Argon2id के ज़रिए 6,00,000+ इटरेशन से चलाता है, और पासवर्ड Signal या फोन कॉल के ज़रिए आउट-ऑफ-बैंड शेयर करता है। तीसरा है libsodium के crypto_box जैसी लाइब्रेरी इस्तेमाल करते हुए पब्लिक-की एक्सचेंज, जहाँ प्राप्तकर्ता X25519 पब्लिक की पब्लिश करता है।

केवल TLS कब ठीक है

हर फ़ाइल को E2EE की ज़रूरत नहीं। अगर आप किसी पत्रकार के साथ प्रेस रिलीज़, अपने ग्रुप चैट के साथ मीम, या पब्लिक मार्केटिंग PDF शेयर कर रहे हैं, तो TLS-ओनली सर्विसें बिल्कुल पर्याप्त हैं। डेटा शुरू से संवेदनशील नहीं था, और प्रोवाइडर का इसे पढ़ना कोई जोखिम नहीं बनाता। आप सुविधा के लिए ऑप्टिमाइज़ कर रहे हैं — प्रीव्यू, थंबनेल, इन-ब्राउज़र एडिटिंग — और वे फीचर मौलिक रूप से सर्वर-साइड plaintext एक्सेस की मांग करते हैं।

गणना मेडिकल इमेजिंग (HIPAA 45 CFR 164.312(a)(2)(iv) के तहत कवर्ड DICOM फ़ाइलें), PCI DSS 4.0 आवश्यकता 3.5.1 के तहत वित्तीय विवरण, कानूनी डिस्कवरी मटेरियल, M&A दस्तावेज़, या GDPR अनुच्छेद 32 के तहत EU पर्सनल डेटा वाली किसी भी चीज़ से बदल जाती है। DPDP अधिनियम 2023 के तहत भारत में पर्सनल डेटा के ट्रांसफर में भी उचित सुरक्षा उपाय अनिवार्य हैं — E2EE इसे सबसे प्रभावी ढंग से पूरा करता है।

वह मेटाडेटा गैप जिसके बारे में कोई बात नहीं करता

परफेक्ट E2EE के साथ भी, सर्वर अभी भी मेटाडेटा देखता है: अपलोड टाइमस्टैंप, फ़ाइल साइज़, सेंडर और प्राप्तकर्ता के IP एड्रेस, यूज़र-एजेंट स्ट्रिंग, ट्रांसफर अवधि। अगर आपके थ्रेट मॉडल में ट्रैफिक एनालिसिस शामिल है — मान लीजिए एक सोर्स से संवाद करने वाला पत्रकार — तो यह मायने रखता है। रात 3:14 बजे Reuters ऑफिस से Istanbul में एक Signal नंबर पर अपलोड की गई 147 MB फ़ाइल एक कहानी बताती है, भले ही कंटेंट सिफरटेक्स्ट हो।

अच्छी E2EE सर्विसें मेटाडेटा रिटेंशन कम करती हैं। शॉर्ट लॉग-रिटेंशन विंडो (7 दिन या कम), बेसिक ट्रांसफर के लिए कोई यूज़र अकाउंट आवश्यक नहीं, ट्रांसफर पेजों पर कोई थर्ड-पार्टी एनालिटिक्स नहीं, और आदर्श रूप से ऑनियन रूटिंग या VPN-फ्रेंडली नीतियाँ देखें। सिफर सूट आसपास के ऑपरेशनल स्वच्छता से कम मायने रखती है।

दावे को वेरिफाई करना

"एंड-टू-एंड एन्क्रिप्टेड" मार्केटिंग टेक्स्ट है जब तक आप साबित नहीं कर सकते। तीन टेस्ट असली E2EE को शब्दखेल से अलग करते हैं। पहला, अपलोड के दौरान DevTools खोलें और नेटवर्क टैब देखें — अगर फ़ाइल बॉडी plaintext multipart/form-data के रूप में जाती है, तो आप TLS-ओनली देख रहे हैं। दूसरा, जाँचें कि डिक्रिप्शन URL में फ्रैगमेंट (#) है या नहीं। कोई फ्रैगमेंट नहीं, कोई क्लाइंट-साइड की नहीं। तीसरा, सर्विस की सबपोना रिस्पॉन्स पॉलिसी पढ़ें: अगर वे लॉ एनफोर्समेंट को फ़ाइल कंटेंट प्रोड्यूस कर सकते हैं, तो फ़ाइलें E2EE नहीं हैं। वारंट कैनरी पब्लिश करने वाली और अपना क्रिप्टो कोड ओपन-सोर्स करने वाली (WebCrypto API उपयोग दिखाने वाले GitHub रेपो) सर्विसें सबसे मज़बूत आश्वासन देती हैं।

hexatransfer.com पर आज़माएं — मुफ्त, बिना अकाउंट, 10 GB तक।