क्या HTTPS में GET डेटा भी एन्क्रिप्ट किया गया है?

127

आप कब प्राप्त करोगे

https://encrypted.google.com/search?q=%s

%sक्वेरी एन्क्रिप्टेड है? या सिर्फ प्रतिक्रिया? यदि ऐसा नहीं है, तो Google को सार्वजनिक सामग्री भी एन्क्रिप्शन के साथ क्यों परोसनी चाहिए?

https http-get

— जदर दयस
स्रोत

145

संपूर्ण अनुरोध URL सहित, और यहां तक कि कमांड ( GET) भी एन्क्रिप्ट किया गया है । केवल एक हस्तक्षेप करने वाली पार्टी जैसे कि प्रॉक्सी सर्वर चमक सकता है गंतव्य पता और पोर्ट।

ध्यान दें, हालांकि, टीएलएस हैंडशेक के क्लाइंट हैलो पैकेट SNI एक्सटेंशन (धन्यवाद @hafichuk) के माध्यम से प्लेटेक्स्ट में पूरी तरह से योग्य डोमेन नाम का विज्ञापन कर सकते हैं , जिसका उपयोग सभी आधुनिक मुख्यधारा ब्राउज़रों द्वारा किया जाता है, हालांकि कुछ केवल नए एरेस पर।

संपादित करें: (जब से यह मुझे एक "अच्छा जवाब" बिल्ला मिला है, मुझे लगता है कि मुझे पूरे प्रश्न का उत्तर देना चाहिए ...)

संपूर्ण प्रतिक्रिया भी एन्क्रिप्टेड है; परदे के पीछे के किसी भी हिस्से को रोक नहीं सकते।

Google https पर खोजों और अन्य सामग्री परोसता है क्योंकि यह सब सार्वजनिक नहीं है, और आप कुछ सार्वजनिक सामग्री को MITM से छुपाना चाह सकते हैं । किसी भी घटना में, Google को अपने लिए जवाब देना सबसे अच्छा है ।

— मार्सेलो कैंटोस
स्रोत

2

मैं इस दावे से थोड़ा दुखी हूं कि URL एन्क्रिप्टेड है। क्या होस्टनाम को url का हिस्सा नहीं माना जाता है? यदि हां, तो कथन गलत है। आईएसपी / प्रॉक्सी सर्वर से होस्टनाम / आईपी पते को छिपाने का कोई तरीका नहीं है उसी तरह आप भौतिक मेल के दौरान गंतव्य पते को छिपा नहीं सकते हैं।

— अभिषेक आनंद

1

@ अभिषेक: होस्टनाम टीसीपी / आईपी हेडर में मौजूद नहीं है। मैं अपने जवाब में आईपी पते को कवर करता हूं।

— मार्सेलो कैंटोस

डोमेन एन्क्रिप्ट नहीं किया गया है । यह नाम आधारित वर्चुअल होस्ट (बनाम आईपी आधारित) का समर्थन करना है। @MarceloCantos पूरी तरह से सही है कि बाकी URL (यानी GETकमांड) एन्क्रिप्टेड है। यह RFC 4366

— hafichuk

@ffichuk: इसके लिए धन्यवाद। मुझे एहसास नहीं था कि TLS fqdn का विज्ञापन कर सकता है। पिछली बार जब मैंने एक https मल्टीसेवर (कई साल पहले, मैं स्वीकार करूँगा) को सेटअप करने की कोशिश की, तो यह एक सिंगल आईपी पर असंभव लग रहा था।

— मार्सेलो कैंटोस

डोमेन नाम वाले TLS के लिए वास्तव में महत्वपूर्ण अतिरिक्त: डोमेन नाम सहित प्लेनटेक्स्ट DNS अनुरोध को भी न भूलें। संभावना वह है जो आपके एन्क्रिप्ट किए गए HTTPS ट्रैफ़िक को देख सकता है और आपके DNS अनुरोधों को भी देख सकता है।

— टिम जी

63

URL स्वयं एन्क्रिप्ट किया गया है, इसलिए क्वेरी स्ट्रिंग में पैरामीटर तार के पार सादे में यात्रा नहीं करते हैं।

हालाँकि, ध्यान रखें कि GET डेटा सहित URL अक्सर वेबसर्वर द्वारा लॉग किए जाते हैं, जबकि POST डेटा शायद ही कभी होता है। तो अगर आप कुछ करने की योजना बना रहे हैं /login/?username=john&password=doe, तो नहीं; इसके बजाय एक POST का उपयोग करें।

— थॉमस
स्रोत

2

+1 धन्यवाद। यह मेरे स्वयं के भौतिक सर्वर पर है, इसलिए मैं लॉग के बारे में बहुत चिंतित नहीं हूं, लेकिन साझा होस्टिंग वातावरण में इस पर विचार करने वाले किसी भी व्यक्ति के लिए यह एक अच्छा विचार है। यह विचार करना भी महत्वपूर्ण है क्योंकि मैं इस तरह से क्रेडिट कार्ड नंबर स्थानांतरित करूंगा, और निश्चित रूप से उन्हें लॉग इन नहीं करना

— चाहूंगा

3

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

— थॉमस

1

आपको इन्हें POST बॉडी में रखना चाहिए, न कि URL क्वेरी स्ट्रिंग।

— थॉमस

1

क्या आपका डर वेबसाइट के डेटा (DB, फ़ाइल, आदि) तक पहुँच की तुलना में इसके लॉग तक पहुँचने पर कम प्रतिबंध है? जब तक डेटा सुरक्षित रूप से वेबसर्वर तक पहुँचता है तब तक IMHO, सब ठीक है। केवल वे लोग जिनके पास वेबसर्वर तक पहुंच है, उन्हें विश्वसनीय माना जाना चाहिए क्योंकि यदि वे नहीं हैं तो कोई रास्ता नहीं है जिससे आप डेटा को एक या दूसरे तरीके से पढ़ पाएंगे।

— सर्ज प्रोफैफलेबुक

1

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

— स्टीन स्कट

21

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

उपरोक्त Google उत्तर से एक बहुत व्यापक उत्तर का एक हिस्सा है:

http://answers.google.com/answers/threadview/id/758002.html#answer

— DVK
स्रोत

17

होस्ट नाम के बाद URL का हिस्सा सुरक्षित रूप से भेजा जाता है।

उदाहरण के लिए, https://somewhere.com/index.php?NAME=FIELD

/index.php?NAME=FIELDभाग एन्क्रिप्टेड है। somewhere.comनहीं है।

— levis501
स्रोत

6

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

— यूजीन मेवस्की 'कॉलबैक
स्रोत

1

कौन सा सर्वर? किसके लिए सुलभ है?

— जादेर डायस

2

@Jader कम से कम और हैकर्स के लिए उस सर्वर के प्रवेशकों के लिए। POST अनुरोध के साथ जानकारी लॉग में नहीं रहती है, जब तक कि यह स्पष्ट रूप से लॉग न हो, लॉग के साथ कोई समस्या नहीं है। GET क्वेरीज़ लॉग में रहती हैं और यदि लॉग के साथ कुछ भी होता है (या व्यवस्थापक किसी भी बुरी गतिविधियों के लिए इन लॉग का उपयोग करने का निर्णय लेता है), तो आप मुश्किल में हैं।

— यूजीन मेवस्की 'कॉलबैक

4

अनुरोध प्रेषित होने से पहले कनेक्शन एन्क्रिप्ट हो जाता है। तो हाँ, अनुरोध स्ट्रिंग स्ट्रिंग सहित भी एन्क्रिप्ट किया गया है।

— चाओ
स्रोत

4

हाँ, यह सुरक्षित है। एसएसएल सब कुछ एन्क्रिप्ट करता है।

POST अनुरोध के अंश:

POST /foo HTTP/1.1
... some other headers

GET अनुरोध के अंश:

GET /foo?a=b HTTP/1.1
... some other headers

दोनों मामलों में सॉकेट पर जो कुछ भी भेजा जाता है वह एन्क्रिप्ट किया जाता है। तथ्य यह है कि ग्राहक देखता है GET अनुरोध के दौरान अपने ब्राउज़र में पैरामीटर है इसका मतलब यह नहीं है कि बीच में एक आदमी को वही दिखाई देगा।

— डारिन दिमित्रोव
स्रोत

4

मैं बस HTTPS के माध्यम से एक वेबसाइट से जुड़ा और GET मापदंडों का एक समूह पारित किया। फिर मैंने नेटवर्क को सूँघने के लिए वायरशार्क का इस्तेमाल किया। HTTP का उपयोग करके, URL को अनएन्क्रिप्टेड भेजा जाता है, जिसका अर्थ है कि मैं आसानी से URL में सभी GET पैरामीटर देख सकता हूँ। HTTPS का उपयोग करते हुए, सब कुछ एन्क्रिप्ट किया गया है और मैं यह भी नहीं देख सकता कि कौन सा पैकेट GET कमांड है, अकेले इसकी सामग्री दें!

— जेफ मेम्
स्रोत

3

SSL शीर्ष लेख पार्सिंग से पहले होता है, इसका मतलब है:

Client creates Request
Request gets encrypted
Encrypted request gets transmitted to the Server
Server decrypts the Request
Request gets parsed

एक अनुरोध कुछ इस तरह दिखता है (सटीक वाक्यविन्यास याद नहीं कर सकता है, लेकिन यह काफी करीब होना चाहिए):

GET /search?q=qwerty HTTP/1.1
Host: www.google.de

यही कारण है कि एक ही आईपी पर कई मेजबानों के लिए अलग-अलग एसएसएल सर्टिफिकेट होने से समस्याएँ होती हैं, अनुरोधित होस्टनाम को डिक्रिप्शन तक नहीं जाना जाता है।

— Morfildur
स्रोत

1

HTTP/1.1पहली पंक्ति के अंत में आता है।

— मार्सेलो कैंटोस

@ मार्सेलोस कैंटोस: धन्यवाद, जब से मुझे HTTP रिक्वेस्ट को हाथ से लिखना पड़ा तब से कुछ समय हो गया है।

— मॉर्फिल्डुर

0

HTTPS का उपयोग करते समय GET अनुरोध एन्क्रिप्ट किया गया है - वास्तव में इस कारण सुरक्षित वेबसाइटों को एक विशिष्ट आईपी पता होना चाहिए - अनुरोध किए जाने के बाद तक अनुरोध से इच्छित होस्टनाम (या वर्चुअल निर्देशिका) प्राप्त करने का कोई तरीका नहीं है।

— माइकल बूर
स्रोत

JFYI: एक TLS एक्सटेंशन है जो क्लाइंट को होस्ट नाम निर्दिष्ट करने देता है और इसलिए सर्वर संबंधित प्रमाणपत्र को चुन सकता है।

— यूजीन मेवस्की 'कॉलबैक

@ यूजीन: धन्यवाद - मुझे टीएलएस विस्तार के बारे में पता है, लेकिन केवल जागरूकता के सबसे ढीले अर्थ में - मुझे विवरण का कुछ भी नहीं पता है या यह वास्तविक रूप से कितना व्यापक हो सकता है (या नहीं हो सकता है)।

— माइकल बूर