安全傳輸層協議（TLS）是如何保證安全的？
上篇主要是介紹了HTTP存在的兩大安全問題
- 明文
- 無法驗證服務器的真實性
從而引出了TLS。本篇就來著重介紹下TLS。
說起TLS可能有些人還比較陌生，但如果說到SSL，那知道的人就更多了。TLS其實就是SSL發展而來，版本演進大體為SSL 2.0 -> SSL 3.0 -> TLS 1.0(可以看做是SSL 3.1版)。
TLS主要提供三個基本服務
- 加密
- 身份驗證
- 消息完整性校驗
其中第三點是網絡協議中常用的一個校驗和機制，和我們這邊要說的安全話題不是太相關，不再贅述。而前兩點正好是對應了HTTP的兩個問題，下面分別介紹下。
內容加密
其實網絡通信可以類比為人之間的對話，比如A和B之間需要溝通，但兩人沒法直接見面，但有一個傳話人可以代為傳話。這樣兩人就能間接溝通了，只不過這個傳話的過程是有一定風險(被記錄，被篡改)的。
為了避免這種風險，久而久之A和B想出了一個辦法：他們約定使用傳話人不會的上海話溝通。這樣每次傳話人都聽不懂啥意思，只能盡可能有樣學樣地把A說給他的話學給B聽。
這個普通話翻譯成上海話的過程，對于傳話人來說就是一種內容的『加密』。但這個方法不一定是唯一的，可能以后另一個傳話人懂上海話呢?于是在每次使用方言溝通之前，A和B會先行溝通下他們這次對話使用的語種(兩人真是牛逼!)
這個選擇語種的過程，其實就是兩人之間關于翻譯方式的『協商』過程。傳話人要想從中搗鬼，就能立馬被發現，這樣AB兩人為了溝通安全就會停止這次溝通，轉而找其他的傳話人傳話了。
以上看到AB兩人機智的采用『翻譯』『協商』兩招完成的安全溝通了。將同樣的方法拿到網絡通信中，就是TLS的加密機制了。
這個圖描述了發送端和接收端是怎么協商他們之間的加密機制的。TLS協議是基于TCP協議之上的，圖中第一個藍色往返是TCP的握手過程，不在本文范疇中按下不表。之后的兩次橙色的往返，就是我們要重點說的協商過程了，可以叫做TLS的握手。握手過程如下：
- Client1：TLS版本號 + 所支持加密套件列表 + 希望使用的TLS選項
- Server1：選擇一個客戶端的加密套件 + 自己的公鑰 + 自己的證書 + 希望使用的TLS選項 +(要求客戶端證書)
- Client2：(自己的證書) + 使用服務器公鑰和協商的加密套件加密一個對稱密鑰
- Server2：使用私鑰解密出對稱密鑰后，發送的加密的Finish消息，表明完成握手
我們一步一步來仔細看。
第一步，客戶說明他支持的所有加密套件(就像上海話、廣東話一樣)讓服務端選擇一個。這里和Server1還完成了一個TLS選項的協商，這可以理解為在確定核心的加密方式的同時，順便溝通下是否能支持一些『附加功能』。這些附加功能先按下不表，后續會介紹兩個常用的。
第二步，服務端選擇了加密套件。加密算法都是需要一個秘鑰的，服務端這里給出的是自己的公鑰。這里的公鑰其實蘊含著一個關鍵點：秘鑰協商過程采用了不對稱加密。簡單來說，一般的對稱加密如下
encrypt(明文，秘鑰) = 密文
decrypt(密文，秘鑰) = 明文
也就是說加密和解密用的是一個秘鑰。而非對稱加密就比較神奇了
encrypt(明文，公鑰) = 密文
decrypt(密文，私鑰) = 明文
加密和解密是需要不同的密鑰的。在TLS握手前，客戶端本身不知道服務器的秘鑰的，如果運用對稱加密，那么服務端告訴客戶端秘鑰的過程中，兩者之間的中間節點其實也拿到秘鑰了，這樣后續兩者之間的加密通信，對于中間節點來說也能解密出內容了。因此這里采用不對稱加密，服務端給出一個公鑰供客戶端后續使用。此外這一步服務端還提供了證書，并且可能要求客戶端提供證書。關于證書下文會提到，只要有了證書，就能保證和你通信的對方是真實的，而不是別人偽造的。這里只要先理解，客戶端看到服務端證書后，就能夠相信服務端并使用服務端給的公鑰了。
第三步，客戶端給出了雙方后續加密通信所要使用的對稱密鑰，通過服務器公鑰加密后返回給服務端。由于對稱密鑰是被不對稱加密算法加密起來的，因此中間節點拿到后，沒有辦法解密出真正的內容。
第四步，服務端拿公鑰對應的私鑰解密出真正的對稱密鑰，至此加密算法和加密所需的密鑰都確定，服務端給客戶端發送一個finish完成握手，證明雙方都已經準備好加密通信了。之后雙方的交互都可以使用對稱加密算法加密了。
TLS擴展
說完了如何確定加密的算法和密鑰后，我們再說說那所謂的『附加功能』。所謂TLS的擴展，就是在TLS協議核心保持不變的基礎上，對其進行擴展以使其支持更多的特性，這里簡單介紹下兩個擴展：ALPN和SNI。
ALPN(Application Layer Protocol Negotiation)即應用層協議協商，旨在將原來應用層協議中的協議協商，提前合并到TLS握手時完成，減少一次往返時間。這里通過一個例子來說明下什么叫做應用層的協議協商。假設TLS握手完成了，接下來客戶端和服務端就應該開始進行正常的HTTP通信了，但是客戶端認為HTTP協議比較慢(還記得上篇提到的流式傳輸的效率問題嗎)，在請求內容之前先向服務端提出『我們能不能換HTTP2.0通信』。服務端會根據自己支持HTTP2.0的情況給出答復，之后客戶端會根據服務端的答復，使用HTTP或HTTP2.0向服務端請求內容。可以看到這個過程中又多了一次協商升級協議的往返，導致客戶端拿到返回結果的延遲更大了。為了優化這一點，在HTTP使用TLS加密的時候，會使用ALPN擴展，把協商升級協議的請求放在Client1中，服務端在Server1就返回說是否可以升級協議。這樣TLS握手之后，客戶端就可以直接按HTTP2.0發起請求而不必多一次往返了。
SNI(Server Name Indication)叫做服務器名稱指示，主要是支持服務端同一個機器部署有多個站點的情況的。前面說的證書、公鑰私鑰，都是針對某個站點來說的。網站A和網站B可能租了同一臺服務器，但他們的證書和密鑰一定是不同的。當客戶端請求到這臺公用服務器時，服務器也不知道該返回哪個站點的信息了。這個時候使用SNI擴展，在client1帶上訪問站點的信息，服務端看到后，就會去找對應站點的證書、密鑰了。
TLS的代價
任何事物都是有利有弊，引入TLS機制固然是能夠保證安全，但卻在TCP握手和HTTP通信之間，多加了兩個往返的TLS握手過程。特別是現代網頁應用中充滿了AJAX請求的場景下，請求的往往都是一個很小的資源，在一波TCP包中就能返回的。這種情況下握手需要三次往返，而真正有意義的請求往返只有一次，安全的代價非常大!(關于延遲對于性能的重要性，怎么強調都不為過，但往往會被人所忽視。這里不展開，但可以仔細思考下TCP的擁塞避免策略：在大延遲的情況下TCP包需要等上一波TCP包的往返后才會繼續發送。這就是為什么很多人都是50兆100兆的寬帶還經常覺得上網慢的原因，因為延遲大!而運營商是從來不會宣傳或保證延遲這個指標的)
當然，還是有優化的辦法的。上篇說過，現代web應用經常是打開一個網頁同時會發送幾十個請求。TLS握手這個協商加密套件和密鑰的過程，需要重復幾十次嗎?當然不用。既然這幾十個請求都是請求的同一個網站，那共用第一次請求的協商結果就好了。這樣雖然第一次請求中TLS握手的代價很大(比如占了50%)，但從整個網頁全局看來，代價就降低到了百分之幾了。目前一些主流瀏覽器的實現也確實利用了這個機制：他們會刻意先發起一個請求，待該請求的TLS鏈接完成后，再并發發起其他的請求。后續并發的請求就能夠利用TLS協商后的結果了。
這種對協商結果的復用叫做TLS的『會話恢復機制』，主要有兩種方案：Session Identifier 和 Session Ticket。
Session Identifier即會話標識符，是一種服務端保存會話信息的方案。
- 服務端為每個客戶端保存會話ID和協商后的會話參數
- 會話ID通過Server1帶給客戶端
- 客戶端在后續創建連接的Client1中帶上會話ID
- 如果兩方都還記得會話ID，則可開啟『簡短握手』，一次往返即可
- 如該會話ID的信息在服務端不存在，則繼續正常握手的第二個往返
方案整體思路其實和web應用的session類似，都是在服務端維護信息，客戶端提供一個sessionId。因此該方案面臨和session一樣的挑戰：服務端需要管理海量會話信息并且制定適當的淘汰策略。
Session Ticket即會話記錄單，是一種客戶端保存會話信息的方案。
- 協商成功后會話信息由服務器通過其私鑰加密后攜帶在最后一次交換中
- 由客戶端保存這個加密后的會話信息，但其無法解密得知具體內容
- 下次連接時客戶端將其帶在Client1的SessionTicket擴展信息中
這個方案的整體思路就和cookie類似了，有效地減輕了服務端的壓力。但這屬于一種較新的機制，目前還不是所有客戶端都支持。
證書機制
上面這么大篇幅都是介紹的TLS如何完成『加密』這個事情，然而之前說到的HTTP另一個問題『無法驗證服務器的真實性』還是沒有得到解決。畢竟如果有個節點要偽裝成服務器，和用戶進行TLS的加解密交互，也是完全沒問題的吧。因此，TLS中還需要通過『證書機制』來保證你所訪問的服務器是真實的。從安全層面來說，『證書』和『加密』是同等重要的兩個機制。
做個假設，你和小A是朋友，你們之間什么事都可以暢所欲言。你們當面聊天時，你不介意把自己的隱私和小A分享。你的分享，其實是建立在『當面』的基礎上的，也就是你通過『辨識小A的外貌』來斷定他的真實性后，才會信任他與他分享。如果有一天小A通過一個陌生的電話聯系你，那你恐怕就不會這么毫無防備了。為了驗證電話那頭真的是小A，你們之間可能需要一些驗證機制，比如讓小A說說你們小時候發生的某個事或者在你們兩個面對面的時候確定個暗號。這個事件或者暗號，其實就是你用來認證小A的『證書』了。 這樣你和小A之間的認證就OK了。可有一天，一個自稱小A朋友的小B找到你，想叫你幫個忙，可以你之前從來沒聽說過小B。這個時候為了驗證小B是否是可信的，你只能找來小A幫忙了。你聯系小A使用你們之間的『證書』驗證其真實性后，由小A使用他和小B約定的『證書』來驗證小B的真實性。驗證成功后，你也就能信任小B了吧，畢竟你的朋友小A已經信任電話那頭的小B了。
這個找小A驗證小B的過程，正是TLS中核心的『證書鏈』機制。
前面說到，在TLS握手過程中服務端會提供給客戶端它的證書。這個證書可不是隨意生成的，而是通過指定的權威機構申請頒發的。服務端如果能夠提供一個合法的證書，說明這個服務端是合法的，可以被信任。就拿上圖來說
- 客戶端獲取到了站點證書，拿到了站點的公鑰
- 要驗證站點可信后，才能使用其公鑰，因此客戶端找到其站點證書頒發者的信息
- 站點證書的頒發者驗證了服務端站點是可信的，但客戶端依然不清楚該頒發者是否可信
- 再往上回溯，找到了認證了中間證書商的源頭證書頒發者。由于源頭的證書頒發者非常少，我們瀏覽器之前就認識了，因此可以認為根證書頒發者是可信的
- 一路倒推，證書頒發者可信，那么它所頒發的所有站點也是可信的，最終確定我們所要訪問的服務端是可信的
- 客戶端使用證書中包含的公鑰，繼續完成TLS的握手過程
整個過程包含兩個關鍵點
- 根證書頒發機構的權威性需要保證
- 如何從證書頒發者那里驗證證書的合法性
先說說第一個問題，權威的根證書頒發機構非常少，因此瀏覽器和操作系統都會內置一些可信的根證書頒發機構，也就是說這些機構的權威性是由瀏覽器或操作系統保證的。但曾經也出現過一些并不權威的證書由于某些目的被內置在中國版的Firefox中這樣的事件，讓人直呼防不勝防。
好在當前大多數情況下跟證書還是能夠保證權威的，如果是CNNIC這種系統性風險，那也只有靠多關注安全新聞來及時避免了。通過系統或瀏覽器配置就能查看到自己內置可信的跟證書頒發機構了，這里是我mac的結果。如果發生了像上述CNNIC證書的問題，只要到證書列表這里刪除對應的可信證書即可。
再來說說第二個問題，如何從證書頒發者那里驗證某個證書的有效性。每個證書頒發機構在頒發證書的同時，有義務維護其認證站點的權威性：比如每個證書都有過期時間，一旦到期就要立即失效;某個站點需要更換證書服務商，換上新的證書時，老的也就立即要失效，否則老的證書可能會被挪用到不法站點上;由于站點自身問題導致私鑰泄密，那么TLS的加密就不能保證安全;證書頒發機構被冒名頂替等等。一旦發生以上任何一種情況，證書頒發者都要保證對應證書立即失效。證書頒發者一般提供兩種方式來驗證證書有效性：CRL和OCSP。
CRL(Certificate Revocation List)即證書撤銷名單。證書頒發者會提供一份已失效證書的名單，供瀏覽器驗證證書使用。當然這份名單是巨長無比的，瀏覽器不可能每次TLS都去下載，所以常用做法是瀏覽器會緩存這份名單，定期做后臺更新。這樣雖然后臺更新存在時間間隔，證書失效不實時，但一般也OK了。
OCSP(Online Certificate StatusProtocol)即在線證書狀態協議。除了離線文件，證書頒發者也會提供實時的查詢接口，查詢某個特定證書目前是否有效。實時查詢的問題在于瀏覽器需要等待這個查詢結束才能繼續TLS握手，延遲會很大。此外，通過『某個IP請求了某個證書的OCSP請求』這個信息，其實就暴露了某個用戶正在訪問某個網站了，也算是一種隱私的泄露。
以上是站在證書頒發者的角度說明會提供兩種判斷方式，實際情況下瀏覽器究竟會選擇哪種方式判斷，每個瀏覽器都有自己的實現。下圖是通過chrome查看某個網站的證書信息，可以看到其中的證書鏈和證書驗證信息。
中間人攻擊
介紹完證書如何保證站點的可信以后，我們來看看如果證書不合法會怎么樣。導致不合法證書還能被使用有兩種情況，一種是前文提到的CNNIC證書等類似的系統性風險，另一種是用戶缺乏安全意識，手動信任了存在安全隱患的證書。
對于前者，我們要多關注安全新聞定期排雷，對于后者我們要提高安全意識，以后看到這些畫面時可要慎之又慎了，而不是一味地點同意。
一旦非法的證書被瀏覽器視為合法，那么就面臨著一種『中間人攻擊』的風險：惡意節點會通過持有的非法證書和客戶端交互，之后代替客戶端，向真實服務器發起請求，并把服務器的請求返回給客戶端。這樣客戶端好像感覺自己直接連接了服務器，但實際上有個隱藏的中間人，神不知鬼不覺地竊取了中間的信息。
至此，已經將TLS技術如何應對『明文』和『無法驗證服務器的真實性』兩個主要安全問題講完了，由于本人并不從事網工相關職業，因此就沒有深究到協議消息幀細節，只是從原理層面進行了理解。如果關于TLS還有什么沒有提到，或者理解不正確的，歡迎各位提出來~
