寫(xiě)在前面

最近在看了解HTTP相關(guān)的一些知識(shí)，主要在看《圖解HTTP》這本書(shū)，感覺(jué)還不錯(cuò)。所以結(jié)合自己的理解，做一下筆記。話說(shuō)之前還大概過(guò)了下《HTTP權(quán)威指南》，感覺(jué)這本書(shū)內(nèi)容過(guò)多了，不太適合新手看。新手還是建議看《圖解HTTP》。

什么是HTTPS

HTTPS(全稱：Hyper Text Transfer Protocol over Secure Socket Layer)，是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版。

HTTPS在應(yīng)用層(HTTP)和傳輸層(TCP)之間加入了一個(gè)安全層(SSL或TLS)。目的是為了解決HTTP協(xié)議的幾個(gè)缺點(diǎn)：

• 通信使用明文(不加密)，內(nèi)容可能會(huì)被竊聽(tīng)。
• 無(wú)法證明報(bào)文的完整性，所以有可能早已篡改。
• 不驗(yàn)證通信方的身份，因此有可能遭遇偽裝。

HTTPS是位于安全層之上的HTTP，這個(gè)安全層位于TCP之上

HTTP的幾個(gè)缺點(diǎn)

通信使用明文(不加密)，內(nèi)容可能會(huì)被竊聽(tīng)。

HTTP協(xié)議并沒(méi)有對(duì)通信以及數(shù)據(jù)進(jìn)行加密，是明文發(fā)送的。而我們使用HTTP請(qǐng)求的時(shí)候，數(shù)據(jù)會(huì)經(jīng)過(guò)許多個(gè)路由器，代理之類的設(shè)備，在這個(gè)過(guò)程中，只要有人在某一個(gè)環(huán)節(jié)抓取了數(shù)據(jù)包(這個(gè)操作并不難)，那這個(gè)請(qǐng)求的數(shù)據(jù)就會(huì)被看到。如果請(qǐng)求里面有一些重要的數(shù)據(jù)，比如銀行卡賬號(hào)、手機(jī)號(hào)、密碼等信息，就會(huì)有泄露的風(fēng)險(xiǎn)。

無(wú)法證明報(bào)文的完整性，所以有可能早已篡改。

由于HTTP協(xié)議無(wú)法證明通信的報(bào)文完整性，因此，在請(qǐng)求或響應(yīng)送出之后直到對(duì)方接收之前的這段時(shí)間內(nèi)，即使請(qǐng)求或響應(yīng)遭到篡改，也沒(méi)有辦法獲悉。

換句話說(shuō)，沒(méi)有任何辦法確認(rèn)，發(fā)出的請(qǐng)求/響應(yīng)和接收到的請(qǐng)求/響應(yīng)是相同的。

不驗(yàn)證通信方的身份，因此有可能遭遇偽裝。

HTTP協(xié)議的實(shí)現(xiàn)本身非常簡(jiǎn)單，不論是誰(shuí)發(fā)過(guò)來(lái)的請(qǐng)求都會(huì)返回響應(yīng)，因此不確認(rèn)通信方，會(huì)存在以下隱患：

• 無(wú)法確認(rèn)請(qǐng)求發(fā)送至目標(biāo)的Web服務(wù)器是否是按真實(shí)意圖返回響應(yīng)的那臺(tái)服務(wù)器。有可能是偽裝的Web服務(wù)器。
• 無(wú)法確認(rèn)響應(yīng)返回到的客戶端是否是按真實(shí)意圖接收響應(yīng)的那個(gè)客戶端，有可能是偽裝的客戶端。
• 無(wú)法確定正在通信的對(duì)方是否具備訪問(wèn)權(quán)限，因?yàn)槟承￤eb服務(wù)器上保存著重要的信息，只想發(fā)給特定用戶通信的權(quán)限。
• 無(wú)法判斷請(qǐng)求是來(lái)自何方，出自何手。

即使是無(wú)意義的請(qǐng)求也會(huì)照單全收。無(wú)法阻止海量請(qǐng)求下的DoS攻擊。

HTTP+加密+完整性保護(hù)+認(rèn)證=HTTPS

我們來(lái)看下HTTPS是如何解決上面的問(wèn)題的。

使用通信加密解決HTTP的明文發(fā)送問(wèn)題

不同于HTTP的明文通信，HTTPS的通信是經(jīng)過(guò)加密的。所以，就算有人在通信的過(guò)程中抓取到了數(shù)據(jù)包，因?yàn)闆](méi)有密鑰，所以無(wú)法知道數(shù)據(jù)包的具體內(nèi)容，這樣可以對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行保護(hù)。

HTTPS中，網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)(請(qǐng)求和響應(yīng))都是經(jīng)過(guò)加密的

HTTPS通信中，客戶端和服務(wù)器都會(huì)有兩個(gè)相同的通信密鑰(設(shè)為密鑰A)，客戶端發(fā)送請(qǐng)求時(shí)，會(huì)使用密鑰A對(duì)請(qǐng)求進(jìn)行加密成密文，服務(wù)器接收到請(qǐng)求之后，會(huì)使用密鑰A對(duì)請(qǐng)求內(nèi)容進(jìn)行解密，得到客戶端發(fā)送的明文，進(jìn)行處理。響應(yīng)過(guò)程也相似。

因此，在網(wǎng)絡(luò)傳輸?shù)倪^(guò)程中，因?yàn)閿?shù)據(jù)被加密了，所以就算有人獲取到了數(shù)據(jù)包，因?yàn)闆](méi)有密鑰A，所以就無(wú)法解密出數(shù)據(jù)包的內(nèi)容，看到的是一堆亂碼。

像這種加密和解密都是使用同一個(gè)密鑰的加密方式叫做對(duì)稱加密(也叫共享加密，共同擁有一個(gè)密鑰)。使用密鑰A加密的內(nèi)容，只能用密鑰A來(lái)解密，其他的密鑰都無(wú)法解密。常用的對(duì)稱加密算法有DES,3DES,AES。

還有一種加密方式叫非對(duì)稱加密(也叫公開(kāi)密鑰加密)。非對(duì)稱加密需要使用兩個(gè)密鑰，公開(kāi)密鑰(public key)和私有密鑰(private key)。公開(kāi)密鑰是公開(kāi)的，所有人都知道。私有密鑰是保密的，除了自己，不讓任何人知道。

• 使用公開(kāi)密鑰加密的數(shù)據(jù)，只有使用私有密鑰才能解密。
• 使用私有密鑰加密的數(shù)據(jù)，只有使用公開(kāi)密鑰才能解密。
• 使用摘要驗(yàn)證保證數(shù)據(jù)完整性

HTTPS不僅僅使用了對(duì)稱加密的方式，還使用了非對(duì)稱加密的方式。事實(shí)上，HTTPS通信過(guò)程中，客戶端會(huì)持有一個(gè)公鑰，服務(wù)器會(huì)持有一個(gè)私鑰。使用非對(duì)稱加密可以完成好幾個(gè)關(guān)鍵的操作。比如驗(yàn)證身份，比如協(xié)商通信的對(duì)稱密鑰，比如數(shù)據(jù)傳輸過(guò)程中加密摘要。

HTTPS中使用摘要算法來(lái)驗(yàn)證數(shù)據(jù)完整性，使用非對(duì)稱密鑰加解密摘要，使用對(duì)稱密鑰對(duì)數(shù)據(jù)進(jìn)行加解密

如上圖所示，在請(qǐng)求和響應(yīng)過(guò)程中，除了加密后的數(shù)據(jù)，還會(huì)發(fā)送一個(gè)報(bào)文摘要，通過(guò)這個(gè)摘要，可以驗(yàn)證數(shù)據(jù)是否被篡改。

拿響應(yīng)為例，

• 服務(wù)器會(huì)將明文的響應(yīng)用摘要算法計(jì)算摘要，跟數(shù)據(jù)一起發(fā)送給客戶端。
• 客戶端將接收到的響應(yīng)數(shù)據(jù)解密出來(lái)后，計(jì)算摘要。

然后客戶端會(huì)將自己計(jì)算出來(lái)的摘要跟服務(wù)器發(fā)送過(guò)來(lái)的摘要進(jìn)行對(duì)比，如果兩個(gè)是相同的，那么證明服務(wù)器發(fā)出的響應(yīng)數(shù)據(jù)跟客戶端收到的響應(yīng)數(shù)據(jù)是相同的。也就是數(shù)據(jù)是完整的，沒(méi)有丟失，也沒(méi)有遭到篡改。

但是這里的前提是，服務(wù)器發(fā)過(guò)來(lái)的摘要沒(méi)有被篡改，如果有人在篡改了數(shù)據(jù)之后，連摘要也改了，那就有點(diǎn)坑了。所以HTTTPS會(huì)使用非對(duì)稱加密對(duì)摘要進(jìn)行加密，防止摘要被篡改。

• 服務(wù)器會(huì)將明文的響應(yīng)用摘要算法計(jì)算摘要。
• 將摘要使用私鑰進(jìn)行加密，跟數(shù)據(jù)一起發(fā)送給客戶端。
• 客戶端將接收到的響應(yīng)數(shù)據(jù)解密出來(lái)后，計(jì)算摘要。
• 客戶端將接收到的摘要使用公鑰進(jìn)行解密。

然后客戶端會(huì)將自己計(jì)算出來(lái)的摘要跟解密出來(lái)的服務(wù)器發(fā)送過(guò)來(lái)的摘要進(jìn)行對(duì)比，如果兩個(gè)是相同的，那么證明服務(wù)器發(fā)出的響應(yīng)數(shù)據(jù)跟客戶端收到的響應(yīng)數(shù)據(jù)是相同的。也就是數(shù)據(jù)是完整的，沒(méi)有丟失，也沒(méi)有遭到篡改。

為什么非對(duì)稱加密可以保證服務(wù)器發(fā)送的摘要不被修改呢?

因?yàn)樗借€只有服務(wù)器有，也就是說(shuō)，只有服務(wù)器能夠使用私鑰進(jìn)行加密。而使用私鑰加密的數(shù)據(jù)，只有公鑰可以解密。換句話說(shuō)，用公鑰能夠解密出來(lái)的數(shù)據(jù)，就是使用私鑰加密過(guò)的。所以，只要客戶端使用公鑰能夠解密出來(lái)加密過(guò)的摘要，那么這個(gè)摘要就是服務(wù)器使用私鑰加密的。而且私鑰只有服務(wù)器知道，別人無(wú)法篡改加密后的摘要。

這里其實(shí)我有個(gè)疑問(wèn)，反過(guò)來(lái)，在請(qǐng)求過(guò)程中，客戶端使用公鑰加密摘要，然后服務(wù)器私有私鑰解密摘要。貌似只有證明這個(gè)摘要是使用公鑰加密的，但是，公鑰是公開(kāi)的，別人也能知道，那別人不就可以篡改這個(gè)摘要?

使用數(shù)字證書(shū)驗(yàn)證服務(wù)器的身份

HTTPS是如何確認(rèn)服務(wù)器的真實(shí)性的呢?也就說(shuō)，怎樣確認(rèn)跟客戶端通信的服務(wù)器就是我們的域名指向的服務(wù)器，而不是其他服務(wù)器冒充的?

HTTPS采用非對(duì)稱加密方式解決問(wèn)題。

服務(wù)器擁有私鑰，這個(gè)私鑰只有服務(wù)器有，所以，只要客戶端擁有服務(wù)器的公鑰，那么，當(dāng)服務(wù)器使用私鑰加密數(shù)據(jù)發(fā)送給客戶端，而客戶端能夠解密出數(shù)據(jù)，說(shuō)明公鑰和私鑰是配對(duì)的，而公鑰是對(duì)應(yīng)著我們想要的那個(gè)服務(wù)器的，所以就代表服務(wù)器是真的。

那么問(wèn)題又來(lái)了，我們?cè)趺茨玫皆摲?wù)器的公鑰呢?在客戶端內(nèi)置?怎么多網(wǎng)站，怎么看都不現(xiàn)實(shí)。

那我們就在建立連接的時(shí)候發(fā)送給客戶端。

嗯，HTTPS就是這么做的。

不對(duì)，那發(fā)送公鑰的時(shí)候，公鑰也可能被篡改啊，要是被篡改成其他服務(wù)器的公鑰，以后就是跟其他冒充的服務(wù)器通信了，那怎么玩?

嗯，HTTPS引入了權(quán)威的第三方機(jī)構(gòu)來(lái)確保這個(gè)公鑰確實(shí)是該服務(wù)器的。

如果要使用HTTPS，服務(wù)器管理人員需要向CA(權(quán)威的證書(shū)頒發(fā)機(jī)構(gòu))購(gòu)買(mǎi)證書(shū)。CA會(huì)將該服務(wù)器的域名、公鑰、公司信息等內(nèi)容封裝到證書(shū)中。并且使用CA自己的私鑰對(duì)證書(shū)進(jìn)行簽名。那么，服務(wù)器將證書(shū)發(fā)給客戶端，客戶端如果驗(yàn)證出證書(shū)是有效的，并且證書(shū)的域名跟目前通信的域名一致，那么這個(gè)證書(shū)里面的公鑰就是有效的。而且當(dāng)前是域名指向的服務(wù)器的公鑰。所以，我們就能確保拿到的公鑰是真的了。

嗯，這個(gè)CA機(jī)構(gòu)頒發(fā)的證書(shū)就叫做數(shù)字證書(shū)。

問(wèn)題又來(lái)了，客戶端如何驗(yàn)證服務(wù)器發(fā)過(guò)來(lái)證書(shū)是有效的呢?

證書(shū)上有CA用其私鑰做的簽名，而一般客戶端都會(huì)內(nèi)置這些權(quán)威機(jī)構(gòu)(CA)的公鑰的，所以能夠直接拿到CA的公鑰對(duì)證書(shū)上的簽名進(jìn)行解密，然后自己根據(jù)證書(shū)上的說(shuō)明計(jì)算摘要，兩個(gè)摘要一致的話，代表證書(shū)是有效。因?yàn)橹挥蠧A自己才有私鑰，別人是不可能冒充這個(gè)簽名的。

說(shuō)了那么多，HTTPS在連接建立時(shí)會(huì)發(fā)給客戶端一個(gè)數(shù)字證書(shū)，客戶端驗(yàn)證了數(shù)字證書(shū)之后，就能確認(rèn)服務(wù)器的身份。同時(shí)還可以用數(shù)字證書(shū)上的公鑰加密隨機(jī)生成的共享密鑰A，與服務(wù)器協(xié)商接下來(lái)通信過(guò)程中加密數(shù)據(jù)所用的共享密鑰A。

HTTPS握手過(guò)程

HTTPS握手過(guò)程

SSL 協(xié)議既用到了公鑰加密技術(shù)又用到了對(duì)稱加密技術(shù)，對(duì)稱加密技術(shù)雖然比公鑰加密技術(shù)的速度快，可是公鑰加密技術(shù)提供了更好的身份認(rèn)證技術(shù)。SSL 的握手協(xié)議非常有效的讓客戶和服務(wù)器之間完成相互之間的身份認(rèn)證，其主要過(guò)程如下：

①客戶端向服務(wù)器請(qǐng)求HTTPS連接。

客戶端向服務(wù)器傳送客戶端SSL 協(xié)議的版本號(hào)，加密算法的種類，產(chǎn)生的隨機(jī)數(shù)，以及其他服務(wù)器和客戶端之間通訊所需要的各種信息。

②服務(wù)器確認(rèn)并返回證書(shū)。

服務(wù)器向客戶端傳送SSL 協(xié)議的版本號(hào)，加密算法的種類，隨機(jī)數(shù)以及其他相關(guān)信息，同時(shí)服務(wù)器還將向客戶端傳送自己的證書(shū)。

③客戶端驗(yàn)證服務(wù)器發(fā)來(lái)的證書(shū)。

客戶端利用服務(wù)器傳過(guò)來(lái)的信息驗(yàn)證服務(wù)器的合法性，服務(wù)器的合法性包括：證書(shū)是否過(guò)期，發(fā)行服務(wù)器證書(shū)的CA 是否可靠，發(fā)行者證書(shū)的公鑰能否正確解開(kāi)服務(wù)器證書(shū)的“發(fā)行者的數(shù)字簽名”，服務(wù)器證書(shū)上的域名是否和服務(wù)器的實(shí)際域名相匹配。如果合法性驗(yàn)證沒(méi)有通過(guò)，通訊將斷開(kāi);如果合法性驗(yàn)證通過(guò)，將繼續(xù)進(jìn)行第四步。

④信息驗(yàn)證通過(guò)，客戶端生成隨機(jī)密鑰A，用公鑰加密后發(fā)給服務(wù)器。

從第③步驗(yàn)證過(guò)的證書(shū)里面可以拿到服務(wù)器的公鑰，客戶端生成的隨機(jī)密鑰就使用這個(gè)公鑰來(lái)加密，加密之后，只有擁有該服務(wù)器(持有私鑰)才能解密出來(lái)，保證安全。

⑤服務(wù)器用私鑰解密出隨機(jī)密鑰A，以后通信就用這個(gè)隨機(jī)密鑰A來(lái)對(duì)通信進(jìn)行加密。

我們這個(gè)握手過(guò)程并沒(méi)有將驗(yàn)證客戶端身份的邏輯加進(jìn)去。因?yàn)樵诖蠖鄶?shù)的情況下，HTTPS只是驗(yàn)證服務(wù)器的身份而已。如果要驗(yàn)證客戶端的身份，需要客戶端擁有證書(shū)，在握手時(shí)發(fā)送證書(shū)，而這個(gè)證書(shū)是需要成本的。