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 क्यासिङ नियमहरूले प्रमाणित अनुरोधका प्रतिक्रिया भण्डारण गर्न पनि सीमा लगाउँछन्, र त्यहीँ नै व्यक्तिगत पृष्ठ डेटा खुलासा बन्छ। प्रोक्सीलाई खुला रिले देखाउनुको सट्टा स्वीकृत क्लाइन्टमा सीमित राख्नुहोस्।

हिट नाप्नुहोस्, स्टपवाच होइन

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

काम, क्यास कुञ्जी र पुनः प्रयोग अनुमति दिने नीति लेख्नुहोस्। क्यास भनेको अप्टिमाइजेसनको पोसाकमा डेटा साझेदारीको निर्णय हो।