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 कैशिंग नियम प्रमाणित अनुरोधों के प्रतिक्रियाओं को संग्रहीत करने को भी सीमित करते हैं, और ठीक वहीं व्यक्तिगत पृष्ठ डेटा के खुलासे में बदल जाता है। प्रॉक्सी को खुला रिले दिखाने के बजाय स्वीकृत क्लाइंट तक सीमित रखें।

हिट मापें, स्टॉपवॉच नहीं

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

कार्यभार, कैश कुंजी और वह नीति दर्ज करें जिसने पुन: उपयोग की अनुमति दी। कैश अनुकूलन के वेश में डेटा साझा करने का निर्णय है।