SSL Record Protocol sử dụng để trao đổi tất cả các kiểu dữ liệu trong một phiên, bao gồm các thông điệp, dữ liệu của các giao thức SSL khác và dữ liệu của ứng dụng.
SSL Record Protocol liên quan đến việc bảo mật và đảm bảo toàn vẹn dữ liệu. Mục đích của SSR Record Protocol là thu nhận những thông điệp mà ứng dụng chuẩn bị gửi, phân mảnh dữ liệu cần truyền, đóng gói, bổ xung header tạo thành một đối tượng gọi là bản ghi (record), bản ghi đó được mã hoá và có thể truyền bằng giao thức TCP.
Bước đầu tiên của quá trình chuẩn bị truyền dữ liệu là phân mảnh dữ liệu, tức là chia nhỏ dòng dữ liệu thành các mảnh kích thước 16KB (hoặc nhỏ hơn). Những mảnh dữ liệu này sau đó có thể được nén trước khi truyền. Sau đó bắt đầu quá trình tạo các bản ghi cho mỗi đơn vị dữ liệu bằng cách bổ xung thêm header, một số byte cho đủ kích thước qui định của bản ghi nếu kích thước bản ghi chưa đủ và cuối cùng là phần MAC. MAC (Message Authentication Code) là mã xác thực thông điệp sử dụng để khi phát dữ liệu trong các phiên SSL.
Phần header của mỗi bản ghi chứa 2 thông tin quan trọng đó là độ dài của bản ghi và độ dài của khối dữ liệu thêm vào phần dữ liệu gốc. Phần dữ liệu của một bản ghi gồm:
• các byte bổ xung cho đủ kích thước gói tin qui định
• giá trị MAC
MAC được sử dụng để kiểm chứng sự toàn vẹn của thông điệp chứa trong bản ghi gửi cùng với MAC đó. MAC là kết quả của một của một hàm băm theo một thuật toán băm được qui định trước (ví dụ MD5 hoặc SHA-1).
MAC được tính toán dựa trên việc áp dụng hàm băm trên các dữ liệu sau: khoá bí mật, dữ liệu gốc, phần thông tin bổ xung, số thứ tự.
Khoá bí mật ở đây có thể là khoá ghi MAC của client (client write MAC secret) hoặc của server (server write MAC secret) tuỳ thuộc vào ai là người tạo gói tin.
Sau khi nhận được một gói tin thì bên nhận tự tính lại giá trị MAC và so sánh với giá trị MAC chứa trong gói tin đó. Nếu hai giá trị MAC đó giống nhau có nghĩa là dữ liệu không bị thay đổi trong quá trình truyền trên mạng. Độ dài của trường MAC phụ thuộc vào phương pháp để tính ra nó. Tiếp theo, phần dữ liệu cộng với MAC sẽ được mã hoá sử dụng phương pháp mã hoá (đối xứng) đã thoả thuận trước ví dụ DES hoặc triple DES. Như vậy là cả dữ liệu và MAC đều được mã hóa. Phần dữ liệu đã được mã hoá đó được gắn thêm header bao gồm các trường sau:
• Kiểu nội dung (content type): xác định dữ liệu nào chứa trong gói tin để quyết định xem giao thức nào ở lớp cao hơn sẽ chịu trách nhiệm xử lý dữ liệu của gói tin đó. Các giá trị có thể của trường này là: change_cipher_spec, alert, handshake và application_data tham chiếu đến các giao thức tương ứng ở mức cao hơn.
• Phiên bản chính (major version): phần chỉ số chính của phiên bản SSL đang sử dụng. Ví dụ với SSL 3.0 thì giá trị trường này là 3.
• Phiên bản phụ (minor version): phần chỉ số phụ của phiên bản SSL đang sử dụng. Ví dụ với SSL 3.0 thì giá trị trường này là 0.
Sau khi tính toán xong các trường này, bản ghi đã được tạo xong và sẵn sàng để gửi đến cho máy đích. Toàn bộ quá trình chuẩn bị bản ghi trước khi gửi được mô tả trong hình 2.6.
Hình 2.6 : Quá trình tạo một bản ghi của SSL Record Protocol
• Bước đầu tiên là phân mảnh.Mỗi message của lớp bên trên được phân mảnh thành các block ,mỗi block là 214 byte (16384 byte) hoặc ít hơn.
• Tiếp theo,nén được áp dụng 1 cách tùy chọn.Nén phải là không mất mát thông tin và có thể không làm tăng chiều dài nội dung nhiều hơn 1024 byte (Dĩ nhiên, người ta mong muốn nén làm co lại dữ liệu hơn là nới rộng dữ liệu.Tuy nhiên, với những block ngắn, có thể, do định dạng quy ước, thuật toán nén thực sự làm cho output dài hơn input).Trong SSLv3 (cũng như phiên bản hiện tại của TLS), không có thuật toán nén nào được chỉ rõ, vì vậy thuật toán nén mặc định là null.
• Bước xử lí kế tiếp là tính toán MAC (mã xác thực message) trên dữ liệu đã được nén.Để thực hiện cần dùng đến 1 khóa bí mật được chia sẻ. Phép tính được định nghĩa như sau:
hash(MAC_write_secret || pad_2 || hash(MAC_write_secret || pad_1 ||seq_num ||SSLCompressed.type || SSLCompressed.length || SSLCompressed.fragment))
trong đó:
|| : phép nối/hoặc.
MAC_write_secret: khóa bí mật được chia sẻ. hash: thuật toán băm mã hóa, MD5 hoặc SHA-1.
pad_1: byte 0x36 (0011 0110) được lặp lại 48 lần (384 bit) cho MD5 và 40 lần (320 bit) cho SHA-1.
pad_2: byte 0x5c (0101 1100) được lặp lại 48 lần cho MD5 và 40 lần cho SHA- 1.
seq_num: sequence number cho message này.
SSLCompressed.type: giao thức ở lớp trên được dùng để xử lí phân mảnh này. SSLCompressed.length: chiều dài của phân mảnh đã được nén.
phân mảnh ở dạng plaintext).
Chú ý rằng, cái này tương tự như thuật toán HMAC. Điểm khác biệt là 2 phần đệm (pad) được || trong SSLv3 và được XOR trong HMAC.Thuật toán MAC trong SSLv3 được dựa trên bản phác thảo Internet ban đầu cho HMAC.Phiên bản gần nhất của HMAC được định nghĩa trong RFC 2104,sử dụng XOR.
• Kế tiếp, message đã nén cộng thêm MAC được mã hóa theo phương pháp mã hóa đối xứng.
Mã hóa có thể không làm tăng chiều dài nội dung hơn 1024 byte,vì vậy chiều dài tổng cộng không vượt quá 214+2048. Các thuật toán mã hóa sau được cho phép:
Block cipher (Mã hóa khối) Stream cipher (Mã hóa luồng) Thuật toán Kích thước khóa Thuật toán Kích thước khóa (adsbygoogle = window.adsbygoogle || []).push({});
AES 128,256 RC4-40 40 IDEA 128 RC4-128 128 RC2-40 40 DES-40 40 DES 56 3DES 168 Fortezza 80
• DES (Data Encryption Standard) là một thuật toán mã hoá có chiều dài khoá là 56 bit.
• 3-DES (Triple-DES): là thuật toán mã hoá có độ dài khoá gấp 3 lần độ dài khoá
trong mã hoá DES
• DSA (Digital Signature Algorithm): là một phần trong chuẩn về xác thực số đang
được được chính phủ Mỹ sử dụng.
• KEA (Key Exchange Algorithm) là một thuật toán trao đổi khoá đang được chính
• MD5 (Message Digest algorithm) được phát thiển bởi Rivest.
• RSA: là thuật toán mã hoá công khai dùng cho cả quá trình xác thực và mã hoá dữ
liệu được Rivest, Shamir, and Adleman phát triển.
• RSA key exchange: là thuật toán trao đổi khoá dùng trong SSL dựa trên thuật toán
RSA.
• RC2 and RC4: là các thuật toán mã hoá được phát triển bởi Rivest dùng cho RSA
Data Security.
• SHA-1 (Secure Hash Algorithm): là một thuật toán băm đang được chính phủ Mỹ
sử dụng.
Các thuật toán trao đổi khoá như KEA, RSA key exchange được sử dụng để 2 bên client và server xác lập khoá đối xứng mà họ sẽ sử dụng trong suốt phiên giao dịch SSL. Và thuật toán được sử dụng phổ biến là RSA key exchange.
Các phiên bản SSL 2.0 và SSL 3.0 hỗ trợ cho hầu hết các bộ mã hoá. Người quản trị có thể tuỳ chọn bộ mã hoá sẽ dùng cho cả client và server. Khi một client và server trao đổi thông tin trong giai đoạn bắt tay (handshake), họ sẽ xác định bộ mã hoá mạnh nhất có thể và sử dụng chúng trong phiên giao dịch SSL.
Fortezza có thể được sử dụng trong mục tiêu mã hóa smart card.
Với mã hóa stream (luồng),message đã nén cộng thêm MAC được mã hóa.Chú ý rằng MAC được tính toán trước khi mã hóa xảy ra và MAC được mã hóa cùng với plaintext hoặc là plaintext đã nén.
Với mã hóa block (khối), MAC có thể được đệm thêm trước khi mã hóa.Phần đệm thêm (padding) có dạng gồm nhiều byte đệm được theo sau bởi 1 byte chỉ rõ chiều dài của phần đệm.Tổng số lượng đệm vào là lượng nhỏ nhất sao cho tổng kích thước dữ liệu được mã hóa (plaintext +MAC + padding) là 1 bội số của chiều dài khối mã hóa.Ví dụ, plaintext (hoặc text đã nén nếu nén được dùng) là 58 byte, với MAC là 20 byte (dùng SHA-1), được mã hóa với chiều dài block là 8 byte (như DES..).Cùng với byte padding.length ,nó sinh ra tổng cộng 79 byte.Để tạo ra 1 số
nguyên là bội của 8,1 byte đệm được thêm vào.
• Bước cuối cùng của xử lí SSL Record Protocol là gắn thêm vào1 header, bao gồm các mục sau:
o Content Type (8 bit): giao thức lớp trên được dùng để xử lí phân mảnh đi kèm.
o Major Version (8 bit): chỉ ra phiên bản SSL tối đa được dùng. Ví dụ, SSLv3, giá trị này là 3.
o Minor Version (8 bit) : chỉ ra phiên bản tối thiểu được dùng.Ví dụ, SSLv3 ,giá trị này là 0.
o Compressed Length (16 bit) : chiều dài theo byte của phân mảnh plaintext (hoặc chiều dài theo byte của phân mảnh đã nén nếu nén được dùng).Gía trị lớn nhất là 214+2048.
Hình 2.7: Hình minh họa định dạng SSL Record
Các loại nội dung được định nghĩa là change_cipher_spec,alert, handshake, và application_data. Ba cái đầu tiên là các giao thức đặc trưng-SSL,được bàn đến trong phần kế tiếp.Chú ý rằng không có sự khác biệt nào được tạo ra giữa các ứng dụng (như HTTP..) có thể dùng SSL,nội dung dữ liệu được tạo ra bởi các ứng dụng đó thì không trong suốt đối với SSL.
2.2.2. Giao thức SSL Change Cipher Spec: (adsbygoogle = window.adsbygoogle || []).push({});
Đây là giao thức SSL đơn giản nhất. Nó chỉ chứa một thông điệp mang giá trị 1. Mục đích duy nhất của thông điệp này là làm chuyển trạng thái của một phiên từ “đang chờ” (pending) sang “bền vững” (fixed). Ví dụ khi 2 bên qui ước bộ giao thức nào sẽ sử dụng. Cả client và server đều phải gửi thông điệp loại này cho bên đối tác, sau khi đã trao đổi xong thì coi như hai bên đã đồng ý với nhau.
Hình 2.8 Hình minh họa định dạng SSL Change Cipher Spec
2.2.3. Giao thức SSL Alert:
Giao thức SSL Alert được dùng để truyền cảnh báo liên kết SSL với đầu cuối bên kia. Như với những ứng dụng khác sử dụng SSL, alert messages được nén và mã hóa, được chỉ định bởi trạng thái hiện tại.
Mỗi message trong giao thức này gồm 2 bytes .Byte đầu tiên giữ giá trị cảnh báo(1) hoặc nguy hiểm(2) để thông báo độ nghiêm ngặt của message. Nếu mức độ là nguy hiểm, SSL lập tức chấp dứt kết nối. Những kết nối cùng phiên khác vẫn có thể tiếp tục nhưng sẽ không kết nối nào khác trên phiên này được khởi tạo thêm. Byte thứ hai chứa một mã chỉ ra cảnh báo đặc trưng. Đầu tiên , chúng ta liệt kê những cảnh báo đó mà luôn ở mức nguy hiểm ( được định nghĩa từ những thông số SSL):
• unexpected_message: message không thích hợp.
• bad_record_mac: MAC không chính xác.
• decompression_failure: việc giải nén nhận input không thích hợp(ví dụ như 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: bên gửi không thể thương lượng một bộ chấp nhận được của các thông số bảo mật được đưa ra từ những lựa chọn có sẵn.
• illegal_parameter: một trường trong một handshake message thì vượt khỏi dãy hoặc trái với những trường khác
Phần còn lại của cảnh báo thì như sau:
• close_notify: thông báo cho bên nhận rằng bên gửi sẽ không gửi thêm message nào nữa trong kết nối này.Mỗi nhóm thì được yêu cầu gửi một close_notify cảnh báo trước khi kết thúc phần ghi của một kết nối.
• no_certificate: có thể được gửi để trả lời cho một yêu cầu certificate nếu không certificate thích hợp nào có sẵn.
• bad_certificate: certificate nhận được thì không hợp lệ(ví dụ như chứa một chữ ký không xác minh).
• unsupported_certificate: dạng certificate nhận được thì không hỗ trợ.
• certificate_revoked: certificate đã bị thu hồi bởi nhà cung cấp.
• certificate_expired: certificate đã hết hạn đăng ký.
• certificate_unknown: một số phát sinh không nói rõ xuất hiện trong quá trình xử ký certificate làm cho nó không thể chấp nhận.
Hình 2.9 Hình minh họa định dạng SSL Alert
2.2.2. Giao thức SSL Handshake:
Hình 2.10 Hình minh họa định dạng SSL Handshake
Phần “khó hiểu” nhất của SSL là giao thức Handshake. Giao thức này cho phép server và client chứng thực với nhau và thương lượng cơ chế mã hóa, thuật toán MAC và khóa mật mã được sử dụng để bảo vệ dữ liệu được gửi trong SSL record. Giao thức SSL Handshake thường được sử dụng trước khi dữ liệu của ứng dụng được truyền đi.
Giao thức SSL Handshake bao gồm một loạt những message trao đổi giữa client và server. Mỗi message có ba trường:
• Type (1 byte): chỉ ra một trong mười dạng message .
• Length (3 bytes): độ dài của message theo bytes.
• Content (>=0 bytes): tham số đi kèm với message này, được liệt kê trong Bảng 2.10
Bảng 2.11. Các kiểu message giao thức SSL handshake
Kiểu message Thông số
Hello_request Null
Client_hello version, random, session id, cipher suite, compression method (adsbygoogle = window.adsbygoogle || []).push({});
Server_hello version, random, session id, cipher suite, compression Certificate chain of X.509v3 certificates
Server_key_exchange parameters, signature Certificate_request type, authorities
Server_done Null
Certificate_verify signature
Client_key_exchange parameters, signature
Finished Hash value
Hình 2.12 thể hiện trao đổi lúc ban đầu cần được thiết lập một kết nối logic giữa client và server.Việc trao đổi có thể xem như có 4 giai đoạn.
2.2.4.1. Giai đoạn 1 : Thiết lập khả năng bảo mật :
Giai đoạn này được dung để bắt đầu một kết nối logic và thiết lập khả năng bảo mật mà sẽ liên kết với nó.Việc trao đổi thì được khởi tạo bởi client bằng việc gửi một client_hello message với những thông số sau đây:
• Version: version SSL mới nhất mà client biết.
• Random: một cấu trúc sinh ra ngẫu nhiên từ client, bao gồm một nhãn thời gian 32 bit và 28 bytes sinh bởi một bộ sinh số ngẫu nhiên an toàn. Những giá trị này phục vụ cho lần này vsử dụng suốt quá trình trao đổikhóa để ngăn tấn công lập lại.
• Session ID: một ID của phiên có chiều dài thay đổi được.SessionID khác 0 nghĩa là client muốn cập nhật tham số của một kết nối đang tồn tại hay tạo một kết nối mới trên phiên này.SessionID = 0 chỉ ra rằng client 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à 1 danh sách mà chứa những bộ biên dịch của những thuật toán mã hóa được hỗ trợ bởi client, tham khảo theo thứ tự giảm dần. Mỗi thành phần trong danh sách (mỗi bộ mã hóa) định nghĩa cả một khóa trao đổi và một CipherSpec, những thông số này sẽ được bàn đến sau.
• Compression Method: đây là danh sách của những phương thức nén mà client hỗ trợ.
Sau khi gửi client_hello message, client chờ nhận server_hello message mà chứa cùng thông số với client_hello message.Với server_hello message, những thỏa thuận kèm theo được áp dụng. Trường Version chứa version thấp hơn được đề nghị bởi client và cao nhất được hổ trợ bởi sever.Trường Random được sinh ra bởi server và độc lập với trường Random của client. Nếu trường SessionID của client khác 0, thì giá trị tương tự được dùng bởi server,ngược lại thì trường SessionID của server chứa giá trị của một phiên mới. Trường CipherSuite chứa bộ mã hóa chọn bởi server từ những đề xuất của
client. Trường Compression chứa phương thức nén chọn bởi server từ những đề xuất của client.
Thành phần đầu tiên của thông số Cipher Suite là phương thức trao đổi khóa (ví dụ như bằng cách nào những khóa mã hóa cho việc mã hóa thông thường và MAC được trao đổi ).Những phương thức trao đổi khóa sau được hỗ trợ:
• RSA: khóa bí mật được mã hóa với khóa công khai RSA của bên nhận. Một public-key certificate cho khóa bên nhận phải được tạo sẵn.
• Fixed Diffie-Hellman: đây là sự trao đổi khóa Diffie-Hellman trong certificate của server chứa các thông số công khai Diffie-Hellman được ký bởi Certificate Authority (CA) .Nghĩa là certificate khóa công khai chứa các thông số khóa công khai Diffie-Hellman. Client chứa sẵn các thông số khóa công khai Diffie- Hellman đó trong certificate nếu chứng thực client được yêu cầu hoặc trong một message trao đổi khóa.Phương thức này mang lại kết quả một khóa bí mật cố định giữa hai đầu, dựa trên tính toán Diffie- Hellman sử dụng khóa công khai cố định.
• Ephemeral Diffie-Hellman: Phương pháp được sử dụng để tạo khó “ephemeral” (tạm thời,1 lần)– khóa tạm thời. Trong trường hợp này, khóa công khai Diffie- Hellman được trao đổi,được ký sử dụng khóa bí mật RSA hoặc DSS của bên gửi.Bên nhận có thể sử dụng khóa công khai tương ứng để xác minh chữ ký.