टिम हडसन, ओपनएसएसएल कॉरपोरेशन के अध्यक्ष – साक्षात्कार श्रृंखला

Tim Hudson SSLeay के सह‑लेखक हैं और OpenSSL Conference के आयोजकों में से एक हैं, प्राग, 13‑15 अक्टूबर 2026। उनका सिस्टम और नेटवर्क सुरक्षा में 30 से अधिक वर्षों का अनुभव है और वह OpenSSL Corporation के अध्यक्ष तथा Cryptsoft Pty Ltd में मुख्य प्रौद्योगिकी अधिकारी (CTO) हैं। 1995 से, उनका कार्य Eric Young के साथ SSLeay की सह‑स्थापना (जो बाद में OpenSSL Library बन गई), RSA Security ऑस्ट्रेलिया विकास केंद्र की सह‑स्थापना, अमेरिकी एन्क्रिप्शन निर्यात नियमों में बदलाव में योगदान, 30 से अधिक FIPS 140 मान्यताओं का नेतृत्व, OASIS KMIP और SAM तकनीकी समितियों के सह‑अध्यक्ष, और RSA Conference, AusCERT, ICMC, LinuxConf तथा OpenSSL Conference सहित प्रमुख सुरक्षा सम्मेलनों में भाषण देना शामिल है।

OpenSSL एक वैश्विक सहयोगी ओपन‑सोर्स प्रोजेक्ट है जो OpenSSL Library को विकसित और रखरखाव करता है, जो दुनिया की सबसे अधिक उपयोग की जाने वाली क्रिप्टोग्राफ़िक लाइब्रेरीज़ में से एक है। विभिन्न ऑपरेटिंग सिस्टम, क्लाउड प्लेटफ़ॉर्म, एंटरप्राइज़ सॉफ़्टवेयर और जुड़े उपकरणों में उपयोग होने वाली OpenSSL Library हर दिन अरबों सुरक्षित ऑनलाइन इंटरैक्शन की रक्षा करती है। OpenSSL फ़ाउंडेशन और OpenSSL कॉरपोरेशन के माध्यम से, यह प्रोजेक्ट भरोसेमंद क्रिप्टोग्राफी को आगे बढ़ाने, सतत ओपन‑सोर्स विकास का समर्थन करने और इंटरनेट की सुरक्षा को मजबूत करने के लिए प्रतिबद्ध है।

आपने 1995 में Eric Young के साथ SSLeay की सह‑स्थापना तब की जब आपने गैर‑अमेरिकी SSL कार्यान्वयन की आवश्यकता पहचानी, और वह कार्य अंततः OpenSSL की नींव बन गया। आप मूल रूप से किस समस्या को हल करने की कोशिश कर रहे थे, और क्या उस समय आपको यह अंदाज़ा था कि यह तकनीक इंटरनेट सुरक्षा का इतना मौलिक हिस्सा बन जाएगी?

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

मेरे पास वह ज्ञान था जो अधिकांश लोग भूल चुके थे। Eric Young ने कुछ साल पहले एक DES कार्यान्वयन लिखा था: अच्छा, साफ़, मुफ्त में उपलब्ध कोड, जो केवल अपने उद्देश्य के लिए लिखा गया था और इस सब से पूरी तरह असंबंधित था। Eric SSL पर काम नहीं कर रहे थे। उन्हें SSL का पता नहीं था। जब Netscape ने विनिर्देश प्रकाशित किया, मैं उसे पढ़ा, समस्या लेकर Eric के पास गया और इसे उनके मौजूदा कार्य से एक अपेक्षाकृत मामूली कदम के रूप में प्रस्तुत किया।

यह पूरी तस्वीर नहीं थी। प्रत्येक भाग सरल था लेकिन भागों की संख्या काफी अधिक थी। एक DES कार्यान्वयन आपको एक सममित सिफर देता है। SSL को सार्वजनिक कुंजी क्रिप्टोग्राफी, मनमानी सटीक अंकगणित, ASN.1, X.509 प्रमाणपत्र प्रबंधन, और एक प्रोटोकॉल स्टेट मशीन की आवश्यकता होती है, और सभी को सही होना चाहिए, क्योंकि क्रिप्टोग्राफी में लगभग सही और टूटे हुए समान होते हैं। मैंने इसे आशावादी रूप से प्रस्तुत किया था। Eric ने जल्द ही समझ लिया कि इसमें कितना काम है, और इसे आनंदित किया, क्योंकि पैमाना बाधा नहीं बल्कि आकर्षण था। मुझे नहीं लगता कि यह किसी अन्य तरीके से शुरू होता।

उन्होंने क्रिप्टोग्राफ़िक कोर बनाया, इसलिए लाइब्रेरी में उनके प्रारंभिक अक्षर हैं। मैंने उन भागों को संभाला जो लाइब्रेरी को अन्य लोग वास्तव में तैनात कर सकें: अनुप्रयोग एकीकरण, परीक्षण, दस्तावेज़ीकरण, और समुदाय पक्ष। मैंने सक्रिय रूप से किसी भी प्रतिस्पर्धी एन्क्रिप्शन लाइब्रेरी को खोजा जहाँ वह उपयोग में थी और उसे बदल दिया या प्रतिस्थापित किया। SSLtelnet, SSLftp, NCSA httpd और कई अन्य पैकेज मेरे काम थे, जो Eric द्वारा लागू किए गए क्रिप्टोग्राफ़िक एल्गोरिदम और प्रोटोकॉल पर आधारित अनुप्रयोग थे। इस मिश्रण ने हम दोनों को वह करने की अनुमति दी जो हमें वास्तव में रुचिकर था, और यही मुख्य कारण है कि यह जारी रहा।

ऑस्ट्रेलिया में होना ही इस समस्या को हल करने की संभावना बनाता था, और फिर पता चला कि कई अन्य लोगों को भी बिल्कुल वही समस्या उसी कारण से थी। ब्रिस्बेन में एक विशिष्ट ग्राहक आवश्यकता को पूरा करने के लिए बनाया गया कुछ, संयुक्त राज्य के बाहर सभी के लिए उपयोगी हो गया, और अंततः कई लोगों के लिए भी उपयोगी हो गया।

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

आप तीन दशकों से अधिक समय तक क्रिप्टोग्राफी और इंटरनेट सुरक्षा में काम कर रहे हैं। उस अवधि में खतरे के परिदृश्य में सबसे नाटकीय परिवर्तन क्या रहा, और कौन सी सुरक्षा समस्याएँ तकनीक में विशाल प्रगति के बावजूद आश्चर्यजनक रूप से समान बनी रही?

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

दूसरा परिवर्तन पैमाना और निर्भरता है। 1995 में औसत एप्लिकेशन वह था जो आप स्वयं लिखते थे। आज औसत एप्लिकेशन वह है जिसे आप असेंबल करते हैं, और उसमें अधिकांश कोड उन लोगों द्वारा लिखा गया है जिन्हें आप कभी नहीं मिले और जिनका नाम नहीं जानते। हमले का सतह आपके कोड से आपके निर्भरताओं की ओर स्थानांतरित हो गया है, और अधिकांश संगठनों ने अपने सोच को उसी अनुसार नहीं बदला है।

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

OpenSSL 4.0 अप्रैल 2026 में जारी किया गया, जो कई वर्षों में प्रोजेक्ट की पहली बड़ी रिलीज़ थी। यह रिलीज़ हमें क्रिप्टोग्राफ़िक बुनियादी ढांचे के भविष्य के बारे में क्या बताती है, और कौन से परिवर्तन उन संगठनों के लिए अंततः सबसे अधिक महत्वपूर्ण होंगे जो OpenSSL पर निर्भर हैं?

4.0 को समझने का सबसे उपयोगी पहलू यह है कि यह मुख्यतः एक घटाव रिलीज़ है, और यही इसका उद्देश्य था।

हमने ENGINE इंटरफ़ेस को पूरी तरह हटा दिया। हमने SSLv3 और SSLv2 ClientHello को हटा दिया। हमने कंपाइल टाइम पर अप्रचलित एलिप्टिक कर्व्स और स्पष्ट EC कर्व्स को अक्षम कर दिया। हमने ASN1_STRING को अस्पष्ट बना दिया और बड़ी संख्या में API हस्ताक्षरों को कड़ा किया। यही परिवर्तन लोगों के लिए काम उत्पन्न करते हैं, और यही परिवर्तन महत्वपूर्ण हैं, क्योंकि एक क्रिप्टोग्राफ़िक लाइब्रेरी जो केवल जोड़ती रहती है, सुरक्षित नहीं रह सकती। प्रत्येक अप्रचलित कोड पाथ जो आप जीवित रखते हैं, वह एक हमला सतह है जिसे कोई आपके behalf में रख रहा है और कोई परीक्षण नहीं कर रहा।

कुछ जोड़ भी हैं: Encrypted Client Hello, RFC 8998 समर्थन जिसमें हाइब्रिड SM2/ML‑KEM समूह, cSHAKE, SNMP और SRTP KDFs, TLS 1.2 के लिए नेगोशिएटेड FFDHE। विशेष रूप से ECH एक वास्तविक गोपनीयता अंतर को बंद करता है, क्योंकि Server Name Indication ने TLS 1.3 के जारी होने के बाद से आप जिस प्रत्येक साइट पर जाते हैं उसकी पहचान लीक कर रही थी। लेकिन हटाने ही कहानी हैं।

मैं जो मुख्य बात संगठनों को समझाना चाहता हूँ वह यह है: 4.0 LTS रिलीज़ नहीं है। इसका समर्थन मई 2027 तक रहेगा। वर्तमान दीर्घकालिक स्थिर रिलीज़ 3.5 है, जिसका समर्थन अप्रैल 2030 तक है, और 3.5 में पहले से ही पोस्ट‑क्वांटम एल्गोरिद्म शामिल हैं। यदि आप नवीनतम कोड चाहते हैं, तो 4.0 चलाएँ। यदि आप एक स्थिर लक्ष्य चाहते हैं जिसके आसपास आप पाँच‑साल की माइग्रेशन योजना बना सकें, तो 3.5 चलाएँ। केवल संख्या बड़ी होने के कारण चुनना वह गलती है जो हम हर चक्र में देखते हैं।

पोस्ट‑क्वांटम क्रिप्टोग्राफी एक अनुसंधान समस्या से माइग्रेशन चुनौती की ओर बढ़ी है, और OpenSSL पहले से ही ML‑KEM, ML‑DSA, और SLH‑DSA तथा हाइब्रिड पोस्ट‑क्वांटम कुंजी विनिमय को समर्थन देता है। उन व्यापारिक नेताओं के लिए जो मानते हैं कि क्वांटम कंप्यूटिंग अभी भी बहुत दूर है, आज वे कौन से जोखिमों को नज़रअंदाज़ कर रहे हैं?

सबसे आम गलती यह है कि इसे यह प्रश्न मानना कि क्रिप्टोग्राफ़िक रूप से प्रासंगिक क्वांटम कंप्यूटर कब आएगा। यह गलत चर है। सही प्रश्न है कि आपका डेटा कितने समय तक गोपनीय रहना चाहिए, और आपकी माइग्रेशन में कितना समय लगेगा। दूसरा को पहला से घटाएँ और आपको वास्तविक समय सीमा मिलती है, और कई संगठनों के लिए वह सीमा पहले ही बीत चुकी है।

एन्क्रिप्टेड ट्रैफ़िक को आज ही कैप्चर किया जा सकता है और अनिश्चितकाल तक संग्रहीत किया जा सकता है। यदि उसमें मौजूद जानकारी का संवेदनशीलता क्षितिज बीस साल का है (जैसे रोगी रिकॉर्ड, कर्मचारी फ़ाइलें, बौद्धिक संपदा, कूटनीतिक सामग्री, वित्तीय स्थिति), तो प्रतिद्वंद्वी को अभी क्वांटम कंप्यूटर की आवश्यकता नहीं है। उन्हें केवल अंततः एक चाहिए, और बीच में सस्ता स्टोरेज चाहिए। यह कोई काल्पनिक हमला नहीं है; यह एक फ़ाइलिंग निर्णय है।

दूसरी बात जिसे नज़रअंदाज़ किया जा रहा है वह है कि माइग्रेशन एक ही प्रोजेक्ट नहीं है। कुंजी विनिमय आसान हिस्सा है, और उसका अधिकांश भाग पहले ही हो रहा है: OpenSSL 3.5 ने हाइब्रिड पोस्ट‑क्वांटम कुंजी विनिमय को TLS का डिफ़ॉल्ट बना दिया है, इसलिए कई संगठन अभी बिना निर्णय लिए पोस्ट‑क्वांटम कुंजी समझौता कर रहे हैं। हस्ताक्षर और प्रमाणपत्र पदानुक्रम कठिन हिस्सा है, क्योंकि इसमें प्रमाणपत्र प्राधिकरण, हार्डवेयर ट्रस्ट रूट, फ़र्मवेयर साइनिंग कुंजियाँ, हार्डवेयर सुरक्षा मॉड्यूल, और पंद्रह‑साल के फ़ील्ड जीवन वाले उपकरण शामिल हैं, जो यह मानते थे कि RSA हमेशा ठीक रहेगा।

तीसरी बात वह प्रतिबंध है जिसके लिए कोई बजट नहीं बनाता: पोस्ट‑क्वांटम हस्ताक्षर बड़े होते हैं। एक ML‑DSA‑65 हस्ताक्षर लगभग ECDSA P‑256 हस्ताक्षर से पचास गुना बड़ा होता है, और SLH‑DSA और भी बड़ा है। यह चीज़ों को तोड़ देता है: हैंडशेक आकार, सीमित उपकरण, हार्ड‑कोडेड फ़ील्ड सीमा वाले प्रोटोकॉल, उपग्रह और IoT लिंक। आप इन समस्याओं को परीक्षण द्वारा पाते हैं, न कि मानक पढ़कर।

पोस्ट‑क्वांटम माइग्रेशन की चुनौतियों में से एक यह है कि संगठन शायद ही जानते हों कि उनके अनुप्रयोगों, बुनियादी ढांचे, उपकरणों और तृतीय‑पक्ष निर्भरताओं में क्रिप्टोग्राफी कहाँ उपयोग हो रही है। कंपनियों को कैसे क्रिप्टोग्राफ़िक इन्वेंट्री और क्रिप्टो‑एजिलिटी अपनानी चाहिए ताकि अगली बड़ी एल्गोरिद्म परिवर्तन आपातकाल न बन जाए?

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

आपको देखना होगा। तीन परतें हैं, और उन्हें अलग‑अलग तकनीकों की जरूरत है। आप द्वारा लिखा कोड: स्थिर विश्लेषण, निर्भरता स्कैनिंग, और वर्षों पहले हार्ड‑कोड किए गए एल्गोरिद्म पहचान के लिए grep। आप द्वारा लिंक किया कोड: सॉफ़्टवेयर बिल ऑफ़ मटेरियल्स, जिसे क्रिप्टोग्राफ़िक बिल ऑफ़ मटेरियल्स में विस्तारित किया गया है, जहाँ CBOM काम वास्तव में उपयोगी है। आप द्वारा खरीदा या कनेक्ट किया गया: नेटवर्क अवलोकन, क्योंकि आपके सिस्टम जो वायर्ड पर बातचीत करते हैं वह वास्तविक सत्य है और अक्सर वह नहीं होता जो कोई मानता है।

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

और वह भाग जिसे लगभग सभी छोड़ देते हैं: इसे अभ्यास में लाएँ। ऐसी एजिलिटी जिसे आपने कभी उपयोग नहीं किया, वह एक दावा है, क्षमता नहीं। एक शांत सप्ताहांत चुनें, गैर‑प्रोडक्शन वातावरण में किसी एल्गोरिद्म को बंद करें, और देखें क्या टूटता है। कुछ तो टूटेगा। इसे अपने शेड्यूल पर खोज लेना बेहतर है बजाय एक अनिवार्य आपातकालीन परिवर्तन के दौरान।

एक उपयोगी बाध्यकारी कारक प्रमाणपत्र आयु है। उद्योग बहुत छोटे‑आयु वाले प्रमाणपत्रों की ओर बढ़ रहा है, जिससे मैन्युअल प्रमाणपत्र प्रबंधन असहनीय हो जाता है और वह ऑटोमेशन आवश्यक हो जाता है जिसकी आपको पहले से ही आवश्यकता थी। यदि आप प्रमाणपत्र जारी करने और रोटेशन को सही ढंग से स्वचालित करते हैं, तो आपने अधिकांश वह मशीनरी बना ली है जो भविष्य के एल्गोरिद्म परिवर्तन के लिए आवश्यक होगी।

AI साइबर सुरक्षा रक्षा और हमलावरों की क्षमताओं दोनों को बदल रहा है। आप कहाँ मानते हैं कि AI वास्तव में सुरक्षा समीकरण को बदलता है, और कहाँ संगठनों का ध्यान तकनीक पर अधिक है जबकि वे अधिक मूलभूत कमजोरियों को नज़रअंदाज़ कर रहे हैं?

AI वास्तव में एक चीज़ को बदलता है, और मैं इसे सीधे बता सकता हूँ क्योंकि यह हमारे साथ हुआ है।

इस वर्ष OpenSSL में उजागर किए गए कई कमजोरियों को AI‑संचालित विश्लेषण ने पाया। जनवरी में हमने बारह मुद्दों को ठीक करने वाली रिलीज़ जारी की, जो मूलतः एक शोध समूह द्वारा स्वचालित विश्लेषण से मिली थीं, और उन्होंने रिपोर्ट के साथ पैच भी प्रदान किए। जून में हमने PKCS#7 सत्यापन में एक उच्च‑गंभीरता वाला उपयोग‑के‑बाद‑मुक्ति बग ठीक किया, जिसे एक शोधकर्ता ने AI प्रणाली के साथ काम करते हुए पाया। यह मेमोरी‑सुरक्षा और पार्सिंग बग खोजने में वास्तविक क्षमता परिवर्तन है, जो वर्षों से विशेषज्ञों द्वारा समीक्षा किए गए परिपक्व C कोड में हुआ। मैंने अन्य क्रिप्टोग्राफ़िक लाइब्रेरीज़ में भी यही पैटर्न देखा है। इस वर्ष के Bouncy Castle CVE के एक बैच का विश्लेषण करने पर स्वचालित कोड विश्लेषण की छाप स्पष्ट है।

स्पष्ट निहितार्थ यह है कि यह दोनों पक्षों को प्रभावित करता है। वही तकनीकें उन लोगों के पास भी हैं जो उनका उपयोग करना चाहते हैं, समान कोडबेस पर, और रक्षक के पास विशेष पहुँच नहीं है।

कम स्पष्ट निहितार्थ, और वह जिसे मैं ज़ोर देना चाहूँगा, वह रखरखावकर्ताओं पर पड़ने वाला बोझ है। एक विश्वसनीय दिखने वाली कमजोरियों की रिपोर्ट बनाना अब लगभग मुफ्त है। उसे ट्रायेज़ करना नहीं है। इसमें अभी भी एक मानव विशेषज्ञ का वास्तविक समय लागत आती है। ओपन‑सोर्स सुरक्षा टीमें, जो आमतौर पर छोटी और अक्सर स्वयंसेवक होती हैं, उच्च‑विविधता वाली रिपोर्टों की बढ़ती मात्रा को संभाल रही हैं। अच्छी रिपोर्टें, जैसे मैंने उल्लेख किया शोध, पुनरुत्पादन और पैच के साथ आती हैं। बुरी रिपोर्टें उन लोगों पर सेवा‑अस्वीकार (DoS) हमला हैं जिन पर आप निर्भर हैं। यदि आपका संगठन ओपन‑सोर्स कोड के खिलाफ AI का उपयोग कर रहा है, तो ट्रायेज़ क्षमता को दूसरे छोर पर फंड करें।

जहाँ मेरा मानना है ध्यान गलत दिशा में है: AI आपके सिस्टम को पैच नहीं करता। यह आपके एसेट्स की इन्वेंट्री नहीं बनाता, आपके क्रेडेंशियल्स को नहीं घुमाता, आपके असमर्थित हार्डवेयर को नहीं हटाता, या अगले महीने समाप्त होने वाले प्रमाणपत्र के लिए किसी को जिम्मेदार नहीं बनाता। संगठन AI सुरक्षा टूल खरीदते हैं जबकि वे सॉफ़्टवेयर चलाते हैं जिसमें ज्ञात, अनपैच्ड कमजोरियाँ हैं, तो उनका क्रम गलत है। अनग्लैमरस काम अभी भी वह जोखिम है।

कई संगठन टूल्स में भारी निवेश करते हैं लेकिन कॉन्फ़िगरेशन त्रुटियों, पुरानी प्रणालियों, कमजोर प्रक्रियाओं या खराब घटना तैयारी के कारण असुरक्षित रहते हैं। आप कौन सी सबसे महत्वपूर्ण सुरक्षा गलतियों को लगातार देखते हैं, और हमले से पहले नेतृत्व टीमों को क्या तैयार रखना चाहिए?

सबसे महत्वपूर्ण गलती यह है कि सुरक्षा को एक खरीदारी गतिविधि माना जाता है। टूल्स खरीदे जाते हैं, बजट पूरे होते हैं, डैशबोर्ड हरे होते हैं, और कोई नहीं पूछता कि क्या संगठन वास्तव में बुनियादी चीजें कर सकता है।

दूसरी गलती यह है कि आप नहीं जानते कि आप क्या चलाते हैं। आप उन सॉफ़्टवेयर को पैच नहीं कर सकते जो आपके पास हैं, इसका पता नहीं है, और अधिकांश संगठन वास्तविक सामग्री को एक घटना के दौरान ही खोजते हैं। इसलिए बिल‑ऑफ़‑मैटेरियल्स का काम महत्वपूर्ण है, न कि अनुपालन दस्तावेज़ के रूप में, बल्कि उस चीज़ के रूप में जो आपको दो बजे सुबह तब चाहिए जब कोई महत्वपूर्ण सलाह जारी हो और कोई पूछे कि क्या आप प्रभावित हैं।

तीसरी गलती डिफ़ॉल्ट सेटिंग्स हैं। सिस्टम स्थापित होते हैं, काम करते हैं, और कॉन्फ़िगरेशन कभी नहीं देखा जाता। पाँच साल बाद वह कॉन्फ़िगरेशन एक देयता बन जाता है, और मूल निर्णय लेने वाले लोग अब वहाँ नहीं होते।

चौथी गलती कुंजी और प्रमाणपत्र प्रबंधन को व्यक्तियों पर छोड़ देना है। स्वयं‑निर्मित आउटेज का एक उल्लेखनीय हिस्सा समाप्त हुए प्रमाणपत्रों के कारण होता है, जिन्हें एक व्यक्ति स्प्रेडशीट में चुपचाप ट्रैक कर रहा था, जब तक कि वह नौकरी बदल न ले।

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

फिर इसका अभ्यास करें। एक कार्यशाला अभ्यास, वार्षिक रूप से एक बार, कार्यकारी स्तर पर, अधिक वास्तविक अंतराल उजागर करेगा बनिस्बत एक और टूल के।

जब एक गंभीर साइबर‑अटैक होता है, तो कार्यकारी लोग अचानक तकनीकी, कानूनी, परिचालन और संचार निर्णय भारी दबाव में ले सकते हैं। कौन सी बातें उन संगठनों को अलग करती हैं जो प्रभावी रूप से प्रतिक्रिया देते हैं उन संगठनों से जो घटना को काफी बदतर बना देती हैं?

वे संगठन जो इसे अच्छी तरह संभालते हैं, उन्होंने घटना से पहले महत्वपूर्ण निर्णय ले लिये होते हैं, इसलिए घटना के दौरान वे कार्यान्वयन कर रहे होते हैं, न कि विचार‑विमर्श। यही अधिकांश बात है।

तैयारी के अलावा, कुछ बातें लगातार अच्छे और बुरे प्रतिक्रियाओं को अलग करती हैं।

वे तकनीकी जांच को कार्यकारी और संचार ट्रैक से अलग करते हैं, और उनके बीच एक परिभाषित इंटरफ़ेस बनाते हैं। जब वही लोग घुसपैठ को रोकने और ग्राहक सूचना तैयार करने की कोशिश करते हैं, तो दोनों काम बुरे होते हैं।

वे सुधार से पहले साक्ष्य संरक्षित रखते हैं। समझौता किए गए मशीन को तुरंत पुनः बनाना एक शक्तिशाली प्रवृत्ति है, लेकिन यह वह जानकारी नष्ट कर देता है जिसकी आपको दायरा स्थापित करने के लिए जरूरत है। यदि आप नहीं बता सकते “उन्होंने और क्या छुआ”, तो आप विश्वसनीय रूप से नहीं कह सकते कि घटना समाप्त हो गई है।

वे स्वीकार करते हैं कि प्रारंभिक जानकारी अस्थायी है और उसी अनुसार संवाद करते हैं। अधिकांश प्रतिष्ठात्मक क्षति मैंने देखी, वह ब्रीच से नहीं बल्कि आत्मविश्वासी शुरुआती बयानों से आई, जिन्हें बाद में वापस लेना पड़ा। “यहाँ हम क्या जानते हैं, यहाँ हम अभी नहीं जानते, यहाँ हम आपको कब अपडेट करेंगे” कहना कमजोरी नहीं है। यह वह एकमात्र स्थिति है जिसे आपको उलटना नहीं पड़ेगा।

और सबसे महत्वपूर्ण: वे ऐसी स्थितियाँ बनाते हैं जहाँ इंजीनियर कार्यकारियों को बुरी खबर बता सकते हैं। मैंने सबसे अधिक देखा है कि एक संगठन में कानूनी जोखिम इतना स्पष्ट था कि कोई भी वह व्यक्ति नहीं बनना चाहता जो वास्तव में क्या हुआ लिखे। फिर घटना चुपचाप बिगड़ती है। यदि आपके इंजीनियर अपनी जिम्मेदारी को स्वयं संभाल रहे हैं न कि घटना को, तो आपके पास एक शासन समस्या है जिसे कोई भी टूल ठीक नहीं कर सकता।

OpenSSL एक असामान्य स्थिति में है: यह तकनीकी इकोसिस्टम में व्यापक रूप से उपयोग की जाने वाली महत्वपूर्ण ओपन‑सोर्स बुनियादी ढांचा है, जबकि OpenSSL कॉरपोरेशन व्यावसायिक समुदायों की सेवा पर केंद्रित है, और स्वतंत्र रूप से संचालित OpenSSL फ़ाउंडेशन भी है। सुरक्षा और संगतता के बारे में निर्णय लेते समय, जब यह इंटरनेट के इतने बड़े हिस्से को प्रभावित कर सकता है, तो आप उद्यमों, डेवलपर्स, नियामकों और व्यापक ओपन‑सोर्स समुदाय की आवश्यकताओं को कैसे संतुलित करते हैं?

ईमानदार उत्तर यह है कि आप उन्हें इस तरह संतुलित नहीं करते कि हर निर्णय में सभी को खुश रखें। आप उन्हें एक प्रकाशित नीति के साथ संतुलित करते हैं और उसे पूर्वानुमेय रूप से लागू करते हैं, ताकि लोग आपके आसपास योजना बना सकें, भले ही उन्हें किसी विशेष परिणाम से असहमति हो।

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

संरचनात्मक उत्तर स्वयं विभाजन है। फ़ाउंडेशन ओपन‑सोर्स लाइब्रेरी और उसके आसपास के समुदाय की सेवा के लिए मौजूद है। कॉरपोरेशन व्यावसायिक आवश्यकताओं (समर्थन प्रतिबद्धताएँ, FIPS मान्यताएँ, विशिष्ट समय‑सीमा) वाली संस्थाओं की सेवा के लिए है और पूरे प्रोजेक्ट को वित्तीय रूप से स्थायी बनाता है। इन्हें अलग रखने से न तो किसी सेट की जरूरतें चुपचाप दूसरे के पक्ष में हल होती हैं। जब उद्यम आवश्यकताएँ और समुदाय आवश्यकताएँ वास्तव में टकराती हैं, तो वह टकराव दो संगठनों के बीच होता है जिनकी स्पष्ट जिम्मेदारियाँ हैं, न कि एक व्यक्ति के दिमाग के भीतर।

दूसरा भाग सही सुनना है, जिसके लिए वास्तविक तंत्र चाहिए, न कि अनुमान। यही कारण है कि हम सम्मेलन आयोजित करते हैं, जो इस अक्टूबर प्राग में है, और क्यों समुदाय बुनियादी ढांचा मौजूद है। रखरखावकर्ता के लिए यह बहुत आसान है कि वे उपयोगकर्ताओं की जरूरतों के बारे में आत्मविश्वासी सिद्धांत विकसित करें। उनके साथ कमरे में होना बहुत अधिक उपयोगी है।

10. अगले दशक को देखते हुए, आप कौन सी सुरक्षा या क्रिप्टोग्राफ़िक परिवर्तन को आज भी संगठनों द्वारा कम‑आँकित मानते हैं, और SSL, OpenSSL, और पिछले 30 वर्षों की इंटरनेट सुरक्षा के विकास से कौन से सबक नेताओं को लागू करने चाहिए?

मेरे अनुसार सबसे कम‑आँकित परिवर्तन पोस्ट‑क्वांटम क्रिप्टोग्राफी को एल्गोरिद्म समस्या के रूप में नहीं, बल्कि मशीन पहचान और सभी चीज़ों के नीचे प्रमाणपत्र पदानुक्रम है।

पोस्ट‑क्वांटम कुंजी विनिमय मुख्यतः डिफ़ॉल्ट्स द्वारा हल हो जाएगा, और इसका अधिकांश हिस्सा पहले ही हो चुका है। जो डिफ़ॉल्ट्स द्वारा नहीं हल होगा वह भरोसे का बुनियादी ढांचा है: हार्डवेयर में रूट प्रमाणपत्र, फ़र्मवेयर साइनिंग कुंजियाँ जो उपकरणों में जली हुई हैं, दशकों के शेष सेवा जीवन वाले HSM, औद्योगिक और मेडिकल सिस्टम जो 2040 में भी चलेंगे और जिनमें निर्माण के समय क्रिप्टोग्राफ़िक धारणाएँ बंधी हैं। इन्हें नई लाइब्रेरी संस्करण भेजकर अपडेट नहीं किया जा सकता, और कुछ मामलों में बिल्कुल भी नहीं। इस प्रतिस्थापन समस्या का पैमाना अभी किसी के पूँजी योजना में नहीं दिखता।

इसके साथ एक नियामक परिवर्तन भी चल रहा है। यूरोप में साइबर रेजिलिएंस एक्ट, और अन्य जगहों पर तुलनीय ढाँचे, उन दायित्वों को बदलेंगे जो आप उन सॉफ़्टवेयर को शिप करने पर रखते हैं जिनमें ऐसे घटक हैं जिन्हें आपने नहीं लिखा। अधिकांश संगठन ने यह नहीं सोचा है कि इसका अर्थ उनके ओपन‑सोर्स निर्भरताओं के लिए क्या है, या उन लोगों के लिए जो इसे बनाए रखते हैं।

तीस साल के तीन सबक:

1. बदलाव में घोषित समय से एक दशक अधिक लगता है। SSLv3 को 2015 में अप्रचलित घोषित किया गया, 2016 में डिफ़ॉल्ट रूप से बंद किया गया और आखिरकार अप्रैल 2026 में हमने उसका कोड हटाया। जिस प्रोटोकॉल को सभी असुरक्षित मानते थे, उसे हटाने में ग्यारह साल लगे। पोस्ट-क्वांटम बदलाव की योजना इस वास्तविकता के अनुसार बनाएँ, प्रेस विज्ञप्ति के अनुसार नहीं।
2. डिफ़ॉल्ट सेटिंग ही ऐसा सुरक्षा नियंत्रण है जो बड़े पैमाने पर काम करता है। ऐसा कोई उपाय काम नहीं करेगा जिसमें हर प्रशासक को सही निर्णय लेना ज़रूरी हो। हाइब्रिड पोस्ट-क्वांटम कुंजी आदान-प्रदान इतनी तेज़ी से लागू हुआ क्योंकि वह डिफ़ॉल्ट रूप से चालू है और किसी निर्णय की ज़रूरत नहीं पड़ती। उन लोगों को ध्यान में रखकर डिज़ाइन करें जो आपके दस्तावेज़ कभी नहीं पढ़ेंगे, क्योंकि लगभग सभी इसी श्रेणी में आते हैं।
3. आप जितना समझते हैं, उससे कम लोगों पर निर्भर हैं। दुनिया का लगभग हर संगठन उस क्रिप्टोग्राफ़िक कोड पर निर्भर है जिसका रखरखाव बहुत कम लोग करते हैं। जब ब्रिस्बेन में हम केवल दो लोग थे, तब भी यही सच था। आज दाँव कई गुना बढ़ चुके हैं, फिर भी संरचना मूल रूप से नहीं बदली है। अगले दशक के लिए आपकी जो भी योजना हो, उसका कोई हिस्सा ऐसे रखरखावकर्ता पर निर्भर है जिससे आपने कभी संपर्क नहीं किया और जिसे आप आर्थिक सहायता नहीं दे रहे। उसकी ज़रूरत पड़ने से पहले यह जान लेना उपयोगी है।

उत्कृष्ट साक्षात्कार के लिए धन्यवाद। जो पाठक अधिक जानना चाहते हैं, उन्हें OpenSSL पर जाना चाहिए।