90 के दशक के आखिर में SSL का नाम बदलकर TLS क्यों किया गया
(tim.dierks.org)- 1990 के दशक के मध्य के browser wars के दौरान Netscape के SSL और Microsoft के PCT के अलग-अलग दिशाओं में जाने की आशंका बढ़ने पर, उद्योग ने इन्हें एक खुले standard में जोड़ने की कोशिश की
- शुरुआती SSL खामियों के कारण जारी नहीं हो सका, और पहला वास्तविक उपयोग वाला संस्करण SSL 2 भी कुछ वर्षों तक इस्तेमाल हुआ, लेकिन उसमें cryptographic और practical सीमाएँ थीं
- Microsoft का PCT, SSL 2 पर आधारित IE और IIS के लिए बनाया गया उसका अपना extension था, और Netscape ने standard पर नेतृत्व न खोने के लिए SSL 3.0 के साथ जवाब दिया
- Netscape और Microsoft ने IETF की open standardization process पर सहमति बनाई, लेकिन यह नहीं दिखना चाहिए था कि IETF सिर्फ Netscape के protocol को ही औपचारिक मंजूरी दे रहा है
- आखिरकार SSL 3.0 में कुछ बदलाव किए गए और उसका नाम भी बदला गया, और TLS 1.0 ने व्यवहारिक रूप से SSL 3.1 जैसे रूप में शुरुआत की
Browser Wars के बीच SSL और PCT
- 1990 के दशक के मध्य में Netscape और Microsoft की browser प्रतिस्पर्धा ने security protocol standardization को भी प्रभावित किया
- Netscape ने SSL protocol विकसित किया
- शुरुआती संस्करण cryptographic खामियों के कारण जल्दी टूट गया और जारी नहीं किया गया
- पहला production संस्करण SSL 2 था, और इसका कुछ वर्षों तक उपयोग हुआ
- SSL 2 में cryptographic और practical खामियाँ थीं, लेकिन स्थिति इतनी गंभीर नहीं थी कि उसे तुरंत बदलना पड़े
- Microsoft ने SSL 2 में बदलाव करके और अपने अतिरिक्त फीचर जोड़कर PCT को परिभाषित किया
- PCT, SSL 2 से निकला हुआ protocol था
- इसका समर्थन IE और IIS तक सीमित था
- Netscape भी SSL 2 की समस्याएँ ठीक करना चाहता था, लेकिन वह यह नहीं चाहता था कि Microsoft standard की leadership या ownership ले ले
- इसके परिणामस्वरूप उसने बड़े बदलावों वाला SSL 3.0 विकसित किया
IETF standardization और TLS नाम
- उद्योग और community के कई लोग protocol के fork होने की स्थिति से बचना चाहते थे
- Consensus Development ने Netscape और Microsoft के प्रतिनिधियों की एक बैठक आयोजित की
- Tim Dierks उस समय Christopher Allen के साथ Consensus Development में काम कर रहे थे
- उन्होंने Netscape contract के तहत SSL 3.0 reference implementation लिखा
- बैठक में Bruce Schneier शामिल थे, और SSL 3 protocol को design करने वाले Paul Kocher भी शायद शामिल थे, जबकि Microsoft की ओर से Barbara Fox प्रतिनिधि थीं
- बातचीत के नतीजे में Microsoft और Netscape इस बात पर सहमत हुए कि IETF protocol को अपने हाथ में लेकर open process के जरिए standardize करेगा
- इस प्रक्रिया का नतीजा यह हुआ कि Tim Dierks ने RFC का संपादन किया
- standardization प्रक्रिया में SSL 3.0 में कुछ बदलाव किए गए
- इसका उद्देश्य यह था कि ऐसा न लगे कि IETF सिर्फ Netscape के protocol को औपचारिक मान्यता दे रहा है
- इसी कारण protocol का नाम भी बदल दिया गया
- इस तरह बना TLS 1.0, जो वास्तव में SSL 3.1 के अधिक करीब का संस्करण था
1 टिप्पणियां
Hacker News की राय
version numbers protocol के फर्क को ठीक से नहीं दिखाते, इसलिए भ्रम और बढ़ता है
SSLv2 व्यापक रूप से deploy हुआ पहला SSL था, लेकिन उसमें बहुत समस्याएँ थीं, और SSLv3 लगभग नया protocol ही था
TLS 1.0 SSLv3 जैसा है, लेकिन IETF standardization प्रक्रिया में थोड़ा सुधारा गया था, और TLS 1.1 block cipher इस्तेमाल करने के तरीके की समस्या को ठीक करने वाला बहुत छोटा revision था
TLS 1.2 MD5 और SHA-1 की कमजोरियों से निपटने के लिए नए hash और AES-GCM जैसे AEAD cipher suites जोड़ने वाला मध्यम आकार का revision था, और TLS 1.3 TLS 1.2 से पहले के कुछ elements को फिर से इस्तेमाल करता है, लेकिन ज्यादातर नए protocol जैसा है
ये सभी protocols इस तरह design किए गए थे कि version अपने-आप negotiate हो सके, ताकि client और server connectivity खोए बिना स्वतंत्र रूप से upgrade कर सकें
उनमें से एक session tickets था, जिसने servers के बीच synchronized state store किए बिना server-side session resumption संभव किया, और दूसरा Server Name Indication था, जिसने server को एक से अधिक certificates इस्तेमाल करने की सुविधा दी
बाद के versions को v1.1, v1.2, v1.3 बनाना कुछ ऐसा लगता है जैसे version number reset करना objectively गलत था, यह मानने से बचने की जिद
उस समय Microsoft बिल्कुल अलग किस्म का खिलाड़ी था, इसलिए SSL/TLS naming confusion इतना अजीब नहीं लगता
उस दौर का M$ हर चीज पर कब्जा करना चाहता था, और मेरा मानना है कि open source internet technologies को धीमा करने की कोशिश उसने 2010s की शुरुआत तक भी नहीं छोड़ी थी
उसने Java Applet को खत्म करने में सफलता पाई, और मुझे लगता है कि JavaScript और CSS को भी कई साल पीछे रखा
2000s की शुरुआत में कंपनी में IE की latest “technology” support करने का दबाव था, लेकिन एक core JS bug ठीक होते ही हमने तुरंत Mozilla 3.0 support करना शुरू कर दिया, और बाद में जब एक Fortune 500 कंपनी internal apps में Mozilla/Firefox को इनके आम होने से काफी पहले इस्तेमाल करने लगी, तो यह अच्छा फैसला साबित हुआ
IE में वे हमेशा चलते थे, और वही लगभग एकमात्र रास्ता था जिस पर Microsoft असर डाल सकता था
Applet “Java धीमा है” का प्रमुख उदाहरण बनकर fail हुए; आम तौर पर यह बात पूरी तरह सही न भी हो, लेकिन Applet के लिए download wait और JVM startup wait के कारण सही थी
आखिरकार HTML/JS ने वे dynamic features बेहतर ढंग से करने शुरू कर दिए जिनके लिए पहले Applet चाहिए होते थे, और HTML से जो क्षेत्र बाकी रह गए उन्हें Flash ने ले लिया, इसलिए वे गायब हो गए
एक मामूली animation के लिए भी JRE startup time हास्यास्पद रूप से लंबा था, उस समय के हिसाब से memory requirements और crashes भी बहुत ज्यादा थे, और Java platform के शुरुआती releases में compatibility issues भी अजीब थे
security model भी मजाक जैसा था, जो इस धारणा पर आधारित था कि CA certificate पा सकने वाले actors अच्छे ही होंगे, और सिर्फ IE ही नहीं बल्कि browsers में sandboxing technology कुल मिलाकर immature थी
s2n से बहुत उम्मीदें थीं, लेकिन AWS के बाहर लगता है कि वह ज्यादा जगह नहीं बना पाया
TLS और SSL में कड़ा फर्क करने वाला व्यक्ति यह मानता है कि उसे फर्क पता है और सामने वाले को भी पता होना चाहिए, लेकिन practical तौर पर यह .doc और .docx के फर्क जैसा है
मूल रूप से अलग हैं, लेकिन आम users को interchangeable दिखते हैं, और field में आम तौर पर लोगों की रुचि बस इसमें होती है कि HTTPS काम कर रहा है या नहीं, अंदरूनी कामकाज में नहीं
मुझे याद है कि जिन लोगों को लगता था कि बड़ा number मतलब बेहतर, उनसे इस पर काफी चर्चा करनी पड़ी थी
modern encrypted network traffic को सब TLS कहें, और जब सचमुच legacy systems की वजह से SSL इस्तेमाल करना पड़े तभी SSL कहें, तो चीजें काफी आसान हो जाएँगी
अभी-अभी मुझे एहसास हुआ कि मेरा दिमाग अनजाने में SSL और TLS में फर्क करने में मुश्किल महसूस कर रहा था
20 साल बाद जाकर समझ आया कि ऐसा क्यों था
इस industry में 15 साल बाद जाकर ठीक से समझ आया कि ssl और tls वही चीज हैं, तो खुद को बेवकूफ जैसा महसूस हो रहा है
trigger यह था कि Java में आज TLSv1.3 इस्तेमाल करने पर भी encrypted connection शुरू करने के लिए अब भी SSLSocket इस्तेमाल होता है
“Transport Layer Security” नाम के तौर पर बेहतर है
“TLS” कहना भी अच्छा है, और SSL में लगातार दो S होने से वह सांप जैसा सुनाई देता है
Transport Layer Security की शुरुआत 1999 में हुई, ऐसा व्यापक रूप से documented है, और “Thread Local Storage” कम से कम 1996 तक के स्रोतों में मिलता है
उस समय यह Microsoft side में, शायद IBM/OS/2 side में भी, ज्यादा आम term था, जबकि Pthreads और Unix में सामान्य तौर पर इसे “thread-specific data” कहा जाता था
2001 के Itanium ABI document ने शायद इस term को व्यापक Unix world में फैलाया, लेकिन लगता है कि Sun भी Solaris और Java side में इसे पहले से इस्तेमाल करता था
सिद्धांत रूप में TLS, IPSec की तरह कोई transport-layer security mechanism हो सकता है जिसके ऊपर arbitrary protocol रखा जा सके, लेकिन व्यवहार में यह लगभग TCP sockets से बंधा है
UDP variant DTLS या QUIC भी TLS specification का हिस्सा नहीं हैं, और Linux का kernel TLS या Windows का मिलता-जुलता infrastructure भी है, लेकिन socket flag से TLS चालू कर देने जितना आसान नहीं है
जब किसी से कहना हो कि किसी वेबसाइट को सुरक्षित रूप से access करना चाहिए, या ऐसी स्थिति हो जहाँ TLS/SSL शब्द इस्तेमाल हो सकता हो, तो आम तौर पर आप क्या कहते हैं, यह जानने की जिज्ञासा है
लंबे समय तक मुझे यह भी नहीं पता था कि TLS “वही चीज़” है, और अब जानने के बाद भी 10 में से 9 बार अब भी SSL ही कहता हूँ
उम्र 38 है और 2011 में काम शुरू किया, लेकिन network programming पहली बार 2004~2005 के आसपास की थी
अभी दूसरे screen पर देखा तो कुछ मिनट पहले जिस function में if statement जोड़ा था, उसका नाम भी
sslCertNotBeforeथामुझे लगता है समस्या का एक हिस्सा यह भी है कि programmers आम तौर पर TLS को सीधे handle नहीं करते
मैंने HTTPS connection से detailed certificate जानकारी निकालने वाला system बनाया था, और Java standard library से ज़रूरी जानकारी निकालना काफ़ी मेहनत वाला काम था
अगर चीज़ें अपने-आप अदृश्य तरीके से handle हो जाएँ तो गलती करना मुश्किल होता है, लेकिन TLS असल में कैसे काम करता है, इसकी गहरी समझ फैलाने में यह ब्लैक-बॉक्स बन जाना बहुत मददगार नहीं है
सबसे dominant OpenSSL के अलावा BoringSSL, LibreSSL, wolfSSL वगैरह हैं
जिन libraries के नाम में TLS आता है उनमें GnuTLS, mbedTLS, s2n-tls, RustTLS हैं, लेकिन वे अपेक्षाकृत कम इस्तेमाल होती हैं
ज़्यादा सही TLS की तुलना में इसके समझे जाने की संभावना ज़्यादा है, और अब असली SSL 3.0 इस्तेमाल करने वाला कोई नहीं है
OpenSSL जैसी classic libraries के नाम में भी SSL है
हालांकि यह 1990s के crypto wars के दौर में SSL सीखने की आदत भी हो सकती है, जब proper SSL encryption इस्तेमाल करने के लिए “US only” Netscape version लेना पड़ता था
क्योंकि आम लोग भी कभी-कभी इसका मतलब जानते हैं
फिर भी कभी-कभी SSL मुँह से निकल जाता है
उम्र 51 है और 90s के मध्य में IT काम शुरू किया था
लगता है TLS 1.0 में SSL 3.0 की तुलना में काफ़ी बड़े improvements नहीं थे क्या?
लेख पढ़कर तो ऐसा लगता है जैसे बस अलग दिखने के लिए कुछ चीज़ें बदल दी गईं
जब पहले से यह बताया गया था कि POODLE attack सिर्फ़ SSL3 को प्रभावित करता है और TLS1.0 को नहीं, तो सिर्फ़ उस जानकारी से भी अंदाज़ा लगाया जा सकता था कि यह padding oracle होगा
दोनों काफ़ी मिलते-जुलते हैं और यह कहना उचित है कि उनमें कुछ “bug fixes” शामिल थे
बहुत पुरानी बात है इसलिए हो सकता है कुछ चीज़ें भूल गया हूँ, और क्योंकि SSL3 और TLS1.0 हमेशा साथ में implement किए थे, details छूट गई हों
कुल मिलाकर यह ज़्यादा ऐसा था कि IETF ने SSL 3.0 protocol को ज्यों-का-त्यों approve नहीं किया और अपना क्षेत्र चिह्नित किया
संबंधित लेख के रूप में जनवरी 1996 के Dr. Dobb's Journal में “Randomness and the Netscape Browser” है
https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht...
यह 1996 में लिखा गया लेख है, और इसमें इस्तेमाल भाषा आज के publications से पहले ही काफ़ी अलग महसूस होती है, इसलिए उम्रदराज़ होने का एहसास होता है
जैसे 1996 में था, वैसे ही आज LWN articles [1] वगैरह काफी मिलती-जुलती शैली में पढ़े जाते हैं
हालांकि वे थोड़े ज़्यादा general readers को target करते हुए थोड़ा कम कठोर हो सकते हैं
[1] https://lwn.net/
याद है कि Eric Rescorla की “SSL and TLS: Designing and Building Secure Systems” TLS के इतिहास और यहाँ तक कैसे पहुँचे, यह समझने में बेहद उपयोगी थी
यह 2001 में आई किताब है, और इसने कुछ ऐसी समस्याओं के बारे में पहले ही चेतावनी दी थी जो बाद में CVE बनीं, और second-hand में कुछ dollars में मिल भी सकती है
2014 के आसपास तक यह consensus बहुत पक्का था कि SSL 2.0 में गंभीर खामियाँ हैं
handshake तक ठीक से authenticated नहीं था