HTTPS目前是網(wǎng)站標(biāo)配，否則瀏覽器會提示鏈接不安全，同HTTP相比比，HTTPS提供安全通信，具體原因是多了個“S”層，或者說SSL層[Secure Sockets Layer]，現(xiàn)在一般都是TLS[Transport Layer Security]，它是HTTP明文通信變成安全加密通信的基礎(chǔ)，SSL/TLS介于應(yīng)用層和TCP層之間，從應(yīng)用層數(shù)據(jù)進(jìn)行加密再傳輸。安全的核心就在加密上：
如上圖所示，HTTP明文通信經(jīng)中間路由最終發(fā)送給對方，如果中間某個路由節(jié)點抓取了數(shù)據(jù)，就可以直接看到通信內(nèi)容，甚至可以篡改后，路由給目標(biāo)對象，如下：
可見HTTP傳輸是不安全的，但，如果傳輸?shù)氖侵挥须p方可校驗的密文，就可以避免被偷竊、篡改，保證傳輸?shù)陌踩?，這就是SSL/TLS層做的事情。
HTTPS從哪些方面保證傳輸?shù)陌踩裕?/h2>
SSL/TLS協(xié)議主要從三方面來保證數(shù)據(jù)傳輸?shù)陌踩裕罕Ｃ堋㈣b別、完整：
- 身份校驗與鑒別：強(qiáng)制服務(wù)器端認(rèn)證與客戶端認(rèn)證【SSL證書有效性】，來保證消息的源頭準(zhǔn)確
- 數(shù)據(jù)保密性：通過非對稱與對稱加密保證傳輸?shù)臄?shù)據(jù)無法被解析
- 數(shù)據(jù)的完整性：利用MAC[Message Authentication Codes]消息摘要算法來保證
第一個問題：怎么保證通信的另一端是目標(biāo)端
對用戶端而言：怎么保證訪問的網(wǎng)站就是目標(biāo)網(wǎng)站？答案就是證書。每個HTTPS網(wǎng)站都需要TLS證書，在數(shù)據(jù)傳輸開始前，服務(wù)端先將證書下發(fā)到用戶端，由用戶根據(jù)證書判斷是否是目標(biāo)網(wǎng)站。這其中的原理是什么，證書又是如何標(biāo)識網(wǎng)站的有效性呢？證書也叫 digital certificate 或者public key certificate，是密碼學(xué)中的概念，在TLS中就是指CA證書【由證書的簽發(fā)機(jī)構(gòu)（Certificate Authority，簡稱為 CA）頒布的證書】，好比是權(quán)威部門的公章，WIKI百科解釋如下：
In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key.[1] The certificate includes information about the key, information about the identity of its owner (called the subject), and the digital signature of an entity that has verified the certificate's contents (called the issuer). If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.
大意就是證書包含了目標(biāo)站點的身份信息，并可以通過某種方式校驗其合法性，對于任何一個HTTPS網(wǎng)站，你都可以拿到其CA證書公鑰信息，在Chrome瀏覽器中點擊HTTPS網(wǎng)站的鎖標(biāo)志，就可以查看公鑰信息，并可以導(dǎo)出CA二進(jìn)制文件：
瀏覽器就是通過這個文件來校驗網(wǎng)站是否安全合法，可以看到，證書其實內(nèi)置了一個頒發(fā)鏈條關(guān)系，根證書機(jī)構(gòu)->次級證書機(jī)構(gòu)->次次級->網(wǎng)站自身，只要驗證這個鏈條是安全的，就證明網(wǎng)站合法，背后的技術(shù)其實是信任鏈+RSA的非對稱加密+系統(tǒng)內(nèi)置根證書。CA在頒發(fā)證書的時候，會用自己的私鑰計算出要頒發(fā)證書的簽名，其公鑰是公開的，只要簽名可被公鑰驗證就說明該證書是由該CA頒發(fā)的，核心校驗邏輯如下
- 簽名算法：散列函數(shù)計算公開明文信息摘要，之后采用簽名機(jī)構(gòu)的CA私鑰對信息摘要進(jìn)行加密，密文即簽名;那如果想要驗證證書有效，
- 驗簽算法：讀取證書中的相關(guān)的明文信息，采用簽名相同的散列函數(shù)計算得到信息摘要A，然后獲取簽名機(jī)構(gòu)的CA公鑰，對簽名信息進(jìn)行解密，得到證書信息摘要B，如果A=B則說明證書是由其上級CA簽發(fā)的，
那么上級的CA又是如何保證安全呢？重復(fù)上述操作即可，最終都是靠根證書來驗證的，根證書的安全性不需要驗證，由系統(tǒng)保證，如此就形成了一個證書的信任鏈，也就能驗證當(dāng)前網(wǎng)站證書的有效性，證書的信任鏈校驗如下：
第二個問題：如何保證數(shù)據(jù)保密性
TLS協(xié)議最大的提升點就是數(shù)據(jù)的安全，通HTTP通信相比，HTTPS的通信是加密的，在協(xié)商階段，通過非對稱加密確定對稱加密使用的秘鑰，之后利用對稱秘鑰進(jìn)行加密通信，這樣傳輸?shù)臄?shù)據(jù)就是密文，就算中間節(jié)點泄漏，也可以保證數(shù)據(jù)不被竊取，從而保證通信數(shù)據(jù)的安全性。
第三個個問題：數(shù)據(jù)的完整性
第三個問題，雖然中間節(jié)點無法竊取數(shù)據(jù)，但是還是可以隨意更改數(shù)據(jù)的，那么怎么保證數(shù)據(jù)的完整性呢，這個其實任何數(shù)據(jù)傳輸中都會有這個問題，通過MAC[Message Authentication Codes]信息摘要算法就可以解決這個問題，同普通MD5、SHA等對比，MAC消息的散列加入了秘鑰的概念，更加安全，是MD5和SHA算法的升級版，可以認(rèn)為TLS完整性是數(shù)據(jù)保密性延伸，接下來就借助WireShark看看TLS握手的過程，并看看是如何實現(xiàn)身份鑒別、保密性、完整性的。
HTTPS傳輸?shù)陌踩訵ireShark原理分析
HTTPS安全通信簡化來說：在協(xié)商階段用非對稱加密協(xié)商好通信的對稱秘鑰，然后用對稱秘鑰加密進(jìn)行數(shù)據(jù)通信，簡易的WireShark TLS/SSL協(xié)商過程示意如下：
細(xì)化分離后示意如下：
握手分多個階段，不過一次握手可以完成多個動作，而且也并不是所有類型的握手都是上述模型，因為協(xié)商對稱秘鑰的算法不止一種，所以握手的具體操作也并非一成不變，比如RSA就比ECDHE要簡單的多，目前主流使用的都是ECDHE，具體流程拆分如下：
Client Hello 【TLS/SSL握手發(fā)起】
Client Hello是TLS/SSL握手發(fā)起的第一個動作，類似TCP的SYN，Client Hello 階段客戶端會指定版本，隨機(jī)數(shù)、支持的密碼套件供服務(wù)端選擇，具體的包數(shù)據(jù)如下
啟動TLS握手過程，提供自己所能支持各種算法，同時提供一個將來所能用到的隨機(jī)數(shù)。
ContentType指示TLS通信處于哪個階段階段，值22代表Handshake，握手階段，Version是TLS的版本1.2，在握手階段，后面鏈接的就是握手協(xié)議，這里是Client Hello，值是1，同時還會創(chuàng)建一個隨機(jī)數(shù)random給Server，它會在生成session key【對稱密鑰】時使用。之后就是支持的供服務(wù)端選擇的密碼套件，接下來等服務(wù)端返回。
Server Hello
Handshake Type: Server Hello (2)，作為對Client Hello的響應(yīng) ，確定使用的加密套件: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)，密鑰協(xié)商使用 ECDHE，簽名使用 RSA，
數(shù)據(jù)通信通信使用 AES 對稱加密，并且密鑰長度是128位，GCM分組，同時生成一個服務(wù)端的random及會話ID回傳。
Certificate 服務(wù)端發(fā)送證書
這一步服務(wù)器將配置的證書【鏈】發(fā)送給客戶端，客戶端基于上文所述的證書鏈校驗證書的有效性，這里發(fā)送的證書是二進(jìn)制格，可以利用wireshark右鍵“Export Packet Bytes”功能，導(dǎo)出.CER格式的證書。如下可以看到傳輸?shù)淖C書鏈。
導(dǎo)出的CER格式的證書如下，最關(guān)鍵的就其公鑰跟數(shù)字簽名。
Server Key Exchange Server Hello Done
Server Key Exchange是針對選定的ECDHE協(xié)商所必須的步驟，Diffie-Hellman模型解釋如下：
In Diffie-Hellman, the client can't compute a premaster secret on its own; both sides contribute to computing it, so the client needs to get a Diffie-Hellman public key from the server. In ephemeral Diffie-Hellman, that public key isn't in the certificate (that's what ephemeral Diffie-Hellman means). So the server has to send the client its ephemeral DH public key in a separate message so that the client can compute the premaster secret (remember, both parties need to know the premaster secret, because that's how they derive the master secret). That message is the ServerKeyExchange.
大意就是ephemeral Diffie-Hellman不會使用證書中的靜態(tài)公鑰參與對稱秘鑰的生成，而是需要服務(wù)端與客戶端通過彼此協(xié)商確定對稱秘鑰，而D-H算法模型需要兩對非對稱秘鑰對，各端保留自己的私鑰，同時握有雙方的公鑰，然后基于D-H算法雙端可以算出一樣的對稱加密秘鑰，而這就需要C/S互傳自己的公鑰
服務(wù)端做完這一步，其實ECDHE算法中服務(wù)端需要提供的信息已經(jīng)結(jié)束，發(fā)送 Server Hello Done告訴客戶端，然后等待客戶端回傳它的D-H公鑰。
算法：
Client端私鑰keyc，計算C端公鑰pubKC = g^keyc mod p，Server端私鑰keys，計算S端公鑰pubKS = g ^ keys mod p
pubKS ^ keyc mod p= pubKC ^ keys mod p
其中p和g是公開的DH參數(shù)，只要P是一個足夠大的數(shù)，在不知道私鑰的情況下，即使截獲了雙方的公鑰，也是很難破解的。
Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
客戶端收到服務(wù)端的證書后，利用信任鏈檢測證書有效性，同時也會同Server Key Exchange 類似，將自己的Diffie-Hellman公鑰發(fā)送給Server端，
至此，ECDHE協(xié)商所需要的信息都傳輸完畢， 雙方都可以基于ECDHE算法算出的共享密鑰，同時結(jié)合之前的隨機(jī)數(shù)生成最終的對稱加密秘鑰：
客戶端隨機(jī)數(shù) & 服務(wù)端隨機(jī)數(shù) & ECDHE 算法算出的共享密鑰
之后客戶端發(fā)送Change Cipher Spec與 Encrypted Handshake Message標(biāo)識握手完成，同時傳輸一個加密的數(shù)據(jù)給Server，驗證雙方確立的秘鑰是否正確，這就需要服務(wù)端也要重復(fù)這個操作給客戶端，這樣才能驗證彼此的加解密一致，即服務(wù)端也要來一次Encrypted Handshake Message回傳給客戶端校驗，
走完如上流程，雙方就確認(rèn)了正確的對稱加密通道，后面就是TLS的數(shù)據(jù)通信，其Record Layer的ContentType 也會變成 Content Type: Application Data (23)：
Client Hello與Server Hello階段交換的隨機(jī)數(shù)有什么用
最終對稱會話密鑰包含三部分因子：
- 客戶端隨機(jī)數(shù)
- 服務(wù)端隨機(jī)數(shù)
- ECDHE 算法算出的共享密鑰
Client Hello與Server Hello階段交換的隨機(jī)數(shù)，是為了提高秘鑰的「隨機(jī)」程度而進(jìn)行的，這樣有助于提高會話密鑰破解難度。
HTTPS中間人攻擊及抓包
HTTPS通過加密與完整性校驗可以防止數(shù)據(jù)包破解與篡改，但對于主動授信的抓包操作是沒法防護(hù)，比如Charles抓包，在這個場景用戶已經(jīng)風(fēng)險，并且將Charles提供的證書信任為根證書，這從源頭上構(gòu)建了一條虛擬的信任鏈：在握手階段，Charles利用自己的公鑰，生成客戶端可以信任的篡改證書，從而可以充作中間人進(jìn)而抓包，所謂中間人攻擊，感覺跟Https抓包原理一樣，都是要強(qiáng)制添加一個自己的信任根證書。
