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

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

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

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

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

मध्यस्थ

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

ट्रेसरूट की मदद से, इन हॉप्स को एक साथ देखा जा सकता है. मेरे कंप्यूटर से 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 या Ngnx जैसे सर्वर में आसानी से सेट अप किया जा सकता है. उदाहरण के लिए, http://example.com/ से https://example.com/ पर रीडायरेक्ट करने वाला Ngnx कॉन्फ़िगरेशन ऐसा दिखता है:

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

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

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

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

इस तरह के हमले के जोखिम को कम करने के लिए, ब्राउज़र से एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी (एचएसटीएस) को लागू करने के लिए कहें. 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 एचटीटीपी रिस्पॉन्स भेजकर आपकी साइट पर कैसे आते हैं. इसके बाद, पक्का करें कि आपके सभी उपयोगकर्ताओं के सेशन की संवेदनशील जानकारी में, सिर्फ़ सुरक्षित कनेक्शन का इस्तेमाल होता हो. ऐसा करने के लिए, कुकी सेट करते समय सुरक्षित कीवर्ड जोड़ें. यह सब करने के बाद, पक्का करें कि आपके उपयोगकर्ता गलती से बस से न गिरें: उनकी सुरक्षा करने के लिए, यह पक्का करें कि उनका ब्राउज़र एक Strict-Transport-Security हेडर भेजकर सही काम करता हो.

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

रिसॉर्स

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