作者：銳銳愛籃球

前言

HTTP協(xié)議作為網(wǎng)絡(luò)通信的主要協(xié)議，本身具有很多優(yōu)點(diǎn)，但是同時(shí)，HTTP本身也存在缺陷和不足，主要表現(xiàn)在下面幾個(gè)方面：

（1）使用明文通信

（2）不驗(yàn)證通信雙方的身份

（3）對(duì)報(bào)文的完整性不做驗(yàn)證

這些不足在其他沒進(jìn)行加密的網(wǎng)絡(luò)通信協(xié)議上也存在，而在互聯(lián)網(wǎng)交換數(shù)據(jù)時(shí)，數(shù)據(jù)要經(jīng)歷復(fù)雜的網(wǎng)絡(luò)鏈路和設(shè)備才能到達(dá)對(duì)方，所以網(wǎng)絡(luò)通信的安全顯得尤其重要。而HTTPS協(xié)議則是在HTTP協(xié)議上加入了加密、認(rèn)證和數(shù)據(jù)完整性校驗(yàn)的協(xié)議。

信息傳輸四大主要安全問題

（1）如果信息以明文傳輸，則在傳輸過程中會(huì)被竊聽。

（2）假冒：由于通信雙方事先沒有確認(rèn)對(duì)方的真實(shí)身份，而直接進(jìn)行通信，那么就有可能向非目標(biāo)方發(fā)送了自己的信息，這種情況為假冒。

（3）篡改：由于沒有對(duì)數(shù)據(jù)進(jìn)行完整性校驗(yàn)，所以在傳輸?shù)倪^程中可能被中間人篡改，而拿到非預(yù)期的數(shù)據(jù)。

（4）事后抵賴：假如發(fā)送方對(duì)接收方有惡意，那么可以發(fā)送一個(gè)錯(cuò)誤的信息，因?yàn)闆]有對(duì)消息的來源進(jìn)行驗(yàn)證和識(shí)別，所以事后發(fā)送方可以說這些信息并不是他發(fā)出的，這導(dǎo)致很多金融交易，合同簽署無法在互聯(lián)網(wǎng)完成。

而解決這四大存在的安全問題，需要用到很多安全相關(guān)的算法，而這些算法都是HTTPS協(xié)議的基石。

對(duì)稱加密和非對(duì)稱加密

為了解決在信息傳輸過程中的“竊聽”問題，我們首先想到的是對(duì)數(shù)據(jù)進(jìn)行加密，而加密類型有對(duì)稱加密和非對(duì)稱加密兩種。

（1）對(duì)稱加密：加密和解密都使用相同的密鑰，常用的算法有AES，DES，三重DES等算法。我們主要關(guān)注對(duì)稱加密的信息傳遞過程。

舉個(gè)例子：假如你和阿諾德需要進(jìn)行通信，而存在竊聽者伊芙，但是你和阿諾德都知道你的門牌號(hào)是322，這個(gè)就是你和阿諾德的共享密鑰，你要把7這個(gè)數(shù)字告訴對(duì)方，你就說，阿諾德，我要告訴你的數(shù)字是，這個(gè)數(shù)字加上我的門牌號(hào)是329，那么阿諾德知道你的門牌號(hào)是322，那么329 - 322 = 7，順利得到解密后的數(shù)據(jù)7，但是伊芙不知道你的門牌號(hào)是多少，所以他只能知道加密后的329，卻無法知道原始的信息是多少。這也就是對(duì)稱加密在信息傳遞過程中的作用，在對(duì)稱加密中，只有通信雙方知道密鑰，所以信息傳遞是安全的。

但是上述例子的前提是雙方都知道了共享密鑰，而實(shí)際通信過程中，通信雙方都是不知道密鑰的，所以在數(shù)據(jù)通信之前，需要發(fā)送方將密鑰發(fā)送給接收方，但是發(fā)送的密鑰會(huì)被中間人竊取，可以用新的密鑰加密通信密鑰，但是新的密鑰又如何安全發(fā)送到接收方那里呢？所以單純的對(duì)稱加密算法產(chǎn)生的“密鑰分配問題”，也就是如何把密鑰安全送到對(duì)方手上的問題。

（2）非對(duì)稱加密：加密和解密用的是不同的密鑰，用于加密的密鑰叫公鑰，用于解密的密鑰叫私鑰。非對(duì)稱加密主要有RSA算法，橢圓曲線加密算法等。

通信的過程：A和B進(jìn)行通信，B首先選擇一種非對(duì)稱加密算法，生成公鑰和私鑰，然后把公鑰發(fā)送給A，A使用公鑰對(duì)數(shù)據(jù)進(jìn)行加密，再把加密后的數(shù)據(jù)發(fā)送給B，然后B拿到數(shù)據(jù)后使用私鑰進(jìn)行加密。在通信的過程中，中間人可以拿到公鑰和加密后的數(shù)據(jù)，但是由于沒有私鑰，無法對(duì)數(shù)據(jù)進(jìn)行解密。

非對(duì)稱加密存在的問題：在上述例子中，有個(gè)前提，就是公鑰確定是B發(fā)送的，但是實(shí)際中，如何判定公鑰的來源是最大的問題，如下圖所示

A，B進(jìn)行通信，存在中間人X，B用非對(duì)稱加密算法生成自己的私鑰Sb和公鑰Pb，X也用某種非對(duì)稱加密算法生成自己的公鑰Px，私鑰Sx，在B向A發(fā)送公鑰的時(shí)候，X進(jìn)行中間攔截，把A的公鑰替換成自己的公鑰Px，而A拿到了公鑰，但是不知道這公鑰是誰的，于是A用X的公鑰Px對(duì)數(shù)據(jù)加密后發(fā)送給B，這時(shí)候，X攔截了發(fā)送的數(shù)據(jù)，用自己的私鑰Sx進(jìn)行解密，獲得了數(shù)據(jù)，同時(shí)用B的公鑰加密了數(shù)據(jù)后發(fā)送給B，整個(gè)過程中，X架在了A和B中間，攔截公鑰和數(shù)據(jù)，同時(shí)替換公鑰，悄無聲息竊取數(shù)據(jù)，而A，B對(duì)此渾然不知。因?yàn)锳拿到了公鑰進(jìn)行加密，而B則可以用自己的私鑰對(duì)數(shù)據(jù)進(jìn)行解密，所以非對(duì)稱加密在網(wǎng)絡(luò)信息傳輸中無法抵御“中間人攻擊”。

同時(shí)，和對(duì)稱加密相比，非對(duì)稱加密算法加密和解密都比較耗時(shí)，無法對(duì)大量的零散數(shù)據(jù)進(jìn)行加密解密，會(huì)極大消耗性能，所以需要平衡對(duì)稱加密和非對(duì)稱加密的使用。

迪菲—赫爾曼密鑰交換算法，用明信片方式傳輸秘密

無論是對(duì)稱加密還是非對(duì)稱加密，他們存在的問題都是，如何在通信雙方安全交換密鑰的問題。感謝迪菲-赫爾曼算法，讓我們可以安全的共享密鑰。

用一個(gè)顏料的例子來理解這個(gè)算法。我們假設(shè)在一個(gè)房間里， 有你，阿諾德，伊芙三個(gè)人，你想和阿諾德通信，不想讓伊芙知道，這時(shí)候，房間里有很多不同顏色的顏料，而顏料可以進(jìn)行任意的混合，但是顏料混合之后則不能分開，而每種顏色的顏料就是通信的密鑰（單獨(dú)顏色和混合后的顏色）。

（1）首先，你和阿諾德先各自選擇一種顏料，只有自己知道（通信雙方各自有自己的私鑰）

（2）選擇一種新的不同的顏色進(jìn)行公開，這種顏色和你們選擇的私有顏色都不同（發(fā)布公鑰）

（3）你和阿諾德分別把公共的顏料和自己的私有顏料進(jìn)行混合，創(chuàng)造出新的顏料

（4）你和阿諾德互相交換公用-私有混合顏料

到了這一步，你和阿諾德都可以用雙方的私人顏料和公開的顏料混合后的顏料作為密鑰進(jìn)行加密通信，而中間人伊芙由于不能分開顏料，無法拿到通信雙方的密鑰，所以無法進(jìn)行中間人攻擊。

繼續(xù)進(jìn)行圖解

（1）算法基礎(chǔ)

（2）通信雙方密鑰準(zhǔn)備

通信雙方 A 和 B 先生稱自己私有密鑰 Sa 和 Sb，同時(shí)發(fā)送方 A 選擇一個(gè)公鑰P，發(fā)送給B，公鑰即使被竊取也無所謂，同時(shí)A 使用公鑰P和自己的私鑰Sa, 合成新的密鑰PSa，B在拿到公鑰P之后也合成新的密鑰PSb

（3）交換生成的新密鑰

通信雙方互相交換在第二步中生成的密鑰，這個(gè)新生成的密鑰即使被竊取也無所謂，拿到對(duì)方的密鑰后，把拿到的密鑰和自己的私有密鑰進(jìn)行混合，產(chǎn)生新的密鑰PSaSb，由于和順序無關(guān)，所以生成的密鑰一定相同。

而中間人X，可以拿到的是公鑰P，以及雙方生成的密鑰，但是由于無法解開合成的密鑰，也不知道雙方的私鑰，所以中間人X無法破解加密的信息。

通過迪菲-赫爾曼算法通過交換公用信息生成安全密鑰，可以防止數(shù)據(jù)被竊聽。 但是這個(gè)算法解決不了數(shù)據(jù)被惡意篡改，假冒以及事后抵賴的問題。而要解決后面的問題，就需要用到數(shù)字簽名。

數(shù)字簽名與數(shù)字證書

1. 數(shù)字簽名

在上面講述的非對(duì)稱加密算法中，由接收方生成公鑰和私鑰，然后發(fā)送方用公鑰進(jìn)行加密，接收方用私鑰進(jìn)行解密，而數(shù)字簽名的生成則相反，由發(fā)送方生成公鑰和私鑰，發(fā)送方用私鑰進(jìn)行加密，而接收方用公鑰進(jìn)行解密。流程如下圖：

發(fā)送方生成了公鑰P和私鑰S，在發(fā)送數(shù)據(jù)之前，用私鑰S對(duì)數(shù)據(jù)進(jìn)行加密，加密后的數(shù)據(jù)就是數(shù)據(jù)簽名，將數(shù)據(jù)和數(shù)據(jù)簽名同時(shí)發(fā)送給接收方B，B在拿到數(shù)據(jù)和數(shù)字簽名之后，先用公鑰P解密數(shù)字簽名，獲得內(nèi)容，再和內(nèi)容進(jìn)行對(duì)比，看和收到的消息是否一致。如果收到的消息不一致，那么接收方判定這個(gè)接收不合法，，會(huì)讓發(fā)送方重新發(fā)送數(shù)據(jù)。

為什么使用反向的非對(duì)稱加密可以確認(rèn)發(fā)送者是否為A呢？因?yàn)閷?duì)于一個(gè)可逆的非對(duì)稱加密算法（RSA算法），能用A的公鑰解密的數(shù)據(jù)，必定是用A的私鑰加密的，也就是說，這數(shù)據(jù)必定是由A發(fā)出的，所以采用數(shù)字簽名，可以解決“來源認(rèn)證”，“篡改”，“事后抵賴”的問題。但是數(shù)字簽名有個(gè)缺陷，就是生成的公鑰上面并沒有A的信息，所以B不知道到底這個(gè)公鑰是A的還是有人冒充A發(fā)出的，而解決這個(gè)問題就必須使用數(shù)字證書。

1. 數(shù)字證書

（1）證書生成 假如發(fā)送方A要將自己的公鑰發(fā)送給B，首先他先找到證書認(rèn)證中心，去認(rèn)證自己的身份。

A自己生產(chǎn)了公鑰Pa和私鑰Sa，由證書認(rèn)證中心CA，CA 也有自己的公鑰Pc和私鑰Sc，A把自己的身份信息和公鑰Pa 發(fā)送給證書認(rèn)證中心去鑒定。

證書認(rèn)證中心會(huì)根據(jù)各種手段驗(yàn)證A的合法性，驗(yàn)證通過后，會(huì)使用自己的私鑰Sc對(duì)A的信息和公鑰Pa加密，生成數(shù)字簽名，并將這個(gè)簽名返回給A。

（2）證書驗(yàn)證 在進(jìn)行數(shù)據(jù)傳輸時(shí)，A先把CA認(rèn)證過的數(shù)字證書，還有自己的身份信息發(fā)送給B，B去CA拿公鑰進(jìn)行解密，如果能夠解密，說明證書確實(shí)是由該機(jī)構(gòu)所發(fā)的。然后解密提取里面的身份信息，和A發(fā)送過來的進(jìn)行對(duì)比，如果身份信息準(zhǔn)確無誤，那么說明里面的公鑰確實(shí)是由A所發(fā)出的，所以提取出里面的公鑰，進(jìn)行后續(xù)的操作。

有中間人攻擊冒充的情況：

X直接冒充A，給B發(fā)送了自己的公鑰，但是因?yàn)椴皇且宰C書形式發(fā)送的，所以B直接拒絕，拋棄這個(gè)公鑰。

所以X只能用自己的身份信息和公鑰去申請(qǐng)數(shù)字證書，但是因?yàn)樗麩o法獲得A的信息，所以他無法生成和A一樣的數(shù)字證書。

（3）數(shù)字證書鏈 如果我們用“套娃”的思路來看數(shù)字證書的問題，那么從數(shù)字證書CA拿到的公鑰就是合法的嗎？我們可以懷疑A的身份，我們自然可以預(yù)想CA機(jī)構(gòu)已經(jīng)被中間人攻擊了，相關(guān)的密鑰都被替換。

所以證書機(jī)構(gòu)CA的合法性需要更高級(jí)別的證書機(jī)構(gòu)來認(rèn)證，而更高級(jí)別的證書認(rèn)證機(jī)構(gòu)自然也有比它更高級(jí)別的證書機(jī)構(gòu)來認(rèn)證其合法性，而這些就構(gòu)成了數(shù)字證書鏈。

形成了一個(gè)樹狀結(jié)構(gòu)，而最頂層的就是根認(rèn)證中心，根認(rèn)證中心由其本身驗(yàn)證自己的合法性。而我們能做的就是信任證書鏈，安全的本質(zhì)就是信任的邊界，如果我們什么都不信任，那么安全也就無從談起。

從SSL握手看HTTPS協(xié)議

SSL握手的流程如下：

步驟 1：

客戶端發(fā)送請(qǐng)求報(bào)文開始 SSL 通信。報(bào)文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長(zhǎng)度等）。步驟 2~步驟4：服務(wù)器可進(jìn)行 SSL 通信應(yīng)答，發(fā)送 Certificate 報(bào)文，報(bào)文中包含公開密鑰證書，供客戶端驗(yàn)證。

步驟 5~步驟7：

SSL 第一次握手結(jié)束之后，客戶端以 Client Key Exchange 報(bào)文作為回應(yīng)。報(bào)文中包含通信加密中使用的一種被稱為 Pre-master secret 的隨機(jī)密碼串。該報(bào)文已用步驟 3 中的公開密鑰進(jìn)行加密，并提示服務(wù)器，后續(xù)使用Pre-master secret進(jìn)行數(shù)據(jù)加密。

步驟 8~步驟9：

服務(wù)器進(jìn)行應(yīng)答。

步驟 10：

服務(wù)器和客戶端的 Finished 報(bào)文交換完畢之后，SSL 連接就算建立完成。當(dāng)然，通信會(huì)受到 SSL 的保護(hù)。從此處開始進(jìn)行應(yīng)用層協(xié)議的通信，即發(fā)送 HTTP 請(qǐng)求。

步驟 11：

應(yīng)用層協(xié)議通信，即發(fā)送 HTTP 響應(yīng)。

步驟 12：

最后由客戶端斷開連接。

在步驟1中，客戶端會(huì)生成第一個(gè)隨機(jī)字符串Random1, 在步驟2服務(wù)端響應(yīng)的時(shí)候，會(huì)生成第二個(gè)隨機(jī)字符串Random2，也就是在第四步結(jié)束的時(shí)候，客戶端和服務(wù)端都擁有了兩個(gè)隨機(jī)字符串。同時(shí)在第四步結(jié)束的時(shí)候，客戶端會(huì)拿著服務(wù)端的證書去進(jìn)行校驗(yàn)，檢驗(yàn)成功，則提取其中的公鑰。提取成功之后，客戶端生成一個(gè)字符串Random3，然后用獲取到的服務(wù)端公鑰進(jìn)行加密，生成Pre-master secret，并發(fā)送給服務(wù)端。服務(wù)端在第7步結(jié)束后用私鑰對(duì)Pre-master secret進(jìn)行解密，獲取到Random3，到這步開始，客戶端和服務(wù)端都同時(shí)擁有了Random1， Random2， Random3三個(gè)隨機(jī)字符串，從而可以使用迪菲-赫爾曼算法及其變種構(gòu)建對(duì)稱加密算法的密鑰，實(shí)現(xiàn)后續(xù)HTTP通信的加密。

到此，整個(gè)HTTPS流程結(jié)束。總結(jié)就是，用對(duì)稱加密的算法對(duì)通信數(shù)據(jù)進(jìn)行加密，用非對(duì)稱加密的手段構(gòu)建證書認(rèn)證體系和對(duì)對(duì)稱加密的核心組件（隨機(jī)字符串）進(jìn)行加密，實(shí)現(xiàn)通信安全，解決網(wǎng)絡(luò)通信中“竊聽”，“假冒”，“篡改”，“事后抵賴”的問題。HTTPS可以說是安全算法的綜合應(yīng)用。