आपके लॉक आइकन के पीछे का सर्टिफिकेट उस पेज की घोषणा पहले ही कर चुका था जिसे आपने अभी लॉन्च भी नहीं किया

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

इस तंत्र को Certificate Transparency कहा जाता है, और इसका किसी हैकिंग से कोई लेना देना नहीं है। यह HTTPS सर्टिफिकेट का एक सार्वजनिक और स्थायी रिकॉर्ड है जो 2018 से मौजूद है, मुफ्त में खोजा जा सकता है, और इसमें पहले से ही हर उस होस्टनेम का पूरा इतिहास दर्ज है जिसे इस साइट ने, या किसी भी साइट ने, कभी किसी ऐसे सर्टिफिकेट के पीछे रखा जो बिना ब्राउज़र चेतावनी के काम करता था। लगभग किसी भी ऑपरेटर ने इसमें अपनी खुद की एंट्री कभी देखी ही नहीं। यहां असली खाली जगह यही है जिसे भरने की जरूरत है, यह सामान्य अर्थों में कोई कमजोरी नहीं है, बल्कि एक ऐसा रिकॉर्ड है जो हमेशा से सार्वजनिक था मगर उसे कभी वैसा माना ही नहीं गया।

जारी होते ही एक सर्टिफिकेट चुपचाप क्या बन जाता है

2018 से, सार्वजनिक रूप से भरोसेमंद सर्टिफिकेट, वह तरह जिसकी वजह से Chrome और Safari चेतावनी के बजाय एक सामान्य लॉक आइकन दिखाते हैं, को कई Certificate Transparency लॉग में से किसी एक में दर्ज होना ही पड़ता है, वरना ये ब्राउज़र उस पर भरोसा नहीं करते। Apple ने उसी साल बाद में Safari के लिए भी यही शर्त जोड़ दी। इसका मकसद खास तौर पर वयस्क साइटों या क्लासिफाइड डायरेक्टरीज को निशाना बनाना नहीं था; इसे इसलिए बनाया गया था ताकि कोई किसी और के डोमेन के लिए चुपके से नकली सर्टिफिकेट जारी करके उसका ट्रैफिक न रोक पाए। इसका एक साइड इफेक्ट यह है कि यह लॉग हर उस असली सर्टिफिकेट को भी दर्ज करता है जो कोई साइट खुद के लिए हासिल करती है, और यह रिकॉर्ड कभी भी निजी रहने के लिए नहीं बनाया गया था।

यह लॉग नाम के साथ हर उस होस्ट को सूचीबद्ध करता है जिसे कोई सर्टिफिकेट असल में कवर करता है। admin.example.com के लिए जारी किया गया सर्टिफिकेट ठीक वही नाम, साफ टेक्स्ट में, हमेशा के लिए दिखाता है। इससे कोई फर्क नहीं पड़ता कि उस नाम के पीछे वाला पेज कभी साइट के मेनू से लिंक किया गया था, साइटमैप में जिक्र हुआ था, या किसी सर्च इंजन में इंडेक्स हुआ था। सर्टिफिकेट अथॉरिटी ने उसे जारी होते ही उसी पल दर्ज कर लिया, चाहे वह Let's Encrypt हो, Cloudflare हो, या ज्यादातर होस्टिंग पैनलों में built-in ऑटोमैटिक सर्टिफिकेट मैनेजर हो, क्योंकि ये सब एक जैसे ब्राउज़र नियमों के अधीन हैं।

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

यहां एक असली अपवाद है, और वह आगे आने वाली हर बात के लिए मायने रखता है: एक वाइल्डकार्ड सर्टिफिकेट, वह जो किसी एक सटीक नाम के बजाय *.example.com जैसे पूरे पैटर्न को कवर करता है, लॉग में सिर्फ वह पैटर्न ही दर्ज करता है। जो विशिष्ट होस्टनेम असल में उसका इस्तेमाल करते हैं, जैसे newcity.example.com या staging.example.com, वे लॉग में नाम के साथ दिखाई नहीं देते। वहीं एक सटीक सबडोमेन के लिए समर्पित सर्टिफिकेट हमेशा नाम के साथ दिखाई देता है। यही फर्क वह असली लीवर है जो एक ऑपरेटर के पास वाकई होता है, और यह आगे फिर से आएगा।

यह वाकई किसी अजनबी के हाथ में क्या सौंप देता है, तीन ठोस तरीकों से

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

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

तीसरा है एक ऐसा इतिहास जिसे कोई वापस नहीं ले सकता। लॉग कुछ भूलता नहीं। तीन साल पुराना कोई टेस्ट सबडोमेन, किसी ऐसे पार्टनर के लिए बना कम उम्र का पेज जो अब मौजूद ही नहीं, या कोई staging कॉपी जिसे किसी डेवलपर ने हटाने का इरादा किया था मगर भूल गया: यह सब हमेशा के लिए लॉग में रह जाता है, यहां तक कि सर्टिफिकेट एक्सपायर होने के बाद भी, और उसकी ओर इशारा करने वाला DNS रिकॉर्ड हटाए जाने के बाद भी। आज crt.sh पर कोई डोमेन खोजने से ऐसे नाम सामने आ सकते हैं जिन्हें मौजूदा टीम में किसी को बनाना याद ही नहीं। खतरनाक हिस्सा वह एंट्री खुद नहीं है, बल्कि यह संभावना है कि उस पते पर पहले जवाब देने वाला सर्वर अब भी वहीं खड़ा है, कभी अपडेट नहीं हुआ, क्योंकि सबने मान लिया कि लिंक हटाना उसे बंद करने के बराबर है।

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

इनमें से कुछ भी क्या नहीं रोकता, और वाकई क्या काम करता है

उन्हीं टूल्स की ओर मुड़ना लुभावना लगता है जो यह तय करते हैं कि सर्च इंजन किसी साइट को कैसे देखते हैं, लेकिन यहां उनमें से कोई काम नहीं आता। यह डायरेक्टरी कौन से क्रॉलर कौन से पेज देख सकते हैं को लेकर जो फैसले पहले से लेती है, वे robots.txt और सर्च इंजन इंडेक्सिंग के जरिए चलते हैं, एक बिल्कुल अलग सिस्टम जिसके बारे में किसी सर्टिफिकेट लॉग ने कभी सुना ही नहीं। किसी बॉट को ब्लॉक करना, किसी पेज को डीइंडेक्स करना, या उसे noindex मार्क करना, इससे कुछ नहीं बदलता कि उसका सर्टिफिकेट लॉग में दिखेगा या नहीं, क्योंकि लॉग सर्टिफिकेट को खुद दर्ज करता है, न कि सर्च इंजनों के सामने पेज की दृश्यता को।

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

बाद में किसी सबडोमेन का नाम बदलना या उसे मिटा देना भी कुछ ठीक नहीं करता, क्योंकि लॉग में पुरानी एंट्री ठीक वहीं रह जाती है जहां वह थी। इस तरह पहले से दर्ज हो चुके किसी नाम के लिए कोई पिछली तारीख से सफाई उपलब्ध नहीं है: एक ऑपरेटर वाकई जो बदल सकता है, वह सिर्फ यह है कि अब से आगे क्या होता है।

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

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

इस हफ्ते वाकई क्या जांचना है

पहला कदम कुछ खर्च नहीं करता और पांच मिनट लेता है: crt.sh खोलें, इस साइट का अपना डोमेन टाइप करें, और जो कुछ भी सामने आए उसकी पूरी लिस्ट पढ़ें। कोई भी अनजान एंट्री होस्टिंग संभालने वाले से सीधा सवाल पूछने लायक है: क्या यह अब भी चल रहा है, और अगर हां, तो आज सार्वजनिक इंटरनेट को इसका पता क्यों मालूम है।

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

अगले किसी नए शहर या देश के लॉन्च के लिए, टेस्टिंग चरण को उस शहर के ठीक-ठीक नाम वाले सर्टिफिकेट के बजाय किसी वाइल्डकार्ड सर्टिफिकेट या साझा आंतरिक सर्टिफिकेट के नीचे चलना चाहिए, ताकि लॉग मार्केटिंग से पहले ही विस्तार की घोषणा न कर दे। यह अगले लॉन्च से पहले किसी डेवलपर या होस्टिंग प्रोवाइडर से पक्का करने लायक एक अकेली सेटिंग है, पहले से लाइव किसी चीज का दोबारा निर्माण नहीं।

आज पहले से चल रहे हर आंतरिक लॉगिन, मॉडरेशन, या बिलिंग पेज के लिए, सवाल यह नहीं है कि उसका नाम अंदाजा लगाने में कितना मुश्किल है। सवाल यह है कि नाम चाहे जो भी हो, उसके आगे एक असली पासवर्ड और, जहां मुमकिन हो, पते पर आधारित पाबंदी मौजूद है या नहीं, क्योंकि एक बार जब नाम खुद ही सार्वजनिक हो चुका हो, तो वाकई टिकने वाली चीज यही है, और crt.sh जांचने के बाद यह बात ज्यादातर मामलों में पहले से ही सच निकलेगी।