講真赂毯，理解 HTTPS 這一篇就夠了

前言

本文將逐步的來還原 HTTPS 的設(shè)計過程糖赔，理解從 HTTP 到 HTTPS 的轉(zhuǎn)變中萍丐，到底都發(fā)生了些什么。

HTTP 的缺陷

首先先來說說為什么需要 HTTPS放典，也就是 HTTP 的主要不足是什么

通信使用明文(不加密)逝变，內(nèi)容可能會被竊聽
不驗證通信方的身份，因此有可能遭遇偽裝
無法證明報文的完整性奋构，所以有可能已遭篡改

通信使用明文可能被竊聽

HTTP 本身不具備加密的功能壳影，即 HTTP 報文使用明文(指未經(jīng)過加密的報文)方式發(fā)送。

所謂互聯(lián)網(wǎng)弥臼，是由能連通到全世界的網(wǎng)絡(luò)組成的宴咧。無論世界哪個角落的服務(wù)器在和客戶端通信時，在此通信線路上的某些網(wǎng)絡(luò)設(shè)備径缅、光纜掺栅、計算機等都不可能是個人的私有物，所以不排除某個環(huán)節(jié)中會遭到惡意窺視行為纳猪。

比如使用免費的抓包工具 Wireshark, 就可以獲取 HTTP 的請求和響應(yīng)報文進行分析氧卧。

加密處理防止被竊聽

目前大家正在研究的如何防止竊聽保護信息的幾種對策中，最為普及的就是加密技術(shù)兆旬。加密的對象為以下

通信加密

HTTP 協(xié)議中沒有加密機制假抄，但可以通過和 SSL(Secure Socket Layer，安全套接層)或 TLS(Transport Layer Security，安全層傳輸協(xié)議)的組合使用宿饱，加密 HTTP 的通信內(nèi)容

通常熏瞄，HTTP 直接和 TCP 通信。當(dāng)使用 SSL 時谬以，則演變成先和 SSL 通信强饮，再由 SSL 和 TCP 通信了。用 SSL 建立安全通信線路之后为黎，就可以在這條線路上進行 HTTP 通信了邮丰。

SSL 是獨立于 HTTP 的協(xié)議，所以不光是 HTTP 協(xié)議铭乾，其他運行在應(yīng)用層的 SMTP 和 Telnet 等協(xié)議均可配合 SSL 協(xié)議使用剪廉。可以說 SSL 是當(dāng)今世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全技術(shù)炕檩。

內(nèi)容的加密

由于 HTTP 協(xié)議中沒有加密機制斗蒋，那么就對 HTTP 協(xié)議傳輸?shù)膬?nèi)容本身加密。即把 HTTP 報文里所含的內(nèi)容進行加密處理笛质。

在這種情況下泉沾，客戶端需要對 HTTP 報文進行加密處理后再發(fā)送請求。

為了做到有效的內(nèi)容加密妇押，前提是要求客戶端和服務(wù)器同時具備加密和解密機制跷究。

不驗證通信方的身份就可能遭遇偽裝

在 HTTP 協(xié)議通信時，由于不存在確認(rèn)通信方的處理步驟敲霍，任何人都可以發(fā)起請求俊马。另外，服務(wù)器只要接收到請求色冀，不管對方是誰都會返回一個響應(yīng) (但也僅限于發(fā)送端的 IP 地址和端口號沒有被 Web 服務(wù)器設(shè)定限制訪問的前提下)

HTTP 協(xié)議的實現(xiàn)本身非常簡單潭袱，不論是誰發(fā)送過來的請求都會返回響應(yīng)柱嫌，因此不確認(rèn)通信方锋恬，會存在以下各種隱患

無法確定請求發(fā)送至目標(biāo)的 Web 服務(wù)器是否是按真實意圖返回響應(yīng)的那臺服務(wù)器。有可能是偽裝的 Web 服務(wù)器
無法確定響應(yīng)返回到的客戶端是否是按真實意圖接收響應(yīng)的那個客戶端编丘。有可能是偽裝的客戶端
無法確定正在通信的對方是否具備訪問權(quán)限与学。因為某些 Web 服務(wù)器上保存著重要的信息，只想發(fā)給特定用戶通信的權(quán)限
即使是無意義的請求也會照單全收嘉抓。無法阻止海量請求下的 DoS 攻擊 (Denial of Service索守，拒絕服務(wù)攻擊)

使用證書驗證身份

雖然使用 HTTP 協(xié)議無法確定通信方，但如果使用 SSL 則可以抑片。SSL 不僅提供加密處理卵佛，而且還使用了一種被稱為證書的手段，可用于確定雙方身份

證書由值得信任的第三方機構(gòu)頒發(fā)，用以證明服務(wù)器和客戶端是實際存在的截汪。另外疾牲，偽造證書從技術(shù)角度來說是異常困難的一件事。所以只要能夠確認(rèn)通信方(服務(wù)器或客戶端)持有的證書衙解，即可判斷通信方的真實意圖

通過使用證書阳柔，以證明通信方就是意料中的服務(wù)器。這對使用者個人來講蚓峦，也減少了個人信息泄露的危險性舌剂。

另外，客戶端持有證書即可完成個人身份的確認(rèn)暑椰，也可用于對 Web 網(wǎng)站的認(rèn)證環(huán)節(jié)霍转。

古往今來，三角戀的關(guān)系一直都不被看好一汽，但是在 HTTPS 的協(xié)議里谴忧，客戶端，服務(wù)器和被信賴的第三方機構(gòu)這三者的關(guān)系確實奠定一切的基礎(chǔ)角虫。

無法證明報文完整性沾谓，可能已遭篡改

所謂完整性是指信息的準(zhǔn)確度。若無法證明其完整性戳鹅，通常也就意味著無法判斷信息是否準(zhǔn)確

由于 HTTP 協(xié)議無法證明通信的報文完整性均驶，因此在請求或響應(yīng)送
出之后直到對方接收之前的這段時間內(nèi)，即使請求或響應(yīng)的內(nèi)容遭到篡改枫虏，也沒有辦法獲悉妇穴。

比如，從某個 Web 網(wǎng)站上下載內(nèi)容隶债，是無法確定客戶端下載的文件和服務(wù)器上存放的文件是否前后一致的腾它。文件內(nèi)容在傳輸途中可能已經(jīng)被篡改為其他的內(nèi)容。即使內(nèi)容真的已改變死讹，作為接收方的客戶端也是覺察不到的瞒滴。

像這樣，請求或響應(yīng)在傳輸途中赞警，遭攻擊者攔截并篡改內(nèi)容的攻擊稱為中間人攻擊(Man-in-the-Middle attack妓忍，MITM)。

雖然 HTTP 協(xié)議中有確定報文完整性的方法愧旦，但事實上并不便捷世剖、可靠。其中常用的是 MD5 和 SHA-1 等散列值校驗的方法笤虫，以及用來確認(rèn)文件的數(shù) 字簽名方法旁瘫。

可惜的是祖凫，用這些方法也依然無法百分百保證確認(rèn)結(jié)果正確。因 MD5 本身被改寫的話酬凳，用戶是沒有辦法意識到的蝙场。

為了有效防止這些弊端，有必要使用 HTTPS粱年。SSL 提供認(rèn)證和加密處理及摘要功能售滤。僅靠 HTTP 確保完整性是非常困難的，因此通過和其他協(xié)議組合使用來實現(xiàn)這個目標(biāo)台诗。

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

HTTPS 并非是應(yīng)用層的一種新協(xié)議完箩。只是 HTTP 通信接口部分用 SSL(Secure Socket Layer)和 TLS(Transport Layer Security)協(xié)議代替而已。

簡言之拉队，所謂 HTTPS弊知，其實就是身披 SSL 協(xié)議這層外殼的 HTTP

加密方法

在對 SSL 進行講解之前，我們先來了解一下加密方法粱快。

加密方法只是解決方案秩彤，我們首先要做的是理解我們的問題域——什么是安全？

A 與 B 通信的內(nèi)容事哭，有且只有 A 和 B 有能力看到通信的真正內(nèi)容

好漫雷，問題域已經(jīng)定義好了（現(xiàn)實中當(dāng)然不止這一種定義）。?對于解決方案鳍咱，很容易就想到了對消息進行加密降盹。

共享密鑰方式加密（對稱密鑰加密）

加密和解密同用一個密鑰的方式稱為共享密鑰加密(Common key crypto system)，也被叫做對稱密鑰加密谤辜。

只要這個密鑰不公開給第三者蓄坏，同時密鑰足夠安全，我們就解決了我們一開始所定問題域了丑念。因為世界上有且只有圖上的客戶端與服務(wù)器知道如何加密和解密他們之間的消息涡戳。

但是在實際的互聯(lián)網(wǎng)環(huán)境下 Web 服務(wù)器的通信模型沒有這么簡單，因為如果服務(wù)器端對所有的客戶端通信都使用同樣的對稱加密算法脯倚，無異于沒有加密渔彰。所以實際中 Web 服務(wù)器與每個客戶端使用不同的對稱加密算法

以共享密鑰方式加密（對稱密鑰加密）時必須將密鑰也發(fā)給對方。那么就會產(chǎn)生一個新的問題挠将，究竟怎樣才能安全地轉(zhuǎn)交?

在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時胳岂，如果通信被監(jiān)聽那么密鑰就可會落入攻擊者之手编整，同時也就失去了加密的意義舔稀。另外還得設(shè)法安全地保管接收到的密鑰。

發(fā)送密鑰就有被竊聽的風(fēng)險掌测，但不發(fā)送内贮，對方就不能解密产园。再說，密鑰若能夠安全發(fā)送夜郁，那數(shù)據(jù)也應(yīng)該能安全送達

公開密鑰加密（非對稱加密）

密碼學(xué)領(lǐng)域中什燕，有一種稱為“非對稱加密”的加密算法，特點是私鑰加密后的密文竞端，只要是公鑰屎即，都可以解密，但是公鑰加密后的密文事富，只有私鑰可以解密技俐。私鑰只有一個人有，而公鑰可以發(fā)給所有的人统台。

使用公開密鑰加密方式雕擂，發(fā)送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息后贱勃，再使用自己的私有密鑰進行解密井赌。利用這種方式，不需要發(fā)送用來解密的私有密鑰贵扰，也不必?fù)?dān)心密鑰被攻擊者竊聽而盜走仇穗。

另外，要想根據(jù)密文和公開密鑰戚绕，恢復(fù)到信息原文是異常困難的仪缸，因為解密過程就是在對離散對數(shù)進行求值，這并非輕而易舉就能辦到列肢。退一步講恰画，如果能對一個非常大的整數(shù)做到快速地因式分解，那么密碼破解還是存在希望的瓷马。但就目前的技術(shù)來看是不太現(xiàn)實的拴还。

HTTPS 加密機制

若密鑰能夠?qū)崿F(xiàn)安全交換，那么有可能會考慮僅使用公開密鑰加密來通信欧聘。但是公開密鑰加密與共享密鑰加密相比片林，其處理速度要慢。

所以應(yīng)充分利用兩者各自的優(yōu)勢怀骤，將多種方法組合起來用于通信费封。在交換密鑰環(huán)節(jié)使用公開密鑰加密方式，之后的建立通信交換報文階段則使用共享密鑰加密方式蒋伦。

HTTPS 采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制

公開密鑰加密處理起來比共享密鑰加密方式更為復(fù)雜弓摘，因此若在通信時使用公開密鑰加密方式，效率就很低

證明公開密鑰正確性的證書

細心的人可能已經(jīng)注意到了如果使用公開密鑰加密痕届，客戶端必須需要一開始就持有公鑰韧献，要不沒法開展加密行為啊末患，所以需要服務(wù)器端將公鑰發(fā)送給每一個客戶端。

遺憾的是锤窑，公開密鑰加密方式還是存在一些問題的璧针。那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。比如渊啰，正準(zhǔn)備和某臺服務(wù)器建立公開密鑰加密方式下的通信時探橱，如何證明收到的公開密鑰就是原本預(yù)想的那臺服務(wù)器發(fā)行的公開密鑰。既如果服務(wù)器端發(fā)送公鑰給客戶端時绘证，被中間人調(diào)包了走搁，怎么辦？

為了解決上述問題迈窟，可以使用由數(shù)字證書認(rèn)證機構(gòu)(CA私植，Certificate Authority)和其相關(guān)機關(guān)頒發(fā)的公開密鑰證書。

數(shù)字證書認(rèn)證機構(gòu)處于客戶端與服務(wù)器雙方都可信賴的第三方機構(gòu)的立場上车酣。服務(wù)器會將這份由數(shù)字證書認(rèn)證機構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端曲稼，以進行公開密鑰加密方式通信。公鑰證書也可叫做數(shù)字證書或直接稱為證書湖员。

接到證書的客戶端可使用數(shù)字證書認(rèn)證機構(gòu)的公開密鑰贫悄，對那張證書上的數(shù)字簽名進行驗證，一旦驗證通過娘摔，客戶端便可明確兩件事：

認(rèn)證服務(wù)器的公開密鑰的是真實有效的數(shù)字證書認(rèn)證機構(gòu)
服務(wù)器的公開密鑰是值得信賴的

此處認(rèn)證機關(guān)的公開密鑰必須安全地轉(zhuǎn)交給客戶端窄坦。使用通信方式時，如何安全轉(zhuǎn)交是一件很困難的事凳寺，因此鸭津，多數(shù)瀏覽器開發(fā)商發(fā)布版本時，會事先在內(nèi)部植入常用認(rèn)證機關(guān)的公開密鑰

到這里可能會感覺 HTTPS 的通信過程結(jié)束了肠缨，但是還遺漏了一個場景:

第三方機構(gòu)不可能只給你一家公司制作證書逆趋，它也可能會給中間人這樣有壞心思的公司發(fā)放證書。這樣的晒奕，中間人就有機會對你的證書進行調(diào)包闻书，客戶端在這種情況下是無法分辨出是接收的是你的證書，還是中間人的脑慧。因為不論中間人魄眉，還是你的證書，都能使用第三方機構(gòu)的公鑰進行解密闷袒。如圖

那客戶端是如何來驗證證書的呢坑律？答案是證書本身就已經(jīng)告訴客戶端怎么驗證證書的真?zhèn)巍?/p>

證書上寫著如何根據(jù)證書的內(nèi)容生成證書編號∷耍客戶端拿到證書后根據(jù)證書上的方法自己生成一個證書編號脾歇，如果生成的證書編號與證書上的證書編號相同蒋腮，那么說明這個證書是真實的淘捡。

同時藕各，為避免證書編號本身又被調(diào)包，所以使用第三方的私鑰進行加密焦除。

證書的制作如圖所示

當(dāng)客戶端拿到證書后激况，開始對證書中的內(nèi)容進行驗證，如果客戶端計算出來的證書編號與證書中的證書編號相同膘魄，則驗證通過:

以上即為 HTTPS 通信的全部過程

思路整理

為了更好地理解 HTTPS乌逐，我們來整理一下 HTTPS 的通信步驟

客戶端通過發(fā)送 Client Hello 報文開始 SSL 通信。報文中包含客戶端支持的 SSL 的指定版本创葡、加密組件(Cipher Suite)列表(所使用的加密算法及密鑰長度等)
服務(wù)器可進行 SSL 通信時浙踢，會以 Server Hello 報文作為應(yīng)答。和客戶端一樣灿渴，在報文中包含 SSL 版本以及加密組件洛波。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的。
之后服務(wù)器發(fā)送 Certificate 報文骚露。報文中包含公開密鑰證書蹬挤。
最后服務(wù)器發(fā)送 Server Hello Done 報文通知客戶端，最初階段的 SSL 握手協(xié)商部分結(jié)束棘幸。
SSL 第一次握手結(jié)束之后焰扳，客戶端以 Client Key Exchange 報文作為回應(yīng)。報文中包含通信加密中使用的一種被稱為 Pre-master secret 的隨機密碼串误续。該報文已用步驟 3 中的公開密鑰進行加密吨悍。
接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報文。該報文會提示服務(wù)器蹋嵌，在此報文之后的通信會采用 Pre-master secret 密鑰加密畜份。
客戶端發(fā)送 Finished 報文。該報文包含連接至今全部報文的整體校驗值欣尼。這次握手協(xié)商是否能夠成功爆雹，要以服務(wù)器是否能夠正確解密該報文作為判定標(biāo)準(zhǔn)。
服務(wù)器同樣發(fā)送 Change Cipher Spec 報文愕鼓。
服務(wù)器同樣發(fā)送 Finished 報文钙态。
服務(wù)器和客戶端的 Finished 報文交換完畢之后，SSL 連接就算建立完成菇晃。當(dāng)然册倒，通信會受到 SSL 的保護。從此處開始進行應(yīng)用層協(xié)議的通信磺送，即發(fā) 送 HTTP 請求驻子。
應(yīng)用層協(xié)議通信灿意，即發(fā)送 HTTP 響應(yīng)。
最后由客戶端斷開連接崇呵。斷開連接時缤剧，發(fā)送 close_notify 報文。

以上做了一些省略域慷，這步之后再發(fā)送 TCP FIN 報文來關(guān)閉與 TCP 的通信荒辕。

在以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)時會附加一種叫做 MAC(Message Authentication Code)的報文摘要犹褒。MAC 能夠查知報文是否遭到篡改抵窒，從而保護報文的完整性。

HTTPS 缺陷

HTTPS 也存在一些問題叠骑，那就是當(dāng)使用 SSL 時李皇，它的處理速度會變慢。

由于 HTTPS 還需要做服務(wù)器宙枷、客戶端雙方加密及解密處理掉房，因此會消耗 CPU 和內(nèi)存等硬件的資源
和 HTTP 通信相比，SSL 通信部分消耗網(wǎng)絡(luò)資源朦拖。而 SSL 通信部分圃阳，又因為要對通信進行處理，所以時間上又延長了

講真竖哩，理解 HTTPS 這一篇就夠了