協(xié)議需求：

搞這么個協(xié)議是為了干嘛，這個協(xié)議需要具備什么樣的特性。前三點(diǎn)非常重要，也是HTTPS協(xié)議的主要作用。

1.對內(nèi)容進(jìn)行加密
建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?br> SSL/TLS協(xié)議進(jìn)行加解密，且通常采用的非對稱加密算法為RSA。
公鑰加密，私鑰解密。

2.能夠進(jìn)行身份認(rèn)證
確認(rèn)對方的真實(shí)性。
證書由受信任的數(shù)字證書認(rèn)證機(jī)構(gòu)(Certificate Authority, CA)所頒發(fā)的，就認(rèn)為對方是真的。
比如，12306官網(wǎng)的購票入口采用https協(xié)議，但其證書是由默認(rèn)不受信任的CA所頒發(fā)的，這個機(jī)構(gòu)叫SRCA，呵呵呵。

中鐵數(shù)字證書認(rèn)證中心（中鐵CA，SRCA）

你也可以手動添加它為受信任的，但是至少默認(rèn)是不受信任的。因此，在默認(rèn)情況下，Chrome會認(rèn)為這不是真正的12306官網(wǎng)的購票入口，返回錯誤為：

12306

雖然它確實(shí)是真的，但是誰讓它是個野雞CA呢。

3.能保證數(shù)據(jù)完整性
防止內(nèi)容被第三方冒充或者篡改。
數(shù)字摘要是采用單項(xiàng)Hash函數(shù)將需要加密的明文“摘要”成一串固定長度（128位）的密文，這一串密文又稱為數(shù)字指紋(fingerprint)，它有固定的長度，而且不同的明文摘要成密文，其結(jié)果總是不同的，而同樣的明文其摘要必定一致。“數(shù)字摘要“是https能確保數(shù)據(jù)完整性和防篡改的根本原因。
所以只要對內(nèi)容稍有改動，算出來的指紋就和原來的指紋不一樣了，這樣就可以知道內(nèi)容已經(jīng)被篡改過，不可信了。

4.需要具備兼容性
基于兼容性的考慮，可以得出的結(jié)論是：

• HTTPS 還是要基于 TCP 來傳輸（如果改為 UDP 作傳輸層，無論是 Web 服務(wù)端還是瀏覽器客戶端，都要大改，動靜太大了）
• 單獨(dú)使用一個新的協(xié)議，把 HTTP 協(xié)議包裹起來（所謂的“HTTP over SSL”，實(shí)際上是在原有的 HTTP 數(shù)據(jù)外面加了一層 SSL 的封裝。HTTP 協(xié)議原有的 GET、POST 之類的機(jī)制，基本上原封不動）

5.需要具備可擴(kuò)展性
前面說了，HTTPS 相當(dāng)于是“HTTP over SSL”?！　?br> 如果 SSL 這個協(xié)議在“可擴(kuò)展性”方面的設(shè)計足夠牛逼，那么它除了能跟 HTTP 搭配，還能夠跟其它的應(yīng)用層協(xié)議搭配。豈不美哉？　　
現(xiàn)在看來，當(dāng)初設(shè)計 SSL 的人確實(shí)比較牛。如今的 SSL/TLS 可以跟很多常用的應(yīng)用層協(xié)議（比如：FTP、SMTP、POP、Telnet）搭配，來強(qiáng)化這些應(yīng)用層協(xié)議的安全性。

6.需要考慮性能
為了確保性能，SSL 的設(shè)計者至少要考慮如下幾點(diǎn)：

• 如何選擇加密算法
  “對稱”or“非對稱”
• 如何兼顧 HTTP 采用的“短連接”TCP 方式
  SSL 是在1995年之前開始設(shè)計的，那時候的 HTTP 版本還是 1.0，默認(rèn)使用的是“短連接”的 TCP 方式（即，默認(rèn)不啟用 Keep-Alive）

Q&A

一些問題，答疑解惑。

1. 為什么需要身份認(rèn)證，單純用“非對稱加密算法”的風(fēng)險。

風(fēng)險就是：中間人攻擊。

• 沒有被攻擊之前，應(yīng)該是這樣的：
  第1步 網(wǎng)站服務(wù)器先基于“非對稱加密算法”，隨機(jī)生成一個“密鑰對”（為敘述方便，稱之為“k1 和 k2”）。因?yàn)槭请S機(jī)生成的，目前為止，只有網(wǎng)站服務(wù)器才知道 k1 和 k2。
  第2步 網(wǎng)站把 k1 保留在自己手中，把 k2 用【明文】的方式發(fā)送給訪問者的瀏覽器。因?yàn)?k2 是明文發(fā)送的，自然有可能被偷窺。不過不要緊。即使偷窺者拿到 k2，也【很難】根據(jù) k2 推算出 k1（這一點(diǎn)是由“非對稱加密算法”從數(shù)學(xué)上保證的）。
  第3步 瀏覽器拿到 k2 之后，先【隨機(jī)生成】第三個對稱加密的密鑰（簡稱 k）。然后用 k2 加密 k，得到 k'（k' 是 k 的加密結(jié)果）瀏覽器把 k' 發(fā)送給網(wǎng)站服務(wù)器。由于 k1 和 k2 是成對的，所以只有 k1 才能解密 k2 的加密結(jié)果。因此這個過程中，即使被第三方偷窺，第三方也【無法】從 k' 解密得到 k。
  第4步 網(wǎng)站服務(wù)器拿到 k' 之后，用 k1 進(jìn)行解密，得到 k至此，瀏覽器和網(wǎng)站服務(wù)器就完成了密鑰交換，雙方都知道 k，而且【貌似】第三方無法拿到 k。然后，雙方就可以用 k 來進(jìn)行數(shù)據(jù)雙向傳輸?shù)募用堋?/li>
• 被攻擊之后，變成這樣的了：
  第1步 這一步跟原先一樣——服務(wù)器先隨機(jī)生成一個“非對稱的密鑰對”k1 和 k2（此時只有網(wǎng)站知道 k1 和 k2）。
  第2步 當(dāng)網(wǎng)站發(fā)送 k2 給瀏覽器的時候，攻擊者截獲 k2，保留在自己手上。然后攻擊者自己生成一個【偽造的】密鑰對（以下稱為 pk1 和 pk2）。攻擊者把 pk2 發(fā)送給瀏覽器。
  第3步 瀏覽器收到 pk2，以為 pk2 就是網(wǎng)站發(fā)送的。瀏覽器不知情，依舊隨機(jī)生成一個對稱加密的密鑰 k，然后用 pk2 加密 k，得到密文的 k'瀏覽器把 k' 發(fā)送給網(wǎng)站。（以下是關(guān)鍵）發(fā)送的過程中，再次被攻擊者截獲。因?yàn)?pk1 pk2 都是攻擊者自己生成的，所以攻擊者自然就可以用 pk1 來解密 k' 得到 k然后，攻擊者拿到 k 之后，用之前截獲的 k2 重新加密，得到 k''，并把 k'' 發(fā)送給網(wǎng)站。
  第4步 網(wǎng)站服務(wù)器收到了 k'' 之后，用自己保存的 k1 可以正常解密，所以網(wǎng)站方面不會起疑心。至此，攻擊者完成了一次漂亮的偷梁換柱，而且讓雙方都沒有起疑心。
• 所以，為什么會被攻擊？
  因?yàn)槿狈?strong>可靠的身份認(rèn)證。
• 如何實(shí)現(xiàn)可靠的身份認(rèn)證。
  有兩種方式：
  1.基于某些“私密的共享信息”
  2.基于雙方都信任的“公證人”
  對于 SSL/TLS 的應(yīng)用場景，由于雙方（客戶端和服務(wù)器）通常都是互不相識的，顯然不可能采用第一種方式（私密的共享信息），而只能采用第二種方式（依賴雙方都信任的“公證人”）?！　?br> 那么，誰來充當(dāng)這個公證人？
  當(dāng)然是第三方：CA

2.基于 CA 證書進(jìn)行的密鑰交換

第1步（這是“一次性”的準(zhǔn)備工作） 網(wǎng)站方面首先要花一筆銀子，在某個 CA 那里購買一個數(shù)字證書。該證書通常會對應(yīng)幾個文件：其中一個文件包含公鑰，還有一個文件包含私鑰。此處的“私鑰”，相當(dāng)于“方案2”里面的 k1；而“公鑰”類似于“方案2”里面的 k2。網(wǎng)站方面必須在 Web 服務(wù)器上部署這兩個文件。所謂的“公鑰”，顧名思義就是可以公開的 key；而所謂的“私鑰”就是私密的 key。其實(shí)前面已經(jīng)說過了，這里再嘮叨一下：“非對稱加密算法”從數(shù)學(xué)上確保了——即使你知道某個公鑰，也很難（不是不可能，是很難）根據(jù)此公鑰推導(dǎo)出對應(yīng)的私鑰。
第2步 當(dāng)瀏覽器訪問該網(wǎng)站，Web 服務(wù)器首先把包含公鑰的證書發(fā)送給瀏覽器。
第3步 瀏覽器驗(yàn)證網(wǎng)站發(fā)過來的證書。如果發(fā)現(xiàn)其中有詐，瀏覽器會提示“CA 證書安全警告”。由于有了這一步，就大大降低了（注意：是“大大降低”，而不是“徹底消除”）前面提到的“中間人攻擊”的風(fēng)險。為啥瀏覽器能發(fā)現(xiàn) CA 證書是否有詐？因?yàn)檎?jīng)的 CA 證書，都是來自某個權(quán)威的 CA。如果某個 CA 足夠權(quán)威，那么主流的操作系統(tǒng)（或?yàn)g覽器）會內(nèi)置該 CA 的“根證書”。（比如 Windows 中就內(nèi)置了幾十個權(quán)威 CA 的根證書）因此，瀏覽器就可以利用系統(tǒng)內(nèi)置的根證書，來判斷網(wǎng)站發(fā)過來的 CA 證書是不是某個 CA 頒發(fā)的。（關(guān)于“根證書”和“證書信任鏈”的概念，請參見《數(shù)字證書及CA的掃盲介紹》）
第4步 如果網(wǎng)站發(fā)過來的 CA 證書沒有問題，那么瀏覽器就從該 CA 證書中提取出“公鑰”。然后瀏覽器隨機(jī)生成一個“對稱加密的密鑰”（以下稱為 k）。用 CA 證書的公鑰加密 k，得到密文 k'瀏覽器把 k' 發(fā)送給網(wǎng)站。
第5步 網(wǎng)站收到瀏覽器發(fā)過來的 k'，用服務(wù)器上的私鑰進(jìn)行解密，得到 k。至此，瀏覽器和網(wǎng)站都擁有 k，“密鑰交換”大功告成啦。

總結(jié)：
1.client和server之間，首先通過CA證書的公鑰/密鑰同步對稱密鑰，之后信息的傳輸用對稱密鑰進(jìn)行加解密。
2.client不會再順便接受一個公鑰了，這個公鑰必須是CA認(rèn)證的才行。所以這時中間人截獲了CA證書的公鑰就沒毛用了，就算cilent用證書公鑰加密一個k，然后發(fā)送給它，它也沒辦法解開，因?yàn)樗鼪]CA證書的私鑰。
3.所以突破口就在CA證書上了。

值得參考的鏈接

背景知識、協(xié)議的需求、設(shè)計的難點(diǎn)
https://program-think.blogspot.com/2014/11/https-ssl-tls-1.html
數(shù)字證書與認(rèn)證機(jī)構(gòu)CA
https://program-think.blogspot.com/2010/02/introduce-digital-certificate-and-ca.html
非對稱VS對稱，身份認(rèn)證
https://program-think.blogspot.com/2014/11/https-ssl-tls-2.html
詳解https是如何確保安全的
http://www.wxtlife.com/2016/03/27/%E8%AF%A6%E8%A7%A3https%E6%98%AF%E5%A6%82%E4%BD%95%E7%A1%AE%E4%BF%9D%E5%AE%89%E5%85%A8%E7%9A%84%EF%BC%9F/
相關(guān)異常javax.net.ssl.SSLHandshakeException:
http://www.itdecent.cn/p/7c1bc2daef8d