http - क्या एचटीटीपीएस यूआरएल एन्क्रिप्टेड हैं?




post ssl (8)

क्या टीएलएस / एसएसएल (एचटीटीपीएस) एन्क्रिप्शन का उपयोग करते समय सभी यूआरएल एन्क्रिप्ट किए गए हैं? मैं जानना चाहता हूं क्योंकि मैं टीएलएस / एसएसएल (एचटीटीपीएस) का उपयोग करते समय सभी यूआरएल डेटा छिपाना चाहता हूं।

यदि टीएलएस / एसएसएल आपको कुल यूआरएल एन्क्रिप्शन देता है तो मुझे यूआरएल से गोपनीय जानकारी छिपाने की चिंता करने की ज़रूरत नहीं है।


आप हमेशा पूर्ण यूआरएल की गोपनीयता पर भरोसा नहीं कर सकते हैं। उदाहरण के लिए, जैसा कि कभी-कभी एंटरप्राइज़ नेटवर्क पर होता है, आपके कंपनी पीसी जैसे आपूर्ति किए गए डिवाइस एक अतिरिक्त "भरोसेमंद" रूट प्रमाणपत्र के साथ कॉन्फ़िगर किए जाते हैं ताकि आपका ब्राउज़र चुपचाप https ट्रैफ़िक के प्रॉक्सी (मैन-इन-द-बीच) निरीक्षण पर भरोसा कर सके । इसका मतलब है कि पूर्ण यूआरएल निरीक्षण के लिए खुलासा किया गया है। यह आमतौर पर एक लॉग में सहेजा जाता है।

इसके अलावा, आपके पासवर्ड भी सामने आए हैं और शायद लॉग इन हैं और यह एक बार पासवर्ड का उपयोग करने या अपने पासवर्ड को बदलने के लिए एक और कारण है।

अंत में, अन्यथा एन्क्रिप्टेड नहीं होने पर अनुरोध और प्रतिक्रिया सामग्री का भी खुलासा किया जाता है।

निरीक्षण सेटअप का एक उदाहरण यहां चेकपॉइंट द्वारा वर्णित है। आपूर्ति किए गए पीसी का उपयोग करके एक पुरानी शैली "इंटरनेट कैफे" भी इस तरह स्थापित की जा सकती है।


एक तृतीय पक्ष जो यातायात की निगरानी कर रहा है, वह आपके ट्रैफ़िक की जांच करके देखे गए पृष्ठ को निर्धारित करने में सक्षम हो सकता है, जिस पर साइट पर जाने पर किसी अन्य उपयोगकर्ता के ट्रैफ़िक की तुलना की जा सकती है। उदाहरण के लिए यदि साइट पर केवल 2 पृष्ठ थे, तो दूसरे की तुलना में एक बड़ा, फिर डेटा स्थानांतरण के आकार की तुलना से पता चलता है कि आप किस पृष्ठ पर गए थे। तीसरे पक्ष से इसे छुपाया जा सकता है लेकिन वे सामान्य सर्वर या ब्राउज़र व्यवहार नहीं हैं। उदाहरण के लिए साइप्रेट, https://scirate.com/arxiv/1403.0297 से यह पेपर https://scirate.com/arxiv/1403.0297

आम तौर पर अन्य उत्तरों सही होते हैं, व्यावहारिक रूप से हालांकि यह पेपर दिखाता है कि पृष्ठों का दौरा किया गया (यानी यूआरएल) काफी प्रभावी ढंग से निर्धारित किया जा सकता है।


चूंकि कोई भी तार कैप्चर नहीं करता है, यहां एक है।
सर्वर नाम (यूआरएल का डोमेन हिस्सा) सादे पाठ में ClientHello पैकेट में प्रस्तुत किया गया है।

निम्नलिखित ब्राउज़र अनुरोध को दिखाता है:
https://i.stack.imgur.com/path/?some=parameters&go=here

टीएलएस संस्करण फ़ील्ड पर अधिक के लिए यह उत्तर देखें (उनमें से 3 हैं - संस्करण नहीं, फ़ील्ड जिनमें प्रत्येक में संस्करण संख्या है!)

https://www.ietf.org/rfc/rfc3546.txt :

3.1। सर्वर नाम संकेत

[टीएलएस] किसी क्लाइंट के लिए एक सर्वर को उस सर्वर का नाम बताने के लिए तंत्र प्रदान नहीं करता है जो वह संपर्क कर रहा है। ग्राहकों के लिए एक ही अंतर्निहित नेटवर्क पते पर एकाधिक 'आभासी' सर्वर होस्ट करने वाले सर्वरों के लिए सुरक्षित कनेक्शन की सुविधा के लिए यह जानकारी प्रदान करना वांछनीय हो सकता है।

सर्वर नाम प्रदान करने के लिए, क्लाइंट में (विस्तारित) क्लाइंट हैलो में "server_name" प्रकार का विस्तार शामिल हो सकता है।


संक्षेप में:

  • ClientHello एक्सटेंशन का उपयोग होने पर ClientHello (यूआरएल का डोमेन हिस्सा) ClientHello पैकेट के अंदर स्पष्ट रूप से प्रेषित किया जा सकता है

  • बाकी यूआरएल ( /path/?some=parameters&go=here ) ClientHello अंदर कोई व्यवसाय नहीं है क्योंकि अनुरोध यूआरएल एक HTTP चीज (ओएसआई लेयर 7) है, इसलिए यह कभी भी टीएलएस हैंडशेक (परत 4 या 5)। बाद में यह एक GET /path/?some=parameters&go=here HTTP/1.1 HTTP अनुरोध, सुरक्षित टीएलएस चैनल स्थापित होने के बाद।


कार्यकारी सारांश

डोमेन नाम स्पष्ट रूप से प्रेषित किया जा सकता है (यदि एसएनआई एक्सटेंशन टीएलएस हैंडशेक में उपयोग किया जाता है) लेकिन यूआरएल (पथ और पैरामीटर) हमेशा एन्क्रिप्ट किया जाता है।


जब तक आप सर्वर से कनेक्शन स्थापित नहीं करते हैं, वैसे ही GET का उपयोग केवल 'name' लिए किया जाता है, आपको क्या मिलेगा (डेटा भेजने के लिए नहीं), आपको डेटा भेजने के लिए POST उपयोग करना होगा।


मैं पिछले उत्तरों से सहमत हूं:

स्पष्ट होना:

टीएलएस के साथ, यूआरएल ( https://www.example.com/ ) का पहला भाग अभी भी दृश्य बनाता है क्योंकि यह कनेक्शन बनाता है। दूसरा भाग (/ herearemygetparameters / 1/2/3/4) टीएलएस द्वारा संरक्षित है।

हालांकि कई कारण हैं कि आपको जीईटी अनुरोध में पैरामीटर क्यों नहीं डालना चाहिए।

सबसे पहले, जैसा कि पहले से ही दूसरों द्वारा उल्लेख किया गया है: - ब्राउज़र पता बार के माध्यम से रिसाव - इतिहास के माध्यम से रिसाव

इसके अतिरिक्त आपके पास http रेफरर के माध्यम से यूआरएल का रिसाव है: उपयोगकर्ता टीएलएस पर साइट ए देखता है, फिर साइट बी के लिंक पर क्लिक करता है। यदि दोनों साइटें टीएलएस पर हैं, तो साइट बी के अनुरोध में साइट ए से पूरा यूआरएल होगा अनुरोध के रेफरर पैरामीटर। और साइट बी से व्यवस्थापक सर्वर बी की लॉग फाइलों से इसे पुनर्प्राप्त कर सकता है।)


मैं यहाँ एक छलांग लगाने जा रहा हूं और मान लीजिए कि आप https अनुरोध के "प्राप्त करें" भाग का मतलब है।

उस मामले में, हाँ और नहीं। यूआरएल का सर्वर पता भाग स्पष्ट रूप से एन्क्रिप्टेड नहीं है क्योंकि इसका उपयोग कनेक्शन सेट अप करने के लिए किया जाता है।

बाकी सब कुछ एक HTTPS कनेक्शन में एन्क्रिप्ट किया गया है। लेकिन यदि आप पोस्ट के बजाय जीईटी का उपयोग कर रहे हैं तो उपयोगकर्ता अभी भी यूआरएल को स्थान पट्टी से काट और पेस्ट कर पाएगा, और शायद आप उसमें गोपनीय जानकारी नहीं डालना चाहेंगे जो स्क्रीन पर देखे किसी को भी देखा जा सके ।

जो कुछ भी कहा, आपको अपनी शब्दावली से सावधान रहना चाहिए। एक प्रसिद्ध swashbuckler उद्धृत करने के लिए: आप उस शब्द (यूआरएल) का उपयोग करते रहें, मुझे नहीं लगता कि इसका मतलब है कि इसका मतलब क्या है इसका मतलब है ....


हां, एसएसएल कनेक्शन टीसीपी परत और HTTP परत के बीच है। ग्राहक और सर्वर पहले एक सुरक्षित एन्क्रिप्टेड टीसीपी कनेक्शन (एसएसएल / टीएलएस प्रोटोकॉल के माध्यम से) स्थापित करते हैं और फिर क्लाइंट उस एन्क्रिप्टेड टीसीपी कनेक्शन पर HTTP अनुरोध (GET, POST, DELETE ...) भेज देगा।


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





httprequest