बस सत्यापित करना चाहते हैं, जब एक SSL कनेक्शन (http पोस्ट) बनाने कहना है:HTTPS के साथ, यूआरएल और अनुरोध हेडर सुरक्षित अनुरोध के रूप में सुरक्षित हैं?
https://www.example.com/some/path?customer_key=123123123
आप किसी को भी customer_key बारे में जानने की, इस दृष्टिकोण भले ही मैं एक https बनाने रहा हूँ काम नहीं करेगा नहीं करना चाहते हैं कनेक्शन सही है?
सभी डेटा जिन्हें मैं सुरक्षित करना चाहता हूं, अनुरोध निकाय में होना चाहिए?
HTTPS RFC का हवाला देते हुए:
जब TLS हैंडशेक समाप्त हो गया है। क्लाइंट पहला HTTP अनुरोध शुरू कर सकता है। सभी HTTP डेटा को टीएलएस "एप्लिकेशन डेटा" के रूप में भेजा जाना चाहिए।
अनिवार्य रूप से, सुरक्षित एसएसएल/टीएलएस चैनल पहले स्थापित किया गया है। केवल तब HTTP प्रोटोकॉल का उपयोग किया जाता है। यह HTTP शीर्षलेखों सहित SSL के साथ सभी HTTP ट्रैफ़िक की रक्षा करेगा (जिसमें यूआरएल और कुकीज़ शामिल हैं)।
हैंडशेक में जो दिखाई दे सकता है वह होस्ट नाम ही है, क्योंकि यह सर्वर प्रमाणपत्र में निहित है जो हैंडशेक में स्पष्ट रूप से दिखाई देगा (और गंतव्य आईपी पते को देखकर होस्ट नाम का अनुमान लगाना अक्सर आसान होता है वैसे भी)।
सर्वर नाम संकेत का उपयोग करते समय, अनुरोध किया गया होस्ट नाम संदेश में ClientHello संदेश में भी दिखाना चाहिए। अन्यथा, सर्टिफिकेट से मेजबान नाम का अनुमान लगाने के लिए अस्पष्टता के लिए कुछ अस्पष्टता हो सकती है यदि प्रमाण पत्र एकाधिक होस्ट नामों के लिए मान्य है (उदा। एकाधिक विषय Alt नाम या वाइल्डकार्ड)। इस मामले में ग्राहक से DNS अनुरोध को सहेजने से हमलावर एक सुराग दे सकता है।
अन्य लोगों के उत्तरों और टिप्पणियों को पढ़ना, कुछ Referer के बारे में मुद्दों का उल्लेख करते हैं (spec में r खो गए हैं) और लॉग।
शेष संभावित कमजोर बिंदुओं में से एक है आप उपयोगकर्ता को यह लिंक देते हैं। यदि यह सादे HTTP पर प्रदत्त वेब पेज में एम्बेड किया गया है, तो कोई भी व्यक्ति जो उस पृष्ठ को पढ़ सकता है उसे देख पाएगा। आपको एचटीटीपीएस पर भी ऐसे पेज की सेवा करनी चाहिए। यदि आप उस लिंक को ई-मेल द्वारा भेजते हैं, तो मैं कहूंगा कि सभी दांव बंद हैं, क्योंकि मेल सर्वर शायद ही कभी अपने बीच कनेक्शन को एन्क्रिप्ट करते हैं और उपयोगकर्ता अक्सर बिना किसी एन्क्रिप्शन के अपने ई-मेल खाते तक पहुंच सकते हैं।
संपादित करें:
इसके अलावा, आप क्लाइंट प्रमाण पत्र प्रमाणीकरण का उपयोग कर रहे हैं, क्लाइंट प्रमाणपत्र दिखाई अगर यह प्रारंभिक हाथ मिलाना के दौरान बातचीत के जरिए किया जाता है हो जाएगा। यह वेबसाइट तक पहुंचने वाले उपयोगकर्ता का नाम रिसाव कर सकता है (प्रायः विषय डीएन में उपयोगकर्ता नाम होता है)। ग्राहक प्रमाण पत्र तब दिखाई नहीं देगा जब इसे फिर से बातचीत किए गए हैंडशेक के दौरान भेजा जाता है।
मेरा उत्तर नहीं दे रहा है! स्पष्ट रूप से होस्ट कनेक्शन स्थापित होने से पहले केवल होस्ट नाम स्पष्ट टेक्स्ट में भेजा जाता है।
केवल www.example.com snoopers को दिखाई जाएगी। अनुरोध का पथ खंड एसएसएल/टीएलएस द्वारा संरक्षित है।
जाहिर है, आपको एचटीटीपीएस द्वारा मूल हाइपरलिंक भी भेजना होगा।
निर्भर करता है कि ..
आप एक पैकेट का उपयोग करते हैं स्निफर आप तार पर भेजे गए डेटा नहीं देख सकता। इस दृष्टिकोण के साथ मुख्य समस्या यह है कि अनुरोध यूआरएल अक्सर सादे पाठ में सर्वर के लॉग में सहेजा जाता है, ब्राउज़र इतिहास यूआरएल रखता है, यूआरएल रेफरर हेडर में पास हो जाते हैं और शायद तीसरे पक्ष की सेवाओं (गूगल एनालिटिक्स) द्वारा जारी रहेंगे।
अच्छी तरह से यह सर्वर पर सर्वर है, क्लाइंट ब्राउज़र सर्वर पर नहीं। – codecompleting
'रेफरर' को HTTPS के साथ पास नहीं किया जाना चाहिए: http://stackoverflow.com/a/8848843/372643 – Bruno
सुरक्षित डेटा स्थापित करने के बाद अनुरोध डेटा भेजा जाएगा, इसलिए उपर्युक्त यूआरएल के साथ कोई चिंता नहीं है, लेकिन याद रखें कि आपका डेटा एन्क्रिप्टेड नहीं है, केवल सर्वर और क्लाइंट के बीच चैनल एन्क्रिप्ट किया गया है, अगर कोई इस चैनल को क्रैक कर सकता है, तो स्पष्ट रूप से आपका देख सकता है डेटा।
एसएसएल आपके डेटा के शीर्ष पर रैपर एन्क्रिप्टेड चैनल है। यदि डेटा सादा है, तो कोई भी जो SSL को क्रैक कर सकता है, वह आपके डेटा को स्पष्ट रूप से देख सकता है।
चैनल एन्क्रिप्शन और डेटा एन्क्रिप्शन के बीच क्या अंतर है। एसएसएल हैंडशेक में, सर्वर और http क्लाइंट एक गुप्त कुंजी पर सहमत होते हैं और भेजा गया डेटा उस गुप्त कुंजी का उपयोग करके एन्क्रिप्ट किया जाता है, है ना? – Ashwin
@Ashwin, मान लें कि आप तार पर एबीसी भेज रहे हैं, एसएसएल गुप्त कुंजी का उपयोग कर एबीसी लपेटता है, तो यह कुछ [एबीसी], [] रैपर (या) कुंजी होगा, लेकिन उसके अंदर की सामग्री अभी भी एबीसी है। अगर किसी को [] (आपकी कुंजी) पता है, तो वे आसानी से आपका डेटा प्राप्त कर सकते हैं। – kosa
किसी को भी मेरी कुंजी कैसे पता चलेगा। यह केवल एक ग्राहक है जो ग्राहक और प्रमाण पत्र के बीच साझा किया जाता है? क्या किसी तीसरे व्यक्ति द्वारा गुप्त कुंजी जानने का कोई तरीका है? – Ashwin
बस स्पष्ट करने के लिए (कुछ अन्य उत्तरों को देखकर)। आपकी समस्या बीच में छिपाने के बारे में है, है ना? क्या आप * अपने * लॉग्स को स्टोर करने के तरीके से चिंतित हैं (संभवतः आप इस सर्वर को चला रहे हैं)? – Bruno
संभावित डुप्लिकेट [क्या https यूआरएल एन्क्रिप्टेड हैं?] (Http://stackoverflow.com/questions/499591/are-https-urls-encrypted) – Gumbo