Với giao thức trao đổi khoá Diffie-Hellman, có hai trạng thái của thông điệp ClientKeyExchange. Nếu trao đổi Diffie-Hellman là ngắn, thì thông điệp có định dạng nhƣ hình 22: Thân thông điệp gồm giá trị Yc của client, xếp theo chiều dài giá trị. Nếu trao đổi Diffie-Hellman là chi tiết, giá trị Yc đƣợc lƣu trong chứng chỉ của client, khi đó ClientKeyExchange sẽ trống.
Hình 28: Thông điệp ClientKeyExchange với Fortezza
Với trao đổi khoá Fortezza / DMS, thông điệp ClientKeyExchange yêu cầu một tập hợp các tham số (10 giá trị).
10). Thông điệp CertificateVerify
Thông điệp này đƣợc sử dụng để cung cấp sự xác thực rõ ràng hơn về chứng chỉ của client. Thông điệp chỉ đƣợc gửi với chứng chỉ client nào có khả năng ký số. Khi đƣợc gửi, nó theo ngay sau thông điệp ClientKeyExchange. Thông điệp này ký trên hàm băm dựa trên các thông điệp, và cấu trúc của nó đƣợc định nghĩa nhƣ sau:
Hình 29: Tạo thông điệp CertificateVerify
Định dạng chính xác của thông tin tuỳ thuộc vào việc chứng chỉ của client dùng chữ ký RSA hay DSA. Với các chứng chỉ RSA, hai hàm băm riêng biệt đƣợc kết hợp lại và ký: một hàm băm MD5 và một hàm băm SHA. Với các chứng chỉ DSA, chỉ một hàm băm SHA đƣợc tạo và đƣợc ký.
Trong mọi trƣờng hợp, thông tin mà server đƣa vào các hàm băm là nhƣ nhau. Client xây dựng thông tin trong ba bƣớc. Đầu tiên, họ tính giá trị đặc biệt gọi là Master Secret.
Client tính giá trị Master Secret theo tiến trình sau:
1. Bắt đầu với 48 byte Premaster secret. Client tạo ra giá trị này và gửi nó tới server trong thông điệp ClientKeyExchange.
2. Tính hàm băm SHA của ký tự ASCII „A‟ theo sau Premaster secret, giá trị ngẫu nhiên của client (từ ClientHello) và giá trị ngẫu nhiên của server (từ ServerHello).
3. Tính hàm băm MD5 của Premaster secret và đầu ra của bƣớc 2.
4. Tính hàm băm SHA của hai ký tự ASCII „BB‟, Premaster secret, giá trị ngẫu nhiên của client, giá trị ngẫu nhiên của server.
5. Tính hàm băm MD5 của Premaster secret và đầu ra của bƣớc 4. * Kết hợp kết quả bƣớc 3 và bƣớc 5.
6. Tính hàm băm SHA của ba kí tự ASC „CCC‟, Premaster secret, giá trị ngẫu nhiên của client, giá trị ngẫu nhiên của server.
7. Tính hàm băm MD5 của Premaster secret và đầu ra của bƣớc 6. * Kết hợp kết quả bƣớc 7 và bƣớc 6.
Khi client đã có giá trị Master Secret, nó chuyển tới giai đoạn tiếp theo là tạo hàm băm nội dung đầy đủ các thông điệp Handshake SSL trƣớc đó, đã đƣợc trao đổi trong suốt một phiên, theo sau là Master Secret, tiếp theo là giá trị byte đơn
001100110, đƣợc lặp lại 48 lần cho MD5, và 40 lần cho SHA.
Trong bƣớc thứ ba, client tạo hàm băm mới sử dụng Master Secret tƣơng tự, theo sau là giá trị 01011100, đƣợc lặp lại 48 lần cho MD5, và 40 lần cho SHA. Cuối cùng là đầu ra của hàm băm.
Giai đoạn 4 : Kết thúc kết nối bảo mật
Lúc này, thông điệp ChangeCipherSpec đƣợc gửi bởi client, và client sao chép lại CipherSpec trạng thái chờ vào CipherSpec hiện tại. Client gửi thông điệp kết thúc dƣới các thuật toán mới và các khoá. Đáp lại, server gửi thông điệp ChangeCipherSpec của mình, chuyển CipherSpec chờ thành CipherSpec hiện tại, sau đó gửi thông điệp kết thúc dƣới CipherSpec mới. Giai đoạn bắt tay kết thúc, client và server có thể bắt đầu trao đổi dữ liệu tầng ứng dụng.
11). Thông điệp ChangeCipherSpec
Client gửi thông điệp ChangeCipherSpec và sao chép trạng thái CipherSpec chờ vào CipherSpec hiện tại. Thông điệp này đƣợc gửi ngay sau thông điệp CertificateVerify. Nó thể hiện rằng thông điệp ChangeCipherSpec đƣợc nhận giữa các thông điệp handshake và các thông điệp kết thúc. Sẽ xảy ra lỗi nếu thông điệp ChangeCipherSpec không đƣợc theo sau bởi thông điệp Finished.
12). Thông điệp Finished
Thông điệp này luôn đƣợc gửi ngay sau thông điệp CipherSpec, để kiểm tra lại các tiến trình xác thực và trao đổi khoá đã thành công. Kiểu thông điệp Handshake kết thúc này là 20. Thông điệp Finish bản thân nó đƣợc mã hoá sử dụng các tham số Cipher suite.
Hình 30: Thông điệp Finished
Phần thân thông điệp Finish bao gồm kết quả của hai hàm băm, một sử dụng thuật toán băm MD5, và một sử dụng SHA. Cả hai sự tính toán này đều sử dụng đầu vào nhƣ nhau, và đều tính trong hai bƣớc.
- Đầu tiên ngƣời gửi tạo hàm băm nội dung đầy đủ các thông điệp Handshake SSL đã trao đổi trƣớc đó trong suốt một phiên, theo sau là quy tắc của ngƣời gửi, Master Secret và Padding.
Quy tắc của ngƣời gửi là giá trị hexa 434c4e54 nếu ngƣời gửi là client, 53525652 nếu ngƣời gửi là server.
Padding là giá trị 001100110, lặp lại 48 lần cho MD5 và 40 lần cho SHA. - Bƣớc thứ hai, ngƣời gửi tạo ra hàm băm mới sử dụng master secret, theo sau là một padding thay đổi và đầu ra của hàm băm trƣớc. Padding bƣớc hai là giá trị 01011100, lặp lại 48 lần cho MD5 và 40 lần cho SHA.
Hình 31: Thông điệp Finished bao gồm một hàm băm
Chú ý rằng, có sự giống nhau giữa tính toán này và tính toán hàm băm cho thông điệp CertificateVerify. Tuy nhiên cũng có hai điểm khác biệt. Đầu tiên, hàm băm Finished bao gồm quy tắc của ngƣời gửi trong khi CertificateVerify thì không. Thứ hai, tập hợp các thông điệp handshake sẽ khác khi hai hàm băm đƣợc tính. Trong mỗi trƣờng hợp, chú ý rằng SSL không đề cập tới ChangeCipherSpec, vì thế nội dung của nó không đƣợc tính tới trong hàm băm.
Sau khi thông điệp Finished của server đƣợc gửi đi, quá trình bắt tay hoàn thành và một phiên SSL đƣợc thiết lập. Từ lúc này trở đi, mọi truyền thông giữa hai bên đều đƣợc mã hoá cho tới khi kết thúc một phiên.
2.2.9. Các hệ mã hoá sử dụng với SSL
Giao thức SSL hỗ trợ nhiều hệ mã hoá sử dụng cho các hoạt động chứng thực server và client, cho quá trình truyền thông chứng chỉ số và trong quá trình thành lập khoá phiên. Client và server có thể có nhiều bộ mã hoá khác nhau, tuỳ thuộc vào phiên bản SSL hỗ trợ, các chính sách công ty chấp nhận các hệ mã hoá, và các hạn chế của chính phủ trong việc sử dụng các phần mềm hỗ trợ SSL.
Trong các chức năng khác, giao thức SSL Handshake có thể quyết định cách client và server đàm phán lựa chọn hệ mã hoá sử dụng cho việc chứng thực, cho quá trình truyền chứng chỉ và cho quá trình thành lập khoá phiên.
Bộ mã hoá mô tả sau đây có liên quan tới các thuật toán:
DSA (Digital Signature Algorithm): một phần của chuẩn chứng thực số tại Hoa kỳ.
KEA (Key Exchange Algorithm): Thuật toán trao đổi khoá tại Hoa kỳ. MD5 (Message Digest): Thuật toán băm đƣợc phát triển bởi Rivest. RC2-RC4: Hệ mã hoá của Rivest đƣợc phát triển cho RSA Data Security.
RSA: Hệ mã hoá khoá công khai cho mã hoá và xác thực (Rivest, Shamir, Adleman).
RSA key exchange: Thuật toán trao đổi khoá cho SSL dựa trên thuật toán RSA. SHA-1: Secure Hash Algorithm, thuật toán băm sử dụng tại Hoa kỳ.
SKIPJACK: Thuật toán mã hoá đối xứng cổ điển đƣợc cài đặt trong phần cứng tƣơng thích FORTEZZA, sử dụng tại Hoa kỳ.
Triple-DES.DES: đƣợc cài đặt 3 vòng.
Các thuật toán trao đổi khoá nhƣ KEA và RSA key exchange đƣợc sử dụng để hai 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, thuật toán đƣợc sử dụng phổ biến là RSA key exchange.
Các phiên bản SSL 2.0, 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 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.
Các quyết định về bộ mã hoá tuỳ thuộc vào quyết định của tổ chức dựa trên các thoả hiệp giữa dữ liệu nhạy cảm, tốc độ mã hoá và việc áp dụng các quy tắc. Một vài tổ chức có thể không hỗ trợ các hệ mã hoá yếu nhằm loại bỏ các kết nối SSL với hệ mã hoá yếu. Nhằm phục vụ khối lƣợng ngƣời dùng lớn, ngƣời quản trị có thể muốn hỗ trợ càng nhiều hệ mã hoá trong SSL càng tốt.
Theo cách thức này, khi client hay server trong cùng một nƣớc kết nối tới client và server trong cùng nƣớc khác, chúng sẽ thoả hiệp nhằm sử dụng các hệ mã hoá mạnh nhất có thể. Khi client, server trong nƣớc kết nối tới client hay server trên thế giới, chúng sẽ thỏa hiệp để sử dụng các hệ mã hoá đƣợc cho phép bởi chính phủ Mỹ. Tuy nhiên do hệ mã hoá 40 bit có thể bị phá dễ dàng, các nhà quản trị có thể sử dụng các hệ mã hoá hợp pháp mạnh hơn và cần loại bỏ việc hỗ trợ các hệ mã hoá 40 bit.
2.2.10. Bảo mật của SSL
Mức độ bảo mật của SSL phụ thuộc chính vào độ dài khoá hay phụ thuộc vào việc sử dụng phiên bản mã hoá 40bit và 128bit. Phƣơng pháp mã hoá 40bit đƣợc sử dụng rộng rãi không hạn chế ngoài nƣớc Mỹ, phiên bản mã hoá 128bit chỉ đƣợc sử dụng trong nƣớc Mỹ và Canada. Theo luật pháp Mỹ, các mật mã “mạnh” đƣợc phân loại vào nhóm “vũ khí” (weapon) và do đó khi sử dụng ngoài Mỹ (coi nhƣ là xuất khẩu vũ khí) phải đƣợc phép của chính phủ Mỹ hay phải đƣợc cấp giấy phép của Bộ Quốc phòng Mỹ (DoD).
Đây là lợi điểm cho quá trình thực hiện các dịch vụ thƣơng mại và thanh toán điện tử trong Mỹ và các nƣớc đồng minh phƣơng Tây, là điểm bất lợi cho việc sử dụng các sản phẩm cần có cơ chế bảo mật và an toàn trong giao dịch điện tử nói chung và thƣơng mại điện tử nói riêng trong các nƣớc khác.
Các phƣơng thức tấn công (hay bẻ khoá) nhằm vào các thuật toán bảo mật thƣờng dựa trên phƣơng pháp “tấn công vét cạn” (Brute-force attack) bằng cách thử- sai miền không gian các giá trị có thể của khoá. Số phép thử-sai tǎng lên khi độ dài khoá tǎng và dẫn đến vƣợt quá khả nǎng và công suất tính toán, kể cả các siêu máy tính hiện đại. Thí dụ, với độ dài khoá là 40bit, thì số phép thử sẽ là 240=1,099,511,627,776 tổ hợp.
Tuy nhiên độ dài khoá lớn kéo theo tốc độ tính toán giảm (luỹ thừa nghịch đảo) và dẫn đến khó có khả nǎng áp dụng trong thực tiễn. Một khi khoá bị phá, toàn bộ thông tin giao dịch trên mạng sẽ bị kiểm soát.
Tuy nhiên do độ dài khoá lớn (thí dụ 128, 256 bít), số phép thử-sai trở nên “không thể thực hiện” vì phải mất hàng nǎm hoặc thậm chí hàng nghìn nǎm với công suất và nǎng lực tính toán của máy tính mạnh nhất hiện nay.
Ngay từ nǎm 1995, bản mã hoá 40bit đã bị phá bởi sử dụng thuật toán vét cạn. Ngoài ra, một số thuật toán bảo mật (DES 56bit, RC4, MD4,...) hiện nay cũng bị coi là không an toàn khi áp dụng một số phƣơng pháp và thuật toán tấn công đặc biệt. Đã có một số đề nghị thay đổi trong luật pháp Mỹ, nhằm cho phép sử dụng rộng rãi các phần mềm mã hoá dùng mã 56bit, nhƣng hiện nay vẫn chƣa đƣợc chấp thuận.
2.2.10.1.Một số thách thức về bảo mật
Trong cộng đồng những ngƣời làm bảo mật, một trong các phƣơng pháp kiểm tra độ bảo mật / an toàn của các thuật toán bảo mật là: ngoài cơ sở lý thuyết thuật toán, còn đƣa ra các “thách thức” (challenge) với số tiền thƣởng tƣợng trƣng, nhằm kiểm tra tính thực tiễn của thuật toán. Sau đây là một số thông tin tham khảo:
- Ngày 14 tháng 7 nǎm 1995, Hal Finney đặt một thách thức SSL đầu tiên: bản ghi phiên làm việc của trình duyệt Netscape sử dụng thuật toán RC4-128- EXPORT-20. Ngày 16 tháng 8 nǎm 1995, David Byers, Eric Young, Adam Back đã phá thách thức này trong vòng 2 giờ, chi phí ƣớc tính 10,000 USD.
- Ngày 19 tháng 8 nǎm 1995, Hal Finney đặt một thách thức SSL thứ hai: một “key cracking ring”. Đã bị phá trong 32 giờ.
- Ngày 17 tháng 9 nǎm 1995, Ian Goldberg và David Wagner đã phá đƣợc thuật toán sinh số giả ngẫu nhiên (cơ sở cho việc sinh số nhận dạng phiên SSL - session ID) của phiên bản Netscape 1.1 trong vòng vài giờ trên máy trạm làm việc. Điều này dẫn đến việc Netscape phải nhanh chóng đƣa ra phiên bản để sửa “lỗ hổng” bảo mật trong trình duyệt. Hiện nay phiên bản mới nhất của Netscape có khả nǎng bảo mật an toàn cao nhƣng chỉ đƣợc phép dùng trong nƣớc Mỹ.
2.2.11. Ƣu điểm và hạn chế của SSL 2.2.11.1.Ƣu điểm của SSL
Tính năng mạnh nhất của SSL / TLS là chúng xác định mối quan hệ với các tầng giao thức khác nhƣ thế nào trong hệ thống kiến trúc mạng OSI. Tại mức cao nhất là phần mềm ứng dụng hoặc các trình duyệt. Chạy phía dƣới các ứng dụng này là giao thức tầng ứng dụng bao gồm Telnet, FTP, HTTP…
Bên dƣới nữa là giao thức SSL và các thuật toán mã hoá đƣợc sử dụng để kết nối. Bên dƣới SSL là tầng giao vận. Hầu hết các trƣờng hợp đó là TCP/IP. Tuy nhiên, giao thức SSL là duy nhất, không phụ thuộc vào giao thức mạng. Bởi vì SSL không phụ thuộc vào các tầng giao thức, cho nên SSL trở thành một nền tảng độc lập hay là một thực thể mạng độc lập.
Một sức mạnh khác của SSL là ngăn chặn cách thức tấn công từ điển. Cách thức này sử dụng từ điển để phá khoá trong hệ mã hoá. SSL khắc phục đƣợc điều này bởi cho phép không gian khoá là rất lớn đối với hệ mã hoá đƣợc sử dụng. SSL cung cấp hai mức độ tin cậy: 40 bit và 128 bit tuỳ thuộc khả năng của browser. SSL 128 bit và SSL 40 bit ý nói độ dài của khoá phiên dùng để mã hoá dữ liệu sau khi đã định danh và đƣợc thiết lập bằng giải thuật khoá công khai (RSA hoặc Diffie-Hellman). Độ dài của khoá phiên càng lớn thì độ bảo mật càng cao. Hiện nay SSL 128 bit có độ tin cậy lớn nhất. Theo RSA phải mất hàng tỉ năm mới có thể giải mã đƣợc bằng các kỹ thuật hiện nay.
Cách thức tấn công “từ điển” có thể bị ngăn chặn bởi sử dụng phƣơng pháp số Nonce (Nonce number). Số này đƣợc sinh ngẫu nhiên, đƣợc server sử dụng, Nonce number là một số không thể bị phá khoá.
Giao thức SSL còn bảo vệ chính nó với đối tác thứ 3. Đó là các client xâm nhập bất hợp pháp dữ liệu trên đƣờng truyền. Client xâm nhập này có thể giả mạo client hoặc server, SSL ngăn chặn sự giả mạo này bằng cách sử dụng khoá riêng của server và sử dụng chứng chỉ số. Phƣơng thức bắt tay trong TLS cũng tƣơng tự. Tuy nhiên, TLS tăng cƣờng sự bảo mật bằng cách cho phép truyền phiên bản giao thức, số hiệu phiên làm việc, hệ mã hoá và cách thức nén đƣợc sử dụng. TLS bổ xung thêm hai thuật toán băm không có trong SSL.
2.2.11.2.Hạn chế của SSL
Giao thức SSL, cũng giống nhƣ bất kỳ công nghệ nào, cũng có những hạn chế. Vì SSL cung cấp các dịch vụ bảo mật, cần quan tâm đặc biệt tới các giới hạn của nó. Giới hạn của SSL thƣờng là trong ba trƣờng hợp:
Do những ràng buộc cơ bản của bản thân giao thức SSL. Đây là hệ quả của việc thiết kế SSL và ứng dụng chịu tác động của nó.
Do giao thức SSL cũng thừa kế một vài điểm yếu từ các công cụ mà nó sử dụng, cụ thể là các thuật toán ký và mã hoá. Nếu các thuật toán này có điểm yếu, SSL thƣờng không thể khắc phục chúng.
Do môi trƣờng, trong đó SSL đƣợc triển khai, có những thiếu sót và giới hạn. Mặc dù trong thiết kế đã xét đến mối quan hệ với rất nhiều ứng dụng khác nhau, SSL rõ ràng đƣợc tập trung vào việc bảo mật các giao dịch Web. SSL yêu cầu một giao thức vận chuyển tin cậy nhƣ TCP. Đó là yêu cầu hoàn toàn hợp lý trong các giao