क्या प्रॉक्सी सर्वर कैश एसएसएल प्राप्त कर सकता है? यदि नहीं, प्रतिक्रिया शरीर एन्क्रिप्शन पर्याप्त होगा?

Question

क्या कोई (|| कोई भी) प्रॉक्सी सर्वर कैश सामग्री जिसे ग्राहक द्वारा https पर अनुरोध किया जाता है? चूंकि प्रॉक्सी सर्वर क्वेरीस्ट्रिंग, या http शीर्षलेख नहीं देख सकता है, मुझे लगता है कि वे नहीं कर सकते हैं।

मैं डेस्कटॉप अनुप्रयोग पर विचार कर रहा हूं, जो कि उनकी कंपनियों प्रॉक्सी के पीछे कई लोगों द्वारा चलाया जाता है। यह एप्लिकेशन इंटरनेट पर सेवाओं तक पहुंच सकता है और मैं 'रीड' के लिए इन-बिल्ट इंटरनेट कैशिंग इंफ्रास्ट्रक्चर का लाभ लेना चाहता हूं। यदि कैशिंग प्रॉक्सी सर्वर एसएसएल वितरित सामग्री को कैश नहीं कर सकता है, तो क्या प्रतिक्रिया की सामग्री को एन्क्रिप्ट करना एक व्यावहारिक विकल्प होगा?

मैं सभी जीईटी अनुरोधों पर विचार कर रहा हूं कि हम असमर्थित एन्क्रिप्शन का उपयोग करके एन्क्रिप्टेड शरीर के साथ http पर कैचबल से अनुरोध किया जाना चाहिए, जहां प्रत्येक क्लाइंट में डिक्रिप्शन कुंजी होती है। जब भी हम एक जीईटी करना चाहते हैं जो कैच करने योग्य नहीं है, या पोस्ट ऑपरेशन है, तो यह एसएसएल पर किया जाएगा।

Answer 1

नहीं, सीधे https को कैश करना संभव नहीं है। क्लाइंट और सर्वर के बीच पूरा संचार एन्क्रिप्ट किया गया है। एक प्रॉक्सी सर्वर और क्लाइंट के बीच बैठता है, इसे कैश करने के लिए, आपको इसे पढ़ने में सक्षम होना चाहिए, यानी एन्क्रिप्शन को डिक्रिप्ट करना।

आप इसे कैश करने के लिए कुछ कर सकते हैं। क्लाइंट को भेजे गए एसएसएल को अवरुद्ध करते हुए, आप मूल रूप से अपने प्रॉक्सी पर एसएसएल करते हैं। असल में डेटा क्लाइंट और आपकी प्रॉक्सी के बीच एन्क्रिप्ट किया जाता है, यह डिक्रिप्ट, पढ़ा और कैश किया जाता है, और डेटा एन्क्रिप्ट किया जाता है और सर्वर पर भेजा जाता है। सर्वर से उत्तर भी अवरुद्ध, पढ़ा और एन्क्रिप्टेड है। मुझे यकीन नहीं है कि आप इसे प्रमुख प्रॉक्सी सॉफ़्टवेयर (जैसे स्क्विड) पर कैसे करते हैं, लेकिन यह संभव है।

इस दृष्टिकोण के साथ एकमात्र समस्या यह है कि प्रॉक्सी को क्लाइंट को एन्क्रिप्ट करने के लिए स्वयं हस्ताक्षरित प्रमाणपत्र का उपयोग करना होगा। ग्राहक यह बताने में सक्षम होगा कि बीच में प्रॉक्सी ने डेटा पढ़ा है, क्योंकि प्रमाणपत्र मूल साइट से नहीं होगा।

Answer 2

रोरी द्वारा टिप्पणी कि प्रॉक्सी को एक आत्म-हस्ताक्षरित प्रमाणपत्र का उपयोग करना होगा यदि कठोर रूप से सत्य नहीं है।

प्रत्येक नए एसएसएल होस्ट के लिए एक नया प्रमाण उत्पन्न करने के लिए प्रॉक्सी लागू किया जा सकता है जिसे इसे सामान्य रूट प्रमाण से निपटने और हस्ताक्षर करने के लिए कहा जाता है। ओपी के एक कॉरपोरेट वातावरण के परिदृश्य में, सामान्य हस्ताक्षर प्रमाण क्लाइंट मशीनों पर एक विश्वसनीय सीए के रूप में आसानी से स्थापित किया जा सकता है और वे यातायात के लिए इन "फिक्र" एसएसएल कर्टों को खुशी से स्वीकार करेंगे क्योंकि कोई होस्टनाम मेल नहीं होगा।

वास्तव में यह ठीक है कि कैसे इस तरह के सॉफ्टवेयर Charles Web Debugging Proxy के रूप में ब्राउज़र की सुरक्षा त्रुटियों के कारण बिना SSL यातायात के निरीक्षण के लिए अनुमति देते हैं, आदि

Answer 3

मुझे लगता है कि तुम सिर्फ SSL का उपयोग और एक HTTP क्लाइंट लाइब्रेरी पर भरोसा करना चाहिए कि कैशिंग (पूर्व: विंडोज़ पर WinInet) करता है। यह कल्पना करना मुश्किल है कि एंटरप्राइज़ वाइड कैशिंग के लाभ प्रॉक्सी पर कस्टम सुरक्षा एन्क्रिप्शन योजना या प्रमाण पत्र मज़े लिखने के दर्द के लायक हैं। इससे भी बदतर, एन्क्रिप्शन योजना पर आप उल्लेख करते हैं, इकाई निकाय पर असममित सिफर करने से आपके आवेदन के सर्वर पक्ष पर एक विशाल पेर्फ हिट की तरह लगता है; एक कारण है कि एसएसएल कनेक्शन के वास्तविक पेलोड के लिए सममित सिफर का उपयोग करता है।

Answer 4

मुझे लगता है कि आपको केवल एसएसएल का उपयोग करना चाहिए और एक HTTP क्लाइंट लाइब्रेरी पर भरोसा करना चाहिए जो कैशिंग (पूर्व: विंडोज़ पर विनइनेट) करता है। यह कल्पना करना मुश्किल है कि एंटरप्राइज़ वाइड कैशिंग का लाभ कस्टम सुरक्षा एन्क्रिप्शन योजना या प्रॉक्सी पर सर्टिफिकेट मज़े लिखने के दर्द के लायक है। इससे भी बदतर, आपके द्वारा उल्लिखित एन्क्रिप्शन योजना पर, इकाई निकाय पर एसिमेट्रिक सिफर करने से आपके आवेदन के सर्वर पक्ष पर एक विशाल पेर्फ हिट की तरह लगता है; एक कारण है कि एसएसएल कनेक्शन के वास्तविक पेलोड के लिए सममित सिफर का उपयोग करता है।

संबंधित एप्लिकेशन ब्राउज़र ऐप नहीं है, यह एक डेस्कटॉप ऐप इंटरनेट पर डेटा खींच रहा है। क्या होने जा रहा है कि ऐप के सभी उदाहरण एक ही समय में एक ही टुकड़े खींच रहे होंगे। इस डेटा को सुरक्षित करने की आवश्यकता है, लेकिन मैं ऐप के कुछ उदाहरणों को कॉर्पोरेट प्रॉक्सी सर्वर से कैश संस्करण प्राप्त करके perf को बढ़ाने की उम्मीद कर रहा हूं।

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

सर्वर पक्ष पर डेटा/संदेश निकाय पूर्व-एन्क्रिप्टेड और वितरित इन-मेमोरी हैश-टेबल में कैश किया जाएगा। प्रति-अनुरोध के आधार पर एन्क्रिप्शन नहीं किया जाएगा।

मैं एक संदेश बस का उपयोग करके भी जांच कर रहा हूं, जैसे NServiceBus।

Answer 5

बाहर चेक www.bluecoat.com एक वाणिज्यिक प्रॉक्सी कि वास्तव में https साइटों को ब्लॉक करने के क्रम में अवरोधन कर सकते हैं, सामग्री को प्रतिबंधित, वायरस और कैश सामग्री के लिए निरीक्षण किया है (हो जाता है)

Answer 6

कैसे एक सर्वर की स्थापना के बारे में उस घटक के पीछे अनुप्रयोग सर्वर पर कैश जो https प्रतिक्रियाओं को एन्क्रिप्ट करता है? यदि आपके पास रिवर्स-प्रॉक्सी सेटअप है तो यह उपयोगी हो सकता है।

मैं कुछ इस तरह की सोच रहा हूँ:

application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)