1. HTTPS 是什么

HTTP 協(xié)議內(nèi)容都是按照?本的?式明?傳輸?shù)?，這就導(dǎo)致在傳輸過程中出現(xiàn)?些被篡改的情況。HTTPS 也是?個應(yīng)?層協(xié)議，是在 HTTP 協(xié)議的基礎(chǔ)上引?了?個加密層。HTTPS的端口號是443。

它是在應(yīng)用層和傳輸層間加了一個軟件層，當(dāng)進(jìn)行網(wǎng)絡(luò)傳輸時，從上而下就是在加密，從下而上就是在解密。

2. 什么是"加密"

加密就是把明?(要傳輸?shù)男畔?進(jìn)??系列變換，?成密文。解密就是把密?再進(jìn)行一系列變換，還原成明文。在這個加密和解密的過程中，往往需要?個或者多個中間的數(shù)據(jù)， 輔助進(jìn)?這個過程。這樣的數(shù)據(jù)稱為密鑰。

為什么要加密呢？
由于我們通過?絡(luò)傳輸?shù)娜魏蔚臄?shù)據(jù)包都會經(jīng)過運(yùn)營商的?絡(luò)設(shè)備(路由器, 交換機(jī)等)，那么運(yùn)營商的?絡(luò)設(shè)備就可以解析出你傳輸?shù)臄?shù)據(jù)內(nèi)容，并進(jìn)?篡改。

假設(shè)我們要下載一個軟件，點(diǎn)擊 “下載按鈕”，其實(shí)就是在給服務(wù)器發(fā)送了?個 HTTP 請求。獲取到的 HTTP 響應(yīng)其實(shí)就包含了該APP 的下載鏈接。運(yùn)營商劫持之后，就發(fā)現(xiàn)這個請求是要下載天天動聽，那么就自動的把交給用戶的響應(yīng)給篡改成 “QQ瀏覽器” 的下載地址了。

3. 常見的加密方式

對稱加密：
采用單鑰密碼系統(tǒng)的加密方法，同?個密鑰可以同時用作信息的加密和解密。這種加密方法稱為對稱加密，也稱為單密鑰加密。特征：加密和解密所用的密鑰是相同的。特點(diǎn)：算法公開、計算量小、加密速度快、加密效率高。

非對稱加密：
需要兩個密鑰來進(jìn)行加密和解密，這兩個密鑰是公開密鑰（public key，簡稱公鑰）和私有密鑰（private key，簡稱私鑰）。特點(diǎn)：算法強(qiáng)度復(fù)雜、安全性依賴于算法與密鑰但是由于其算法復(fù)雜，而使得加密解密速度沒有對
稱加密解密的速度快。
我們可以通過公鑰對明文加密，變成密文，通過私鑰對密文解密，變成明文。
也可以通過私鑰對明?加密，變成密文，通過公鑰對密?解密，變成明?。

4. 數(shù)據(jù)摘要 && 數(shù)字簽名

數(shù)字指紋(數(shù)據(jù)摘要)，其基本原理是利用單向散列函數(shù)(Hash函數(shù))對信息進(jìn)行運(yùn)算。生成一串固定長度的數(shù)字摘要。數(shù)字指紋并不是一種加密機(jī)制，但可以用來判斷數(shù)據(jù)有沒有被竄改。

摘要特征：和加密算法的區(qū)別是，摘要嚴(yán)格意義不是加密，因?yàn)闆]有解密，只不過從摘要很難反推原信息，通常用來進(jìn)行數(shù)據(jù)對比。

數(shù)字簽名：摘要經(jīng)過加密，就得到數(shù)字簽名。

5. HTTPS 的工作過程探究

既然要保證數(shù)據(jù)安全，就需要進(jìn)行"加密"，?絡(luò)傳輸中不再直接傳輸明文了，而是加密之后的"密?"，加密的方式有很多，但是整體可以分成兩大類: 對稱加密 和 非對稱加密。

5.1 方案1 - 只使用對稱加密

如果通信雙?都各自持有同?個密鑰X，且沒有別?知道，這兩方的通信安全當(dāng)然是可以被保證的（除非密鑰被破解）。

引?對稱加密之后，即使數(shù)據(jù)被截獲， 由于?客不知道密鑰是啥，因此就?法進(jìn)?解密。

但是這里還存在一些問題：
1.客戶端和服務(wù)器雙方怎么知道對應(yīng)的密鑰是什么？
2.服務(wù)器同?時刻其實(shí)是給很多客戶端提供服務(wù)的，這么多客戶端，每個人用的秘鑰都必須是不同的(如果是相同那密鑰就太容易擴(kuò)散了，黑客就也能拿到了)。因此服務(wù)器就需要維護(hù)每個客戶端和每個密鑰之間的關(guān)聯(lián)關(guān)系，這也是個很麻煩的事情。

5.2 方案2 - 只使用非對稱加密

鑒于?對稱加密的機(jī)制，如果服務(wù)器先把公鑰以明文方式傳輸給瀏覽器，之后瀏覽器向服務(wù)器傳數(shù)據(jù)前都先?這個公鑰加密好再傳，從客戶端到服務(wù)器信道似乎是安全的(有安全問題)，因?yàn)橹挥蟹?wù)器有相應(yīng)的私鑰能解開公鑰加密的數(shù)據(jù)。

這里看起來客戶端給服務(wù)器發(fā)送數(shù)據(jù)是安全的，但是服務(wù)器給客戶端發(fā)送數(shù)據(jù)該怎么辦呢？服務(wù)器用私鑰加密，但是公鑰許多人都有，那么服務(wù)器給客戶端發(fā)送的數(shù)據(jù)就是不安全的。

5.3 方案3 - 雙方都使用非對稱加密

1.服務(wù)端擁有公鑰S與對應(yīng)的私鑰S’，客戶端擁有公鑰C與對應(yīng)的私鑰C’。
2.客戶和服務(wù)端交換公鑰。
3.客戶端給服務(wù)端發(fā)信息：先用S對數(shù)據(jù)加密，再發(fā)送，只能由服務(wù)器解密，因?yàn)橹挥蟹?wù)器有私鑰S’。
4. 服務(wù)端給客戶端發(fā)信息：先用C對數(shù)據(jù)加密，在發(fā)送，只能由客戶端解密，因?yàn)橹挥锌蛻舳擞兴借€C’。

雖然這里看起來沒問題，但還存在安全問題，并且效率太低了。

5.4 方案4 - 非對稱加密 + 對稱加密

1.服務(wù)端具有非對稱公鑰S和私鑰S’。
2.客戶端發(fā)起https請求，獲取服務(wù)端公鑰S。
3.客戶端在本地生成對稱密鑰C，通過公鑰S加密，發(fā)送給服務(wù)器。
4.由于中間的網(wǎng)絡(luò)設(shè)備沒有私鑰，即使截獲了數(shù)據(jù)，也無法還原出內(nèi)部的原文，也就無法獲取到對稱密鑰。
5.服務(wù)器通過私鑰S’解密，還原出客戶端發(fā)送的對稱密鑰C，并且使用這個對稱密鑰加密給客戶端返回的響應(yīng)數(shù)據(jù)。
6.后續(xù)客戶端和服務(wù)器的通信都只?對稱加密即可，由于該密鑰只有客戶端和服務(wù)器兩個主機(jī)知道， 其它主機(jī)/設(shè)備不知道密鑰即使截獲數(shù)據(jù)也沒有意義。

由于對稱加密的效率比非對稱加密高很多, 因此只是在開始階段協(xié)商密鑰的時候使用非對稱加密, 后續(xù)的傳輸仍然使用對稱加密。

雖然上?已經(jīng)比較接近答案了，但是依舊有安全問題，方案 2，方案 3，方案 4都存在?個問題，如果最開始，中間?就已經(jīng)開始攻擊了呢？或者把服務(wù)器發(fā)給客戶端的公鑰給修改了呢？

5.5 中間人攻擊

Man-in-the-MiddleAttack，簡稱“MITM攻擊”。

1.服務(wù)器具有非對稱加密算法的公鑰S，私鑰S’。
2.中間人具有非對稱加密算法的公鑰M，私鑰M’。
3.客戶端向服務(wù)器發(fā)起請求，服務(wù)器明文傳送公鑰S給客戶端。
4.中間人劫持?jǐn)?shù)據(jù)報文，提取公鑰S并保存好，然后將被劫持報文中的公鑰S替換成為自己的公鑰M，并將偽造報文發(fā)給客戶端。
5.客戶端收到報文，提取公鑰M(自己當(dāng)然不知道公鑰被更換過了)，自己形成對稱秘鑰C，?公鑰M加密C，形成報文發(fā)送給服務(wù)器。
6.中間人劫持后，直接用自己的私鑰M’進(jìn)行解密，得到通信秘鑰C，再用曾經(jīng)保存的服務(wù)端公鑰S加密后，將報文推送給服務(wù)器。
7.服務(wù)器拿到報文，用自己的私鑰‘S’解密，得到通信秘鑰C。
8.雙方開始采?C進(jìn)行對稱加密，進(jìn)行通信。但是一切都在中間人的掌握中，劫持?jǐn)?shù)據(jù)，進(jìn)行竊聽甚?修改，都是可以的。

問題本質(zhì)出在哪里了呢？客戶端無法確定收到的含有公鑰的數(shù)據(jù)報文，就是目標(biāo)服務(wù)器發(fā)送過來的！

5.6 引入證書

CA認(rèn)證：
服務(wù)端在使用HTTPS前，需要向CA機(jī)構(gòu)申領(lǐng)一份數(shù)字證書，數(shù)字證書里含有證書申請者信息、公鑰信息等。服務(wù)器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，證書就如身份證，證明服務(wù)端公鑰的權(quán)威性。

當(dāng)服務(wù)端申請CA證書的時候，CA機(jī)構(gòu)會對該服務(wù)端進(jìn)行審核，并專門為該網(wǎng)站形成數(shù)字簽名，過程如下：
1. CA機(jī)構(gòu)擁有非對稱加密的私鑰A和公鑰A’
2. CA機(jī)構(gòu)對服務(wù)端申請的證書明文數(shù)據(jù)進(jìn)行hash，形成數(shù)據(jù)摘要
3. 然后對數(shù)據(jù)摘要用CA私鑰A’加密，得到數(shù)字簽名S
服務(wù)端申請的證書明文和數(shù)字簽名S 共同組成了數(shù)字證書，這樣?份數(shù)字證書就可以頒發(fā)給服務(wù)端了。

客戶端進(jìn)行認(rèn)證：
當(dāng)客戶端獲取到這個證書之后, 會對證書進(jìn)行校驗(yàn)(防止證書是偽造的)。
比如：判定證書的有效期是否過期，判定證書的發(fā)布機(jī)構(gòu)是否受信任(操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu))，驗(yàn)證證書是否被篡改：從系統(tǒng)中拿到該證書發(fā)布機(jī)構(gòu)的公鑰，對簽名解密，得到?個 hash 值(稱為數(shù)據(jù)摘要)，設(shè)為 hash1。然后計算整個證書的 hash 值，設(shè)為 hash2。對比 hash1 和 hash2 是否相等。如果相等，則說明證書是沒有被篡改過的。

因?yàn)楹灻叩乃借€是CA機(jī)構(gòu)，中間人是不可能有的，如果證書的內(nèi)容被修改，那么計算出來的hash值就不一樣，則說明證書已被篡改，證書不可信。如果把數(shù)據(jù)摘要修改，那么它不能進(jìn)行加密，客戶端的公鑰打不開，說明摘要修改。

中間人能不能把整個證書掉包？
因?yàn)橹虚g人沒有CA私鑰，所以無法制作假的證書。所以中間人只能向CA申請真證書，然后用自己申請的證書進(jìn)行掉包。這個確實(shí)能做到證書的整體掉包，但是別忘記，證書明文中包含了域名等服務(wù)端認(rèn)證信息，如果整體掉包，客戶端依舊能夠識別出來。

為什么簽名不直接加密，而要先hash形成摘要？
縮小簽名密文的長度，加快數(shù)字簽名的驗(yàn)證簽名的運(yùn)算速度。

5.7 方案 5 - 非對稱加密 + 對稱加密 + 證書認(rèn)證

在客戶端和服務(wù)器剛?建立連接的時候，服務(wù)器給客戶端返回?個證書，證書包含了之前服務(wù)端的公鑰， 也包含了網(wǎng)站的?份信息。后面就是進(jìn)行我們的方案4操作。

總結(jié)：
HTTPS 工作過程中涉及到的密鑰有三組：

其實(shí)?切的關(guān)鍵都是圍繞這個對稱加密的密鑰，其它的機(jī)制都是輔助這個密鑰工作的。第?組?對稱加密的密鑰是為了讓客戶端拿到第?組?對稱加密的公鑰，第?組?對稱加密的密鑰是為了讓客戶端把對稱密鑰傳給服務(wù)器。文章來源地址http://www.zghlxwxcb.cn/news/detail-660661.html

到了這里，關(guān)于應(yīng)用層協(xié)議——https的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！