閒話HTTPS

前言

大家在瀏覽網頁的時候一定有這樣的體驗，有一些網站在網址那裏會顯示一個綠色的掛鎖，並且網址中“https”相關的字樣也是綠色的，聰明的朋友肯定會問，這些顏色和符號代表什麼意思呢？想想大家在上網的時候，經常要輸入賬號和密碼，有時候網購還要輸入信用卡信息，如果這些信息被偷了，後果是很嚴重的。是的，這個綠色的鎖就是用來保護大家的信息不被黑客竊取。

現在很多網站默認使用HTTPS來保護用戶的信息，截止2018年4月，Alexa前100萬的網站中，32.2%使用HTTPS作爲默認設置，互聯網最受歡迎的137971個網站中，57.1%使用了HTTPS；Firefox遙測數據顯示，70%的網站使用了HTTPS。

HTTPS是什麼

HTTPS安全（HTTPS）是超文本傳輸協議（HTTP）的擴展，它能夠使計算機網絡進行安全通信，現已廣泛用於Internet。

HTTPS使用傳輸層安全協議（TLS）或其前身安全套接層（SSL）對通信進行加密。所以HTTPS有時也被稱爲HTTP over TLS或者HTTP over SSL。服務端和客戶端仍然使用HTTP協議進行通信，在通信過程中通過安全的連接來加密和解密他們的請求和響應。HTTPS主要做了兩件事：

1. 對訪問的網站進行身份驗證
2. 傳輸過程中保護交換數據的隱私和完整性

客戶端和服務端之間使用了雙向加密，可以防止竊聽和篡改數據。這樣在一定程度上保證了用戶瀏覽網頁時不會被冒名頂替者欺騙。

最開始的時候，HTTPS主要用於保護萬維網上的支付行爲，電子郵件和公司信息系統中的敏感交易。後面隨着大家安全意識的增強，網站普遍開啓了HTTPS，用於保護網頁的真實性，賬戶安全，並保持用戶通信，身份和網頁瀏覽的私密性。

安全連接

客戶端和服務端的SSL/TLS連接通過握手建立，建立安全連接的目的在於：

1. 保護通信的隱私和完整。通過加密通信，確保沒有任何第三方能夠讀取或篡改客戶端與服務器交換的數據。
2. 身份鑑定。通過使用非對稱加密技術，SSL/TLS能讓通信雙方識別對方的身份。也就是說，雙方都知道他們正在與誰通信。在網絡交易中，這尤其重要，因爲我們需要確保資金轉給了能確認身份的人
3. 完全正向保密（PFS）。簡單的說，PFS的主要工作是確保在服務器私鑰遭到入侵的情況下，攻擊者無法解密任何先前的TLS通信。通過使用Diffie-Hellman臨時密鑰交換可以實現PFS，該交換爲每個會話提供新的密鑰，密鑰只在會話的生命週期中生效。

握手流程

握手的流程如下：

大致可以分爲三個階段

1. Hello階段。握手從客戶端發送ClientHello消息開始。

   • Client Hello，發送下面的內容：

     • client_version：客戶端支持的SSL/TLS版本
     • random：一個32字節的隨機數，其中4個字節是客戶端當前時間戳。
     • session_id：連接會話ID，如果不爲空，服務器將搜索緩存的會話，並在找到匹配的情況下恢復會話。
     • compression_methods：壓縮數據包的方式。使用壓縮可以提高傳輸速度。
     • cipher_suites：使用的加密算法的組合，用來衡量連接的總體安全性。
     下面是用wireshark抓包的一個例子：

   • Server Hello，發送下面的內容：

     • server_version：服務端從客戶端支持的SSL/TLS版本中選出一個
     • random：一個32字節的隨機數，其中4個字節是服務端當前時間戳。
     • session_id：會話id。如果不爲空，服務端會搜索緩存中的會話，如果找到則恢復會話。如果爲空，一個新的會話將會被創建。
     • compression_methods：如果支持，服務器將統一使用客戶端的首選壓縮方法。
     • cipher_suites：如果支持，服務器將同意客戶的首選密碼套件。

     下面是Server Hello的一個例子：

     
     

2. 交換證書階段

   • Certificate：服務端發送簽名證書和公鑰，向客戶端證明自己。
   • Client Certificate（可選）：服務端有時候也可能要求客戶端證明自己。此時客戶端將自己的簽名證書提供給服務端

   下面是Certificate的一個例子：

   
   

3. 密鑰交換階段：

   • Server Key Exchange：僅當服務端提供的證書不足以允許客戶端交換預主密鑰時，服務端纔會發送交換密鑰信息
   • Server Hello Done：服務端確認Hello消息完成。

   下面是用Server Key Exchange和Server Hello Done的例子

   
   
   
   • Client Key Exchange。在接收到服務端Hello Done後，客戶端發送Client Key Exchange給服務端。如果服務端請求客戶端證書，客戶端要在發送證書後在發送Key Exchange。在這個階段中，客戶端將創建一個預主密鑰。
     • Pre-Master Secret：預主密鑰由客戶端創建，創建後與服務端共享。在共享前，客戶端使用服務端公鑰對其進行加密。這樣只有服務端可以解密該消息。
     • Master Secret：服務端收到預主密鑰後，將使用其私鑰對其進行解密。現在。客戶端和服務端都更具之前交換的隨機值計算主密鑰。計算的僞代碼如下，其中PRF是用來生成僞隨機數據的函數master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
   • Change Cipher-Spec：此時，客戶端和服務端都可以切換到安全的機密環境。 Change Cipher Spec協議用於通知彼此可以使用新的加密方法了。

   下面是一個抓包例子

   
   

握手過程的最後一條消息和安全連接中的第一條加密消息是Finished，下下面是一個例子。

證書

信任

從形式上看，SSL/TLS證書只是一個文本文件而已，任何用於文本編輯器的人都可以創建一個證書。利用一些現有的工具可以輕易創建一個證書來聲明自己是谷歌，並且控制着域名gmail.com。如果真的能這樣的話，SSL/TLS將成爲一個笑話。身份驗證流程是：

1. 客戶端問“你是Google嗎？”
2. 服務器回答“呃，這還用問嗎，你看，這裏有張紙，上面寫着‘我是Google’”
3. 客戶說“好的，這是我的數據。”

防止這種鬧劇的辦法在於數字簽名，它允許一方驗證另一方的紙張是否合法。

有兩個情況讓用戶可以信任一個證書：

• 這個證書在用戶信任的證書列表中
• 這個證書能夠證明自己被控制上述列表的證書控制器所信任。

第一種情況很簡單。瀏覽器都會預先安裝來自證書頒發機構（CA）的可信SSL證書列表。用戶可以查看，添加，刪除這些證書。在實際情況中，這些證書會由賽門鐵克，Comodo和GoDaddy等非常安全，可靠指的信賴的組織來頒發。

符合第二種情況更難一些。服務器很容易說：“呃，我的名字是，呃微軟，你信任賽門鐵克，呃他們完全信任我，所以你懂得。”有點聰明的客戶可能去問賽門鐵克：“我這裏有一個叫微軟的說你相信他們，這是真的嗎？”不過，即使賽門鐵克說“是的，我們知道微軟，他是可信的”，你仍然不知道這個號稱是微軟的服務器真的是微軟呢，還是其他更糟糕的東西。這就是我們需要數字簽名的原因。

數字簽名

之前提到過，SSL/TLS證書有用到公鑰/私鑰對。公鑰作爲證書的一部分被公開，而私鑰需要很好的保護。這對非對稱密鑰在SSL握手中用於交換雙方的另一個密鑰來對數據進行加密和解密，即客戶端使用服務器的公鑰來加密對稱密鑰並將其安全地發送到服務器，然後服務器使用其私鑰對其進行解密。任何人都可以使用公鑰進行加密，但只有服務器可以使用私鑰進行解密。

而數字簽名的使用正好相反。證書由一個權威機構“簽署”，權威機構在證書上記錄“我們已經證實此證書的控制者擁有對證書上列出的域名具有控制權”，記錄的方式是，授權機構使用他們的私鑰對證書的內容進行加密，並將該密文附加到證書上作其數字簽名。任何人都可以使用授權機構的公鑰解密這個簽名進行驗證。因爲只有授權機構才能使用私鑰加密內容，所以只有授權機構能夠真正創建一個有效的簽名。

因此，如果服務器聲稱擁有由賽門鐵克簽署的Microsoft.com的證書，瀏覽不必相信它。如果用賽門鐵克的公鑰能夠證明證書上的簽名是有效的話，那麼這個證書就是合法的。賽門鐵克會採取措施確保他們簽署的組織確實擁有Microsoft.com域名，如果客戶端信任賽門鐵克，那麼也可以信任服務屬於Microsoft公司。

自簽名

值得注意的是，所有根CA證書都是“自簽名的”，也就是說數字證書是使用CA自己的私鑰生成的。和其他證書相比，CA證書沒有什麼特殊的地方。你完全可以生成自己的自簽名證書，並根據需要使用此證書來簽署其他證書。只不過你的證書並沒有作爲CA預先加載到其他人的瀏覽器裏，其他人都不會相信你你簽署證書或者其他證書。如果你膽敢宣稱“我是微軟，這是我自己簽發和簽署的官方證書”，所有的瀏覽器都會因爲這個錯誤的憑證拋出一個非常可怕的錯誤信息。

。

這些安全措施要由瀏覽器和操作系統發行商來處理，他們只信任乾淨的根CA，那些組織是他們的用戶最終信任審查網站並保證證書安全的組織。

防範攻擊

技術上，用戶並不需要驗證是否應該信任發送證書的一方，而是應該信任證書中包含的公鑰。SSL證書是完全公開和公開的，因此任何攻擊者都可以獲取Microsoft的證書，攔截客戶對Microsoft.com的請求並向其提供合法證書。客戶會接受證書並地開始握手。但是，當客戶端加密將用於實際數據加密的密鑰時，它將使用真實證書中獲得的Microsoft的公鑰進行加密。由於攻擊者沒有微軟的私鑰來解密，通信無法進行進行。即使握手完成，他們仍然無法解密密鑰，因此無法解密客戶端發送給他們的任何數據。只要攻擊者不控制可信證書的私鑰，數據就無法被解密。如果攻擊者用某種方式讓客戶相信了假冒的證書和公鑰，還是會產生問題。

一些有意思的事情

咖啡店可以通過他們的網絡監控HTTPS流量嗎？

並不能。公鑰密碼術的神奇在於攻擊者可以嗅探客戶端和服務器之間交換的每一個字節的數據，但是並不能獲取這些數據裏的信息。在不安全的WI-FI網絡上瀏覽HTTP的網站是非常危險的。舉個例子，用戶使用HTTPS提交用戶名/密碼組合的表單，但假如這個表單是通過HTTP加載的，攻擊者可能會在表單HTML中插入惡意代碼，將賬號/密碼發送到他們自己的服務器上。

公司可以通過他們的網絡監視HTTPS流量嗎？

如果公司控制着你用的電腦，那麼是的。每一個信任鏈的根源在於隱含信任的CA，並且這些權限的列表存儲在瀏覽器中。公司可以將自己的自簽名證書添加到電腦的CA列表中。因爲瀏覽器信任其僞造的簽名，因此公司可以提供聲稱代表相應網站的證書，來攔截你所有的HTTPS請求。由於客戶端將使用其惡意證書的公鑰對所有HTTPS請求進行加密，因此他們可以使用相應的私鑰解密並檢查（甚至修改）請求，然後將其發送到其預期的位置。

公司是由這個能力的，取決於他們想不想這樣幹。

結語

HTTPS不是不可破解的，並且SSL/TLS協議必須隨着新攻擊被發現和壓制而不斷髮展。不過在很多情況下，它能夠保證足夠的安全性。關鍵點在於，雖然HTTPS可以保證數據安全地到達目的地，但是它並不能保護用戶免受XSS攻擊，重放攻擊，數據庫泄漏的威脅。它正如電影中《黑衣人》的主題曲：“Walk in shadow, move in silence, guard against extra-terrestrial violence（行於陰影，行於沉默，打擊暴力和恐怖
）”