Chức năng của thành phần trong ngăn xếp giao thức TLS
TLS record protocol (giao thức bản ghi TLS): cấp tính tin cậy và tính ngun vẹn. Nó điều khiển phân mảnh và nén dữ liệu ứng dụng.
TLS Handshake Protocol (Bắt tay giao thức TLS): Định nghĩa các thỏa thuận mã hóa và hàm băm an tồn và các khóa mã hóa được sử dụng để bảo vệ dữ liệu.
Change Cipher Spec Protocol (giao thức thay đổi đặc tính khóa): Bao gồm các bản tin chứa các byte. Các bản tin ln được gửi giữa hai thực thể, trong q trình hình thành kết TLS nó thơng báo các thực thể khác về bộ khóa thỏa thuận sẽ được dùng sau khi nhận bản tin này.
Alert Protocol (giao thức cảnh báo): Dùng để gửi TLS liên quan tới việc cảnh báo các thực thể khác. Mỗi cảnh báo có các mức độ khác nhau, có thể là cực kỳ nguy hiểm. Nếu là cảnh báo cực kỳ nguy hiểm thì kết nối TLS sẽ bị kết thúc ngay lập tức.
b. TLS Handshake (thủ tục bắt tay TLS)
TLS Handshake định nghĩa bản tin được client và server dùng để nhận thực, thỏa thuận hàm băm an toàn và thuật tốn mã hóa và cung cấp cho nhau dữ liệu bí mật để tạo các khóa mã hóa. Khóa mã hóa được sử dụng với các thuật toán đã thỏa thuận bởi
Hình 3.17 Các bản tin trong handshake
Luồng bản tin gửi trong quá trình bắt tay được chỉ ra trong hình trên và các luồng bản tin có thể chia thành 4 pha như sau: pha 1: thiết lập quan hệ bảo mật. Pha 2: nhận thực Server và trao đổi khóa. Pha 3: nhận thực client và trao đổi khóa. Pha 4: kết thúc.
i. Pha 1: thiết lập bảo mật
Handshake được khởi tạo bởi client, nó gửi bản tin ClientHello. Bản tin này có 5 thơng số, được miêu tả như trong bảng sau.
Tên thông số Mô tả
ProtocolVersion Phiên bản giao thức TLS mà client dùng trong phiên TLS
Random Số ngẫu nhiên có thể được tạo bởi bộ khởi tạo số bảo mật ngẫu nhiên.
SessionID Bộ nhận dạng phiên có chiều dài thay đổi, nó có giá trị bằng 0 nếu như client muốn tạo một kết nối mới trên một phiên mới. Nếu một client muốn tham gia lại một phiên, nó có bộ nhận dạng phiên khác 0.
CipherSuit Nó là danh sách những phần tùy chọn hỗ trợ bởi client. Client ghi ra các phần tử được ưu tiên nhất. Mỗi phần tử lại ghi ra một thuật tốn trao đổi khóa và mơ tả thuật tốn dùng cho việc mã
thod
Bảng 3.7 Các thông số bản tin ClientHello
Khi server nhận bản tin ClientHello, nó chọn một bộ mã hóa được đưa ra bởi client, và chỉ thị nén và chèn chúng vào trong bản tin ServerHello. Bản tin ServerHello có phần tên các thơng số giống như trong bản tin ClientHello. Ngồi bộ mã hóa và chỉ thị nén, server còn tạo một bộ nhận dạng phiên, nếu như thông số SessionID trong bản tin ClientHello được đặt bằng 0, và duy nhất một giá trị Random. Sau đó Server gửi bản tin ServerHello tới client. Và bây giờ, cả hai phía đã thỏa thuận dùng thuật tốn trao đổi khóa, thuật tốn mã hóa đối xứng và hàm băm an toàn.
Cả giao thức TLS Handshake và TLS Record đều dùng hàm băm đảm bảo, nó có thể là MD5 hoặc là SHA-1 cùng với thuật tốn HMAC cung cấp việc bảo vệ tính ngun vẹn bản tin.
ii. Pha 2: Nhận thực Server và trao đổi khóa
Nếu như server lựa chọn nhận thực chính nó với client, nó gửi một khóa xác nhận chung trong bản tin Certificate. Trước khi client và server có thể dùng thuật tốn mã hóa được thỏa thuận, chúng phải thay đổi khóa bí mật bằng cách dùng một trong những những thuật tốn được mơ tả trong hình dưới đây.
Thuật tốn thay đổi khóa
Mơ tả Thay đổi khóa
RSA
Server gửi chứng nhận khóa cơng khai của nó tới client trong một bản tin Certificate. Chứng nhận khóa cơng khai chứa khóa cơng khai RSA của server và được kí hiệu bởi CA
Client kiểm tra chứng nhận khóa cơng khai và dùng khóa cơng khai RSA để mã hóa bảo mật trước tiên. Bảo mật trước tiên đã mã hóa được gửi tới server trong bản tin ClientKeyExchang. Diffie-Hellman
nhanh
• Server gửi chứng nhận khóa cơng khai của nó tới client trong một bản tin Certificate. Chứng nhận khóa cơng khai chứa khóa cơng khai RSA của server và được kí hiệu bởi CA.
• Server khởi tạo khóa cơng khai Diffie-Hellman bằng cách dùng các thơng số Diffie-Hellman hợp lệ. Khóa cơng khai và các thơng số được kí hiệu với khóa riêng của server và gửi tới client trong bản tin ServerKeyExchange.
Diffie-Hellman của nó, bằng cách dùng các thơng số trong bản tin.
• Client gửi khóa cơng khai Diffie-Hellman của nó tới server trong bản tin ClientKeyExchange.
• Cả hai thực thể này thu được bảo mật trước tiên bằng cách dùng thuật toán Diffie-Hellman.
Diffie-Hellman • Server gửi chứng nhận khóa cơng khai của nó tới client trong một bản tin Certificate. Chứng nhận khóa cơng khai chứa khóa cơng khai RSA của server và được kí hiệu bởi CA.
• Client kiểm tra kí hiệu số của chứng nhận khóa cơng khai nhận được.
• Client gửi khóa cơng khai Diffie-Hellman của nó trong bản tin Certificate hoặc là trong bản tin ClientKeyExchange.
• Cả hai thực thể thu được bảo mật đầu tiên bằng cách dùng thuật tốn Diffie-Hellman
Diffie-Hellman ẩn
• Chứng nhận khóa cơng khai khơng được sử dụng.
• Server gửi khóa cơng khai Diffie-Hellman của nó tới client trong bản tin ServerKeyExchange.
• Client gửi khóa cơng khai Diffie-Hellman tới server trong bản tin ClientKeyExchange.
• Cả hai thực thể thu được khóa bảo mật đầu tiên bằng cách dùng thuật tốn Diffie-Hellman.
Bảng 3.8 Mơ tả thuật một số thuật tốn trao đổi khóa dùng trong TLS.
Bản tin CertificateRequest là tùy chọn, được gửi bởi server để yêu cầu khóa xác nhận chung từ client. Bản tin chứa hai danh sách. Danh sách đầu tiên ghi rõ các kiểu khóa xác nhận chung mà server sẽ chấp nhận. Danh sách thứ hai ghi các CA mà server nhận.
Bản tin tiếp theo gửi bởi server đó là bản tin ServerHelloDone. Chức năng của nó chỉ là báo cho client biết rằng server đã gửi tất cả bản tin liên kết với bản tin ServerHello. Sau đó server sẽ đợi client đáp ứng.
iii. Pha 3 Nhận thực client và trao đổi khóa
Nếu như server đã u cầu client nhận thực chính nó với server, client được yêu cầu gửi chứng nhận khóa cơng khai có hiệu lực trong bản tin Certificate. Nếu client
tin Certificate, thì nó gửi một bản tin cảnh báo tới server. Sau đó server có thể quyết định là thủ tục bắt tay có nên tiếp tục hay khơng.
Bản tin ClientKeyExchange ln được gửi bởi client và mục đích của nó là để thực hiện thay đổi bí mật trước tiên. So với bản tin ServerKeyExchange thì nó khơng được kí hiệu.
Và cuối cùng đó là bản tin CertificateVerify, nó được gửi tùy chọn từ client tới server để cấp quyền sở hữu của nó về khóa cơng khai mà đã gửi trong bản tin Certificate trước. Bản tin này có chứa hàm băm MD5 hoặc là SHA-1của toàn bộ bản tin được gửi hoặc là nhận trong quá trình thực hiện thủ tục bắt tay.
iv. Pha 4 Finish
Cả client và server đều biết bảo mật đầu tiên và có thể có thể tính bảo mật chủ. Khi cả hai thực thể đã tính mã bí mật chủ (được tính theo hàm giả ngẫu nhiên), chúng dùng nó để tính khóa mã hóa đối xứng, khóa HMAC và giá trị khởi tạo cho thuật tốn mã hóa.
Khi client đã tính tất cả các khóa, nó gửi bản tin ChangeCipherSpec tới server. Cũng giống như tất cả các bản tin khác được gửi bởi client, lúc này nó sẽ được mã hóa và tính nguyên vẹn được bảo vệ bởi giao thức bản ghi TLS. Sau đó client sẽ gửi bản tin Finish, đây là bản tin cuối cùng được client gửi đi trong quá trình thực hiện thủ tục bắt tay. Bản tin Finish kiểm tra việc trao đổi khóa và nhận thực xử lý đã thành công, bản tin này chứa giá trị hàm băm của tất cả các bản tin đã gửi trong quá trình bắt tay (trừ bản tin Finish).
Khi server nhận bản tin ChangeCipherSpec từ client, nó gửi bản tin này tới client. Về phần client, bây giờ server mã hóa và bảo vệ tồn bộ tất cả các bản tin. Sau đó server kết thúc bắt tay bằng cách gửi bản tin Finish tới client.
d. hoạt động của giao thức bản ghi TLS
Hình sau chỉ ra hoạt động của giao thức bản ghi TLS:
Giao thức này cho phép bản tin được truyền, nó phân mảnh dữ liệu thành các khối được quản lý, nén dữ liệu theo tùy chọn, áp dụng HMAC, thêm header (tiêu đề), và truyền tải các khối TCP (đơn vị truyền của TCP là mảnh).