OCSP ગોપનીયતા: પ્રતિસાદકર્તા પ્રમાણપત્ર જુએ છે, તમારું URL નહીં
OCSP વિનંતી પૃષ્ઠનો માર્ગ નહીં, પરંતુ પ્રમાણપત્ર અને સમયની ક્ષણ ઓળખે છે. સ્ટેપલિંગ, કેશિંગ અને ક્લાયન્ટ નીતિ નક્કી કરે છે કે તપાસ કોણ નિરીક્ષણ કરે છે.
સ્થિતિ તપાસ એક પ્રમાણપત્ર વિશે એક પ્રશ્ન પૂછે છે, અને જવાબ તેના પોતાના જોડાણ પર મુસાફરી કરે છે. તેમાં તે પૃષ્ઠનો માર્ગ હોતો નથી જે તપાસ તરફ દોરી ગયો. ગોપનીયતાની ચર્ચાઓ આ વિનિમયને ઘણીવાર બ્રાઉઝિંગ ઇતિહાસની ફીડ તરીકે ગણે છે, જે વિનંતી શું વહન કરે છે તેને વધારીને બતાવે છે અને પ્રતિસાદકર્તા શું નિરીક્ષણ કરી શકે તેને ઓછું આંકે છે. તે શું જાહેર કરે છે તે નક્કી કરતા પહેલાં વિનંતી વાંચો.
વિનંતી એક પ્રમાણપત્ર ઓળખે છે
OCSP પ્રમાણપત્ર ઓળખકર્તા હેશ ફંક્શન, બે ઇશ્યુઅર હેશ અને લક્ષ્ય પ્રમાણપત્રની સીરિયલ નંબરમાંથી બનાવવામાં આવે છે, જેમ RFC 6960 માં નિર્દિષ્ટ છે. દરેક ક્ષેત્ર એક પ્રમાણપત્ર તરફ નિર્દેશ કરે છે, URL કે HTTP વિનંતી તરફ નહીં.
પૃષ્ઠનો માર્ગ, ક્વેરી સ્ટ્રિંગ અને કોઈપણ ફોર્મ સામગ્રી પ્રમાણભૂત ઓળખકર્તામાં ગેરહાજર છે. પ્રતિસાદકર્તાને ચોક્કસ URL મળે છે એવા દાવા માટે પ્રમાણપત્ર તપાસ સિવાય બીજે ક્યાંકથી પુરાવાની જરૂર છે. વિનંતી હજી પણ એક પ્રમાણપત્ર અને એક ક્ષણનું નામ લે છે, અને પ્રતિસાદકર્તા જાણી શકે છે કે કઈ સેવા તેને રજૂ કરે છે.
જે ખૂટે છે તે પૃષ્ઠ છે, આખો સંદર્ભ નહીં. પ્રમાણપત્ર તપાસ સાથે જાણીતી સેવા સાથે પુનરાવર્તિત સ્રોત એમાંથી કોઈ એક કરતાં વધુ માહિતીપ્રદ હોઈ શકે છે.
પ્રતિસાદકર્તા ખરેખર શું નિરીક્ષણ કરી શકે છે
પ્રતિસાદકર્તા તેની સુધી પહોંચતું જોડાણ જુએ છે: સ્રોત સરનામું, સમય અને તેની તૈનાતી જે પરિવહન મેટાડેટા નોંધે છે તે. જો સ્થિતિ વિનંતી VPN ને અનુસરે છે, તો તે સ્રોત વપરાશકર્તાના એક્સેસ નેટવર્કને બદલે VPN એક્ઝિટ હોઈ શકે છે. ફક્ત એટલા માટે ન ધારો કે સ્થિતિ વિનંતી પૃષ્ઠ વિનંતી જેવો જ માર્ગ લે છે કારણ કે બંને એક બ્રાઉઝર સત્રના છે.
એક જ ટ્રેસમાંથી અનુમાન કરવાને બદલે ક્લાયન્ટનું સમર્થિત રાઉટિંગ અને ચકાસણી વર્તન તપાસો. વિભાજિત ટનલ બે વિનંતીઓને જુદી જુદી દિશામાં મોકલી શકે છે.
સ્ટેપલ કરેલો પ્રતિસાદ બીજી સામાન્ય પેટર્ન છે. RFC 6066 નું TLS status_request એક્સટેન્શન સર્વરને પોતાના હેન્ડશેક સાથે OCSP પ્રતિસાદ જોડવા દે છે, જેથી ક્લાયન્ટ તે જોડાણ માટે જાતે સ્થિતિ લેવાને બદલે જે આપવામાં આવ્યું છે તેની ચકાસણી કરે છે. તે પરિવર્તન નિરીક્ષકને બદલી નાખે છે. લેવાનું કામ સર્વર બાજુ કરે છે, અને ક્લાયન્ટનું પોતાનું સરનામું તે જોડાણ માટે ક્યારેય પ્રતિસાદકર્તા સુધી પહોંચતું નથી.
હેન્ડશેકમાં સ્ટેપલ થયેલી સ્થિતિ આવી શકે છે
આમાંથી કંઈપણ ખાતરી આપતું નથી કે ક્લાયન્ટ ક્યારેય બીજી ચકાસણી વિનંતી કરશે નહીં. ચેઇન બાંધકામ, સ્થિતિ નીતિ અને સમર્થિત પદ્ધતિઓ અમલીકરણ પ્રમાણે બદલાય છે.
એક બ્રાઉઝરમાં પ્રમાણપત્ર દર્શક દરેક ઓપરેટિંગ સિસ્ટમ અને VPN ક્લાયન્ટનું વર્ણન નથી. એક જ નેટવર્ક કેપ્ચર જુદા જુદા ચકાસણી સેટિંગ્સ હેઠળ જુદા જુદા અર્થ આપી શકે છે.
કેશિંગ એક પૃષ્ઠ એક શોધની ધારણા તોડે છે
કેશિંગ પૃષ્ઠ લોડને શોધોથી અલગ કરે છે. બ્રાઉઝર એક સમયગાળા માટે પ્રતિસાદ ફરી વાપરી શકે છે, તેથી એક પૃષ્ઠ દર્શનનો અર્થ એક નેટવર્ક વિનંતી નથી.
વિરુદ્ધ ભૂલ એટલી જ સામાન્ય છે. કેશ કરેલો પ્રતિસાદ આગલું રિફ્રેશ ક્યારે થશે તે વિશે કંઈ કહેતો નથી, અને રિફ્રેશ સમયપત્રક ખૂલી રહેલા પૃષ્ઠ સાથે સંબંધિત ન પણ હોય. કેપ્ચરને OCSP સાથે જોડતા પહેલાં ક્લાયન્ટના વર્તમાન દસ્તાવેજીકરણ અને અમલમાં રહેલી ચકાસણી નીતિનો ઉપયોગ કરો.
માન્ય સ્થિતિ પ્રતિસાદે ચકાસનારની પ્રામાણિકતા અને તાજગીના નિયમો પૂરા કરવા પડે છે, અને HTTP 200 સારી સ્થિતિ સમાન નથી. સમયસમાપ્તિ રદ કરવું નથી. તે પરિણામો જુદા જુદા ક્લાયન્ટ વર્તન તરફ દોરે છે અને તેમને એક ભૂલમાં ભેગા ન કરવા જોઈએ.
ગોપનીયતાની પસંદગીઓ જે ચકાસણી અકબંધ રાખે છે
જ્યાં શોધ પોતે સંવેદનશીલ છે, ત્યાં સિસ્ટમ માલિક સાથે સમર્થિત ડિલિવરી અને કેશિંગ વિકલ્પોની ચર્ચા કરો. રદ કરવાની તપાસ અથવા ચેઇન ચકાસણી બંધ કરીને તેને ઉકેલશો નહીં.
વધુ શાંત ટ્રેસ વધુ સુરક્ષિત જોડાણ નથી. પીઅર ઓળખ, ચેઇન ચકાસણી અને ઇચ્છિત રદ કરવાની નીતિ અકબંધ રાખો, અને ડિલિવરી માર્ગ ફક્ત તે વિકલ્પ દ્વારા બદલો જે તૈનાતી સમર્થન આપે છે. કયો વિકલ્પ પસંદ કરવામાં આવ્યો અને તેનો માલિક કોણ છે તે નોંધો.
જ્યારે કોઈ શોધ અણધારી રીતે દેખાય, ત્યારે પ્રાપ્તકર્તા, માર્ગ અને પ્રમાણપત્ર ક્રિયા અલગ અલગ નામ આપો. ઇશ્યુઅર ડાઉનલોડ, સ્થિતિ ક્વેરી અને પૃષ્ઠ વિનંતી ત્રણ ઘટનાઓ છે. તેમને એક તરીકે ગણવાથી ગોપનીયતા સમીક્ષા અચોક્કસ બને છે અને કયા પક્ષે ખરેખર કંઈક શીખ્યું તે છુપાય છે. પ્રોટોકોલ ક્ષેત્રોથી શરૂ કરો અને નેટવર્ક માર્ગ તરફ બહાર જાઓ.