Skip to content

Zoom-in: Asymmetric Encryption

Karify98·
Cover Image for Zoom-in: Asymmetric Encryption

Trình duyệt hiện ổ khóa xanh — kết nối an toàn. Dữ liệu được mã hóa. Mọi người biết vậy rồi dừng lại ở đó.

graph LR
    C(["🔒 HTTPS"]) -->|"an toàn"| S(["✅ Kết nối"])
    style C fill:#1e293b,stroke:#475569,color:#cbd5e1
    style S fill:#1e293b,stroke:#475569,color:#cbd5e1

Phóng to dần vào black box đó.


Layer 1 — Vấn đề gốc: mã hóa đối xứng cần trao đổi key

Mã hóa đơn giản nhất là mã hóa đối xứng: cùng một key để mã hóa và giải mã. Nhanh, hiệu quả — nhưng có một bài toán không giải được.

sequenceDiagram
    participant A as Alice
    participant E as 🕵️ Eve (nghe lén)
    participant B as Bob

    A->>B: "Dùng key này nhé: XK9m#..."
    Note over E: Eve bắt được key trong lúc truyền
    A->>B: "Tin nhắn mã hóa: ..."
    Note over E: Eve dùng key đã bắt được để giải mã

Nếu muốn giao tiếp an toàn, hai bên phải có cùng key. Nhưng để trao đổi key đó qua internet không an toàn thì cần key khác để mã hóa — vòng lặp không có lối thoát.

Vấn đề còn lại: cần cách trao đổi thông tin bí mật qua kênh công khai mà không cần chia sẻ bí mật trước.

Layer 2 — Cặp khóa: public key và private key

Mã hóa bất đối xứng dùng hai key liên kết toán học: một public key (chia sẻ với mọi người) và một private key (chỉ chủ sở hữu biết).

graph LR
    Gen["🔑 Key Generator"] -->|"tạo ra"| Pub["📢 Public Key\n(chia sẻ công khai)"]
    Gen -->|"tạo ra"| Priv["🔒 Private Key\n(giữ bí mật tuyệt đối)"]

    style Gen fill:#3b2a1a,stroke:#f59e0b,color:#fcd34d
    style Pub fill:#1e3a5f,stroke:#3b82f6,color:#93c5fd
    style Priv fill:#1a3a2a,stroke:#22c55e,color:#86efac

Tính chất đặc biệt:

  • Mã hóa bằng public key → chỉ private key giải được: ai cũng có thể gửi tin nhắn bí mật cho bạn
  • Ký bằng private key → ai cũng xác nhận bằng public key: chứng minh tin nhắn đến từ bạn

Hai tính chất này giải quyết hai bài toán khác nhau — và cả hai đều quan trọng trong HTTPS.

Vấn đề còn lại: tại sao biết được private key từ public key là điều không thể?

Layer 3 — Toán học một chiều: tại sao không thể đảo ngược

Sự bảo mật của mã hóa bất đối xứng dựa trên bài toán toán học dễ tính một chiều, cực kỳ khó đảo ngược.

Ví dụ với RSA: nhân hai số nguyên tố lớn với nhau thì dễ, nhưng phân tích ngược lại từ tích ra hai thừa số thì cực kỳ khó:

p = 104729          q = 224737
n = p × q = 23,540,041,273    ← tính trong microsecond

Cho n = 23,540,041,273 → tìm p và q?
→ Với số đủ lớn (2048 bit): siêu máy tính cần hàng nghìn năm

Trong thực tế, RSA dùng số nguyên tố hàng trăm chữ số. Không có thuật toán thực tế nào phân tích được trong thời gian hợp lý.

Vấn đề còn lại: biết public key thật sự đến từ server đúng không — hay đây là server giả mạo?

Layer 4 — Certificate: ai đảm bảo public key là thật

Nếu kẻ tấn công có thể chèn public key của họ vào giữa, mọi mã hóa đều vô nghĩa. Vấn đề này được giải quyết bằng certificate — văn bản kỹ thuật số xác nhận public key thuộc về ai.

sequenceDiagram
    participant Server as karify98.site
    participant CA as 🏛️ Certificate Authority\n(DigiCert, Let's Encrypt...)
    participant Browser as Trình duyệt

    Server->>CA: "Đây là public key của tôi, xác nhận giúp tôi"
    CA->>CA: Xác minh quyền sở hữu domain
    CA-->>Server: Certificate (public key + chữ ký của CA)

    Browser->>Server: HTTPS request
    Server-->>Browser: Certificate
    Browser->>Browser: Kiểm tra chữ ký CA\n(trình duyệt tin CA vì CA đã được cài sẵn)
    Browser-->>Browser: ✅ Public key đáng tin

Trình duyệt có sẵn danh sách Certificate Authority (CA) đáng tin — khoảng 150 tổ chức được cài sẵn trong hệ điều hành. Khi server trình certificate do CA ký, trình duyệt tin vì tin CA.


Full picture

Cách HTTPS kết hợp tất cả để thiết lập kênh an toàn.

sequenceDiagram
    participant C as Trình duyệt
    participant S as Server

    C->>S: ClientHello — cipher suites hỗ trợ
    S-->>C: Certificate (public key + chữ ký CA)
    C->>C: Xác minh certificate ✓

    Note over C,S: Trao đổi key bằng mã hóa bất đối xứng
    C->>S: Mã hóa session key bằng public key server
    S->>S: Giải mã session key bằng private key

    Note over C,S: Từ đây dùng mã hóa đối xứng (nhanh hơn)
    C->>S: Dữ liệu mã hóa bằng session key 🔒
    S-->>C: Response mã hóa bằng session key 🔒

HTTPS không dùng mã hóa bất đối xứng để mã hóa toàn bộ dữ liệu — chỉ dùng để trao đổi session key an toàn. Sau đó chuyển sang mã hóa đối xứng vì nhanh hơn nhiều.


Ba nhầm lẫn phổ biến

HTTPS mã hóa toàn bộ bằng RSA

RSA chỉ dùng trong TLS handshake để trao đổi session key. Dữ liệu thực tế được mã hóa bằng AES (mã hóa đối xứng) vì AES nhanh hơn RSA hàng trăm lần. Mỗi kết nối HTTPS có một session key riêng.

Ổ khóa xanh = website an toàn

Ổ khóa chỉ đảm bảo kết nối được mã hóa — không đảm bảo website đó đáng tin. Trang web lừa đảo (phishing) hoàn toàn có thể có HTTPS và ổ khóa xanh, vì Let's Encrypt cấp certificate miễn phí cho bất kỳ ai sở hữu domain.

Private key cần được chia sẻ với CA

CA không bao giờ thấy private key. CA chỉ xác nhận rằng public key thuộc về chủ sở hữu domain, rồi ký xác nhận đó. Private key luôn nằm trên server — nếu bị lộ, certificate phải thu hồi ngay lập tức.

Takeaway

Mã hóa bất đối xứng tồn tại để giải quyết bài toán trao đổi bí mật qua kênh công khai — không phải để mã hóa dữ liệu (quá chậm). Certificate tồn tại vì public key cần được xác nhận là thật. Mỗi thứ trong chuỗi HTTPS giải quyết một vấn đề cụ thể mà thứ trước để lại.

Khi gặp lỗi SSL, câu hỏi đúng: "certificate hết hạn, không khớp domain, hay CA không được tin?" — trình duyệt thường báo chính xác loại lỗi nếu biết đọc thông báo lỗi.


Bài viết được hỗ trợ bởi Amy 🌸 - AI Assistant. Nội dung đã được kiểm duyệt bởi tác giả.

Related Posts