OCSP गोपनीयता: उत्तरदाताले प्रमाणपत्र देख्छ, तपाईंको URL होइन

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

अनुरोधले एउटा प्रमाणपत्र पहिचान गर्छ

OCSP प्रमाणपत्र पहिचानकर्ता ह्यास फङ्सन, जारीकर्ताका दुई ह्यास र लक्ष्य प्रमाणपत्रको क्रम संख्याबाट बनाइन्छ, जसरी RFC 6960 मा निर्दिष्ट छ। प्रत्येक क्षेत्रले एउटा प्रमाणपत्रतर्फ संकेत गर्छ, URL वा HTTP अनुरोधतर्फ होइन।

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

अनुपस्थित पृष्ठ हो, सम्पूर्ण सन्दर्भ होइन। प्रमाणपत्र जाँचसँगै परिचित सेवा र दोहोरिने स्रोत थप्दा तीमध्ये कुनै एउटाभन्दा बढी जानकारी दिन सक्छ।

उत्तरदाताले वास्तवमा के अवलोकन गर्न सक्छ

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

एउटै ट्रेसबाट अनुमान गर्नुको सट्टा ग्राहकले समर्थन गर्ने राउटिङ र प्रमाणीकरण व्यवहार जाँच्नुहोस्। विभाजित टनेलले दुई अनुरोधलाई फरक दिशामा पठाउन सक्छ।

स्टेपल गरिएको प्रतिक्रिया अर्को सामान्य ढाँचा हो। RFC 6066 को TLS status_request एक्सटेन्सनले सर्भरलाई आफ्नै ह्यान्डसेकमा OCSP प्रतिक्रिया जोड्न दिन्छ, त्यसैले ग्राहकले त्यो जडानका लागि आफैं स्थिति ल्याउनुको सट्टा दिइएको कुरा प्रमाणित गर्छ। त्यो परिवर्तनले अवलोकनकर्ता बदल्छ। ल्याउने काम सर्भर पक्षले गर्छ, र ग्राहकको आफ्नै ठेगाना त्यो जडानका लागि कहिल्यै उत्तरदातासम्म पुग्दैन।

स्थिति ह्यान्डसेकमा स्टेपल भएर आउन सक्छ

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

एउटा ब्राउजरको प्रमाणपत्र दर्शक हरेक अपरेटिङ सिस्टम र VPN ग्राहकको वर्णन होइन। एउटै सञ्जाल क्याप्चरले फरक प्रमाणीकरण सेटिङमा फरक अर्थ राख्न सक्छ।

क्यासिङले एक पृष्ठ एक खोज भन्ने मान्यता तोड्छ

क्यासिङले पृष्ठ लोड र खोजलाई अलग गर्छ। ब्राउजरले केही समय प्रतिक्रिया पुनः प्रयोग गर्न सक्छ, त्यसैले एक पटक पृष्ठ हेर्दा एक सञ्जाल अनुरोध हुन्छ भन्ने होइन।

उल्टो गल्ती पनि उत्तिकै सामान्य छ। क्यास गरिएको प्रतिक्रियाले अर्को रिफ्रेस कहिले हुन्छ भन्ने केही भन्दैन, र रिफ्रेस तालिका खोलिएको पृष्ठसँग असम्बन्धित हुन सक्छ। क्याप्चरलाई OCSPसँग जोड्नुअघि ग्राहकको हालको कागजात र लागू प्रमाणीकरण नीति प्रयोग गर्नुहोस्।

मान्य स्थिति प्रतिक्रियाले प्रमाणकको प्रामाणिकता र ताजापनका नियम पूरा गर्नुपर्छ, र HTTP 200 राम्रो स्थितिसरह हुँदैन। समय सकिनु रद्द हुनु होइन। यी परिणामले फरक ग्राहक व्यवहारतर्फ लैजान्छन् र तिनलाई एउटै त्रुटिमा मिलाउनु हुँदैन।

प्रमाणीकरण अक्षुण्ण राख्ने गोपनीयता विकल्प

जहाँ खोज आफैं संवेदनशील छ, त्यहाँ प्रणाली मालिकसँग समर्थित डेलिभरी र क्यासिङ विकल्पबारे छलफल गर्नुहोस्। रद्दीकरण जाँच वा चेन प्रमाणीकरण बन्द गरेर यसलाई समाधान नगर्नुहोस्।

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

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