रेस्ट पर एन्क्रिप्शन vs ट्रांज़िट में: दोनों सुरक्षा के लिए ज़रूरी

Transit encryption दो points के बीच move हो रहे data को protect करता है — जैसे आपका ब्राउज़र और एक सर्वर — TLS 1.3 का उपयोग करके AES-256-GCM या ChaCha20-Poly1305 के साथ। Rest encryption disk पर बैठे data को protect करता है, आमतौर पर full-disk encryption के लिए AES-256-XTS या per-file के लिए AES-256-GCM। दोनों में से अकेला काफी नहीं है। TLS नेटवर्क snooping से बचाती है लेकिन सर्वर पर decrypt होती है; at-rest encryption stored data protect करती है लेकिन बेकार है अगर keys ciphertext के बगल में रहें। असली security दोनों को layer करने से आती है, आदर्श रूप से client-side (end-to-end) encryption के साथ ताकि सर्वर को कभी plaintext न मिले।

दो अलग threats, दो अलग controls

Threats इस पर निर्भर करते हैं कि आपका data कहाँ है:

Transit में (network path): coffee-shop attacker जो packet sniffer चला रहा हो, compromised ISP router, undersea cables tap करने वाला nation-state। 2013 के Snowden documents ने NSA के MUSCULAR program का खुलासा किया जो Google के internal fiber links tap करता था। Defense: TLS 1.3, apps के लिए अधिमानतः certificate pinning के साथ।

Rest में (storage): चुराया गया लैपटॉप, leaked backup tape, misconfigured S3 bucket, disk access वाला rogue datacenter employee। 2017 का Equifax breach 147 million records expose किया जिसका एक कारण था कि data unencrypted पड़ा था। Defense: disks के लिए LUKS, BitLocker, FileVault; per-file या per-block के लिए AES-256-GCM या AES-256-XTS।

गलती है एक को दूसरे का substitute समझना। TLS database dump protect नहीं करती। Disk encryption man-in-the-middle attack नहीं रोकती।

TLS 1.3 transit में data कैसे protect करता है

TLS 1.3, RFC 8446 (2018) में standardized, आधुनिक default है। इसमें:

• Forward secrecy default से ephemeral ECDHE key exchange के ज़रिए। अगर server की long-term key leak हो, past sessions protected रहते हैं।
• AEAD ciphers only — AES-128-GCM, AES-256-GCM, या ChaCha20-Poly1305। पुराने CBC modes और RC4 गए।
• Single round-trip handshake (1-RTT), या resumption के लिए zero round-trip (0-RTT)।
• Encrypted handshake ताकि passive observers certificate chain न देख सकें।

हर reputable फ़ाइल ट्रांसफर सर्विस — WeTransfer, SwissTransfer, Tresorit, Proton Drive, HexaTransfer — कम से कम 12 महीने HTTPS enforce करने वाले HSTS headers के साथ TLS 1.3 चलाती है। SSL Labs के testssl tool पर verify करें; A- से नीचे score में configuration issues हैं।

सर्वर पर at-rest encryption कैसे काम करती है

Files पहुँचने और TLS terminate होने के बाद, at-rest encryption लेती है। कई layers हैं:

• Block-level (full-disk): LUKS पर AES-256-XTS (Linux), BitLocker (Windows), FileVault (macOS), या cloud-provider equivalents जैसे AWS EBS encryption। Stolen disks से protect करता है।
• Filesystem-level: eCryptfs, ext4/F2FS पर Fscrypt। हर user की files अलग keys से encrypted।
• Object-storage level: AWS S3 SSE-KMS, customer-managed keys के साथ Azure Blob, Google Cloud Storage। हर object AES-256-GCM से encrypted।
• Application-level: सर्विस storage को देखने से पहले खुद अपने code में हर फ़ाइल encrypt करती है, KMS या HSM में keys के साथ।

Application-level सबसे strong है क्योंकि encryption किसी storage system के data देखने से पहले होती है। AWS KMS प्रति key $1/माह plus $0.03 per 10,000 requests charge करता है — इतना सस्ता कि serious सर्विसेज़ इसे per file इस्तेमाल करती हैं।

"Keys ciphertext के बगल में" trap

यहाँ at-rest encryption आमतौर पर fail होती है। अगर keys उसी सर्वर पर store हों जहाँ ciphertext है, तो सर्वर breach करने वाला attacker दोनों पाता है। Provider technically "encrypted at rest" box tick कर सकता है compliance के लिए जबकि सर्वर compromise के खिलाफ ज़ीरो real protection देता है।

अच्छे architectures concerns अलग करते हैं:

• Ciphertext S3 या similar object storage पर।
• Encryption keys AWS KMS, Google Cloud KMS, Azure Key Vault, या dedicated HSM में।
• Keys तक access short-lived IAM credentials और audit logs से gated।

महान architectures और आगे जाते हैं: keys सर्वर पर कभी exist नहीं करतीं। Client-side encryption (E2EE) का मतलब है user का ब्राउज़र key generate करता है, फ़ाइल encrypt करता है, key रखता है। सर्वर ciphertext store करता है और leak करने के लिए कुछ नहीं है।

Encryption gaps कहाँ दिखते हैं

दोनों controls होते हुए भी, data कई जगह briefly plaintext होता है:

• सर्वर memory में अपलोड processing, virus scanning, या thumbnail generation के दौरान। इस window में memory dump plaintext reveal करता है।
• Access logs में अगर debugging के लिए filenames या content snippets log हों।
• Backup tapes में अगर backups same encryption inherit न करें।
• Compression या transcoding के दौरान जहाँ सर्विस फ़ाइल कंटेंट process करती है।
• Download के बाद browser cache में अगर user clear न करे।

यही gaps हैं इसीलिए zero-knowledge (client-side) encryption मायने रखती है। जब files ब्राउज़र में अपलोड से पहले encrypt हों, सर्वर-साइड gaps irrelevant हो जाते हैं — सर्वर को सिर्फ ciphertext मिलती है।

बड़ी सर्विसेज़ वास्तव में क्या करती हैं

Public documentation के आधार पर rough classification:

• Google Drive, Dropbox, OneDrive: transit में TLS 1.3, provider-held keys के साथ rest पर AES-256। Zero-knowledge नहीं — provider आपकी files पढ़ सकता है।
• WeTransfer (free tier): TLS 1.3, AWS S3 पर rest में AES-256। Provider keys रखता है।
• Box Enterprise: TLS 1.3, rest पर AES-256-GCM, optional customer-managed keys (Box KeySafe)।
• Tresorit, Proton Drive, SwissTransfer E2EE tier, HexaTransfer: transit में TLS 1.3, rest पर AES-256-GCM, लेकिन per-file keys client-generated हैं और सर्वर तक कभी नहीं पहुँचतीं। Effectively zero-knowledge।

Sensitive data के लिए, सिर्फ last category insider threats और valid legal demands के खिलाफ meaningful protection देती है।

Compliance और "defense in depth" की ज़रूरत

Regulators explicitly दोनों require करते हैं:

• GDPR Article 32 "pseudonymisation and encryption of personal data" mandate करता है बिना यह restrict किए कि data किस state में है।
• HIPAA Security Rule 45 CFR § 164.312 transit और rest दोनों में ePHI encryption require करता है।
• PCI DSS 4.0 Requirement 3 और 4 "stored cardholder data protect करना" (at rest) को "transmission के दौरान strong cryptography से protect करना" (in transit) से अलग करता है।
• DPDP Act 2023 (भारत) — data fiduciaries को personal data के लिए उचित security safeguards implement करने होंगे, जिसमें transit और rest दोनों में encryption शामिल है।

सिर्फ एक देना compliance failure है security failure से पहले।

दोनों active हैं या नहीं verify करें

किसी भी फ़ाइल ट्रांसफर सर्विस के लिए पाँच quick checks:

1. TLS 1.3 केवल strong ciphers के साथ confirm करने के लिए testssl.sh https://provider.com चलाएं।
2. कम से कम 31,536,000 (एक साल) के max-age के साथ HSTS headers चेक करें।
3. Rest पर AES-256-GCM या AES-256-XTS के explicit mention के लिए security whitepaper पढ़ें।
4. Confirm करें keys application database में नहीं, KMS या HSM में हैं।
5. SOC 2 Type II या ISO 27001 certification देखें — दोनों documented at-rest और in-transit controls require करते हैं।

Bonus: client-side encryption option available है या नहीं देखें। अगर हाँ, तो sensitive किसी भी चीज़ के लिए चालू करें।

उन्हें सही तरीके से layer करें

जो pattern वाकई काम करता है:

1. ब्राउज़र random AES-256-GCM key से फ़ाइल encrypt करता है (client-side)।
2. Ciphertext TLS 1.3 पर सर्वर तक जाती है (in transit)।
3. सर्वर ciphertext को AES-256 encrypted storage पर store करता है (at rest)।
4. Decryption key सिर्फ share URL fragment में रहती है, सर्वर को कभी नहीं भेजी जाती।

तीन independent layers। एक टूटे, दूसरे hold करते हैं। यही design है जो HexaTransfer इस्तेमाल करता है, Tresorit Send, Proton Drive share links और SwissTransfer के E2EE mode के साथ।

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