SSL Handshake Protocol [8, 20] 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 đƣợ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 kết nối SSL tƣơng ứng. Mục đích của SSL 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 đƣợ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 chọn): 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 kết nối TCP với cổng HTTPS (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 kết nối 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 kết nối 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 kết nối trƣớc đó, kết nối này hoặc một kết nối đ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ên. 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 kết nối một cách phù hợp. Sau khi đa 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 kết nối này.
– Một bộ mật mã đƣợc chọn 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 kết nối 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ỉ định 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ã hoá đƣợc chọn bởi server và đƣợc gửi trong thông báo SERVERHELLO.
Các bộ mã hoá đã đƣợc xác định trong giao thức SSL về cơ bản giống nhƣ bộ mã hoá đã xác định cho TLS.
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 chỉ số, server gửi chứng chỉ số site của nó đến client trong một thông báo CERTIFICATE tƣơng ứng. Chứng chỉ số phải thích hợp cho thuật toán trao đổi khóa của bộ mã hoá đƣợc chọn và thƣờng là một chứng chỉ số 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 chỉ số có thể thực sự tham chiếu đến toàn bộ một chuỗi các chứng chỉ số, đƣợc sắp xếp theo thứ tự với chứng chỉ số của đối tƣợng gửi trƣớc tiên theo sau là bất kỳ chứng chỉ số CA tiến hành theo trình tự hƣớng đến một CA gốc (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 chỉ số, một chứng chỉ số có thể đƣợc sử dụng chỉ để xác nhận các chữ ký kỹ 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 chỉ số site gồm một khóa chung RSA 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 chỉ số 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 chỉ số đƣợ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 chỉ số 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 chứa một chứng chỉ số 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 CLIENTKEYEXCHANGE 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 premaster 48 byte, mã hóa nó bằng khóa chung đƣợc tìm thấy trong chứng chỉ số site hoặc khóa RSA tạm thời từ thông báo SERVERKEYEXCHANGE và gửi kết quả trở về server trong thông báo CLIENTKEYEXCHANGE. 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 chỉ số 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 master, 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 master 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 chỉ số cá nhân. Nó chỉ đƣợc gửi theo sau một chứng chỉ client có khả năng tạo chữ ký (tất cả chứng nhận ngoại trừ các chứng chỉ số chứa các tham số Diffie - Hellman 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 CHANGECIPHERSPEC 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 đa thành công. Thực tế, thông báo FINISHED là thông báo đầu tiên đƣợc bảo vệ bằng các thuật toán mới đƣợc thoả thuận 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 đoi hỏi sự xác 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 đa gửi thông báo FINISHED. Việc thực thi SSL Handshake Protocol hoàn tất bằng việc 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 kết nối an toàn đƣợc thiết lập giữa client và server. Kết nối này bây giờ có thể đƣợc sử dụng để gửi dữ liệu ứng dụng. 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à kết nối 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 rút 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 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 kết nối 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 dụng.
Các thuật toán mã hoá và xác thực của SSL đƣợc sử dụng bao gồm (phiên bản 3.0):
DES: chuẩn mã hoá dữ liệu (ra đời năm 1977), phát minh và sử dụng của chính phủ Mỹ.
DSA: thuật toán chữ ký điện tử, chuẩn xác thực điện tử, phát minh và sử dụng của chính phủ Mỹ.
KEA: thuật toán trao đổi khoá, phát minh và sử dụng của chính phủ Mỹ. MD5: thuật toán tạo giá trị “băm” (message digest), phát minh bởi Rivest. RC2, RC4: mã hoá Rivest, phát triển bởi công ty RSA Data Security.
RSA: thuật toán khoá công khai, cho mã hoá và xác thực, phát triển bởi Rivest, Shamir và Adleman.
RSA key exchange: thuật toán trao đổi khoá cho SSL dựa trên thuật toán RSA.
SHA-1: thuật toán hàm băm an toàn, phát triển và sử dụng bởi chính phủ Mỹ.
SKIPJACK: thuật toán khoá đối xứng phân loại đƣợc thực hiện trong phần cứng Fortezza, sử dụng bởi chính phủ Mỹ.
Triple-DES: mã hoá DES ba lần.
Cơ sở lý thuyết và cơ chế hoạt động của các thuật toán sử dụng về bảo mật trên hiện nay là phổ biến rộng rãi và công khai, trừ các giải pháp thực hiện trong ứng dụng thực hành vào trong các sản phẩm bảo mật (phần cứng, phần mềm).