本文翻譯自：
https://www.wst.space/ssl-part1-ciphersuite-hashing-encryption/
https://www.wst.space/ssl-part-2-diffie-hellman-key-exchange/
作為一名安全愛好者，我一向很喜歡SSL（目前是TLS）的運(yùn)作原理。理解這個(gè)復(fù)雜協(xié)議的基本原理花了我好幾天的時(shí)間，但只要你理解了底層的概念和算法，就會感覺整個(gè)協(xié)議其實(shí)很簡單。在學(xué)習(xí)SSL運(yùn)作原理的過程中，我獲益匪淺。回想起在大學(xué)期間學(xué)到的密碼學(xué)，那段時(shí)間學(xué)習(xí)它們可是一件很無聊的事?，F(xiàn)在，我開始明白老師為什么要讓我學(xué)習(xí)加密的算法，因?yàn)槊艽a學(xué)可以讓我們的生活變得更加輕松。在這里，我想分享我所學(xué)到的一切，當(dāng)然，我希望這對你能有所幫助。我們就此開始吧。
SSL的歷史
在了解SSL的歷史時(shí)，有必要提一下Mozilla Foundation。說到Mozilla，首先我們想到的是他們著名的瀏覽器Firefox。根據(jù)各種消息來源來看，F(xiàn)irefox是繼Chrome和Safari之后最受歡迎的瀏覽器。但Firefox杰出的前身是Netscape，在90年代它是互聯(lián)網(wǎng)用戶中最受歡迎的瀏覽器。盡管這樣，在微軟推出了Internet Explorer之后，Netscape的時(shí)代也就隨之結(jié)束了，之后他們便建立了著名的Mozilla基金會，它仍然在成長。
1994年，Netscape為Netscape Navigator瀏覽器研發(fā)了SSL。其作用主要是為了防止中間人攻擊。后來，隨著互聯(lián)網(wǎng)可訪問性的增加，銀行開始利用互聯(lián)網(wǎng)進(jìn)行交易。當(dāng)時(shí)安全性是一個(gè)很重要的問題，IETF （互聯(lián)網(wǎng)工程任務(wù)組），也就是一群標(biāo)準(zhǔn)化互聯(lián)網(wǎng)協(xié)議的人，他們研發(fā)屬于自己的協(xié)議版本來標(biāo)準(zhǔn)化SSL，這是在1999年，現(xiàn)在該協(xié)議被稱為TLS（傳輸層安全性），它的最新版本是TLS 1.3。
關(guān)于密碼學(xué)的幾點(diǎn)注意事項(xiàng)
首先，在深入研究這個(gè)話題之前，我們需要對幾件事情有一個(gè)基本的了解。最重要的一個(gè)是密碼學(xué)。理解SSL您不需要成為密碼學(xué)專家，但基本的了解是必要的。我們接下來會在這里討論基礎(chǔ)知識。已經(jīng)知道非對稱和對稱密鑰加密的朋友們可以直接跳過本節(jié)進(jìn)入下一部分。
??密碼學(xué)的處理對象是數(shù)字和字符串?；旧险麄€(gè)宇宙中的每一個(gè)數(shù)據(jù)都是數(shù)字。這里我們所說的數(shù)字，就是0和1，也就是二進(jìn)制。你在屏幕上看到的圖像，通過耳機(jī)聽到的音樂，一切都是二進(jìn)制文件，但我們的耳朵和眼睛都不能理解二進(jìn)制文件嗎？只有大腦才能理解這一點(diǎn)，但即使它能夠理解二進(jìn)制文件，它也無法享受二進(jìn)制文件。因此，我們將二進(jìn)制文件轉(zhuǎn)換為人類可理解的格式，如mp3，jpg等。我們將這個(gè)過程稱為編碼，它是雙向處理，可以很容易地解碼成原始形式。
哈希
散列是另一種數(shù)據(jù)一旦轉(zhuǎn)換為其他形式將永遠(yuǎn)無法恢復(fù)的加密技術(shù)。在Layman的術(shù)語中，沒有稱為去散列的過程。有很多哈希函數(shù)都可以完成這項(xiàng)工作，比如sha-512，md5等等。wst.space 的sha-512 值是，
83d98e97ec1efc3cb4d20f81a246bff06a1c145b7c06c481defed6ef31ce6ad78db3ecb36e7ce097966f019eab7bdc7ffa6b
3f b8c5226871667ae13a6728c63b
您可以通過訪問某個(gè)在線創(chuàng)建哈希網(wǎng)站并輸入wst.space 來驗(yàn)證。
如果無法恢復(fù)原始值，那么我們在哪兒可以使用它呢？密碼！當(dāng)你給移動(dòng)設(shè)備或PC設(shè)置密碼時(shí)，便會創(chuàng)建哈希密碼然后存儲在安全的位置。當(dāng)您下次進(jìn)行登錄嘗試時(shí)，再次使用相同的算法（散列函數(shù)）對輸入的字符串進(jìn)行散列，并將輸出與存儲的值進(jìn)行匹配。如果它是相同的，你就會登錄。否則你將無法登錄。
對密碼運(yùn)用哈希算法，我們就可以確保攻擊者即使竊取了存儲的密碼文件也永遠(yuǎn)不會得到我們的密碼。攻擊者有的只是密碼的哈希值。他也可能會找到最常用密碼的列表，然后將sha-512應(yīng)用于每個(gè)密碼，再將其與手中的值進(jìn)行比較，這種方法稱為字典攻擊。但這樣做需要多久？如果您的密碼足夠隨機(jī)，您認(rèn)為這種破解方法是否有效？
我們在一篇博客文章中討論了會話cookie。它的值是會話cookie，通常是哈希值。Facebook，Google和亞馬遜數(shù)據(jù)庫中的所有密碼都經(jīng)過哈希處理，或者至少它們應(yīng)該被哈?；?。
接下來是加密
加密位于散列和編碼之間。編碼是一個(gè)雙向過程，不應(yīng)用于提供安全性。加密也是一個(gè)雙向過程，但當(dāng)且僅當(dāng)加密密鑰已知時(shí)才能檢索原始數(shù)據(jù)。如果您不知道加密的工作原理，請不要擔(dān)心，我們將在此討論基礎(chǔ)知識。這對理解SSL的基礎(chǔ)知識已經(jīng)足夠了。共有兩種類型的加密，即對稱加密和非對稱加密。
對稱密鑰加密
我盡可能地說簡單點(diǎn)。所以，我們可以通過移位算法來理解對稱加密，這個(gè)算法是通過將字母向左或向右移動(dòng)來加密字母表。我們?nèi)∫粋€(gè)字符串CRYPTO并考慮一個(gè)數(shù)字+3，然后，CRYPTO的加密格式將是FUBSWR，也就是意味著每個(gè)字母向右移動(dòng)3個(gè)位置。
這里，單詞CRYPTO稱為明文，輸出FUBSWR稱為密文，值+3稱為加密密鑰（對稱密鑰），整個(gè)過程為密碼。這是最古老和最基本的對稱密鑰加密算法之一，其首次使用是在Julius Caesar時(shí)期，所以以他的名字命名，它是一種著名的凱撒密碼。任何知道加密密鑰并且可以應(yīng)用凱撒算法的人都可以反向并檢索原始明文。因此，它被稱為對稱加密。
我們可以使用TLS進(jìn)行對稱加密嗎
如您所知，這種算法很容易破解，因?yàn)榭赡苄暂^小。我們可以將key的值從1更改為任何內(nèi)容，并逐個(gè)迭代26個(gè)字母。請注意，如果我們只加密小寫英文字母，則key的值限制為26。我們的計(jì)算機(jī)使用Bruteforce處理這個(gè)過程只需幾毫秒。如今，存在諸如AES（高級加密標(biāo)準(zhǔn)）和3DES（三重?cái)?shù)據(jù)加密算法）的復(fù)雜算法。它們都被公認(rèn)為很難破解。
這是在發(fā)送和接收數(shù)據(jù)時(shí)在SSL/TLS中使用的加密技術(shù)。但客戶端和服務(wù)器需要在開始加密數(shù)據(jù)之前就密鑰達(dá)成一致并進(jìn)行交換，是這樣的嗎？交換密鑰的最初步驟顯然是純文本。如果攻擊者在共享密鑰時(shí)捕獲密鑰怎么辦？那使用它也就沒有了意義。因此，我們需要一種安全機(jī)制來交換密鑰，而不會讓攻擊者真正看到它。所以就出現(xiàn)了非對稱密鑰加密的作用。
非對稱密鑰加密
我們知道，在對稱加密中，相同的密鑰用于加密和解密。一旦該密鑰被盜，所有數(shù)據(jù)都將消失。這是一個(gè)巨大的風(fēng)險(xiǎn)，我們需要更復(fù)雜的技術(shù)。1976年，Whitfield Diffie和Martin Hellman首次提出了非對稱加密的概念，該算法被稱為Diffie-Hellman密鑰交換。然后在1978年，麻省理工學(xué)院的Ron Rivest，Adi Shamir和Leonard Adleman發(fā)表了RSA 算法。這些都可以被視為非對稱加密的基礎(chǔ)。
與對稱加密相比，在非對稱加密中，將有兩個(gè)關(guān)鍵點(diǎn)而不是一個(gè)。一個(gè)稱為公鑰，另一個(gè)稱為私鑰。理論上，在啟動(dòng)期間，我們可以生成公私鑰匙對我們的機(jī)器。私鑰應(yīng)保存在安全的地方，絕不應(yīng)與任何人共享。顧名思義，公鑰可以與希望向您發(fā)送加密文本的任何人共享?，F(xiàn)在，那些擁有您的公鑰的人可以使用它加密秘密數(shù)據(jù)。如果密鑰對是使用RSA算法生成的，那么它們應(yīng)該在加密數(shù)據(jù)時(shí)使用相同的算法。一般來說，加密算法會在公鑰中指定，加密數(shù)據(jù)只能使用您擁有的私鑰。
我們可以對所有TLS使用非對稱加密嗎
非對稱加密也稱為公鑰基礎(chǔ)結(jié)構(gòu)，又稱PKI，這樣命名的原因是自解釋。不管怎樣，只要您保持私鑰安全，數(shù)據(jù)就是安全的。多好??！所以，現(xiàn)在你可能會想，為什么我們?nèi)匀粫赥LS中使用對稱加密？我們有很多安全的PKI啊。是的，我也同意。但應(yīng)該指出，必須在不影響可用性的情況下再處理安全的問題。由于PKI涉及雙密鑰架構(gòu)并且密鑰長度通常很大，因此加密-解密開銷非常高。與對稱密鑰加密相比，它需要更多的時(shí)間和CPU占有率。
因此，當(dāng)在客戶端和服務(wù)器之間發(fā)送和接收數(shù)據(jù)時(shí)，用戶會感覺到等待的時(shí)間更久，而且瀏覽器會開始吃掉CPU。因此PKI僅用于在客戶端和服務(wù)器之間交換對稱密鑰，此后，才是對稱密鑰加密開始起作用并且新的數(shù)據(jù)傳輸也使用了這種技術(shù)。好吧，我知道我只是在這里輕描淡寫，因?yàn)槲疫€沒有真正涉足這個(gè)話題。請記住我們到目前為止所討論的內(nèi)容然后回到這兒，我們將從下一篇博客文章中深入探討。
密鑰交換算法
在博客系列的最后部分，我們已經(jīng)討論了密碼學(xué)的基本概念：包括散列，對稱和非對稱加密等。除了他們的歷史，我沒有說過任何關(guān)于SSL或TLS的內(nèi)容。我希望我們已經(jīng)完成了基礎(chǔ)部分，所以讓我們挖掘點(diǎn)真實(shí)的東西吧。在這篇博文中，我們將根據(jù)Diffie-Hellman密鑰交換的密鑰交換算法。
了解SSL中的加密類型
從博客系列的最后一部分開始，我們知道在SSL中使用了對稱加密和非對稱加密，接下來，我們將看到使用了哪種加密算法，在哪里使用的以及使用的原因。
想象一下，你正在瀏覽Facebook，F(xiàn)acebook在默認(rèn)情況下通過https重新路由您的所有流量。由于您使用的是TLS（我將在大多數(shù)地方使用TLS而不是SSL，因?yàn)樗F(xiàn)在是標(biāo)準(zhǔn)的）連接，您會在URL欄上看到一個(gè)綠色框以確認(rèn)該連接是安全的。在單個(gè)會話期間，您會進(jìn)行多項(xiàng)活動(dòng)，例如評論，聊天，在頁面之間導(dǎo)航，滾動(dòng)新聞源等等。每次執(zhí)行這些操作時(shí)，在客戶端和服務(wù)器之間會共享多個(gè)請求和響應(yīng)，所有這些通信都必須通過https才能確保數(shù)據(jù)安全。這意味著服務(wù)器和客戶端瀏覽器正在為單個(gè)Facebook會話加密和解密數(shù)據(jù)包100次。
我們知道公鑰加密的解密密鑰永遠(yuǎn)不會與任何人共享，所以比對稱密鑰加密更安全，但是，如果我們還知道，在公鑰基礎(chǔ)設(shè)施（PKI）中，與對稱密鑰加密相比，它使用更多的CPU而且需要更多的時(shí)間來加密和解密，開銷更高，導(dǎo)致瀏覽器（和應(yīng)用程序服務(wù)器）開始占用您的CPU資源；此外，瀏覽器每次都必須經(jīng)歷繁忙的加密步驟，所以需要更多的時(shí)間才能提供內(nèi)容。
如何解決
鑒于以上原因，我們需要使用對稱加密來實(shí)現(xiàn)這一目標(biāo)，這樣可以更快，資源消耗可以更少，兩全其美。但客戶端和服務(wù)器在開始加密之前必須就單個(gè)密鑰達(dá)成一致，對吧？他們會怎么做？在共享唯一的密鑰時(shí)，坐在客戶端和服務(wù)器之間的攻擊者可以捕獲它和Kaboom！您的所有數(shù)據(jù)都泄漏了。故而必須有一種解決方法來共享密鑰并在那里我們使用公鑰加密。
在客戶端和服務(wù)器之間共享并同意一個(gè)秘密密鑰的一系列過程我們稱為握手，這是TLS的第一步。握手涉及多個(gè)過程，整個(gè)過程稱為公鑰基礎(chǔ)結(jié)構(gòu)，還記得我們在博客系列的最后部分使用了這個(gè)術(shù)語嗎？PKI包括證書頒發(fā)機(jī)構(gòu)（CA），數(shù)字簽名等，我們將在下面深入討論基礎(chǔ)架構(gòu)。
密鑰交換算法
因此，很明顯非對稱加密用于交換密鑰，但用哪種算法呢？自從非對稱密碼學(xué)發(fā)明以來，提出了許多算法。在寫這篇文章的過程中，TLS1.2是常用的標(biāo)準(zhǔn)，還有RSA、Diffie-Hellman密鑰交換、ECDH（Elliptic Curve Diffie-Hellman）、SRP（安全遠(yuǎn)程密碼）、由TLS 1.2支持密鑰交換算法PSK（Pre Shared Key）。
在這里討論所有算法可能是個(gè)麻煩事，相反我們將討論最常見且易于理解的Diffie-Hellman密鑰交換算法。
Diffie-Hellman Key Exchange解釋
我不打算直接去算，因?yàn)檫@方面并不是我的強(qiáng)項(xiàng)，而是讓我們嘗試用顏色類比來理解這個(gè)概念。想象一下，Alice和Bob正在做一些海報(bào)工作，他們的對手 Mallory也坐在替補(bǔ)席旁邊。Alice和Bob想要達(dá)成共識，使用一種顏色來設(shè)計(jì)海報(bào)，他們無法大聲討論，因?yàn)镸allory會聽到它。那么他們?nèi)绾谓y(tǒng)一顏色呢？這個(gè)問題的解決方案就是Diffie-Hellman密鑰交換算法的最簡單形式，接下來我們來一探究竟。
方案步驟
- 1.首先，Alice會選擇一種常見的顏色，比如黃色，然后告訴Bob，她將在本次會議中使用黃色。顯然，Mallory可以聽到，但是沒有關(guān)系。
- 2.然后，Alice和Bob選擇他們自己的秘密顏色，他們不會告訴對方。所以Mallory永遠(yuǎn)不會知道秘密顏色。例如，Alice選橙色作為秘密顏色，Bob選綠色。
- 3.在這個(gè)步驟中，Alice將混合她的秘密顏色橙色和常用顏色黃色以產(chǎn)生新的顏色。涼鞋的顏色是可以嗎？（我的顏色感覺不太好，原諒我。）
- 4.同樣，Bob也將他的秘密顏色與黃色混合以生成新的藍(lán)色。
- 5.Alice和Bob將告訴彼此這些新顏色。Mallory可以看到?jīng)鲂伾退{(lán)色，但不是他們的秘密顏色。
- 6.交換完成后，Alice會將她的秘密顏色（橙色）混合到Bob發(fā)送的混合物中。Bob會將他的秘密顏色（綠色）與Alice發(fā)送的混合物混合。
- 7.現(xiàn)在Alice和Bob都達(dá)到了一種共同秘密色彩的混合物。請參考下圖。Mallory將會被涼鞋色和藍(lán)色困住，因?yàn)镸allory不知道Alice和Bob的秘密顏色，所以他永遠(yuǎn)不會達(dá)到他們倆得到的共同的秘密顏色。
image
這里，共同色（Yellow）可以被視為服務(wù)器的公鑰，每個(gè)人都可以使用。最后獲得的公共秘密可以被認(rèn)為是用于在進(jìn)一步的會話中加密數(shù)據(jù)的對稱密鑰，這不完全正確，但對于基本的理解，我們先保持這樣，如果你深入挖掘，相信你會理解到精確的邏輯。
Diffie-Hellman密鑰交換背后的數(shù)學(xué)
讓我們來看看上述算法背后的基本數(shù)學(xué)。為了更好地理解Diffie-Hellman的概念，我們需要了解模運(yùn)算。那些不想看數(shù)學(xué)的朋友們可以跳過本節(jié)，其他人可以關(guān)注我。
很明顯，當(dāng)你將7和8加起來，你會得到15，這是小學(xué)算術(shù)問題。但是在12小時(shí)制的情況下，情況就不是這樣的了。如果時(shí)間現(xiàn)在是7點(diǎn)，那么8小時(shí)后，時(shí)間將是3點(diǎn)。故而我們可以說時(shí)鐘是算術(shù)模12的模運(yùn)算的最簡單的例子。在這種情況下，我們知道12:00也就相當(dāng)于00:00，所以我們可以說12和0是一樣的，反之亦然。
在數(shù)學(xué)上，
A = b(mod P)
如果我們將p的值設(shè)為12，將b設(shè)為21。然后，
21（mod 12）= 9
我們將其轉(zhuǎn)換為Diffie-Hellman示例。在閱讀以下內(nèi)容時(shí)，請記住顏色類比。想象一下，Alice和Bob都知道g和p的值，或者Alice先前決定了這些值并將其發(fā)送給Bob。換句話說，這些值是公開的?，F(xiàn)在，
觀察到 S_A= S_B=K 。這是用于加密會話的會話密鑰。
Mallory獲得秘密鑰匙的機(jī)會
在整個(gè)過程中，請注意Alice（a）的秘密和Bob（b）的秘密永遠(yuǎn)不會彼此共享。因此，Mallory只知道g，p，A和B.為了得到K的值，Mallory首先需要從A = g^a（mod p）和B = g^b（mod p）計(jì)算a＆b ，數(shù)學(xué)上這被稱為離散對數(shù)問題。對于較大的p值，要計(jì)算結(jié)果幾乎100％不可行。在實(shí)際的TLS實(shí)現(xiàn)中，p的長度將在1024或2048位的范圍內(nèi)。也就是說，2048位密鑰的長度在 2^2047和 2^2048之間。希望你知道一個(gè)2^3長度的秘鑰的最大值可以為8.想象一下2048位密鑰得有多復(fù)雜。
當(dāng)使用這樣的密鑰時(shí)，即使是世界上最大的超級計(jì)算機(jī)也將花費(fèi)100年的時(shí)間才能計(jì)算出a＆b。更不幸的是，這些值會隨著每個(gè)會話而變化。所以啊，即使攻擊者算出了這個(gè)值，在以下會話中他也無法用來模擬用戶。這就是所謂的完美前瞻性保密。
我們現(xiàn)在安全嗎
服務(wù)器和客戶端瀏覽器已經(jīng)同意安全共享通過強(qiáng)密鑰交換算法的密鑰，一切都看起來很不錯(cuò)。但是先等等，我們真的足夠安全嗎？讓我們想象一下我們嘗試使用https連接到facebook.com的場景，假設(shè)攻擊者已經(jīng)位于您的瀏覽器和Facebook服務(wù)器之間，您的瀏覽器將告訴Facebook服務(wù)器啟動(dòng)TLS通道，但攻擊者可以設(shè)置自己的服務(wù)器，并通過他的服務(wù)器重新路由你和Facebook.com之間的所有通信，因此，當(dāng)Facebook服務(wù)器發(fā)送其公鑰時(shí)，攻擊者可以用他的公鑰替換它并將其轉(zhuǎn)發(fā)給您。
然后下一步，您收到公鑰認(rèn)為它實(shí)際上來自Facebook.com，您的瀏覽器將使用它加密您的密鑰并將其發(fā)送回Facebook。再一次，攻擊者會抓住它并猜猜是什么？他有相應(yīng)的私鑰來解密密鑰，然后用Facebook.com的公鑰（他已經(jīng)擁有）的原始值加密它并將其轉(zhuǎn)發(fā)回Facebook.com，然后，他將繼續(xù)進(jìn)行加密 - 解密過程，如此一來，他就可以看到你和Facebook.com之間共享的所有內(nèi)容。
現(xiàn)在怎么辦
問題的答案是CA（證書頒發(fā)機(jī)構(gòu)）。簡單來說，證書頒發(fā)機(jī)構(gòu)由X.509標(biāo)準(zhǔn)指定，以確保數(shù)據(jù)的完整性，數(shù)據(jù)完整性可確保在傳輸中的數(shù)據(jù)不會被第三方實(shí)體篡改。換句話說，CA充當(dāng)瀏覽器和服務(wù)器之間的中間人，確保數(shù)據(jù)完整性是CA的職責(zé)。
我們將在下一篇博客文章中深入討論CA。
