एचटीटीपीएस और एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी की मदद से, नुकसान पहुंचाने वाले मिडलमैन को गुमराह करना

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

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

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

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

मध्यस्थ

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

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 का ऑमनीबॉक्स, कनेक्शन के स्टेटस के बारे में काफ़ी जानकारी देता है.
Chrome का ऑमनीबॉक्स, कनेक्शन की स्थिति के बारे में काफ़ी जानकारी देता है.

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

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

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

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

कृपया इस रास्ते से जाएं

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

$ 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 का हाल ही का लेख "एसएसएल/टीएलएस की मदद से अपने वेब सर्वर को सुरक्षित करना" पढ़ें.
  • Strict-Transport-Security हेडर के बारे में सभी तकनीकी जानकारी पाने के लिए, एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी स्पेसिफ़िकेशन (RFC6797) को पढ़ना ज़रूरी है.
  • जब आपको यह पता चल जाए कि आपको क्या करना है, तो अगला चरण यह होगा कि आप अपनी साइट के लिए यह विज्ञापन दें कि उस पर सिर्फ़ सर्टिफ़िकेट के एक खास सेट की मदद से पहुंचा जा सकता है. IETF पर कुछ काम चल रहा है, जिससे आपको Public-Key-Pins हेडर के ज़रिए ऐसा करने की अनुमति मिलेगी. हालांकि, अभी यह शुरुआती दौर है, लेकिन यह दिलचस्प और फ़ॉलो करने लायक है.