本文將分兩個專題去理解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
視頻鏈接http://edu.aqniu.com/course/317