經常都在聽說 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 握手的流程，
公眾號：沒有夢想的阿巧 后臺回復 "群聊"，一起學習，一起進步
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/179280.html
標籤：其他
上一篇：Redis持久化
下一篇：資料庫事務隔離級別