目錄：
http有什麼弊端
http是基於tcp的應用層協議。tcp本身是沒有任何安全策略的，所以http傳輸的數據是不安全的。
https協議簡介
https在http協議技術上加入SSL層來實現安全，大致可以概括爲通過非對稱加密來約定對稱加密祕鑰。且https默認端口443
什麼是對稱加密、非對稱加密
對稱加密
採用單鑰密碼系統的加密方法，同一個密鑰可以同時用作信息的加密和解密，這種加密方法稱爲對稱加密，也稱爲單密鑰加密。
非對稱加密
對稱加密算法在加密和解密時使用的是同一個祕鑰；而非對稱加密算法需要兩個密鑰來進行加密和解密，這兩個祕鑰是公開密鑰（public key，簡稱公鑰）和私有密鑰（private key，簡稱私鑰）。
公鑰加密的數據只能有與之對應的私鑰解密
私鑰加密的數據可以被任何與之對應的公鑰解密
HTTPS原理
問題一：解決數據加密問題
通過http發送的數據都是明文，如圖：
這樣傳輸數據hello很有可能被別人掉包，我們第一時間想到的就是加密，A發送消息給B，那麼提前約定好一個對稱祕鑰S，如圖：
但實際情況是我們的網站要面向很多個用戶，如圖：
現在問題來了，這麼多個客戶端，保不齊哪個客戶端把祕鑰S泄露了，這時整個網站都是不安全的了。
於是我們想了另外一種辦法，每個客戶端都是用不同的加密算法，如圖：
但這只是我們理想的情況，實際情況是客戶端怎麼知道我用那種加密算法，分別進行協商的話如圖：
於是我們引入第二個問題：如何保證協商過程是安全的？
問題二：如何保證協商過程是安全的
我們這裏通過非對稱加密來實現，非對稱加密的公鑰每個客戶端都持有，私鑰僅服務器持有。如圖：
此時客戶端生成隨機數通過公鑰加密傳給服務器，服務器通過私鑰解密得到隨機數，至此對稱加密的祕鑰就協商好了。由此可見https通過非對稱加密實現了對稱加密算法的協商。而且每次https請求都會生成這樣的隨機數。
但是我們還要解決兩個問題：
1.客戶端公鑰哪裏來的
2.客戶端如何確認公鑰是真的
問題三：客戶端公鑰哪裏來的&客戶端如何確認公鑰是真的
實際情況是服務器會將公鑰發送給客戶端，但是又引入了一個新的問題，如果服務器能把公鑰安全的發送給客戶端，服務器也就能把對稱祕鑰發送給客戶端，那[問題二]也就不存在。所以我們在發送公鑰的過程依然面臨[問題二]類似問題，如圖：
有些同學可能會想到我再用一個私鑰(下稱私鑰2)去加密我要發送的公鑰，客戶端用公鑰2(與私鑰2對應)去解密得到我想要的公鑰，但是公鑰2又是從哪來的，如此循環下去就成了雞生蛋蛋生雞的問題。
於是我們想到一種方法，上述所謂的公鑰2私鑰2我們都用第三方的(像是兩小孩大家找老師評理一樣的道理)，第三方公鑰存在客戶端，第三方私鑰存在第三方(這個東西我們永遠獲取不到，是第三方給別人或者給自己頒發證書用的)。而且這個第三方一定是公認的。如下經過第三方的私鑰加密過的服務器公鑰我們給他起個名字：”數字證書” 這個數字證書並是實際中的數字證書，這裏僅爲了說明https假設出來的 如下圖：
如果客戶端能正確的通過第三方公鑰解密出服務端發來的公鑰證明公鑰是真的。如果客戶端無法正確解密，證明這個數字證書在傳輸途中被掉包了
如上我們解決了[問題3]，但是有面臨一個新的問題，數字證書我們可以到申請，別人也可以申請，那黑客也可以申請，而且黑客的證書也是合法的。這是就出現瞭如下問題
第三方機構頒發給我和黑客各自一份證書
客戶端認爲我和黑客的證書都是合法的
黑客劫持了我的請求，替換成他的證書搞我 - -#
於是我們需要解決問題四：同一機構頒發的不同證書被混用
問題四：同一機構頒發的不同證書被混用
要解決這個問題，必須指定證書隸屬於那個網站，一份證書只能屬於一個網站使用，當然包含二級域名。
證書完整信息包含以下幾個部分(大家可以百度具體查看每個部分的作用)：
- Issuer (證書的發佈機構)
- Valid from , Valid to (證書的有效期)
- Public key (我們要發送給客戶端的公鑰)
- Subject (證書所有者)
- Signature algorithm (簽名所使用的算法)
- Thumbprint, Thumbprint algorithm (指紋以及指紋算法)
這其中證書的所有者很關鍵，如果在用戶訪問的是a.com 但是拿回來的證書所有者是b.com，那麼瀏覽器是不信任這個證書。
好，[問題四]被解決了，我們有面臨一個新的問題，這個證書所有者被改了怎麼辦，黑客把自己的證書所有者改成了你的網站域名，然後把證書發給了用戶，又讓這些可惡的人算計了。
問題五：如何防止證書不被篡改
下意識想到的可能是我們可能想到的是每次讓客戶端到第三方那裏認證下證書的真僞，但是這樣效率是在太低了。於是我們引入新的概念：數字簽名
數字簽名步驟：
1.根據證書信息(主要是用戶名和該用戶的公鑰)通過哈希(圖示MD5，但是實際非MD5)生成信息摘要(通俗理解爲證書編號)
2.用第三方私鑰對信息摘要加密生成數字簽名
數字簽名+上邊提到數字證書的內容 = 完整的真實的數字證書
客戶端收到數字證書的驗證工作如下：
1.通過本地的第三方公鑰對摘要信息解密
2.通過數字證書中的Signature algorithm (簽名所使用的算法)對證書進行hash計算。
3.對比1和2的結果是否一致。
這裏的第三方機構其實就是CA，通過以上操作，我們已經完成了非對稱加密實現對稱加密祕鑰協商的所有動作。
最後一個問題，客戶端的第三方公鑰從哪裏獲取
問題六：客戶端的第三方公鑰從哪裏獲取
實際第三方公鑰存在於頒發用戶證書的中級證書裏，中級證書和用戶證書沒有任何區別，那麼中級證書的真僞如何判斷，最終就是通過根證書。
可信渠道認證根證書，根證書認證中級證書，中級證書認證中級證書……，中級證書認證個人證書，個人證書認證用戶拿到的公鑰。如圖：
這裏的根證書是操作系統安裝好以後就存在的。
鳴謝
寫這篇博客觸發點是今天面試別人的時候問到了這個問題，但是突然想不起細節了，所以今天寫一下，主要是做個筆記。感謝以下兩位的博客：
呦呦鹿鳴，食野之芩 ： http://blog.csdn.net/zbuger/article/details/51595229
翟志軍 ：https://mp.weixin.qq.com/s/8Y2BX80Ka9B8McmZOqMVQg （原諒我比較懶，大部分圖都是從這裏摘的）
寫在最後
其實我在理解https時有一個疑惑：
https通過CA公鑰解密摘要信息，然後和證書信息做hash後的值做了對比，從而判斷證書的真僞。這裏爲什麼不能直接省掉做hash的過程，直接對整個證書內容進行CA私鑰加密，如果客戶端用根證書中的公鑰能解密則證書是真的，當然這裏的能解密不是嚴格意義上的能解密，而是解密後的格式和正常格式一致，就認爲能解密。而不能解密則認爲證書是假的。
我自己的猜測：
1.數字證書需要找到這個證書的頒發者來驗證證書真假，意味着頒發者一定是不能加密傳輸的，所以造成證書一部分加密，一部分非加密。很不整齊，雖然現在也是一部分加密，一部分非加密，但是加密部分僅是摘要信息，除摘要信息外部分是沒有加密的。
2.如果整個證書加密，那客戶端解密時根本不確定這個證書是真還是假，相比較對hash解密而言，對整個證書解密效率肯定會差很多。
3.如果整個證書加密，意味者證書發送到客戶端，客戶端完全不發看到證書的任何信息，除證書的頒發者。對維護、問題定位造成很大困難。
4.如果證書恰巧被篡改，而且篡改完的用戶名和用戶公鑰隨便通過一個私鑰加密後傳給客戶端，客戶端此時拿着本地CA公鑰解密恰好解密出一個和正常公鑰用戶信息格式一樣的數據，會騙過所有認證。客戶端誤認爲這個證書是真的。雖然這種情況發生後，客戶端拿到的公鑰一定是不正確的（因爲被篡改的證書不是通過CA私鑰加密的），但客戶端依然會用這樣的一個錯誤公鑰加密信息傳遞數據。這樣的數據即無法被服務器解析也無法被篡改者解析，直接造成了https不可用。
以下10-26補充
用對hash的原因今天上午查了很多資料,最終原因是:
但是我還是認爲我上邊的猜測一部分也是合理的哈,就不刪除上邊的猜測了.
hash的不可逆特性作用
hash是不可逆的,數字簽名基於這個特點通過判斷hash是否發生變化來判斷整個數字證書是否發生篡改,但是如果hash出現碰撞,意味着別人可以通過碰撞hash篡改數字證書內容.篡改的內容如果恰好是服務器發給客戶端的公鑰,整個數字證書就都失效了.
參考資料
360doc vavava : http://www.360doc.com/content/10/1116/18/61151_69907721.shtml
sohu: http://www.sohu.com/a/168303317_99901444
沃通論壇 : https://www.wosign.com/basic/codesign_basic.htm