- Arguments: mailbox name (tên hòm thư)
3.4.4 SSL Handshake Protocol
Hình 3.9 SSL
SSL Handshake Protocol là giao thức con SSL chính được xếp lớp trên SSL Record Protocol. Kết quả, các thông báo thiết lập quan hệ SSL được cung cấp cho lớp bản ghi SSL nơi chúng được bao bọc trong một hoặc nhiều bản ghi SSL vốn được xử lý và được chuyển như được xác định bởi phương pháp nén và thông số mật mã của session SSL hiện hành và các khóa mật mã của nối kết SSL tương ứng. Mục đích
Handshake Protocol là yêu cầu một client và server thiết lập và duy trì thông tin trạng thái vốn được sử dụng để bảo vệ các cuộc liên lạc. Cụ thể hơn, giao thức phải yêu cầu client và server chấp thuận một phiên bản giao thức SSL chung, chọn phương thức nén và thông số mật mã, tùy ý xác thực nhau và tạo một khóa mật chính mà từ đó các khóa session khác nhau dành cho việc xác thực và mã hóa thông báo có thể được dẫn xuất từ đó.
Tóm lại, việc thực thi SSL Handshake Protocol giữa một client C và một server S có thể được tóm tắt như sau (các thông báo được đặt trong các dấu ngoặc vuông thì tùy ý): 1: C -> S: CLIENTHELLO 2: S -> C: SERVERHELLO [CERTIFICATE] [SERVERKEYEXCHANGE] [CERTIFICATEREQUEST] SERVERHELLODONE 3: C -> [CERTIFICATE] CLIENTKEYEXCHANGE [CERTIFICATEVERIFY] CHANGECIPHERSPEC FINISHED 4: S -> C: CHANGECIPHERSPEC FINISHED
Khi Client C muốn kết nối với server S, nó thiết lập một nối kết TCP với cổng HTTPS (vốn không được đưa vào phần mô tả giao thức) và gởi một thông báo CLIENTHELLO đến server ở bước 1 của sự thực thi SSL Handshake Protocol.
Client cũng có thể gởi một thông báo CLIENTHELLO nhằm phản hồi lại một thông báo HELLOREQUEST hoặc chủ động thương lượng lại các tham số bảo mật của một nối kết hiện có. Thông báo CLIENTHELLO bao gồm các trường sau đây:
- Số của phiên bản SSL cao nhất được biểu hiện bởi client (thường là 3.0).
- Một cấu trúc ngẫu nhiên do client tạo ra gồm một tem thời gian 32 bit có dạng UNIX chuẩn và một giá trị 28 byte được tạo ra bởi một bộ tạo số giả ngẫu nhiên. - Một định danh session mà client muốn sử dụng cho nối kết này.
- Một danh sách các bộ mật mã client hỗ trợ.
- Một danh sách các phương pháp nén mà client hỗ trợ.
Chú ý rằng trường session identity (định danh session) nên rỗng nếu session SSL hiện không tồn tại hoặc nếu client muốn tạo các tham số bảo mật mới. Ở một trong hai trường hợp, một trường session identity không rỗng là xác định một session SSL hiện có giữa client và server (nghĩa là một session có các tham số bảo mật mà client muốn sử dụng lại.). Định danh session có thể bắt nguồn từ một nối kết trước đó, nối kết này hoặc một nối kết đang hoạt động. Cũng chú ý rằng danh sách các bộ mật mã được hỗ trợ, được chuyển từ client đến server trong thông báo CLIENTHELLO, chứa các tổ hợp thuật toán mật mã được hỗ trợ bởi client theo thứ tự ưu tiêm. Mỗi bộ mật mã xác định một thuật toán trao đổi khóa và một thông báo mật mã. Server sẽ chọn một bộ mật mã hoặc nếu các lựa chọn có thể chấp nhận được không được trình bầy, trả về một thông báo lỗi và đóng nối kết một cách phù hợp. Sau khi đã gởi thông báo CLIENTHELLO, client đợi một thông báo SERVERHELLO. Bất kỳ thông báo khác được trả về bởi server ngoại trừ một thông báo HELLOREQUEST được xem như là một lỗi vào thời điểm này.
Ở bước 2, server xử lý thông báo CLIENTHELLO và đáp ứng bằng một thông báo lỗi hoặc thông báo SERVERHELLO. Tương tự như thông báo CLIENTHELLO, thông báo SERVERHELLO có các trường sau đây:
- Một số phiên bản server chứa phiên bản thấp hơn của phiên bản được đề nghị bởi client trong thông báo CLIENTHELLO và được hỗ trợ cao nhất bởi Server.
- Một cấu trúc ngẫu nhiên do server tạo ra cũng gồm một tem thời gian 32bit có dạng UNIX chuẩn và một giá trị 28bit được tạo ra bởi một bộ tạo số ngẫu nhiên. - Một định danh session tương ứng với nối kết này.
- Một bộ mật mã được chọn từ bởi server từ danh sách các bộ mật mã được hỗ trợ bởi client.
- Một phương pháp nén được chọn bởi server từ danh sách các thuật toán nén được hỗ trợ bởi client.
Nếu định danh session trong thông báo CLIENTHELLO không rỗng, server tìm trong cache session của nó nhằm tìm ra một mục tương hợp. Nếu mục tương hợp được tìm thấy và server muốn thiết lập nối kết mới bằng cách sử dụng trạng thái session tương ứng, server đáp ứng bằng cùng một giá trị như được cung cấp bởi client. Chỉ địn này là một session được tiếp tục lại và xác định rằng cả hai phía phải tiến hành trực tiếp với các thông báo CHANGECIPHERSPEC và FINISHED được trình bày thêm bên dưới. Nếu không, trường này chứa một giá trị khác nhận biết một session mới. Server cũng có thể trả về một trường định danh session rỗng để biểu thị rằng session sẽ không được lưu trữ và do đó không thể được tiếp tục sau đó. Cũng chú ý rằng trong thông báo SERVERHELLO, server chọn một bộ mật mã và một phương pháp nén từ các danh sách được cung cấp bởi client trong thông báo CLIENTHELLO. Các thuật toán trao đổi khóa, xác thực, mã hóa và xác thực thông báo được xác định bởi bộ mã được chọn bởi server và được làm lộ ra trong thông báo SERVERHELLO. Các bộ mật mã vốn đã được xác định trong giao thức SSL về cơ bản giống như bộ mật mã đã xác định cho TLS (như được tóm tắt ở các bản 1.4 đến 1.7 trong những bài viết trước).
Ngoài thông báo SERVERHELLO, server cũng phải gởi các thông báo khác đến client. Ví dụ, nếu server sử dụng sự xác thức dựa vào chứng nhân, server gởi chứng
nhận phải thích hợp cho thuật toán trao đổi khóa của bộ mật mã được chọn và thường là một chứng nhận X.509v3. Cùng loại thông báo sẽ được sử dụng sau đó cho sự đáp ứng của client đối với thông báo sẽ được sử dụng sau đó cho sự đáp ứng của client đối với thông báo CERTIFICATERequest của server. Trong trường hợp của các chứng nhận X.509v3, một chứng nhận có thể thực sự tham chiếu đến toàn bộ một chuỗi các chứng nhận, được sắp xếp theo thứ tự với chứng nhận của đối tượng gởi trước tiên theo sau là bất kỳ chứng nhận CA tiến hành theo trình tự hướng đến một CA gốc (vốn sẽ được chấp nhận bởi client).
Tiếp theo, server có thể gởi một thông báo SERVERKEYEXCHANGE đến client nếu nó không có chứng nhận, một chứng nhận vốn có thể được sử dụng chỉ để xác nhận các chữ ký kỹ thuật số hoặc sử dụng thuật toán trao đổi khóa dựa vào token FORITEZZA (KEA). Rõ ràng, thông báo này không được yêu cầu nếu chứng nhận site gồm một khóa chung RSA vốn có thể được sử dụng trong việc mã hóa. Ngoài ra, một server không nặc danh có thể tùy ý yêu cầu một chứng nhận cá nhân để xác thực client. Do đó, nó gởi một thông báo CERTIFICATERequest đến client. Thông báo này chứa một danh sách các loại chứng nhận được yêu cầu, được phân loại theo thứ tự ưu tiên của server cũng như một danh sách các tên được phân biệt cho các CA có thể chấp nhận. Ở cuối bước 2, server gởi một thông báo SERVERHELLODone đến client để chỉ định sự kết thúc SERVERHELLO và các thông báo đi kèm.
Sau khi nhận SERVERHELLO và các thông báo đi kèm, client xác nhận rằng chứng nhận site server (nếu được cung cấp) là hợp lệ và kiểm tra nhằm bảo đảm rằng các thông số bảo mật được cung cấp trong thông báo SERVERHELLO có thể được chấp nhận. Nếu server yêu cầu sự xác thực client, client gởi một thông báo CERTIFICATE vốn chứa một chứng nhận cá nhân cho khóa chung của người dùng đến server ở bước 3. Tiếp theo, client gởi một thông báo CLIENTK- EYEXCHANGE có dạng phụ thuộc vào thuật toán cho mỗi khóa được chọn bởi server:
- Nếu RSA được sử dụng cho việc xác thực server và trao đổi khóa, client tạo một khóa mật tiền chính 48 byte, mã hóa nó bằng khóa chung được tìm thấy trong chứng nhận site hoặc khóa RSA tạm thời từ thông báo SERVERKE-YEXCHANGE và gởi kết quả trở về server trong thông báo CLIENTKEYE-XCHANGE. Lần lượt server sử dụng khóa riêng tương ứng để giải mã khóa mật chính.
- Nếu các token FORTEZZA được sử dụng để trao đổi khóa, client dẫn xuất một khóa mã hóa token (TEK) bằng cách sử dụng KEA. Phép tình KEA cảu client sử dụng khóa chung từ chứng nhận server cùng với một số tham số riêng trong token của client. Client gởi các tham số chung cần thiết cho server để cũng tạo TEK, sử dụng các tham sô riêng của nó. Nó tạo một khóa mật chính, bao bọc nó bằng cách sử dụng TEK và gởi kết quả cùng với một số vector khởi tạo đến server như là một phần của thông báo CLIENTKEYEXCHANGE. Lần lượt, server có thể giải mã khóa mật chính một cách thích hợp. Thuật toán trao đổi khóa này không được sử dụng rộng rãi.
Nếu sự xác thực client được yêu cầu, client cũng gởi một thông báo CERTIFICATEVERIFY đến server. Thông báo này được sử dụng để cung cấp sự xác thực rõ ràng định danh của người dùng dựa vào chứng nhận các nhân. Nó chỉ được gởi theo sau một chứng chỉ client vốn có khả năng tạo chữ ký (tất cả chứng nhận ngoại trừ các chứng nhận chứa các tham số DiffeHallman cố định). Sau cùng, client hoàn tất bước 3 bằng cách gởi một thông báo CHANGE -CIPHERSPEC và một thông báo FINISHED tương ứng đến server. Thông báo FINISHED luôn được gởi ngay lập tức sau thông báo CHANGECIPERSPEC để xác nhận rằng các tiến trình trao đổi khóa và xác thực đã thành công. Thực tế, thông báo FINISHED là thông báo đầu tiên vốn được bảo vệ bằng các thuật toán mới được thương lượng và các khóa session. Nó chỉ có thể được tạo và được xác nhận nếu những khóa này được cài đặt một cách phù hợp ở cả hai phía. Không đòi hỏi sự báo nhận thông báo FINISHED; các phía có thể bắt đầu gởi dữ liệu được mã hóa ngay lập tức sau khi đã gởi thông báo FINISHED. Việc thực thi SSL Handshake Protocol hoàn tất bằng việc
cũng yêu cầu server gởi một thông báo CHANGECIPHERSPEC và một thông báo FINISHED tương ứng đến client ở bước 4.
Sau khi sự thiết lập SSL hoàn tất, một nối kết an toàn được thiết lập giữa client và server. Nối kết này bây giờ có thể được sử dụng để gởi dữ liệu ứng dụng vốn được bao bọc bởi SSL Record Protocol. Chính xác hơn, dữ liệu ứng dụng có thể được phân đoạn, được nén, hoặc được mã hóa và đước xác thực theo SSL Record Protocol cũng như thông tin trạng thái session và nối kết vốn bây giờ được thiết lập (tùy thuộc việc thực thi SSL Handshake Protocol).
SSL Handshake Protocol có thể được rutst ngắn nếu client và server quyết định tiếp tục lại một session SSL được thiết lập trước đó (và vẫn được lưu trữ) hoặc lặp lại một session SSL hiện có. Trong trường hợp này, chỉ ba dòng thông báo và tổng cộng sáu thông báo được yêu cầu. Các dòng thông báo tương ứng có thể được tóm tắt như sau: 1: C -> S: CLIENTHELLO 2: S -> C: SERVERHELLO CHANECIPHERSPEC FINISHED 3: S ->C: CHANGECIPHERSPEC FINISHED
bước 1, client gởi một thông báo CLIENTHELLO đến server vốn có một định danh session cần được tiếp tục lại. Lần lượt server kiểm tra cache session của nó để tìm một mục tương hợp. Nếu một mục tương hợp được tìm thấy, server muốn tiếp tục lại nối kết bên dưới trạng thái session đã xác định, nó trả về một thông báo SERVERHELLO với cùng một định danh session ở bước 2. Vào thời điểm này, cả client lẫn server phải gởi các thông báo CHANGECIPHERSPEC và FINISHED đến nhau ở bước 2 và 3. Một khi việc tái thiết lập session hoàn tất, client và server có thể bắt đầu trao đổi dữ liệu ứng dung.