👕 🦂 🤡 HTTPS कनेक्शन के पहले कुछ मिलीसेकंड ⛸️ 💇🏻 ⚽️

समीक्षाओं को पढ़ने के घंटों के बाद, बॉब ने उत्सुकता से पूरे दूध के गैलन के लिए चेकआउट बटन पर क्लिक किया, और ...
वाह, अभी क्या हुआ?

220 मिलीसेकंड से अधिक, कई दिलचस्प चीजें हुईं, जिसके कारण फ़ायरफ़ॉक्स ने एड्रेस बार का रंग बदल दिया और निचले दाएं कोने में एक लॉक प्रदर्शित किया। मेरे पसंदीदा विंडसर टूल और थोड़े संशोधित फ़ायरफ़ॉक्स डीबग बिल्ड का उपयोग करके, हम यह पता लगाने की कोशिश करेंगे कि वास्तव में क्या हुआ था।
RFC 2818 तक, फ़ायरफ़ॉक्स जानता है कि "https" का मतलब है कि आपको Amazon.com से जुड़ने के लिए पोर्ट 443 का उपयोग करना होगा:

ग्राहक अभिवादन

टीएलएस विभिन्न प्रकार के "रिकॉर्ड" में सभी ट्रैफ़िक को लपेटता है। हम देखते हैं कि HEX में पैकेट का पहला बाइट 0x16 = 22 है, जिसका अर्थ है कि "रिकॉर्ड" एक "हैंडशेक" है:

अगले दो बाइट्स 0x0301 हैं, जिसका अर्थ संस्करण 3.1 है, जिसका अर्थ है कि टीएलएस 1.0 वास्तव में एसएसएल 3.1 है।
एक हैंडशेक रिकॉर्ड कई संदेशों में टूट गया है। पहला "ग्राहक अभिवादन" (0x01) है। यहाँ कई महत्वपूर्ण बिंदु हैं:

अनियमितता:

ये चार बाइट्स 1 जनवरी, 1970 से वर्तमान यूनिक्स समय, सेकंड की संख्या हैं। हमारे मामले में, यह 0x4a2f07ca है। उनका अनुसरण 28 यादृच्छिक बाइट्स द्वारा किया जाता है, जिनकी बाद में आवश्यकता होगी।
सत्र आईडी:

हमारे मामले में, यह क्षेत्र खाली है। यदि हम कुछ सेकंड पहले Amazon.com से जुड़े, तो हम सत्र जारी रख सकते हैं और पूर्ण हैंडशेक नहीं कर सकते।
साइफर सूट:

ब्राउज़र द्वारा समर्थित सभी एन्क्रिप्शन एल्गोरिदम की सूची। डिफ़ॉल्ट रूप से, बहुत मजबूत TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA का उपयोग किया जाता है, इसके बाद अन्य 33 विकल्प होते हैं। अगर आप कुछ नहीं समझते हैं तो चिंता न करें। इसके बाद, हम सीखते हैं कि अमेज़न हमारे डिफ़ॉल्ट विकल्प को स्वीकार नहीं करेगा।
Server_name एक्सटेंशन:

Amazon.com को बताने का एक तरीका है कि ब्राउज़र को www.amazon.com पर एक पेज की आवश्यकता है। यह काफी सुविधाजनक है, क्योंकि टीएलएस हैंडशेक HTTP ट्रैफिक से बहुत पहले शुरू हो जाता है। HTTP में एक "होस्ट" हेडर है, जो आपको एक ही आईपी पर सैकड़ों साइट्स होस्ट करने की अनुमति देता है। एसएसएल को पारंपरिक रूप से विभिन्न साइटों के लिए अलग-अलग आईपी की आवश्यकता होती है, लेकिन यह एक्सटेंशन सर्वर को किसी विशेष साइट के लिए प्रमाण पत्र के साथ प्रतिक्रिया करने की अनुमति देता है।

सर्वर ग्रीटिंग

Amazon.com एक बड़े हैंडशेक के साथ प्रतिक्रिया करता है, आकार में दो पैकेट (2,551 बाइट्स)। यह उसी बाइट अनुक्रम 0x0301 को इंगित करता है, जिसका अर्थ है कि अमेज़ॅन टीएलएस 1.0 का उपयोग करने के लिए सहमत है। दिलचस्प डेटा के साथ रिकॉर्ड में तीन उप संदेश हैं:

सर्वर स्वागत संदेश:
- चार यूनिक्स समय बाइट्स और 28 यादृच्छिक बाइट्स।
- निम्नलिखित अनुरोधों को पूरा करने के लिए 32 बाइट्स में सत्र आईडी।
- हमारे द्वारा प्रस्तावित 34 एल्गोरिदम में से, अमेज़ॅन ने "TLS_RSA_WITH_RC4_128_MD5" (0x0004) को चुना। इसका मतलब यह है कि RSA एल्गोरिथ्म का उपयोग प्रमाण पत्र हस्ताक्षर और कुंजी विनिमय, डेटा एन्क्रिप्ट करने के लिए RC4 एल्गोरिथ्म, सामग्री को सत्यापित करने के लिए MD5 हैश फ़ंक्शन को सत्यापित करने के लिए किया जाएगा। हम बाद में इस सब पर अधिक विस्तार से चर्चा करेंगे। यह मुझे लगता है कि अमेज़ॅन के पास इन विशेष एल्गोरिदम को चुनने के अपने कारण हैं, उदाहरण के लिए, सीपीयू पर लोड को कम करना। एक कम संभावना विकल्प रॉन रिवेस्ट के लिए धन्यवाद है, जो उपरोक्त तीनों एल्गोरिदम के निर्माता हैं।
प्रमाणपत्र संदेश:
- 2.464 बाइट्स और इसके प्रमाण पत्र में एक विशाल संदेश, जिसे ग्राहक अमेज़ॅन प्रमाणपत्र को मान्य करने के लिए उपयोग कर सकते हैं। यह सब ब्राउज़र में भी देखा जा सकता है।
संदेश "सर्वर ग्रीटिंग पूरा"

एक खाली संदेश "ग्रीटिंग" के सफल समापन का संकेत देता है और यह दर्शाता है कि सर्वर क्लाइंट प्रमाणपत्रों का अनुरोध नहीं करेगा।

प्रमाणपत्र सत्यापन

प्रमाणपत्र की आवश्यकता है ताकि ब्राउज़र यह सुनिश्चित कर सके कि यह विशेष रूप से Amazon.com के साथ संचार करता है। यह प्रमाणपत्र की शुरुआत और समाप्ति तिथियों को देखता है, और यह भी जांचता है कि क्या सार्वजनिक कुंजी गुप्त कुंजियों के आदान-प्रदान के लिए अधिकृत है।

हमें प्रमाणपत्रों पर भरोसा क्यों करना चाहिए?

एक "हस्ताक्षर" इसके साथ जुड़ा हुआ है, बड़े-एंडियन प्रारूप में एक लंबी संख्या:

कोई भी इन बाइट्स को भेज सकता है। हमें इस हस्ताक्षर पर भरोसा क्यों करना चाहिए? जवाब देने के लिए, हम गणित की दुनिया की एक छोटी यात्रा करते हैं:

RSA का एक छोटा सा परिचय

कुछ लोगों को आश्चर्य होता है कि गणित का प्रोग्रामिंग से कोई संबंध है या नहीं। प्रमाण पत्र गणित का उपयोग करने का एक बहुत स्पष्ट मामला है। अमेज़ॅन प्रमाणपत्र हमें बताता है कि हस्ताक्षर को सत्यापित करने के लिए हमें आरएसए का उपयोग करने की आवश्यकता है। RSA को 1970 में प्रोफेसरों MIT Ron Rivest, Adu Shamir और Len Adleman द्वारा बनाया गया था, जिन्होंने 2000 साल के गणित से विचारों को संयोजित करने और एक सरल एल्गोरिथ्म बनाने के लिए एक सुंदर तरीका खोजा:

आप दो अभाज्य संख्याएँ, p और q चुनें। उन्हें गुणा करें और n प्राप्त करें। अगला, आप एक साधारण सार्वजनिक घातांक ई चुनते हैं, जो कि एन्क्रिप्टिंग घातांक होगा, और एक विशेष रूप से चयनित व्युत्क्रम ई, डी, जो डिक्रिप्टर होगा। फिर आप n और e को सार्वजनिक करें और गुप्त रखें। आप पी और क्यू के बारे में भूल सकते हैं, या इसे डी के साथ स्टोर कर सकते हैं।

अब, यदि आपके पास कोई संदेश है, तो आपको उसके बाइट्स को संख्या एम के रूप में प्रस्तुत करना होगा। यदि आपको संदेश को एन्क्रिप्ट करने की आवश्यकता है, तो हम गणना करते हैं:

सी (एम ^ई (मॉड एन)

इसका मतलब है कि आपको एम को अपने आप से गुणा करना होगा। mod n का मतलब है कि हम n से विभाजित होने के केवल शेष को लेते हैं। उदाहरण के लिए, 11 AM + 3 घंटे = 2PM (मॉड 12 घंटे)। रिसीवर डी जानता है और डिक्रिप्ट करने के लिए रिवर्स ऑपरेशन कर सकता है:

C ^d ^e (M ^e ) d ≡ M ^{e * d} ≡ M ¹ mod M (mod n)

यह भी दिलचस्प है कि d वाला व्यक्ति M को d की शक्ति के लिए संदेश उठाकर एक दस्तावेज़ पर हस्ताक्षर कर सकता है:

एम ^डी ≡ एस (मॉड एन)

यह संभव है क्योंकि हस्ताक्षरकर्ता S, M, e और n को सार्वजनिक बनाता है। कोई भी सरल गणना के साथ एस के हस्ताक्षर को सत्यापित कर सकता है:

S ^e ^d (M ^d ) ^e ≡ M ^{d * e *} M ^{e * d} ¹ M ¹ ) M (mod n)

सार्वजनिक कुंजी क्रिप्टोग्राफी को अक्सर असममित कहा जाता है क्योंकि एन्क्रिप्शन कुंजी (हमारे मामले में, ई) डिक्रिप्शन कुंजी (डी) के बराबर नहीं है। RSA मैजिक काम करता है क्योंकि आप C magic M ^e (mod n) की गणना बहुत जल्दी कर सकते हैं, लेकिन यह लगभग असंभव है ^{d d} ) M (mod n) बिना d को जाने। जैसा कि हमने पहले देखा, डी को वापस n और p के गुणन से प्राप्त किया जाता है, जो कि जटिल है।

हस्ताक्षर का सत्यापन

वास्तविक जीवन में आरएसए के साथ काम करते समय, यह याद रखना महत्वपूर्ण है कि सभी संख्याएं __ very__ बड़ी होनी चाहिए। कितना? अमेज़न VeriSign कक्षा 3 सुरक्षित सर्वर CA द्वारा प्रमाणित है इसका मतलब है कि n 2048 बिट लंबा होना चाहिए, जो दशमलव में है:

1890572922 9464742433 9498401781 6528521078 8629616064 3051642608 4317020197 7241822595 6075980039 8371048211 4887504542 4200635317 0422636532 2091550579 0341204005 1169453804 7325464426 0479594122 4167270607 6731441028 3698615569 9947933786 3789783838 5829991518 1037601365 0218058341 7944190228 0926880299 3425241541 4300090021 1055372661 2125414429 9349272172 5333752665 6605550620 5558450610 3253786958 8361121949 2417723618 5199653627 5260212221 0847786057 9342235500 9443918198 9038906234 1550747726 8041766919 1500918876 1961879460 3091993360 6376719337 6644159792 1249204891 7079005527 7689341573 9395596650 5484628101 0469658502 1566385762 0175231997 0268718746 7514321
(पी और क्यू चुनने के साथ सौभाग्य। यदि संभव हो, तो आप एक नकली वेरिसाइन प्रमाण पत्र उत्पन्न कर सकते हैं।)

यदि हम सार्वजनिक ई वेरीसाइन की शक्ति के लिए हस्ताक्षर एस बढ़ाते हैं, और फिर मॉड्यूल एन द्वारा शेष विभाजन लेते हैं, तो हम हेक्स में डिक्रिप्ट किए गए हस्ताक्षर प्राप्त करते हैं:

0001FFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFF00302130 0906052B0E03021A 05000414C19F8786 871775C60EFE0542 E4C2167C830539DB

PKCS # 1 v1.5 मानक के अनुसार, पहला बाइट 00 एन्क्रिप्शन ब्लॉक के लिए पूर्णांक के रूप में परिवर्तित होता है जो मॉड्यूल से छोटा होता है (मुझे अभी तक समझ नहीं आया कि मॉड्यूल क्या था - लगभग। अनुवाद।)। दूसरा बाइट 01 इंगित करता है कि यह एक निजी कुंजी ऑपरेशन है। फिर खाली जगह स्कोर करने के लिए एफएफ बाइट्स का एक गुच्छा। यह बाइट 00 के साथ समाप्त होता है, फिर अनुक्रम "30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14", जिसका अर्थ है SHA-1 फ़ंक्शन का उपयोग। पिछले 20 बाइट्स साइनस सर्टिफिकेट में बाइट्स से SHA-1 के परिणाम हैं।

चूंकि डिक्रिप्ट किए गए मान को सही ढंग से स्वरूपित किया गया है और अंतिम बाइट्स अपने आप की गणना करने के लिए अनुरूप हैं, इसलिए हम यह मान सकते हैं कि कोई व्यक्ति जो वेरिसाइन क्लास 3 सिक्योर सर्वर सीए निजी कुंजी जानता है, ने इस पर हस्ताक्षर किए हैं।

आप इस प्रक्रिया को दोहरा सकते हैं और सत्यापित कर सकते हैं कि वेरिसाइन क्लास 3 सिक्योर सर्वर सीए प्रमाणन को वेरिसाइन के क्लास 3 पब्लिक प्राइमरी सर्टिफिकेशन अथॉरिटी ने साइन किया है।

लेकिन कोई उस पर भरोसा क्यों करे? ट्रस्ट की इस श्रृंखला में और अधिक लिंक नहीं हैं।

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

पूर्व मास्टर कुंजी

हमने Amazon.com की जाँच की और हम इसके सार्वजनिक एन्क्रिप्शन एक्सपोनेंट ई और मॉड्यूल एन को जानते हैं। हमारी सुनने वाला कोई भी ऐसा कर सकता है। अब हमें एक यादृच्छिक कुंजी उत्पन्न करने की आवश्यकता है जिसे हमलावर पहचान नहीं पाता है। यह उतना सरल नहीं है जितना यह लग सकता है, नेटस्केप नेविगेटर 1.1 एसएसएल में छद्म यादृच्छिक संख्या जनरेटर की भेद्यता के कारण उस समय की मशीनों पर 25 सेकंड में क्रैक किया जा सकता है। यदि आप मानते हैं कि वास्तविक संयोग मुश्किल है, तो आप ओपनएसएसएल को डेबियन के लिए अनुरक्षकों से पूछ सकते हैं।

विंडोज पर, उदाहरण के लिए, छद्म यादृच्छिक संख्या पीढ़ी फ़ंक्शन 125 स्रोतों से डेटा लेता है। फ़ायरफ़ॉक्स अपने परिणाम का उपयोग करता है और अपने स्वयं के छद्म यादृच्छिक डेटा के कुछ बिट्स जोड़ता है

48-बाइट "पूर्व-मास्टर कुंजी" को गुप्त रखना बहुत महत्वपूर्ण है, क्योंकि इसमें से कई चीजें काट ली जाती हैं। कोई आश्चर्य नहीं कि फ़ायरफ़ॉक्स इतना मुश्किल है। मुझे डीबग संस्करण बनाने और इसे देखने के लिए SSLDEBUGFILE और SSLTRACE झंडे सेट करने पड़े

4456: एसएसएल [131491792]: प्री-मास्टर सीक्रेट [लेन: 48]
03 01 bb 7b 08 98 a7 49 de e8 e9 b8 91 52 ec 81 ... {... I ..... R ...
4c c2 39 7b f6 ba 1c 0a b1 95 50 29 be 02 ad e6 L.9 {...... P) ...
ad 6e 11 3f 20 c4 66 f0 64 22 57 7e e1 06 7a 3b .n? .fd "डब्ल्यू ~ ..z;

यह पूरी तरह से यादृच्छिक नहीं है, टीएलएस मानक के पहले दो बाइट्स 03 01 होना चाहिए।

प्रमुख विनिमय
अब हमें इस गुप्त संख्या को Amazon.com पर स्थानांतरित करना होगा। चूँकि अमेज़न “TLS_RSA_WITH_RC4_128_MD5” का उपयोग करना चाहता था, इसलिए हम इसे RSA के साथ एन्क्रिप्ट करेंगे। आप एक संदेश के रूप में पूर्व-मास्टर कुंजी के केवल 48 बाइट्स का उपयोग कर सकते हैं, लेकिन PKCS # 1 v1.5 मानक के अनुसार, आपको यादृच्छिक डेटा के साथ एक खाली जगह को भरने और पैकेट आकार को 128 बाइट्स में लाने की आवश्यकता है। इसलिए हमलावर को पैकेट को डिक्रिप्ट करना अधिक कठिन होगा।

अंत में, फ़ायरफ़ॉक्स अंतिम अनएन्क्रिप्टेड मैसेज भेजता है, "चेंज सिफर स्पेस" एंट्री:

यह फ़ायरफ़ॉक्स के अमेज़न को बताने का तरीका है कि यह निम्नलिखित संदेशों के लिए पहले से पारित गुप्त कुंजियों का उपयोग करने जा रहा है।

कम्प्यूटिंग मास्टर सीक्रेट

यदि हमने सब कुछ सही किया है, तो दोनों पक्ष अब प्री-मास्टर कुंजी के 48 बाइट्स जानते हैं। अमेज़ॅन की ओर से एक मामूली अविश्वास है, क्योंकि पूर्व-मास्टर में केवल क्लाइंट डेटा होता है और सर्वर डेटा नहीं होता है। मास्टर कुंजी की गणना करके इसे ठीक करें।

Master_secret = PRF (pre_master_secret, "मास्टर सीक्रेट", ClientHello.random + ServerHello.random)

PRF एक छद्म आयामी फ़ंक्शन है जिसे विनिर्देशों में परिभाषित किया गया है और यह बहुत मुश्किल है। यह HMAC संस्करण MD5 और SHA-1 का उपयोग करता है। आधा इनपुट प्रत्येक फ़ंक्शन को भेजा जाता है, और परिणाम हमलों के लिए बहुत प्रतिरोधी है।

नतीजतन, हमें मास्टर गुप्त के 48 बाइट्स मिलते हैं।

4C AF 20 30 8F 4C AA C5 66 4A 02 90 F2 AC 10 00 39 DB 1D E0 1F CB E0 ED 9D D7 E6 BE 62 A4 6C 18 06 AD 79 21 DB 82 1D 53 84 35 35 A7 1F C1 01 19

अन्य कुंजी उत्पन्न करें

अब जब दोनों पक्षों के पास एक गुप्त रहस्य है, तो विनिर्देश के अनुसार हम "कुंजी ब्लॉक" बनाने के लिए PRF का उपयोग करके सत्र के लिए आवश्यक सभी कुंजी की गणना कर सकते हैं, जिसमें से हम आवश्यक डेटा लेते हैं:

key_block = PRF (SecurityParameters.master_secret, "कुंजी विस्तार", SecurityParameters.server_random + SecurityParameters.client_random);

"कुंजी ब्लॉक" से बाइट्स के लिए आवश्यक हैं:
client_write_MAC_secret [SecurityParameters.hash_size]
server_write_MAC_secret [SecurityParameters.hash_size]
client_write_key [SecurityParameters.key_material_length]
server_write_key [SecurityParameters.key_material_length]
client_write_IV [SecurityParameters.IV_size]
server_write_IV [SecurityParameters.IV_size]

चूंकि हम ब्लॉक एन्क्रिप्शन के बजाय स्ट्रीमिंग का उपयोग करते हैं, इसलिए हमें आरंभीकरण वैक्टर की आवश्यकता नहीं है। हालाँकि, हमें प्रत्येक पक्ष के लिए दो संदेश प्रमाणीकरण कोड (मैक) कुंजी, प्रत्येक 16 बाइट्स की आवश्यकता है, क्योंकि एमडी 5 का परिणाम भी 16 बाइट्स लंबा है। इसके अलावा, RC4 16 बाइट कुंजी का उपयोग करता है, जिसकी आवश्यकता दोनों पक्षों को भी होगी। सामान्य तौर पर, हमें कुंजी ब्लॉक से 2 * 16 + 2 * 16 = 64 बाइट्स की आवश्यकता होती है

PRF चल रहा है, हमें मिलता है:
client_write_MAC_secret = 80 B8 F6 09 51 74 EA DB 29 28 EF 6F 9A B8 81 B0
server_write_MAC_secret = 67 7C 96 7B 70 C5 BC 62 9D 1D 1F 4A A6 79 81 61
client_write_key = 32 13 2C DD 1B 39 36 40 84 4A DE E5 6C 52 46 72
server_write_key = 58 36 C4 0D 8C 7C 74 DA 6D B7 34 0A 91 B6 6F A7

एन्क्रिप्ट होने के लिए तैयार हो जाओ!

ग्राहक द्वारा भेजा गया अंतिम हैंडशेक संदेश "अंतिम संदेश" है। यह एक मुश्किल संदेश है जो यह साबित करता है कि किसी ने भी हाथ नहीं लगाया और साबित कर दिया कि हम कुंजी जानते हैं। क्लाइंट हैंडशेक संदेशों से सभी बाइट्स लेता है और इसे बफर में जोड़ता है। फिर पुष्टि के 12 बाइट्स की गणना छद्म-यादृच्छिक संख्या जनरेटर, मास्टर कुंजी, "क्लाइंट समाप्त" लाइन और MD5 और SHA-1 बफर से की जाती है।

Ver_data = PRF (master_secret, "क्लाइंट समाप्त", MD5 (हैंडशेक_मेज़ेज) + SHA-1 (हैंडशेक_मेज़ेज))

हम परिणाम लेते हैं और बाइट 0x14 जोड़ते हैं, पूरा होने का संकेत देते हैं, और हेडर की लंबाई 00 00s को इंगित करते हैं कि हम 12 बाइट भेज रहे हैं। फिर, जैसा कि भविष्य में और सभी एन्क्रिप्टेड संदेशों के लिए, आपको यह सुनिश्चित करने की आवश्यकता है कि किसी ने डिक्रिप्टेड सामग्री को जाली नहीं किया है। हम MD5, या इसके HMAC संस्करण का उपयोग करते हैं।

HMAC_MD5 (कुंजी, m) = MD5 ((कुंजी) opad) ++ MD5 ((कुंजी m ipad) ++ m)
(Ation का अर्थ है XOR, ++ का अर्थ है संघनन, "opad" बाइट्स है "5c 5c ... 5c", और "ipad" बाइट्स है "36 36 ... 36")।

सामान्य तौर पर, हम गणना करते हैं:
HMAC_MD5 (client_write_MAC_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));

जैसा कि आपने देखा होगा, हम अनुरोध संख्या में मिलाते हैं, जो एक पैकेट पुनरावृत्ति के साथ एक विशिष्ट हमले से बचाता है।
यह केवल एन्क्रिप्ट करने के लिए बनी हुई है।

RC4 एन्क्रिप्शन

एन्क्रिप्शन एल्गोरिदम का चयनित सेट हमें आरसी 4 का उपयोग करने के लिए कहता है। यह इतना सरल है कि आप इसे कुछ मिनटों में सीख सकते हैं।

RC4 एक 256 बाइट सरणी S बनाने और 0 से 255 तक मानों के साथ भरने से शुरू होता है। फिर आपको कुंजी के बाइट्स को "हस्तक्षेप" करके सरणी के माध्यम से जाना होगा। यह यादृच्छिक बाइट्स उत्पन्न करने के लिए उपयोग की जाने वाली राज्य मशीन बनाने के लिए किया जाता है। फिर हम सरणी एस को मिलाते हैं।

आलेखीय रूप से, इसे निम्नानुसार दर्शाया जा सकता है:

एक बाइट को एन्क्रिप्ट करने के लिए, हम XOR के साथ एक छद्म यादृच्छिक बाइट को एन्क्रिप्ट करते हैं।
तो, सब कुछ काफी सरल है, और जल्दी से काम करता है। मुझे ऐसा लगता है कि इस वजह से, अमेज़ॅन ने इस एल्गोरिदम को चुना।

याद रखें कि हमारे पास "client_write_key" और "server_write_key" है। इसका मतलब है कि हमें RC4 के दो उदाहरणों की आवश्यकता है: एक डिक्रिप्टिंग प्रतिक्रियाओं के लिए, दूसरा एन्क्रिप्टिंग अनुरोधों के लिए।

"Client_write" से पहले कुछ यादृच्छिक बाइट्स "7E 20 7A 4D FE FB 78 A7 33 ..." हैं। यदि आप एक अनएन्क्रिप्टेड हेडर के साथ इन बाइट्स का चयन करते हैं और "14 00 00 0C 98 F0 AE CB C4 ..." संदेश के बाइट्स की जांच करते हैं, तो हमें नीचे दिए गए स्क्रीनशॉट के स्क्रीनशॉट में देखा जा सकता है:

सर्वर लगभग एक ही काम करता है। यह "चेंज सिफर स्पेस" और फिर एक "फाइनल" संदेश भेजता है, जिसमें सभी हैंडशेक संदेश और एक अनएन्क्रिप्टेड "अंतिम" संदेश शामिल होता है। यह क्लाइंट को साबित करता है कि सर्वर उसके संदेशों को डिक्रिप्ट करने में सक्षम था।

आवेदन स्तर पर आपका स्वागत है!

अब, 220 मिलीसेकंड के बाद (तीन घंटे बाद - लगभग अनुवाद।), हम अंततः आवेदन स्तर का उपयोग करने के लिए तैयार हैं। अब आप नियमित HTTP ट्रैफ़िक का आदान-प्रदान कर सकते हैं, जिसे RC4 का उपयोग करके TLS के साथ एन्क्रिप्ट किया जाएगा और स्पूफिंग के मामले में जाँच की जाएगी।

हैंडशेक अब पूरा हो गया है। टीएलएस रिकॉर्ड की सामग्री अब 0x17 है। एन्क्रिप्टेड ट्रैफ़िक 17 03 01 से शुरू होता है, जो टीएलएस के रिकॉर्ड और संस्करण के प्रकार को इंगित करता है।

पैकेट एन्क्रिप्शन:

GET /gp/cart/view.html/ref=pd_luc_mri HTTP / 1.1
होस्ट: www.amazon.com
उपयोगकर्ता-एजेंट: मोज़िला / 5.0 (विंडोज; यू; विंडोज एनटी 6.0; एन-यूएस; आरवी: 1.9.0.10) गेको / 2009060911 माइनफील्ड / 3.0.10 (.NET सीएलआर 3.5.30729)
स्वीकार करें: टेक्स्ट / html, एप्लिकेशन / xhtml + xml, एप्लीकेशन / xml; q = 0.9, * / *; q / =
स्वीकार-भाषा: en-us, en; q = 0.5
स्वीकार-एनकोडिंग: गज़िप, अपस्फीति
स्वीकार-चर्या: ISO-8859-1, utf-8; q = 0.7, *; q = 0.7
कीप-अलाइव: 300
कनेक्शन: जीवित रखें
...

लगभग निम्नलिखित परिणाम देगा:

सर्वर वही करता है। डिक्रिप्शन हमें निम्नलिखित देता है:

HTTP / 1.1 200 ठीक है
दिनांक: बुध, 10 जून 2009 01:09:30 GMT
सर्वर: सर्वर
...
अवधारणा: करीब
स्थानांतरण-एन्कोडिंग: chunked

कनेक्शन तब तक खुला रहता है जब तक दोनों तरफ संदेश पूरा होने की चेतावनी नहीं भेज देता है, और फिर कनेक्शन बंद कर देता है। यदि हम पिछले कनेक्शन को बंद करने के तुरंत बाद फिर से कनेक्ट करते हैं, तो हम पुरानी चाबियों का उपयोग कर सकते हैं ताकि हैंडशेक फिर से बाहर न करें।

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

वह सब है!

टीएलएस आरएफसी में कई विवरण शामिल हैं जिनकी हमने चर्चा नहीं की है। हमने फ़ायरफ़ॉक्स और अमेज़ॅन के बीच केवल 220 मिलीसेकंड नृत्य की जांच की। हमने सीखा कि यदि कोई अमेज़न के नंबर n को p और q में घटाता है, तो वे प्रमाणपत्र बदलने तक सभी अमेज़न ट्रैफ़िक को डिक्रिप्ट कर सकते हैं।

केवल 220 मिलीसेकंड में, इंटरनेट पर दो बिंदु जुड़े हुए हैं, एक दूसरे को विश्वास के लिए पर्याप्त डेटा प्रदान करते हैं, एन्क्रिप्शन एल्गोरिदम सेट करते हैं और एन्क्रिप्टेड ट्रैफ़िक का आदान-प्रदान शुरू करते हैं।

और सब इतना है कि बॉब दूध खरीद सकता है।

HTTPS कनेक्शन के पहले कुछ मिलीसेकंड