6.9K 413 37

Đã đăng vào Thứ Năm, 10:24 SA 10 phút đọc

136

Bạn đã thực sự hiểu HTTPS là gì chưa? Hay chỉ mới biết nó "Secure" thôi

Chắc anh em đều biết HTTPS an toàn hơn HTTP rồi, nhưng hôm nay Sydexa muốn đi sâu hơn một chút: TLS Handshake diễn ra như thế nào? Verify certificate là gì?

Hiểu rõ 2 điều này sẽ giúp anh em debug được những lỗi kinh điển như "certificate expired", "untrusted CA", hay "SSL handshake failed" đó nha. Bắt đầu thôi

Bạn cho chúng mình xin 1 upvote để chúng mình có động lực ra những bài viết thú vị hơn nữa 😄😄😄

Chúng mình có tạo Group cho các bạn cùng chia sẻ và học hỏi về thiết kế hệ thống nha 😄😄😄

Các bạn tham gia để gây dựng cộng đồng System Design Việt Nam thật lớn mạnh nhé 😍😍😍

Cộng Đồng System Design Việt Nam: https://www.facebook.com/groups/sydexa

Kênh TikTok: https://www.tiktok.com/@sydexa.com Kênh youtube: https://www.youtube.com/@sydexa.official

Chương 1: HTTP vs HTTPS - Khác nhau ở đâu nhỉ?

HTTP truyền dữ liệu dạng plain text → dễ bị đánh cắp. Giống như gửi bưu thiếp, ai nhặt được cũng đọc được nội dung.

HTTPS = HTTP + mã hóa → đảm bảo bí mật, toàn vẹn, và xác thực server. Giống như bỏ thư vào hộp khóa, chỉ người có chìa khóa đúng mới đọc được nội dung.

HTTPS dùng 2 loại mã hóa:

Asymmetric (RSA/ECC): Trao đổi key ban đầu (chậm nhưng an toàn)
Symmetric (AES): Mã hóa data thực tế (nhanh)

Vậy câu hỏi là: làm sao client và server trao đổi được "chìa khóa bí mật" qua internet mà không bị lộ? Câu trả lời nằm ở TLS Handshake.

Chương 2: TLS Handshake - Quy trình bắt tay 3 bước

Ví dụ: Giống như bạn gửi mật khẩu ngân hàng cho bạn qua thư, nhưng sợ bị đánh cắp giữa đường.

Quy trình sẽ diễn ra như nào? Trình duyệt của bạn cần “nói chuyện” với server theo các bước sau

(Thực tế handshake gồm nhiều message nhỏ, nhưng ở đây Sydexa gom thành 3 bước dễ hiểu)

Bước 1: "Trình duyệt nói Xin chào, tôi muốn nói chuyện bí mật"

Trình duyệt nói: "Chào server, tôi muốn kết nối an toàn, tôi biết những cách mã hóa này [danh sách cipher suites]"

Bước 2: Server trả lời lại: "OK, mình dùng cách mã hóa này nhé"

Gửi kèm chứng chỉ TLS (giống CMND/CCCD) chứng minh "tôi đúng là sydexa.com", không phải hacker giả mạo
Trong chứng chỉ có public key (ổ khóa công khai)
Gửi các giá trị ngẫu nhiên và tham số ECDHE (trong phương pháp mới – TLS 1.3) để hai bên cùng tạo khóa bí mật chung sau này

Giống việc server gửi về cho bạn 1 cái ổ khóa MỞ (ai cũng khóa được) + CMND photo chứng minh "đúng là tao đây”

⚠️ Quan trọng: Client phải verify certificate tại đây!

Bước 2.5: SSL Certificate Verification (Kiểm tra chứng chỉ)

Trước khi tin tưởng server, trình duyệt phải kiểm tra certificate như kiểm tra CCCD giả:

1. Kiểm tra chữ ký số (Digital Signature)

Certificate được ký bởi Certificate Authority (CA) - giống như Bộ Công An cấp CCCD
Có các CA uy tín là: Let's Encrypt, DigiCert, GlobalSign...
Trình duyệt có sẵn danh sách CA đáng tin (root certificates)

Giống như: CCCD có dấu giáp lai của công an thì mới tin, không tin CCCD photo tự in ở nhà

2. Kiểm tra domain name

Certificate có đúng cho domain đang truy cập không?
Ví dụ: cert của google.com không dùng được cho sydexa.com

3. Kiểm tra thời hạn

Certificate còn hiệu lực không? (chưa expired)
Chưa bị thu hồi (revoked) không?

Nếu verify FAIL → Trình duyệt hiện cảnh báo "Your connection is not private" mà bạn vẫn hay gặp

Nếu verify OK → Tiếp tục bước 3 ✅

Phương pháp cũ: RSA Key Exchange - dùng trong TLS 1.2 và cũ hơn:

Bước 3: "Tôi gửi chìa khóa bí mật trong hộp đã khóa”

Trình duyệt làm những việc sau:

Tạo ra 1 session key (chìa khóa dùng chung) - giống như tạo ra 1 chìa khóa để mở hộp thư của 2 người
Dùng public key từ certificate của server để khóa cái session key này lại (mã hóa bất đối xứng RSA/ECC - chỉ private key mới giải mã được, đảm bảo chỉ server đích nhận được)
Gửi "session key đã được khóa" này cho server

Server dùng private key (chỉ mình nó có) để mở ra và lấy session key.

“Bạn bỏ mật khẩu vào hộp, khóa bằng ổ khóa bạn vừa nhận, gửi lại. Chỉ người có chìa khóa (private key) mới mở được”

Nhược điểm: Nếu sau này private key của server bị lộ, hacker có thể giải mã lại toàn bộ traffic cũ đã lưu lại (không có Perfect Forward Secrecy)

Phương pháp mới: trong TLS 1.3 (phiên bản mới nhất, được dùng phổ biến từ 2018):

Bước 3: "Cùng nhau tạo chìa khóa bí mật”

Thay vì một bên tạo key rồi gửi cho bên kia (dễ bị nghe lén), cả client và server sẽ cùng tính toán ra cùng một session key mà không cần gửi key qua mạng.

Lúc nãy trong Bước 1 và Bước 2, client và server đã “ngầm” gửi cho nhau một số thông tin tạm thời —mỗi bên có một chìa riêng, một chìa công khai và một vài số ngẫu nhiên. Giờ chính những thứ đó sẽ được dùng để tạo ra chìa khóa bí mật chung (session key).

Cách hoạt động (dùng thuật toán Diffie-Hellman Ephemeral - ECDHE):

Client tạo số ngẫu nhiên bí mật (private key tạm) + tính ra một "số công khai"
Server cũng tạo số ngẫu nhiên bí mật (private key tạm) + tính ra một "số công khai"
Client gửi "số công khai" của mình cho Server
Server gửi "số công khai" của mình cho Client + ký lên nó bằng private key từ certificate để chống giả mạo
Client dùng: số bí mật của mình + số công khai của server → tính ra session key
Server dùng: số bí mật của mình + số công khai của client → tính ra session key
Kỳ diệu: Cả hai tính ra được cùng một session key!

Giống như Bạn và người yêu muốn tạo ra một màu bí mật chung để nhận diện nhau:

Bạn có màu bí mật riêng (đỏ), người yêu có màu bí mật riêng (xanh)
Cả hai cùng có màu vàng công khai (ai cũng biết)
Bạn trộn: đỏ + vàng = cam, gửi cam cho người yêu
Người yêu trộn: xanh + vàng = lục, gửi lục cho bạn
Bạn trộn: đỏ (bí mật) + lục (nhận được) = nâu
Người yêu trộn: xanh (bí mật) + cam (nhận được) = nâu
Cả hai có màu nâu giống nhau! Kẻ nghe lén chỉ thấy cam, lục, vàng → không tính ra được nâu

Ưu điểm của ECDHE:

✅ Kẻ nghe lén không thể tính ra session key (chỉ thấy số công khai)
✅ Perfect Forward Secrecy: Ngay cả khi sau này private key của server bị lộ, các session cũ vẫn an toàn vì dùng số ngẫu nhiên tạm thời

Xong! Giờ cả 2 đều có session key giống nhau. Từ giờ mọi tin nhắn đều mã hóa bằng key này (nhanh và an toàn).

Và đó là quy trình bắt tay 3 bước để client và server trao đổi "chìa khóa bí mật" một cách an toàn qua internet không an toàn. Sau khi có session key chung, mọi dữ liệu HTTP thực sự (request/response) mới bắt đầu được gửi đi - tất cả đều được mã hóa.

Chương 3: Final thoughts: Vậy nếu không có bước Certificate Verification (Kiểm tra chứng chỉ) thì sao?

Không có verification, hacker có thể làm Man-in-the-Middle Attack:

Bạn nghĩ đang kết nối bank.com
Hacker chặn giữa đường, gửi certificate giả
Bạn gửi mật khẩu → Hacker đọc được → Game over

Nhờ CA verification → Hacker không thể giả mạo certificate vì không có chữ ký của CA!

Nếu thấy bài viết này hay thì cho chúng mình xin 1 upvote và comment để chúng mình có động lực viết nhiều bài hay hơn nha 😄😄😄

Lời nhắn