HTTPS目前是網(wǎng)站標(biāo)配，否則瀏覽器會(huì)提示鏈接不安全，同HTTP相比比，HTTPS提供安全通信，具體原因是多了個(gè)“S”層，或者說(shuō)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ā)送給對(duì)方，如果中間某個(gè)路由節(jié)點(diǎn)抓取了數(shù)據(jù)，就可以直接看到通信內(nèi)容，甚至可以篡改后，路由給目標(biāo)對(duì)象，如下：
可見HTTP傳輸是不安全的，但，如果傳輸?shù)氖侵挥须p方可校驗(yàn)的密文，就可以避免被偷竊、篡改，保證傳輸?shù)陌踩裕@就是SSL/TLS層做的事情。
HTTPS從哪些方面保證傳輸?shù)陌踩裕?/h3>
SSL/TLS協(xié)議主要從三方面來(lái)保證數(shù)據(jù)傳輸?shù)陌踩裕罕Ｃ堋㈣b別、完整：
- 身份校驗(yàn)與鑒別：強(qiáng)制服務(wù)器端認(rèn)證與客戶端認(rèn)證【SSL證書有效性】，來(lái)保證消息的源頭準(zhǔn)確
- 數(shù)據(jù)保密性：通過(guò)非對(duì)稱與對(duì)稱加密保證傳輸?shù)臄?shù)據(jù)無(wú)法被解析
- 數(shù)據(jù)的完整性：利用MAC[Message Authentication Codes]消息摘要算法來(lái)保證
第一個(gè)問(wèn)題：怎么保證通信的另一端是目標(biāo)端
對(duì)用戶端而言：怎么保證訪問(wèn)的網(wǎng)站就是目標(biāo)網(wǎng)站？答案就是證書。每個(gè)HTTPS網(wǎng)站都需要TLS證書，在數(shù)據(jù)傳輸開始前，服務(wù)端先將證書下發(fā)到用戶端，由用戶根據(jù)證書判斷是否是目標(biāo)網(wǎng)站。這其中的原理是什么，證書又是如何標(biāo)識(shí)網(wǎng)站的有效性呢？證書也叫 digital certificate 或者public key certificate，是密碼學(xué)中的概念，在TLS中就是指CA證書【由證書的簽發(fā)機(jī)構(gòu)（Certificate Authority，簡(jiǎn)稱為 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)站點(diǎn)的身份信息，并可以通過(guò)某種方式校驗(yàn)其合法性，對(duì)于任何一個(gè)HTTPS網(wǎng)站，你都可以拿到其CA證書公鑰信息，在Chrome瀏覽器中點(diǎn)擊HTTPS網(wǎng)站的鎖標(biāo)志，就可以查看公鑰信息，并可以導(dǎo)出CA二進(jìn)制文件：
瀏覽器就是通過(guò)這個(gè)文件來(lái)校驗(yàn)網(wǎng)站是否安全合法，可以看到，證書其實(shí)內(nèi)置了一個(gè)頒發(fā)鏈條關(guān)系，根證書機(jī)構(gòu)->次級(jí)證書機(jī)構(gòu)->次次級(jí)->網(wǎng)站自身，只要驗(yàn)證這個(gè)鏈條是安全的，就證明網(wǎng)站合法，背后的技術(shù)其實(shí)是信任鏈+RSA的非對(duì)稱加密+系統(tǒng)內(nèi)置根證書。CA在頒發(fā)證書的時(shí)候，會(huì)用自己的私鑰計(jì)算出要頒發(fā)證書的簽名，其公鑰是公開的，只要簽名可被公鑰驗(yàn)證就說(shuō)明該證書是由該CA頒發(fā)的，核心校驗(yàn)邏輯如下
- 簽名算法：散列函數(shù)計(jì)算公開明文信息摘要，之后采用簽名機(jī)構(gòu)的CA私鑰對(duì)信息摘要進(jìn)行加密，密文即簽名;那如果想要驗(yàn)證證書有效，
- 驗(yàn)簽算法：讀取證書中的相關(guān)的明文信息，采用簽名相同的散列函數(shù)計(jì)算得到信息摘要A，然后獲取簽名機(jī)構(gòu)的CA公鑰，對(duì)簽名信息進(jìn)行解密，得到證書信息摘要B，如果A=B則說(shuō)明證書是由其上級(jí)CA簽發(fā)的，
那么上級(jí)的CA又是如何保證安全呢？重復(fù)上述操作即可，最終都是靠根證書來(lái)驗(yàn)證的，根證書的安全性不需要驗(yàn)證，由系統(tǒng)保證，如此就形成了一個(gè)證書的信任鏈，也就能驗(yàn)證當(dāng)前網(wǎng)站證書的有效性，證書的信任鏈校驗(yàn)如下：
第二個(gè)問(wèn)題：如何保證數(shù)據(jù)保密性
TLS協(xié)議最大的提升點(diǎn)就是數(shù)據(jù)的安全，通HTTP通信相比，HTTPS的通信是加密的，在協(xié)商階段，通過(guò)非對(duì)稱加密確定對(duì)稱加密使用的秘鑰，之后利用對(duì)稱秘鑰進(jìn)行加密通信，這樣傳輸?shù)臄?shù)據(jù)就是密文，就算中間節(jié)點(diǎn)泄漏，也可以保證數(shù)據(jù)不被竊取，從而保證通信數(shù)據(jù)的安全性。
第三個(gè)個(gè)問(wèn)題：數(shù)據(jù)的完整性
第三個(gè)問(wèn)題，雖然中間節(jié)點(diǎn)無(wú)法竊取數(shù)據(jù)，但是還是可以隨意更改數(shù)據(jù)的，那么怎么保證數(shù)據(jù)的完整性呢，這個(gè)其實(shí)任何數(shù)據(jù)傳輸中都會(huì)有這個(gè)問(wèn)題，通過(guò)MAC[Message Authentication Codes]信息摘要算法就可以解決這個(gè)問(wèn)題，同普通MD5、SHA等對(duì)比，MAC消息的散列加入了秘鑰的概念，更加安全，是MD5和SHA算法的升級(jí)版，可以認(rèn)為TLS完整性是數(shù)據(jù)保密性延伸，接下來(lái)就借助WireShark看看TLS握手的過(guò)程，并看看是如何實(shí)現(xiàn)身份鑒別、保密性、完整性的。
HTTPS傳輸?shù)陌踩訵ireShark原理分析
HTTPS安全通信簡(jiǎn)化來(lái)說(shuō)：在協(xié)商階段用非對(duì)稱加密協(xié)商好通信的對(duì)稱秘鑰，然后用對(duì)稱秘鑰加密進(jìn)行數(shù)據(jù)通信，簡(jiǎn)易的WireShark TLS/SSL協(xié)商過(guò)程示意如下：
細(xì)化分離后示意如下：
握手分多個(gè)階段，不過(guò)一次握手可以完成多個(gè)動(dòng)作，而且也并不是所有類型的握手都是上述模型，因?yàn)閰f(xié)商對(duì)稱秘鑰的算法不止一種，所以握手的具體操作也并非一成不變，比如RSA就比ECDHE要簡(jiǎn)單的多，目前主流使用的都是ECDHE，具體流程拆分如下：
Client Hello 【TLS/SSL握手發(fā)起】
Client Hello是TLS/SSL握手發(fā)起的第一個(gè)動(dòng)作，類似TCP的SYN，Client Hello 階段客戶端會(huì)指定版本，隨機(jī)數(shù)、支持的密碼套件供服務(wù)端選擇，具體的包數(shù)據(jù)如下
啟動(dòng)TLS握手過(guò)程，提供自己所能支持各種算法，同時(shí)提供一個(gè)將來(lái)所能用到的隨機(jī)數(shù)。
ContentType指示TLS通信處于哪個(gè)階段階段，值22代表Handshake，握手階段，Version是TLS的版本1.2，在握手階段，后面鏈接的就是握手協(xié)議，這里是Client Hello，值是1，同時(shí)還會(huì)創(chuàng)建一個(gè)隨機(jī)數(shù)random給Server，它會(huì)在生成session key【對(duì)稱密鑰】時(shí)使用。之后就是支持的供服務(wù)端選擇的密碼套件，接下來(lái)等服務(wù)端返回。
Server Hello
Handshake Type: Server Hello (2)，作為對(duì)Client Hello的響應(yīng) ，確定使用的加密套件: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)，密鑰協(xié)商使用 ECDHE，簽名使用 RSA，
數(shù)據(jù)通信通信使用 AES 對(duì)稱加密，并且密鑰長(zhǎng)度是128位，GCM分組，同時(shí)生成一個(gè)服務(wù)端的random及會(huì)話ID回傳。
Certificate 服務(wù)端發(fā)送證書
這一步服務(wù)器將配置的證書【鏈】發(fā)送給客戶端，客戶端基于上文所述的證書鏈校驗(yàn)證書的有效性，這里發(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是針對(duì)選定的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不會(huì)使用證書中的靜態(tài)公鑰參與對(duì)稱秘鑰的生成，而是需要服務(wù)端與客戶端通過(guò)彼此協(xié)商確定對(duì)稱秘鑰，而D-H算法模型需要兩對(duì)非對(duì)稱秘鑰對(duì)，各端保留自己的私鑰，同時(shí)握有雙方的公鑰，然后基于D-H算法雙端可以算出一樣的對(duì)稱加密秘鑰，而這就需要C/S互傳自己的公鑰
服務(wù)端做完這一步，其實(shí)ECDHE算法中服務(wù)端需要提供的信息已經(jīng)結(jié)束，發(fā)送 Server Hello Done告訴客戶端，然后等待客戶端回傳它的D-H公鑰。
算法：
Client端私鑰keyc，計(jì)算C端公鑰pubKC = g^keyc mod p，Server端私鑰keys，計(jì)算S端公鑰pubKS = g ^ keys mod p
pubKS ^ keyc mod p= pubKC ^ keys mod p
其中p和g是公開的DH參數(shù)，只要P是一個(gè)足夠大的數(shù)，在不知道私鑰的情況下，即使截獲了雙方的公鑰，也是很難破解的。
Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
客戶端收到服務(wù)端的證書后，利用信任鏈檢測(cè)證書有效性，同時(shí)也會(huì)同Server Key Exchange 類似，將自己的Diffie-Hellman公鑰發(fā)送給Server端，
至此，ECDHE協(xié)商所需要的信息都傳輸完畢， 雙方都可以基于ECDHE算法算出的共享密鑰，同時(shí)結(jié)合之前的隨機(jī)數(shù)生成最終的對(duì)稱加密秘鑰：
客戶端隨機(jī)數(shù) & 服務(wù)端隨機(jī)數(shù) & ECDHE 算法算出的共享密鑰
之后客戶端發(fā)送Change Cipher Spec與 Encrypted Handshake Message標(biāo)識(shí)握手完成，同時(shí)傳輸一個(gè)加密的數(shù)據(jù)給Server，驗(yàn)證雙方確立的秘鑰是否正確，這就需要服務(wù)端也要重復(fù)這個(gè)操作給客戶端，這樣才能驗(yàn)證彼此的加解密一致，即服務(wù)端也要來(lái)一次Encrypted Handshake Message回傳給客戶端校驗(yàn)，
走完如上流程，雙方就確認(rèn)了正確的對(duì)稱加密通道，后面就是TLS的數(shù)據(jù)通信，其Record Layer的ContentType 也會(huì)變成 Content Type: Application Data (23)：
Client Hello與Server Hello階段交換的隨機(jī)數(shù)有什么用
最終對(duì)稱會(huì)話密鑰包含三部分因子：
- 客戶端隨機(jī)數(shù)
- 服務(wù)端隨機(jī)數(shù)
- ECDHE 算法算出的共享密鑰
Client Hello與Server Hello階段交換的隨機(jī)數(shù)，是為了提高秘鑰的「隨機(jī)」程度而進(jìn)行的，這樣有助于提高會(huì)話密鑰破解難度。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-403534.html
HTTPS中間人攻擊及抓包
HTTPS通過(guò)加密與完整性校驗(yàn)可以防止數(shù)據(jù)包破解與篡改，但對(duì)于主動(dòng)授信的抓包操作是沒(méi)法防護(hù)，比如Charles抓包，在這個(gè)場(chǎng)景用戶已經(jīng)風(fēng)險(xiǎn)，并且將Charles提供的證書信任為根證書，這從源頭上構(gòu)建了一條虛擬的信任鏈：在握手階段，Charles利用自己的公鑰，生成客戶端可以信任的篡改證書，從而可以充作中間人進(jìn)而抓包，所謂中間人攻擊，感覺跟Https抓包原理一樣，都是要強(qiáng)制添加一個(gè)自己的信任根證書。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-403534.html
到了這里，關(guān)于用WireShark看HTTPS的SSL/TLS協(xié)議的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
