VPN मागील कॅशिंग: HTTPS अजूनही काय लपवते

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

TLS सत्र ब्राउझरचे आहे

सामान्य HTTPS मध्ये ब्राउझर साइटशी की वर बोलणी करतो, आणि हातमिळवणीनंतरचे प्रत्येक रेकॉर्ड त्या टोकांच्या जोडीसाठी एन्क्रिप्ट होते. VPN गेटवे स्वतः तयार केलेला बोगदा डिक्रिप्ट करतो आणि नंतर अपारदर्शक TLS रेकॉर्ड पुढे पाठवतो. त्याला गंतव्ये, वेळ आणि आकार दिसतो, विनंतीची ओळ किंवा प्रतिसादाचा मुख्य भाग नाही. हीच अशी सीमा आहे ज्यासोबत प्रत्येक कॅशला राहावे लागते.

ती मोडणारी कोणतीही रचना TLS अडवणुकीची रचना आहे, तिचे प्रमाणपत्र विश्वास आणि उपकरण व्यवस्थापनाचे स्वतःचे परिणाम आहेत.

CONNECT बोगदा आहे, कॅश नाही

स्पष्ट फॉरवर्ड प्रॉक्सी साधारणपणे HTTP CONNECT विनंती घेतो आणि नंतर दोन्ही दिशांना बाइट्स रिले करतो. रिले हा मुख्य शब्द आहे: प्रॉक्सी एन्क्रिप्टेड संभाषणाचे विश्लेषण करत नाही.

curl -sSI -x http://proxy.example:3128 https://example.com/

प्रतिसाद हेडर प्रॉक्सीच्या बोगदा हाताळणीतून येतात, पृष्ठाच्या कॅश केलेल्या प्रतीतून नाही. यशस्वी CONNECT म्हणजे मार्ग चालतो, असे नाही की पुनर्वापरासाठी काही साठवले गेले. पोर्ट 443 कॅशकडे वळवणे त्यालाही TLS बोलायला शिकवत नाही, कारण कॅशिंगला वाचनीय संदेश लागतात. क्लायंट कॉन्फिगरेशनने समर्थित स्पष्ट प्रॉक्सी सेटिंग वापरावी, स्पष्टीकरण नसलेले रीडायरेक्ट नाही.

तुम्ही चालवता ते कॅश करा, तुम्ही ब्राउझ करता ते नाही

जिथे सामग्री तुमची आहे, तिथे रिव्हर्स प्रॉक्सी TLS संपवू शकतो आणि मंजूर प्रतिसाद जाणीवपूर्वक साठवू शकतो. जिथे ती पॅकेज भांडाराची आहे, तिथे प्रकल्प समर्थित आरसा वापरा.

nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"

पहिला आदेश कॅश क्षेत्र कॉन्फिगर आहे का आणि कुठे लागू होते हे दाखवतो, तर दुसरा एका वस्तूसाठी मूळाचे स्वतःचे कॅशिंग निर्देश दाखवतो. सामायिक कॅशने ताजेपणा, कॅश नियंत्रणे आणि प्रस्तुती वेगळे करणारे विनंती गुणधर्म मानले पाहिजेत; private आणि no-store वेगवेगळे अर्थ देतात आणि हिट दर वाढवण्यासाठी कोणतेही काढू नये. HTTP कॅशिंग नियम प्रमाणित विनंत्यांचे प्रतिसाद साठवण्यावरही मर्यादा घालतात, आणि तिथेच वैयक्तिक पृष्ठ डेटा उघड होते. प्रॉक्सी खुला रिले म्हणून दाखवण्याऐवजी मंजूर क्लायंटपुरता मर्यादित ठेवा.

हिट मोजा, स्टॉपवॉच नाही

वेगवान दुसरी विनंती नवीन कॅशने काही केले असे सिद्ध करत नाही, कारण ब्राउझर आणि ऑपरेटिंग सिस्टम स्वतः आक्रमकपणे कॅश करतात. प्रॉक्सीकडून हिट आणि मिस काउंटर मागा आणि नियंत्रित पुनरावृत्तीत मूळाचा रहदारी पहा. ज्ञात वस्तूचा एक पुनरावृत्त डाउनलोड वापरा, आधी कॅश सक्रिय आणि नंतर टाळून, आणि गेलेला वेळ नाही तर मूळाने दिलेले बाइट्स तुलना करा. नंतर अधिकृतता सीमा तपासा: लॉगिन आवश्यक असलेले संसाधन दुसऱ्या क्लायंटला देऊ नये.

काम, कॅश की आणि पुनर्वापरास परवानगी देणारे धोरण नोंदवा. कॅश म्हणजे ऑप्टिमायझेशनच्या पोशाखातील डेटा सामायिकरणाचा निर्णय.