協(xié)議需求：
搞這么個協(xié)議是為了干嘛厂庇，這個協(xié)議需要具備什么樣的特性繁堡。前三點非常重要，也是HTTPS協(xié)議的主要作用伯诬。
1.對內容進行加密
建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?br>
SSL/TLS協(xié)議進行加解密檬贰，且通常采用的非對稱加密算法為RSA姑廉。
公鑰加密缺亮，私鑰解密翁涤。
2.能夠進行身份認證
確認對方的真實性。
證書由受信任的數(shù)字證書認證機構(Certificate Authority, CA)所頒發(fā)的萌踱，就認為對方是真的葵礼。
比如，12306官網(wǎng)的購票入口采用https協(xié)議并鸵，但其證書是由默認不受信任的CA所頒發(fā)的鸳粉，這個機構叫SRCA，呵呵呵园担。
中鐵數(shù)字證書認證中心（中鐵CA届谈，SRCA）
你也可以手動添加它為受信任的，但是至少默認是不受信任的弯汰。因此艰山，在默認情況下，Chrome會認為這不是真正的12306官網(wǎng)的購票入口咏闪，返回錯誤為：
雖然它確實是真的曙搬，但是誰讓它是個野雞CA呢。
3.能保證數(shù)據(jù)完整性
防止內容被第三方冒充或者篡改鸽嫂。
數(shù)字摘要是采用單項Hash函數(shù)將需要加密的明文“摘要”成一串固定長度（128位）的密文纵装，這一串密文又稱為數(shù)字指紋(fingerprint)，它有固定的長度据某，而且不同的明文摘要成密文橡娄，其結果總是不同的，而同樣的明文其摘要必定一致癣籽⊥彀Γ“數(shù)字摘要“是https能確保數(shù)據(jù)完整性和防篡改的根本原因扳还。
所以只要對內容稍有改動，算出來的指紋就和原來的指紋不一樣了橱夭，這樣就可以知道內容已經(jīng)被篡改過氨距，不可信了。
4.需要具備兼容性
基于兼容性的考慮棘劣，可以得出的結論是：
- HTTPS 還是要基于 TCP 來傳輸（如果改為 UDP 作傳輸層俏让，無論是 Web 服務端還是瀏覽器客戶端，都要大改茬暇，動靜太大了）
- 單獨使用一個新的協(xié)議首昔，把 HTTP 協(xié)議包裹起來（所謂的“HTTP over SSL”，實際上是在原有的 HTTP 數(shù)據(jù)外面加了一層 SSL 的封裝糙俗。HTTP 協(xié)議原有的 GET勒奇、POST 之類的機制，基本上原封不動）
5.需要具備可擴展性
前面說了巧骚，HTTPS 相當于是“HTTP over SSL”赊颠。
如果 SSL 這個協(xié)議在“可擴展性”方面的設計足夠牛逼劈彪，那么它除了能跟 HTTP 搭配竣蹦，還能夠跟其它的應用層協(xié)議搭配。豈不美哉沧奴？
現(xiàn)在看來痘括，當初設計 SSL 的人確實比較牛。如今的 SSL/TLS 可以跟很多常用的應用層協(xié)議（比如：FTP滔吠、SMTP纲菌、POP、Telnet）搭配疮绷，來強化這些應用層協(xié)議的安全性翰舌。
6.需要考慮性能
為了確保性能，SSL 的設計者至少要考慮如下幾點：
- 如何選擇加密算法
“對稱”or“非對稱” - 如何兼顧 HTTP 采用的“短連接”TCP 方式
SSL 是在1995年之前開始設計的矗愧，那時候的 HTTP 版本還是 1.0灶芝，默認使用的是“短連接”的 TCP 方式（即，默認不啟用 Keep-Alive）
Q&A
一些問題唉韭，答疑解惑夜涕。
1. 為什么需要身份認證，單純用“非對稱加密算法”的風險属愤。
風險就是：中間人攻擊女器。
- 沒有被攻擊之前，應該是這樣的：
第1步 網(wǎng)站服務器先基于“非對稱加密算法”住诸，隨機生成一個“密鑰對”（為敘述方便驾胆，稱之為“k1 和 k2”）涣澡。因為是隨機生成的，目前為止丧诺，只有網(wǎng)站服務器才知道 k1 和 k2入桂。
第2步 網(wǎng)站把 k1 保留在自己手中，把 k2 用【明文】的方式發(fā)送給訪問者的瀏覽器驳阎。因為 k2 是明文發(fā)送的抗愁，自然有可能被偷窺。不過不要緊呵晚。即使偷窺者拿到 k2蜘腌，也【很難】根據(jù) k2 推算出 k1（這一點是由“非對稱加密算法”從數(shù)學上保證的）。
第3步 瀏覽器拿到 k2 之后饵隙，先【隨機生成】第三個對稱加密的密鑰（簡稱 k）撮珠。然后用 k2 加密 k，得到 k'（k' 是 k 的加密結果）瀏覽器把 k' 發(fā)送給網(wǎng)站服務器金矛。由于 k1 和 k2 是成對的芯急，所以只有 k1 才能解密 k2 的加密結果。因此這個過程中绷柒，即使被第三方偷窺志于，第三方也【無法】從 k' 解密得到 k涮因。
第4步 網(wǎng)站服務器拿到 k' 之后废睦，用 k1 進行解密，得到 k至此养泡，瀏覽器和網(wǎng)站服務器就完成了密鑰交換嗜湃，雙方都知道 k，而且【貌似】第三方無法拿到 k澜掩。然后购披，雙方就可以用 k 來進行數(shù)據(jù)雙向傳輸?shù)募用堋?/li> - 被攻擊之后，變成這樣的了：
第1步 這一步跟原先一樣——服務器先隨機生成一個“非對稱的密鑰對”k1 和 k2（此時只有網(wǎng)站知道 k1 和 k2）肩榕。
第2步 當網(wǎng)站發(fā)送 k2 給瀏覽器的時候刚陡，攻擊者截獲 k2，保留在自己手上株汉。然后攻擊者自己生成一個【偽造的】密鑰對（以下稱為 pk1 和 pk2）筐乳。攻擊者把 pk2 發(fā)送給瀏覽器。
第3步 瀏覽器收到 pk2乔妈，以為 pk2 就是網(wǎng)站發(fā)送的蝙云。瀏覽器不知情，依舊隨機生成一個對稱加密的密鑰 k路召，然后用 pk2 加密 k勃刨，得到密文的 k'瀏覽器把 k' 發(fā)送給網(wǎng)站波材。（以下是關鍵）發(fā)送的過程中，再次被攻擊者截獲身隐。因為 pk1 pk2 都是攻擊者自己生成的廷区，所以攻擊者自然就可以用 pk1 來解密 k' 得到 k然后，攻擊者拿到 k 之后贾铝，用之前截獲的 k2 重新加密躲因，得到 k''，并把 k'' 發(fā)送給網(wǎng)站忌傻。
第4步 網(wǎng)站服務器收到了 k'' 之后大脉，用自己保存的 k1 可以正常解密，所以網(wǎng)站方面不會起疑心水孩。至此镰矿，攻擊者完成了一次漂亮的偷梁換柱，而且讓雙方都沒有起疑心俘种。 - 所以秤标，為什么會被攻擊？
因為缺乏可靠的身份認證宙刘。 - 如何實現(xiàn)可靠的身份認證苍姜。
有兩種方式：
1.基于某些“私密的共享信息”
2.基于雙方都信任的“公證人”
對于 SSL/TLS 的應用場景，由于雙方（客戶端和服務器）通常都是互不相識的悬包，顯然不可能采用第一種方式（私密的共享信息）衙猪，而只能采用第二種方式（依賴雙方都信任的“公證人”）〔冀
那么垫释，誰來充當這個公證人？
當然是第三方：CA
2.基于 CA 證書進行的密鑰交換
第1步（這是“一次性”的準備工作） 網(wǎng)站方面首先要花一筆銀子撑瞧，在某個 CA 那里購買一個數(shù)字證書棵譬。該證書通常會對應幾個文件：其中一個文件包含公鑰，還有一個文件包含私鑰预伺。此處的“私鑰”订咸，相當于“方案2”里面的 k1；而“公鑰”類似于“方案2”里面的 k2酬诀。網(wǎng)站方面必須在 Web 服務器上部署這兩個文件脏嚷。所謂的“公鑰”，顧名思義就是可以公開的 key料滥；而所謂的“私鑰”就是私密的 key然眼。其實前面已經(jīng)說過了，這里再嘮叨一下：“非對稱加密算法”從數(shù)學上確保了——即使你知道某個公鑰葵腹，也很難（不是不可能高每，是很難）根據(jù)此公鑰推導出對應的私鑰屿岂。
第2步 當瀏覽器訪問該網(wǎng)站，Web 服務器首先把包含公鑰的證書發(fā)送給瀏覽器鲸匿。
第3步 瀏覽器驗證網(wǎng)站發(fā)過來的證書爷怀。如果發(fā)現(xiàn)其中有詐，瀏覽器會提示“CA 證書安全警告”带欢。由于有了這一步运授，就大大降低了（注意：是“大大降低”，而不是“徹底消除”）前面提到的“中間人攻擊”的風險乔煞。為啥瀏覽器能發(fā)現(xiàn) CA 證書是否有詐吁朦？因為正經(jīng)的 CA 證書，都是來自某個權威的 CA渡贾。如果某個 CA 足夠權威逗宜，那么主流的操作系統(tǒng)（或瀏覽器）會內置該 CA 的“根證書”。（比如 Windows 中就內置了幾十個權威 CA 的根證書）因此空骚，瀏覽器就可以利用系統(tǒng)內置的根證書纺讲，來判斷網(wǎng)站發(fā)過來的 CA 證書是不是某個 CA 頒發(fā)的。（關于“根證書”和“證書信任鏈”的概念囤屹，請參見《數(shù)字證書及CA的掃盲介紹》）
第4步 如果網(wǎng)站發(fā)過來的 CA 證書沒有問題熬甚，那么瀏覽器就從該 CA 證書中提取出“公鑰”。然后瀏覽器隨機生成一個“對稱加密的密鑰”（以下稱為 k）肋坚。用 CA 證書的公鑰加密 k乡括，得到密文 k'瀏覽器把 k' 發(fā)送給網(wǎng)站。
第5步 網(wǎng)站收到瀏覽器發(fā)過來的 k'冲簿，用服務器上的私鑰進行解密粟判，得到 k。至此峦剔，瀏覽器和網(wǎng)站都擁有 k，“密鑰交換”大功告成啦角钩。
總結：
1.client和server之間吝沫，首先通過CA證書的公鑰/密鑰同步對稱密鑰，之后信息的傳輸用對稱密鑰進行加解密递礼。
2.client不會再順便接受一個公鑰了惨险，這個公鑰必須是CA認證的才行。所以這時中間人截獲了CA證書的公鑰就沒毛用了脊髓，就算cilent用證書公鑰加密一個k辫愉，然后發(fā)送給它，它也沒辦法解開将硝，因為它沒CA證書的私鑰恭朗。
3.所以突破口就在CA證書上了屏镊。
值得參考的鏈接
背景知識、協(xié)議的需求痰腮、設計的難點
https://program-think.blogspot.com/2014/11/https-ssl-tls-1.html
數(shù)字證書與認證機構CA
https://program-think.blogspot.com/2010/02/introduce-digital-certificate-and-ca.html
非對稱VS對稱而芥，身份認證
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/
相關異常javax.net.ssl.SSLHandshakeException:
http://www.reibang.com/p/7c1bc2daef8d
