HTTPS為什麼安全 &分析 HTTPS 串連建立全過程

標籤：國內   文字   提高   隱私   com   行資料   https協議   為我   互動圖   

專題一：HTTPS為什麼安全

1、http為什麼不安全？

http協議屬於明文傳輸協議，互動過程以及資料轉送都沒有進行加密，通訊雙方也沒有進行任何認證，通訊過程非常容易遭遇劫持、監聽、篡改，嚴重情況下，會造成惡意的流量劫持等問題，甚至造成個人隱私泄露（比如銀行卡卡號和密碼泄露）等嚴重的安全問題。

可以把http通訊比喻成寄送信件一樣，A給B寄信，信件在寄送過程中，會經過很多的郵遞員之手，他們可以拆開信讀取裡面的內容（因為http是明文傳輸的）。A的信件裡面的任何內容（包括各類帳號和密碼）都會被輕易竊取。除此之外，郵遞員們還可以偽造或者修改信件的內容，導致B接收到的信件內容是假的。

比如常見的，在http通訊過程中，“中間人”將廣告連結嵌入到伺服器發給使用者的http報文裡，導致使用者介面出現很多不良連結； 或者是修改使用者的要求標頭URL，導致使用者的請求被劫持到另外一個網站，使用者的請求永遠到不了真正的伺服器。這些都會導致使用者得不到正確的服務，甚至是損失慘重。

2、https如何保證安全？

要解決http帶來的問題，就要引入加密以及身分識別驗證機制。

如果Server（以後簡稱伺服器）給Client（以後簡稱 用戶端）的訊息是密文的，只有伺服器和用戶端才能讀懂，就可以保證資料的保密性。同時，在交換資料之前，驗證一下對方的合法身份，就可以保證通訊雙方的安全。那麼，問題來了，伺服器把資料加密後，用戶端如何讀懂這些資料呢？這時伺服器必須要把加密的密鑰（對稱金鑰，後面會詳細說明）告訴用戶端，用戶端才能利用對稱金鑰解開密文的內容。但是，伺服器如果將這個對稱金鑰以明文的方式給用戶端，還是會被中間人截獲，中間人也會知道對稱金鑰，依然無法保證通訊的保密性。但是，如果伺服器以密文的方式將對稱金鑰發給用戶端，用戶端又如何解開這個密文，得到其中的對稱金鑰呢？

說到這裡，大家是不是有點兒糊塗了？一會兒密鑰，一會兒對稱金鑰，都有點兒被搞暈的節奏。在這裡，提前給大家普及一下，這裡的密鑰，指的是非對稱加解密的密鑰，是用於TLS握手階段的； 對稱金鑰，指的是對稱加解密的密鑰，是用於後續傳輸資料加解密的。下面將詳細說明。

這時，我們引入了非對稱加解密的概念。在非對稱加解密演算法裡，公開金鑰加密的資料，有且只有唯一的私密金鑰才能夠解密，所以伺服器只要把公開金鑰發給用戶端，用戶端就可以用這個公開金鑰來加密進行資料轉送的對稱金鑰。用戶端利用公開金鑰將對稱金鑰發給伺服器時，即使中間人截取了資訊，也無法解密，因為私密金鑰只部署在伺服器，其他任何人都沒有私密金鑰，因此，只有伺服器才能夠解密。伺服器拿到用戶端的資訊並用私密金鑰解密之後，就可以拿到加解密資料用的對稱金鑰，通過這個對稱金鑰來進行後續通訊的資料加解密。除此之外，非對稱式加密可以很好的管理對稱金鑰，保證每次資料加密的對稱金鑰都是不相同的，這樣子的話，即使用戶端病毒拉取到通訊緩衝資訊，也無法竊取正常通訊內容。

上述通訊過程，可以畫成以下互動圖：

但是這樣似乎還不夠，如果通訊過程中，在三向交握或者用戶端發起HTTP請求過程中，用戶端的請求被中間人劫持，那麼中間人就可以偽裝成“假冒用戶端”和伺服器通訊；中間人又可以偽裝成“假冒伺服器”和用戶端通訊。接下來，我們詳細闡述中間人擷取對稱金鑰的過程：

中間人在收到伺服器發送給用戶端的公開金鑰（這裡是“正確的公開金鑰”）後，並沒有發給用戶端，而是中間人將自己的公開金鑰（這裡中間人也會有一對公開金鑰和私密金鑰，這裡稱呼為“偽造公開金鑰”）發給用戶端。之後，用戶端把對稱金鑰用這個“偽造公開金鑰”加密後，發送過程中經過了中間人，中間人就可以用自己的私密金鑰解密資料並拿到對稱金鑰，此時中間人再把對稱金鑰用“正確的公開金鑰”加密發回給伺服器。此時，用戶端、中間人、伺服器都擁有了一樣的對稱金鑰，後續用戶端和伺服器的所有加密資料，中間人都可以通過對稱金鑰解密出來。

中間人擷取對稱金鑰的過程如下：

為瞭解決此問題，我們引入了數位憑證的概念。伺服器首先產生公私密金鑰，將公開金鑰提供給相關機構（CA），CA將公開金鑰放入數位憑證並將數位憑證頒布給伺服器，此時伺服器就不是簡單的把公開金鑰給用戶端，而是給用戶端一個數位憑證，數位憑證中加入了一些數位簽章的機制，保證了數位憑證一定是伺服器給用戶端的。中間人發送的偽造認證，不能夠獲得CA的認證，此時，用戶端和伺服器就知道通訊被劫持了。加入了CA數位簽章認證的SSL會話過程如下所示：

所以綜合以上三點：非對稱式加密演算法（公開金鑰和私密金鑰）交換對稱金鑰+數位憑證驗證身份（驗證公開金鑰是否是偽造的）+利用對稱金鑰加解密後續傳輸的資料=安全

3、https協議簡介

為什麼是簡單地介紹https協議呢？因為https涉及的東西實在太多了，尤其是其中的加解密演算法，十分複雜，作者本身對這些演算法也研究不完，只是懂其中的一些皮毛而已。這部分僅僅是簡單介紹一些關於https的最基本原理，為後面分析https的建立過程以及https最佳化等內容打下理論基礎。

3.1 對稱式加密演算法

對稱式加密是指：加密和解密使用相同密鑰的演算法。它要求發送方和接收方在安全通訊之前，商定一個對稱金鑰。對稱演算法的安全性完全依賴於密鑰，密鑰泄漏就意味著任何人都可以對他們發送或接收的訊息解密，所以密鑰的保密性對通訊至關重要。

3.1.1 對稱式加密又分為兩種模式：流加密和區塊編碼器

流加密是將訊息作為位元組流對待，並且使用數學函數分別作用在每一個位元組位上。使用流加密時，每加密一次，相同的明文位會轉換成不同的密文位。流加密使用了密鑰流產生器，它產生的位元組流與明文位元組流進行異或，從而產生密文。

區塊編碼器是將訊息劃分為若干個分組，這些分組隨後會通過數學函數進行處理，每次一個分組。假設使用64位的分組密碼，此時如果訊息長度為640位，就會被劃分成10個64位的分組（如果最後一個分組長度不到64，則用0補齊之後加到64位），每個分組都用一系列數學公式進行處理，最後得到10個加密文本分組。然後，將這條密文訊息發送給對端。對端必須擁有相同的分組密碼，以相反的順序對10個密文分組使用前面的演算法解密，最終得到明文訊息。比較常用的區塊編碼器演算法有DES、3DES、AES。其中DES是比較老的密碼編譯演算法，現在已經被證明不安全。而3DES是一個過渡的密碼編譯演算法，相當於在DES基礎上進行三重運算來提高安全性，但其本質上還是和DES演算法一致。而AES是DES演算法的替代演算法，是現在最安全的對稱式加密演算法之一。

3.1.2 對稱式加密演算法的優缺點：

優點：計算量小、加密速度快、加密效率高。

缺點：

（1）交易雙方都使用同樣密鑰，安全性得不到保證；

（2）每次使用對稱式加密演算法時，都需要使用其他人不知道的惟一密鑰，這會使得發收資訊雙方所擁有的鑰匙數量呈幾何級數增長，密鑰管理成為負擔。

3.2 非對稱式加密演算法

在非對稱金鑰交換演算法出現以前，對稱式加密的最主要缺陷就是不知道如何在通訊雙方之間傳輸對稱金鑰，而又不讓中間人竊取。非對稱金鑰交換演算法誕生之後，專門針對對稱金鑰傳輸做加解密，使得對稱金鑰的互動傳輸變得非常安全了。

非對稱金鑰交換演算法本身非常複雜，金鑰交換過程涉及到隨機數產生，模指數運算，空白補齊，加密，簽名等等一系列極其複雜的過程，作者本人也沒有研究完全透徹。常見的金鑰交換演算法有RSA，ECDHE，DH，DHE等演算法。涉及到比較複雜的數學問題。其中，最經典也是最常用的是RSA演算法。

RSA：誕生於1977年，經過了長時間的破解測試，演算法安全性很高，最重要的是，演算法實現非常簡單。缺點就是需要比較大的質數（目前常用的是2048位）來保證安全強度，極其消耗CPU運算資源。RSA是目前唯一一個既能用於金鑰交換又能用於認證簽名的演算法，RSA 是最經典，同時也是最常用的是非對稱加解密演算法。

3.2.1 非對稱式加密相比對稱式加密更加安全，但也存在兩個致命的缺點：

（1）CPU計算資源消耗非常大。一次完全TLS握手，金鑰交換時的非對稱解密計算量占整個握手過程的90%以上。而對稱式加密的計算量只相當於非對稱式加密的0.1%。如果後續的應用程式層資料轉送過程也使用非對稱加解密，那麼CPU效能開銷太龐大，伺服器是根本無法承受的。賽門特克給出的實驗資料顯示，加解密同等數量的檔案，非對稱演算法消耗的CPU資源是對稱演算法的1000倍以上。

（2）非對稱式加密演算法對加密內容的長度有限制，不能超過公開金鑰長度。比如現在常用的公開金鑰長度是2048位，意味著待加密內容不能超過256個位元組。

所以非對稱加解密（極端消耗CPU資源）目前只能用來作對稱金鑰交換或者CA簽名，不適合用來做應用程式層內容傳輸的加解密。

3.3 身份認證

https協議中身份認證的部分是由CA數位憑證完成的，認證由公開金鑰、認證主體、數位簽章等內容組成。在用戶端發起SSL請求後，服務端會將數位憑證發給用戶端，用戶端會對認證進行驗證（驗證這張認證是否是偽造的？也就是公開金鑰是否是偽造的），如果認證不是偽造的，用戶端就擷取用於對稱金鑰交換的非對稱金鑰（擷取公開金鑰）。

3.3.1 數位憑證有三個作用：

1、身份授權。確保瀏覽器訪問的網站是經過CA驗證的可信任的網站。

2、分發公開金鑰。每個數位憑證都包含了註冊者產生的公開金鑰（驗證確保是合法的，非偽造的公開金鑰）。在SSL握手時會通過certificate訊息傳輸給用戶端。

3、驗證認證合法性。用戶端接收到數位憑證後，會對認證合法性進行驗證。只有驗證通過後的認證，才能夠進行後續通訊過程。

3.3.2 申請一個受信任的CA數位憑證通常有如下流程：

（1）公司（實體）的伺服器產生公開金鑰和私密金鑰，以及CA數位憑證請求。

（2）RA（憑證註冊及審核機構）檢查實體的合法性（在註冊系統裡面是否註冊過的正規公司）。

（3）CA（認證簽發機構）簽發認證，發送給申請者實體。

（4）認證更新到repository（負責數位憑證及CRL內容儲存和分發），實體終端後續從repository更新認證，查詢認證狀態等。

3.4 數位憑證驗證

申請者拿到CA的認證並部署在網站伺服器端，那瀏覽器發起握手並接收到認證後，如何確認這個認證就是CA簽發的呢？怎樣避免第三方偽造這個認證？答案就是數位簽章（digital signature）。數位簽章是認證的防偽標籤，目前使用最廣泛的SHA-RSA（SHA用於雜湊演算法，RSA用於非對稱式加密演算法）。數位簽章的製作和驗證過程如下：

1、數位簽章的簽發。首先是使用雜湊函數對待簽名內容進行安全雜湊，產生訊息摘要，然後使用CA自己的私密金鑰對訊息摘要進行加密。

2、數位簽章的校正。使用CA的公開金鑰解密簽名，然後使用相同的簽名函數對簽署憑證內容進行簽名，並和服務端數位簽章裡的簽名內容進行比較，如果相同就認為校正成功。

需要注意的是：

（1）數位簽章簽發和校正使用的非對稱金鑰是CA自己的公開金鑰和私密金鑰，跟認證申請者（提交認證申請的公司實體）提交的公開金鑰沒有任何關係。

（2）數位簽章的簽發過程跟公開金鑰加密的過程剛好相反，即是用私密金鑰加密，公開金鑰解密。（一對公開金鑰和私密金鑰，公開金鑰加密的內容只有私密金鑰能夠解密；反過來，私密金鑰加密的內容，也就有公開金鑰才能夠解密）

（3）現在大的CA都會有憑證鏈結，憑證鏈結的好處：首先是安全，保持CA的私密金鑰離線使用。第二個好處是方便部署和撤銷。這裡為啥要撤銷呢？因為，如果CA數位憑證出現問題（被篡改或者汙染），只需要撤銷相應層級的認證，根憑證依然是安全的。

（4）根CA認證都是自簽名，即用自己的公開金鑰和私密金鑰完成了簽名的製作和驗證。而憑證鏈結上的認證簽名都是使用上一級認證的非對稱金鑰進行簽名和驗證的。

（5）怎樣擷取根CA和多級CA的金鑰組？還有，既然是自簽名和自認證，那麼它們是否安全可信？這裡的答案是：當然可信，因為這些廠商跟瀏覽器和作業系統都有合作，它們的根公開金鑰都預設裝到了瀏覽器或者作業系統環境裡。

3.5 資料完整性驗證

資料轉送過程中的完整性使用MAC演算法來保證。為了避免網路中傳輸的資料被非法篡改，或者資料位元被汙染，SSL利用基於MD5或SHA的MAC演算法來保證訊息的完整性（由於MD5在實際應用中存在衝突的可能性比較大，所以盡量別採用MD5來驗證內容一致性）。 MAC演算法是在密鑰參與下的資料摘要演算法，能將密鑰和任意長度的資料轉換為固定長度的資料。寄件者在密鑰的作用下，利用MAC演算法計算出訊息的MAC值，並將其添加在需要發送的訊息之後，並發送給接收者。接收者利用同樣的密鑰和MAC演算法計算出訊息的MAC值，並與接收到的MAC值比較。如果二者相同，則報文沒有改變；否則，報文在傳輸過程中被修改或者汙染，接收者將丟棄該報文。 SHA也不能使用SHA0和SHA1，山東大學的王小雲教授（很牛的一個女教授，大家有興趣可以上網搜尋一下她的事迹）在2005年就宣布破解了 SHA-1完整版演算法，並獲得了業內專家的認可。微軟和google都已經宣布16年及17年之後不再支援sha1簽署憑證。

專題二：實際抓包分析

本文對百度搜尋進行了兩次抓包，第一次抓包之前清理了瀏覽器的所有緩衝；第二次抓包是在第一次抓包後的半分鐘內。

百度在2015年已經完成了百度搜尋的全站https，這在國內https發展中具有重大的意義（目前BAT三大家中，只有百度宣稱自己完成了全站HTTPS）。所以這篇文章就以www.baidu.com為例進行分析。

同時，作者採用的是chrome瀏覽器，chrome支援SNI （server Name Indication） 特性，對於HTTPS效能最佳化有很大的用處。

註：SNI是為瞭解決一個伺服器使用多個網域名稱和認證的SSL/TLS擴充。一句話簡述它的工作原理就是：在和伺服器建立SSL串連之前，先發送要訪問的網域名稱（hostname），這樣伺服器根據這個網域名稱返回一個合適的認證。目前，大多數作業系統和瀏覽器都已經很好地支援SNI擴充，OpenSSL 0.9.8已經內建這一功能，新版的nginx和apache也支援SNI擴充特性。

本文抓包訪問的URL為：http://www.baidu.com/

（如果是https://www.baidu.com/，則以下結果不一樣！）

抓包結果：

可以看到，百度採用以下策略：

（1）對於高版本瀏覽器，如果支援 https，且加解密演算法在TLS1.0 以上的，都將所有 http請求重新導向到 https請求

（2）對於https請求，則不變。

【詳細解析過程】

1、TCP三向交握

可以看到，我的電腦訪問的是http://www.baidu.com/，在初次建立三向交握的時候， 用戶端是去串連 8080連接埠的（我所在小區網路總出口做了一層總代理，因此，用戶端實際和代理機做的三向交握，代理機再幫用戶端去串連百度伺服器）

2、tunnel建立

由於小區網關設定了代理訪問，因此，在進行https訪問的時候，用戶端需要和代理機做"HTTPS CONNECT tunnel" 串連（關於"HTTPS CONNECT tunnel"串連，可以理解為：雖然後續的https請求都是代理機和百度伺服器進行公私密金鑰串連和對稱金鑰交換，以及資料通訊；但是，有了隧道串連之後，可以認為用戶端也在直接和百度伺服器進行通訊。）

fiddler抓包結果：

3、client hello

3.1 隨機數

在用戶端問候中，有四個位元組以Unix時間格式記錄了用戶端的國際標準時間間（UTC）。國際標準時間間是從1970年1月1日開始到當前時刻所經曆的秒數。在這個例子中，0x2516b84b就是國際標準時間間。在他後面有28位元組的隨機數（random_C），在後面的過程中我們會用到這個隨機數。

3.2 SID（Session ID）

如果出於某種原因，對話中斷，就需要重新握手。為了避免重新握手而造成的訪問效率低下，這時候引入了session ID的概念， session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要用戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的“對稱金鑰”，而不必重建一把。

因為我們抓包的時候，是幾個小時內第一次訪問https://www.baodu.com ，因此，這裡並沒有Session ID.（稍會兒我們會看到隔了半分鐘，第二次抓包就有這個Session ID）

session ID是目前所有瀏覽器都支援的方法，但是它的缺點在於session ID往往只保留在一台伺服器上。所以，如果用戶端的請求發到另一台伺服器（這是很有可能的，對於同一個網域名稱，當流量很大的時候，往往後台有幾十台RS機在提供服務），就無法恢複對話。session ticket就是為瞭解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支援。

3.3 密文族（Cipher Suites）

RFC2246中建議了很多中組合，一般寫法是"金鑰交換演算法-對稱式加密演算法-雜湊演算法，以“TLS_RSA_WITH_AES_256_CBC_SHA”為例：

（a）TLS為協議，RSA為金鑰交換的演算法；

（b）AES_256_CBC是對稱式加密演算法（其中256是密鑰長度，CBC是分組方式）；

（c）SHA是雜湊的演算法。

瀏覽器支援的密碼編譯演算法一般會比較多，而服務端會根據自身的業務情況選擇比較適合的加密組合發給用戶端。（比如綜合安全性以及速度、效能等因素）

3.4 Server_name擴充（一般瀏覽器也支援 SNI擴充）

當我們去訪問一個網站時，一定是先通過DNS解析出網站對應的ip地址，通過ip地址來訪問網站，由於很多時候一個ip地址是給很多的網站公用，因此如果沒有server_name這個欄位，server是無法給與用戶端相應的數位憑證的，Server_name擴充則允許伺服器對瀏覽器的請求授予相對應的認證。

伺服器回複

（包括Server Hello，Certificate，Certificate Status）

伺服器在收到client hello後，會回複三個資料包，下面分別看一下：

4、Server Hello

4.1、我們得到了伺服器的以Unix時間格式記錄的UTC和28位元組的隨機數 （random_S）。

4.2、Seesion ID，服務端對於session ID一般會有三種選擇  （稍會兒我們會看到隔了半分鐘，第二次抓包就有這個Session ID）：

（1）恢複的session ID：我們之前在client hello裡面已經提到，如果client hello裡面的session ID在服務端有緩衝，服務端會嘗試恢複這個session；

（2）新的session ID：這裡又分兩種情況，第一種是client hello裡面的session ID是空值，此時服務端會給用戶端一個新的session ID，第二種是client hello裡面的session ID此伺服器並沒有找到對應的緩衝，此時也會回一個新的session ID給用戶端；

（3）NULL：服務端不希望此session被恢複，因此session ID為空白。

4.3、我們記得在client hello裡面，用戶端給出了多種加密族 Cipher，而在用戶端所提供的加密族中，服務端挑選了“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”

（a）TLS為協議，RSA為金鑰交換的演算法；

（b）AES_256_CBC是對稱式加密演算法（其中256是密鑰長度，CBC是分組方式）；

（c）SHA是雜湊的演算法。

這就意味著服務端會使用ECDHE-RSA演算法進行金鑰交換，通過AES_128_GCM對稱式加密演算法來加密資料，利用SHA256雜湊演算法來確保資料完整性。

5、Certificate

在前面的https原理研究中，我們知道為了安全的將公開金鑰發給用戶端，服務端會把公開金鑰放入數位憑證中並發給用戶端（數位憑證可以自簽發，但是一般為了保證安全會有一個專門的CA機構簽發），所以這個報文就是數位憑證，4097 bytes就是認證的長度。

我們開啟這個認證，可以看到認證的具體資訊，這個具體資訊通過抓包報文的方式不是太直觀，可以在瀏覽器上直接看。（點擊chrome瀏覽器左上方的綠色鎖型按鈕）

6、Server Hello Done

我們抓的包是將 Server Hello Done  和 server key exchage 合并的包：

7、用戶端驗證認證真偽性

用戶端驗證認證的合法性，如果驗證通過才會進行後續通訊，否則根據錯誤情況不同做出提示和操作，合法性驗證封裝括如下：

（1）憑證鏈結的可信性trusted certificate path，方法如前文所述；

（2）認證是否吊銷revocation，有兩類方式離線CRL與線上OCSP，不同的用戶端行為會不同；

（3）有效期間expiry date，認證是否在有效時間範圍；

（4）網域名稱domain，核查認證網域名稱是否與當前的訪問網域名稱匹配，匹配規則後續分析；

8、秘鑰交換

這個過程非常複雜，大概總結一下：

（1）首先，用戶端利用CA數位憑證實現身份認證，利用非對稱式加密協商對稱金鑰。

（2）用戶端會向伺服器傳輸一個“pubkey”隨機數，伺服器收到之後，利用特定演算法產生另外一個“pubkey”隨機數，用戶端利用這兩個“pubkey”隨機數產生一個 pre-master 隨機數。

（3）用戶端利用自己在 client hello 裡面傳輸的隨機數random_C，以及收到的server hello裡面的隨機數random_S，外加pre-master 隨機數，利用對稱金鑰產生演算法產生 對稱金鑰enc_key：enc_key=Fuc(random_C, random_S, Pre-Master)

9、產生session ticket

如果出於某種原因，對話中斷，就需要重新握手。為了避免重新握手而造成的訪問效率低下，這時候引入了session ID的概念， session ID（以及session ticke）的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要用戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的“對話密鑰”，而不必重建一把。

因為我們抓包的時候，是幾個小時內第一次訪問 https://www.baodu.com 首頁，因此，這裡並沒有 Session ID.（稍會兒我們會看到隔了半分鐘，第二次抓包就有這個Session ID）

session ID是目前所有瀏覽器都支援的方法，但是它的缺點在於session ID往往只保留在一台伺服器上。所以，如果用戶端的請求發到另一台伺服器，就無法恢複對話。session ticket就是為瞭解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支援。

後續建立新的https會話，就可以利用 session ID 或者 session Tickets ， 對稱秘鑰可以再次使用，從而免去了 https 公私密金鑰交換、CA認證等等過程，極大地縮短 https 會話連線時間。

10、利用對稱秘鑰傳輸資料

三、半分鐘後，再次訪問百度：

有這些大的不同：

由於伺服器和瀏覽器緩衝了 Session ID 和 Session Tickets，不需要再進行 密鑰憑證傳遞，CA認證，產生 對稱金鑰等過程，直接利用半分鐘前的對稱金鑰加解密資料進行會話。

1、Client Hello

2、Server Hello

HTTPS為什麼安全 &分析 HTTPS 串連建立全過程