當你在瀏覽器的地址欄上輸入https開頭的網址后，瀏覽器和服務器之間會在接下來的幾百毫秒內進行大量的通信。InfoQ的這篇文章對此有非常詳細的描述。這些復雜的步驟的第一步，就是瀏覽器與服務器之間協商一個在后續通信中使用的密鑰算法。這個過程簡單來說是這樣的：

瀏覽器把自身支持的一系列Cipher Suite(密鑰算法套件，后文簡稱Cipher)[C1,C2,C3, …]發給服務器；

服務器接收到瀏覽器的所有Cipher后，與自己支持的套件作對比，如果找到雙方都支持的Cipher，則告知瀏覽器；

瀏覽器與服務器使用匹配的Cipher進行后續通信。如果服務器沒有找到匹配的算法，瀏覽器(以Firefox 30為例，后續例子中使用的瀏覽器均為此版本的Firefox)將給出錯誤信息:

本文將講述如何探究這一過程。

1. 瀏覽器

瀏覽器支持哪些Cipher？這取決于瀏覽器支持的SSL/TLS協議的版本。習慣上，我們通常把HTTPS與SSL協議放到一起；事實上，SSL協議是Netcape公司于上世紀90年代中期提出的協議，自身發展到3.0版本。1999年該協議由ITEL接管，進行了標準化，改名為TLS。可以說，TLS 1.0就是SSL 3.1版本。在Wikipedia上并沒有SSL獨立的條目，而是會重定向到TLS，可見兩種協議關系之緊密。

目前TLS最新版本是1.2。互聯網上有超過99%的網站支持TLS 1.0，而支持TLS 1.2的網站尚不足40%。打開Firefox瀏覽器，在地址欄中輸入about:config，然后搜索tls.version，會看到下面的選項:

其中security.tls.version.min和security.tls.version.max兩項決定了Firefox支持的SSL/TLS版本，根據Firefox文檔的介紹，這兩項的可選值及其代表的協議是：

0 – SSL 3.0

1 – TLS 1.0

2 – TLS 1.1

3 – TLS 1.2

因此上圖的設置說明當前瀏覽器支持協議的下限是SSL 3.0，上限是TLS 1.2。現在，如果把security.tls.version.min一項改為3，那么瀏覽器就只支持TLS 1.2了。前文提到，目前只有不足40%的網站支持TLS 1.2，比如Amazon就不在這40%之列，所以此時訪問https://amazon.com，就會收到“Secure Connection Failed”的錯誤信息，如圖1所示。

了解了SSL/TLS協議后，可以使用Wireshark(或類似的可以抓去網絡包的工具)通過分析網絡包的信息，來查看瀏覽器發送給服務器的所有Cipher。Wireshark是一款使用簡單卻非常強大的抓包工具。

瀏覽器會首先發起握手協議，既一個“ClientHello”消息，在消息體中，可以找到Firefox支持的Cipher。在Wireshark中，按照Protocol協議排序，然后從TLS 1.2協議的報文中找到一個Info為“Client Hello”的。選中這個，然后在下面的報文信息窗口中依次找到Secure Sockets Layer -> TLSv1.2 Record Layer -> Handshake Protocal -> Cipher Suites。例子中的第一個Cipher是TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256，一共有23個:

如果繼續找一個Info為“ServerHello”的報文，可以在類似的位置找到服務器返回的Cipher，在本例中是TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:

關于密鑰算法這一長串名字的含義，后面說明。接下來，瀏覽器就要等待服務器響應它的請求。我們來看一看服務器端都做了些什么。

2. 服務器

讓我們以Windows為例。若要查看操作系統支持哪些密鑰算法，可以運行gpedit.msc，依次進入”Computer Configuration” -> ”Administrative Templates” -> “Network” -> “SSL Configuration Settings”，這時可以在窗口右邊看到”SSL Cipher Suite Order”項：

點擊該項后進入”SSL Cipher Suite Order”。這里可以看到操作系統支持的Cipher的集合，以及對不同Cipher的排序

如果需要調整這里排序，或者去掉一些弱的Cipher，可以點擊左上角的“Enabled”，然后在“Options”中重寫編輯Cipher的列表。如果喜歡命令行，可以通過下面的Powershell命令修改密鑰算法套件：

Set-ItemProperty -path HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\0001002 -name Functions -value "XXX,XXX,XXX"

那么Cipher的這一長串名字是什么含義呢？其實，每種Cipher的名字里包含了四部分信息，分別是

密鑰交換算法，用于決定客戶端與服務器之間在握手的過程中如何認證，用到的算法包括RSA，Diffie-Hellman，ECDH，PSK等

加密算法，用于加密消息流，該名稱后通常會帶有兩個數字，分別表示密鑰的長度和初始向量的長度，比如DES 56/56, RC2 56/128, RC4 128/128, AES 128/128, AES 256/256

報文認證信息碼(MAC)算法，用于創建報文摘要，確保消息的完整性(沒有被篡改)，算法包括MD5，SHA等。

PRF(偽隨機數函數)，用于生成“master secret”。

完全搞懂上面的內容似乎還需要一本書的介紹(我已經力不從心了)。不過大致了解一下，有助于理解Cipher的名字，比如前面服務器發回給客戶端的Cipher，

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

從其名字可知，它是

基于TLS協議的；

使用ECDHE、RSA作為密鑰交換算法；

加密算法是AES(密鑰和初始向量的長度都是256)；

MAC算法(這里就是哈希算法)是SHA。

熟悉了Cipher名字背后的含義后，讓我們看看像IIS這樣的Web服務器如何選擇一個密鑰算法呢？假如瀏覽器發來的密鑰算法套件為[C1, C2, C3]，而Windows Server支持的套件為[C4, C2, C1, C3]時，C1和C2都是同時被雙方支持的算法，IIS是優先返回C1，還是C2呢？答案是C2。IIS會遍歷服務器的密鑰算法套件，取出第一個C4，發現瀏覽器并不支持；接下來取第二個C2，這個被瀏覽器支持！于是，IIS選擇了C2算法，并將它包含在一個“ServerHello”握手協議中，發回給客戶端。這就有了圖5中的結果。

3. 選擇

作為瀏覽器的使用者，你可以讓瀏覽器只能訪問支持TLS 1.2協議的站點，以獲得更好的安全性，以及更差的體驗。作為服務器的維護者，似乎將最強壯的Cipher排在前面是正確的選擇。就在前不久，我們開發的一個Web報稅系統在一次由第三方進行的安全檢查中，被報出的問題之一就是服務器默認的Cipher太弱(RC4-based)，于是我們使用了AES-based的Cipher，但是密鑰長度只是選擇了128，而不是256，背后的擔憂主要來自于性能——加密與解密是CPU密集型操作，我們擔心到報稅忙季時，過強的Cipher會帶來性能問題。

其實像Amazon和Google這些互聯網公司都在使用RC4-based的加密算法。這又是一次理論與實踐的交鋒。至于這次對于的線上系統所做的調整會不會對性能產生影響，幾個月后就能見分曉了。

http://kb.cnblogs.com/page/530044/

總結

以上是生活随笔為你收集整理的tsl加密算法_HTTPS背后的加密算法（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。