https即 HTTP Secure,HTTP的通訊介面部分用SSL和TLS協議代替，並非是一種新的協議。
TLS協議是在SSL3.0的基礎上開發的協議，以下統一用TLS協議來說明
http的問題
- 通訊使用明文，內容被竊聽後存在安全問題
- 不驗證通訊方的身份，可能遭到偽裝
- 無法驗證報文的完整性，內容可能遭到篡改
http問題解決思路
明文不行，考慮先加密再傳輸呢？比如我傳輸過程中使用一種加密演算法，在瀏覽器端自己加密和解密，服務端也提供對應的策略來加密和解密。前端程式碼基本屬於完全暴露在所有人的面前，這種自己實現加密和解密的機制都會被別人知曉（祕鑰都會被看到），毫無安全性可言，另外如果每個人都要這麼搞一套，那就是重複造輪子，時間成本巨大，而且還不一定能做到很安全。
當然還包括效能、相容性等等問題。
通訊加密祕鑰的安全性問題
祕鑰肯定不能硬編碼寫到程式碼中，一種解決方式是在每次通訊的過程中先生成祕鑰，然後的資訊再用這個祕鑰進行加密通訊，但是初次傳輸過程中，仍然會出現明文傳輸祕鑰的問題，一旦被竊聽，後續所有的加密都都白費
初次祕鑰傳輸的問題
密碼學中的非對稱加密可以解決這種場景，非對稱加密擁有兩個祕鑰：公鑰和私鑰。公鑰可以解開私鑰加密的內容，私鑰可以解開公鑰加密的內容，那麼只要私鑰不洩密，通過公鑰加密的內容就算被擷取，現有的技術手段，是很難通過擷取的內容和公鑰得到原有的內容
公鑰能否信任
如果獲取的公鑰是竊聽人的公鑰，而不是真正服務提供方的公鑰，那麼後續的通訊加密都是使用的竊聽人的公鑰，竊聽人也自然使用自己的私鑰可以進行解密。因此獲取的公鑰必須是能夠信任的。
解決方式是把公鑰放到數字證書中，這個證書由受信任的第三方機構進行頒發，並通過三方的私鑰進行加密。客戶端發起請求首先會向服務端請求三方的證書，客戶端通過三方的公鑰進行解密後，就安全拿到了服務端的公鑰。
第三方的公鑰本身則是由瀏覽器和作業系統自己去維護
證書被替換的風險
竊聽人也可以自己去申請個證書，放上自己的公鑰，這樣客戶端同樣也可以通過三方的公鑰解密，但是解密出來的卻是竊聽人的公鑰。 解決方式是使用數字簽名，證書上涵蓋如何根據證書來生成數字簽名的方法，與通過第三方機構的公鑰解析到數字簽名想比較，驗證數字簽名是否一樣，一樣則表明證書確是要訪問的服務的。
比如證書上會寫所代表的網站，校驗的時候加上訪問的網站，就可以得到對應的資訊
https的通訊過程
https是建立在TLS協議之上的，它的通訊過程也是以TLS為基礎。首先進行"握手"，通過之後再進行通訊
TLS握手協議概述
-
客戶端傳送 ClientHello 資訊，包含
- 一個隨機數
- 客戶端所支援的協議版本
- 客戶端支援的對稱加密演算法
- key_share(表明使用Diffie-Hellman) 或者是 pre_shared_key 或者這兩者都有
-
服務端收到 ClientHello 之後，返回一個 ServerHello 資訊，包含：
- 協議的版本，比如TLS1.3
- 一個隨機數
- 使用的加密演算法
- 如果決定使用 (EC)DHE key,那麼會包含 "key_share" ;如果使用 PSK key,就會包含 "pre_shared_key"
-
服務端傳送證書
如果客戶端也需要驗證，會再傳送一個要證書的請求給客戶端
-
服務端傳送 Server Hello Done 給客戶端，表示Server Hello結束
如果客戶端收到了證書請求，會先傳送客戶端證書
-
客戶端對伺服器的證書進行校驗，沒通過則傳送警告給使用者，確認是否繼續，通過則返回 Pre master secret（這也是客戶端產生的一個隨機數）,這個 Pre master secret 本身會使用證書中的公鑰進行加密
-
客戶端傳送 Change Cipher Spec 報文，表示後續通訊都會採用雙方商定的加密方法和祕鑰傳送。
-
客戶端會根據之前傳遞的隨機數(2個)以及 Pre master secret 這三個隨機數生成一個master_ key,然後從master_key中提取會話用的祕鑰，用它加密一段內容，涵蓋在這裡客戶端傳送Finished報文中，表示客戶端握手階段結束同時也用來校驗加密通道
-
伺服器傳送 Change Cipher Spec ，表示服務端也切換到位
-
服務端拿到公鑰加密後的 Pre master secret 後，通過私鑰解密，使用與客戶端相同的方法，以及步驟7中的3個隨機數，生成會話用的祕鑰，使用這個加密祕鑰傳送一個Finished報文給客戶端，驗證加密通道，同時服務端握手結束
客戶端和服務端都能對Finished資訊正常解密且訊息被驗證，說明通道建立，後續通過上面產生的會話祕鑰對資料進行加密傳輸
非對稱加密與對稱加密的混合使用
握手過程中，有一個隨機數是使用非對稱祕鑰加密後傳輸的，傳輸成功之後，二者生成的最後一個會話祕鑰用來通話，這是因為非對稱祕鑰加密和解密處理速度相對對稱祕鑰要慢，因此僅在握手階段使用非對稱祕鑰傳遞，通訊的時候使用握手階段生成的會話祕鑰進行加密
3個隨機數
在握手的階段首先是客戶端隨機生成了一個隨機數，這是明文傳輸的，接著服務端返回了一個隨機數，也是明文傳輸的，最後客戶端使用了一個pre_master_key通過非對稱加密的方式加密傳輸的，為什麼用到了3個隨機數再經過計算得到一個master_key，然後才提取會話key？
首先說一下 pre_master_key,在握手的過程中，會先約定好到底使用按個 Cipher Suit,比如約定使用RSA或者是(EC)DH suites 【(elliptic curve) Diffie-Hellman】，RSA會傳送一個隨機的48位元組的 pre_master_key給服務端，但是 (EC)DH卻不是，它產生的可能比48位元組要長，也有可能要短，而且分佈並不均衡。雖然通過RSA或者是(EC)DH是保證了pre_master_key本身的保密性，但是根據情況的不同，產生的祕鑰格長度(格式)不一致，而多數情況下，保持一樣長度的祕鑰會有很好的結果，比如一樣的長度允許將祕鑰交換端與加密端區分開來(打個比方，不能根據長度猜到到底是用的那個非對稱演算法)，某種程度上來說也就具備更好的隨機性。因而最好處理下pre_master_key保證最終輸出的key的一致性
另外從安全性考慮，pre_master_key一旦使用後需要刪掉
而對於產生pre_master_key的演算法對於rsa來說每次是隨機的，但是對於dh，包括ecdh演算法(不考慮匿名dh和瞬時dh)，就只有hello訊息中的兩個隨機數因子了。但是ssl協議本身並不信任每個主機都能產生完全隨機的數字，如果隨機數不隨機,被猜出來就不合適了，因此選用3個隨機數來達到更好的隨機效果
隨機帶來的好處一個是當前的通訊不容易被才出來，另外每次都會不一樣，就是說就算當前的被才出來了，歷史上的也無法解出正確的密文(也叫前向保護)。
最終通過PRF演算法計算出一個固定長度為48位元組的master_key，從中再提取出對應的會話key,提取規則如下：
client_write_MAC_key[SecurityParameters.mac_key_length]
server_write_MAC_key[SecurityParameters.mac_key_length]
client_write_key[SecurityParameters.enc_key_length] //會話key
server_write_key[SecurityParameters.enc_key_length] //會話key
client_write_IV[SecurityParameters.fixed_iv_length]
server_write_IV[SecurityParameters.fixed_iv_length]
複製程式碼TLS的資料傳送 - Record Protocol
record protocol負責資料的傳送，它會把資料分割成可處理的幾塊（每塊2的14方位元組或者更少），然後進行壓縮，新增MAC(用於校驗資料的完整性)，加密，然後扔給底層的協議去處理；接收方則是進行資料的解密，校驗，解壓縮和重新聚合，再傳送給上層的協議
HTTPS能夠被信任的前提
- 瀏覽器正確的實現了HTTPS且作業系統中安裝了正確且受信任的證書頒發機構(想想盜版的作業系統==)
- 證書頒發機構僅信任合法的網站
- 被訪問的網站提供了有效的證書，即這個證書是由作業系統信任的證書機構簽發的
- 證書正確的驗證了被訪問的網站
- 協議的加密層能夠有效的提供認證和高強度的加密
引用
rfc1.2中關於record protocol部分
rfc1.2中關於master_key計算與會話key提取
Diffie-Hellman運作
3個隨機數的意義-來自csdn dog250
pre_master_key討論
master_key,session_key,pre_master_key的解釋
數字簽名簡介
也許這樣理解https更容易
討論http加密資料和使用https詳情戳這裡
SSL/TLS原理詳解
HTTPS被信任
圖解HTTP