一.簡介
https(secure hypertext transfer protocol)安全超文字傳輸協議 它是乙個安全通訊通道，它基於http開發，用於在客戶計算機和伺服器之間交換資訊。它使用安全套接字層(ssl)進行資訊交換，簡單來說它是http的安全版,是使用 tls/ssl 加密的 http 協議。
http 協議採用明文傳輸資訊，存在資訊竊聽、資訊篡改和資訊劫持的風險，而協議 tls/ssl 具有身份驗證、資訊加密和完整性校驗的功能，可以避免此類問題。
tls/ssl 全稱安全傳輸層協議 transport layer security, 是介於 tcp 和 http 之間的一層安全協議，不影響原有的 tcp 協議和 http 協議，所以使用 https 基本上不需要對 http 頁面進行太多的改造。
二.http的問題
由於http使用明文傳輸，可以使用軟體抓包。容易被劫持。
三.加密方式
https加密通訊有兩種加密，一種是非對稱加密，另一種是對稱加密。
非對稱加密，就是加密和解密的秘鑰不同，乙個私鑰乙個公鑰，公鑰加密，私鑰解密，你訪問某https站點時，是可以知道這個站點的公鑰的。公鑰進行加密，而解密是只能用私鑰進行解密
，而私鑰是握在站點手裡的，只有該站點可以知道，顯然，這樣的安全性很高，但有個很嚴重的問題就是，非對稱解密相當損耗cpu效能，全部內容都用非對稱加密交流效能大大下降。
對稱加密，就是加密和解密都是用的同乙個秘鑰，加密和解密都很快，在不知道秘鑰的情況下，想要破解的難度也非常大，比非對稱加密破解還要難。但有個問題就是，如果用對稱秘鑰的話，在第一次握手協商秘鑰的時候，很可能就已經被劫持，這時你的加密也就毫無安全性可言了。
四.https握手的過程詳細描述
1 客戶端發起乙個https的請求，把自身支援的一系列cipher suite（金鑰演算法套件，簡稱cipher）傳送給服務端
2 服務端，接收到客戶端所有的cipher後與自身支援的對比，如果不支援則連線斷開，反之則會從中選出一種
加密演算法
和hash演算法
以證書的形式返回給客戶端，
證書裡面包含了 **公鑰+各種資訊+簽名（ca機構的私鑰對各種資訊加密後生成簽名）。
3 客戶端收到服務端響應後會做以下幾件事
3.1 驗證證書的合法性
3.1.1 頒發證書的機構是否合法與是否過期，
**證書
中包含的**位址是否與正在訪問的位址一致
3.1.2 公鑰加密，私鑰解，私鑰加密公鑰也可以解。ca證書會在作業系統安裝時就安裝好，所以每個人電腦上都有根證書，使用ca證書中帶的公鑰來對
**證書的簽名
進行解密，然後和證書中的
各種資訊
做比較就可以校驗出證書的合法性
3.1.3 證書驗證通過後，在瀏覽器的位址列會加上一把小鎖
3.2 生成隨機密碼
如果證書驗證通過，或者使用者接受了不授信的證書，此時瀏覽器會生成一串
隨機數，然後用證書中的
公鑰加密
。
3.3 hash握手資訊
用最開始約定好的hash方式，把
握手訊息
取hash值
， 然後用
隨機數加密 「
握手訊息+握手訊息hash值(簽名)
」 並一起傳送給服務端
在這裡之所以要取握手訊息的hash值，主要是把握手訊息做乙個簽名，用於驗證握手訊息在傳輸過程中沒有被篡改過。
最終傳送給服務端的訊息密文組成：
公鑰加密的
（隨機數+
隨機數加密的
（握手訊息+握手訊息hash值）
）4 服務端拿到客戶端傳來的密文，用自己的私鑰來解密取出
隨機數密碼，再用
隨機數密碼解密
握手訊息
與hash值
，將握手訊息
用約定的hash方式取hash值，並與傳過來的hash值做對比確認是否一致。
然後用隨機數密碼加密一段握手訊息(握手訊息+握手訊息的hash值 )給客戶端
5 客戶端用
隨機數解密並計算握手訊息的hash，如果與服務端發來的hash一致，此時握手過程結束，之後所有的通訊資料將由之前瀏覽器生成的
隨機數密碼並利用對稱加密演算法進行加密
因為這串
隨機數金鑰只有客戶端和服務端知道，所以即使中間請求被攔截也是沒法解密資料的，以此保證了通訊的安全
那麼這裡再推理幾種情況能不能破解這個校驗方案：
中間人攻擊第一波
客戶端say hello 後，被**伺服器攔截，然後他再向我們真正的伺服器發相同的say hello，這時候伺服器不知道你是誰，給了**伺服器公開金鑰證書，然後**伺服器再把證書**給客戶端，客戶端校驗沒毛病，然後用公鑰加密的隨機字串發給**伺服器，這個時候**伺服器懵逼了，因為他沒有私鑰，解密不到隨機字串到底是什麼，好吧，他雖然看不懂，但是還是把這一坨東西原封不動的給了伺服器，伺服器一看，沒毛病，再把加密資訊給**伺服器，**伺服器，因為不知道剛才的隨機字串是什麼，而這個時候客戶端和伺服器已經不再使用公鑰加密，而是使用了共享金鑰加密，而關鍵的關鍵就是金鑰就是剛才的隨機字串。**伺服器再次懵逼，就看資料來來回回，可是他看不懂，這樣的中間人，只能算蠢萌的中轉人，這也就是使用了https之後，packetcapture擷取到的資料都是亂碼的原因，關於這個可以參考這裡。
中間人攻擊第二波
客戶端say hello 後，被**伺服器攔截，**伺服器也有ca頒發的證書，他把自己的合法證書發給客戶端，客戶端用證書裡面的公鑰解密簽名之後，得到了各種資訊，一看資訊都對上了，沒毛病信任。然後**伺服器宰相真正的伺服器say hello，伺服器下發真正的證書，**伺服器假裝自己是客戶端，信任了證書，然後校驗通過，髮用真正公鑰加密後的隨機數給伺服器，伺服器當然能解開，也就是**伺服器作為客戶端和真正的伺服器建立了合法的通訊。再看客戶端在校驗了**伺服器自己的證書後也建立了合法的通訊，這個時候，**伺服器作為中間人，因為他有自己的私鑰和真正的公鑰，可以欺上瞞下，倆邊的資訊都從它這裡過了一次，資訊被他**到。攻擊成功。
怎麼防禦？
客戶端內建真正的公鑰，當**伺服器把它自己的證書傳過來的時候，客戶端用內建的公鑰去解密證書中的簽名，因為不是真正的私鑰加密的所以解密失敗，校驗也就失敗，連線中斷。這也就是客戶端信任所有的證書的風險—被中間人攻擊。
參考：
HTTPS工作原理
https其實是有兩部分組成 http ssl tls，也就是在http上又加了一層處理加密資訊的模組。服務端和客戶端的資訊傳輸都會通過tls進行加密，所以傳輸的資料都是加密後的資料。客戶端發起https請求 這個沒什麼好說的，就是使用者在瀏覽器裡輸入乙個https 然後連線到server的443埠...
https工作原理
https協議一句話總結 要使客戶端與服務端的通訊過程得到安全保證，必須使用對稱加密演算法，但是協商對稱加密演算法的過程，需要使用非對稱加密演算法來保證安全，然而直接使用非對稱加密的過程本身也不安全，會有中間人篡改公鑰的可能性，所以客戶端與服務端不直接使用公鑰，而是使用數字證書頒發機構頒發的證書來保...
https工作原理
https其實是有兩部分組成 http ssl tls，也就是在http上又加了一層處理加密資訊的模組。服務端和客戶端的資訊傳輸都會通過tls進行加密，所以傳輸的資料都是加密後的資料 這個沒什麼好說的，就是使用者在瀏覽器裡輸入乙個https 然後連線到server的443埠。採用https協議的伺服...