View Full Version : Giới thiệu SSL
CHƯƠNG 1: TỔNG QUAN
1.1 Giới thiệu chung về SSL
Chúng ta thường gặp hầu hết giao thức ống ảo ở tầng transport, xa hơn nữa, là giao thức Secure Sockets Layer (SSL) nằm trong những thứ khác, bảo mật những tác vụ HTML (Hypertext Markup Language) trên Web. Khi chúng ta gặp, SSL có rất nhiều những ứng dụng và có thể dễ dàng được sử dụng để xây dựng mục đích tổng quát những đường ống ảo ở tầng Transport. SSL hoạt động trên vùng rộng nghĩa là những tiện ích của TCPdump và SSLdump, hãy xem cách thức chúng ta có thể sử dụng để xây dựng một đường ống ảo giữa hai chương trình hoặc cả hai cái không cần đến những quan tâm đến SSL, cuối cùng hãy xem cách chúng ta có thể sử dụng SSL để xây dựng một VPN giữa hai mạng.
http://i384.photobucket.com/albums/oo289/hamicun/1-3.jpg
1.2 Tổng quan về SSL (Secure Sockets Layer)
http://i384.photobucket.com/albums/oo289/hamicun/2-3.jpg
SSL là một sự xuất hiện bổ sung của VPN trên thị trường. Nó được thiết kế cho những giải pháp truy cập từ xa và không cung cấp những kết nối site-to-site. SSL VPNs cung cấp vấn đề bảo mật truy cập đầu tiên những ứng dụng web. Bởi vì SSL sử dụng trình duyệt web, điển hình là những người sử dụng không phải chạy bất kỳ phần mềm client đặc biệt nào trên những máy tính của họ.
SSL VPNs hoạt động ở tầng phiên (session layer) của mô hình tiêu chuẩn OSI. Và bởi vì client là một trình duyệt web, chỉ những ứng dụng đó mà chúng hổ trợ trình duyệt web, bằng mặc định, nó sẽ làm việc với một giải pháp VPN. Vì thế những ứng dụng như Telnet, FTP, SMTP, POP3, multimedia, hệ thống điện thoại di động IP, điều khiển desktop từ xa, và những cái khác không làm việc với SSL VPNs bởi vì chúng không sử dụng trình duyệt web cho giao diện đầu cuối người dùng của họ. Tất nhiên, nhiều nhà cung cấp cũng sử dụng cả java hoặc ActiveX để nâng cao SSL VPNs bằng việc hổ trợ những ứng dụng không phải là HTTP, những khách hàng là POP3, SMTP e-mail, và tập tin Microsoft Windows và chia sẻ máy in. Ví dụ sự bổ sung SSL VPNs của Cisco hỗ trợ những ứng dụng không phải là web chẳng hạn Citrix, Windows Terminal Services, và nhiều cái khác. Thêm vào đó, một vài nhà cung cấp sử dụng java hay ActiveX để phân phối những thành phần SSL VPNs khác, chẳng hạn như thêm vào những chức năng bảo mật cho việc xóa hết những dấu vết từ một hoạt động của một khách hàng trên máy tính của họ sau khi SSL VPNs đã được kết thúc. Cisco chỉ sự bổ xung SSL VPN như là WebVPN.
1.3 Lịch sử phát triển
SSL được coi là giao thức bảo mật quan trọng lớp vận chuyển (Layer Transport) có tầm quan trọng cao nhất đối với sự bảo mật của các trình ứng dụng trên Web.
Nói chung, có một số khả năng để bảo vệ bằng mật mã lưu lượng dữ liệu HTTP. Ví dụ, vào những năm 1990, tập đoàn CommerceNet đã đề xuất S-HTTP mà về cơ bản là một cải tiến bảo mật của HTTP. Một phần thực thi của S-HTTP đã làm cho có sẵn công cộng trong một phiên bản được chỉnh sửa của trình duyệt Mosaic NCSA mà những người dùng phải mua (trái với trình duyệt Mo NCSA "chuẩn" có sẵn công cộng và miễn phí trên Internet).
Tuy nhiên, cùng thời điểm Netscape Communication đã giới thiệu SSL và một giao thức tương ứng với phiên bản đầu tiên của Netscape Navigator, Trái với tập đoàn CommerceNet, Netscape Communications đã không tính phí các khách hàng của nó về việc thực thi giao thức bảo mật của nó. Kết quả, SSL trở thành giao thức nổi bật để cung cấp các dịch vụ bảo mật cho lưu lượng dữ liệu HTTP 1994 và S-HTTP lặng lẽ biến mất.
Cho đến bây giờ, có ba phiên bản của SSL:
1. SSL 1.0: được sử dụng nội bộ chỉ bởi Netscape Communications. Nó chứa một số khiếm khuyết nghiêm trọng và không bao giờ được tung ra bên ngoài.
2. SSL 2.0: được kết nhập vào Netscape Communications 1.0 đến 2.x. Nó có một số điểm yếu liên quan đến sự hiện thân cụ thể của cuộc tấn công của đối tượng trung gian. Trong một nỗ lực nhằm dùng sự không chắc chắn của công chúng về bảo mật của SSL, Microsoft cũng đã giới thiệu giao thức PCT (Private Communication Technology) cạnh tranh trong lần tung ra Internet Explorer đầu tiên của nó vào năm 1996.
3. Netscape Communications đã phản ứng lại sự thách thức PCT của Microsoft bằng cách giới thiệu SSL 3.0 vốn giải quyết các vấn đề trong SSL 2.0 và thêm một số tính năng mới. Vào thời điểm này, Microsoft nhượng bộ và đồng ý hỗ trợ SSL trong tất cả các phiên bản phần mềm dựa vào TCP/IP của nó (mặc dù phiên bản riêng của nó vẫn hỗ trợ PCT cho sự tương thích ngược).
Thông số kỹ thuật mới nhất của SSL 3.0 đã được tung ra chính thức vào tháng 3 năm 1996. Nó được thực thi trong tất cả các trình duyệt chính bao gồm ví dụ Microsoft Internet Explorer 3.0 (và các phiên bản cao hơn), Netscape Navigator 3.0 (và các phiên bản cao hơn), và Open. Như được thảo luận ở phần sau trong chương này, SSL 3.0 đã được điều chỉnh bởi IETF TLS WG. Thực tế, thông số kỹ thuật giao thức TLS 1.0 dẫn xuất từ SSL 3.0.
CHƯƠNG 2: CẤU TRÚC VÀ CÁC GIAO THỨC BẢO MẬT SSL
2.1 Cấu trúc SSL
Cấu trúc của SSL và giao thức SSL tương ứng được minh họa trong hình 1.1(Cấu trúc SSL và giao thức SSL). Theo hình này, SSL ám chỉ một lớp (bảo mật) trung gian giữa lớp vận chuyển (Transport Layer) và lớp ứng dụng (Application Layer). SSL được xếp lớp lên trên một dịch vụ vận chuyển định hướng nối kết và đáng tin cậy, chẳng hạn như được cung cấp bởi TCP. Về khả năng, nó có thể cung cấp các dịch vụ bảo mật cho các giao thức ứng dụng tùy ý dựa vào TCP chứ không chỉ HTTP. Thực tế, một ưu điểm chính của các giao thức bảo mật lớp vận chuyển (Transport layer) nói chung và giao thức SSL nói riêng là chúng độc lập với ứng dụng theo nghĩa là chúng có thể được sử dụng để bảo vệ bất kỳ giao thức ứng dụng được xếp lớp lên trên TCP một cách trong suốt. Hình 1.1 minh họa một số giao thức ứng dụng điển hình bao gồm NSIIOP, HTTP, FTP, Telnet, IMAP, IRC, và POP3. Tất cả chúng có thể được bảo vệ bằng cách xếp lớn chúng lên trên SSL (mẫu tự S được thêm vào trong các từ ghép giao thức tương ứng chỉ định việc sử dụng SSL).
Tuy nhiên, chú ý rằng SSL có một định hướng client-server mạnh mẽ và thật sự không đáp ứng các yêu cầu của các giao thức ứng dụng ngang hàng.
http://i384.photobucket.com/albums/oo289/hamicun/3-3.jpg
Hình 1.1: Cấu trúc của SSL và giao thức SSL
Tóm lại, giao thức SSL cung cấp sự bảo mật truyền thông vốn có ba đặc tính cơ bản:
1. Các bên giao tiếp (nghĩa là client và server) có thể xác thực nhau bằng cách sử dụng mật mã khóa chung.
2. Sự bí mật của lưu lượng dữ liệu được bảo vệ vì nối kết được mã hóa trong suốt sau khi một sự thiết lập quan hệ ban đầu và sự thương lượng khóa session đã xảy ra.
3. Tính xác thực và tính toàn vẹn của lưu lượng dữ liệu cũng được bảo vệ vì các thông báo được xác thực và được kiểm tra tính toàn vẹn một cách trong suốt bằng cách sử dụng MAC.
Tuy nhiên, điều quan trọng cần lưu ý là SSL không ngăn các cuộc tấn công phân tích lưu lượng. Ví dụ, bằng cách xem xét các địa chỉ IP nguồn và đích không được mã hóa và các sô cổng TCP, hoặc xem xét lượng dữ liệu được truyền, một người phân tích lưu lượng vẫn có thể xác định các bên nào đang tương tác, các loại dịch vụ đang được sử dụng, và đôi khi ngay cả dành được thông tin về các mối quan hệ doanh nghiệp hoặc cá nhân. Hơn nữa, SSL không ngăn các cuộc tấn công có định hướng dựa vào phần thực thi TCP, chẳng hạn như các cuộc tấn công làm tràn ngập TCP SYN hoặc cưỡng đoạt session.
Để sử dụng sự bảo vệ SSL, cả client lẫn server phải biết rằng phía bên kia đang sử dụng SSL. Nói chung, có ba khả năng để giải quyết vấn đề này:
1. Sử dụng các số cổng chuyên dụng được dành riêng bởi Internet Asigned Numbers Authority (IANA). Trong trường hợp này, một số cổng riêng biệt phải được gán cho mọi giao thức ứng dụng vốn sử dụng SSL.
2. Sử dụng số cổng chuẩn cho mọi giao thức ứng dụng và để thương lượng các tùy chọn bảo mật như là một phần của giao thức ứng dụng (bây giờ được chỉnh sửa đôi chút).
3. Sử dụng một tùy chọn TCP để thương lượng việc sử dụng một giao thức bảo mật, chẳng hạn như SSL trong suốt giai đoạn thiết lập nối kết TCP thông thường.
Sự thương lượng dành riêng cho ứng dụng của các tùy chọn bảo mật (nghĩa là khả năng thứ hai) có khuyết điểm là đòi hỏi mọi giao thức ứng dụng được chỉnh sửa để hiểu tiến trình thương lượng. Ngoài ra, việc xác định một tùy chọn TCP (nghĩa là khả năng thứ ba) là một giải pháp tốt, nhưng đó không được thảo luận nghiêm túc cho đến bây giờ. Thực tế, các số cổng riêng biệt đã được dành riêng và được gán bởi IANA cho mọi giao thức ứng dụng vốn có thể chạy trên SSL hoặc TLS (nghĩa là khả năng thứ nhất). Tuy nhiên, hãy chú ý việc sử dụng các số cổng riêng biệt cũng có khuyết điểm là đòi hỏi hai nối kết TCP nếu client không biết những gì mà server hỗ trợ. Trước tiên, client phải nối kết với cổng an toàn và sau đó với cổng không an toàn hay ngược lại. Rất có thể các giao thức sau này sẽ hủy bỏ phương pháp này và tìm khả năng thứ hai. Ví dụ, SALS (Simple Authentication và Security Layer) xác định một phù hợp để thêm sự hỗ trợ xác thực vào các giao thức ứng dụng dựa vào kết nối. Theo thông số kỹ thuật SALS, việc sử dụng các cơ chế xác thực có thể thương lượng giữa client và server của một giao thức ứng dụng đã cho.
Các số cổng được gán bởi IANA cho các giao thức ứng dụng vốn chạy trên SSL/TLS được tóm tắt trong bảng 1.2 và được minh họa một phần trong hình 1.1. Ngày nay, "S" chỉ định việc sử dụng SSL được thêm (hậu tố) nhất quán vào các từ ghép của các giao thức ứng dụng tương ứng (trong một số thuật ngữ ban đầu, S được sử dụng và được thêm tiền tố một cách không nhất quán và một số từ ghép).
http://i384.photobucket.com/albums/oo289/hamicun/1-4.jpg
Bảng1.2: Các số cổng được gán cho các giao thức ứng dụng chạy trên TLS/SSL.
Nói chung, một session SSL có trạng thái và giao thức SSL phải khởi tạo và duy trì thông tin trạng thái ở một trong hai phía của session. Các phần tử thông tin trạng thái session tương ứng bao gồm một session ID, một chứng nhận ngang hàng, một phương pháp nén, một thông số mật mã, một khóa mật chính và một cờ vốn chỉ định việc session có thể tiếp tục lại hay không, được tóm tắt trong bảng 1.3. Một session SSL có thể được sử dụng trong một số kết nối và các thành phần thông tin trạng thái nối kết tương ứng được tóm tắt trong bảng 1.4. Chúng bao
gồm các tham số mật mã, chẳng hạn như các chuỗi byte ngẫu nhiên server và client, các khóa mật MAC ghi server và client, các khóa ghi server và client, một vector khởi tạo và một số chuỗi. Ở trong hai trường hợp, điều quan trọng cần lưu ý là các phía giao tiếp phải sử dụng nhiều session SSL đồng thời và các session có nhiều nối kết đồng thời.
http://i384.photobucket.com/albums/oo289/hamicun/2-4.jpg
Bảng 1.3 Các thành phần thông tin trạng thái Session SSL
http://i384.photobucket.com/albums/oo289/hamicun/3-4.jpg
Bảng 1.4 Các thành phần thông tin trạng thái nối kết SSL
Như được minh họa trong hình 1.1, giao thức SSL gồm hai phần chính, SSL Record Protocol và một số giao thức con SSL được xếp lớp trên nó:
- Record OK được xếp lớp trên một dịch vụ lớp vận chuyển định hướng nối kết và đáng tin cậy, chẳng hạn như được cung cấp bởi TCP và cung cấp sự xác thực nguồn gốc thông báo, sự bí mật dữ liệu và dữ liệu.
- Các dịch vụ toàn vẹn (bao gồm nhưng thứ như chống xem lại).
- Các giao thức con SSL được xếp lớp trên SSL Record Protocol để cung cấp sự hỗ trợ cho việc quản lý session SSL và thiết lập nối kết.
Giao thức con SSL quan trọng nhất là SSL Handshake Protocol. Lần lượt giao thức này là một giao thức xác thực và trao đổi khóa vốn có thể được sử dụng để thương lượng, khởi tạo và đồng bộ hóa các tham số bảo mật và thông tin trạng thái tương ứng được đặt ở một trong hai điểm cuối của một session hoặc nối kết SSL.
Sau khi SSL Handshake Protocol đã hoàn tất, dữ liệu ứng dụng có thể được gửi và được nhận bằng cách sử dụng SSL Record Protocol và các tham số bảo mật được thương lượng và các thành phần thông tin trạng thái.
Các số cổng được gán bởi IANA cho các giao thức ứng dụng vốn chạy trên SSL/TLS được tóm tắt trong bảng 1.2 và được minh họa một phần trong hình 1.1. Ngày nay, "S" chỉ định việc sử dụng SSL được thêm (hậu tố) nhất quán vào các từ ghép của các giao thức ứng dụng tương ứng (trong một số thuật ngữ ban đầu, S được sử dụng và được thêm tiền tố một cách không nhất quán và một số từ ghép).
Bảng1.2: Các số cổng được gán cho các giao thức ứng dụng chạy trên TLS/SSL.
http://i384.photobucket.com/albums/oo289/hamicun/Hinh1-2.jpg
Nói chung, một session SSL có trạng thái và giao thức SSL phải khởi tạo và duy trì thông tin trạng thái ở một trong hai phía của session. Các phần tử thông tin trạng thái session tương ứng bao gồm một session ID, một chứng nhận ngang hàng, một phương pháp nén, một thông số mật mã, một khóa mật chính và một cờ vốn chỉ định việc session có thể tiếp tục lại hay không, được tóm tắt trong bảng 1.3. Một session SSL có thể được sử dụng trong một số kết nối và các thành phần thông tin trạng thái nối kết tương ứng được tóm tắt trong bảng 1.4. Chúng bao gồm các tham số mật mã, chẳng hạn như các chuỗi byte ngẫu nhiên server và client, các khóa mật MAC ghi server và client, các khóa ghi server và client, một vector khởi tạo và một số chuỗi. Ở trong hai trường hợp, điều quan trọng cần lưu ý là các phía giao tiếp phải sử dụng nhiều session SSL đồng thời và các session có nhiều nối kết đồng thời.
Bảng 1.3 Các thành phần thông tin trạng thái Session SSL
http://i384.photobucket.com/albums/oo289/hamicun/Hinh2.jpg
Bảng 1.4 Các thành phần thông tin trạng thái nối kết SSL
http://i384.photobucket.com/albums/oo289/hamicun/Hinh3.jpg
Như được minh họa trong hình 1.1, giao thức SSL gồm hai phần chính, SSL Record Protocol và một số giao thức con SSL được xếp lớp trên nó:
- Record OK được xếp lớp trên một dịch vụ lớp vận chuyển định hướng nối kết và đáng tin cậy, chẳng hạn như được cung cấp bởi TCP và cung cấp sự xác thực nguồn gốc thông báo, sự bí mật dữ liệu và dữ liệu.
- Các dịch vụ toàn vẹn (bao gồm nhưng thứ như chống xem lại).
- Các giao thức con SSL được xếp lớp trên SSL Record Protocol để cung cấp sự hỗ trợ cho việc quản lý session SSL và thiết lập nối kết.
Giao thức con SSL quan trọng nhất là SSL Handshake Protocol. Lần lượt giao thức này là một giao thức xác thực và trao đổi khóa vốn có thể được sử dụng để thương lượng, khởi tạo và đồng bộ hóa các tham số bảo mật và thông tin trạng thái tương ứng được đặt ở một trong hai điểm cuối của một session hoặc nối kết SSL.
Sau khi SSL Handshake Protocol đã hoàn tất, dữ liệu ứng dụng có thể được gửi và được nhận bằng cách sử dụng SSL Record Protocol và các tham số bảo mật được thương lượng và các thành phần thông tin trạng thái.
2. 2 Các giao thức bảo mật SSL
SSL Record Protocol nhận dữ liệu từ các giao thức con SSL lớp cao hơn và xử lý việc phân đoạn, nén, xác thực và mã hóa dữ liệu. Chính xác hơn, giao thức này lấy một khối dữ liệu có kích cỡ tùy ý làm dữ liệu nhập và tọa một loạt các đoạn dữ liệu SSL làm dữ liệu xuất (hoặc còn được gọi là các bản ghi) nhỏ hơn hoặc bằng 16,383 byte.
hình 1.5: Các bước SSL Record Protocol.
http://i384.photobucket.com/albums/oo289/hamicun/Hinh4.jpg
Các bước khác nhau của SSL Record Protocol vốn đi từ một đoạn dữ liệu thô đến một bản ghi SSL Plaintext (bước phân đoạn), SSL Compressed (bước nén) và SSL Ciphertext (bước mã hóa) được minh họa trong hình 1.5. Sau cùng, mỗi bản ghi SSL chứa các trường thông tin sau đây:
- Loại nội dung;
- Số phiên bản của giao thức;
- Chiều dài;
- Tải trọng dữ liệu (được nén và được mã hóa tùy ý);
- MAC.
Loại nội dung xác định giao thức lớp cao hơn vốn phải được sử dụng để sau đó xử lý tải trọng dữ liệu bản ghi SSL (sau khi giải nén và giải mã hóa thích hợp).
Số phiên bản của giao thức xác định phiên bản SSL đang sử dụng (thường là version 3.0)
Mỗi tải trọng dữ liệu bản ghi SSL được nén và được mã hóa theo phương thức nén hiện hành và thông số mật mã được xác định cho session SSL.
Lúc bắt đầu mỗi session SSL, phương pháp nén và thông số mật mã thường được xác định là rỗng. Cả hai được xác lập trong suốt quá trình thực thi ban đầu SSL Handshake Protocol. Sau cùng, MAC được thêm vào mỗi bản ghi SSL. Nó cung cấp các dịch vụ xác thực nguồn gốc thông báo và tính toàn vẹn dữ liệu. Tương tự như thuật toán mã hóa, thuật toán vốn được sử dụng để tính và xác nhận MAC được xác định trong thông số mật mã của trạng thái session hiện hành. Theo mặc định, SSL Record Protocol sử dụng một cấu trúc MAC vốn tương tự nhưng vẫn khác với cấu trúc HMAC hơn. Có ba điểm khác biệt chính giữa cấu trúc SSL MAC và cấu trúc HMAC:
1. Cấu trúc SSL MAC có một số chuỗi trong thông báo trước khi hash để ngăn các hình thức tấn công xem lại riêng biệt.
2. Cấu trúc SSL MAC có chiều dài bản ghi.
3. Cấu trúc SSL MAC sử dụng các toán tử ghép, trong khi cấu trúc MAC sử dụng moduloe cộng 2.
Tất cả những điểm khác biệt này hiện hữu chủ yếu vì cấu trúc SSL MAC được sử dụng trước cấu trúc HMAC trong hầu như tất cả thông số kỹ thuật giao thức bảo mật Internet. Cấu trúc HMAC cũng được sử dụng cho thông số kỹ thuật giao thức TLS gần đây hơn.
Như được minh họa trong hình 1.5, một số giao thức con SSL được xếp lớp trên SSL Record Protocol. Mỗi giao thức con có thể tham chiếu đến các loại thông báo cụ thể vốn được gửi bằng cách sử dụng SSL Record Protocol. Thông số kỹ thuật SSL 3.0 xác định ba giao thức SSL sau đây:
- Alert Protocol;
- Handshake Protocol;
- ChangeCipherSpec Protocol;
Tóm lại, SSL Alert Protocol được sử dụng để chuyển các cảnh báo thông qua SSL Record Protocol. Mỗi cảnh báo gồm 2 phần, một mức cảnh báo và một mô tả cảnh báo.
SSL Handshake Protocol là giao thức con SSL chính được sử dụng để hỗ trợ xác thực client và server và để trao đổi một khóa session. Do đó SSL Handshake Protocol trình bày tổng quan và được thảo luận trong phần tiếp theo.
Sau cùng, SSL ChangeCipherSpec Protocol được sử dụng để thay đổi giữa một thông số mật mã này và một thông số mật mã khác. Mặc dù thông số mật mã thường được thay đổi ở cuối một sự thiết lập quan hệ SSL, nhưng nó cũng có thể được thay đổi vào bất kỳ thời điểm sau đó.
Ngoài những giao thức con SSL này, một SSL Application Data Protocol được sử dụng để chuyển trực tiếp dữ liệu ứng dụng đến SSL Record Protocol.
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 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 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 site của nó đến client trong một thông báo CERTIFICATE tương ứng. 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 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 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 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 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 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 đã 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 dun
Những bổ sung SSL Client (SSL Client Implementations)
Một nguyên nhân chính mà những người quản trị mạng yêu cầu đưa ra những bổ sung SSL VPN những giao thức SSL VPNs mà không yêu cầu bất cứ loại phần mềm đặc biệt của VPN Client nào để được cài đặt trước trên những máy tính để bàn của người sử dụng. Tất nhiên, người sử dụng biết một vài phần mềm cần thiết, giống như một trình duyệt web đươc hổ trợ SSL, đặc thù với cả Java và ActiveX cũng được hổ trợ, và hầu như người sử dụng đã cài những điều này từ một sự cài đặt ban đầu trên máy tính.
Có 3 loại SSL Client Implementation tổng quát:
• Clientless
• Thin client
• Network client
Bởi vì chỉ một trình duyệt web được yêu cầu trên máy tính người sử dụng, SSL client thông thường được xem như là “Clientless” hoặc “webified”. Vì thế SSL VPN thỉnh thoảng được gọi là clientless VPN. Điều trở ngại chính của một clientless VPN là chỉ giao thông dạng web có thể được bảo vệ.
Đặc thù của một Thin client là phần mềm java hoặc ActiveX đã tải xuống thông qua SSL VPN đến máy tính người sử dụng. Nó cho phép một tập hợp nhỏ những ứng dụng không phải là web được vận chuyển thông qua SSL VPN. Trong việc truy cập dựa vào mạng, một SSL client được cài đặt trên máy tính của người sử dụng; tuy nhiên, đặc tính này được tải xuống máy tính của người sử dụng.
SSL Protection
SSL VPN không cần thiết cung cấp việc bảo vệ của dữ liệu ở tầng network, chẳng hạn như IPSec, PPTP, và L2TP. Client SSL VPN cung cấp việc bảo vệ cho những ứng dụng web ở tầng Session (tầng thứ 5) mà chúng sử dụng trình duyệt web. Vì thế, nó sử dụng việc bảo vệ giao thông ở một vài thứ được giới hạn, cho ứng dụng giao thông được bảo vệ, một vài cách sự truy cập của người sử dụng đến ứng dụng phải thông qua một trình duyệt web. Tất nhiên, bất kỳ một cách kết nối kiểu HTTP có thể dễ dàng được bảo vệ bởi vì người sử dụng sử dụng trình duyệt web cho kiểu chức năng này, nhưng điều này có thể xuất hiện những vấn đề cho những kiểu ứng dụng khác, chẳng hạn như Telnet, POP3, SMTP, SNMP, ping, traceroute, FTP, IP telephony, Citrix, Oracle’s SQL*net, tập tin và việc chia sẽ máy in thông qua Windows hoặc Unix và nhiều thứ khác.
Sự khác nhau giữa IPSec và SSL VPNs:
• IPSec cung cấp sự bảo vệ cho những gói IP và những giao thức đã vận chuyển hai mạng hoặc giữa hai máy.
• SSL VPNs cung cấp việc bảo vệ cho sự truy cập của người sử dụng đến những dịch vụ và những ứng dụng trên mạng.
Kiến trúc mạng:
file:///C:/Users/Dv5T/AppData/Local/Temp/msohtmlclip1/01/clip_image001.gif
Một SSL được cấu hình trên Router:
+ Chuẩn độc lập.
+ Giải quyết ECT và kết nối với một hub server DMVPN.
Hoạt động:
o Dùng một trình duyệt web được enable SSL,người dùng thiết lập một kết nối đến SSL VPN.
o Phiên SSL VPN được thiết lập.
o Người dùng truy cập trong cùng một mạng.
Chú ý: SSL VPN cung cấp một lối đi vào mạng. Nó luôn được thiết lập sau tường lửa.
Đặc điểm:
* Dùng IE để thiết lập một kết nối đến cổng SSL VPN.
* Cổng SSL VPN sẽ đáp ứng với người dùng đăng nhập vào trang HTML.
* Usename và password sẽ được xác nhận đến cổng cho việc chứng thực với máy chủ RADIUS.
* Nếu một phiên được thiết lập, cổng sẽ được duy trì băng cách gửi một phiên ”cookies”.
* Cookies này phải ghi nhớ tất cả các ngừời dùng HTTP tiếp theo để yêu cầu cho việc chứng thực tại cổng SSL VPN.
* Nếu cookies này bị lỗi hay bị hỏng, phiên này sẽ bị ngưng và người dùng sẽ không truy cập trong cùng mạng được nữa.
* Việc dùng phiên để ghi nhớ mãi cho đến khi người dùng log out, phiên này sẽ ngưng hay bị xoá sạch bởi cổng SSL VPN.
* Trang SSL VPN và các toolbar sẽ được trình bày trên trình duyệt web của người dùng.
* Từ trang này người dùng có thể truy cập đến các trang HTTP có sẵn bằng cách nhấn vào ” Start Application Access” link ,người dùng có thể truy cập lại đến các server bên trong được cấu hình thông qua cổng chuyển tiếp TCP.
TCP port forwarding
• Người dùng download một java applet để bắt đầu một yêu cầu HTTP đến cổng SSL VPN từ client.
• Cổng SSL VPN sẽ tạo một kết nối TCP đến server.
• Sau khi cài đặt, kết nối giữa client và server sẽ được xử lí như là một đường nối SSL với những gói tin TCP đang được chuyển từ một hướng khác.
CHƯƠNG 3: GIẢI PHÁP BẢO MẬT VỚI SSL
3. 1 Phân tích
Truyền thông HTTP được định nghĩa cho máy chủ Web nói chung, thông thường là các trang thông tin. Tuy nhiên nếu đang nghĩ đến việc chạy một trang điện tử hoặc các dịch vụ Web khác yêu cầu phiên giao dịch an toàn thì bạn cần phải mã hóa dữ liệu được truyền thông giữa máy chủ Web và các máy khách của nó. Trường hợp thường được sử dụng nhất đó là Secure Sockets Layer (SSL), SSL sử dụng mã hóa khóa công khai để bảo vệ thông tin bí mật của người dùng (như là thẻ tín dụng, số tài khoản ngân hàng) vẫn được truyền tải trên Web. Trong bài viết này chúng tôi sẽ giới thiệu với các bạn SSL làm việc như thế nào và làm thế nào để kích hoạt nó trên máy chủ Internet Information Services (IIS) Web của bạn.
SSL sử dụng chứng chỉ số được đưa ra bởi một nhóm có thẩm quyền về cấp chứng chỉ hợp lệ (CA) để thẩm định các thành phần tham dự liên quan đến phiên giao dịch (cả máy khách và máy chủ). Nếu máy chủ Web được thiết lập yêu cầu đến các kết nối an toàn thì nó sẽ từ chối những yêu cầu không an toàn. Để kết nối đến một trang an toàn, máy khách phải sử dụng https:// để bắt đầu địa chỉ URL thay vì http://.
Nếu một số thành phần trên trang sử dụng http:// trong các liên kết thì người duyệt web sẽ nhận được một thông báo cho biết rằng một số mục trên trang này là không an toàn. Bạn có thể tránh được điều này bằng cách sử dụng https:// cho tất cả các liên kết hoặc sử dụng một đường dẫn tương đối không chứa “http” hay “https”.
http://i384.photobucket.com/albums/oo289/hamicun/Hinh5.jpg
Khi trình duyệt của máy khách khởi tạo một kết nối an toàn, “sự bắt tay” SSL xuất hiện. Trình duyệt sẽ kiểm tra chứng chỉ để xác nhận tính hợp lệ đồng nhất của máy chủ, giá trị của chứng chỉ và xác nhận chứng chỉ đã hết hạn sử dụng. Sau đó máy khách và máy chủ tìm ra phương pháp mã hóa và các khóa để sử dụng.
Khi thủ tục “bắt tay” được hoàn tất, một khóa mới sẽ được tạo và khóa này sử dụng để tạo các khóa session, khóa session được dùng để mã hóa phần tin còn lại bằng sử dụng phương pháp mã hóa giữa máy khách và máy chủ. Máy chủ sẽ thích hợp với máy khách nếu nó được cấu hình để xác nhận thẩm quyền máy khách.
Khi một yêu cầu HTTP được gửi đi, các yêu cầu trong trường biểu mẫu và các biến chương trình (biến được gắn vào phần cuối của URL) được gỡ bỏ khỏi URL và được chèn vào khối dữ liệu đã mã hóa, dữ liệu đã mã hóa gồm có dữ liệu được nhập vào trên biểu mẫu trong trình duyệt máy khách. Đáp ứng từ phía máy chủ cũng tương tự như vậy khi nó trả về cho máy khách.
3.2 Thực thi
Bước đầu tiên trong việc thực thi SSL cho Web site của bạn đó là phải có được chứng chỉ SSL từ một trung tâm cấp chứng chỉ SSL. Chứng chỉ SSL của Web Server để phân biệt tên miền và địa chỉ IP riêng biệt của nó. Bạn có thể mua chứng chỉ SSL từ các nhà cung cấp chứng chỉ như Verisign, Thawte, Entrust hay một số nhà cung cấp chứng chỉ công cộng khác. Chứng chỉ của những công ty đó đều được các trình duyệt lớn nhận ra. Bạn cũng có thể có được chứng chỉ từ một CA nội bộ.
Để cấu hình IIS 6.0 Web site (chạy trên Windows Server 2003) sử dụng mã hóa SSL, bạn thực hiện theo các bước dưới đây:
1. Mở IIS Manager từ menu Programs | Administrative Tools
2. Trong cửa sổ bên trái của giao diện người dùng, bạn mở nút có tên Web server (trong ví dụ là CA1), sau đó mở rộng thư mục Web Sites như trong hình A.
http://i384.photobucket.com/albums/oo289/hamicun/Hinh6.jpg
Hình A: Mở thư mục Web Sites trong IIS Manager
3. Kích chuột phải vào Web site mà bạn muốn sử dụng SSL, sau đó chọn Properties để mở được trang thuộc tính Properties cho trang này.
4. Kích vào tab Directory Security như trong hình B.
http://i384.photobucket.com/albums/oo289/hamicun/Hinh7.jpg
Hình B: Tab Directory Security
6. Bên dưới Secure Communications, bạn kích chuột vào nút Server Certificate. Động tác này sẽ khởi chạy Web Server Certificate Wizard. Kích nút Next trên trang đầu tiên của Wizard.
7. Trên trang Server Certificate, bạn sẽ có các lựa chọn như sau: Create a new certificate (Tạo một chứng chỉ mới), Assign an existing certificate (Gán một chứng chỉ đang tồn tại), Import a certificate from a Key Manager backup file (Nhập một chứng chỉ từ file backup Key Manager), Import a certificate from a .pfx file (Nhập một chứng chỉ từ file .pfx), Copy or move a certificate from a remote server to this site (Sao chép hoặc di chuyển một chứng chỉ từ một máy chủ điều khiển từ xa đến site này). Tạo lựa chọn thích hợp và theo các bước dưới đây. Để nhập một chứng chỉ, bạn cần biết:
•Đường dẫn tới nơi mà chứng chỉ được lưu
•Mật khẩu trên file .pl
Để tạo một chứng chỉ mới, bạn cần gửi yêu cầu đến một bộ phận có thẩm quyền cấp chứng chỉ cho mạng của bạn hoặc chuẩn bị yêu cầu và gửi nó một cách thủ công đến CA không trên mạng của bạn. Bạn phải nhập vào URL cho Web site và nếu dự định là cho site này có thể dùng được trên Internet thì tên của nó phải hợp với tên miền riêng bên ngoài trang. Nếu trang chỉ sử dụng cho người dùng nội bộ thì bạn có thể sử dụng tên NetBIOS.
8. Nếu đang tạo một chứng chỉ mới, bạn phải nhập vào vị trí địa lý của mình (như là quốc gia, tỉnh thành,…) trong trang thông tin địa lý.
9. Yêu cầu chứng chỉ sẽ được lưu dưới dạng file text nếu bạn chọn tạo yêu cầu thủ công và gửi nó đến sau. Nhập vào tên cho file văn bản này.
10. Xem lại những thông tin yêu cầu trên trang Request File Summary và kích Next để tạo file. Bạn có thể gửi file đến bộ phận cấp chứng chỉ.
Nếu đang đệ trình một yêu cầu đến CA nội bộ:
11. Bảo đảm rằng cổng 443 được chọn trong trang SSL Port
12. Chọn CA trong trang Choose a Certification Authority
13. Xem lại thông tin yêu cầu và kích Next để đệ trình yêu cầu trong trang Certificate Request Submission
Bạn có thể xóa yêu cầu bằng cách chạy Wizard một lần nữa. Trở về tab Directory Security trong trang thuộc tính và kích Server Certificate. Wizard sẽ thông báo rằng một yêu cầu chứng chỉ đang chờ và hỏi xem bạn có muốn tiếp tục yêu cầu đang chờ và cài đặt hay xóa yêu cầu đang chờ này hay không.
Khi có chứng chỉ, bạn có thể bảo đảm cho Web site bằng những bước dưới đây:
1. Trên tab Directory Security của trang thuộc tính, dưới Secure Communications, bạn kích nút Edit (lưu ý rằng có 3 nút Edit trên trang này; bạn chỉ kích vào nút dưới Secure Communications).
2. Tích vào hộp Require secure channel (SSL) tại phần trên cùng của hộp thoại Secure Communications. Nếu bạn muốn yêu cầu mã hóa 128 bit, hãy tích vào hộp kiểm thích hợp như những gì thể hiện trong hình C. Một số trình duyệt cũ có thể không hỗ trợ mã hõa 128 bit.
http://i384.photobucket.com/albums/oo289/hamicun/Hinh8.jpg
Hình C: Thiết lập yêu cầu về an toàn SSL
3. Dưới Client Certificates, bạn cần phải quyết định chọn xem muốn bỏ qua các chứng chỉ máy khác, chấp nhận hoặc yêu cầu chứng chỉ máy khách. Bạn cũng có thể ánh xạ các chứng chỉ máy khách đối với tài khoản người dùng Windows ở đây và kích hoạt danh sách chứng chỉ thực Certificate Trust List. Kích OK khi đã kết thúc việc cấu hình các thiết lập đó.
4. Quay trở lại tab Directory Security, dưới Authentication và Access Control tại phần trên của trang, bạn kích nút Edit.
5. Dưới Authenticated Access, bạn có thể chọn tên người dùng yêu cầu và mật khẩu của họ bất kỳ hoặc tất cả các phương pháp thẩm định sau đây: thẩm định Integrated Windows, thẩm định Digest cho các máy chủ miền Windows, thẩm định cơ bản Basic, NET Passport,…. Sau khi cấu hình các tham chiếu ở đây, bạn kích OK.
6. Kích OK một lần nữa để đóng các hộp thoại và đóng IIS MMC.
Kiểm tra kết nối
Để thẩm định rằng kết nối SSL của bạn làm việc, trong trình duyệt nhập vào tên của máy chủ (tên miền đầy đủ cho Internet Web server hoặc tên NetBIOS cho máy chủ nội bộ), gõ https:// vào vị trí bắt đầu của URL. Bạn sẽ nhận được một thông báo rằng bạn đang xem các trang trên một kết nối an toàn. Kích OK. Web site an toàn sẽ được hiển thị.
Tớ có câu hỏi về SSL/TLS mong được các anh/chị giúp đỡ
Vì sao SSL/TLS có một giao thức Change Cipher Spec riêng thay vì sử dụng một thông báo change_cipher_spec trong giao thức Handshake?
Vì sao SSL/TLS có thể chống được hình thức tấn công gửi lại thông báo trong giao thức Handshake?Vì sao SSL/TLS có một giao thức Change Cipher Spec riêng thay vì sử dụng một thông báo change_cipher_spec trong giao thức Handshake?
Với câu hỏi thứ nhất em có đọc một vài tài liêu thấy giao thức Change Cipher Spec cho phép thay đổi thuật toán hay là các tham số trong quá trình trao đổi. Em Không biết câu trả lời đúng chưa mong được giúp đỡ
Powered by vBulletin® Version 4.1.9 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.