2021-05-12 14:32:11
HTTPS 背後的加密演算法
當你在瀏覽器的位址列上輸入https開頭的網址後,瀏覽器和伺服器之間會在接下來的幾百毫秒內進行大量的通訊。InfoQ的這篇文章對此有非常詳細的描述。這些複雜的步驟的第一步,就是瀏覽器與伺服器之間協商一個在後續通訊中使用的金鑰演算法。這個過程簡單來說是這樣的:
- 瀏覽器把自身支援的一系列Cipher Suite(金鑰演算法套件,後文簡稱Cipher)[C1,C2,C3, …]發給伺服器;
- 伺服器接收到瀏覽器的所有Cipher後,與自己支援的套件作對比,如果找到雙方都支援的Cipher,則告知瀏覽器;
- 瀏覽器與伺服器使用匹配的Cipher進行後續通訊。如果伺服器沒有找到匹配的演算法,瀏覽器(以Firefox 30為例,後續例子中使用的瀏覽器均為此版本的Firefox)將給出錯誤資訊:
Secure連線失敗錯誤
本文將講述如何探究這一過程。
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,會看到下面的選項:
AboutConfig
其中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”的錯誤資訊,如圖2所示。
了解了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個:
clienthello
如果繼續找一個Info為“ServerHello”的報文,可以在類似的位置找到伺服器返回的Cipher,在本例中是TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:
serverhello
關於金鑰演算法這一長串名字的含義,後面說明。接下來,瀏覽器就要等待伺服器響應它的請求。我們來看一看伺服器端都做了些什麼。
2. 伺服器
讓我們以Windows為例。若要檢視作業系統支援哪些金鑰演算法,可以執行gpedit.msc,依次進入”Computer Configuration” -> ”Administrative Templates” -> “Network” -> “SSL Configuration Settings”,這時可以在視窗右邊看到”SSL Cipher Suite Order”項:
gpedit
點選該項後進入”SSL Cipher Suite Order”。這裡可以看到作業系統支援的Cipher的集合,以及對不同Cipher的排序
cipher-suite-order
如果需要調整這裡排序,或者去掉一些弱的Cipher,可以點選左上角的“Enabled”,然後在“Options”中重寫編輯Cipher的列表。如果喜歡命令列,可以通過下面的Powershell命令修改金鑰演算法套件:
Set-ItemProperty-path HKLM:SOFTWAREPoliciesMicrosoftCryptographyConfigurationSSL 001002-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的加密演算法。這又是一次理論與實踐的交鋒。至於這次對於的線上系統所做的調整會不會對效能產生影響,幾個月後就能見分曉了。
Https(SSL/TLS)原理詳解 http://www.linuxidc.com/Linux/2015-07/120229.htm
理解 HTTPS 協定 http://www.linuxidc.com/Linux/2015-06/118484.htm
利用httpd+OpenSSL來實現網站的https http://www.linuxidc.com/Linux/2014-03/98954.htm
簡單設定HTTPS 認證存取 http://www.linuxidc.com/Linux/2014-03/98767.htm
Nginx設定SSL證書部署HTTPS網站 http://www.linuxidc.com/Linux/2013-08/88271.htm
本文永久更新連結地址:http://www.linuxidc.com/Linux/2015-08/121812.htm
相關文章