Rate this post

SSL bắt nguồn từ Netscape. Phiên bản 3 của giao thức được thiết kế với sự đánh giá công khai và đầu vào từ ngành công nghiệp và đã được xuất bản dưới dạng tài liệu dự thảo trên Internet. Sau đó, khi đạt được sự đồng thuận để đệ trình giao thức chuẩn hóa Internet, nhóm công tác TLS được thành lập trong IETF để phát triển một tiêu chuẩn chung. Phiên bản TLS được xuất bản đầu tiên này về cơ bản có thể được coi là SSLv3.1 và rất gần và tương thích ngược với SSLv3.

Phần này dành cho thảo luận về SSLv3. Trong phần tiếp theo, sự khác biệt chính giữa SSLv3 và TLS được mô tả.

Các bài viết liên quan:

Tóm tắt nội dung

Kiến trúc SSL

SSL được thiết kế để sử dụng TCP để cung cấp dịch vụ bảo mật đầu cuối đáng tin cậy. SSL không phải là một giao thức đơn lẻ mà là hai lớp giao thức, như được minh họa trong Hình dưới.

The SSL Record Protocol cung cấp các dịch vụ bảo mật cơ bản cho các giao thức lớp cao hơn khác nhau. Đặc biệt, Giao thức truyền siêu văn bản (HTTP), cung cấp dịch vụ truyền cho tương tác máy khách / máy chủ Web, có thể hoạt động trên SSL. Ba giao thức lớp cao hơn được định nghĩa là một phần của SSL: Giao thức Bắt tay, Giao thức Thông số Mật mã Thay đổi và Giao thức Cảnh báo. Các giao thức đặc biệt SSL này được sử dụng trong việc quản lý các trao đổi SSL và sẽ được xem xét sau trong phần này.

Hai khái niệm SSL quan trọng là phiên SSL và kết nối SSL, được định nghĩa trong thông số kỹ thuật như sau.

Connection: Kết nối là phương tiện vận chuyển (theo định nghĩa của mô hình phân lớp OSI) cung cấp loại dịch vụ phù hợp. Đối với SSL, các kết nối như vậy là các mối quan hệ ngang hàng. Các kết nối là thoáng qua. Mọi kết nối được liên kết với một phiên.
Session: Phiên SSL là một liên kết giữa máy khách và máy chủ. Các phiên được tạo bởi Giao thức Bắt tay. Phiên xác định một tập hợp các mật mã

các tham số bảo mật có thể được chia sẻ giữa nhiều kết nối. Các phiên được sử dụng để tránh việc thương lượng tốn kém các tham số bảo mật mới cho mỗi kết nối.

Giữa bất kỳ cặp bên nào (các ứng dụng như HTTP trên máy khách và máy chủ), có thể có nhiều kết nối an toàn. Về lý thuyết, cũng có thể có nhiều phiên đồng thời giữa các bên, nhưng tính năng này không được sử dụng trong thực tế.

Có một số trạng thái được liên kết với mỗi phiên. Khi một phiên được thiết lập, sẽ có trạng thái hoạt động hiện tại cho cả đọc và ghi (tức là nhận và gửi). Ngoài ra, trong Giao thức Bắt tay, các trạng thái đọc và ghi đang chờ xử lý được tạo ra. Sau khi kết thúc thành công Handshake Protocol, các trạng thái đang chờ xử lý sẽ trở thành trạng thái hiện tại.

Trạng thái phiên được xác định bởi các tham số sau.

Session identifier: Một chuỗi byte tùy ý được chọn bởi máy chủ để xác định trạng thái phiên hoạt động hoặc có thể tiếp tục.
Peer certificate: Chứng chỉ X509.v3 của người ngang hàng. Phần tử này của trạng thái có thể là rỗng.
Compression method: Thuật toán được sử dụng để nén dữ liệu trước khi mã hóa.
Cipher spec: Chỉ định thuật toán mã hóa dữ liệu hàng loạt (chẳng hạn như null, AES, v.v.) và thuật toán băm (chẳng hạn như MD5 hoặc SHA-1) được sử dụng để tính toán MAC. Nó cũng xác định các thuộc tính mật mã như hash_size.
Master secret: bí mật 48 byte được chia sẻ giữa máy khách và máy chủ.
Is resumable: Một cờ cho biết liệu phiên có thể được sử dụng để bắt đầu các kết nối mới.

Trạng thái kết nối được xác định bởi các tham số sau.

Server and client random: Trình tự theo từng byte được máy chủ và máy khách chọn cho mỗi kết nối.
Server write MAC secret: Khóa bí mật được sử dụng trong các hoạt động MAC trên dữ liệu được gửi bởi máy chủ.
Client write MAC secret: Khóa bí mật được sử dụng trong các hoạt động MAC trên dữ liệu do máy khách gửi.
Server write key: Khóa mã hóa bí mật cho dữ liệu được máy chủ mã hóa và máy khách giải mã.
Client write key: Khóa mã hóa đối xứng cho dữ liệu được máy khách mã hóa và máy chủ giải mã.
Initialization vectors: Khi sử dụng mật mã khối ở chế độ CBC, một vectơ khởi tạo (IV) được duy trì cho mỗi khóa. Trường này được khởi tạo lần đầu tiên bởi Giao thức Bắt tay SSL. Sau đó, khối bản mã cuối cùng từ mỗi bản ghi được giữ lại để sử dụng như IV với bản ghi sau.

Sequence numbers: Mỗi bên duy trì các số thứ tự riêng biệt cho truyền và nhận tin nhắn cho mỗi kết nối. Khi một bên gửi hoặc nhận một thông báo thông số kỹ thuật mật mã thay đổi, số thứ tự thích hợp được đặt thành không. Số thứ tự không được vượt quá 2⁶⁴ – 1.

Các bài viết khác:

SSL Record Protocol

Giao thức Bản ghi SSL cung cấp hai dịch vụ cho các kết nối SSL:

Tính bảo mật: Giao thức Bắt tay xác định một khóa bí mật được chia sẻ được sử dụng để mã hóa thông thường các tải trọng SSL.
Tính toàn vẹn của thông báo: Giao thức bắt tay cũng xác định khóa bí mật được chia sẻ được sử dụng để tạo mã xác thực thông báo (MAC).

Hình dưới chỉ ra hoạt động tổng thể của SSL Record Protocol. SSL Record Protocol nhận một thông điệp ứng dụng được truyền đi, phân mảnh dữ liệu thành các khối có thể quản lý, tùy chọn nén dữ liệu, áp dụng MAC, mã hóa, thêm tiêu đề và truyền đơn vị kết quả trong một phân đoạn TCP. Dữ liệu nhận được sẽ được giải mã, xác minh, giải nén và tập hợp lại trước khi chuyển đến người dùng cấp cao hơn.

Bước đầu tiên là phân mảnh. Mỗi thông báo lớp trên được phân mảnh thành các khối có kích thước từ 2¹⁴ byte (16384 byte) trở xuống. Tiếp theo, tùy chọn nén được áp dụng. Nén phải không mất dữ liệu và không được làm tăng độ dài nội dung quá 1024 byte. Trong SSLv3 (cũng như phiên bản TLS hiện tại), không có thuật toán nén nào được chỉ định, vì vậy thuật toán nén mặc định là null.

Bước tiếp theo trong quá trình xử lý là tính toán mã xác thực tin nhắn qua dữ liệu nén. Vì mục đích này, một khóa bí mật được chia sẻ được sử dụng. Phép tính được định nghĩa là

Lưu ý rằng điều này rất giống với thuật toán HMAC. Sự khác biệt là hai miếng đệm được ghép nối trong SSLv3 và được XORed trong HMAC. Thuật toán SSLv3 MAC dựa trên bản nháp Internet ban đầu cho HMAC, thuật toán này đã sử dụng phép nối. Phiên bản cuối cùng của HMAC (được định nghĩa trong RFC 2104) sử dụng XOR.

Tiếp theo, tin nhắn nén cộng với MAC được mã hóa bằng mã hóa đối xứng. Mã hóa không được làm tăng độ dài nội dung hơn 1024byte, để tổng độ dài không được vượt quá 2¹⁴ + 2048. Mã hóa sau thuật toán được phép:

Block cipher	Stream cipher
Thuật toán	Kích thước khóa	Thuật toán	Kích thước khóa
AES	128, 256	RC4-40	40
IDEA	128	RC4-128	128
RC2-40	40
DES-40	40
DES	56
3DES	168
Fortezza	80

Đối với mã hóa luồng, tin nhắn nén cộng với MAC được mã hóa. Lưu ý rằng MAC được tính toán trước khi quá trình mã hóa diễn ra và MAC sau đó được mã hóa cùng với bản rõ hoặc bản rõ nén.

Đối với mã hóa khối, đệm có thể được thêm vào sau MAC trước khi mã hóa- sự. Phần đệm có dạng một số byte đệm theo sau là một byte chỉ dẫn về chiều dài của phần đệm.

Tổng lượng đệm là nhỏ nhất số lượng sao cho tổng kích thước của dữ liệu được mã hóa (bản rõ cộng với MAC cộng với phần đệm) là bội số của độ dài khối của mật mã. Một ví dụ là bản rõ (hoặc văn bản nén nếu sử dụng tính năng nén) 58 byte, với MAC là 20 byte (sử dụng SHA-1), được mã hóa bằng cách sử dụng độ dài khối 8 byte (ví dụ: DES). Với byte độ dài phần đệm, điều này mang lại tổng cộng 79 byte. Để làm cho tổng số nguyên là bội số của 8, một byte đệm được thêm vào.

Bước cuối cùng của quá trình xử lý Giao thức Bản ghi SSL là chuẩn bị một tiêu đề bao gồm các trường sau:

Content Type (8 bit): Giao thức lớp cao hơn được sử dụng để xử lý phân đoạn kèm theo.
Content Type (8 bit): Cho biết phiên bản SSL chính đang được sử dụng. Đối với SSLv3, giá trị là 3.
Minor Version (8 bit): Cho biết phiên bản nhỏ đang được sử dụng. Đối với SSLv3, giá trị là 0.
Compressed Length (16 bit): độ dài tính bằng byte của đoạn văn bản rõ (hoặc nén phân mảnh nếu nén được sử dụng). Giá trị lớn nhất là 214 + 2048.

Các loại nội dung đã được xác định là change_cipher_spec, change_cipher_spec,
alert, handshake, and application_data. Ba giao thức đầu tiên là các giao thức dành riêng cho SSL, sẽ được thảo luận tiếp theo. Lưu ý rằng không có sự phân biệt nào giữa các ứng dụng khác nhau (ví dụ: HTTP) có thể sử dụng SSL; nội dung của dữ liệu được tạo bởi các ứng dụng đó là không rõ ràng đối với SSL.

Change Cipher Spec Protocol

Change Cipher Spec Protocol là một trong ba giao thức dành riêng cho SSL sử dụng Giao thức bản ghi SSL và nó là giao thức đơn giản nhất. Giao thức này bao gồm mộtthông báo, bao gồm một byte đơn với giá trị 1. Mục đích duy nhất của thông báo này là làm cho trạng thái đang chờ xử lý được sao chép vào trạng thái hiện tại, cập nhật bộ mật mã sẽ được sử dụng trên sự liên quan.

Alert Protocol

The Alert Protocol được sử dụng để chuyển các cảnh báo liên quan đến SSL đến thực thể ngang hàng. Cũng như các ứng dụng khác sử dụng SSL, thông báo cảnh báo được nén và mã hóa theo trạng thái hiện tại.

Mỗi thông báo trong giao thức này bao gồm hai byte (Hình 16.5b). Người đầu tiênbyte nhận giá trị cảnh báo (1) hoặc nghiêm trọng (2) để truyền đạt mức độ nghiêm trọng của thông báo. Nếu mức nghiêm trọng, SSL sẽ chấm dứt kết nối ngay lập tức. Các kết nối khác trong cùng một phiên có thể tiếp tục, nhưng không có kết nối mới nào trong phiên này có thể được thiết lập. Byte thứ hai chứa một mã cho biết cảnh báo cụ thể. Đầu tiên, chúng tôi liệt kê những cảnh báo luôn nguy hiểm (định nghĩa từ đặc tả SSL):

unexpected_message: Đã nhận được một thông báo không thích hợp.
bad_record_mac: Đã nhận được MAC không chính xác.
decompression_failure: Hàm giải nén nhận được đầu vào không thích hợp (ví dụ: không thể giải nén hoặc giải nén lớn hơn độ dài tối đa cho phép).
handshake_failure: Người gửi không thể thương lượng một tập hợp các thông số bảo mật có thể chấp nhận được với các tùy chọn có sẵn.
rule_parameter: Một trường trong thông báo bắt tay nằm ngoài phạm vi hoặc không nhất quán với các trường khác.

Các cảnh báo còn lại như sau.

close_notify: Thông báo cho người nhận rằng người gửi sẽ không gửi thêm bất kỳ tin nhắn nào trên kết nối này. Mỗi bên được yêu cầu gửi mộtcảnh báo close_notify trước khi đóng phía ghi của một kết nối.
no_certificate: Có thể được gửi theo yêu cầu chứng chỉ nếu không có chứng chỉ thích hợp.
bad_certificate: Chứng chỉ nhận được bị hỏng (ví dụ: chứa chữ ký không xác minh).
unsupported_certificate: Loại chứng chỉ đã nhận không được hỗ trợ.
certificate_revoked: Chứng chỉ đã bị người ký của nó thu hồi.
certificate_expired: Một chứng chỉ đã hết hạn.
certificate_unknown: Một số vấn đề không xác định khác đã phát sinh trong quá trình xử lý chứng chỉ, khiến nó không thể chấp nhận được.

Xem thêm Kiểm tra lỗ hổng bảo mật Weak Transport Layer Security

Handshake Protocol

Phần phức tạp nhất của SSL là Giao thức Bắt tay. Giao thức này cho phép máy chủ và máy khách xác thực lẫn nhau và thương lượng thuật toán mã hóa và MAC và các khóa mật mã được sử dụng để bảo vệ dữ liệu được gửi trong bản ghi SSL. Giao thức Bắt tay được sử dụng trước khi bất kỳ dữ liệu ứng dụng nào được truyền đi.

Giao thức Bắt tay bao gồm một loạt các thông điệp được trao đổi bởi máy khách và máy chủ. Tất cả chúng đều có định dạng như trong Hình 16.5c. Mỗi thông báo có ba trường:

Loại (1 byte): Cho biết một trong 10 thông điệp. Bảng 16.2 liệt kê các kiểu thông báo được xác định.
Độ dài (3 byte): Độ dài của tin nhắn tính bằng byte.
Nội dung (>= 0 byte): Các tham số liên quan đến thông báo này; đó là được liệt kê trong bảng.

Bảng dưới cho thấy sự trao đổi ban đầu cần thiết để thiết lập một kết nối logic giữa máy khách và máy chủ. Việc trao đổi có thể được xem như có bốn giai đoạn.

Giai đoạn 1- ESTABLISH SECURITY CAPABILITIES

Giai đoạn này được sử dụng để bắt đầu một kết nối logic và thiết lập các khả năng bảo mật sẽ được liên kết với nó. Việc trao đổi được bắt đầu bởi khách hàng, sẽ gửi một tin nhắn client_hello với các tham số sau:

Phiên bản: Phiên bản SSL cao nhất mà khách hàng hiểu được.
Ngẫu nhiên: Cấu trúc ngẫu nhiên do máy khách tạo ra bao gồm dấu thời gian 32 bit và 28 byte được tạo bởi trình tạo số ngẫu nhiên an toàn. Các giá trị này đóng vai trò là các ký tự khác và được sử dụng trong quá trình trao đổi khóa để ngăn chặn các cuộc tấn công replay.
Session ID: Giá trị nhận dạng phiên có độ dài thay đổi. Giá trị khác không cho biết rằng máy khách muốn cập nhật các thông số của kết nối hiện có hoặctạo một kết nối mới trên phiên này. Giá trị 0 chỉ ra rằng máy khách muốn thiết lập một kết nối mới trên một phiên mới.
CipherSuite: Đây là danh sách chứa các kết hợp các thuật toán mật mã được hỗ trợ bởi máy khách, theo thứ tự ưu tiên giảm dần. Mỗi phần tử của danh sách (mỗi bộ mật mã) xác định cả thuật toán trao đổi khóa và CipherSpec; những điều này sẽ được thảo luận sau đó.
Compression Method: Đây là danh sách các phương pháp nén mà máy khách hỗ trợ.

Sau khi gửi thông báo client_hello, ứng dụng sẽ đợi thông báo server_hello, chứa các thông số tương tự như tin nhắn client_hello. Đối với thông báo server_hello, các điều kiện sau được áp dụng. Trường Phiên bản chứa phiên bản thấp hơn do máy khách đề xuất và phiên bản cao nhất được máy chủ hỗ trợ.

Trường Ngẫu nhiên được tạo bởi máy chủ và độc lập với trường Ngẫu nhiên của máy khách. Nếu trường SessionID của máy khách khác không, thì máy chủ sẽ sử dụng cùng một giá trị; nếu không thì trường SessionID của máy chủ chứa giá trị cho một phiên mới. Trường CipherSuite chứa bộ mật mã duy nhất được máy chủ chọn từ những bộ mật mã do máy khách đề xuất. Trường Nén chứa phương pháp nén được máy chủ chọn từ những phương pháp do máy khách đề xuất.

Phần tử đầu tiên của tham số CipherSuite là phương thức trao đổi khóa (nghĩa là phương tiện trao đổi các khóa mật mã cho mã hóa thông thường và MAC). Các phương pháp trao đổi khóa sau được hỗ trợ.

RSA: Khóa bí mật được mã hóa bằng khóa công khai RSA của người nhận. Chứng chỉ khóa công khai cho khóa của người nhận phải có sẵn.
Fixed Diffie-Hellman: Đây là một trao đổi khóa Diffie-Hellman trong đó chứng chỉ của máy chủ chứa các thông số công khai Diffie-Hellman được cơ quan cấp chứng chỉ (CA) ký. Đó là, chứng chỉ khóa công khai chứa các tham số khóa công khai Diffie-Hellman. Máy khách cung cấp các tham số khóa công khai Diffie-Hellman của nó trong chứng chỉ, nếu cần xác thực máy khách hoặc trong một thông điệp trao đổi khóa. Phương pháp này tạo ra một khóa bí mật cố định giữa hai đồng đẳng dựa trên phép tính Diffie-Hellman bằng cách sử dụng các khóa công khai cố định.
Ephemeral Diffie-Hellman: Kỹ thuật này được sử dụng để tạo khóa bí mật tạm thời (tạm thời, một lần). Trong trường hợp này, các khóa công khai Diffie-Hellman được trao đổi, ký bằng cách sử dụng khóa RSA hoặc DSS riêng của người gửi. Người nhận có thể sử dụng khóa công khai tương ứng để xác minh chữ ký. Chứng chỉ được sử dụng để xác thực các khóa công khai. Điều này có vẻ là an toàn nhất trong ba tùy chọn Diffie-Hellman, vì nó dẫn đến một khóa tạm thời, được xác thực.
Anonymous Diffie-Hellman: Thuật toán Diffie-Hellman cơ bản được sử dụng mà không cần xác thực. Đó là, mỗi bên gửi thông số Diffie-Hellman công khai của mìnhvới người khác mà không có xác thực. Cách tiếp cận này dễ bị tấn công giữa các bên, trong đó kẻ tấn công tiến hành Diffie-Hellman ẩn danh với cả hai bên.
Fortezza: Kỹ thuật được xác định cho lược đồ Fortezza.

Theo định nghĩa của một phương pháp trao đổi khóa là CipherSpec, bao gồm các trường sau.

CipherAlgorithm: Bất kỳ thuật toán nào đã đề cập trước đó: RC4, RC2, DES, 3DES, DES40, IDEA hoặc Fortezza
MACAlgorithm: MD5 hoặc SHA-1
CipherType: Stream hoặc Block
IsExportable: Đúng hay Sai
HashSize: 0, 16 (cho MD5) hoặc 20 (cho SHA-1) byte
Key Material: Một chuỗi các byte chứa dữ liệu được sử dụng để tạo các khóa ghi

IV Size: kích thước của Giá trị khởi tạo cho mã hóa Chuỗi khối mật mã (CBC)

Giai đoạn 2 – SERVER AUTHENTICATION AND KEY EXCHANGE

Máy chủ bắt đầu giai đoạn này bằng cách gửi chứng chỉ của nó nếu nó cần được xác thực; thông báo chứa một hoặc một chuỗi các chứng chỉ X.509. Thông báo chứng chỉ là bắt buộc đối với bất kỳ phương thức trao đổi khóa nào đã thỏa thuận ngoại trừ Diffie-Hellman ẩn danh. Lưu ý rằng nếu sử dụng Diffie- Hellman cố định, thông báo chứng chỉ này có chức năng như thông điệp trao đổi khóa của máy chủ vì nó chứa các tham số Diffie-Hellman công khai của máy chủ.

Tiếp theo, một thông báo server_key_exchange có thể được gửi nếu nó được yêu cầu. Nó không bắt buộc trong hai trường hợp: (1) Máy chủ đã gửi một chứng chỉ với các tham số Diffie-Hellman cố định hoặc (2) một trao đổi khóa RSA sẽ được sử dụng. Thông báo server_key_exchange là cần thiết cho những việc sau:

Anonymous Diffie-Hellman: Nội dung thông báo bao gồm hai giá trị Diffie-Hellman toàn cục (một số nguyên tố và một gốc nguyên thủy của số đó) cộng với khóa Diffie-Hellman công khai của máy chủ (xem Hình 10.1).
Ephemeral Diffie-Hellman: Nội dung tin nhắn bao gồm ba thông số Diffie- Hellman được cung cấp cho Diffie-Hellman ẩn danh cộng với chữ ký của các thông số đó.
Trao đổi khóa RSA (trong đó máy chủ đang sử dụng RSA nhưng có khóa RSA chỉ dành cho chữ ký): Theo đó, máy khách không thể chỉ gửi một khóa bí mật được mã hóa bằng khóa công khai của máy chủ. Thay vào đó, máy chủ phải tạo một RSA tạm thờicặp khóa công khai / riêng tư và sử dụng thông báo server_key_exchange để gửi khóa công khai. Nội dung thông báo bao gồm hai tham số của khóa công khai RSA tạm thời (số mũ và mô đun) cùng với chữ ký của các tham số đó.

Một số chi tiết khác về chữ ký được bảo đảm. Như thường lệ, chữ ký được tạo bằng cách lấy băm của một tin nhắn và mã hóa nó bằng khóa riêng của người gửi. Trong trường hợp này, hàm băm được định nghĩa là

hash (ClientHello.random | ServerHello.random | ServerParams)

Vì vậy, hàm băm không chỉ bao gồm các tham số Diffie-Hellman hoặc RSA mà còn bao gồm cả hai dấu ngoặc kép từ các thông báo chào ban đầu. Điều này đảm bảo chống lại các cuộc tấn công phát lại và trình bày sai. Trong trường hợp chữ ký DSS, hàm băm được thực hiện bằng cách sử dụng

Thuật toán SHA-1. Trong trường hợp chữ ký RSA, cả MD5 và SHA-1hàm băm được tính toán và sự ghép nối của hai hàm băm (36 byte) được mã hóa bằng khóa riêng của máy chủ.

Tiếp theo, một máy chủ không ẩn danh (máy chủ không sử dụng Diffie-Hellman ẩn danh) có thể yêu cầu chứng chỉ từ máy khách. Thông báo certificate_request bao gồm hai tham số: certificate_type và certificate_authority. Loại chứng chỉ cho biết thuật toán khóa công khai và việc sử dụng nó:

RSA, chỉ chữ ký
DSS, chỉ chữ ký
RSA cho Diffie-Hellman cố định; trong trường hợp này, chữ ký chỉ được sử dụng để xác thực, bằng cách gửi một chứng chỉ được ký bằng RSA
DSS cho Diffie-Hellman cố định; một lần nữa, chỉ được sử dụng để xác thực
RSA cho phù du Diffie-Hellman
DSS cho con thiêu thân Diffie-Hellman
Fortezza

Tham số thứ hai trong thông báo certificate_request là danh sách các tên phân biệt của tổ chức phát hành chứng chỉ được chấp nhận.

Thông báo cuối cùng trong giai đoạn 2, và một thông báo luôn được yêu cầu, là thông báo server_done, được gửi bởi máy chủ để cho biết kết thúc của hello máy chủ và các thông báo liên quan. Sau khi gửi tin nhắn này, máy chủ sẽđợi phản hồi của khách hàng. Thông báo này không có tham số.

Giai đoạn 3 – CLIENT AUTHENTICATION VÀ KEY EXCHANGE

Khi nhận được thông báo server_done, máy khách nên xác minh rằng máy chủ đã cung cấp chứng chỉ hợp lệ (nếu được yêu cầu) và kiểm tra xem các thông số server_hello có được chấp nhận hay không. Nếu tất cả đều đạt yêu cầu, máy khách sẽ gửi một hoặc nhiều thông báo trở lại máy chủ.

Nếu máy chủ đã yêu cầu chứng chỉ, máy khách sẽ bắt đầu giai đoạn này bằng cách gửi thông báo chứng chỉ. Nếu không có chứng chỉ phù hợp, khách hàng sẽ gửi một cảnh báo no_certificate để thay thế.

Tiếp theo là thông báo client_key_exchange, phải được gửi trong giai đoạn này. Nội dung của tin nhắn tùy thuộc vào loại trao đổi khóa, như sau.

RSA: Máy khách tạo ra một bí mật tổng thể trước 48 byte và mã hóa bằng khóa công khai từ chứng chỉ của máy chủ hoặc khóa RSA tạm thời từ một tin nhắn server_key_exchange. Việc sử dụng nó để tính toán một bí mật sẽ được giải thích sau.
Ephemeral hoặc Anonymous Diffie-Hellman: Các thông số Diffie-Hellman công khai của khách hàng được gửi.
Fixed Diffie-Hellman: Các tham số Diffie-Hellman công khai của khách hàng đã được gửi trong một thông báo chứng chỉ, vì vậy nội dung của thông báo này là rỗng.
Fortezza: Các thông số Fortezza của khách hàng được gửi.

Cuối cùng, trong giai đoạn này, máy khách có thể gửi một thông báo certificate_verify để cung cấp xác minh rõ ràng chứng chỉ máy khách. Thông báo này chỉ được gửi khi hạ thấp bất kỳ chứng chỉ ứng dụng khách nào có khả năng ký (tức là tất cả các chứng chỉ ngoại trừ những người có chứa các tham số Diffie-Hellman cố định). Thông báo này ký mã băm dựa trên các thông báo trước đó, được định nghĩa là

CertificateVerify.signature.md5_hash =

MD5 (master_secret | pad_2 | MD5 (handshake_messages | master_secret | pad_1);

CertificateVerify.signature.sha_hash =

SHA (master_secret | pad_2 | SHA (handshake_messages | master_secret | pad_1);

trong đó pad_1 và pad_2 là các giá trị được xác định trước đó cho MAC, handshake_messages đề cập đến tất cả các thông báo Giao thức bắt tay được gửi hoặc nhận bắt đầu từ client_hello nhưng không bao gồm thông báo này và master_secret là bí mật được tính toán mà cấu trúc của nó sẽ được giải thích ở phần sau của phần này.

Nếu khóa riêng tư của người dùng là DSS, thì nó được sử dụng để mã hóa hàm băm SHA-1. Nếu khóa riêng tư của người dùng là RSA, nó được sử dụng để mã hóa việc ghép các băm MD5 và SHA-1. Trong cả hai trường hợp, mục đích là để xác minh chủ sở hữu của khách hàng của khóa cá nhân cho chứng chỉ khách hàng. Ngay cả khi ai đó đang lạm dụng chứng chỉ của khách hàng, họ sẽ không thể gửi tin nhắn này.

Giai đoạn 4 – FINISH

Giai đoạn này hoàn tất việc thiết lập kết nối an toàn. Máy khách gửi một thông báo change_cipher_spec và sao chép CipherSpec đang chờ xử lý vào CipherSpec hiện tại. Lưu ý rằng thông báo này không được coi là một phần của Giao thức Bắt tay nhưng được gửi bằng Giao thức Thông số Kỹ thuật Mật mã Thay đổi. Sau đó, khách hàng sẽ ngay lập tức gửi thông điệp đã hoàn thành theo các thuật toán, khóa và bí mật mới. Thông báo hoàn thành xác minh rằng trao đổi khóa và xác thựccác quy trình đã thành công. Nội dung của thông báo đã hoàn thành là sự ghép nối của hai giá trị băm:

trong đó Người gửi là mã xác định rằng người gửi là khách hàng và handshake_messages là tất cả dữ liệu từ tất cả các thông báo bắt tay cho đến nhưng không bao gồm thông báo này.

Đáp lại hai thông báo này, máy chủ sẽ gửi thông báo change_cipher_spec, chuyển thông báo đang chờ xử lý đến CipherSpec hiện tại và gửi thông báo đã hoàn thành của nó. Tại thời điểm này, quá trình bắt tay đã hoàn tất và máy khách và máy chủ có thể bắt đầu trao đổi dữ liệu lớp ứng dụng.

Cryptographic Computations

Hai mục khác cũng được quan tâm: (1) việc tạo ra một bí mật chính được chia sẻ bằng cách trao đổi khóa và (2) tạo ra các tham số mật mã từ bí mật chính.

MASTER SECRET CREATION

Bí mật chính được chia sẻ là giá trị 48 byte một lần (384 bit) được tạo cho phiên này bằng cách trao đổi khóa an toàn. Việc tạo ra là trong hai giai đoạn. Đầu tiên, một pre_master_secret được trao đổi. Thứ hai, master_secret được tính toán bởi cả hai bên. Đối với trao đổi pre_master_secret, có hai khả năng.

RSA: 48 byte pre_master_secret được tạo bởi máy khách, được mã hóa bằng khóa RSA công khai của máy chủ và được gửi đến máy chủ. Máy chủ giải mã bản mã bằng cách sử dụng khóa riêng của nó để khôi phục pre_master_secret.
Diffie-Hellman: Cả máy khách và máy chủ đều tạo khóa công khai Diffie-Hellman. Sau khi chúng được trao đổi, mỗi bên thực hiện phép tính Diffie-Hellman để tạo pre_master_secret được chia sẻ.

Cả hai bên hiện tính toán master_secret là

master_secret = MD5 (pre_master_secret | SHA (‘A’ |

pre_master_secret | ClientHello.random | ServerHello.random) |

MD5 (pre_master_secret | SHA (‘CCC’ | pre_master_secret | ClientHello.random | ServerHello.random)

trong đó ClientHello.random và ServerHello.random là hai giá trị nonce được trao đổi trong thông báo hello ban đầu.

GENERATION OF CRYPTOGRAPHIC PARAMETERS

CipherSpecs yêu cầu máy khách ghi bí mật MAC, máy chủ ghi bí mật MAC, khóa ghi máy khách, khóa ghi máy chủ, máy khách ghi IV và máy chủ ghi IV, được tạo từ bí mật chính trong đó đặt hàng. Các tham số này được tạo ra từ bí mật chính bằng cách băm bí mật chính thành một chuỗi các byte an toàn có độ dài đủ cho tất cả các tham số cần thiết.

Việc tạo ra tài liệu quan trọng từ bí mật tổng thể sử dụng cùng một định dạng để tạo ra tài liệu chính từ bí mật tổng thể như

cho đến khi đủ sản lượng. Kết quả của cấu trúc thuật toán này là mộtchức năng pseudorandom. Chúng ta có thể xem master_secret là giá trị hạt giống giả ngẫu nhiên cho hàm. Các số ngẫu nhiên của máy khách và máy chủ có thể được xem như các giá trị muối để làm phức tạp việc phân tích mật mã.

Chia sẻ, cryptography

SSL ( secure socket layer) là gì