說起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握手
這個圖描述了發送端和接收端是怎麼協商他們之間的加密機制的。TLS協議是基于TCP協議之上的，圖中第一個藍色往返是TCP的握手過程，之後的兩次橙色的往返，就是我們要重點說的協商過程了，可以叫做TLS的握手。握手過程如下：
我們一步一步來仔細看。
第一步，客戶說明他支持的所有加密套件（就像上海話、廣東話一樣）讓服務端選擇一個。這裡和Server1還完成了一個TLS選項的協商，這可以理解為在确定核心的加密方式的同時，順便溝通下是否能支持一些『附加功能』。這些附加功能先按下不表，後續會介紹兩個常用的。
第二步，服務端選擇了加密套件。加密算法都是需要一個秘鑰的，服務端這裡給出的是自己的公鑰。這裡的公鑰其實蘊含着一個關鍵點：秘鑰協商過程采用了不對稱加密。簡單來說，一般的對稱加密如下
encrypt(明文，秘鑰) = 密文
decrypt(密文，秘鑰) = 明文
也就是說加密和解密用的是一個秘鑰。而非對稱加密就比較神奇了
encrypt(明文，公鑰) = 密文
decrypt(密文，私鑰) = 明文
加密和解密是需要不同的密鑰的。在TLS握手前，客戶端本身不知道服務器的秘鑰的，如果運用對稱加密，那麼服務端告訴客戶端秘鑰的過程中，兩者之間的中間節點其實也拿到秘鑰了，這樣後續兩者之間的加密通信，對于中間節點來說也能解密出内容了。因此這裡采用不對稱加密，服務端給出一個公鑰供客戶端後續使用。此外這一步服務端還提供了證書，并且可能要求客戶端提供證書。關于證書下文會提到，隻要有了證書，就能保證和你通信的對方是真實的，而不是别人僞造的。這裡隻要先理解，客戶端看到服務端證書後，就能夠相信服務端并使用服務端給的公鑰了。
第三步，客戶端給出了雙方後續加密通信所要使用的對稱密鑰，通過服務器公鑰加密後返回給服務端。由于對稱密鑰是被不對稱加密算法加密起來的，因此中間節點拿到後，沒有辦法解密出真正的内容。
第四步，服務端拿公鑰對應的私鑰解密出真正的對稱密鑰，至此加密算法和加密所需的密鑰都确定，服務端給客戶端發送一個finish完成握手，證明雙方都已經準備好加密通信了。之後雙方的交互都可以使用對稱加密算法加密了。
說完了如何确定加密的算法和密鑰後，我們再說說那所謂的『附加功能』。所謂TLS的擴展，就是在TLS協議核心保持不變的基礎上，對其進行擴展以使其支持更多的特性，這裡簡單介紹下兩個擴展：ALPN和SNI。
TLS擴展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即會話标識符，是一種服務端保存會話信息的方案。
方案整體思路其實和Web應用的session類似，都是在服務端維護信息，客戶端提供一個sessionId。因此該方案面臨和session一樣的挑戰：服務端需要管理海量會話信息并且制定适當的淘汰策略。
Session Ticket即會話記錄單，是一種客戶端保存會話信息的方案。
這個方案的整體思路就和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握手過程中服務端會提供給客戶端它的證書。這個證書可不是随意生成的，而是通過指定的權威機構申請頒發的。服務端如果能夠提供一個合法的證書，說明這個服務端是合法的，可以被信任。就拿上圖來說
整個過程包含兩個關鍵點
先說說第一個問題，權威的根證書頒發機構非常少，因此浏覽器和操作系統都會内置一些可信的根證書頒發機構，也就是說這些機構的權威性是由浏覽器或操作系統保證的。但曾經也出現過一些并不權威的證書由于某些目的被内置在中國版的Firefox中這樣的事件，讓人直呼防不勝防。
CNNIC
好在當前大多數情況下根證書還是能夠保證權威的，如果是CNNIC這種系統性風險，那也隻有靠多關注安全新聞來及時避免了。通過系統或浏覽器配置就能查看到自己内置可信的根證書頒發機構了，這裡是我mac的結果。如果發生了像上述CNNIC證書的問題，隻要到證書列表這裡删除對應的可信證書即可。
mac自帶根證書
再來說說第二個問題，如何從證書頒發者那裡驗證某個證書的有效性。每個證書頒發機構在頒發證書的同時，有義務維護其認證站點的權威性：比如每個證書都有過期時間，一旦到期就要立即失效；某個站點需要更換證書服務商，換上新的證書時，舊的也就立即要失效，否則舊的證書可能會被挪用到不法站點上；由于站點自身問題導緻私鑰洩密，那麼TLS的加密就不能保證安全；證書頒發機構被冒名頂替等等。一旦發生以上任何一種情況，證書頒發者都要保證對應證書立即失效。證書頒發者一般提供兩種方式來驗證證書有效性：CRL和OCSP。
CRL（Certificate Revocation List）即證書撤銷名單。證書頒發者會提供一份已失效證書的名單，供浏覽器驗證證書使用。當然這份名單是巨長無比的，浏覽器不可能每次TLS都去下載，所以常用做法是浏覽器會緩存這份名單，定期做後台更新。這樣雖然後台更新存在時間間隔，證書失效不實時，但一般也OK了。
OCSP（Online Certificate StatusProtocol）即在線證書狀态協議。除了離線文件，證書頒發者也會提供實時的查詢接口，查詢某個特定證書目前是否有效。實時查詢的問題在于浏覽器需要等待這個查詢結束才能繼續TLS握手，延遲會很大。此外，通過『某個IP請求了某個證書的OCSP請求』這個信息，其實就暴露了某個用戶正在訪問某個網站了，也算是一種隐私的洩露。
以上是站在證書頒發者的角度說明會提供兩種判斷方式，實際情況下浏覽器究竟會選擇哪種方式判斷，每個浏覽器都有自己的實現。下圖是通過chrome查看某個網站的證書信息，可以看到其中的證書鍊和證書驗證信息。
證書例子
中間人攻擊介紹完證書如何保證站點的可信以後，我們來看看如果證書不合法會怎麼樣？導緻不合法證書還能被使用有兩種情況：一種是前文提到的CNNIC證書等類似的系統性風險，另一種是用戶缺乏安全意識，手動信任了存在安全隐患的證書。
惡意節點被信任
對于前者，我們要多關注安全新聞定期排雷，對于後者我們要提高安全意識，以後看到這些畫面時可要慎之又慎了，而不是一味地點同意。
IE
chrome
firefox
一旦非法的證書被浏覽器視為合法，那麼就面臨着一種『中間人攻擊』的風險：惡意節點會通過持有的非法證書和客戶端交互，之後代替客戶端，向真實服務器發起請求，并把服務器的請求返回給客戶端。這樣客戶端好像感覺自己直接連接了服務器，但實際上有個隐藏的中間人，神不知鬼不覺地竊取了中間的信息。
中間人攻擊
至此，已經将TLS技術如何應對『明文』和『無法驗證服務器的真實性』兩個主要安全問題講完了，從原理層面進行了理解。如果關于TLS有什麼疑問的，可在"IT人才圈"微信公衆号發送"TLS"進群讨論交流~
,更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
