OCSP गोपनीयता: प्रतिसादक प्रमाणपत्र पाहतो, तुमचा URL नाही

स्थिती तपासणी एका प्रमाणपत्राबद्दल एक प्रश्न विचारते, आणि उत्तर स्वतःच्या कनेक्शनवर प्रवास करते. तपासणीकडे नेणारा पृष्ठाचा मार्ग त्यात नसतो. गोपनीयतेच्या चर्चा या देवाणघेवाणीकडे ब्राउझिंग इतिहासाची फीड म्हणून पाहतात, ज्यामुळे विनंती काय वाहते ते जास्त आणि प्रतिसादक काय पाहू शकतो ते कमी मानले जाते. ती काय उघड करते हे ठरवण्यापूर्वी विनंती वाचा.

विनंती एक प्रमाणपत्र ओळखते

OCSP प्रमाणपत्र ओळखकर्ता हॅश फंक्शन, जारीकर्त्याचे दोन हॅश आणि लक्ष्य प्रमाणपत्राचा अनुक्रमांक यांपासून तयार होतो, जसे RFC 6960 मध्ये निर्दिष्ट आहे. प्रत्येक क्षेत्र एका प्रमाणपत्राकडे निर्देश करते, URL किंवा HTTP विनंतीकडे नाही.

पृष्ठाचा मार्ग, क्वेरी स्ट्रिंग आणि कोणताही फॉर्म मजकूर मानक ओळखकर्त्यात नाही. प्रतिसादकाला नेमका URL मिळतो या दाव्यासाठी प्रमाणपत्र तपासणीशिवाय दुसरीकडून पुरावा लागतो. विनंती अजूनही एक प्रमाणपत्र आणि एक क्षण नावाने सांगते, आणि ते कोणती सेवा सादर करते हे प्रतिसादकाला माहीत असू शकते.

जे नाही ते पृष्ठ आहे, संपूर्ण संदर्भ नाही. प्रमाणपत्र तपासणीबरोबर ओळखीची सेवा आणि पुनरावृत्ती होणारा स्रोत यांच्या पैकी कशाहीपेक्षा अधिक माहिती देऊ शकतात.

प्रतिसादक प्रत्यक्षात काय पाहू शकतो

प्रतिसादक त्याच्यापर्यंत पोहोचणारे कनेक्शन पाहतो: स्रोत पत्ता, वेळ आणि त्याची तैनाती नोंदवते तो कोणताही वाहतूक मेटाडेटा. स्थिती विनंती VPNचे अनुसरण करत असेल, तर तो स्रोत वापरकर्त्याचे प्रवेश नेटवर्क नसून VPN निर्गम असू शकतो. दोन्ही एकाच ब्राउझर सत्राचे आहेत एवढ्याच कारणाने स्थिती विनंती पृष्ठ विनंतीसारखाच मार्ग घेते असे गृहीत धरू नका.

एका ट्रेसवरून अनुमान काढण्याऐवजी क्लायंटला समर्थित राउटिंग आणि पडताळणी वर्तन तपासा. विभाजित टनेल दोन्ही विनंत्या वेगवेगळ्या दिशांनी पाठवू शकते.

स्टेपल केलेला प्रतिसाद हा दुसरा सामान्य नमुना आहे. RFC 6066 मधील TLS status_request विस्तार सर्व्हरला त्याच्या स्वतःच्या हँडशेकला OCSP प्रतिसाद जोडण्याची परवानगी देतो, त्यामुळे क्लायंट त्या कनेक्शनसाठी स्वतः स्थिती आणण्याऐवजी दिलेले प्रमाणित करतो. हा बदल निरीक्षक बदलतो. आणण्याचे काम सर्व्हर बाजू करते, आणि क्लायंटचा स्वतःचा पत्ता त्या कनेक्शनसाठी कधीही प्रतिसादकापर्यंत पोहोचत नाही.

स्थिती हँडशेकमध्ये स्टेपल होऊन येऊ शकते

यापैकी काहीही क्लायंट कधीही दुसरी पडताळणी विनंती करणार नाही याची हमी देत नाही. साखळी बांधणी, स्थिती धोरण आणि समर्थित यंत्रणा अंमलबजावणीनुसार बदलतात.

एका ब्राउझरमधील प्रमाणपत्र दर्शक प्रत्येक ऑपरेटिंग सिस्टम आणि VPN क्लायंटचे वर्णन नाही. एकच नेटवर्क कॅप्चर वेगवेगळ्या पडताळणी सेटिंग्जमध्ये वेगळे अर्थ देत असू शकते.

कॅशिंग एक पृष्ठ एक शोध हे गृहीतक तोडते

कॅशिंग पृष्ठ लोड आणि शोध वेगळे करते. ब्राउझर काही काळ प्रतिसाद पुन्हा वापरू शकतो, म्हणून एक पृष्ठ भेट म्हणजे एक नेटवर्क विनंती नाही.

उलट चूक तितकीच सामान्य आहे. कॅश केलेला प्रतिसाद पुढील रीफ्रेश कधी होईल हे सांगत नाही, आणि रीफ्रेश वेळापत्रक उघडल्या जाणाऱ्या पृष्ठाशी संबंधित नसू शकते. कॅप्चरचे OCSPशी नाते जोडण्यापूर्वी क्लायंटचे सध्याचे दस्तऐवज आणि लागू पडताळणी धोरण वापरा.

वैध स्थिती प्रतिसादाने पडताळणीकर्त्याचे प्रामाणिकपणा आणि ताजेपणाचे नियम पूर्ण केले पाहिजेत, आणि HTTP 200 चांगल्या स्थितीइतके नाही. कालबाह्यता रद्द करणे नाही. ही परिणाम वेगळ्या क्लायंट वर्तनाकडे नेतात आणि त्यांना एका त्रुटीत एकत्र करू नये.

पडताळणी अखंड ठेवणारे गोपनीयता पर्याय

शोध स्वतः संवेदनशील असेल, तेथे सिस्टम मालकाशी समर्थित वितरण आणि कॅशिंग पर्यायांवर चर्चा करा. रद्दीकरण तपासणी किंवा साखळी पडताळणी बंद करून ते सोडवू नका.

अधिक शांत ट्रेस अधिक सुरक्षित कनेक्शन नाही. पीअर ओळख, साखळी पडताळणी आणि इच्छित रद्दीकरण धोरण अखंड ठेवा, आणि वितरण मार्ग फक्त तैनातीला समर्थित पर्यायानेच बदला. कोणता पर्याय निवडला आणि त्याचा मालक कोण आहे ते नोंदवा.

शोध अनपेक्षितपणे दिसल्यास प्राप्तकर्ता, मार्ग आणि प्रमाणपत्र क्रिया वेगवेगळे नावाने सांगा. जारीकर्ता डाउनलोड, स्थिती क्वेरी आणि पृष्ठ विनंती या तीन घटना आहेत. त्यांना एक मानल्यास गोपनीयता आढावा अचूक राहत नाही आणि कोणत्या पक्षाने खरेच काही शिकले हे लपते. प्रोटोकॉल क्षेत्रांपासून सुरुवात करा आणि नेटवर्क मार्गाकडे बाहेर जा.