最近準(zhǔn)備面試沒時(shí)間更新，之前對(duì)https 還只是停留在一個(gè)表層，于是今天繼續(xù)看了他的協(xié)議文檔。對(duì)它有個(gè)重新的認(rèn)識(shí)。

  互聯(lián)網(wǎng)上傳輸數(shù)據(jù)，普遍使用的是超文本傳輸協(xié)議，即 HTTP (HyperText Transfer Protocol)；HTTP 協(xié)議定義了一套規(guī)范，讓客戶端或?yàn)g覽器可以和服務(wù)器正常通信，完成數(shù)據(jù)傳輸。但是，HTTP 使用明文傳輸，比如你輸入賬號(hào)/密碼提交登錄。這個(gè)直接就提交給服務(wù)器了。這很可能被中間人截取。所以就出現(xiàn)了https .
   對(duì)通信數(shù)據(jù)進(jìn)行加密，即使被中間截取也無法獲取數(shù)據(jù)，加密傳輸確實(shí)安全，但是客戶端把數(shù)據(jù)加密后，服務(wù)器也是不能解密

對(duì)稱加密

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

  加入一方把這個(gè)鑰匙泄露了，我們的加密也不安全了。引出了——客戶端在每次請(qǐng)求通信之前，先和服務(wù)器協(xié)商，通過某種辦法，產(chǎn)生只有雙方知道的對(duì)稱密鑰這個(gè)就是一個(gè)秘鑰交換。通常是采取非對(duì)稱加密。

RSA 密鑰交換算法

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

簡單而言，服務(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)诵帐祥_頭字母拼在一起組成的

具體的交互過程：

客戶端向服務(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ā)送給客戶端的公鑰可能在傳送過程中被中間人截獲并篡改,因?yàn)橹虚g人也可以生成一對(duì)非對(duì)稱密鑰，它會(huì)截獲服務(wù)器發(fā)送的公鑰，然后把它自己的公鑰 MiddleMan-PublicKey 發(fā)送給客戶端，進(jìn)行欺騙

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

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

客戶端怎么確定收到的公鑰，真的就是服務(wù)器的公鑰？
當(dāng)客戶端收到服務(wù)器發(fā)過來的證書后，只要證書不是偽造的，那么上面記載的公鑰肯定也就是真的！
我們介紹一種防偽手段：簽名（Signature）

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

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

這就相當(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
，簡稱 CA
）生成一對(duì)公/私鑰；
服務(wù)器將自己的域名、公鑰等信息提交給 CA
審查；
CA
審查無誤，使用私鑰把服務(wù)器信息的摘要加密，生成的密文就是所謂簽名（Signature）；
CA
把服務(wù)器的信息、簽名、有效期等信息集合到一張證書上，頒發(fā)給服務(wù)器；
客戶端收到服務(wù)器發(fā)送的證書后，使用 CA
的公鑰解密簽名，獲得服務(wù)器信息的摘要，如果和證書上記錄的服務(wù)器信息的摘要一致，說明服務(wù)器信息是經(jīng)過 CA
認(rèn)可的

什么是信息摘要？簡單來說，就是一段任意長的數(shù)據(jù)，經(jī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é)
本文簡述了 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ī)范 https://tools.ietf.org/html/rfc5246
HTTPS 連接前的幾毫秒發(fā)生了什么 http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
查看 Windows 系統(tǒng)根證書 https://technet.microsoft.com/zh-cn/library/cc754841.aspx