1016

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

यदि TLS / SSL आपको कुल URL एन्क्रिप्शन देता है, तो मुझे URL से गोपनीय जानकारी छिपाने के बारे में चिंता करने की आवश्यकता नहीं है।

ssl https httprequest

— डैनियल कीवातिनोस
स्रोत

76

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

— जुलफ

43

URL को ब्राउज़र इतिहास और सर्वर लॉग में भी संग्रहीत किया जाता है - अगर मैं अपना नाम और पासवर्ड कहीं संग्रहीत करना चाहता था, तो यह इन दो स्थानों पर नहीं होगा।

— पिस्कोर ने बिल्डिंग

47

उदाहरण के लिए, मान लें कि मैं यात्रा करता हूं https://somewhere_i_trust/ways_to_protest_against_the_government/। तब URL में गोपनीय डेटा होता है, अर्थात् सुझाव है कि मैं अपनी सरकार के खिलाफ विरोध करने पर विचार कर रहा हूं।

— स्टीव जेसप

42

मैं मूल (ब्राउज़र आधारित नहीं) ऐप से एक HTTP अनुरोध करते समय खुद से यह सवाल पूछ रहा था। मैं अनुमान लगा रहा हूं कि यह मोबाइल ऐप डेवलपर्स को दिलचस्पी दे सकता है। इस मामले में, ऊपर की टिप्पणियां (जबकि सच) अप्रासंगिक हैं (कोई यूआरएल दिखाई नहीं देता है, कोई ब्राउज़िंग इतिहास नहीं है), इसका उत्तर देते हुए, मेरी समझ में एक सरल: "हां, यह एन्क्रिप्टेड है"।

— DannyA

23

उन लोगों के लिए जो एक बार सोचते हैं कि आप HTTPS हैं, कोई नहीं जानता कि आप कहां जा रहे हैं, यह पहले पढ़ें: सर्वर का होस्टनाम (उदाहरण example.com) अभी भी SNI के कारण लीक हो जाएगा । इसका DNS से कोई लेना-देना नहीं है और यदि आप DNS का उपयोग नहीं करते हैं या एन्क्रिप्टेड DNS का उपयोग करते हैं तो भी रिसाव होगा।

— पचेरियर

911

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

— मार्क नोवाकोव्स्की
स्रोत

98

यह अभी भी @Jalf द्वारा बताई गई बात पर ही ध्यान देने योग्य है। URL का डेटा ब्राउज़र के इतिहास में भी सहेजा जाएगा, जो लंबे समय तक असुरक्षित हो सकता है।

— माइकल एकस्ट्रैंड

20

सिर्फ GET या POST नहीं। DELETE, PUT, HEAD, या TRACE भी हो सकता है।

4

हाँ यह ब्राउज़र के इतिहास के लिए एक सुरक्षा मुद्दा हो सकता है। लेकिन मेरे मामले में मैं ब्राउज़र का उपयोग नहीं कर रहा हूं (मूल पोस्ट में ब्राउज़र का उल्लेख नहीं किया गया है)। एक मूल ऐप में पर्दे के पीछे कस्टम https कॉल का उपयोग करना। यह सुनिश्चित करने का एक सरल उपाय है कि आपके ऐप का गंभीर कनेक्शन सुरक्षित है।

— झिंगले-डिंगल

28

ध्यान दें कि URL का DNS रिज़ॉल्यूशन शायद एन्क्रिप्ट नहीं किया गया है। तो आपके ट्रैफ़िक को सूँघने वाला कोई व्यक्ति शायद अभी भी वह डोमेन देख सकता है जिसे आप एक्सेस करने का प्रयास कर रहे हैं।

— ChewToy

21

SNI URL के SSL एन्क्रिप्शन के 'होस्ट' भाग को तोड़ता है। आप इसे वायरशार्क के साथ स्वयं परीक्षण कर सकते हैं। SNI के लिए एक चयनकर्ता है, या जब आप दूरस्थ होस्ट से कनेक्ट होते हैं तो आप अपने SSL पैकेट की समीक्षा कर सकते हैं।

— सेमीहाउस

652

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

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

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

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

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

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

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

संक्षेप में:

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

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

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

मार्च 2019 अद्यतन

यह एक लाने के लिए धन्यवाद carlin.scott ।

SNI एक्सटेंशन में पेलोड को अब इस ड्राफ्ट RFC प्रस्ताव के माध्यम से एन्क्रिप्ट किया जा सकता है । यह क्षमता केवल टीएलएस 1.3 में मौजूद है (एक विकल्प के रूप में और इसे लागू करने के लिए दोनों सिरों पर निर्भर है) और टीएलएस 1.2 और नीचे के साथ कोई पीछे की संगतता नहीं है।

CloudFlare कर रहा है और आप यहां के इंटर्नल के बारे में अधिक पढ़ सकते हैं - यदि चिकन अंडे से पहले आना चाहिए, तो आप चिकन कहां डालते हैं?

व्यवहार में इसका अर्थ है कि FQDN को सादे पाठ में प्रसारित करने के बजाय (जैसे Wireshark कैप्चर शो), अब इसे एन्क्रिप्ट किया गया है।

नोट: यह एक रिवर्स DNS लुकअप MAY वैसे भी इच्छित गंतव्य होस्ट को प्रकट करने के बाद से सुरक्षा के एक से अधिक गोपनीयता पहलू को संबोधित करता है।

— evilSnobu
स्रोत

37

सही उत्तर, A से Z तक की पूरी व्याख्या के साथ। मुझे कार्यकारी सारांश पसंद है। मेरा दिन @evilSnobu

— oscaroscar

4

बिल्कुल सही जवाब, upvote! फिर भी ग्राहक के हिस्से पर विचार करें क्योंकि ब्राउज़र इतिहास एक रिसाव हो सकता है। हालाँकि, ट्रांसपोर्ट लेयर के संबंध में, URL-पैरामीटर एन्क्रिप्ट किए गए हैं।

— जेन्स क्रेडलर

2

आप इस उत्तर को इस तथ्य से अपडेट करना चाह सकते हैं कि TLS 1.3 SNI एक्सटेंशन को एन्क्रिप्ट करता है, और सबसे बड़ी CDN बस यही कर रही है: blog.cloudflare.com/encrypted-sni बेशक एक पैकेट स्निफर सिर्फ रिवर्स-डीएनएस लुकअप कर सकता है आप जिस आईपी पते से जुड़ रहे हैं।

— carlin.scott 21:00

@evilSnobu, लेकिन उपयोगकर्ता नाम: उपयोगकर्ता नाम का पासवर्ड हिस्सा : password@domain.com एन्क्रिप्टेड है, है ना? इसलिए यह https का उपयोग करके url में संवेदनशील डेटा पास करना सुरक्षित है।

— मक्सिम शमीहुलौ

1

वे तार पर (परिवहन में) एन्क्रिप्टेड हैं, लेकिन यदि या तो अंत (उपयोगकर्ता या सर्वर) URL को एक सादे पाठ फ़ाइल में लॉग करता है और क्रेडेंशियल को पवित्र नहीं करता है ... अब यह एक अलग वार्तालाप है।

— दुष्टनोबू

159

जैसा कि अन्य उत्तर पहले ही बता चुके हैं, https "URL" वास्तव में एन्क्रिप्टेड हैं। हालाँकि, डोमेन नाम को हल करते समय आपका DNS अनुरोध / प्रतिक्रिया शायद नहीं है, और निश्चित रूप से, यदि आप एक ब्राउज़र का उपयोग कर रहे थे, तो आपके URL भी रिकॉर्ड किए जा सकते हैं।

— ज़च स्क्रिवेना
स्रोत

21

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

— स्टीव जेसप

8

@SteveJessop, कृपया "जावास्क्रिप्ट हैक

— Pacerier

6

@Pacerier: निश्चित रूप से हैक्स तारीख है, लेकिन क्या मैं के बारे में समय जैसी चीजों था बात कर रहा था stackoverflow.com/questions/2394890/... । 2010 में यह एक बड़ी बात थी कि इन मुद्दों की जांच की जा रही थी और हमलों को परिष्कृत किया गया था, लेकिन मैं इस समय वास्तव में इसका पालन नहीं कर रहा हूं।

— स्टीव जेसोप

2

@Pacerier: अधिक उदाहरण: webdevwonders.com/… , webdevwonders.com/…

— Steve Jessop

1

आप OpenDNS का उपयोग एनक्रिप्टेड DNS सेवा के साथ कर सकते हैं। मैं इसे अपने मैक पर उपयोग करता हूं, लेकिन मैंने पाया कि विंडोज संस्करण ठीक से काम नहीं कर रहा है। हालांकि यह कुछ समय पहले था, इसलिए यह अब ठीक काम कर सकता है। लिनक्स के लिए अभी तक कुछ भी नहीं। opendns.com/about/innovations/dnscrypt

— SPRBRN

101

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

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

— पीटर Štibraný
स्रोत

1

अनुरोध की संपूर्णता। होस्ट नाम स्पष्ट में भेजा गया है। बाकी सब एन्क्रिप्टेड है।

— सैम सिर्री

98

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

स्पष्ट होना:

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

हालाँकि, कई कारण हैं कि आपको GET अनुरोध में पैरामीटर नहीं रखना चाहिए।

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

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

— टोबियास
स्रोत

3

@EJP आपको समझ नहीं आया कि टोबियास क्या कह रहा है। वह कह रहा है कि यदि आप साइट A पर एक लिंक पर क्लिक करते हैं जो आपको साइट B पर ले जाएगा, तो साइट B को रेफरर URL मिल जाएगा। उदाहरण के लिए, यदि आप siteA.com?u=username&pw=123123 पर हैं , तो siteB.com (जो siteA.com के पेज से जुड़ा हुआ है) को रेफ़रिंग के रूप में " siteA.com?u=username&pw/123123 " प्राप्त होगा। URL, ब्राउज़र द्वारा HTTPS के अंदर siteB.com पर भेजा गया। अगर यह सच है, तो यह बहुत बुरा है। क्या यह सच तोबियास है?

— त्रिकूट

9

@EJP, डोमेन के दृश्य क्योंकि है SNI जो सभी आधुनिक वेब ब्राउज़र का उपयोग करें। EFF के इस आरेख को यह भी देखें कि कोई भी उस साइट के डोमेन को देख सकता है जिसे आप देख रहे हैं। यह ब्राउज़र दृश्यता के बारे में नहीं है। यह इस बारे में है कि बाज को क्या दिखाई देता है।

— ब्यूज

10

@trusktr: ब्राउजर्स को HTTPS पेज से रेफर हेडर नहीं भेजना चाहिए। यह HTTP विनिर्देशन का हिस्सा है ।

— मार्टिन गेइसर

8

@MartinGeisler, कीवर्ड "चाहिए" है। ब्राउज़रों को "चाहिए" ("चाहिए" के विपरीत) के बारे में ज्यादा परवाह नहीं है। अपने स्वयं के लिंक से: "दृढ़ता से अनुशंसा की जाती है कि उपयोगकर्ता का चयन करने में सक्षम हो या न हो कि रेफ़र फ़ील्ड भेजा गया है। उदाहरण के लिए, ब्राउज़र क्लाइंट के पास खुले तौर पर / अनाम रूप से ब्राउज़ करने के लिए टॉगल स्विच हो सकता है, जो क्रमशः भेजने / भेजने में सक्षम / अक्षम करेगा। संदर्भ और जानकारी से " । ऑप्स, जो वास्तव में क्रोम ने किया था। यदि आप गुप्त मोड में हैं, तब भी Chrome रेफ़रर को छोड़कर लीक करता है ।

— पचेरियर

48

मार्क नोवाकोव्स्की के उपयोगी उत्तर के अतिरिक्त - URL सर्वर पर लॉग्स (जैसे / में / आदि / httpd / लॉग / ssl_access_log) में संग्रहीत किया जाता है, इसलिए यदि आप नहीं चाहते कि सर्वर अधिक समय तक सूचना बनाए रखे। शब्द, इसे URL में न डालें।

— रोडरी कुसैक
स्रोत

34

हां और ना।

सर्वर एड्रेस भाग एन्क्रिप्ट नहीं किया गया है क्योंकि यह कनेक्शन सेट करने के लिए उपयोग किया जाता है।

यह भविष्य में एन्क्रिप्टेड एसएनआई और डीएनएस के साथ बदल सकता है लेकिन 2018 तक दोनों प्रौद्योगिकियां आमतौर पर उपयोग में नहीं हैं।

पथ, क्वेरी स्ट्रिंग आदि एन्क्रिप्टेड हैं।

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

— साबुनदान
स्रोत

8

इसे +1 करना चाहते हैं, लेकिन मुझे "हाँ और नहीं" भ्रामक लगता है - आपको इसे बदलना चाहिए कि बस सर्वर नाम एनक्रिप्शन के बिना DNS का उपयोग करके हल किया जाएगा।

— लॉरेंस डॉल

7

मेरी समझ में, ओपी सही अर्थों में URL शब्द का उपयोग करता है। मुझे लगता है कि यह उत्तर अधिक भ्रामक है, क्योंकि यह URL में होस्टनाम और DNS रिज़ॉल्यूशन में होस्टनाम के बीच स्पष्ट रूप से अंतर नहीं करता है।

— Guillaume

4

URL एन्क्रिप्ट किया गया है। HTTP ट्रांजेक्शन का हर पहलू एन्क्रिप्टेड है। सिर्फ 'बाकी सब ’नहीं। अवधि। -1।

— user207421

4

@EJP लेकिन DNS लुकअप का उपयोग URL के एक बिंदु भाग पर होता है, इसलिए गैर-तकनीकी व्यक्ति के लिए, संपूर्ण URL एन्क्रिप्टेड नहीं है। गैर-तकनीकी व्यक्ति जो केवल गैर-तकनीकी चीजों को देखने के लिए Google.com का उपयोग कर रहा है, उसे यह नहीं पता है कि डेटा अंततः कहां रहता है या इसे कैसे संभाला जाता है। डोमेन, जो उस URL का हिस्सा है जिसे उपयोगकर्ता देख रहा है, 100% एन्क्रिप्टेड नहीं है क्योंकि मैं हमलावर के रूप में वह जिस साइट पर जा रहा हूं उसे सूँघ सकता है। URL का केवल / पथ स्वाभाविक रूप से आम आदमी के लिए एन्क्रिप्टेड है (यह कोई फर्क नहीं पड़ता कि कैसे)।

— त्रिकूट

6

@EJP, @ trusktr, @ लॉरेंस, @ गिलौम। आप सभी की गलती है। इसका DNS से कोई लेना देना नहीं है। एसएनआई " टीएलएस वार्ता के हिस्से के रूप में वर्चुअल डोमेन का नाम भेजें ", इसलिए भले ही आप डीएनएस का उपयोग न करें या यदि आपका डीएनएस एन्क्रिप्ट किया गया है, तो भी एक स्निफर आपके अनुरोधों के होस्टनाम को देख सकता है ।

— पचेरियर

9

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

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

— pbhj
स्रोत

यह वास्तव में केवल बहुत छोटी साइटों पर संभव होगा, और उन मामलों में, साइट का विषय / स्वर / प्रकृति शायद अभी भी प्रत्येक पृष्ठ पर उसी के बारे में होगी।

— कैमरून

5

मेरे द्वारा दिए गए उद्धरण से: "हम 6000 से अधिक वेबपेजों के खिलाफ एक ट्रैफ़िक विश्लेषण हमले की पेशकश करते हैं, जिसमें स्वास्थ्य सेवा, वित्त, कानूनी सेवाओं और स्ट्रीमिंग वीडियो जैसे क्षेत्रों में व्यापक रूप से उपयोग की जाने वाली, उद्योग की अग्रणी वेबसाइटों के 10 HTTPS तैनाती हैं। हमारा हमला व्यक्तिगत पृष्ठों की पहचान करता है। 89% सटीकता के साथ एक ही वेबसाइट [...] "। ऐसा लगता है कि व्यवहार्यता के रूप में आपका निष्कर्ष गलत है।

— pbhj

2

इस तरह की भेद्यता के बारे में अधिक पढ़ने में दिलचस्प किसी के लिए, इस प्रकार के हमलों को आमतौर पर साइड-चैनल हमलों के रूप में जाना जाता है ।

— दान बीचर्ड

7

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

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

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

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

— डॉन गिलिस
स्रोत

6

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

— JoshBerke
स्रोत

अपने तीसरे पक्ष के कॉल उपलब्ध कराना HTTPS के अस्वस्थ हैं हालांकि यह एक समस्या नहीं है?

— लियाम

3

इसे थर्ड पार्टी सर्टिफिकेट के साथ एन्क्रिप्ट किया जाएगा ताकि वे

— जोशबर्के

5

यह अब 2019 है और टीएलएस v1.3 जारी किया गया है। Cloudflare के अनुसार, SNI को TLS v1.3 के लिए एन्क्रिप्ट किया जा सकता है। तो, मैंने खुद को महान बताया! आइए देखें कि यह cloudflare.com के टीसीपी पैकेट के भीतर कैसा दिखता है। इसलिए, मैंने क्लाउड क्रोम सर्वर की प्रतिक्रिया से "क्लाइंट हेलो" हैंडशेक पैकेट पकड़ा, जो ब्राउज़र और वायरशर्क के रूप में पैकेट स्निफर के रूप में Google Chrome का उपयोग करता है। मैं अभी भी क्लाइंट हैलो पैकेट के भीतर सादे पाठ में सर्वर का नाम पढ़ सकता हूं।

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

तो ऐसा लगता है कि एसएनआई के एन्क्रिप्शन को TLSv1.3 के साथ काम करने के लिए अतिरिक्त कार्यान्वयन की आवश्यकता होती है

निम्नलिखित लेख में Cloudflare द्वारा दिए गए SNI के एन्क्रिप्शन को TLSv1.3 के भाग के रूप में वर्णित किया गया है। हालांकि, क्लाउडफेयर.कॉम से सभी HTTP यूआरएल टीएलएस v1.3 के तहत टीसीपी पैकेट के भीतर सादे पाठ में हैं

[ https://blog.cloudflare.com/encrypted-sni/deside3]

— निकोलस गुएरनेट
स्रोत

"एसएनआई को एन्क्रिप्ट किया जा सकता है" - यही प्रमुख बिंदु है। वर्तमान Google Chrome के साथ Cloudflare.com/ssl/encrypted-sni की जाँच करते हुए कहते हैं कि "इस पृष्ठ पर जाने पर आपके ब्राउज़र ने SNI को एन्क्रिप्ट नहीं किया है।" दो टैंगो लगते हैं ...

— पिस्कवर ने बिल्डिंग

जाहिरा तौर पर वर्तमान फ़ायरफ़ॉक्स ईएसएनआई कर सकता है, लेकिन यह डिफ़ॉल्ट रूप से अक्षम है: आपको सक्षम करने की आवश्यकता है network.security.esni.enabled, network.trr.mode2 पर सेट करें (जो वर्तमान में आपके DoH रिवाल्वर को CloudFlare पर सेट करता है), और ब्राउज़र को फिर से चालू करें (sic!)। तब वह ESNI का उपयोग करेगा - जहां डोमेन के बुनियादी ढांचे द्वारा समर्थित है। देखें blog.mozilla.org/security/2018/10/18/... जानकारी के लिए।

— पिस्कोवर ने बिल्डिंग

3

हां और ना।

वास्तविक URL एन्क्रिप्ट किया गया है, जिसका अर्थ है कि कोई आपके द्वारा देखी गई वेबसाइट पर सटीक वेबपेज नहीं बता सकता है। हालाँकि, TLS हेडर में उस सर्वर का होस्टनाम शामिल है जिसे आप एक्सेस कर रहे हैं (जैसे www.quora.com) अनएन्क्रिप्टेड। DNS भी लगभग कभी एन्क्रिप्ट नहीं किया गया है, और आपके द्वारा एक्सेस किए जा रहे होस्टनाम को भी लीक कर देगा। यह DNS क्वेरी डिफ़ॉल्ट रूप से आपके ISP के सर्वर के खिलाफ लगभग हमेशा होती है, इसलिए वे आसानी से आपके द्वारा उपयोग की जाने वाली प्रत्येक वेबसाइट के होस्टनाम को अन्य DNS सर्वरों के लिए आपके DNS अनुरोधों को सूँघकर, या अपने खुद के खिलाफ रिकॉर्ड करके देख सकते हैं।

हालांकि, अगर आपकी चिंता यह है कि क्या कोई यह पता लगा सकता है कि आप किस वेबसाइट पर पहुंच रहे हैं तो यह पर्याप्त नहीं है। HTTPS OSI लेयर 4 पर काम करता है, और उस स्तर पर सभी डेटा को एन्क्रिप्ट करता है, लेकिन निचले स्तर के नेटवर्क तक ले जाते हैं जो इसे ले जाते हैं। कोई व्यक्ति अभी भी OSI लेयर पर ट्रैफ़िक के पथ और गंतव्य का पता लगा सकता है। इसका मतलब है कि कोई व्यक्ति आपके ट्रैफ़िक को सूँघकर IP पता प्राप्त कर सकता है और उस वेबसाइट के डोमेन नाम का विस्तार कर सकता है जिसे आप एक्सेस कर रहे थे।

इससे भी बदतर, पहली बार (और कुछ बाद के समय के आधार पर, कैसे / जब आपके DNS कैश को साफ़ किया जाता है), तो आप संभवतः अपने DNS सर्वर को अपने HTTPS लक्ष्य URL के आईपी पते (फिर से,) का अनुरोध करने के लिए एक अनएन्क्रिप्टेड DNS क्वेरी भेजेंगे। डिफ़ॉल्ट रूप से आपके ISP के सर्वर) आपके DNS सर्वर के पथ के साथ आपके ट्रैफ़िक तक पहुँच रखने वाला कोई भी व्यक्ति इस क्वेरी को सूँघ सकता है।

यदि आप एक उच्च स्तर की गोपनीयता की तलाश में हैं, तो आपको एक विश्वसनीय एन्क्रिप्टेड वीपीएन और / या एन्क्रिप्टेड प्रॉक्सी सेवा के साथ HTTPS को पूरक करने की आवश्यकता होगी। आप अपने DNS प्रश्नों की सुरक्षा के लिए DNSSEC में देख सकते हैं। यह सेवा विश्वसनीय होनी चाहिए, क्योंकि वे आपके ट्रैफ़िक के स्रोतों और गंतव्यों के उपरोक्त अनुरेखण को आसानी से कर सकते हैं।

— हिमांशु पटेल
स्रोत

2

पहले से ही कुछ अच्छे जवाब हैं, उनमें से ज्यादातर ब्राउज़र नेविगेशन में ध्यान केंद्रित कर रहे हैं। मैं इसे 2018 में लिख रहा हूं और शायद कोई मोबाइल एप्लिकेशन की सुरक्षा के बारे में जानना चाहता है।

मोबाइल एप्लिकेशन के लिए , यदि आप एप्लिकेशन (सर्वर और ऐप) के दोनों सिरों को नियंत्रित करते हैं, जब तक आप HTTPS का उपयोग करते हैं तो आप सुरक्षित हैं । आईओएस या एंड्रॉइड प्रमाणपत्र को सत्यापित करेगा और संभावित एमआईएम हमलों को कम करेगा (जो इस सब में एकमात्र कमजोर बिंदु होगा)। आप HTTPS कनेक्शन के माध्यम से संवेदनशील डेटा भेज सकते हैं कि इसे परिवहन के दौरान एन्क्रिप्ट किया जाएगा । बस आपके ऐप और सर्वर को https के माध्यम से भेजे गए किसी भी पैरामीटर का पता चल जाएगा।

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

— रिकार्डो BRGWeb
स्रोत

1

इसके अतिरिक्त, यदि आप एक ReSTful API का निर्माण कर रहे हैं, तो ब्राउज़र रिसाव और http रेफ़रर इश्यू ज्यादातर कम हो जाते हैं क्योंकि क्लाइंट एक ब्राउज़र नहीं हो सकता है और आपके पास लिंक पर क्लिक करने वाले लोग नहीं हो सकते हैं।

यदि यह मामला है तो मैं एक बियर टोकन प्राप्त करने के लिए oAuth2 लॉगिन की सिफारिश करूंगा। जिस स्थिति में केवल संवेदनशील डेटा प्रारंभिक क्रेडेंशियल्स होगा ... जो कि संभवतः किसी भी पोस्ट अनुरोध में होना चाहिए

— क्रिस रटलेज
स्रोत

0

जब आपके पास पहले से ही बहुत अच्छे उत्तर हैं, तो मुझे वास्तव में इस वेबसाइट पर स्पष्टीकरण पसंद है: https://https.cio.gov/faq/#what-information-does-https-protect

संक्षेप में: HTTPS खाल का उपयोग:

HTTP विधि
क्वेरी params
POST निकाय (यदि वर्तमान में)
अनुरोध हेडर (कुकीज़ शामिल)
स्थिति का कोड

— pedrorijo91
स्रोत

क्या HTTPS URL एन्क्रिप्ट किए गए हैं?

संक्षेप में:

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

मार्च 2019 अद्यतन

सर्वर एड्रेस भाग एन्क्रिप्ट नहीं किया गया है क्योंकि यह कनेक्शन सेट करने के लिए उपयोग किया जाता है।

पथ, क्वेरी स्ट्रिंग आदि एन्क्रिप्टेड हैं।