Tweet
SSL Handshake hoạt động như thế nào?
Hình trên mô tả phiên bản rút gọn của quá trình SSL/TLS Handshake giữa Client và Server. Đây là giai đoạn hai bên "bắt tay" để thống nhất cách bảo mật trước khi truyền dữ liệu ứng dụng.
Client kết nối đến Server và gửi Client Hello.
Thông điệp này về cơ bản nói rằng:
"Tôi muốn thiết lập một kết nối bảo mật. Đây là phiên bản TLS, các Cipher Suite và các khả năng mật mã mà tôi hỗ trợ."
Client Hello thường chứa các thông tin như TLS version, danh sách Cipher Suite, Client Random và các TLS Extension.
2. Server Hello – Server lựa chọn
Server nhận Client Hello và trả về Server Hello.
Server lựa chọn các tham số phù hợp mà cả hai bên cùng hỗ trợ, chẳng hạn phiên bản TLS và Cipher Suite.
Server cũng gửi Server Random. Client Random và Server Random sau đó tham gia vào quá trình tạo ra các khóa phiên (session keys).
3. Certificate – Server chứng minh danh tính
Server gửi Digital Certificate cho Client.
Certificate thường chứa Public Key của Server cùng các thông tin nhận dạng và chữ ký số của CA.
Client cần kiểm tra những vấn đề quan trọng như Certificate có còn hạn hay không, hostname có khớp hay không và Certificate có được ký bởi CA mà Client tin cậy hay không.
Đây là bước rất quan trọng để chống lại Man-in-the-Middle Attack. 4. Server Hello Done – Server hoàn tất phần thương lượng ban đầu
Trong TLS 1.2 và các phiên bản cũ, Server Hello Done thông báo rằng Server đã gửi xong các thông tin cần thiết trong giai đoạn này và đang chờ Client tiếp tục quá trình handshake.
Trong một handshake đầy đủ, tùy Cipher Suite, sơ đồ thực tế có thể còn có các message như Server Key Exchange, Client Key Exchange... Hình trên đã cố tình lược bỏ chúng.
5. Change Cipher Spec – Chuyển sang kết nối được bảo vệ
Sau khi quá trình trao đổi khóa hoàn tất và hai bên đã tạo được các session key cần thiết, Change Cipher Spec báo hiệu việc chuyển sang sử dụng các tham số mật mã vừa thương lượng.
Từ đây, các thông điệp tiếp theo có thể được bảo vệ bằng các khóa phiên.
Sơ đồ trên tiếp tục được giản lược vì handshake TLS 1.2 thực tế còn có Finished message ở cả hai phía.
6. Application Data – Bắt đầu truyền dữ liệu
Sau khi handshake thành công, Client và Server bắt đầu trao đổi Application Data.
Ví dụ với HTTPS:
HTTP Data → TLS Encryption → TCP → IP
Lúc này, dữ liệu ứng dụng không còn được truyền dưới dạng plaintext trên mạng mà được TLS bảo vệ về Confidentiality và Integrity.
Điểm quan trọng: TLS không dùng Public Key để mã hóa toàn bộ dữ liệu
Đây là điểm người học Security rất dễ hiểu nhầm.
Asymmetric Cryptography chủ yếu được sử dụng trong quá trình xác thực và thiết lập/trao đổi bí mật để tạo khóa phiên. Sau đó Symmetric Cryptography như AES mới được sử dụng để bảo vệ lượng lớn Application Data.
Lý do rất đơn giản: mã hóa đối xứng nhanh và hiệu quả hơn nhiều.
Có thể nhớ toàn bộ quá trình bằng chuỗi:
Client Hello → Server Hello → Certificate → Key Establishment → Session Keys → Encrypted Application Data
Và nếu nhìn ở góc độ Security Engineer:
Certificate giải quyết bài toán "Tôi đang nói chuyện với ai?"
Key Exchange giải quyết bài toán "Hai bên tạo bí mật chung bằng cách nào?"
Symmetric Encryption giải quyết bài toán "Làm sao truyền lượng lớn dữ liệu an toàn và hiệu quả?"
Đó chính là nền tảng mật mã phía sau HTTPS, SSL VPN và rất nhiều hệ thống bảo mật sử dụng TLS hiện nay.
Hình trên mô tả phiên bản rút gọn của quá trình SSL/TLS Handshake giữa Client và Server. Đây là giai đoạn hai bên "bắt tay" để thống nhất cách bảo mật trước khi truyền dữ liệu ứng dụng.
Lưu ý: sơ đồ sử dụng các bản tin như Server Hello Done và Change Cipher Spec, nên về mặt kỹ thuật nó gần với TLS 1.2/SSL truyền thống, không phải quy trình TLS 1.3 hiện đại.
1. Client Hello – Client mở đầu cuộc thương lượngClient kết nối đến Server và gửi Client Hello.
Thông điệp này về cơ bản nói rằng:
"Tôi muốn thiết lập một kết nối bảo mật. Đây là phiên bản TLS, các Cipher Suite và các khả năng mật mã mà tôi hỗ trợ."
Client Hello thường chứa các thông tin như TLS version, danh sách Cipher Suite, Client Random và các TLS Extension.
2. Server Hello – Server lựa chọn
Server nhận Client Hello và trả về Server Hello.
Server lựa chọn các tham số phù hợp mà cả hai bên cùng hỗ trợ, chẳng hạn phiên bản TLS và Cipher Suite.
Server cũng gửi Server Random. Client Random và Server Random sau đó tham gia vào quá trình tạo ra các khóa phiên (session keys).
3. Certificate – Server chứng minh danh tính
Server gửi Digital Certificate cho Client.
Certificate thường chứa Public Key của Server cùng các thông tin nhận dạng và chữ ký số của CA.
Client cần kiểm tra những vấn đề quan trọng như Certificate có còn hạn hay không, hostname có khớp hay không và Certificate có được ký bởi CA mà Client tin cậy hay không.
Đây là bước rất quan trọng để chống lại Man-in-the-Middle Attack. 4. Server Hello Done – Server hoàn tất phần thương lượng ban đầu
Trong TLS 1.2 và các phiên bản cũ, Server Hello Done thông báo rằng Server đã gửi xong các thông tin cần thiết trong giai đoạn này và đang chờ Client tiếp tục quá trình handshake.
Trong một handshake đầy đủ, tùy Cipher Suite, sơ đồ thực tế có thể còn có các message như Server Key Exchange, Client Key Exchange... Hình trên đã cố tình lược bỏ chúng.
5. Change Cipher Spec – Chuyển sang kết nối được bảo vệ
Sau khi quá trình trao đổi khóa hoàn tất và hai bên đã tạo được các session key cần thiết, Change Cipher Spec báo hiệu việc chuyển sang sử dụng các tham số mật mã vừa thương lượng.
Từ đây, các thông điệp tiếp theo có thể được bảo vệ bằng các khóa phiên.
Sơ đồ trên tiếp tục được giản lược vì handshake TLS 1.2 thực tế còn có Finished message ở cả hai phía.
6. Application Data – Bắt đầu truyền dữ liệu
Sau khi handshake thành công, Client và Server bắt đầu trao đổi Application Data.
Ví dụ với HTTPS:
HTTP Data → TLS Encryption → TCP → IP
Lúc này, dữ liệu ứng dụng không còn được truyền dưới dạng plaintext trên mạng mà được TLS bảo vệ về Confidentiality và Integrity.
Điểm quan trọng: TLS không dùng Public Key để mã hóa toàn bộ dữ liệu
Đây là điểm người học Security rất dễ hiểu nhầm.
Asymmetric Cryptography chủ yếu được sử dụng trong quá trình xác thực và thiết lập/trao đổi bí mật để tạo khóa phiên. Sau đó Symmetric Cryptography như AES mới được sử dụng để bảo vệ lượng lớn Application Data.
Lý do rất đơn giản: mã hóa đối xứng nhanh và hiệu quả hơn nhiều.
Có thể nhớ toàn bộ quá trình bằng chuỗi:
Client Hello → Server Hello → Certificate → Key Establishment → Session Keys → Encrypted Application Data
Và nếu nhìn ở góc độ Security Engineer:
Certificate giải quyết bài toán "Tôi đang nói chuyện với ai?"
Key Exchange giải quyết bài toán "Hai bên tạo bí mật chung bằng cách nào?"
Symmetric Encryption giải quyết bài toán "Làm sao truyền lượng lớn dữ liệu an toàn và hiệu quả?"
Đó chính là nền tảng mật mã phía sau HTTPS, SSL VPN và rất nhiều hệ thống bảo mật sử dụng TLS hiện nay.
Attached Files