SSL/TLS hoạt động ra sao?
Bài viết này hệ thống lại một số kiến thức tôi tìm hiểu được sau một thời gian làm việc với SSL. Hy vọng phần nào giúp cho những ai chưa rõ và có nhu cầu tìm hiểu. Bài viết bao gồm:
- Sơ lược về lịch sử để giúp các bạn phân biệt được SSL và TLS
- Các khái niệm: review kiến thức về một số khái niệm bạn cần nắm trước khi đọc phần nội dung chính
- TLS handshake protocol.
TLS: Transport Layer Security, là giao thức bảo mật kênh truyền được phát triển bởi IETF dựa trên SSL 3.0. Phiên bản ổn định: TLS 1.2 (2008), phiên bản mới nhất: TLS 1.3 (2018).
Mặc dù TLS được phát triển dựa trên SSL nhưng 2 giao thức này không thay thế cho nhau. Một số tính năng trên TLS không được hỗ trợ bởi SSL. Năm 2011, IETF khuyên không dùng SSL 2.0. Năm 2015, IETF khuyên không dùng SSL 3.0. TLS là giao thức tiêu chuẩn được IETF công bố và được sử dụng rộng rãi ngày nay.
Trong giao tiếp công việc hàng ngày, có thể bạn hay nghe đôi khi người ta dùng từ SSL, đôi khi dùng từ TLS, nếu không phải trong ngữ cảnh so sánh chúng với nhau thì có lẽ họ đang nói về chung một giao thức. Trong bài viết này tôi sẽ dùng từ TLS.
Mã hóa bất đối xứng, asymmetric encryption, dữ liệu được mã hóa bởi khóa công khai (public key) chỉ có thể được giải mã bằng khóa bí mật (private key) và ngược lại, dữ liệu được mã hóa bởi khóa bí mật chỉ có thể được giải mã bởi khóa công khai. Hình thức mã hóa này an toàn và khó bị bẻ hơn mã hóa đối xứng.
Certificate authority, CA, tạm dịch là nhà cung cấp certificate. Root CA: certificate cấp 1, nhà cung cấp tự cấp cho mình.
- Sơ lược về lịch sử để giúp các bạn phân biệt được SSL và TLS
- Các khái niệm: review kiến thức về một số khái niệm bạn cần nắm trước khi đọc phần nội dung chính
- TLS handshake protocol.
Lịch sử
SSL: Secure Sockets Layer, là một giao thức bảo mật kênh truyền được phát triển bởi Netscape năm 1994. Phiên bản mới nhất của SSL là 3.0 (1996).TLS: Transport Layer Security, là giao thức bảo mật kênh truyền được phát triển bởi IETF dựa trên SSL 3.0. Phiên bản ổn định: TLS 1.2 (2008), phiên bản mới nhất: TLS 1.3 (2018).
Mặc dù TLS được phát triển dựa trên SSL nhưng 2 giao thức này không thay thế cho nhau. Một số tính năng trên TLS không được hỗ trợ bởi SSL. Năm 2011, IETF khuyên không dùng SSL 2.0. Năm 2015, IETF khuyên không dùng SSL 3.0. TLS là giao thức tiêu chuẩn được IETF công bố và được sử dụng rộng rãi ngày nay.
Trong giao tiếp công việc hàng ngày, có thể bạn hay nghe đôi khi người ta dùng từ SSL, đôi khi dùng từ TLS, nếu không phải trong ngữ cảnh so sánh chúng với nhau thì có lẽ họ đang nói về chung một giao thức. Trong bài viết này tôi sẽ dùng từ TLS.
Các khái niệm
Mã hóa đối xứng, symmetric encryption, khóa mã hóa cũng chính là khóa giải mã.Mã hóa bất đối xứng, asymmetric encryption, dữ liệu được mã hóa bởi khóa công khai (public key) chỉ có thể được giải mã bằng khóa bí mật (private key) và ngược lại, dữ liệu được mã hóa bởi khóa bí mật chỉ có thể được giải mã bởi khóa công khai. Hình thức mã hóa này an toàn và khó bị bẻ hơn mã hóa đối xứng.
Certificate authority, CA, tạm dịch là nhà cung cấp certificate. Root CA: certificate cấp 1, nhà cung cấp tự cấp cho mình.
TLS Handshake Protocol
Mục đích: Sau khi thực hiện, server và client sẽ cùng nhau chọn được một khóa đối xứng để mã hóa dữ liệu trao đổi cho nhau. Khóa này chỉ có thời hạn trong 1 phiên làm việc (tạm gọi là session key).
- TLS client gửi bản tin "client hello" có chứa các thông tin cơ bản về khả năng của client như phiên bản SSL/TLS hỗ trợ, các chuẩn mã hóa hỗ trợ, các chuẩn nén hỗ trợ và một chuỗi byte ngẫu nhiên để dùng cho việc tính toán session key sau này.
- TLS server trả lời bằng bản tin "server hello" có chứa một chuẩn mã hóa mà cả client và server đều hỗ trợ và một chuỗi byte ngẫu nhiên do server tự sinh ra. Server cũng gửi certificate của mình cho client thông qua bản tin "server certificate"
Nếu server cần chứng thực client, server sẽ gửi thêm một bản tin "client certificate request" có chứa các loại certificate hỗ trợ và tên phân biệt của các CA được chấp nhận. - Client xác thực certificate của server dựa vào danh sách các root CA được cài đặt sẵn ở máy. (Nếu là thiết lập SSL cho HTTPS thì các root CA được cài đặt sẵn ở trình duyệt)
- Nếu ở bước 2, server có gửi "client certificate request", client sẽ gửi certificate của mình thông qua "client certificate".
- Server xác thực certificate của client.
- Client sinh ra một chuỗi byte ngẫu nhiên gọi là premaster secret, dùng public key của server mã hóa nó và gửi về cho server qua bản tin "client key exchange". Chuỗi byte này dùng để tính toán ra khóa đối xứng dùng cho việc mã hóa dữ liệu kênh truyền: master secret hay là session key.
- Client gửi bản tin "client finished" được mã hóa bằng session key được tạo ra ở bước 6.
- Server gửi bản tin "server finished" cũng được mã hóa bằng session key.
- Kênh truyền mã hóa được thiết lập thành công, tất cả các bản tin sau này đều được mã hóa.
Tìm hiểu thêm tại RFC2246
- Ủa, nếu vậy sao client không tạo ra một cặp khóa bất đối xứng rồi gửi public key cho server, vừa an toàn, vừa tiện lợi, bắt tay chi cho cực vậy rồi lỡ có ai bẻ được khóa thì sao?
- Trả lời: nguyên nhân quan trọng nhất là mã hóa hay giải mã bất đối xứng mất thời gian gắp hàng trăm lần mã hóa hay giải mã đối xứng. Các giao thức của TLS có những cơ chế để đảm bảo độ an toàn cho khóa đối xứng, như dùng chuỗi random từ cả hai phía client và server để đảm bảo độ ngẫu nhiên cho khóa, có yêu cầu về thời gian truyền nhận các message đã mã hóa, có cơ chế sinh khóa khác (không đề cập trong bài viết này) nếu phát hiện bất thường về thời gian truyền nhận... nên cũng phần nào bù đắp cho độ bảo mật so với dùng khóa bất đối xứng.
- Ủa, nếu vậy sao client không tạo ra một cặp khóa bất đối xứng rồi gửi public key cho server, vừa an toàn, vừa tiện lợi, bắt tay chi cho cực vậy rồi lỡ có ai bẻ được khóa thì sao?
- Trả lời: nguyên nhân quan trọng nhất là mã hóa hay giải mã bất đối xứng mất thời gian gắp hàng trăm lần mã hóa hay giải mã đối xứng. Các giao thức của TLS có những cơ chế để đảm bảo độ an toàn cho khóa đối xứng, như dùng chuỗi random từ cả hai phía client và server để đảm bảo độ ngẫu nhiên cho khóa, có yêu cầu về thời gian truyền nhận các message đã mã hóa, có cơ chế sinh khóa khác (không đề cập trong bài viết này) nếu phát hiện bất thường về thời gian truyền nhận... nên cũng phần nào bù đắp cho độ bảo mật so với dùng khóa bất đối xứng.
Comments
Post a Comment