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