概述：
本文主要研究HTTPS協議的流程，通過抓包分析握手過程，主要將圍繞HTTPS優化進行展開。
探究：
1、WHAT
什麼是HTTPS,這個百度應該就有一大堆了，不做詳細描述，它是互聯網安全的基礎之一，工作在傳輸層之上，使用的加密協議爲TLS/SSL,
具體分爲以下幾個版本，
截止目前
SSL/TLS 協議族中有7種協議（網上有）： -
SSL v1 從未正式公開。
-
SSL v2 協議設計有缺陷，不安全。
-
SSL v3 老舊過時，缺乏一些新的密鑰特性。
-
TLS v1.0 在很大程度上是安全的，至少沒有曝光重大的安全漏洞。
-
TLS v1.1 和 TLS v1.2 目前都沒有著名的安全漏洞曝光。
-
TLS v1.3 仍然在草案階段，而且有待時間檢驗。
2、HOW
如何配置最簡單的https服務，這裏以nginx舉例。
a、創建服務器私鑰並去除口令：
openssl genrsa -des3 -out server.key 1024
openssl rsa -in server.key -out server.key
b、創建簽名請求的證書（CSR）,這個是給CA機構審覈用的,這裏我們自己審覈生成CRT證書：
openssl req -new -key server.key -out server.csr
d、最後使用上述私鑰和CSR 標記證書：
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
e、配置nginx，在server塊中開啓 ssl，然後設置好證書和祕鑰的地址即可。
ssl on; #開啓
ssl_certificate ssl/server.crt; #證書，包含公鑰
ssl_certificate_key ssl/server.key; #祕鑰
3、WHY
整個SSL協議棧包括了三種類型的協議：
-
-
握手協議：用於協商 SSL 密鑰
-
記錄協議：用於記錄 SSL 會話相關信息
-
警報協議：用於通知對端停止 SSL 會話
-
先來看看握手過程：
以上圖描述了 SSL握手的過程，主要分爲以下幾個部分
-
-
-
-
client hello
-
server hello
-
client key exchange
-
change cipher spec
-
-
-
前兩個過程生成了 非對稱加密的重要參數，創建了非對稱祕鑰，後兩個過程創建了對稱加密祕鑰。
接下來用wiresharke抓包，這裏抓的是本地的請求數據。
TCP先進行三次握手流程：
第一步：客戶端(192.168.194.1)發送SYN包，seq爲0，不攜帶數據
第二步 ：服務器端(192.168.194.132)返回SYN+ACK,不攜帶數據
第三步： 客戶端返回ACK，這裏省略不在分析，就是把ACK位設置爲了1, 至此TCP連接就已經建立了.
接下來會建立SSL連接，下面繼續分析SSL連接連接過程：
第一步： 客戶端發送 Client Hello數據包。具體抓包內容可以看到client hello握手協議的內容，稍後再根據這些內容研究優化HTTPS性能。
主要內容：
支持的最高TSL協議版本version，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，當前基本不再使用低於 TLSv1 的版本; 我這裏因爲使用的最新的谷歌瀏覽器，所以
支持的協議最高版本是TLS 1.2
客戶端支持的加密套件 cipher suites 列表， 每個加密套件對應前面 TLS 原理中的四個功能的組合：
認證算法 Au (身份驗證)、
密鑰交換算法 KeyExchange(密鑰協商)、
對稱加密算法 Enc (信息加密)、
信息摘要 Mac(完整性校驗);
支持的壓縮算法 compression methods 列表，用於後續的信息壓縮傳輸;
隨機數 random_C，用於後續的密鑰的生成;
擴展字段 extensions，支持協議與算法的相關參數以及其它輔助信息等，常見的 SNI 就屬於擴展字段，後續單獨討論該字段作用。
。然後服務器端會返回一個ACK確認包。(2次RTT)；
第二步：服務端返回ServerHello數據包。
server hello
a、server hello 主要確定了服務器端選擇的版本，產生的隨機字符串(用於生成對稱祕鑰), 使用的加密套件，壓縮算法等。
b、證書，即包含了服務器端信息的公鑰。我這個證書的長度是587個字節，客戶端會驗證這個證書的身份
c、server key exchange 這一步主要是根據前面選擇的加密套件中的 對稱祕鑰交換算法來的。涉及到使用DH算法通過兩個隨機數RANDOM_C計算祕鑰的問題。
d、sever hello done 標記給客戶端我發送完畢
這一步主要是服務器端發送證書，生成對稱祕鑰（1次RTT）
第三步：客戶端收到server hello以後,發送client key exchange等給服務器端, 注意這裏標識了ACK，減少了一次RTT
這一步同樣也是根據服務端選擇的加密套件中的交換算法決定的 等（1次RTT）
第四步： 客戶端返回ACK以及會話的ticket
這一步主要是
1、建立了ticket(類似於cookie,方便對稱加密複用 見下方詳解)
2、客戶端通知服務器端，修改了加密方法，
3、之後就可以是用對稱祕鑰加解密通行了（1次RTT）
總結：以上就是HTTPS首次建立連接的大體過程，當然還包括了一些複雜的擴展選項。
PS：
難點一：關於server hello中的server key exchange 和 第三步中的客戶端響應client key exchange
這個是客戶端和服務器端交換祕鑰的算法，不同的加密使用的是不同的算法， 比如這裏（server hello），服務器選擇了
使用
，這個加密套件中包含的 祕鑰交換算法爲 DH算法，還有其他的祕鑰交換算法，比如直接通過生成的公祕鑰進行加密發送。
a、公祕鑰交換祕鑰
使用服務器的公鑰對premaster進行加密，發送給服務器端，服務器端通過私鑰解密，最後雙方根據premaster和相互生成的隨機字符串確定一個對稱祕鑰。
b、DH祕鑰交換算法 （這裏使用的加密套件就是使用這種交換算法）
how：迪菲－赫爾曼密鑰交換（Diffie–Hellman key exchange，簡稱“D–H”） 是一種安全協議。
它可以讓雙方在完全沒有對方任何預先信息的條件下通過不安全信道建立起一個密鑰。這個密鑰可以在後續的通訊中作爲對稱密鑰來加密通訊內容。
what： 它的使用是封裝在加密套件中的，協商加密使用的交換算法不需要我們介入。
why ：
![]()
![]()
假如用戶A和用戶B希望交換一個密鑰。
取素數p和整數a，a是p的一個原根，公開a和p。
A選擇隨機數XA < p，並計算YA=a^XA mod p。
B選擇隨機數XB < p，並計算YB=a^XB mod p。
每一方都將X保密而將Y公開讓另一方得到。
A計算密鑰的方式是：K=(YB) ^XA mod p
B計算密鑰的方式是：K=(YA) ^XB mod p
上面是相關算法的實現，同樣我們來看看server key exchange包中的DH參數和 client key exchange中的參數：
有一個參數 pubkey， 還有一個是爲了防止參數被篡改增加的簽名
同樣有一個參數 pubkey
這裏的算法稍微有點複雜，在下一篇文章中具體介紹。 大家只要記住這裏有一個Client random, server random, server pub ,client pub的交換就行了。
難點二：會話中建立的session ID和ticket
HTTPS的過程是在TCP三次握手之後會進行SSL的四次握手，如果一個業務請求包含多條的加密流，反覆的握手請求勢必會導致較高的延遲。SSL的設計者們在儘量減少握手次數方面也是做了一定的考慮的。具體就是Session ID和Session
ticket的應用。本文主要就Session ticket方法結合具體應用做一次簡單的分析。
流關聯的一種形式是Session ID，可以去了解一下原理。而本文所述的Sessionticket，是流關聯的另外一種應用場景。
無論是Session ID還是Session ticket都是爲了複用已有的加密參數，諸如祕鑰以及加密算法等，進而減少SSL的握手次數，目的是提高有效數據的響應效率。
Session ID的思想就是服務器端爲每一次的會話生成並記錄一個ID號併發送給客戶端，在重新連接的時候（多次短連接場景），客戶端向服務器發送該ID號，服務器查找自己的會話記錄，匹配之後，重用之前的加密參數信息。
而Sessionticket的思想類似於cookie，是由服務器將ticket數據結構發由客戶端管理，ticket中是包含了加密參數等連接信息。當需要重連的時候，客戶端將ticket發送給服務器。這樣雙方就得到了重用的加密參數。
Session ticket較之Session ID優勢在於服務器使用了例如DNS負載均衡等技術的時候。Session ID往往是存儲在一臺服務器上，當我向不同的服務器請求的時候，就無法複用之前的加密參數信息，而Session ticket可以較好的解決此類問題，因爲相關的加密參數信息交由客戶端管理，服務器只要確認即可。不過目前只有部分瀏覽器支持Session
ticket，比如谷歌等。其他不支持的瀏覽器仍然使用Session ID
難點三： TLS/SSL的區別
SSL：（Secure Socket Layer，安全套接字層），位於可靠的面向連接的網絡層協議和應用層協議之間的一種協議層。SSL通過互相認證、使用數字簽名確保完整性、使用加密確保私密性，以實現客戶端和服務器之間的安全通訊。該協議由兩層組成：SSL記錄協議和SSL握手協議。
TLS：(Transport Layer Security，傳輸層安全協議)，用於兩個應用程序之間提供保密性和數據完整性。該協議由兩層組成：TLS記錄協議和TLS握手協議。
SSL是Netscape開發的專門用戶保護Web通訊的，目前版本爲3.0。最新版本的TLS 1.0是IETF(工程任務組)制定的一種新的協議，它建立在SSL 3.0協議規範之上，是SSL 3.0的後續版本。兩者差別極小，可以理解爲SSL 3.1，它是寫入了RFC的。
難點四： RSA和DH祕鑰協商的區別和優缺點
RSA算法是基於大數難於分解的原理。不但可以用於認證，也可以用於密鑰傳輸。那麼用戶A和B如何利用RSA算法來傳輸密鑰呢？
1：A產生一個密鑰K，用B的公鑰加密K，然後將得到的密文發送給B。
2：B用自己的私鑰解密收到的密鑰，就可以得到密鑰。
DH算法實現以及兩者的區別見下一章，
摘要參考：