許多小伙伴應(yīng)該都聽過大名鼎鼎的HTTPS，而HTTPS就是通過在HTTP的基礎(chǔ)上引入TLS，實現(xiàn)對明文進(jìn)行傳輸加密和身份認(rèn)證，保證了傳輸過程的安全。由于TLS協(xié)議深度依賴抽象復(fù)雜的密碼學(xué)原理、工具箱及設(shè)計模式，令許多小伙伴都望而卻步。不用擔(dān)心，今天小懌會用通俗易懂的方式，層層遞進(jìn)，帶領(lǐng)大家一起經(jīng)歷密碼學(xué)入門到TLS精通之路。
1、TLS速覽—3W1H分析
1.WHAT：TLS是什么？
TLS（傳輸層安全性協(xié)議，Transport Layer Security）及它的前身SSL（安全套接字層，現(xiàn)在不推薦使用的）是一種旨在提供計算機(jī)網(wǎng)絡(luò)上的安全通信的加密協(xié)議。TLS建立在網(wǎng)景（Netscape）開發(fā)的早期SSL規(guī)范（1994、1995、1996）的基礎(chǔ)上；SSL從網(wǎng)景移交到IETF后，IETF將其更名為TLS，TLS最早版本發(fā)布于1999年，當(dāng)前最新版本為發(fā)布于2018年8月的TLS 1.3。
2.WHY：為什么要用TLS？
目的是在兩個或多個通信計算機(jī)應(yīng)用程序之間提供機(jī)密性、認(rèn)證、數(shù)據(jù)完整性、前向安全性等安全特性，防止通信被竊聽和篡改。
3.WHERE：TLS現(xiàn)在用在哪？
廣泛用于電子郵件，即時消息傳遞（微信）和IP語音等應(yīng)用中，最常見的應(yīng)用場景是作為HTTPS的‘安全’層。
4.HOW：TLS到底咋用？
借用密碼學(xué)的經(jīng)典原則：永遠(yuǎn)不要試圖去創(chuàng)造自己的加密算法，要使用專家設(shè)計好的標(biāo)準(zhǔn)算法。讓我們引申下，由于side effect破解的存在，在生產(chǎn)環(huán)境中甚至都不要使用自己實現(xiàn)的TLS協(xié)議，目前有很多開源的TLS協(xié)議實現(xiàn)，可以針對應(yīng)用場景進(jìn)行裁剪和適配。
以上內(nèi)容你學(xué)會（廢）了嗎？那讓我們再上點(diǎn)對抗哈。讓我們看一個TLS中最常使用的密碼套件(Cipher Suite)：
由上面這個加密算法套件可見，如果想弄清楚TLS，必須對密碼學(xué)的基本概念（密鑰交換、身份驗證、加密算法模式等），使用它們期望解決的威脅以及各場景下常用的密碼學(xué)算法有基本的了解，才能真正從整體“戰(zhàn)略”上了解TLS，為后面從“戰(zhàn)術(shù)”角度逐個擊破單個技術(shù)點(diǎn)打下基礎(chǔ)，否則就是“基礎(chǔ)不牢，地動山搖”，霧里看花，不知所云。
考慮到很多小伙伴對于密碼學(xué)概念不甚了解，我們的TLS介紹將分為兩期：
1.密碼學(xué)概述：對密碼學(xué)概念、威脅、解決方案做總覽式介紹
2.TLS協(xié)議詳解：從時間線、握手流程、分層模型及記錄格式角度刨析TLS
那下面就讓我們開始密碼學(xué)概述的介紹吧。
2、TLS密碼學(xué)初識—概念、威脅及解決方案
TLS作為安全通信的協(xié)議，每一設(shè)計細(xì)節(jié)無不是圍繞著安全與性能兩大核心來展開的，跟著小懌來看看現(xiàn)實中安全通信面臨的威脅、受威脅的特性及相應(yīng)解決方案。
1.機(jī)密性(Confidentiality)
這個安全特性是最直觀的，直白講就是我們理解的對消息加密。比如平時大家都喜歡在網(wǎng)上買東西，付款時需要輸入賬戶密碼，如果網(wǎng)上傳輸?shù)氖菍嶋H密碼本身，黑客只要簡單竊聽下網(wǎng)線上的消息即可獲取交易密碼，所以在實際的交易過程中不能直接傳輸密碼原文，必須使用密鑰對交易的密碼進(jìn)行加密再傳輸。對消息進(jìn)行加密后，即使黑客竊聽到了我們的消息，也無法獲知消息的具體內(nèi)容，這個過程實現(xiàn)了消息的機(jī)密性?，F(xiàn)實中常常使用加解密速度較快的對稱加密算法來實施加密：AES，3DES等。
2.密鑰配送(Key Exchange)
雖然通過密鑰對消息進(jìn)行加密實現(xiàn)了機(jī)密性，但同時也引入了另一威脅，即進(jìn)行加密用的密鑰該如何傳遞給對方呢？如果加密消息用的密鑰是使用原文來傳輸?shù)?，那如果該密鑰被竊聽了，黑客直接使用該密鑰對密文進(jìn)行解密，還是可以得到原消息，機(jī)密性也就無從談起。
因此在通信開始之前，必須先傳輸加密時使用的密鑰，或者就加密時使用的密鑰達(dá)成一致，基于此便引入了密鑰配送技術(shù)來解決這一威脅?，F(xiàn)實中最常使用的密鑰交換技術(shù)有Diffie-Hellman、RSA等。
Tips：Diffie-Hellman密鑰交換（Diffie-Hellman key exchange）基本原理是：通信雙方通過交換一些可以公開的信息就能夠生成出共享的秘密數(shù)字，而這一秘密數(shù)字就可以被用作對稱密碼的密鑰，實際上雙方并沒有真正交換密鑰，而是通過計算生成出了一個相同的共享秘鑰。因此，這種方法又稱為Diffie-Hellman密鑰協(xié)商（Diffie-Hellman key agreement）。
以上兩個威脅中黑客只使用竊聽等被動攻擊手段，并沒有實施篡改或攔截消息等其他主動攻擊，然而現(xiàn)實中，黑客往往更加強(qiáng)力，具備主動攻擊的能力，同樣隨著攻擊者的攻擊能力升級，也會帶來更加難以解決的對安全通信的威脅。
3.消息完整性(Integrity)
現(xiàn)實中很多消息比如HTTP，常常具有一些固定的格式，一些場景下黑客可以無需破解原文，直接對密文中的某些字段進(jìn)行修改來施加攻擊。如下圖所示：如果黑客知曉轉(zhuǎn)賬消息的消息格式，識別出其中的賬戶部分，直接將轉(zhuǎn)賬賬戶設(shè)為黑客自己的賬戶，就能繞過破解密碼難題和機(jī)密性防御，輕易達(dá)成盜竊目的。
為此，通信雙方必須對其發(fā)出的消息的內(nèi)容完整性進(jìn)行驗證，即確保發(fā)出的消息是原消息，未在傳輸過程中被篡改。這個威脅的解決方法是在消息末尾添加消息認(rèn)證碼MAC(Message authentication code)，常用的算法有HMAC、GMAC等。
實際使用中通常將機(jī)密性和消息完整性解決方案使用固定的方式組合在一起，構(gòu)成稱為認(rèn)證加密AE(Authenticated Encryption)的技術(shù)。常用的AE算法有：AES-192-GCM、AES-256-GCM、ChaCha20-IETF-Poly1305等。
4.身份驗證與中間人攻擊(Identification&MITM)
主動攻擊者還可能通過對消息進(jìn)行攔截、替換、偽裝，實施臭名昭著的中間人攻擊。所謂中間人攻擊，就是主動攻擊者混入發(fā)送者和接收者的中間，對發(fā)送者偽裝成接收者，對接收者偽裝成發(fā)送者的攻擊方式，在這里，Mallory就是“中間人”。教科書式的講法比較抽象，其實這種攻擊模式頗似“梁山伯與祝英臺”式的棒打鴛鴦的橋段，讓我們一起看下：
比如梁山伯寫一封信向祝英臺表示愛意，并約定一起私奔的時間，好巧不巧，這封信在投遞過程中被祝父母攔下來了，看到信上的內(nèi)容，大為生氣，下定決心阻撓這段姻緣。于是，一邊偽造祝英臺筆跡給梁山伯回了封絕交書，一邊又偽造梁山伯筆跡給祝英臺也寫了封絕交書，祝英臺和梁山伯各自收到信后，悲痛欲絕，在這個過程中祝英臺父母施加就是中間人攻擊。
為了解決該威脅，正如現(xiàn)實生活中一樣，我們首先想到的是在報文上簽個名字，這個想法很直觀，也是正確的。這個做法在數(shù)字領(lǐng)域被稱為數(shù)字簽名：即發(fā)送方通過私鑰對消息進(jìn)行加密，而接受方通過對應(yīng)公鑰進(jìn)行解密，利用公私鑰的一一對應(yīng)特性（私鑰加密所得到的密文只有用與之對應(yīng)的公鑰才能正確解密）?，F(xiàn)實中常用的簽名算法有：RSA、DSA、ECDSA等。
5.公鑰證書及公鑰基礎(chǔ)設(shè)施(PKC&PKI)
然而，要正確使用數(shù)字簽名，有一個大前提，那就是用于驗證簽名的公鑰必須屬于真正的發(fā)送者。即便數(shù)字簽名算法再強(qiáng)大，如果你得到的公鑰是偽造的，那么數(shù)字簽名也會完全失效，類比現(xiàn)實中手寫簽名、蓋章也是可以偽造的，那么即使消息簽了名字蓋了章，也還是無法確認(rèn)信件的真實性。
現(xiàn)在我們發(fā)現(xiàn)自己陷入了一個死循環(huán)——數(shù)字簽名是用來識別消息篡改及偽裝的，但是為此我們又必須從沒有被偽裝的發(fā)送者得到?jīng)]有被篡改的公鑰才行。
公鑰在傳輸過程中被攔截、替換，數(shù)字簽名被破解，安全通信再次土崩瓦解，好像我們又回到了原點(diǎn)？但讓我們重新整理下思路，會發(fā)現(xiàn)其實我們已經(jīng)離“真相”只差了一步：最開始傳輸?shù)募用苊荑€是無法公開的，而現(xiàn)在我們需要傳輸?shù)墓€卻是可以公開給任何人。傳輸需要保密的東西問題轉(zhuǎn)化為了傳輸不需要保密，只需確保真實性的東西，就好比由最初需要是傳輸?shù)氖倾y行卡密碼，轉(zhuǎn)變?yōu)橹恍鑲鬏斏矸葑C號即可。而在虛擬網(wǎng)絡(luò)上身份的證明被稱為公鑰證書(Public-Key Certificate，PKC)，里面記有姓名、組織、郵箱地址等個人信息以及屬于此人的公鑰，類比于政府機(jī)關(guān)，網(wǎng)絡(luò)中由認(rèn)證機(jī)構(gòu)CA（Certification Authority）來管理頒發(fā)公鑰證書。
有了這種類似的證書之后通信傳輸?shù)碾p方不在直接交換公鑰，而是通過交換雙方經(jīng)過權(quán)威機(jī)構(gòu)背書的公鑰證書來間接實現(xiàn)公鑰的傳遞。
喜歡刨根問底的小伙伴們肯定會問，那認(rèn)證機(jī)構(gòu)又是如何來確保公鑰證書的真實性呢？其實這個問題類似于遞歸循環(huán)，服務(wù)器的證書由中間證書來背書，中間權(quán)威機(jī)構(gòu)又會由根證書來背書，這中間的認(rèn)證鏈接關(guān)系稱為信任鏈(trust chain)，而這個最終的頒發(fā)根證書機(jī)構(gòu)，稱作信任錨點(diǎn)(Trust Anchor)。而操作系統(tǒng)或是瀏覽器通常會內(nèi)置很多知名的權(quán)威根證書機(jī)構(gòu)的公鑰證書，所以通信傳輸中無需傳輸根證書機(jī)構(gòu)的證書，這使得最終的信任鏈如遞歸一樣有一個結(jié)束條件，不至于陷入死循環(huán)中。
3、密碼學(xué)家的工具箱
最后，讓我們來整理下上文描述的通信過程中的威脅、特性及相應(yīng)解決方案，構(gòu)成稱為“密碼學(xué)家的工具箱”的密碼學(xué)套件：
大家再回到文章開始的TLS算法套件來檢驗下我們的學(xué)習(xí)成果,是否對其中的術(shù)語有個總覽式的理解呢？
經(jīng)過這些密碼理論的鋪墊和介紹，很多小伙伴已經(jīng)迫不及待的想看看TLS協(xié)議如何實現(xiàn)這些安全概念了！正如我們開篇提到，其實TLS協(xié)議只是密碼學(xué)工具箱及模式的應(yīng)用，理解了密碼學(xué)安全概念、威脅及解決方案，協(xié)議的理解也就水到渠成了。
欲知“TLS”后事如何，且聽下回分解~想繼續(xù)了解TLS的小伙伴們，請持續(xù)關(guān)注我們的公眾號吧，我們會后續(xù)會帶來詳細(xì)地接地氣的TLS協(xié)議解析。
