1 पॉइंट द्वारा GN⁺ 2025-06-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 1990 के दशक के मध्य में Netscape और Microsoft के बीच ब्राउज़र प्रतिस्पर्धा के दौरान SSL प्रोटोकॉल सामने आया
  • SSL 2 में क्रिप्टोग्राफिक और व्यावहारिक खामियां थीं, और इसी आधार पर Microsoft ने PCT प्रोटोकॉल पेश किया
  • Netscape ने जवाबी रणनीति के तौर पर SSL 3.0 विकसित किया ताकि बढ़त हासिल की जा सके
  • उद्योग और समुदाय चाहते थे कि ब्राउज़रों के बीच compatibility बनी रहे, इसलिए standardization की भूमिका IETF को सौंपी गई
  • इसी प्रक्रिया में प्रोटोकॉल का नाम बदलकर TLS 1.0 किया गया, और वही नाम आज तक चला आ रहा है

पृष्ठभूमि: ब्राउज़र प्रतिस्पर्धा और सुरक्षा प्रोटोकॉल का जन्म

  • 1990 के दशक के मध्य में Netscape और Microsoft ने ब्राउज़र बाज़ार में बेहद तीखी प्रतिस्पर्धा बनाई हुई थी
  • इसी प्रतिस्पर्धा के दौरान Netscape ने SSL प्रोटोकॉल विकसित किया

SSL 2 और उसकी समस्याएं

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

Microsoft की प्रतिक्रिया: PCT प्रोटोकॉल

  • प्रतिस्पर्धा तेज़ होने के बीच Microsoft ने SSL 2 में अपनी अतिरिक्त सुविधाएं जोड़कर PCT नाम का प्रोटोकॉल पेश किया
  • PCT को सिर्फ Internet Explorer(IE) और IIS में समर्थन मिला

Netscape की नई रणनीति: SSL 3.0

  • Netscape भी SSL 2 की समस्याओं को सुधारना चाहता था, लेकिन वह नहीं चाहता था कि Microsoft बढ़त ले ले
  • इसलिए उसने SSL 3.0 विकसित किया, जिसमें पहले की तुलना में स्पष्ट बदलाव लाने की कोशिश की गई

ब्राउज़र उद्योग की standardization वार्ता

  • उद्योग और समुदाय के सदस्य नहीं चाहते थे कि प्रोटोकॉल दो हिस्सों में बंट जाए (fork की स्थिति से बचने के लिए)
  • Consensus Development (जहां लेखक काम करते थे) ने Netscape और Microsoft के प्रतिनिधियों की बैठक का नेतृत्व किया
    • इस बैठक में Bruce Schneier(प्रसिद्ध होने से पहले के दौर में), Paul Kocher(SSL 3 के डिज़ाइनर), Barbara Fox(Microsoft प्रतिनिधि) आदि शामिल थे

IETF द्वारा standardization और नाम परिवर्तन

  • Netscape और Microsoft दोनों इस बात पर सहमत हुए कि IETF(Internet Engineering Task Force) प्रोटोकॉल के standardization process का नेतृत्व करे
  • लेखक ने IETF standard document (RFC) के संपादन का काम संभाला
  • राजनीतिक समझौते के हिस्से के रूप में, SSL 3.0 में कुछ बदलाव किए गए और उसका नाम भी नया रखना पड़ा (ताकि यह आभास न हो कि IETF ने मौजूदा प्रोटोकॉल को ‘जैसा है वैसा’ मंज़ूर कर लिया)
  • नतीजतन TLS 1.0 नाम सामने आया, और तकनीकी रूप से यह SSL 3.1 के बराबर का प्रोटोकॉल था

समापन

  • अब पीछे मुड़कर देखने पर, यह पूरा नामकरण और standardization पर चर्चा का सिलसिला कुछ हद तक हास्यास्पद लगता है

1 टिप्पणियां

 
GN⁺ 2025-06-16
Hacker News की राय
  • सिर्फ version number देखकर यह ठीक से समझना मुश्किल है कि protocol कितना बदला, इस उलझन भरी स्थिति का विवरण: SSLv2 पहला व्यापक रूप से इस्तेमाल किया गया SSL version था, लेकिन उसमें कई समस्याएँ थीं। SSLv3 लगभग पूरी तरह से नए सिरे से बनाया गया protocol था। TLS 1.0, SSLv3 से बहुत मिलता-जुलता था, लेकिन IETF standardization process में कुछ छोटे revision किए गए। TLS 1.1, TLS 1.0 में block cipher इस्तेमाल के तरीके की समस्या को ठीक करने वाला छोटा update version था। TLS 1.2 में cryptography के विकास के अनुसार मध्यम स्तर के बदलाव किए गए; latest hash support (MD5 और SHA-1 vulnerabilities के जवाब में), AEAD cipher suites (जैसे AES-GCM) का support जोड़ा गया। TLS 1.3 अधिकांशतः नया protocol है, लेकिन इसमें TLS 1.2 और उससे पहले की कुछ विशेषताएँ भी शामिल हैं। हर protocol में automatic version negotiation feature इस तरह design की गई कि client और server स्वतंत्र रूप से upgrade हों और connectivity न टूटे

  • उस समय का Microsoft आज की कंपनी से बिल्कुल अलग था, यह ध्यान में रखें तो आज के मानकों से भी यह बिल्कुल अजीब नहीं लगता। तब 'M$' open source internet technologies को रोकने के लिए हर तरीका अपनाता था, और 2010s की शुरुआत तक यह रवैया बना रहा। मेरा मानना है कि Java Applets के आगे न बढ़ पाने और बाजार से बाहर होने में इसका भी योगदान था। JavaScript और CSS का विकास भी कई वर्षों तक धीमा लगा। कंपनी में IE की latest technology support लागू करने का दबाव था, लेकिन मैंने Mozilla 3.0 चुना, और JS bug ठीक करने के बाद enterprise SPA development में Mozilla इस्तेमाल किया। बाद में Fortune 500 कंपनियों में भी internal apps के लिए Mozilla/Firefox का इस्तेमाल बढ़ा, और अब लगता है कि वह सही फैसला था

    • उस दौर को याद करूँ to लगता है कि 'M$' उपनाम आज भी फिट बैठता है
  • अगला version नाम फिर से SSL कर देने में भी शायद दिक्कत नहीं होगी, ऐसी राय। तर्क यह है कि आज भी लगभग हर कोई 'SSL' नाम ही इस्तेमाल करता है

    • यह भी उल्लेख किया गया कि "TLS" नाम भी पहले से कई जगह इस्तेमाल हो रहा है। settings और function signatures वगैरह update करना भी काफी झंझट भरा काम है, इसलिए सोचने वाली बात है

    • यह भी ज़ोर देकर कहा गया कि ऐसी राय से किसी को कोई idea नहीं मिलना चाहिए

  • जब किसी को website access सुरक्षित करने के लिए कहा जाता है (यानी TLS/SSL terminology का उपयोग करते समय), तब मैं आम तौर पर कौन-सा नाम इस्तेमाल करता हूँ—यह सवाल भी पूछा गया। साथ में यह भी जानना चाहा गया कि उम्र कितनी है और क्या 1999 से पहले काम किया था। यह भी कहा गया कि अपना जवाब भी जल्द जोड़ूँगा

    • मेरा जवाब है SSL (उम्र 27)। लेकिन code में tls इस्तेमाल करता हूँ, और documentation में confusion से बचने के लिए SSL/TLS लिखना पसंद करता हूँ

      1. मैं SSL कहता हूँ। बहुत समय तक मुझे यह भी ठीक से पता नहीं था कि TLS "वही चीज़" है, और जानने के बाद भी 10 में 9 बार SSL ही कहता हूँ। 2. उम्र 38 (2011 से काम कर रहा हूँ, लेकिन network programming 2004~2005 से)। अभी-अभी जिस code पर काम किया, उसमें function name जैसे sslCertNotBefore में भी SSL ही है। शायद इसलिए कि आम तौर पर programmer सीधे TLS को handle नहीं करते। मेरे code में भी HTTPS से certificate information parse करनी पड़ती है, इसलिए यह काफी झंझट वाला काम था। automation और abstraction की वजह से इसे बिना गलती के संभालना आसान हो जाता है, लेकिन TLS कैसे काम करता है इसकी गहरी समझ में यह कभी-कभी बाधा भी बनता है
    • ज़्यादातर लोग OpenSSL जैसी libraries से secure communication implement करते हैं, जिनके नाम में ssl आता है, इसलिए SSL शब्द ज़्यादा इस्तेमाल होता है। OpenSSL के अलावा BoringSSL, LibreSSL, wolfSSL जैसी libraries भी हैं। TLS नाम वाली libraries कम प्रसिद्ध हैं। उदाहरण के लिए GnuTLS, mbedTLS, s2n-tls, RustTLS

    • SSL शब्द इस्तेमाल करने की मुख्य वजह यह है कि SSL ज़्यादा आसानी से समझ में आता है। तकनीकी रूप से TLS सही है (वास्तव में SSL 3.0 अब कोई इस्तेमाल नहीं करता), लेकिन प्रमुख libraries में भी SSL शब्द बचा हुआ है, इसलिए वही चलता रहता है। सच कहूँ तो 90s के crypto wars के समय SSL नाम सीखा था, और उस दौर में सही SSL encryption के लिए Netscape का "US only" version गैरकानूनी तरीके से download करना पड़ता था—शायद उसी पुरानी आदत की वजह से अब भी SSL कहता हूँ

    • मैं आम तौर पर "https" कहता हूँ। आम लोग भी इसका अर्थ लगभग समझ लेते हैं, इसलिए यह पसंद है

  • मुझे तो पहली बार एहसास हुआ कि मैं अनजाने में SSL और TLS शब्दों में ठीक से फर्क ही नहीं कर रहा था। 20 साल बाद असली वजह जानकर अजीब-सी दिलचस्प भावना हुई

    • बिल्कुल वही एहसास। इंडस्ट्री में 15 साल काम किया, और अब जाकर पता चला कि SSL और TLS मूल रूप से एक ही चीज़ हैं
  • "Transport Layer Security" निश्चित रूप से बेहतर नाम लगता है। मुझे TLS शब्द भी पसंद है। लगातार दो बार S का उच्चारण करने पर यह साँप जैसी आवाज़ देता है, जो मज़ेदार लगता है

    • लेकिन TLS पहले से ही "Thread Local Storage" के लिए भी व्यापक रूप से इस्तेमाल होता है। Transport Layer Security आधिकारिक रूप से 1999 से इस्तेमाल हुआ, लेकिन Thread Local Storage 1996 से पहले ही MS या IBM development environments में मौजूद था। Unix दुनिया में pthread के 1995 में आने के समय से thread-specific data शब्द को ज़्यादा पसंद किया जाता था। शायद 2001 के Itanium ABI documents की वजह से "TLS" शब्द और फैल गया, और Sun Microsystems भी इसे पहले से इस्तेमाल कर रहा होगा। अगर किसी के पास OS/2 manuals हों, तो reference साझा करें

    • मेरे हिसाब से SSL नाम ही ज़्यादा उपयुक्त लगता है। सिद्धांततः TLS कई layers पर काम करने वाला एक सामान्य security mechanism होना चाहिए (जैसे IPSec के साथ भी), लेकिन व्यवहार में इसका उपयोग मुख्यतः TCP sockets के लिए ही होता है। UDP variant DTLS है, QUIC है, लेकिन वे TLS में शामिल नहीं हैं। हाल में Linux kernel TLS और Windows-specific infrastructure भी हैं, लेकिन इन्हें socket flag ऑन करने जितनी आसानी से लागू नहीं किया जा सकता। और सच कहूँ तो साँप जैसी S sound सुनने में काफ़ी cool लगती है

    • "SSL", "TLS" से बोलने में आसान है। S-S-L बोलते समय जीभ को बहुत कम हिलना पड़ता है, इसलिए यह तेज़ और स्वाभाविक लगता है

    • अगर Jungle Book का Kaa TCP security पर बात करते हुए S~S~L नाम बोले, तो काफ़ी जँचेगा। सच कहूँ तो एक और S जोड़कर SSSL कहना भी मज़ेदार होगा

  • जो लोग TLS और SSL में बहुत सख्ती से फर्क करते हैं, वे शायद यह दिखाना चाहते हैं कि उन्हें दोनों का अंतर अच्छी तरह पता है, या वे चाहते हैं कि बातें उसी तरह की जाएँ। यह अंतर कुछ-कुछ .doc और .docx जैसा है—मूल रूप से अलग, लेकिन आम उपयोगकर्ता के लिए लगभग compatible। ज़्यादातर लोगों को बस HTTPS सही से चलना चाहिए; अंदर की बनावट या काम करने के तरीके से उन्हें खास मतलब नहीं होता

  • संबंधित लिंक: 1996 में लिखे गए 'Randomness and the Netscape Browser' (Dr. Dobb's Journal) लेख की साझेदारी https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.html। 1996 का लेख होने के कारण इसकी भाषा और अंदाज़ आज के papers या articles से काफी अलग है; थोड़ा पुराना-सा एहसास देता है

    • आप कौन-सा publication पढ़ते हैं (यानी target/format के अनुसार) इसमें 1996 की तरह आज भी विविधता है। LWN जैसी जगहें अब भी इसी तरह की शैली में रिपोर्ट करती हैं (बस थोड़ा कम औपचारिक होकर) https://lwn.net/
  • सवाल कि क्या TLS 1.0 में SSL 3.0 की तुलना में वास्तव में काफी सुधार नहीं थे? लेख में इसे सिर्फ "अलग दिखाने के लिए किए गए छोटे adjustment" जैसा कहा गया, इसलिए जिज्ञासा हुई

    • वास्तव में बड़े बदलाव और सुधार काफ़ी थे। बस इतना ज़रूर है कि यह SSL 3.0 जितना पूर्ण redesign नहीं था
  • इंटरनेट पर अब भी 3 लाख से अधिक services SSLv2 support कर रही हैं। लिंक: https://shodan.io/search/report/… रुझान ग्राफ: https://trends.shodan.io/search?query=ssl.version%3Asslv2#overview। संख्या पिछले कई वर्षों में काफी घटी है, लेकिन पूरी तरह गायब होने में अभी समय लगेगा

    • तब सवाल है कि वास्तव में SSLv2-आधारित clients कितने बचे हैं। मौजूदा software/libraries में अब इसका कोई अर्थपूर्ण support बचा हो, ऐसा नहीं लगता