HTTPS 與安全#

HTTPS 在 HTTP 的基礎上加入了 TLS/SSL 安全層，實作加密傳輸和身份認證。本章涵蓋 HTTPS 原理、加密算法、數字證書和 TLS 握手過程。

為什麼需要 HTTPS#

HTTP 的安全問題#

HTTP 明文傳輸存在三大風險：

安全通信的四要素#

HTTPS 基礎#

HTTPS = HTTP + TLS#

flowchart TB
    subgraph Stack["HTTPS 協議棧"]
        L1["應用層（HTTP）"]
        L2["安全層（TLS/SSL）"]
        L3["傳輸層（TCP）"]
        L4["網路層（IP）"]
    end

    L1 --> L2 --> L3 --> L4

    style L2 fill:#c8e6c9

HTTPS 只是把 HTTP 的傳輸層從 TCP 換成了 TLS/TCP。語法、語義和 HTTP 完全相同。

TLS 發展歷程#

加密算法#

對稱加密#

特點：加密和解密使用同一個密鑰

明文 ──[密鑰]──→ 密文 ──[同一密鑰]──→ 明文

分組模式：

• GCM：認證加密，推薦使用
• CBC：較老，有安全漏洞

對稱加密速度快，但有密鑰交換問題：如何安全地把密鑰傳給對方？

非對稱加密#

特點：使用一對密鑰（公鑰 + 私鑰）

公鑰加密 ──→ 只有私鑰能解密
私鑰加密 ──→ 只有公鑰能解密（用於簽名）

RSA vs ECC 安全等級對比：

混合加密#

TLS 結合兩種加密方式的優點：

flowchart TD
    A["1. 非對稱加密交換會話密鑰<br/>(解決密鑰交換問題)"] --> B["2. 對稱加密通信<br/>(保證加密效率)"]

    style A fill:#e3f2fd
    style B fill:#c8e6c9

摘要算法與數字簽名#

摘要算法#

將任意長度資料壓縮為固定長度的「指紋」：

特性：

• 單向性：無法從摘要反推原文
• 雪崩效應：原文微小改動導致摘要巨變
• 抗碰撞：難以找到兩個不同原文有相同摘要

數字簽名#

用私鑰對摘要加密，實作身份認證和不可否認：

flowchart LR
    subgraph Sender["發送方"]
        S1["原文"] --> S2["計算摘要"]
        S2 --> S3["私鑰加密"]
        S3 --> S4["簽名"]
    end

    subgraph Receiver["接收方"]
        R1["收到原文 + 簽名"] --> R2["用公鑰解密"]
        R2 --> R3["比對摘要"]
        R3 --> R4["驗證通過"]
    end

    S4 -->|"發送"| R1

    style S3 fill:#fff3e0
    style R4 fill:#c8e6c9

數字簽名只能由私鑰持有者創建，任何人都可以用公鑰驗證。這實作了身份認證和不可否認。

數字證書與 CA#

信任問題#

非對稱加密解決了密鑰交換，但帶來新問題：如何確定公鑰是真的？

攻擊者可以：
1. 冒充網站，發送假公鑰
2. 你用假公鑰加密，攻擊者用其私鑰解密
3. 攻擊者再用真公鑰加密轉發給真網站
→ 中間人攻擊（Man-in-the-Middle）

CA 證書體系#

CA（Certificate Authority） 是可信的第三方機構，為公鑰背書：

flowchart TB
    Root["根 CA<br/>(自簽名，信任起點)"] -->|簽發| Intermediate["中級 CA"]
    Intermediate -->|簽發| Site["網站證書<br/>(用戶訪問的網站)"]

    style Root fill:#ffcdd2
    style Intermediate fill:#fff3e0
    style Site fill:#c8e6c9

證書內容#

證書驗證流程#

flowchart TD
    A["1. 收到伺服器證書"] --> B["2. 檢查證書有效期"]
    B --> C["3. 檢查是否被吊銷 (CRL/OCSP)"]
    C --> D["4. 用上級 CA 公鑰驗證簽名"]
    D --> E["5. 逐級驗證直到根 CA"]
    E --> F["6. 驗證域名是否匹配"]

    style F fill:#c8e6c9

證書類型#

TLS 握手過程#

TLS 1.2 握手（ECDHE）#

sequenceDiagram
    participant C as 客戶端
    participant S as 伺服器

    C->>S: Client Hello<br/>(版本、隨機數、支援的密碼套件)
    S->>C: Server Hello<br/>(版本、隨機數、選定的密碼套件)
    S->>C: Certificate (伺服器證書)
    S->>C: Server Key Exchange<br/>(ECDHE 公鑰 + 簽名)
    S->>C: Server Hello Done

    C->>S: Client Key Exchange (ECDHE 公鑰)

    Note over C,S: 雙方計算 Pre-Master Secret<br/>生成 Master Secret 和會話密鑰

    C->>S: Change Cipher Spec
    C->>S: Finished
    S->>C: Change Cipher Spec
    S->>C: Finished

    Note over C,S: 開始加密通信

握手過程交換三個隨機數：Client Random、Server Random、Pre-Master Secret。這三個隨機數共同生成會話密鑰，即使其中一個洩露也難以破解。

密碼套件#

密碼套件定義了 TLS 使用的算法組合：

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 │    │     │         │    │    │
 │    │     │         │    │    └── 摘要算法
 │    │     │         │    └── 分組模式
 │    │     │         └── 對稱加密算法
 │    │     └── 簽名算法
 │    └── 密鑰交換算法
 └── 協定

推薦（TLS 1.2）：
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

TLS 1.3 密碼套件更簡潔：
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256

TLS 1.3 改進#

前向保密（Forward Secrecy）：即使長期私鑰洩露，過去的通信記錄也無法被解密。ECDHE 每次握手生成臨時密鑰，天然支援前向保密。

實際應用#

組態 HTTPS（Nginx）#

server {
    listen 443 ssl http2;
    server_name example.com;

    # 證書和私鑰
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    # TLS 版本
    ssl_protocols TLSv1.2 TLSv1.3;

    # 密碼套件
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers on;

    # HSTS
    add_header Strict-Transport-Security "max-age=31536000" always;
}

檢測工具#

# 查看證書資訊
openssl s_client -connect example.com:443 -servername example.com

# 查看證書詳情
openssl x509 -in cert.pem -text -noout

# 測試 TLS 組態
nmap --script ssl-enum-ciphers -p 443 example.com

在線檢測#

• SSL Labs ^↗ - 全面的 SSL/TLS 測試
• Mozilla SSL Configuration Generator ^↗ - 組態生成器

本章小結#