什么是 HTTPS ?

不管是使用手機(jī)還是電腦上網(wǎng)，都離不開數(shù)據(jù)的通訊

現(xiàn)在互聯(lián)網(wǎng)上傳輸數(shù)據(jù)，普遍使用的是超文本傳輸協(xié)議，即 HTTP (HyperText Transfer Protocol)

所以，我們以前在上網(wǎng)的時(shí)候，會(huì)發(fā)現(xiàn)所有的網(wǎng)址都有一個(gè) http:// 前綴：

HTTP 協(xié)議

簡(jiǎn)單而言，HTTP 協(xié)議定義了一套規(guī)范，讓客戶端或?yàn)g覽器可以和服務(wù)器正常通信，完成數(shù)據(jù)傳輸

但是，HTTP 使用明文傳輸，比如你輸入賬號(hào)/密碼提交登錄：

明文傳輸

很有可能被中間人竊聽，從而造成數(shù)據(jù)泄露，所以說 HTTP 是不安全的，現(xiàn)代瀏覽器會(huì)在地址欄提示連接不安全：

火狐瀏覽器安全提示

為了解決安全傳輸?shù)膯栴}，人們發(fā)明了 HTTPS，即 HTTP + Secure

為什么 HTTPS 是安全的？

只要把傳輸?shù)臄?shù)據(jù)加密，那么通信就是安全的，前提是除通信雙方外，任何第三方無法解密：

加密傳輸

在上圖示例中，通信的數(shù)據(jù)經(jīng)過加密，即使被中間人竊聽到了，它也無法知道數(shù)據(jù)內(nèi)容

火狐瀏覽器安全提示

HTTPS 是怎么實(shí)現(xiàn)安全通信的？

加密傳輸確實(shí)安全，但是客戶端把數(shù)據(jù)加密后，服務(wù)器怎么解密呢？又怎樣保證中間人竊聽到密文后無法解密呢？

答案是：使用對(duì)稱加密技術(shù)

什么是對(duì)稱加密？
簡(jiǎn)單而言，通信雙方各有一把相同的鑰匙（所謂對(duì)稱），客戶端把數(shù)據(jù)加密鎖起來后，傳送給服務(wù)器，服務(wù)器再用鑰匙解密。同理，服務(wù)器加密后傳輸給客戶端的數(shù)據(jù)，客戶端也可以用鑰匙解密

那么，新的問題又出現(xiàn)了：怎樣在通信之前，給雙方分配兩把一樣的鑰匙呢？

如果真的只有兩個(gè)人要通信的話，可以簡(jiǎn)單的私下見個(gè)面分配好，以后要通信的時(shí)候用就行。但是，實(shí)際通信往往是一個(gè)服務(wù)器和成千上萬(wàn)的客戶端之間，總不能讓每個(gè)人都和服務(wù)器先私下見個(gè)面

另外，即使使用了對(duì)稱加密技術(shù)，如果一方保管不善的話，也有可能鑰匙被人偷了去復(fù)制一個(gè)，這樣就存在很大的安全隱患，最好是每個(gè)客戶端每次和服務(wù)器通信都用不同的密鑰

一個(gè)簡(jiǎn)單的解決方案是：客戶端在每次請(qǐng)求通信之前，先和服務(wù)器協(xié)商，通過某種辦法，產(chǎn)生只有雙方知道的對(duì)稱密鑰

這個(gè)過程就是所謂：密鑰交換(Key Exchange)

密鑰交換算法有很多種實(shí)現(xiàn)，常見的有：

• Deffie-Hellman 密鑰交換算法
• RSA 密鑰交換算法

本文以較簡(jiǎn)單的 RSA 密鑰交換為例

簡(jiǎn)單而言，RSA 密鑰交換算法需要客戶端向服務(wù)器提供一個(gè) Pre-Master-Key，然后通信雙方再生成 Master-Key，最后根據(jù) Master-Key 產(chǎn)生后續(xù)一系列所需要的密鑰，包括傳輸數(shù)據(jù)的時(shí)候使用的對(duì)稱密鑰

那么，客戶端怎么把 Pre-Master-Key 告訴服務(wù)器呢？直接明文傳輸么？

我們之前說過，沒加密的通信都會(huì)被竊聽，是不安全的

似乎進(jìn)入死循環(huán)了：為了加密通信，需要先把 Pre-Master-Key 傳送給服務(wù)器，但是這個(gè)傳送又必須要加密

我們引入一種新的加密技術(shù)：非對(duì)稱加密

什么是非對(duì)稱加密？
簡(jiǎn)單而言，服務(wù)器可以生成一對(duì)不同的密鑰（所謂非對(duì)稱），一把私自保存，稱為私鑰；一把向所有人公開，稱為公鑰
這對(duì)密鑰有這樣的性質(zhì)：公鑰加密后的數(shù)據(jù)只有私鑰能解密，私鑰加密后的數(shù)據(jù)只有公鑰能解密
非對(duì)稱加密的一種經(jīng)典實(shí)現(xiàn)叫 RSA 算法，這種加密算法最早 1977 年由羅納德·李維斯特（Ron Rivest）、阿迪·薩莫爾（Adi Shamir）和倫納德·阿德曼（Leonard Adleman）一起提出的，RSA 就是他們?nèi)诵帐祥_頭字母拼在一起組成的

有了非對(duì)稱加密的技術(shù)后，事情就好辦了：

客戶端把 Pre-Master-Key 用服務(wù)器的公鑰加密后，傳送給服務(wù)器

因?yàn)橹挥蟹?wù)器才有私鑰，所以只有服務(wù)器才能解密數(shù)據(jù)，獲取客戶端發(fā)送來的 Pre-Master-Key

具體的交互過程：

客戶端向服務(wù)器索取公鑰 PublicKey；

服務(wù)器將公鑰發(fā)給客戶端（這里沒有保密需求，因?yàn)楣€是向所有人公開的）；

客戶端使用服務(wù)器的公鑰 PublicKey 把 Pre-Master-Key 加密成密文，傳送給服務(wù)器；

服務(wù)器用私鑰 PrivateKey 解密密文，獲取到客戶端發(fā)送的 Pre-Master-Key;

看起來很完美，但是第 2 步驟又引發(fā)了一個(gè)新問題：

由于互聯(lián)網(wǎng)是公開的，服務(wù)器發(fā)送給客戶端的公鑰可能在傳送過程中被中間人截獲并篡改（所謂中間人攻擊 Man-in-the-middle attack，縮寫：MITM）

中間人攻擊

因?yàn)橹虚g人也可以生成一對(duì)非對(duì)稱密鑰，它會(huì)截獲服務(wù)器發(fā)送的公鑰，然后把它自己的公鑰 MiddleMan-PublicKey 發(fā)送給客戶端，進(jìn)行欺騙

可憐我們的客戶端，竟然信以為真！然后傻乎乎的把自己的 Pre-Master-Key 用 MiddleMan-PublicKey 加密后，發(fā)給中間人

怎么解決這個(gè)問題？

問題等價(jià)于：客戶端怎么確定收到的公鑰，真的就是服務(wù)器的公鑰？

想一想你乘高鐵、坐飛機(jī)的時(shí)候，怎么向工作人員證明你是你

答案很簡(jiǎn)單，到公安局（權(quán)威機(jī)構(gòu) 英文名：Authority）出個(gè)身份證明（Certificate）

身份證上記載了你的號(hào)碼、姓名、年齡、照片、住址，還有簽發(fā)機(jī)關(guān)、有效期等

所以，服務(wù)器也想辦法到權(quán)威機(jī)構(gòu) (Authority) 辦一張證書 Certificate，上面記載了服務(wù)器的域名、公鑰、所屬單位，還有簽發(fā)機(jī)關(guān)、有效期等

當(dāng)客戶端收到服務(wù)器發(fā)過來的證書后，只要證書不是偽造的，那么上面記載的公鑰肯定也就是真的！

證書長(zhǎng)啥樣？
點(diǎn)擊 IE 瀏覽器上的小鎖就可以查看服務(wù)器的證書

查看證書

不過，這里又有個(gè)新問題：怎么證明證書不是偽造的？

我們介紹一種防偽手段：簽名（Signature）

什么是簽名？
我們?cè)谏睢⒐ぷ鬟^程中，經(jīng)常遇到需要簽名的情況：刷信用卡、簽合同等，用來證明這是本人的行為。簽名之所以可信，是因?yàn)槔碚撋厦總€(gè)人的簽名都有生理學(xué)基礎(chǔ)，別人是無法偽造的，就像你的指紋一樣

所以，只要服務(wù)器發(fā)送的證書上有權(quán)威機(jī)構(gòu) Authority 的簽名，就可以確信證書是頒發(fā)給服務(wù)器的，而不是誰(shuí)偽造的

這就相當(dāng)于，只要你的請(qǐng)假條上有領(lǐng)導(dǎo)的簽名，那么 HR 就會(huì)確信領(lǐng)導(dǎo)已經(jīng)審批同意你請(qǐng)假了

如果說人類簽名使用紙筆，那么計(jì)算機(jī)的數(shù)字化簽名怎么實(shí)現(xiàn)呢？

答案是使用非對(duì)稱加密技術(shù)：

數(shù)字證書認(rèn)證機(jī)構(gòu)（Certificate Authority，簡(jiǎn)稱 CA）生成一對(duì)公/私鑰；

服務(wù)器將自己的域名、公鑰等信息提交給 CA 審查；

CA 審查無誤，使用私鑰把服務(wù)器信息的摘要加密，生成的密文就是所謂簽名（Signature）；

CA 把服務(wù)器的信息、簽名、有效期等信息集合到一張證書上，頒發(fā)給服務(wù)器；

客戶端收到服務(wù)器發(fā)送的證書后，使用 CA 的公鑰解密簽名，獲得服務(wù)器信息的摘要，如果和證書上記錄的服務(wù)器信息的摘要一致，說明服務(wù)器信息是經(jīng)過 CA 認(rèn)可的

什么是信息摘要？
簡(jiǎn)單來說，就是一段任意長(zhǎng)的數(shù)據(jù)，經(jīng)過信息摘要處理后，可以得到一段固定長(zhǎng)度的數(shù)據(jù)，比如 32 字節(jié)，只要原始數(shù)據(jù)有任意變動(dòng)，生成的信息摘要都不一樣

但是，在第5步驟又有一個(gè)新問題：客戶端怎么知道 CA 的公鑰？

答案：與生俱來

世界上的根 CA 就那么幾家，瀏覽器或者操作系統(tǒng)在出廠的時(shí)候，已經(jīng)內(nèi)置了這些機(jī)構(gòu)的自簽名證書，上面記錄他們的公鑰信息，你也可以在需要的時(shí)候手動(dòng)安裝 CA 證書

以 Windows 系統(tǒng)為例：

系統(tǒng)信任的根證書

至此，HTTPS 通信過程已經(jīng)很明朗了：

操作系統(tǒng)/瀏覽器 自帶了 CA 根證書；

客戶端因此可以驗(yàn)證服務(wù)器發(fā)送的證書真實(shí)性，從而獲取到服務(wù)器的公鑰；

有了服務(wù)器的公鑰，客戶端就可以把 Pre-Master-Key 傳送給服務(wù)器；

服務(wù)器獲取到 Pre-Master-Key 后，通過后續(xù)產(chǎn)生的對(duì)稱密鑰，就可以和客戶端加密通信了。

總結(jié)

本文簡(jiǎn)述了 HTTPS 通訊過程的基本原理，涉及到了對(duì)稱加密、非對(duì)稱加密、信息摘要、簽名、密鑰交換等技術(shù)基礎(chǔ)，以及發(fā)行機(jī)構(gòu)、數(shù)字證書等概念

具體的 HTTPS 實(shí)現(xiàn)細(xì)節(jié)還要復(fù)雜得多，這里并沒有展開講，但是并不影響對(duì) HTTPS 不熟悉的讀者對(duì)原理有基本的認(rèn)知

參考文獻(xiàn)

• 傳輸層安全協(xié)議規(guī)范 tools.ietf.org/html/rfc524…
• HTTPS 連接前的幾毫秒發(fā)生了什么 www.moserware.com/2009/06/fir…
• 查看 Windows 系統(tǒng)根證書 technet.microsoft.com/zh-cn/libra…

還有問題？ 聯(lián)系作者微博/微信 @Ceelog

總結(jié)

以上是生活随笔為你收集整理的看完你就知道什么是 HTTPS 了的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。