如何理解 HTTPS

常常都在據說 https ,在谷歌瀏覽器上瀏覽不是 https 的網站，都會提示網站不安全。那到底什麼是 https ，之前大概瞭解過一點點，可是對它的原理則是很模糊，趁着此次做業的機會，好好看看一下協議的實現方式。

http

談 https 以前先說一下 http, http 是位於應用層的網絡協議，主要用於網絡中數據的傳輸，可是 http 傳輸是明文傳輸，這意味着網絡上的任何一我的均可以看到你發送了什麼消息，接收了什麼消息。若是世界上沒有不懷好意的人，那這樣確實沒有什麼問題，然而老是有一些變態，或者是壞蛋，喜歡躲在角落裏偷窺別人的生活，以此來達到本身的目的。

加密的方式

爲了防止被人偷窺，只能想辦法加密傳輸的數據。從大的方面來講，加密能夠分爲對稱加密和非對稱加密兩種。

對稱加密

對稱加密很好理解，依靠一種加密算法，生成一個密鑰，你能夠用這一個密鑰對須要加密的數據進行加密，也能夠用這個密鑰對數據進行解密。總之一個密鑰就能完成全部事了，but 問題不在於加密算法，而在於這個密鑰要怎麼保存。想想，有沒有在不經意間看到過別人輸入密碼？人是不可靠的，安全問題不能靠人來保證。

非對稱加密

非對稱加密跟對稱加密差距就大了，非對稱加密會生成一個公鑰和一個私鑰；公鑰能夠公開出來，任何人均可以看到，而且使用公鑰對數據進行加密，可是解密只能用私鑰來進行解密（理論上是這樣）。這樣就只須要保存好私鑰就好了，若是須要和別人進行通訊，只須要把本身的公鑰發送過去，這樣就能夠了。

選擇

單對稱加密

上面也有解釋過，對稱加密是不行的，密鑰的保存是個大問題。

單非對稱加密

單非對稱加密應該是可行的，可是每次傳輸數據雙方都須要進行非對稱加密的解密運算。非對稱加密從數學上保證了從公鑰推導出私鑰的難度是至關大的，要實現這樣的效果，必然要通過大量的運算（與對稱加密相比），這會形成大量性能的損耗。

創建會話

https 創建會話的認證過程也是很難的。

若是沒有 CA

在沒有 CA 的狀況下，客戶端和服務端須要創建鏈接。這時候的流程是怎麼樣的？

客戶端	服務端
request	生成一個密鑰對：k1 爲公鑰,k2 爲私鑰, 發送 k1 給客戶端
用對稱加密算法生成一個密鑰"k", 使用 k1 來加密 「k」,得到密文「k3」, 發送給服務端	服務端用 「k2」 來解密 「k3」，得到 "k", ，而後就可使用 "k"做爲密鑰傳送數據

問題？

上面這樣的步驟就已經安全了嗎？？？

看似是沒有什麼問題，但其實有一個很大的問題：身份認證。

你怎麼知道你收到的公鑰是網站發送給你的呢？在你和網站中間，若是有一我的把網站發給你的公鑰攔截了，而後把本身的公鑰發送給你，而後再把你發送的數據發送到網站。若是有想法，還能篡改你發送的數據，burpsuite 這種軟件就是依靠這樣的原理。比較官方的稱呼叫作「中間人攻擊」。

解決問題

既然問題是身份認證的問題，那就要想辦法解決它。要證明雙方的身份，那就須要引入公證人，在 https 中就是證書。一個機構，若是全世界都相信它，那咱們也能夠選擇相信它，也包括機構頒發的證書，所以只要機構足夠權威，就能夠用來證明網站的身份。

所以網站就不能向以前那樣本身生成一個公鑰，而後發送出去和客戶端進行通訊了。網站的管理者須要向 CA 申請一個證書，證書中包括了公鑰，私鑰以及證書的有效信息，以保證證書的真實性和有效性。由於這些機構是足夠權威的，所以操做系統和瀏覽器默認就安裝了這些機構的證書，在進行身份認證的時候，會經過本地的證書進行校驗，若是網站的證書是有效的，那就認爲這次身份認證成功，能夠進行數據傳輸了。

下面這個圖是 TLS 握手的流程。

公衆號：沒有夢想的阿巧 後臺回覆 "羣聊"，一塊兒學習，一塊兒進步