OCSP गोपनीयता: उत्तरदाता प्रमाणपत्र देखता है, आपका URL नहीं

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

अनुरोध एक प्रमाणपत्र पहचानता है

OCSP प्रमाणपत्र पहचानकर्ता एक हैश फ़ंक्शन, जारीकर्ता के दो हैश और लक्ष्य प्रमाणपत्र की क्रम संख्या से बनाया जाता है, जैसा RFC 6960 में निर्दिष्ट है। प्रत्येक फ़ील्ड एक प्रमाणपत्र की ओर संकेत करता है, किसी URL या HTTP अनुरोध की ओर नहीं।

पृष्ठ का पथ, क्वेरी स्ट्रिंग और कोई भी फ़ॉर्म सामग्री मानक पहचानकर्ता में अनुपस्थित है। यह दावा कि उत्तरदाता को सटीक URL मिलता है, प्रमाणपत्र जाँच के अलावा कहीं और से साक्ष्य माँगता है। अनुरोध अब भी एक प्रमाणपत्र और एक क्षण का नाम लेता है, और उत्तरदाता जान सकता है कि कौन-सी सेवा इसे प्रस्तुत करती है।

जो अनुपस्थित है वह पृष्ठ है, पूरा संदर्भ नहीं। एक प्रमाणपत्र जाँच के साथ एक ज्ञात सेवा के साथ एक बार-बार आने वाला स्रोत इनमें से किसी एक अकेले से अधिक जानकारीपूर्ण हो सकता है।

उत्तरदाता वास्तव में क्या देख सकता है

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

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

स्टेपल किया गया उत्तर दूसरा सामान्य पैटर्न है। RFC 6066 का TLS status_request एक्सटेंशन सर्वर को अपने हैंडशेक से एक OCSP उत्तर जोड़ने देता है, इसलिए क्लाइंट उस कनेक्शन के लिए स्वयं स्थिति लाने के बजाय जो दिया गया है उसका सत्यापन करता है। यह बदलाव प्रेक्षक को बदल देता है। लाने का काम सर्वर पक्ष करता है, और क्लाइंट का अपना पता उस कनेक्शन के लिए कभी उत्तरदाता तक नहीं पहुँचता।

स्थिति हैंडशेक में स्टेपल होकर आ सकती है

इनमें से कोई भी बात गारंटी नहीं देती कि क्लाइंट कभी कोई और सत्यापन अनुरोध नहीं करेगा। चेन निर्माण, स्थिति नीति और समर्थित तंत्र कार्यान्वयन के अनुसार भिन्न होते हैं।

एक ब्राउज़र में प्रमाणपत्र दर्शक हर ऑपरेटिंग सिस्टम और VPN क्लाइंट का विवरण नहीं है। एक ही नेटवर्क कैप्चर अलग-अलग सत्यापन सेटिंग्स के अंतर्गत अलग-अलग अर्थ रख सकता है।

कैशिंग एक पृष्ठ एक खोज की धारणा को तोड़ती है

कैशिंग पृष्ठ लोड को खोजों से अलग करती है। ब्राउज़र किसी उत्तर का कुछ समय तक पुन: उपयोग कर सकता है, इसलिए एक पृष्ठ दर्शन का अर्थ एक नेटवर्क अनुरोध नहीं है।

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

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

गोपनीयता के वे विकल्प जो सत्यापन को अक्षुण्ण रखते हैं

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

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

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