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