文章首發(fā)于個(gè)人博客地址：HTTPS詳解
如需轉(zhuǎn)載译荞，請(qǐng)附帶說明文章出處。

HTTP

tps: HTTP協(xié)議的筆記在另外一篇筆記中詳細(xì)記載，這里對(duì)與HTTP協(xié)議的發(fā)展歷史等不做闡述。

什么是HTTP

HTTP為超文本傳輸協(xié)議堪滨，是一個(gè)基于請(qǐng)求與響應(yīng)懂盐，無狀態(tài)北启，應(yīng)用層的協(xié)議，持剖校基于TCP/IP協(xié)議傳輸數(shù)據(jù)抬旺。互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)祥楣。設(shè)計(jì)HTTP的初衷是為了提供一種發(fā)布和接收HTML頁(yè)面的方法开财。

HTTP的特點(diǎn)

• 無狀態(tài)：對(duì)客戶端沒有存儲(chǔ)狀態(tài)汉柒，對(duì)事物處理沒有記憶能力。比如登錄網(wǎng)站的反復(fù)登錄操作责鳍。
  • 一般可以使用cookies來記錄用戶的登錄相關(guān)信息碾褂，設(shè)定過期時(shí)間等。
• 無連接：HTTP/1.1之前历葛，由于無狀態(tài)的特點(diǎn)正塌，每次請(qǐng)求都需要經(jīng)過TCP三次握手和四次揮手來重新建立和關(guān)閉TCP連接。如果是過多地請(qǐng)求恤溶，對(duì)于資源的利用和性能都有一定的影響乓诽。
  • 一般可以使用Connection: keep-alive來建立持久連接，避免每次都需要重新建立TCP連接咒程。很多瀏覽器采用少量并行的TCP連接鸠天，其中每一個(gè)TCP連接都是持久連接的形式。
  • 但是對(duì)于存在代理服務(wù)器的帐姻，容易出現(xiàn)盲中繼稠集，啞巴代理的情況（代理服務(wù)器不認(rèn)識(shí)Connection: keep-alive）。
  • HTTP/1.1中默認(rèn)連接都是持久連接饥瓷，不需要顯示的指定keep-alive剥纷，在不希望建立持久連接 的請(qǐng)款下，請(qǐng)求首部中添加Connection: close來表示希望接收到響應(yīng)后就斷開連接呢铆。
• 基于請(qǐng)求和響應(yīng)： 有客戶端發(fā)情請(qǐng)求晦鞋，服務(wù)端響應(yīng)。
• 簡(jiǎn)單快速刺洒，靈活
• 使用明文鳖宾，請(qǐng)求和響應(yīng)不會(huì)對(duì)通信放進(jìn)行確認(rèn)，無法保證數(shù)據(jù)的完整性逆航。
  • 針對(duì)HTTP明文傳輸鼎文，可以使用加密傳輸數(shù)據(jù)的方式。比如使用對(duì)陣密鑰加密因俐，MD5加密拇惋，base64加密等。

HTTP通信不加密的風(fēng)險(xiǎn)

• 竊聽風(fēng)險(xiǎn)：第三方可以獲取通信內(nèi)容抹剩。
• 篡改風(fēng)險(xiǎn)：第三方可以修改通信內(nèi)容撑帖。
• 冒充風(fēng)險(xiǎn)：第三方可以冒充他人身份參與通信。

HTTPS

什么是HTTPS

HTTPS是一種通過計(jì)算機(jī)網(wǎng)絡(luò)進(jìn)行安全通信的傳輸協(xié)議澳眷，經(jīng)由HTTP進(jìn)行通信胡嘿，利用SSL/TLS建立全信道，加密數(shù)據(jù)包钳踊。HTTPS使用的主要目的是提供對(duì)網(wǎng)站服務(wù)器的身份認(rèn)證衷敌，同時(shí)保護(hù)交換數(shù)據(jù)的隱私與完整性勿侯。
PS:TLS是傳輸層加密協(xié)議，前身是SSL協(xié)議缴罗，由網(wǎng)景公司1995年發(fā)布助琐，有時(shí)候兩者不區(qū)分。

HTTPS特點(diǎn)

基于HTTP協(xié)議面氓，通過SSL加密兵钮，實(shí)現(xiàn)了數(shù)據(jù)加密，驗(yàn)證身份舌界，數(shù)據(jù)完整性保護(hù)掘譬。

• 內(nèi)容加密：采用混合加密（SSL），無法通過抓包的形式查看明文內(nèi)容呻拌。第三方無法竊聽
• 驗(yàn)證身份：通過HTTPS證書屁药，客戶端可以認(rèn)證確定訪問的是目標(biāo)服務(wù)器。
  • 對(duì)于一些使用非對(duì)稱加密的方式柏锄，很容易出現(xiàn)中間人攻擊（偽造目標(biāo)服務(wù)器，然后通過將自身的公鑰發(fā)送給客戶端用來加密的數(shù)據(jù)复亏，然后使用私鑰解密獲取數(shù)據(jù)）趾娃。
• 保護(hù)數(shù)據(jù)的完整性：可以防止傳輸?shù)膬?nèi)容被中間人冒充或者篡改。

SSL的混合加密

結(jié)合了對(duì)稱加密和非對(duì)稱加密技術(shù)缔御。
對(duì)稱加密：客戶端和服務(wù)端使用同一個(gè)密鑰解密加密抬闷。
非對(duì)稱加密技術(shù)：分為公鑰和私鑰，客戶端使用公鑰加密數(shù)據(jù)傳送給服務(wù)端耕突，服務(wù)端使用私鑰解密獲取數(shù)據(jù)笤成。
混合加密簡(jiǎn)單理解為：
1.客戶端使用對(duì)稱密鑰加密要傳輸?shù)臄?shù)據(jù)。
2.客戶端使用從服務(wù)端獲取到的公鑰加密上一步用于加密數(shù)據(jù)的對(duì)稱密鑰眷茁。
3.服務(wù)端接收到客戶端傳送過來的加密過的數(shù)據(jù)和使用公鑰加密的密鑰炕泳。那么服務(wù)端使用私鑰解密得到之前客戶端加密數(shù)據(jù)使用的密鑰，然后使用該密鑰去解密獲取數(shù)據(jù)上祈。
4.此時(shí)客戶端和服務(wù)端都獲取了用于加密數(shù)據(jù)的對(duì)稱密鑰培遵，那么后面的數(shù)據(jù)傳輸，就直接使用該對(duì)稱密鑰加密傳輸登刺。
注意：上述中說明的對(duì)稱密鑰的生成籽腕，實(shí)際上是通過了三個(gè)隨機(jī)數(shù)按照約定的算法得出的密鑰。具體的說明再后面握手階段有詳細(xì)的講解纸俭。

HTTPS中證書驗(yàn)證

非對(duì)稱加密的隱患

之前說過混合加密主要使用了一個(gè)對(duì)稱密鑰和一對(duì)公鑰和私鑰皇耗。其中公鑰和私鑰是在服務(wù)端生成的，由服務(wù)端發(fā)送給客戶端的揍很，那么其中就有一個(gè)問題了郎楼，如果確蓖蛏耍客戶端獲取的公鑰就是目標(biāo)服務(wù)器發(fā)送的，而不是中間服務(wù)器（中間人攻擊）發(fā)送給你的呢箭启？

中間人攻擊

image.png

如上圖中所示壕翩，SSL加密中是使用公鑰加密的對(duì)稱密鑰，同樣也會(huì)被中間人截獲到傅寡，所以需要確認(rèn)客戶端接收到的公鑰是來自于目標(biāo)服務(wù)器而不是其他服務(wù)器放妈。HTTPS中使用證書驗(yàn)證來確認(rèn)服務(wù)器的身份。

HTTPS證書

證書簡(jiǎn)介

SSL證書一般向權(quán)威的第三方CA機(jī)構(gòu)去請(qǐng)求頒發(fā)荐操。申請(qǐng)之后會(huì)提供給你一個(gè)證書和私鑰芜抒，私鑰直接存在服務(wù)端，證書則發(fā)送給客戶端托启，因?yàn)樽C書中有公鑰宅倒。（申請(qǐng)的方法這里不做闡述）
SSL證書中包含的內(nèi)容：

• 服務(wù)器的域名，比如www.wjsummer.top
• 證書的過期時(shí)間
• 公鑰
• 數(shù)字摘要生成的方法屯耸，比如MD5
• 使用CA機(jī)構(gòu)公鑰加密數(shù)字摘要后生成的數(shù)字簽名拐迁。

image.png

證書的驗(yàn)證

那么當(dāng)服務(wù)端將證書返回給客戶端后，客戶端就可以驗(yàn)證證書的真實(shí)性疗绣。
驗(yàn)證流程：

1. 客戶端根據(jù)證書的信息线召，確認(rèn)域名是否為請(qǐng)求的域名，是否過期等確認(rèn)證書的有效性多矮。
2. 客戶端（比如瀏覽器）根據(jù)證書的頒發(fā)機(jī)構(gòu)缓淹，選擇對(duì)應(yīng)機(jī)構(gòu)的公鑰去解密數(shù)字簽名，獲得數(shù)字摘要A塔逃。
   • 瀏覽器和操作系統(tǒng)都會(huì)維護(hù)一個(gè)權(quán)威的第三方機(jī)構(gòu)列表和它們的公鑰讯壶，那么客戶端在接收到服務(wù)端發(fā)送過來的證書后，就可以根據(jù)證書的頒發(fā)機(jī)構(gòu)找到對(duì)應(yīng)的機(jī)構(gòu)公鑰去解密證書的數(shù)字簽名獲取到數(shù)字摘要湾盗。
3. 客戶端根據(jù)證書上面的信息伏蚊，和數(shù)字摘要生成的方法，計(jì)算生成數(shù)字摘要B淹仑。
4. 對(duì)比解密得到的數(shù)字摘要A和自己生成的數(shù)字摘要B是否一致丙挽。
5. 以上都沒問題則確認(rèn)了當(dāng)前返回響應(yīng)的服務(wù)器是目標(biāo)服務(wù)器。

注：中間人攻擊對(duì)于SSL為了能夠拿到客戶端的明文數(shù)據(jù)匀借，那么就需要提供中間人自己的公鑰和私鑰颜阐，這樣就可以得到后續(xù)的對(duì)稱密鑰，從而解密從客戶端獲取的加密數(shù)據(jù)吓肋。 但是對(duì)于客戶端來說凳怨，公鑰是從證書上獲取的，那么中間人就需要偽造證書，修改上面的公鑰肤舞。 偽造的證書發(fā)送客戶端之后紫新，通過CA機(jī)構(gòu)解密對(duì)比驗(yàn)證就會(huì)發(fā)現(xiàn)不匹配，從而驗(yàn)證失敗李剖。一般會(huì)提醒用戶異常芒率，是否繼續(xù)

image.png

用于加密數(shù)據(jù)的對(duì)稱密鑰生成

前面說混合加密的基本含義時(shí)，特別說明了對(duì)稱密鑰使用了3個(gè)隨機(jī)值來生成篙顺，那么具體的過程這里進(jìn)行詳細(xì)闡述偶芍。

握手階段

SSL/TLS協(xié)議基本過程簡(jiǎn)化表示為:

1. 客戶端向服務(wù)端索要并驗(yàn)證公鑰
2. 雙方協(xié)商生成”對(duì)話密鑰“。
3. 雙方采用”對(duì)話密鑰“進(jìn)行加密通信德玫。

上述基本過程中的前兩步匪蟀，稱為握手階段。握手階段涉及到4次通信宰僧。（握手階段的所有通信都是明文的２谋搿）

第一次通信：客戶端發(fā)出請(qǐng)求

首先，客戶端向服務(wù)端發(fā)出加密通信的請(qǐng)求琴儿，這被叫做ClientHello請(qǐng)求段化。這一步，客戶端只要向服務(wù)器提供以下信息：

• 支持的協(xié)議版本造成，比如TLS 1.0版穗泵。
• 一個(gè)客戶端生成的隨機(jī)數(shù)A，稍后用于生成"對(duì)話密鑰"谜疤。
• 支持的加密方法，比如RSA公鑰加密现诀。
• 支持的壓縮方法夷磕。

第二次通信：服務(wù)端回應(yīng)

服務(wù)器收到客戶端請(qǐng)求后，向客戶端發(fā)出回應(yīng)仔沿，這叫做SeverHello坐桩。服務(wù)器的回應(yīng)包含以下內(nèi)容：

• 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本封锉。如果瀏覽器與服務(wù)器支持的版本不一致绵跷，服務(wù)器關(guān)閉加密通信。
• 一個(gè)服務(wù)器生成的隨機(jī)數(shù)B成福，稍后用于生成"對(duì)話密鑰"碾局。
• 確認(rèn)使用的加密方法，比如RSA公鑰加密奴艾。
• 服務(wù)器證書

第三次通信：客戶端回應(yīng)

客戶端在接受到服務(wù)器回應(yīng)后净当，會(huì)先驗(yàn)證證書。如果證書不是可信機(jī)構(gòu)頒發(fā)、或者證書的域名與實(shí)際域名不一致像啼、或者證書已經(jīng)過期俘闯，就會(huì)像訪問者顯示一個(gè)警告，可以選擇是否還要繼續(xù)通信忽冻。
如果證書沒有問題真朗，那么客戶端就會(huì)從證書中獲取到公鑰。然后向服務(wù)端發(fā)送如下內(nèi)容：

• 一個(gè)隨機(jī)數(shù)C僧诚。該隨機(jī)數(shù)用服務(wù)器公鑰加密遮婶，防止被竊聽。
• 編碼改變通知振诬，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送蹭睡。
• 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束赶么。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值肩豁，用來供服務(wù)器校驗(yàn)。

上面第一項(xiàng)的隨機(jī)數(shù)辫呻，是整個(gè)握手階段出現(xiàn)的第三個(gè)隨機(jī)數(shù)清钥，又稱"pre-master key"。此時(shí)客戶端和服務(wù)端同時(shí)有了三個(gè)隨機(jī)出A,B,C放闺，那么他們就可以通過商定的加密加密方法祟昭，各自生成本次會(huì)話所用的同一把”會(huì)話密鑰“。

第四次通信：服務(wù)器最后的回應(yīng)

服務(wù)器在收到客戶端發(fā)送的第三個(gè)隨機(jī)數(shù)”pre-master key“之后怖侦，計(jì)算生成本次會(huì)話所用的”會(huì)話密鑰“（對(duì)稱密鑰）篡悟。然后向客戶端發(fā)送下面的信息：

• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送匾寝。
• 服務(wù)器握手結(jié)束通知搬葬，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值艳悔，用來供客戶端校驗(yàn)急凰。

至此，整個(gè)握手階段全部結(jié)束猜年。接下來抡锈，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議了乔外，只不過使用”會(huì)話密鑰“（對(duì)稱密鑰）加密內(nèi)容床三。

HTTPS整體流程梳理

image.png

1. client向server發(fā)送請(qǐng)求htts://www.baidu.com。server監(jiān)聽443端口杨幼。
2. server從CA機(jī)構(gòu)申請(qǐng)了一套證書勿璃，包括證書（包含公鑰）和私鑰。在服務(wù)器中配置好（比如Nginx server將今天443端口配置中指定證書和私鑰路徑）。
3. server將證書返回給client补疑。
4. 客戶端根據(jù)證書的信息和證書頒發(fā)機(jī)構(gòu)的公鑰去驗(yàn)證證書的有效性和正確性歧沪。
   • 驗(yàn)證證書的域名，過期時(shí)間莲组，頒發(fā)機(jī)構(gòu)诊胞。
   • 通過CA機(jī)構(gòu)公鑰解密獲得的數(shù)字摘要和client根據(jù)證書信息和加密方法生成的數(shù)字摘要對(duì)比。
5. client和server通過握手階段（4次通信）锹杈，根據(jù)三個(gè)隨機(jī)數(shù)和雙方商定的加密方法生成會(huì)話密鑰撵孤。
   • 第三次通信，隨機(jī)數(shù)被服務(wù)端公鑰加密竭望，由client發(fā)送給服務(wù)端邪码。
6. client和sever都知道了會(huì)話密鑰，那么該次連接中傳送的數(shù)據(jù)就使用該會(huì)話密鑰進(jìn)行加密和解密咬清。

結(jié)束語

路漫漫其修遠(yuǎn)兮闭专，吾將上下而求索。

參考鏈接

SSL/TLS協(xié)議運(yùn)行機(jī)制的概述
Https如何保證了數(shù)據(jù)的安全旧烧？
HTTP和HTTPS協(xié)議影钉，看一篇就夠了