एचटीटीपीएस और एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी की मदद से, नुकसान पहुंचाने वाले बिचौलियों को भ्रमित करना

Mike West

इंटरनेट पर मौजूद निजी डेटा की मात्रा को देखते हुए, एन्क्रिप्ट (सुरक्षित) करने के तरीके को नज़रअंदाज़ नहीं किया जा सकता. मॉडर्न ब्राउज़र में कई ऐसे तरीके होते हैं जिनका इस्तेमाल करके, यह पक्का किया जा सकता है कि डेटा ट्रांसफ़र होने के दौरान, आपके उपयोगकर्ताओं का डेटा सुरक्षित रहे: सुरक्षित कुकी और स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी, इनमें से दो सबसे अहम तरीके हैं. इनकी मदद से, उपयोगकर्ताओं को आसानी से सुरक्षित रखा जा सकता है. साथ ही, उनके कनेक्शन को एचटीटीपीएस पर अपग्रेड किया जा सकता है. इससे यह गारंटी मिलती है कि उपयोगकर्ता का डेटा कभी भी साफ़ तौर पर नहीं भेजा जाता.

आपको इसके बारे में क्यों सोचना चाहिए? इस बारे में सोचें:

किसी वेब पेज को एन्क्रिप्ट (सुरक्षित) न किए गए एचटीटीपी कनेक्शन पर डिलीवर करना, सड़क पर दिखने वाले किसी ऐसे व्यक्ति को बिना सील किया हुआ लिफ़ाफ़ा देने जैसा है जो डाकघर की दिशा में जा रहा हो. अगर आपकी किस्मत अच्छी है, तो हो सकता है कि वह खुद ही उसे सही जगह पर पहुंचा दे या फिर वह उसे किसी ऐसे व्यक्ति को दे दे जो सही दिशा में जा रहा हो. वह व्यक्ति भी ऐसा ही कर सकता है. इस तरह यह सिलसिला चलता रहता है.

इस चेन में मौजूद ज़्यादातर अजनबी भरोसेमंद होते हैं. वे कभी भी आपके खुले हुए पत्र को नहीं देखेंगे या उसमें बदलाव नहीं करेंगे. हालांकि, जितनी बार ईमेल को फ़ॉरवर्ड किया जाएगा, उतने ही ज़्यादा लोगों के पास आपके भेजे गए ईमेल का पूरा ऐक्सेस होगा. आखिर में, इस बात की काफ़ी संभावना है कि जिस व्यक्ति को आपने चिट्ठी भेजी है उसे मेल में कुछ मिलेगा. हालांकि, क्या वह वही चीज़ है जो आपने भेजी थी, यह एक बड़ा सवाल है. शायद तुम्हें वह लिफ़ाफ़ा सील कर देना चाहिए था…

बिचौलियों

इंटरनेट का एक बड़ा हिस्सा, अनजान लोगों के भरोसे पर चलता है. सर्वर एक-दूसरे से सीधे तौर पर कनेक्ट नहीं होते हैं. हालांकि, वे एक-दूसरे को अनुरोध और जवाब भेजते हैं. इसके लिए, वे एक राऊटर से दूसरे राऊटर तक डेटा भेजते हैं. यह प्रक्रिया, टेलीफ़ोन गेम की तरह होती है.

इन हॉप को traceroute की मदद से देखा जा सकता है. मेरे कंप्यूटर से HTML5Rocks तक का रूट कुछ ऐसा दिखता है:

$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
 1  router1-lon.linode.com (212.111.33.229)  0.453 ms
 2  212.111.33.233 (212.111.33.233)  1.067 ms
 3  217.20.44.194 (217.20.44.194)  0.704 ms
 4  google1.lonap.net (193.203.5.136)  0.804 ms
 5  209.85.255.76 (209.85.255.76)  0.925 ms
 6  209.85.253.94 (209.85.253.94)  1.226 ms
 7  209.85.240.28 (209.85.240.28)  48.714 ms
 8  216.239.47.12 (216.239.47.12)  22.575 ms
 9  209.85.241.193 (209.85.241.193)  36.033 ms
10  72.14.233.180 (72.14.233.180)  43.222 ms
11  72.14.233.170 (72.14.233.170)  43.242 ms
12  *
13  lb-in-f102.1e100.net (173.194.71.102)  44.523 ms

13 हॉप्स वाकई खराब नहीं हैं. हालांकि, अगर मैं एचटीटीपी का इस्तेमाल करके अनुरोध भेजता हूं, तो बीच में मौजूद हर राऊटर के पास मेरे अनुरोधों और सर्वर के जवाबों का पूरा ऐक्सेस होता है. सारा डेटा, एन्क्रिप्ट (सुरक्षित) नहीं किए गए सादे टेक्स्ट के तौर पर ट्रांसफ़र किया जा रहा है. साथ ही, इनमें से कोई भी मध्यस्थ, मैन इन द मिडल के तौर पर काम कर सकता है. यह मेरे डेटा को पढ़ सकता है या ट्रांसफ़र के दौरान उसमें हेर-फेर भी कर सकता है.

इससे भी बुरी बात यह है कि इस तरह की रुकावट का पता लगाना काफ़ी मुश्किल होता है. नुकसान पहुंचाने के मकसद से बदला गया एचटीटीपी रिस्पॉन्स, बिलकुल मान्य रिस्पॉन्स जैसा दिखता है. ऐसा इसलिए होता है, क्योंकि ऐसा कोई तरीका मौजूद नहीं है जिससे यह पक्का किया जा सके कि मिला डेटा, भेजे गए डेटा से _बिलकुल_ मेल खाता है. अगर कोई मज़ाक के लिए मेरे इंटरनेट को उलट-पुलट करने का फ़ैसला करता है, तो मेरी किस्मत कम या ज़्यादा खराब है.

क्या यह एक सुरक्षित लाइन है?

प्लेन टेक्स्ट वाले एचटीटीपी से सुरक्षित एचटीटीपीएस कनेक्शन पर स्विच करने से, आपको हैकर से सबसे अच्छी सुरक्षा मिलती है. एचटीटीपीएस कनेक्शन, डेटा भेजने से पहले पूरे चैनल को एंड-टू-एंड एन्क्रिप्ट (सुरक्षित) करते हैं. इससे आपके और आपके डेस्टिनेशन के बीच की मशीनें, ट्रांज़िट स्थिति वाले डेटा को न तो पढ़ सकती हैं और न ही उसमें बदलाव कर सकती हैं.

Chrome का खोज बार, कनेक्शन की स्थिति के बारे में काफ़ी जानकारी देता है.

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

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

डिफ़ॉल्ट रूप से सुरक्षित

सर्टिफ़िकेट का अनुरोध करने और उसे इंस्टॉल करने के बाद, पक्का करें कि आपके उपयोगकर्ताओं को आपकी मेहनत का फ़ायदा मिले: अपने मौजूदा उपयोगकर्ताओं को एचटीटीपी रीडायरेक्शन के ज़रिए, एचटीटीपीएस कनेक्शन पर माइग्रेट करें. साथ ही, पक्का करें कि कुकी सिर्फ़ सुरक्षित कनेक्शन पर डिलीवर की जाएं.

कृपया इस तरफ़ आएं

जब कोई उपयोगकर्ता http://example.com/ पर जाए, तो उसे https://example.com/ पर रीडायरेक्ट करें. इसके लिए, सही Location हेडर के साथ 301 Moved Permanently रिस्पॉन्स भेजें:

$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/

Apache या Nginx जैसे सर्वर में, इस तरह के रीडायरेक्शन को आसानी से सेट अप किया जा सकता है. उदाहरण के लिए, http://example.com/ से https://example.com/ पर रीडायरेक्ट करने वाला Nginx कॉन्फ़िगरेशन ऐसा दिखता है:

server {
    listen [YOUR IP ADDRESS HERE]:80;
    server_name example.com www.example.com;
    location "/" {
        rewrite ^(.*) https://www.example.com$1 permanent;
    }
}

कुकी जार को लॉक करना

कुकी की मदद से, हम उपयोगकर्ताओं को स्टेटलेस एचटीटीपी प्रोटोकॉल पर, लॉग इन करने का बेहतर अनुभव दे पाते हैं. कुकी में सेव किया गया डेटा, हर अनुरोध के साथ भेजा जाता है. इसमें सेशन आईडी जैसी संवेदनशील जानकारी भी शामिल होती है. इससे सर्वर को यह समझने में मदद मिलती है कि वह फ़िलहाल किस उपयोगकर्ता को जवाब दे रहा है. जब हम यह पक्का कर लेते हैं कि उपयोगकर्ता हमारी साइट को एचटीटीपीएस पर ऐक्सेस कर रहे हैं, तो हमें यह भी पक्का करना चाहिए कि कुकी में सेव किया गया संवेदनशील डेटा, सिर्फ़ सुरक्षित कनेक्शन पर ट्रांसफ़र किया जाए और उसे कभी भी साफ़ तौर पर न भेजा जाए.

कुकी सेट करने के लिए, आम तौर पर एचटीटीपी हेडर का इस्तेमाल किया जाता है. यह कुछ इस तरह दिखता है:

set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

ब्राउज़र को निर्देश दिया जा सकता है कि वह कुकी के इस्तेमाल को सुरक्षित सेशन तक सीमित रखे. इसके लिए, एक कीवर्ड जोड़ें:

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure

secure कीवर्ड के साथ सेट की गई कुकी, एचटीटीपी पर कभी नहीं भेजी जाएंगी.

खुली हुई विंडो बंद करना

एचटीटीपीएस पर पारदर्शी रीडायरेक्शन का मतलब है कि आपकी साइट पर आने वाले ज़्यादातर उपयोगकर्ता, सुरक्षित कनेक्शन का इस्तेमाल करेंगे. हालांकि, इससे हमले का खतरा पूरी तरह से खत्म नहीं होता: शुरुआती एचटीटीपी कनेक्शन पूरी तरह से खुला होता है. इस वजह से, एसएसएल स्ट्रिपिंग और इससे जुड़े हमलों का खतरा बना रहता है. अगर किसी मैन इन द मिडल के पास शुरुआती एचटीटीपी अनुरोध का पूरा ऐक्सेस है, तो वह आपके और सर्वर के बीच प्रॉक्सी के तौर पर काम कर सकता है. इससे, सर्वर के इरादों की परवाह किए बिना, आपको असुरक्षित एचटीटीपी कनेक्शन पर रखा जा सकता है.

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

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

इस हेडर के साथ काम करने वाले ब्राउज़र (फ़िलहाल, Firefox, Chrome, और Opera: caniuse में जानकारी है) यह नोट करेंगे कि इस साइट ने सिर्फ़ एचटीटीपीएस ऐक्सेस का अनुरोध किया है. इसका मतलब है कि उपयोगकर्ता चाहे किसी भी तरह से साइट पर आए, वह एचटीटीपीएस पर ही विज़िट करेगा. अगर वह ब्राउज़र में http://example.com/ टाइप करती है, तो भी वह एचटीटीपी कनेक्शन बनाए बिना एचटीटीपीएस पर पहुंच जाएगी. इससे भी बेहतर बात यह है कि अगर ब्राउज़र को कोई अमान्य सर्टिफ़िकेट मिलता है (जो आपके सर्वर की पहचान को स्पूफ़ करने की कोशिश कर रहा हो), तो उपयोगकर्ताओं को एचटीटीपी का इस्तेमाल जारी रखने की अनुमति नहीं दी जाएगी. यह पूरी तरह से सुरक्षित है.

ब्राउज़र, max-age सेकंड (इस उदाहरण में करीब एक महीना) के बाद सर्वर की एचएसटीएस स्थिति को खत्म कर देगा. इसे कुछ ज़्यादा पर सेट करें.

यह भी पक्का किया जा सकता है कि किसी ऑरिजिन के सभी सबडोमेन सुरक्षित हों. इसके लिए, हेडर में includeSubDomains डायरेक्टिव जोड़ें:

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

सुरक्षित तरीके से आगे बढ़ें

एचटीटीपीएस ही एकमात्र ऐसा तरीका है जिससे यह पक्का किया जा सकता है कि आपका भेजा गया डेटा, सही व्यक्ति तक सुरक्षित तरीके से पहुंचे. आपको अपनी साइटों और ऐप्लिकेशन के लिए, आज ही सुरक्षित कनेक्शन सेट अप करना चाहिए. यह काफ़ी आसान प्रोसेस है. इससे आपके ग्राहकों का डेटा सुरक्षित रखने में मदद मिलेगी. एन्क्रिप्ट (सुरक्षित) किया गया चैनल सेट अप करने के बाद, उपयोगकर्ताओं को इस सुरक्षित कनेक्शन पर रीडायरेक्ट करें. इससे कोई फ़र्क़ नहीं पड़ता कि वे आपकी साइट पर कैसे आते हैं. इसके लिए, 301 एचटीटीपी रिस्पॉन्स भेजें. इसके बाद, पक्का करें कि आपके उपयोगकर्ताओं के सेशन की संवेदनशील जानकारी, सिर्फ़ उस सुरक्षित कनेक्शन का इस्तेमाल करती हो. इसके लिए, कुकी सेट करते समय secure कीवर्ड जोड़ें. यह सब करने के बाद, पक्का करें कि आपके उपयोगकर्ताओं को कभी भी गलती से कोई समस्या न हो: उन्हें सुरक्षित रखने के लिए, पक्का करें कि उनका ब्राउज़र Strict-Transport-Security हेडर भेजकर सही काम करे.

एचटीटीपीएस को सेट अप करना आसान है. इससे आपकी साइट और उसके उपयोगकर्ताओं को काफ़ी फ़ायदे मिलते हैं. यह कोशिश करने लायक है.

संसाधन

• StartSSL, पुष्टि किए गए डोमेन के लिए बिना किसी शुल्क के सर्टिफ़िकेट उपलब्ध कराता है. बिना किसी शुल्क के मिलने वाली चीज़ों से बेहतर कुछ नहीं होता. पुष्टि करने के बेहतर लेवल पर अपग्रेड करना मुमकिन है. साथ ही, इसकी कीमत भी सही है.
• एसएसएल सर्वर टेस्ट: अपने सर्वर के लिए एचटीटीपीएस सेट अप करने के बाद, एसएसएल लैब के सर्वर टेस्ट की मदद से पुष्टि करें कि आपने इसे सही तरीके से किया है. आपको ज़्यादा जानकारी वाली रिपोर्ट मिलेगी. इससे आपको पता चलेगा कि आपका कारोबार वाकई में आगे बढ़ रहा है या नहीं.
• Ars Technica का हाल ही का लेख "Securing your Web Server with SSL/TLS", सर्वर सेट अप करने के बारे में ज़्यादा जानकारी पाने के लिए पढ़ा जा सकता है.
• एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी स्पेसिफ़िकेशन (आरएफ़सी6797) को पढ़कर, Strict-Transport-Security हेडर के बारे में वह सारी तकनीकी जानकारी हासिल की जा सकती है जो आपको चाहिए.
• जब आपको पता चल जाए कि आपको क्या करना है, तो अगला कदम यह हो सकता है कि आप यह विज्ञापन दें कि आपकी साइट को सिर्फ़ सर्टिफ़िकेट के खास सेट के ज़रिए ही ऐक्सेस किया जा सकता है. आईईटीएफ़ में कुछ काम चल रहा है, जिससे आपको Public-Key-Pins हेडर की मदद से ऐसा करने की सुविधा मिलेगी. हालांकि, अभी इसमें समय लगेगा, लेकिन यह दिलचस्प है और इस पर नज़र बनाए रखने की ज़रूरत है.