System Design Fundamental

系統設計基礎筆記(一) Security And HTTPS

Security And HTTPS

前言

除了了解前/後端語言與框架如何使用外，也希望能對 Http/Https 的原理與安全機制有所了解。

Prerequistites

  • IP Packet

    • 透過 IP 傳送的最小數據的單位，通常會包含 IP Header 與 payload
    • IP Header 包含來源與目的地的 IP Address
    • payload 就是你要傳送的資料

  • Man-In-The-Middle Attack (又稱呼為 MITM)

    • 意思是攔截 client 與 server 間傳送的訊息 💬
    • 若 client 與 server 間傳送訊息有透過加密與 Https 可防止資料被竊取

  • Symmetric Encryption (對稱加密)

    • 加密與解密資料都使用同一把 key 🔑
    • 缺點是安全性會有所疑慮，key 通常會被分享到一個點或多個點
    • 優點是速度比非對稱加密快 🐇
    • 最廣泛使用的演算法是 Advanced Ecryption Standard(AES)

  • Asymmetric Encryption (非對稱加密)

    • 加密與解密資料會利用到兩把 key 🔑🔑，分別為 public key 與 private key
    • public key 負責加密資料，只能利用相對應的 private key 解密資料
    • 所以 public key 分享給需要加密資料的一端，而 private key 則需要 安全地保存 ㊙️
    • 速度會比對稱加密慢 🐢

  • Advanced Ecryption Standard(AES)

    • 最廣泛使用的加密標準
    • 三種對稱演算法分別為 AES-128、AES-192、AES-256

  • Transport Layer Security (TLS)

    • 在傳輸層的一種協定，目的是為了網路通訊時的安全，確保沒有第三方能竊聽或者竊取任何資訊
    • 衍生於另一種安全協定 Secure Socket Layer (SSL)

  • SSL certificate

    • 由 certificate authority (CA) 頒發給 server 的數位憑證
    • 內容包含 server 端的 public key，因為在 TLS Handshake 過程中會使用到
    • 目的是確認

Http vs Https

Http

  • 全名為 HyperText Transfer Protocol
  • 一種常見的網路通訊協議
  • 流程是 client 送出 http request，而 server 送出回應

Https

  • 全名為 HyperText Transfer Protocol Secure
  • 顧名思義是為了可於網路上🔐安全地通訊而出現的一種網路通訊協議
  • 為了達到上述要求，因此 server 被要求須具備以下兩項
    • 須獲得可信任的憑證(SSL certificates)
    • 使用 Transport Layer Security (TLS) 加密 client 與 server 端的數據。TLS 如何運作，請往下看。

TLS 連接是透過 TLS Handshake 來啟動

  • 流程
    • client 送出 client hello (隨機的 bytes) 給 server
    • server 回應 server hello (也是隨機的 bytes) 以及 SSL certificate
    • client 驗證 CA 頒發的憑證，確認憑證正確屬於此 server 擁有
    • client 接著會送出一組用 public key 加密的 premaster secret 給 server
    • client 和 server 將會使用 client hello, server hello與 premaster secret 產生對稱加密的 session keys，用於後續的通訊內容的加密與解密 🔐

TCP 利用 Handshake 方式來連接與斷連

TCP 三次握手(建立連線)

  • 流程

    • 第一次握手：
      • 客戶端傳送請求 SYN 報文給服務端，傳送完畢之後，客戶端處於 SYN_Send 狀態。
    • 第二次握手：
      • 服務端收到請求報文之後，如果同意連線，會回傳 SYN + ACK 應答報文，服務端為SYN_Receive狀態
    • 第三次握手：
      • 客戶端接收到服務端的 SYN + ACK ，然後傳送確認報文作為應答，客戶端轉為Established狀態

  • 為什麼一定要三次?

    • 為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤

TCP 四次握手(結束連線)

  • 流程
    • 第一次分手
      • 客戶端傳送FIN=1告訴服務端，客戶端所有的資料全部發送完畢，服務端可以關閉接收了。
    • 第二次分手
      • 服務端接收到客戶端的釋放請求連線之後，知道客戶端沒有資料傳送給自己了，然後服務端傳送ACK=1告訴客戶端接收到你發給我的訊息
    • 第三次分手
      • 告訴客戶端，服務端的所有資料傳送完畢，客戶端你也可以關閉接收資料連線了。
    • 第四次分手
      • 客戶端接收到了服務端傳送完畢的訊息之後，就傳送ACK=1，告訴服務端，客戶端已經接收到你的訊息

參考資料 👐

🍀 最後，若喜歡我的分享，可以幫我拍拍手👏，是對我最大的鼓勵!✨