← 回到筆記2025-01-06

SSL vs SSH

比較 SSL/TLS 與 SSH 的運作流程，以及 openssl 與 ssh-keygen 產生的金鑰用途與 CloudFront 使用 PEM 的原因。

發佈 ~3 分鐘 #SSL#SSH

問題： openssl 和 ssh-keygen 長出來的 secret 用途差在哪

→ SSL 和 SSH 的差別是啥？

→ SSL 和 SSH 的運作流程

  • → openssl 和 ssh-keygen 長出來的 secret 用途

→ 為啥 Cloudfront signed URL 使用的是 openssl 長出來的 key 而不是 ssh-keygen

SSL vs SSH

  顧客 <-- SSL --> 店面 <-- SSH --> 管理員
(client)        (server)         (client)
  • SSL：確保交易資訊不會被偷看、確保店面是官方正店
  • SSH：用於遠端管理、維護運作

SSL/TLS 運作流程

  • TLS handshake

    1. Client 發起通訊、提供自己支援的加密算法和隨機數

    2. Server 回覆：選擇雙方都支援的加密法、SSL/TLS 證書、隨機數

      • SSL/TLS 證書裡包含 server public key (generated by openssl) / server domain name / CA signed number，用於給 client 驗證

    3. Client 驗證證書的合法性

    4. 交換臨時公鑰 (Ephemeral Key Exchange)

      1. server 生成 DHE key pair，並把 DHE public key 用 openssl 長出來的私鑰簽名後傳給 client（用 private key 簽名確保未被篡改；傳送 public key + public key 簽章）
      2. client 用 server 憑證的 public key 驗證簽名，確認未被篡改
      3. client 生成 DHE key pair，並把 DHE public key 傳給 server
      4. server/client 用自己的 private key + 對方的 public key 計算出共享密鑰，計算結果會一致，作為後續加密通訊的對稱密鑰

      ⚠️ 為什麼設計這樣的流程？

      1. 效率：避免臨時公鑰加密和解密的開銷，簡化交換流程。
      2. 安全性：即使交換的公鑰被攔截，攻擊者仍無法計算共享密鑰（基於 Diffie-Hellman 的數學特性）。
      3. 身份驗證：伺服器簽名保證了公鑰來源的可信性，防止中間人攻擊。

    5. 之後的通訊都用這把 key 加解密

  • 為什麼交換公鑰時的內容被偷聽、竄改無效？
    • 非對稱式加密沒有私鑰就解不開
    • Key exchange protocol
      • RSA 缺點：server private key 被洩漏則訊息可能會被破解
      • Ephemeral Diffie-Hellman (DHE & ECDHE)
        • 用 ephemeral key 進行金鑰交換
        • 基於數學難題生成 ephemeral key
    • 完整性校驗
      • Client 可以驗證 CA 簽名的合法性
      • TLS 使用 HMAC (Hash-based message authentication code) 來驗證訊息是否被篡改

SSH 運作流程

  1. 建立連線：Key exchange by DHE & ECDHE

    → 驗證 Server 身份 by public key fingerprint

  2. Server 驗證 Client 身份 by 密碼或者 public key

    → server 收到 client 的 public key 會放在 ~/.ssh/authenticated_keys 裡面

    → 這個 client public key 是由 ssh-keygen 長出來的

  3. 使用第一步交換的 key 對後續傳輸的訊息加密

為啥 Cloudfront signed URL 使用的是 openssl 長出來的 key 而不是 ssh-keygen

  1. Cloudfront 要求的密鑰格式是 PEM，這也是 OpenSSL 生成密鑰的預設格式，如果使用 ssh-keygen 則需要額外設定
  2. ssh-keygen 主要支援 SSH 協定，用於遠端登錄或身份驗證，協定本身就與 SSL 不同

→ 衍伸題：為啥 CloudFront 要用 PEM 格式？

  • 行業標準化： PEM 格式是加密領域的通用標準，廣泛兼容多種工具和協議。
  • 靈活性： 可用於存儲公私鑰和證書，適合 CloudFront 的應用需求。
  • 可讀性和易用性： 基於文本的格式便於傳輸和管理。
  • 安全性： 支持加密密鑰存儲。

OpenSSL & ssh-keygen 密鑰用途

特性/用途OpenSSL 生成的密鑰ssh-keygen 生成的密鑰
設計目標通用加密工具，支持多種協議與場景（如 SSL/TLS、數字簽名）專為 SSH 協議設計，用於遠程登錄和身份驗證
格式支持 PEM（默認）、DER、PKCS#8 等多種格式默認生成 OpenSSH 格式，可選擇 PEM 格式
用途場景SSL/TLS 通信、數字簽名、證書生成、數據加密SSH 登錄、SCP/SFTP 文件傳輸、SSH 隧道
應用協議SSL/TLS、HTTPS、X.509 證書SSH（Secure Shell）
生成密鑰的常見算法支持 RSA、ECDSA、Ed25519、DSA、EC支持 RSA、ECDSA、Ed25519
密鑰的主要用途- 簽署和驗證 SSL/TLS 憑證
- 加解密數據
- 密鑰交換		- 驗證 SSH 登錄
- 無密碼登錄
- SSH tunnel 安全
密鑰使用環境通常搭配 Web 服務器（如 Nginx、Apache）或證書管理工具通常搭配 OpenSSH 服務器或客戶端
可否用於 CloudFront是，支持 PEM 格式，適合用於 CloudFront Signed URL否，默認格式不兼容，需手動轉換為 PEM 格式才能使用
典型命令openssl genpkey 或 openssl genrsassh-keygen -t rsa -b 2048
← 回到筆記