HTTPS備忘

TCP報文格式重要欄位介紹

• 序號(Seq):32位，用來標識從TCP源端向目的端傳送的位元組流，發起方傳送資料時對此進行標記
• 確認序號(Ack):32位，ACK=1時，確認序號欄位才有效，Ack=Seq+1
• 標誌位(URG、ACK、PSH、RST、SYN、FIN):
  • FIN釋放一個連線

注意點

• Ack和ACK要區分
• 確認方的Ack=發起方的Seq+1，兩端配對

三次握手/四次揮手

• 三次握手

1. 客戶端->>服務端: 連線請求(SYN=1,seq=X)；
2. 服務端->>客戶端: 授予連線(SYN=1,ACK=1，seq=Y, ack=X+1)；
3. 客戶端->>服務端: 確認(ACK=1,ack=K+1)；

相當於

1. 客戶端：我能說話，你能聽到不？
2. 服務端：我能聽到，那我說話你能聽到不？
3. 客戶端：我也能聽到，我們開始通訊吧。

三次握手就是確保兩端都能正常的接收和傳送。所以才說TCP是可靠的原因。

• 四次揮手

1. 客戶端->>服務端：傳送FIN，關閉客戶端到服務端的傳送，客戶端進入FIN_WAIT_1狀態；
2. 服務端->>客戶端：收到FIN後，傳送一個ACK給客戶端，確認序號為收到序號+1，服務端進入CLOSE_WAIT狀態；
3. 服務端->>客戶端：服務端傳送一個FIN，用來關閉服務端到客戶端的資料傳送，Server進入LAST_ACK狀態；
4. 客戶端->>服務端：收到FIN後，客戶端進入TIME_WAIT狀態，接著傳送一個ACK給服務端，確認序號為收到序號+1，服務端進入CLOSED狀態，完成四次揮手。

相當於

1. 客戶端：我沒啥資料發了，我斷開了
2. 服務端：我知道你要斷開了，並且告訴你我知道了
3. 服務端：我沒啥資料發了，我斷開了
4. 客戶端：我知道你要斷開了，並且告訴你我知道了

為啥揮手要四次呢？因為客戶端你不發了，不代表你不能收了，我服務端沒說不發，你當然不能斷啦。TCP全雙工通訊（雙軌：可以來回傳送訊息，單軌：一個發了，一個等待，一個軌道只能一個訊號傳送），所以有一方是主動斷開，另一方是被動斷開的。（就和分手一樣一樣的！！！）。

HTTP1.1/HTTP2.0

• HTTP/1.1: 持久連線(長連線)、節約頻寬、HOST域、管道機制、分塊傳輸編碼
• HTTP/2: 多路複用、伺服器推送、頭資訊壓縮、二進位制協議等

對稱加密

• 加密和解密的金鑰是一樣的
• 金鑰配送問題
  • 事件共享金鑰
  • 金鑰分配中心
  • DH金鑰交換
  • 公鑰密碼
• 常見演算法：DES（64bit，每隔7位設定一個錯誤檢查的bit，所以共有56bit是有效的）、3DES、AES（用於取代DES）
• 如果每個客戶端的金鑰都是不一樣的，服務端儲存金鑰的壓力巨大，一樣的話，黑客也能拿到，那加不加密都一樣

非對稱加密

• 客戶端可以拿到公鑰，服務端儲存私鑰
• 中間人問題：客戶端無法保證拿到公鑰的準確性

對稱加密+非對稱加密+CA認證

• CA認證：利用第三方權威機構，證明我就是我（是顏色不一樣的煙火）
• 基本流程：
  1. c->s 支援的SSL版本，非對稱加密演算法，隨機數R1
  2. s->c SSL版本，對稱演算法、隨機數R2，證書（服務端把公鑰傳到CA機構，CA機構利用自己的私鑰簽名認證，返回給服務端的）
  3. 證書認證
  4. c->s 隨機數R3 hash(R1, R2) = x
  5. hash(R1, R2) =? x => R1、R2、R3計算得出對應加密中金鑰k
  6. s->c hash(R1, R2, x) = y
  7. hash(R1, R2, x) =? y => R1、R2、R3計算得出對應加密中金鑰k

所以對稱加密的公鑰只有通訊的雙方才知道，也就能保證通訊安全了。

安全性考慮

HTTP通訊傳輸(當你輸入https://www.baidu.com後到底發生了什麼？)

1. 輸入地址
2. DNS解析（根據URL找到IP地址）
3. TCP三次握手
4. 傳送http請求
5. 返回http請求
6. 瀏覽器解析渲染頁面
7. 斷開連線

抓包工具

• Charles
• WireShark