Uploaded byconglongit90
17,212 views

Giao thức bảo mật SSL

Tài liệu này nghiên cứu về SSL (Secure Socket Layer) và TLS (Transport Layer Security), giới thiệu kiến trúc, giao thức và quy trình hoạt động của chúng trong việc bảo mật thông tin trực tuyến. Nó giải thích vai trò của SSL trong việc xác thực danh tính, mã hóa dữ liệu và đảm bảo tính toàn vẹn của thông tin trong các giao dịch thương mại điện tử. Bên cạnh đó, tài liệu cũng thảo luận về các cuộc tấn công đối với SSL và khả năng ứng dụng của nó trong việc bảo mật thông tin.

Embed presentation

Downloaded 1,428 times
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG TPHCM KHOA CÔNG NGHỆ THÔNG TIN II  ĐỀ TÀI MÔN BẢO MẬT THÔNG TIN Giáo viên hướng dẫn : Ths.Lê Phúc Sinh viên thực hiện : Huỳnh Anh Hào Võ Thị Thu Nguyệt Lê Thanh Phong Nguyễn Thị Thanh Thảo Thành phố Hồ Chí Minh 12/2009
PTIT 2009 Đề tài môn Bảo mật thông tin MỤC LỤC Giới Thiệu CHƢƠNG I : SECURE SOCKET LAYER & TRANSPORT LAYER SECURITY ........................................... 5 I.1 Tại sao sử dụng SSL ............................................................................................................................................ 5 I.2 Kiến trúc SSL....................................................................................................................................................... 9 I.3 Giao thức SSL Record ....................................................................................................................................... 10 I.4 Giao thức SSL Change Cipher Spec .................................................................................................................. 13 I.5 Giao thức SSL Alert........................................................................................................................................... 13 I.6 Giao thức SSL Handshake ................................................................................................................................. 15 I.6.1 Giai đoạn 1 : Thiết lập khả năng bảo mật .............................................................................................. 16 I.6.2 Giai đoạn 2 : Xác thực server và trao đổi khóa...................................................................................... 18 I.6.3 Giai đoạn 3 : Xác thực client và trao đổi khóa ...................................................................................... 19 I.6.4 Giai đoạn 4 : Kết thúc ............................................................................................................................ 19 I.7 Tính toán mã hóa ............................................................................................................................................... 20 I.7.1 Việc tạo Master Secret ........................................................................................................................... 20 I.7.2 Việc sinh các tham số mã hóa ................................................................................................................ 21 I.8 Transport Layer Security ................................................................................................................................... 22 I.8.1 Version number ..................................................................................................................................... 22 I.8.2 Message Authentication Code ............................................................................................................... 22 I.8.3 Hàm tính số ngẫu nhiên ......................................................................................................................... 23 I.8.4 Mã cảnh báo........................................................................................................................................... 24 I.8.5 Cipher suite ............................................................................................................................................ 25 I.8.6 Các dạng client certificate ..................................................................................................................... 25 I.8.7 Certificate Verify và Finished Message................................................................................................. 26 I.8.8 Tính toán mã hóa ................................................................................................................................... 26 I.8.9 Phần đệm ............................................................................................................................................... 26 CHƢƠNG II : JAVA SECURE SOCKET EXTENSION API ............................................................................. 27 II.1 Quan hệ giữa các Class ..................................................................................................................................... 27 II.2 Các Class và Interface chính ............................................................................................................................. 28 II.2.1 Lớp SocketFactory và ServerSocketFactory ........................................................................................ 28 II.2.2 Lớp SSLSocketFactory và SSLServerSocketFactory .......................................................................... 28 II.2.3 Lớp SSLSocket và SSLServerSocket ................................................................................................... 29 Secure Socket Layer 2
PTIT 2009 Đề tài môn Bảo mật thông tin II.2.4 Non-blocking I/O với SSLEngine ........................................................................................................ 30 II.2.5 Quá trình khởi động.............................................................................................................................. 31 II.2.6 Phát sinh và xử lý dữ liệu SSL/TLS ..................................................................................................... 32 II.2.7 Trạng thái hoạt động............................................................................................................................. 34 II.2.8 Blocking Tasks ..................................................................................................................................... 35 II.2.9 Kết thúc ................................................................................................................................................ 35 II.2.10 SSLSession Interface .......................................................................................................................... 36 II.2.11 Lớp HttpsURLConnection ................................................................................................................. 36 II.3 Các Class và Interface hỗ trợ ............................................................................................................................ 37 II.3.1 Lớp SSLContext ................................................................................................................................... 38 II.3.2 TrustManager Interface ........................................................................................................................ 39 II.3.3 Lớp TrustManagerFactory.................................................................................................................... 39 II.3.4 X509TrustManager Interface ............................................................................................................... 42 II.3.5 KeyManager Interface .......................................................................................................................... 44 II.3.6 Lớp KeyManagerFactory ..................................................................................................................... 45 II.3.7 X509KeyManager Interface ................................................................................................................. 46 II.3.8 Mối liên hệ TrustManagers và KeyManagers ..................................................................................... 46 II.4 Các Class và Interface hỗ trợ thứ cấp................................................................................................................ 47 II.4.1 SSLSessionContext Interface ............................................................................................................... 47 II.4.2 SSLSessionBindingListener Interface .................................................................................................. 47 II.4.3 Lớp SSLSessionBindingEvent ............................................................................................................. 47 II.4.4 HandShakeCompletedListener Interface .............................................................................................. 47 II.4.5 Lớp SSLHandShakeCompletedEvent .................................................................................................. 47 II.4.6 HostnameVerifier Interface .................................................................................................................. 47 II.4.7 Lớp X509Certificate ............................................................................................................................. 48 CHƢƠNG III : SSL ATTACK ................................................................................................................................ 49 III.1 Các phương pháp tấn công SSL dựa trên kỹ thuật tấn công MITM ................................................................ 49 III.1.1 Diffie Hellman MITM Attack ............................................................................................................. 49 III.1.2 SSL Sniff & SSLSTrip MITM Attack ................................................................................................ 46 III.2 Demo tấn công SSL Strip ................................................................................................................................ 51 CHƢƠNG IV : SSL CAPABILITY ........................................................................................................................ 52 IV.1 Các ứng dụng phổ biến của SSL ..................................................................................................................... 52 IV.2 Triển khai SSL ................................................................................................................................................ 54 Tham khảo Secure Socket Layer 3
PTIT 2009 Đề tài môn Bảo mật thông tin Giới thiệu : Mục tiêu thực hiện đề tài này của những thành viên tham gia là đi sâu tìm hiểu về :  Cấu trúc cũng như cơ chế hoạt động của SSL.  Lập trình xây dựng một web server chạy SSL.  Cách thức tấn công một phiên giao dịch SSL.  Khả năng ứng dụng SSL trong bảo mật thông tin. Đây là lần đầu thực hiện một đề tài lớn nên còn nhiều thiếu sót , mong Thầy và các bạn đóng góp ý kiến để đề tài được hoàn thiện hơn. Chúng em xin cảm ơn sự hướng dẫn nhiệt tình của Thầy Ths.Lê Phúc đã giúp chúng em hoàn thành đề tài này. Secure Socket Layer 4
PTIT 2009 Đề tài môn Bảo mật thông tin Chương I : I.1 Tại sao sử dụng SSL : Ngày nay việc bảo mật thông tin là yếu tố quan trọng để quyết định sự sống còn của một tổ chức ,một công ty hay doanh nghiệp . Với sự phát triển nhanh chóng của công nghệ đã mang lại nhiều tiện ích cho người dùng nhưng đồng thời cũng đặt ra một nhu cầu hết sức cấp thiết về sự an toàn và bảo mật .Và SSL chính là giải pháp tốt nhất hiện nay đáp ứng những nhu cầu đó và nó được coi như là “lá chắn cuối cùng” trong bảo mật thương mại điện tử. Giao thức SSL ban đầu được phát triển bởi Netscape.Version 1.0 thì đã không bao giờ được công bố rộng rãi.Version 2.0 được công bố vào tháng 2/1995 nhưng chứa nhiều lỗ hỏng bảo mật và sau cùng đưa đến mô hình SSL version 3.0 được ban hành năm 1996.Bản sau cùng này được dùng cho TLS version 1.0 và được IETF xác định như một giao thức chuẩn trong RFC 2246 vào tháng 1/1999. Ngày nay Visa, MasterCard, American Express cũng như nhiều công ty giải pháp tài chính hàng đầu khác trên thế giới đã và đang ứng dụng SSL trong thương mại điện tử. Việc truyền các thông tin nhạy cảm trên mạng rất không an toàn vì những vấn đề sau: Bạn không thể luôn luôn chắc rằng bạn đang trao đổi thông tin với đúng đối tượng cần trao đổi. Dữ liệu mạng có thể bị chặn ,vì vậy dữ liệu có thể bị 1 đối tượng thứ 3 khác đọc trộm, thường được biết đến như attacker . Nếu attacker có thể chặn dữ liệu, attacker có thể sửa đổi dữ liệu trước khi gửi nó đến người nhận. SSL giải quyết các vấn đề trên.SSL giải quyết vấn đề đầu tiên bằng cách cho phép 1 cách tùy chọn mỗi bên trao đổi có thể chắc chắn về định danh của phía đối tác trong 1 quá trình gọi là authentication (xác thực).Một khi các bên đã được xác thực,SSL cung cấp 1 kết nối được mã hóa giữa 2 bên để truyền bảo mật các message .Việc mã hóa trong quá trình trao đổi thông tin giữa 2 bên cung cấp sự riêng tư bí mật,vì vậy mà giải quyết được vấn đề thứ 2.Thuật toán mã hóa được sử dụng với SSL bao gồm hàm băm mã hóa,tương tự như 1 checksum.Nó đảm bảo rằng dữ liệu không bị thay đổi trong quá trình truyền dẫn.Hàm băm mã hóa giải quyết vấn đề thứ 3,tính toàn vẹn dữ liệu. Chú ý rằng,cả xác thực và mã hóa đều là tùy chọn, và phụ thuộc vào cipher suites (các bộ mã hóa) được đàm phán giữa 2 đối tượng. Một ví dụ rõ ràng nhất mà trong đó bạn nên sử dụng SSL là trao đổi thông tin giao dịch qua mạng (e- commerce).Trong trao đổi e-commerce,thật dại dột khi giả định rằng bạn có thể chắc chắn về định danh của server mà bạn đang trao đổi thông tin.Ai đó có thể dễ dàng tạo ra 1 Website giả hứa hẹn các dịch vụ tuyệt vời ,chỉ để cho bạn nhập vào đó số tài khoản.SSL cho phép bạn, client,xác thực về định danh của server.Nó cũng cho phép server xác thực định danh của client,mặc dù trong các giao tác Internet,việc này hiếm khi được làm. Secure Socket Layer 5
PTIT 2009 Đề tài môn Bảo mật thông tin Một khi client và server đã hài lòng với định danh của mỗi bên đối tác.SSL cung cấp tính bảo mật và tính toàn vẹn thông qua các thuật toán mã hóa mà nó sử dụng.Điều này cho phép các thông tin nhạy cảm,như số tài khoản,được truyền đi 1 cách an toàn trên Internet. Trong khi SSL cung cấp tính xác thực,tính bảo mật và toàn vẹn dự liệu,nó không cung cấp non-repudiation (tính không từ chối).Non-repudiation có nghĩa là khi 1 đối tượng gửi đi 1 message ,thì sau đó không thể phủ nhận việc mình đã gửi message đó.Khi 1 chữ kí số tương đương được liên kết với 1 message,việc trao đổi này sau đó có thể được chứng minh.SSL 1 mình nó không cung cấp non-repudiation. Tiến trình SSL: Việc trao đổi trên mạng sử dụng SSL bắt đầu với việc trao đổi thông tin qua lại giữa client và server.Sự trao đổi thông tin này gọi là SSL handshake. Ba mục tiêu chính của SSL handshake là: Đàm phán cipher suite. Xác thực định danh (tùy chọn). Hình thành cơ chế bảo mật thông tin, bằng cách thỏa thuận các cơ chế mã hóa. Đàm phán Cipher suite : Một phiên SSL bắt đầu với việc đàm phán giữa client và server xem cipher suite nào mà chúng sẽ sử dùng.Một cipher suite là 1 tập các thuật toán mã hóa và kích thước khóa mà máy tính có thể dùng để mã hóa dữ liệu.Một cipher suite bao gồm thông tin về các thuật toán trao đổi khóa công khai và các thuật toán thỏa thuận khóa,và các hàm băm mã hóa.Client nói với server các cipher suite nào nó có sẵn và server lựa chọn cipher suite tốt nhất có thể chấp nhận. Xác thực server : Trong SSL,bước xác thực là tùy chọn,nhưng trong ví dụ về giao tác e-commerce trên Web, client theo thông thường sẽ muốn xác thực server.Việc xác thực server cho phép client chắc chắn rằng chính server này đại diện cho đối tượng mà client tin tưởng. Để chứng minh server thuộc về tổ chức mà nó khẳng định là nó đại diện,server phải trình chứng chỉ khóa công khai của nó cho client.Nếu chứng chỉ này là hợp lệ ,client có thể chắc chắn về định danh của server. Thông tin trao đổi qua lại giữa client và server cho phép chúng thỏa thuận 1 khóa bí mật chung.Ví dụ,với RSA,client dùng khóa công khai của server,có được từ chứng chỉ khóa công khai, để mã hóa thông tin khóa bí mật.Client gửi thông tin khóa bí mật đã được mã hóa đến server.Chỉ có server mới có thể giải mã cái message này bởi vì quá trình giải mã phải cần đến khóa riêng của server. Gửi dữ liệu đã mã hóa: Bây giờ,cả client và server có thể truy cập đến khóa bí mật chung.Với mỗi message ,chúng dùng đến hàm băm mã hóa,đã được chọn trong bước thứ nhất của tiến trình này,và chia sẻ thông tin bí mật,để tính toán 1 HMAC nối thêm vào message.Sau đó,chúng dùng khóa bí mật và thuật toán khóa bí mật đã được đàm phán ở bước đầu tiên của tiến trình này để mã hóa dữ liệu và HMAC an toàn.Client và server giờ đây có thể trao đổi thông tin với nhau 1 cách an toàn với các dữ liệu đã băm và mã hóa. Giao thức SSL: Secure Socket Layer 6
PTIT 2009 Đề tài môn Bảo mật thông tin Phần trước cung cấp sự mô tả sơ lược về SSL handshake, là sự trao đổi thông tin giữa client và server trước khi gửi các message đã được mã hóa.Phần này mô tả chi tiết hơn.Hình sau minh họa chuỗi tuần tự các message được trao đổi trong SSL handshake.Các message mà chỉ được gửi trong 1 trường hợp nào đó được đánh dấu là tùy chọn. Hình II: Các message SSL Client Server 1.Client hello 2.Server hello 3.Certificate tùy chọn 4.Certificate request tùy chọn 5.Server key exchange tùy chọn 6.Server hello done 7.Certificate tùy chọn 8.Client key exchange 9.Certificate verify tùy chọn 10.Change cipher spec 11.Finish 12.Change cipher spec 13.Finished 14.Encrypted data 14.Encrypted data 15.Close messages 15.Close message Các message SSL được gửi theo thứ tự sau: 1) Client hello: client gửi đến server các thông tin bao gồm phiên bản SSL cao nhất và 1 danh sách các cipher suite mà nó hỗ trợ. (TLS 1.0 được chỉ ra như là SSL3.1).Thông tin cipher suite bao gồm các thuật toán mã hóa và kích thước khóa. 2) Server hello: server chọn ra phiên bản SSL cao nhất và cipher suite tốt nhất mà cả client và server hỗ trợ, và gửi thông tin này về cho client. 3) Certificate: server gửi cho client 1 chứng chỉ hoặc 1 chuỗi chứng chỉ.Về cơ bản,1 chuỗi chứng chỉ bắt đầu bằng chứng chỉ khóa công khai của server và kết thúc bằng chứng chỉ gốc của tổ chức có thẩm quyền chứng chỉ.Message này là tùy chọn,nhưng nó được dùng bất cứ khi nào xác thực server là cần thiết. 4) Certificate request: nếu server cần xác thực client,nó gửi cho client 1 yêu cầu xem chứng chỉ.Trong các ứng dụng internet,message này hiếm khi được gửi đi. Secure Socket Layer 7
PTIT 2009 Đề tài môn Bảo mật thông tin 5) Server key exchange: server gửi cho client 1 message trao đổi khóa server trong khi khóa công khai được gửi ở phần 3) bên trên thì không đủ cho trao đổi khóa. 6) Server hello done: server nói với client rằng nó hoàn thành các message đàm phán ban đầu. 7) Certificate: nếu server cần chứng chỉ từ client trong message 4, client gửi chuỗi chứng chỉ của nó,cũng giống như server làm trong message 3. 8) Client key exchange: client sinh ra thông tin được dùng để tạo ra khóa trong mã hóa đối xứng.Với RSA, client mã hóa thông tin khóa này bằng khóa công khai của server rồi gửi nó đến server. 9) Certificate verify: message này được gửi khi client trình ra chứng chỉ như trên.Mục tiêu của nó là cho phép server hoàn thành tiến trình xác thực client.Khi message này được dùng,client gửi thông tin với chữ kí số tạo bằng hàm băm mã hóa.Khi server giải mã thông tin này bằng khóa công khai của client,server có thể xác thực client. 10) Change cipher spec: client gửi message bảo server thay đổi kiểu mã hóa. 11) Finished: client nói với server rằng nó sẵn sàng để bắt đầu trao đổi dữ liệu an toàn. 12) Change cipher spec: server gửi message bảo client thay đổi kiểu mã hóa. 13) Finished: server nói với client rằng nó sẵn sàng để bắt đầu trao đổi dữ liệu an toàn.Kết thúc SSL handshake. 14) Encrypted data: client và server trao đổi với nhau,sử dụng thuật toán mã hóa đối xứng và hàm băm mã hóa đã đàm phán ở message 1 và 2,và dùng khóa bí mật mà client gửi cho server trong message 8. 15) Closed messages : Kết thúc 1kết nối,mỗi bên gửi 1 message close-notify để thông báo đầu kia biết kết nối bị đóng. Nếu các tham số được sinh ra trong 1 phiên SSL được lưu lại,các tham số này có thể thỉnh thoảng được dùng lại cho các phiên SSL sau.Việc lưu lại các tham số phiên SSL cho phép các trao đổi bảo mật về sau được bắt đầu nhanh chóng hơn. Lựa chọn Cipher suite và xóa Entity verification: Giao thức SSL/TLS định nghĩa 1 chuỗi các bước đặc biệt để bảo đảm 1 kết nối “được bảo vệ”.Tuy nhiên,việc lựa chọn Cipher suite sẽ tác động trực tiếp đến loại bảo mật mà kết nối có được.Ví dụ,nếu 1 cipher suite nặc danh được chọn,ứng dụng không có cách nào để kiểm tra định danh của đầu xa.Nếu 1 suite-không có mã hóa, được chọn,tính bí mật của dữ liệu không thể được bảo vệ.Thêm vào đó,giao thức SSL/TLS không chỉ rõ rằng những tài liệu chứng nhận nhận được phải khớp với những cái mà đầu kia gửi.Nếu kết nối theo cách nào đó mà bị redirect đến 1 kẻ xấu,nhưng tài liệu chứng nhận của kẻ xấu này khi trình ra thì được chấp nhận dựa trên những tư liệu tin tưởng hiện tại,kết nối này sẽ được xét là hợp lệ. Khi dùng SSLSockets/SSLEngines,nên luôn luôn kiểm tra tài liệu chứng nhận của đầu xa trước khi gửi bất kì dữ liệu nào.Các lớp SSLSockets và SSLEngines không tự động kiểm tra hostname trong URL có khớp với hostname trong tài liệu chứng nhận của đầu kia hay không.Một ứng dụng có thể bị khai thác bằng URL spoofing nếu hostname không được kiểm tra. Các giao thức như HTTPS cần thiết phải kiểm tra hostname.Các ứng dụng có thể dùng HostnameVerifier để viết chồng lên luật hostname HTTPS mặc định . Secure Socket Layer 8
PTIT 2009 Đề tài môn Bảo mật thông tin I.2 Kiến trúc SSL : SSL được thiết kế để dùng TCP cung cấp 1 dịch vụ bảo mật đầu cuối-đến-đầu cuối đáng tin cậy.SSL không phải là một giao thức đơn mà là 2 lớp giao thức,như minh họa dưới đây. Hình I.1 : Chồng giao thức SSL SSL Handshake SSL Change Cypher SSL Alert Protocol HTTP Protocol Spec Protocol SSL Record Protocol TCP IP SSL Record Protocol cung cấp các dịch vụ bảo mật cơ bản cho nhiều giao thức khác nhau ở các lớp trên.Trong thực tế, Hyper Text Transfer Protocol (HTTP),cung cấp dịch vụ trao đổi cho tương tác Web client/server,có thể hoạt động trên đỉnh của SSL.Ba giao thức lớp trên được định nghĩa như là các phần của SSL: Handshake Protocol, Change Cypher Spec Protocol và Alert Protocol.Các giao thức mang tính đặc trưng-SSL này được dùng trong phần quản lý trao đổi SSL và được xét đến trong phần sau. Hai khái niệm SSL quan trọng là SSL session (phiên SSL) và SSL connection ( kết nối SSL) ,được định nghĩa như sau: Connection ( kết nối): 1 kết nối là 1 transport _ trong định nghĩa mô hình phân lớp OSI_ cung cấp 1 loại dịch vụ thích hợp.Với SSL,những kết nối như vậy là những mối quan hệ ngang hàng.Các kết nối thì trao đổi nhanh chóng.Mỗi kết nối gắn với 1 phiên. Session (phiên): 1 phiên SSL là 1 liên kết giữa 1 client và 1 server.Các phiên được tạo ra bằng Handshake Protocol (giao thức bắt tay).Các phiên định nghĩa 1 tập các tham số bảo mật bằng mật mã,có thể được chia sẻ giữa nhiều kết nối.Các phiên được dùng để tránh những đàm phán tốn kém_về các tham số bảo mật mới_cho mỗi kết nối. Giữa bất kì 1 cặp của nhóm nào (các ứng dụng như HTTP trên client hay server),có thể có nhiều kết nối bảo mật .Về lý thuyết ,có thể có nhiều phiên đồng thời giữa các nhóm,nhưng đặc trưng này không được dùng trong thực tiễn. Thực sự có nhiều trạng thái gắn với mỗi phiên.Một khi 1 phiên được thành lập,có trạng thái hoạt động hiện thời cho cả đọc và ghi, (như nhận và gửi..).Thêm vào đó, trong suốt quá trình Handshake Protocol, trạng thái treo đọc và ghi được tạo ra.Dựa trên kết luận thành công của Handshake Protocol,các trạng thái treo trở thành trạng thái hiện thời. -Một trạng thái phiên được định nghĩa bởi các thông số sau (các định nghĩa lấy từ đặc trưng SSL): Session Identifier : 1 chuỗi byte bất kì được chọn bởi server để nhận dạng trạng thái phiên là hoạt động (active) hay phục hồi lại (resumable). Peer certificate: một chứng chỉ X509.v3.Thành phần này của trạng thái có thể là null. Compression method: thuật toán được dùng để nén dữ liệu trước khi mã hóa. Secure Socket Layer 9
PTIT 2009 Đề tài môn Bảo mật thông tin Cypher spec : chỉ ra thuật toán mã hóa dữ liệu (như rỗng,AES…) và thuật toán băm (như MD5 hay SHA- 1) sử dụng để tính toán MAC.Nó cũng định nghĩa các thuộc tính mã hóa như hash-size. Master secret : 48 byte bí mật được chia sẻ giữa client và server. Is resumable : một cờ chỉ ra rằng phiên này có thể được dùng để khởi tạo các kết nối khác hay không. -Một trạng thái kết nối được định nghĩa bởi các tham số sau: Server and client random: các chuỗi byte được chọn bởi server và client cho mỗi kết nối. Server write MAC secret: khóa bí mật được sử dụng bởi phép tính MAC trên dữ liệu, được gửi bởi server. Client write MAC secret: khóa bí mật được sử dụng bởi phép tính MAC trên dữ liệu,được gửi bởi client. Server write key: khóa mã hóa quy ước cho dữ liệu được mã hóa bởi server và giải mã bởi client. Client write key :khóa mã hóa quy ước cho dữ liệu được mã hóa bởi client và giải mã bởi server. Initialization vectors: khi 1 khối mã trong mode CBC được dùng, một vector khởi tạo (IV) được duy trì cho mỗi key.Phần này được khởi tạo trước tiên bởi SSL Handshake Protocol.Sau đó,khối mã hóa cuối cùng từ mỗi record được để dành lại để dùng làm IV cho record sau . Sequence number : mỗi bên duy trì các sequence number riêng cho mỗi message được truyền hoặc được nhận trong mỗi kết nối.Khi 1 bên gửi hoặc nhận một change cypher spec message,sequence number thích hợp được thiết lập về 0.Sequence number không thể vượt quá 264-1. I.3 Giao thức SSL Record : SSL Record Protocol cung cấp 2 dịch vụ cho kết nối SSL: Confidentiality (tính cẩn mật): Handshake Protocol định nghĩa 1 khóa bí mật được chia sẻ, khóa này được sử dụng cho mã hóa quy ước các dữ liệu SSL. Message integrity (tính toàn vẹn thông điệp):Handshake Protocol cũng định nghĩa 1 khóa bí mật được chia sẻ, khóa này được sử dụng để hình thành MAC (mã xác thực message). Hình sau chỉ ra toàn bộ hoạt động của SSL Record Protocol.SSL Record Protocol nhận 1 message ứng dụng sắp được truyền đi,phân mảnh dữ liệu thành nhiều block,nén dữ liệu 1 cách tùy chọn,áp dụng vào 1 MAC,mã hóa,thêm vào header,và truyền khối kết quả thu được trong 1 segment TCP.Dữ liệu nhận được được giải mã,kiểm tra ,giải nén,sắp xếp lại và phân phối đến người sử dụng ở lớp cao hơn. Secure Socket Layer 10
PTIT 2009 Đề tài môn Bảo mật thông tin Hình I.2 : Hoạt động của SSL Record Protocol Dữ liệu ứng dụng: Phân mảnh: Nén: Thêm MAC: Mã hóa: Gắn SSL Record header: 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 đến1 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. Secure Socket Layer 11
PTIT 2009 Đề tài môn Bảo mật thông tin  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.  SSLCompressed.fragment: phân mảnh đã được nén (nếu nén không được dùng, 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 AES 128,256 RC4-40 40 IDEA 128 RC4-128 128 RC2-40 40 DES-40 40 DES 56 3DES 168 Fortezza 80 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: Content Type (8 bit): giao thức lớp trên được dùng để xử lí phân mảnh đi kèm. 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. 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. 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. 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. Secure Socket Layer 12
PTIT 2009 Đề tài môn Bảo mật thông tin Hình sau minh họa định dạng SSL record. I.4 Giao thức SSL Change Cipher Spec : Giao thức SSL Change Cipher Spec là giao thức đơn giản nhất trong ba giao thức đặc trưng của SSL mà sử dụng giao thức SSL Record . Giao thức này bao gồm một message đơn 1 byte giá trị là 1. Mục đích chính của message này là sinh ra trạng thái tiếp theo để gán vào trạng thái hiện tại,và trạng thái hiện tại cập nhật lại bộ mã hóa để sử dụng trên kết nối này. I.5 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. Secure Socket Layer 13
PTIT 2009 Đề tài môn Bảo mật thông tin 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. Secure Socket Layer 14
PTIT 2009 Đề tài môn Bảo mật thông tin I.6 Giao thức SSL Handshake : Phần „khó nuốt‟ 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 Hình I.5a Hình I.5a 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 Server_hello version, random, session id, cipher suite, compression method 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 I.5b 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ó bốn giai đoạn. Secure Socket Layer 15
PTIT 2009 Đề tài môn Bảo mật thông tin Hình I.5b Cơ chế giao thức SSL Handshake I.6.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 và sử dụng suốt quá trình trao đổi khóa để ngăn tấn công lập lại. Secure Socket Layer 16
PTIT 2009 Đề tài môn Bảo mật thông tin 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óa „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ý. Certificate được sử dụng để xác thực khóa công khai. Điều này như là sự bảo đảm nhất của ba lựa chọn Diffie-Hellman bởi vì nó là kết quả của sự tạm thời và khóa xác thực. Anonymous Diffie-Hellman: thuật toán Diffie-Hellman cơ bản được sử dụng, không chứng thực.Nghĩa là mỗi lần một bên gửi thông số Diffie-Hellman công khai của nó cho bên kia thì không xác thực.Điều này gần như là có thể bị tấn công bởi tấn công Man-in-the-middle ,trong đó kẻ tấn công điều khiển cả nhóm anonymous Diffie-Hellman. Fortezza: phương pháp định nghĩa cho lược đồ Fortezza. Định nghĩa kèm theo cho một phương pháp trao đổi khóa là CipherSpec , bao gồm những trường sau : CipherAlgorithm: một vài thuật toán kể đến : RC4, RC2, DES, 3DES, DES40, IDEA, Fortezza. MACAlgorithm: MD5 hoặc SHA-1. CipherType: luồng hoặc khối. Secure Socket Layer 17
PTIT 2009 Đề tài môn Bảo mật thông tin IsExportable: True hoặc False. HashSize: 0, 16 (cho MD5), hay 20 (cho SHA-1) bytes. Key Material: thứ tự của các bytes mà chứa dữ liệu được dùng trong sinh khóa . IV Size: kích thước của giá trị khởi tạo cho mã hóa Cipher Block Chaining (CBC). I.6.2 Giai đoạn 2 – Xác thực server và trao đổi khóa : Server bắt đầu giai đoạn này bằng cách gửi certificate của nó nếu nó cần được xác thực; thông điệp chứa một hoặc một chuỗi certificate(chứng thực) X.509. Thông điệp chứng thực được yêu cầu cho bất kì một phương pháp trao đổi khóa nào được thỏa thuận, ngoại trừ anonymous Diffie-Hellman.Chú ý rằng nếu fixed Diffie-Hellman được dùng,thì thông điệp chứng thực có chức năng như là thông điệp trao đổi khóa của server vì nó chứa các tham số Diffie-Hellman công khai của server. Sau đó một thông điệp server_key_exchange được gửi đi nếu nó được yêu cầu.Nó không được yêu cầu trong 2 trường hợp sau:  (1) Server đã gửi một certificate với các tham số fixed Diffie-Hellman.  (2) Trao đổi khoá RSA được dùng. Thông điệp server_key_exchange cần cho các trường hợp sau: - Anonymous Diffie-Hellman : Nội dung thông điệp bao gồm hai giá trị Diffie-Hellman toàn cục(một số nguyên tố và một số nguyên tố cùng nhau với số đó) cùng với khóa Diffie- Hellman của server. - Ephemeral Diffie-Hellman : nội dung thông điệp bao gồm 3 tham số Diffie-Hellman cung cấp cho anonymous Diffie-Hellman,cùng với một chữ kí của các tham số này. - Trao đổi khóa RSA,mà theo đó server sử dụng RSA nhưng có một khóa chữ kí chỉ của RSA. Theo đó,client không thể gửi đi cách đơn giản một khóa bí mật được mã hóa với khóa công khai/bí mật RSA phụ và sử dụng thông điệp server_key_exchanged để gửi khóa công khai.Nội dung thông điệp bao gồm hai tham số của khóa công khai RSA phụ(số mũ và số dư) cùng với một chữ ký của các tham số này. - Fortezza: một vài chi tiết thêm về chữ kí được đảm bảo. Như thường lệ,một chữ kí được tạo ra bởi việc lấy mã băm của một thông điệp và mã hóa nó với khóa bí mật của bên gửi. Trong trường hợp này mã băm được định nghĩa: Hash (ClientHello.random||ServerHello.random||ServerParams) Vì vậy mã băm bao gồm không chỉ các thông số Diffie-Hellman hay RSA,mà còn có hai số ngẫu nhiên từ thông điệp hello khởi tạo.Điều này đảm bảo chống lại tấn công replay và misrepresentation(giả dạng).Trong trường hợp chữ kí DSS,mã băm được biểu diễn sử dụng giải thuật SHA-1. Trong trường hợp chữ kí RSA,cả mã băm MD5 và SHA-1 đều được tính toán, và sự nối nhau của hai mã băm(36 byte) được mã hoá với khóa bí mật của server. Kế đến, một nonanonymous server(server không dùng anonymous Diffie-Hellman) có thể yêu cầu một certificate từ client.Một thông điệp certificate_request bao gồm hai thông số certificate_type và certificate_authorities. Kiểu certificate chỉ ra giải thuật khóa công khai,và nó dùng: - RSA,chỉ dùng chữ kí - DSS,chỉ dùng chữ kí - RSA cho Diffie-Hellman thích hợp, trong trường hợp này chữ kí được dùng chỉ để xác thực,bằng cách gửi dùng certificate được kí với RSA. Secure Socket Layer 18
PTIT 2009 Đề tài môn Bảo mật thông tin - DSS cho fixed Diffie-Hellman, một lần nữa,chỉ dùng để xác thực. - RSA cho ephemeral Diffie-Hellman. - DSS cho ephemeral Diffie-Hellman. - Fortezza. Thông số thứ 2 của thông điệp certificate_request là một danh sách các tên của những CA đặc biệt được chấp nhận. Thông điệp cuối cùng trong giai đoạn 2, và là một phần luôn được yêu cầu,là thông điệp Server_done,mà được gửi cho server để chỉ ra điểm cuối của thông điệp cuối của server_hello và các message đi kèm.Sau khi gửi thông điệp,server sẽ chờ hồi đáp của client.Thông điệp này không có tham số. I.6.3 Giai đoạn 3 – Xác thực client và trao đổi khóa :  Trong khi nhận thông điệp server_done, client sẽ xác nhận xem server cung cấp một chứng chỉ hợp lệ hay chưa nếu được yêu cầu và kiểm tra xem các thông số của server_hello được chấp nhận hay không.Nếu tất cả đều thoả mãn, client gửi một hay nhiều message trở lại cho server. Nếu server yêu cầu một certificate,client bắt đầu giai đoạn này bằng cách gửi 1 thông điệp certificate.Nếu khống có certificate phù hợp nào hợp lệ, client gửi một cảnh báo no_certificate thay thế.  Kế đến là thông điệp client_key_exchange phải được gửi đi trong giai đoạn này.Nội dung của thông điệp phụ thuộc vào kiểu trao đổi khóa. Như sau: - RSA: client sinh một trường 48 byte pre-master secret và mã hóa với khóa công khai từ chứng thực của server hoặc khóa RSA phụ từ thông điệp server_key_exchange. Nó dùng để tính toán một master secret(sẽ được nói sau). - Ephemeral hoặc Anonymous Diffie-Hellman: các tham số Diffie-hellman công khai của client được gửi đi. - Fixed Diffie-Hellman: các tham số Diffie-Hellman công khai của client được gửi đi trong một thông điệp certificate,vì vậy nội dung của thông điệp là null. - Fortezza: các tham số Fortezza của client được gửi đi.  Cuối cùng,trong giai đoạn này,client sẽ gửi 1 message certificate_verify để cung cấp xác thực tường minh của một chứng chỉ client.Thông điệp này chỉ được gửi theo sau bất kì một client certificate nào đã đánh dấu là có khả năng(nghĩa là tất cả certificate ngoại trừ những cái chứa tham số fixed Diffie-Hellman). Thông điệp này đánh dấu một mã băm dựa trên các thông điệp có trước,được định nghĩa như sau: CertificateVerify.signature.md5_hash MD5(master_secret || pad_2 || MD5(handshake_messages || master_secret || pad_1)); Certificate.signature.sha_hash SHA(master_secret || pad_2 || SHA(handshake_messages || master_secret || pad_1));  Với pad_1 và pad_2 là các giá trị được định nghĩa sớm hơn cho MAC, handshake_messages xem xét đến tất cả các thông điệp giao thức bắt tay được gửi đi hay được nhận bắt đầu từ client_hello nhưng không bao gồm thông điệp này,và master_secret là khóa bí mật được tính toán mà quá trình xây dựng sẽ được tìm hiểu sau. Nếu khóa bí mật của user là DSS, thì nó được dùng để mã hóa mã băm SHA-1. Nếu khóa bí mật của user là RSA, nó được dùng để mã hóa chuỗi mã băm MD5 và SHA-1.  Trong trường hợp khác, mục đích là để xác minh quyền sở hữu của client với khóa bí mật cho chứng thực client.Cho dù là bất cứ ai đang lạm dụng certificate của client thì cũng sẽ không thể gửi message này. I.6.4 Giai đoạn 4 – Kết thúc :  Giai đoạn này hoàn thành thiết lập của một kết nối an toàn,Client gửi một thông điệp change_cipher_spec và chép CipherSpec đệm vào CipherSpec hiện tại.Chú ý rằng thông điệp này không được xem là một phần của giao thức bắt tay nhưng được gửi đi sử dụng giao thức Change Cipher Spec. Client sau đó ngay lập tức gửi thông điệp kết thúc theo giải thuật mới, với các khóa và các bí mật.Thông điệp kết thúc xác minh xem quá trình trao đổi khóa và xác thực có thành công hay không.nội dung của thông điệp hoàn tất là một chuỗi của hai giá trị băm : Secure Socket Layer 19
PTIT 2009 Đề tài môn Bảo mật thông tin MD5(master_secret || pad2 || MD5(handshake_messages || Sender || master_secret || pad1)) SHA(master_secret || pad2 || SHA(handshake_messages || Sender || master_secret || pad1))  Tại đó bên gửi là một mã mà xác định rằng bên gửi là client , và handshake_messages là tất cả dữ liệu từ tất cả thông điệp bắt tay trở lên nhưng không bao gồm thông điệp này.  Khi đáp lại hai thông điệp này,server gửi thông điệp change_cipher_spec của chính nó, chuyển đổi trạng thái treo cho cipherSpec hiện tại và gửi thông điệp kết thúc của nó đi.Ở điểm này quá trình bắt tay hoàn thành và client và server có thể bắt đầu trao đổi dữ liệu lớp ứng dụng. I.7 Tính toán mã hóa : Gồm việc tạo ra 1 shared master secret bằng cách trao đổi khóa, và sự sinh ra các tham số mật mã từ master secret. I.7.1 Việc tạo Master Secret : Shared master secret là 1 giá trị one-time 48 byte (384 bits) được sinh ra cho phiên này bằng cách trao đổi khóa an toàn.Việc tạo ra gồm hai bước: - Đầu tiên, một pre-master-secret được trao đổi - Thứ hai, master_secret được tính toán bằng cả hai nhóm. Đối với trao đổi pre_master_secret, có hai khả năng xảy ra:  RSA: 48 byte pre_master_secret được sinh ra bởi client, mã hóa với khóa RSA công khai của server, và gửi cho server.Server giải mã ciphertext sử dụng khóa bí mật của nó để phục hồi lại pre_master_secret.  Diffie-Hellman: cả client và server sinh ra khóa công khai Diffie-Hellman. Sau đó, những khóa này được trao đổi, mỗi bên biểu diễn việc tính toán Diffie-Hellman để tạo ra shared_pre_master_secret. Cả 2 bên tính toán master_secret như sau: master_secret = MD5 (pre_master_secret || SHA ('A' || pre_master_secret ||ClientHello.random || ServerHello.random)) || MD5 (pre_master_secret || SHA ('BB' || pre_master_secret || ClientHello.random || ServerHello.random)) || MD5 (pre_master_secret || SHA ('CCC' || pre_master_secret || ClientHello.random || ServerHello.random)) Với ClientHello.random và ServerHello.random là 2 giá trị số ngẫu nhiên được trao đổi trong thông điệp hello khởi tạo ban đầu. Secure Socket Layer 20
PTIT 2009 Đề tài môn Bảo mật thông tin I.7.2 Việc sinh các tham số mã hóa : CipherSpec yêu cầu một khóa xác thực của client, một khóa xác thực của server, và một khóa mật mã của client, một khóa mật mã của server, một vector khởi tạo IV của client, một vector khởi tạo IV của server, mà được sinh ra từ master_secret theo thứ tự đó.Những tham số này được sinh ra từ master_secret bằng cách băm master_secret thành chuỗi liên tục các byte bảo mật với chiều dài vừa đủ của những tất cả các tham số cần thiết . Việc sinh nguyên liệu khóa từ master_secret sử dụng cùng định dạng cho việc sinh ra master_secret từ pre_master_secret: key_block = MD5(master_secret || SHA('A' || master_secret || ServerHello.random || ClientHello.random)) || MD5(master_secret || SHA('BB' || master_secret || ServerHello.random || ClientHello.random)) || MD5(master_secret || SHA('CCC' || master_secret || ServerHello.random || ClientHello.random)) || . . Cho đến khi đủ số output được phát sinh.Kết quả của cấu trúc giải thuật này là hàm sinh số ngẫu nhiên. Ta có thể xem master_secret như giá trị ngẫu nhiên đưa hạt giống sinh số ngẫu nhiên vào trong hàm sinh số ngẫu nhiên.Các số ngẫu nhiên client và server có thể được nhìn như là các giá trị không đáng tin cậy(salt value) làm phức tạp sự giải mã các mật mã. Secure Socket Layer 21
PTIT 2009 Đề tài môn Bảo mật thông tin I.8 Transport Layer Security : I.8.1 Version Number : Định dạng của một record TLS giống định dạng của record SSL, và các trường trong phần header cũng có ý nghĩa giống nhau.Một sự khác biệt là trong các giá trị phiên bản TLS hiện tại,bản chính là 3 và bản phụ là 1. I.8.2 Message Authentication Code : Có 2 điểm khác biệt giữa SSLv3 và TLS MAC schemes: giải thuật thực tế và phạm vi của phép tính MAC. TLS tạo ra việc sử dụng giải thuật HMAC được định nghĩa trong RFC 2104.Nhớ lại,HMAC được định nghĩa như sau: HMACK(M) = H[(K+ opad)||H[(K+ ipad)||M]] Với : H: hàm băm nhúng(dành cho TLS, hoặc MD5 hoặc SHA-1) M: thông điệp đầu ra đối với HMAC K+ : khóa bí mật đệm các số 0 vào phía bên trái để kết quả bằng với chiều dài khối mã băm (đối với MD5, và SHA-1, chiều dài khối bằng 512 bits) Secure Socket Layer 22
PTIT 2009 Đề tài môn Bảo mật thông tin Ipad =00110110(36H) lặp lại 64 lần (512 bits) Opad =01011100(5CH) lặp lại 64 lần (512 bits) SSLv3 dùng cùng giải thuật, ngoại trừ các byte đệm được nối vào vào khóa bí mật hơn là được XOR với khóa bí mật được đệm vào chiều dài khối.Mức độ an toàn cùng giống trong cả 2 trường hợp. Đối với TLS, phép tính toán MAC hoàn thành các trường hợp được chỉ ra trong đẳng thức sau: HMAC_hash(MAC_write_secret, seq_num || TLSCompressed.type || TLSCompressed.version || TLSCompressed.length || TLSCompressed.fragment) Phép toán MAC bao gồm tất cả các trường được hàm chứa bởi phép tính toán SSLv3, cộng với trường TLSCompresses.version, mà là version của giao thức đang được dùng. I.8.3 Hàm tính số nhẫu nhiên : TLS tạo cách sử dụng hàm tạo số ngẫu nhiên dùng cho PRF để mở rộng các secret(phần bí mật) thành các khối dữ liệu cho mục đích sinh khóa hay phê chuẩn.Đối tượng là để tạo ra cách sử dụng các giá trị shared secret nhỏ có liên hệ với nhau, nhưng để phát sinh các khối dài hơn theo cách an toàn khỏi sự tấn công dựa trên hàm băm và MACx.PRF dựa trên hàm mở rộng dữ liệu sau: P_hash(secret, seed) = HMAC_hash(secret, A(1) || seed) || HMAC_hash(secret, A(2) || seed) || HMAC_hash(secret, A(3) || seed) || ... Với A() được định nghĩa: A(0)=seed A(i) =HMAC_hash(secret,A(i-1)) Secure Socket Layer 23
PTIT 2009 Đề tài môn Bảo mật thông tin Hàm mở rộng dữ liệu tạo cách sử dụng giải thuật HMAC, với hoặc MD5 hoặc SHA-1 như là trên cơ sở hàm băm.Như ta có thể thấy,P_hash có thể lặp đi lặp lại nhiều lần như sự cần thiết để tạo ra số lượng dữ liệu được yêu cầu.Ví dụ, nếu P_SHA-1 được dùng để sinh ra 64 byte dữ liệu,nó sẽ được lặp đi lặp lại 4 lần tạo ra 80 byte dữ liệu,mà 16 byte cuối bị loại bỏ.Trong trường hợp này,P_MD5 cũng sẽ được lặp lại 4 lần,tạo ra chính xác 64 bytes dữ liệu.Chú ý rằng mỗi lần lặp lại sẽ gọi 2 hàm thực thi HMAC, mỗi một cái sẽ quay sang gọi 2 hàm thực thi trên cơ sở giải thuật hàm băm. Để tạo ra PRF an toàn đến mức có thể,nó sử dụng 2 giải thuật băm theo cách mà sẽ đảm bảo sự an toàn của nó nếu giải thuật vẫn còn bảo mật.PRF được định nghĩa : hash(ClientHello.random || ServerHello.random || ServerParams) PRF lấy khi đầu vào một giá trị bí mật, một nhãn xác định, và một giá trị hạt giống(seed) và tạo ra một output có chiều dài tùy ý.Output được tạo bằng cách phân cắt giá trị bí mật thành hai nửa (S1 và S2 và biểu diễn P_hash ở mỗi nửa,sử dụng MD5 ở một nửa và SHA-1 ở nửa khác.Hai kết quả được thực hiện bởi phép XOR để tạo ra output, cho mục đích này,P_MD5 nhìn chung phải lặp lại nhiều lần hơn P_SHA-1 để tạo một lượng dữ liệu ngang bằng cho input bằng hàm XOR) I.8.4 Mã cảnh báo : TLS hỗ trợ tất cả các mã alert code được định nghĩa trong SSLv3 với ngoại lệ no_certificate. Một số các code thêm vào được định nghĩa trong TLS, sau đây là một số cảnh báo mức nguy hiểm:  decryption_failed : một cipher text được giải mã theo cách sai, hoặc nó không phải là phép nhân của chiều dài khối hoặc giá trị đệm của nó,khi kiểm tra là không đúng. Secure Socket Layer 24
PTIT 2009 Đề tài môn Bảo mật thông tin  record_overflow:một TLS record được nhận với một payload(ciphertext) có chiều dài 214+2048 bytes, hoặc ciphertext được giải mã với chiều dài lớn hơn 214+1024 byte.  unknown_ca : một chuỗi certificate hợp lệ hoặc 1 phần chuỗi được nhận,nhưng certificate không được chấp nhận bởi vì CA certificate không thể được cấp phát hoặc không thể tạo ra kết nối với 1 CA hiểu biết,tin cậy.  access_defined: một certificate hợp lệ được nhận, vì khi access_control được thừa nhận, sender quyết định không thực thi với thỏa thuận.  decord_error : một thông điệp không thể được giải mã vì 1 trường bị thiếu range đặc biệt hoặc chiều dài của message không đúng.  export_restriction : một thỏa thuận không được chấp nhận với việc xuất ra các hạn chế trên chiều dài khóa bị phát hiện.  protocol_version: phiên bản giao thức mà client nỗ lực thỏa thuận được nhận thấy nhưng không hỗ trợ.  insufficient_security: trả về thay thế handshake_failure khi thỏa thuận bị thất bại 1 cách đặc biệt bởi vì server yêu cầu cipher nhiều bảo mật hơn những cái khác được hỗ trợ bởi client.  internal_error: một lỗi bên trong không liên hệ với cấp tương đương hoặc sự sửa lỗi của giao thức tạo ra không thể để tiếp tục. Phần còn lại của các cảnh báo mới bao gồm:  decrypt_error: toán hạng mã hóa bắt tay bị hư, bao gồm không thể xác minh 1 chữ kí,mã hóa 1 trao đổi khóa hay công nhận 1 thông điệp hoàn tất.  user_canceled: quá trình bắt tay này bị hoãn lại vì 1 số lí do không liên quan đến sự thất bại giao thức.  no_renegotiation: gửi đi bởi client trong phần đáp lại client hello sau khi thiết lập bắt tay.hoặc những thông điệp này sẽ có kết quả bình thường trong việc thỏa thuận lại,nhưng cảnh báo này chỉ ra rằng sender không thể thỏa thuận.Thông điệp này luôn luôn là 1 cảnh báo(warning). I.8.5 Cipher suite : Có nhiều sự khác nhau nhỏ giữa các cipher suite sẵn có dưới SSLv3 và dưới TLS:  Trao đổi khóa:TLS hỗ trợ tất cả các công nghệ trao đổi khóa của SSLv3 với ngoại lệ của Fortezza.  Các giải thuật mã hóa đối xứng:TLS bao gồm tất cả các giải thuật mã hóa đối xứng được tìm thấy trong SSLv3,với ngoại lệ của Fortezza. I.8.6 Các dạng client certificate : TLS định nghĩa cá kiểu certificate sau đây được yêu cầu trong thông điệp certificate_request:rsa_sign,dss_sign,rsa_fixed_dh, và dss_fixed_dh. Tất cả những kiểu này được định nghĩa trong SSLv3. Thêm vào đó,SSLv3 bao gồm rsa_ephemeral_dh, dss_ephemeral_dh và fortezza_kea. Ephemeral Diffie-Hellman bao gồm đánh dấu các tham số Difie-Hellman với hoặc RSA hoặc DSS, với TLS, rsa_sign và kiểu đánh dấu riêng không cần thiết để đánh dấu các tham số Diffie-Hellman.TLS không bao gồm hê thống Fortezza. Secure Socket Layer 25
PTIT 2009 Đề tài môn Bảo mật thông tin I.8.7 Certificate Verify và Finished Message : Trong thông điệp TLS_certificate_verify, mã băm MD5 và SHA-1 được tính toán chỉ trên các thông điệp bắt tay(handshake_message).Nhớ lại rằng SSLv3 tính toán hàm băm còn bao gồm master_secret và đệm.Các trường thêm vô này thất bại trong việc cộng thêm bảo mật không được thêm vào. Khi các thông điệp hoàn tất trong SSLv3, thông điệp kết thúc trong TLS là 1 mã băm dựa trên shared_master_secret, thông điệp bắt tay ở trước, và một nhãn xác định client hay server, việc tính toán có đôi chút khác biệt. Đối với TLS ta có: PRF(master_secret, finished_label, MD5(handshake_messages)|| SHA-1(handshake_messages)) Với finished_label là chuỗi “client_finished” đối với client và “server finished” đối với server. I.8.8 Tính toán mã hóa : Pre_master_secret đối với TLS được tính toán cùng 1 cách như trong SSLv3.Như trong SSLv3, master_secret trong TLS được tính toán như 1 hàm băm của pre_master_secret và hai số ngẫu nhiên hello.Công thức của phép tính toán TLS khác với công thức tính của SSLv3,được định nghĩa như sau: master_secret = PRF(pre_master_secret, "master secret", ClientHello.random || ServerHello.random) Giải thuật biểu diễn cho đến khi 48 byte của output số ngẫu nhiên được tạo ra.Phép tính toán của khối vật liệu key(MAC secret keys,khóa mã hóa phiên, và ma trận khởi tạo IVs) được định nghĩa như sau: key_block = PRF(master_secret,"key expansion",SecurityParameters.server_random || SecurityParameters.client_random) Cho đến khi đủ output được sinh ra.Như với SSLv3,key_block là 1 hàm của master_secret và client và server random numbers, nhưng với TLS giải thuật thực tế là khác biệt. I.8.9 Phần đệm : Trong SSL, phần đệm thêm vào trước để mã hóa dữ liệu user là số lượng nhỏ nhất được yêu cầu để mà kích thước tổng của dữ liệu được mã hóa là một phép nhân của chiều dài khối của cipher.Trong TLS, padding có thể là bất kì số lượng nào mà có kết quả trong một tổng mà là một phép nhân của chiều dài khối của cipher lên đến 1 giá trị lớn nhất là 255 byte.Ví dụ, nếu 1 plaintext (hoặc văn bản nén được dùng) cộng với MAC+padding length byte là dài 79 byte.Sau đó chiều dài padding,tính theo byte, có thể là 1,9,17 và hơn nữa,đến 249. Chiều dài phần đệm tùy biến có thể chống lại các tấn công dựa trên một phép phân tích các chiều dài của các thông điệp trao đổi. Secure Socket Layer 26
PTIT 2009 Đề tài môn Bảo mật thông tin Chương II : II.1 Quan hệ giữa các Class : Để liên lạc một cách bảo mật, cả hai đầu của kết nối phải kích hoạt SSL. Trong JSSE API, những lớp đầu cuối của kết nối là SSLSocket và SSLEngine . Trong biểu đồ bên dưới, những class lớn được dùng để tạo SSLSocket/SSLEngines được sắp xếp theo trật tự logic. Một SSLSocket thì được tạo bởi một SSLSocketFactory hoặc một SSLServerSocket cho việc nhận vào một kết nối inbound.( mặt khác, một SSLServerSocket được tạo bởi một SSLServerSocketFactory) . Cả các đối tượng SSLSocketFactory và SSLServerSocketFactory được tạo bởi SSLContext. Một SSLEngine được tạo một cách trực tiếp bởi SSLContext, và dựa vào ứng dụng để quản lý tất cả I/O. Ghi chú: Khi sử dụng SSLSockets/SSLEngines ta nên kiểm tra xác thực đầu cuối trước khi gửi dữ liệu. Lớp SSLSocket/SSLEngine sẽ không tự động xác minh, ví dụ hostname trong một URL trùng với hostname trong xác thực đầu cuối. Ứng dụng có thể bị lợi dụng URL spoofing nếu hostname không được xác minh Có hai cách để sử dụng và khởi tạo một SSLContext: Secure Socket Layer 27
PTIT 2009 Đề tài môn Bảo mật thông tin Đơn giản nhất là gọi phương thức tĩnh getDefault trên lớp SSLSocketFactory hoặc SSLServerSocketFactory . Những phương thức này tạo một SSLContext mặc định với một KeyManager, TrustManager và một bộ khởi tạo số bí mật ngẫu nhiên. (Một KeyManagerFactory và TrustManagerFactory mặc định được sử dụng để tạo KeyManager và TrustManager tương ứng.) Key material được tìm thấy trong keystore/truststore mặc định, được định rõ bởi tính chất hệ thống mô tả trong Customizing the Default Key and Trust Stores, Store Types, and Store Passwords. Phương thức trao đổi bên gọi phần lớn điều khiển cách hoạt động của context được tạo thì gọi là phương thức tĩnh getInstance trên lớp SSLContext , sau đó khởi tạo context bằng cách gọi phương thức riêng init của trường hợp . Một thực thể của phương thức init mang ba phần sau: một dãy đối tượng KeyManager, một dãy đối tượng TrustManager và một bộ sinh số bí mật ngẫu nhiên SecureRandom. Đối tượng KeyManager và TrustManager được tạo bởi việc bổ sung các interface(s) thích hợp hoặc dùng lớp KeyManagerFactory và TrustManagerFactory để phát sinh các bổ sung. KeyManagerFactory và TrustManagerFactory có thể được khởi tạo với mỗi key material chứa trong KeyStore qua phương thức TrustManagerFactory/KeyManagerFactory init. Cuối cùng phương thức getTrustManagers (trong TrustManagerFactory) và phương thức getKeyManagers (trong KeyManagerFactory) có thể được gọi để sử dụng những chuỗi của trust hoặc key managers,một cho mỗi loại của trust hoặc key material. Mỗi một kết nối SSL được khởi tạo thì một SSLSession được tạo chứa các thông tin đa dạng, như là ID khởi tạo, bộ mã hóa được dùng , .v.v. . SSLSession khi đó được dùng thể hiện mối liên hệ xảy ra bên trên và thông tin trạng thái giữa hai thực thể . Mỗi kết nối SSL bao gồm 1 phiên tại một thời điểm nhưng phiên đó thì lại có thể được dùng bởi nhiều kết nối giữa những thực thể đó,đồng thời hoặc theo thứ tự. II.2 Các Class và Interface chính : II.2.1 Lớp SocketFactory và ServerSocketFactory : Lớp trừu tượng javax.net.SocketFactory được dùng để tạo socket. Nó phải là subclassed của các factories khác, mà tạo những subclasses riêng biệt của sockets và vì vậy cung cấp một framework tổng quát cho phần thêm vào của chức năng public socket-level. (xem ví dụ SSLSocketFatory ) Lớp javax.net.ServerSocketFactory thì tương tự lớp SocketFactory, nhưng nó chỉ dành riêng cho việc tạo server sockets. Socket factories là cách đơn giản để các chính sách liên quan đến sockets được xây dựng,việc thiết lập sockets theo một cách nào đó thì không yêu cầu cấu hình riêng biệt cho code mà đòi hỏi: Vì sự đa hình của factories và sockets, những dạng khác nhau của sockets có thể cùng dùng code ứng dụng mà bỏ qua các dạng khác nhau của factories. Factories có thể tự tùy chỉnh thông số với các thông số sử dụng trong xây dựng socket. Ví dụ factories tự điều chỉnh để trả về sockets với những timeouts mạng khác nhau hoặc thông số security đã cấu hình . Sockets trả về ứng dụng subclasses của java.net.Socket (hay javax.net.ssl.SSLSocket), cho nên ta có thể trình bày một APIs mới cho những đặc trưng như nén , bảo mật ,đánh dấu record,lựa chọn thống kê, hay vượt tường lữa. II2.2 Lớp SSLSocketFactory và SSLServerSocketFactory : Một javax.net.ssl.SSLSocketFactory hoạt động như một factory cho việc tạo secure sockets. Lớp này là một phân lớp trừu tượng của javax.net.SocketFatory Secure Socket Layer 28
PTIT 2009 Đề tài môn Bảo mật thông tin Secure socket factories đóng gói chi tiết của việc tạo và cấu hình ban đầu secure sockets. Bao gồm xác thực keys, công nhận certificate đầu bên kia, kích hoạt bộ mã hóa và tương tự. Lớp javax.net.ssl.SSLServerSocketFactory thì tương tự lớp SSLSocketFactory, nhưng được sử dụng riêng cho việc tạo server sockets. Tạo một SSLSocketFactory : Có ba cách cơ bản để tạo SSLSocketFactory: Lấy factory mặc định bằng việc gọi phương thức tĩnh SSLSocketFactory.getDefault. Nhận một factory như là 1 thông số API .Đó là code cần tạo sockets nhưng không quan tâm chi tiết như thế nào sockets được cấu hình có thể bao gồm 1 phương thức với 1 thông số SSLSocketFactory được gọi bởi clients để chỉ rõ SSLSocketFactory dùng để tạo sockets,vd : javax.net.ssl.HttpsURLConnection. Xây dựng một factory mới với cách chạy được cấu hình riêng biệt. Factory mặc định được cấu hình đặc trưng để hổ trợ chứng thực server chỉ khi sockets được tạo bởi một factory mặc định không rò rĩ bất cứ thông tin nào về về client hơn một TCP socket bình thường làm. Nhiều lớp tạo và dùng sockets thì không cần biết chi tiết của cách tạo sockets.Việc tạo sockets qua một sockets factory được lướt qua như một thông số như là một cách tốt để cách ly chi tiết của cấu hình socket và tăng sự tái dụng của lớp mà tạo và dùng sockets. Bạn có thể tạo một socket factory mới bằng việc triển khai socket factory subclass của bạn hay sử dụng lớp khác mà hoạt động như một factory cho socket factories. Một ví dụ là lớp SSLContext mà được cung cấp trong JSSE như là một lớp cung cấp cấu hình cơ sở. II.2.3 Lớp SSLSocket và SSLServerSocket : Lớp javax.net.ssl.SSLSocket là một subclass của lớp chuẩn java.net.Socket . Nó hỗ trợ tất cả phương thức socket chuẩn và thêm những phương thức bổ sung đặc trưng vào secure sockets. Cá biệt của lớp này là đóng gói SSLContext bên dưới những gì mà nó tạo. Có những APIs điều khiển việc tạo secure socket sessions cho một socket riêng biệt nhưng việc quản lý trust và key không được che đậy một cách trực tiếp. Lớp javax.net.ssl.SSLServerSocket thì tương tự lớp SSLSocket ,nhưng được dùng đặc trưng cho cho việc tạo server sockets. Để ngăn spoofing đầu bên,bạn nên luôn xác minh đầu cuối cho một SSLSocket. Ghi chú bổ sung : do sự phức tạp của giao thức SSL và TLS ,nó khó để dự đoán có hay không bytes vào trên một kết nối là handshake hay dữ liệu ứng dụng,và như thế nào dữ liệu có thể tác động trạng thái kết nối hiện tại (ngoại trừ trường hợp quá trình bị block). Trong thực thi của Sun JSSE, phương thức available()trên đối tượng đạt được từ SSLSocket.getInputStream()trả về tổng số của bytes dữ liệu ứng dụng giải mã thành công từ kết nối kết nối SSL nhưng lúc này chưa đọc bởi ứng dụng. Tạo một SSLSocket : SSLSocket có thể tạo được bằng hai cách. Thứ nhất, một SSLSocket có thể tạo bởi SSLSocketFactory qua một vài phương thức createSocket trên lớp đó. Cách thứ hai tạo SSLSockets qua phương thức accept trên lớp SSLServerSocket . Secure Socket Layer 29
PTIT 2009 Đề tài môn Bảo mật thông tin II.2.4 Non-blocking I/O với SSLEngine : SSL/TLS đang ngày càng phổ biến. Nó được dùng trong các ứng dụng đa dạng trên một diện rộng các nền máy tính . Theo đà sự phổ biến hiện nay dẫn đến yêu cầu sử dụng nó với những I/O và mô hình chuỗi khác nhau để mà thỏa mãn hiệu suất , khả năng , theo dõi và những yêu cầu khác của ứng dụng.Đó là sự đòi hỏi sử dụng nó trong trong những kênh I/O blocking và non-blocking , I/O không đồng bộ, các luồng input và output đa dạng , và những bộ đệm byte.Đó là sự yêu cầu nó trong môi trường nhạy cảm có độ biến đổi và hiệu suất cao mà yêu cầu quản lý hàng ngàn network connections. Trước J2SE 5 , JSSE API hổ trợ chỉ một khái niệm trừu tượng transport đơn : luồng sockets nền thông qua SSLSocket. Trong khi dạng này tương thích với nhiều ứng dụng , nó không gặp phải những yêu cầu của ứng dụng mà cần dùng I/O khác nhau hay mô hình liên kết. Trong 1.5.0 , một khái niệm trừu tượng mới được giới thiệu để cho phép ứng dụng sử dụng giao thức SSL/TLS trong một đường vận chuyển độc lập , vì vậy những ứng dụng tự do chọn cách thức vận chuyển và mô hình tính toán tốt nhất mà nó cần. Nó còn thích nghi với nhiều mô hình liên kết. Điếu này cho phép một cách hiệu quả I/O và liên kết vào ứng dụng . Bởi vì tính linh hoạt này , ứng dụng bây giờ phải quản lý I/O và liên kết ( những topic phức tạp vào trong chính nó) cũng như nắm rõ giao thức SSL/TLS. Một khái niệm trừu tượng mới cho ra một API cao cấp : người dùng nên sử dụng SSLSocket. Một người mới tiếp xúc API có thể tự hỏi “ Tại sao không chỉ có một SSLSocketChannel mà thuộc java.nio.channels.SocketChannel?" Có hai lý do chính sau : Có nhiều câu hỏi khó về một SSLSocketChannel thì nên như thế nào gồm cả hệ thống phân lớp của nó và nó nên liên kết với Selectors và những dạng khác của SocketChannels như thế nào.Mỗi đề xuất thì mang lại nhiều câu hỏi hơn là trả lời . Nó được giải thích rằng khái niệm trừu thượng API mới mở rộng để làm việc với SSL/TLS yêu cầu cùng một các phép phân tích quan trọng và có thể dẫn đến những APIs lớn và phức tạp. Bất kỳ việc thực thi JSSE nào cho một API mới sẽ tự do chọn lựa I/O và chiến lược tính toán tốt nhất , nhưng ẩn đi những chi tiết không thích hợp cho yêu cầu điều khiển ứng dụng đó. Bất kỳ sự thực thi đặc trưng nên tách rời với các phân đoạn ứng dụng. Bằng việc trừu tượng I/O và dữ liệu xữ lý như những chuỗi bytes, kết quả được giải quyết và API mới có thể sử dụng với bất cứ mô hình I/O nào hiện nay và sắp tới.Trong khi giải pháp này làm I/O và CPU chuyển giao trách nhiệm cho người lập trình , việc thực thi JSSE thì bị ngăn không cho trở nên không sử dụng được bởi vì những chi tiết bên trong không thể cấu hình hay thay đổi. Người dùng những API ngôn ngữ lập trình lập trình Java khác như JGSS và SASL sẽ thông báo những điều tương tự rằng ứng dụng thì cũng chịu trách nhiệm cho dữ liệu vận chuyển. SSLEngine Lớp chính trong khái niệm mới này là javax.net.ssl.SSLEngine .Nó đóng gói một SSL/TLS cơ chế trạng thái và cách vận hành trên bộ đệm byte inbound và outbound hổ trợ bởi người dùng của SSLEngine. Lược đồ sau sẽ minh họa luồng dữ liệu của data từ ứng dụng , đến SSLEngine , đến cơ chế vận chuyển và quay về Secure Socket Layer 30
PTIT 2009 Đề tài môn Bảo mật thông tin Tầng ứng dụng ở bên trái cung cấp dữ liệu ứng dụng (plaintext) trong một application buffer và chuyển nó cho SSLEngine . SSLEngine xử lý dữ liệu chứa trong buffer hoặc bất cứ dữ liệu handshaking nào để tạo ra dữ liệu đã mã hóa SSL/TLS vào đặt vào network buffer cung cấp bởi ứng dụng. Ứng dụng thì sau đó chịu trách nhiệm cho việc vận chuyển tương ứng (bên phải) để gửi nội dung của network buffer đến đầu bên.Lúc nhận dữ liệu đã mã hóa SSL/TLS từ đầu bên ( thông qua tầng vận chuyển) , ứng dụng đưa dữ liệu vào trong network buffer và chuyển nó đến SSLEngine . SSLEngine xử lý nội dung network buffer để tạo ra dữ liệu handshaking hay dữ liệu ứng dụng. Về tổng thể , SSLEngine có thể là một trong năm trạng thái : 1. Creation – sẵn sàng để cấu hình. 2. Initial handshaking - thực thi chứng thực và thương lượng thông số truyền thông. 3. Application data – sẵn sàng cho trao đổi dữ liệu. 4. Rehandshaking - tái thương lượng thông số truyền thông / chứng thực;dữ liệu handshaking có thể đã được gắn vào dữ liệu ứng dụng. 5. Closure – sẵn sàng đóng kết nối. Năm trạng thái này được miêu tả chi tiết hơn trong tài liệu lớp SSLEngine II.2.5 Quá trình khởi động : Để tạo một SSLEngine , bạn sử dụng phương thức SSLContext.createSSLEngine() . Bạn phải cấu hình cơ chế hoạt động như một client hoặc một server, cũng như đặt các thông số cấu hình khác như là cipher suites được dùng và có yêu cầu chứng thực client không. Đây là một ví dụ mà tạo một SSLEngine . Chú ý rằng tên server và số port thì không được dùng cho liên lạc với server – tất các vận chuyển là trách nhiệm của ứng dụng.Chúng gợi ý cho người cung cấp JSSE sử dụng việc cache SSL session, và cho việc thực thi Kerberos-cipher suite cơ bản để định rõ ủy quyền server nào nên được chọn. import javax.net.ssl.*; import java.security.*; // Khởi tạo SSLContext với key material char[] passphrase = "passphrase".toCharArray(); // Khởi tạo lần đầu key và trust material. KeyStore ksKeys = KeyStore.getInstance("JKS"); Secure Socket Layer 31
PTIT 2009 Đề tài môn Bảo mật thông tin ks.load(new FileInputStream("testKeys"), passphrase); KeyStore ksTrust = KeyStore.getInstance("JKS"); ks.load(new FileInputStream("testTrust"), passphrase); // KeyManager's quyết định key material nào được dùng. KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509"); kmf.init(ksKeys, passphrase); // TrustManager's quyết định có cho phép kết nối không. TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509"); tmf.init(ksTrust); sslContext = SSLContext.getInstance("TLS"); sslContext.init( kmf.getKeyManagers(), tmf.getTrustManagers(), null); // Chúng ta đã sẵn sàng cho một engine SSLEngine engine = sslContext.createSSLengine(hostname, port); // Sử dụng như một client engine.setUseClientMode(true); II.2.6 Phát sinh và xử lý dữ liệu SSL/TLS : Hai phương thức chính SSLEngine wrap() và unwrap() thì chịu trách nhiệm cho việc phát sinh và sử dụng dữ liệu network tương ứng. phụ thuộc vào trạng thái SSLEngine, dữ liệu này có thể là dữ liệu handshake hay ứng dụng. Mỗi SSLEngine có một vài giai đoạn trong suốt thời gian sống của nó. Trước khi dữ liệu ứng dụng có thể được gửi/nhận , giao thức SSL/TLS yêu cầu một handshake để khởi tạo thông số mã hóa. Handshake này yêu cầu một loạt các bước tới và lui bởi SSLEngine. SSL Process có thể cung cấp thêm chi tiết về handshake của chính nó. Suốt quá trình handshacking ban đầu, wrap() và unwrap() khởi tạo và sử dụng dữ liệu handshake, và ứng dụng thì chịu trách nhiệm cho việc vận chuyển dữ liệu. Chuỗi wrap()/unwrap() được lập lại cho đến khi hanshake được hoàn tất. Mỗi quá trình hoạt động SSLEngine khởi tạo một SSLEngineResult, của trường SSLEngineResult.HandshakeStatus nào được dùng để xác định cơ chế nào cần xảy ra tiếp theo để tiến tới handshake . Một handshake điển hình có thể như sau: Client SSL/TLS message HSStatus wrap() ClientHello NEED_UNWRAP unwrap() ServerHello/Cert/ServerHelloDone NEED_WRAP wrap() ClientKeyExchange NEED_WRAP wrap() ChangeCipherSpec NEED_WRAP wrap() Finished NEED_UNWRAP unwrap() ChangeCipherSpec NEED_UNWRAP unwrap() Finished FINISHED Bây giờ thì việc handshaking đã hoàn thành, trạng thái tiếp theo sẽ gọi wrap()để thử dùng dữ liệu ứng dụng và packages cho vận chuyển. unwrap()thì làm ngược lại. Để gửi dữ liệu đến đầu bên , ứng dụng trước hết phải cung cấp dữ liệu mà nó muốn gửi đến SSLEngine thông qua SSLEngine.wrap() để thu được dữ liệu đã mã hóa SSL/TLS tương ứng.Ứng dụng sau đó gửi dữ liệu cho đầu bên theo cơ chế vận chuyển mà nó đã chọn . Khi ứng dụng nhận được dữ liệu đã mã hóa SSL/TLS qua cơ chê Secure Socket Layer 32
PTIT 2009 Đề tài môn Bảo mật thông tin vận chuyển, nó cung cấp dữ liệu này cho SSLEngine thông qua SSLEngine.unwrap() để thu được dữ liệu plaintext mà đầu kia muốn gửi. Đây là một thí dụ của một ứng dụng SSL mà sử dụng một non-blocking SocketChannel để liên lạc với bên kia(Nó có thể được tạo thẳng và có thể hay đổi bẳng việc dùng một Selector với non-blocking SocketChannel.) Đoạn code sau sẽ gửi chuỗi "hello" đến đầu bên kia, bằng việc viết mã nó sử dụng SSLEngine đã tạo trong ví dụ trước.Nó sử dụng thông tin từ SSLSession để định nghĩa độ lớn của byte buffers là bao nhiêu. // Tạo một non-blocking socket channel SocketChannel socketChannel = SocketChannel.open(); socketChannel.configureBlocking(false); socketChannel.connect(new InetSocketAddress(hostname, port)); // Hoàn tất việc kết nối while (!socketChannel.finishedConnect()) { // làm bất cứ gì cho đến khi kết nối hoàn tất } // Tạo byte buffers cho việc giữ ứng dụng và dữ liệu đã mã hóa SSLSession session = engine.getSession(); ByteBuffer myAppData = ByteBuffer.allocate(session.getApplicationBufferSize()); ByteBuffer myNetData = ByteBuffer.allocate(session.getPacketBufferSize()); ByteBuffer peerAppData = ByteBuffer.allocate(session.getApplicationBufferSize()); ByteBuffer peerNetData = ByteBuffer.allocate(session.getPacketBufferSize()); // Làm Handshake ban đầu doHandshake(socketChannel, engine, myNetData, peerNetData); myAppData.put("hello".getBytes()); myAppData.flip(); while (myAppData.hasRemaining()) { // Sinh ra dữ liệu mã hóa SSL/TLS (dữ liệu handshake hoặc ứng dụng) SSLEngineResult res = engine.wrap(myAppData, myNetData); // Xử lý trạng thái của bên gọi if (res.getStatus() == SSLEngineResult.Status.OK) { myAppData.compact(); // Gửi dữ liệu mã hóa SSL/TLS cho đầu bên kia while(myNetData.hasRemaining()) { int num = socketChannel.write(myNetData); if (num == -1) { // điều khiển đóng channel } else if (num == 0) { // Nếu không byte nào được viết thì thử lại lần nữa } } } // Điều khiển những trạng thái khác: BUFFER_OVERFLOW, CLOSED ... Secure Socket Layer 33
PTIT 2009 Đề tài môn Bảo mật thông tin } Đoạn code sau đọc dữ liệu từ cùng non-blocking SocketChannel và lấy dữ liệu plaintext ra từ nó bằng cách dùng SSLEngine đã tạo trước đó.Mỗi vòng lặp của đoạn code có thể hoặc không sinh ra bất cứ dữ liệu paintext nào,phụ thuộc vào có hay không handshaking thì đang được xử lý. // Đọc dữ liệu mã hóa SSL/TLS từ đầu bên int num = socketChannel.read(peerNetData); if (num == -1) { // Điều khiển đóng channel } else if (num == 0) { // Không đọc được bytes nào ,thử lại . . . } else { // Xử lý dữ liệu vào peerNetData.flip(); res = engine.unwrap(peerNetData, peerAppData); if (res.getStatus() == SSLEngineResult.Status.OK) { peerNetData.compact(); if (peerAppData.hasRemaining()) { // Dùng peerAppData } } // Điều khiển các trạng thái khác: BUFFER_OVERFLOW, BUFFER_UNDERFLOW, CLOSED ... } II.2.7 Trạng thái của quá trình hoạt động : Để chỉ ra trạng thái của engine và những hành động mà ứng dụng nên có , phương thức SSLEngine.wrap() và SSLEngine.unwrap()trả lại một SSLEngineResult cụ thể,như trong ví dụ trước. SSLEngineResult chứa hai phần của thông tin trạng thái : trạng thái tổng thể cúa bộ máy và trạng thái handshaking. Những trạng thái tổng thể có thể có được biểu diễn bởi SSLEngineResult.Status enum. Một vài ví dụ của trạng thái này bao gồm Ok, có nghĩa la không có lỗi, và BUFFER_UNDERFLOW, có nghĩa là input buffer có dữ liệu chưa đủ, chỉ ra rằng ứng dụng cần thu thêm dữ liệu từ đầu bên (ví dụ như đọc thêm dữ liệu từ network). Những trạng thái handshaking có thể có thì được biểu diễn bởi the SSLEngineResult.HandshakeStatus enum.Chúng biểu diễn việc handshaking có hoàn thành hay chưa, có hay không bên gọi cần thu thêm dữ liệu handshaking từ đầu bên, gửi thêm dữ liệu handshaking cho đầu bên và vân vân. Mỗi kết quả của hai trạng thái cho phép engine chỉ ra rằng ứng dụng phải mang hai hành động : một là trả lời handshaking và một là biểu diễn trạng thái tổng thể của phương thức wrap()/unwrap() .Cho một ví dụ ,có thể engine , như là một kết quả của lệnh gọi đơn SSLEngine.unwrap() , trả về SSLEngineResult.Status.OK để chỉ ra rằng dữ liệu nhận vào đã xử lý thành công và SSLEngineResult.HandshakeStatus.NEED_UNWRAP chỉ ra rằng ứng dụng cần thu thêm dữ liệu mã hóa SSL/TLS từ đầu bên và cung cấp nó cho SSLEngine.unwrap() lần nữa để mà handshaking có thể tiếp tục.Như bạn thấy , ở ví dụ trước thì được đơn giản rất nhiều, chúng cần được phát triển đầy đủ để điều khiển chính xác tất cả trạng thái này. Secure Socket Layer 34
PTIT 2009 Đề tài môn Bảo mật thông tin II.2.8 Blocking Tasks : Suốt quá trình Handshaking, SSLEngine có thể bắt gặp các tasks mà có thể block hay chiếm một thời gian dài.Cho ví dụ như một TrustManager có thể cần kết nối đến một dịch vụ phê chuẩn certificate từ xa, hay một KeyManager có thể cần thúc giục user để xác định certificate nào dùng để chứng thực client.Để giữ cho trạng thái tự nhiên của SSLEngine, khi engine gặp phải việc, nó sẽ trả về SSLEngineResult.HandshakeStatus.NEED_TASK. Trong lúc nhận trạng thái này,ứng dụng cần gọi SSLEngine.getDelegatedTask() để lấy task, sau đó sử dụng kiểu threading dành riêng cho yêu cầu của nó, xử lý task.Ứng dụng có thể thu thread từ một thread pool để xử lý task mà thread chính thường là đang đi điều khiển I/O khác. Đây là một ví dụ mà thực thi mỗi task trong một thread được tạo mới. if (res.getHandshakeStatus() == SSLEngineResult.HandshakeStatus.NEED_TASK) { Task có thể hoạt động; while ((task=engine.getDelegatedTask()) != null) { new Thread(task).start(); } } Engine sẽ block những lệnh call wrap/unwrap sẽ có cho đến khi tất tasks đang đứng bên ngoài được hoàn tất . II.2.9 Kết thúc : Cho một shutdown có trật tự của một kết nối SSL/TLS , giao thức SSL/TLS yêu cầu chuyển giao của close message.Vì vậy, khi một ứng dụng được thực hiện với kết nối SSL/TLS,nó nên thu close message trước tiên từ SSLEngine, sau đó truyền chúng cho đầu bên dùng cơ chế vận chuyển, và cuối cùng shut down cơ chế vận chuyển.Đây là một thí dụ // Chỉ ra ứng dụng được thực hiện với engine engine.closeOutbound(); while (!engine.isOutboundDone()) { // Nhận close message SSLEngineResult res = engine.wrap(empty, myNetData); // Kiển tra trạng thái // Gửi close message cho đầu bên while(myNetData().hasRemaining()) { int num = socketChannel.write(myNetData); if (num == -1) { // điều khiển đóng channel } else if (num == 0) { // không đọc được byte nào,thử lại lần nữa } myNetData().compact(); } } // Đóng transport socketChannel.close(); Thêm vào đó ứng dụng kết thúc SSLEngine một cách dứt khoát , SSLEngine có thể được đóng bởi đầu bên kia ( thông qua việc nhận một close message trong khi nó xử lý dữ liệu handshake) hoặc bằng cách SSLEngine bắt gặp một lỗi trong khi xử lý ứng dụng hoặc dữ liệu handshake, chỉ ra bởi một SSLException..Trong trường hợp như thế ,ứng dụng nên gọi SSLEngine.wrap()để lấy close message và gửi nó cho đầu bên đến khi SSLEngine.isOutboundDone() trả về true, như trong ví dụ trước , hoặc SSLEngineResult.getStatus() trả về CLOSED. Secure Socket Layer 35
PTIT 2009 Đề tài môn Bảo mật thông tin Thêm vào việc shutdown có thứ tự thì cũng có kết thúc không theo thứ tự mà liên kết vận chuyển được cắt đứt trước khi close message được trao đổi.Trong ví dụ trước, ứng dụng có thể nhận -1 khi thử đọc hoặc viết non- blocking SocketChannel. Khi lấy hết dữ liệu nhận vào, bạn nên gọi engine.closeInbound(), mà sẽ xác minh với SSLEngine rằng đầu bên kia đã đóng hoàn toàn phối cảnh SSL/TLS ,và khi đó ứng dụng sẽ vẫn thử shutdown hoàn toàn bằng việc dùng kết quả ở trên.Hiển nhiên, không giống như SSLSocket, ứng dụng dùng SSLEngine phải dính líu tới nhiều chuyển tiếp trạng thái, tình trạng và lập trình hơn việc dùng SSLEngine. Hãy xem NIO-based HTTPS server để biết thêm thông tin về việc viết một ứng dụng SSLEngine cơ bản . II.2.10 SSLSession Interface : Một javax.net.ssl.SSLSession biểu diễn một ngữ cảnh bảo mật được thương lượng giữa hai đầu của một kết nối SSLSocket/SSLEngine. Mỗi một session thì được sắp xếp, nó có thể được chia sẻ bởi SSLSocket/Engines sắp tới kết nối giữa cùng cả hai bên. Session chứa cipher suite mà sẽ được dùng cho liên lạc một secure socket cũng như một non-authoritative gợi ý đến địa chỉ network của đầu bên, và thông tin quản lý như thời gian khởi tạo và lần dùng sau cùng. Session cũng chứa một shared master secret thương lượng giữa các bên về tạo khóa bí mật cho việc mã hóa và đảm bảo sự toàn vẹn của liên lạc thông qua một SSLSocket/SSLEngine. Giá trị của master secret này được biết chỉ được biết cho việc thực thi secure socket bên dưới và nó không bị lộ qua SSLSession API. II.2.11 Lớp HttpsURLConnection : Giao thức https thì tương tự như http, nhưng https trước hết khởi tạo một secure channel thông qua SSL/TLS sockets và xác thực đầu cuối trước khi yêu cầu hoặc nhận dữ liệu . javax.net.ssl.HttpsURLConnection mở rộng lớp java.net.HttpsURLConnection, và thêm vào hỗ trợ cho đặc trưng riêng https . Xem lớp java.net.URL ,java.net.URLConnection,java.net.HttpURLConnection , và javax.net.ssl.HttpURLConnection , để biết thêm thông tin về như thế nào https URLs được xây dựng và sử dụng . Trong lúc nhận một HttpsURLConnection, bạncó thể cấu hình một số thông số của http/https trước khi khởi tạo kết nối network trên thực tế thông qua phương thức URLConnection.connect. Những chú ý chi tiết là: Tùy chỉnh SSLSocketFatory chỉ định Tùy chỉnh HostnameVerifier chỉ định Tùy chỉnh SSLSocketFactory chỉ định Trong một vài trường hợp , nó thì muốn chỉ định SSLSocketFactory rằng một HttpsURLConnection sử dụng riêng. Ví dụ bạn có thể muốn đào xuyên qua một dạng proxy mà không được hổ trợ bởi việc thực thi không đầy đủ . SSLSocketFactory mới có thể trả về những sockets mà đóng vai trò tất cả các tunneling cần thiết , vì vậy cho phép HttpsURLConnection dùng các proxy bổ sung. Lớp HttpsURLConnection có một SSLSocketFactory mặc định mà chỉ định khi nào lớp được load .( Trong trường hợp nó là factory được trả về từ phương thức SSLSocketFactory.getDefault.) Trường hợp đặc biệt có thể có của HttpsURLConnection sẽ thừa hưởng SSLSocketFactory mặc định của hiện tại cho đến khi một SSLSocketFactory mặc định mới được chỉ định cho lớp thông qua phương thức tĩnh HttpsURLConnection.setDefaultSSLSocketFactory. Mỗi trường hợp của HttpsURLConnection thì được tạo , SSLSocketFactory được kế thừa trong trường hợp này có thể được gửi qua bên gọi qua phương thức setSSLSocketFactory . Lưu ý rằng việc thay đổi SSLSocketFactory tĩnh mặc định thì không tác động lên trường hợp đang có của HttpsURLConnections, một lệnh gọi phương thức setSSLSocketFactory thì cần thiết để thay đổi trường hợp đang có. Secure Socket Layer 36
PTIT 2009 Đề tài môn Bảo mật thông tin Một cách khác có thể thu mỗi trường hợp hoặc mỗi lớp SSLSocketFactory bằng việc tạo một lệnh gọi phương thức getSSLSocketFactory/getDefaultSSLSocketFactory , tương ứng từng cái một. Tùy chỉnh HostnameVerifier chỉ định Nếu hostname của URL không trùng với hostname trong xác minh được nhận như một phần của SSL/TLS handshake, nó có thể xảy ra URL spoofing.Nếu việc thực thi không thể xác minh hostname với lý do chắc chắn, việc thực thi SSL sẽ thực thi một lệnh gọi lại HostnameVerifier chỉ định của trường hợp cho kiểm tra. Việc xác nhận hostname có thể thực thi ở bất cứ bước nào cần thiết để làm quyết định, như là thực thi việc so sánh mẫu hostname xen kẽ hay có lẽ pop up một dialog box tương tác. Một việc xác minh không thành công bởi việc kiểm tra hostname sẽ đóng kết nối sẽ đóng kết nối.(Xem RFC 2818 để biết thêm thông tin liên quan đến việc xác minh hostname.) Phương thức setHostnameVerifier/setDefaultHostnameVerifier hoạt động cùng một kiểu phương thức setSSLSocketFactory/setDefaultSSLSocketFactory , trong đó có chỉ định trên mỗi trường hợp và mỗi lớp cơ bản, và giá tri hiện thời có thể được thu bởi một lệnh gọi phương thức getHostnameVerifier/getDefaultHostnameVerifier . II.3 Các Class và Interface hỗ trợ : Các lớp hỗ trợ và giao diện trong section này được cung cấp để hỗ trợ việc tạo ra và thiết lập các đối tượng SSLContext,mà được dùng để tạo các đối tượng SSLSocketFactory,SSLServerSocketFactory,và SSLEngine.Các lớp hỗ trợ và các giao diện là 1 phần của gói javax.net.ssl 3 trong số các lớp này mô tả trong section này(SSLContext,KeyManagerFactory,và TrustManagerFactory) là các lớp engine(cơ cấu).1 lớp engine là 1 lớp API dùng cho các giải thuật xác định(hoặc các giao thức,trong trường hợp của SSLContext),cho cái mà các công cụ có thể được cung cấp trong một hay nhiều gói Cryptographic Service Provider(nhà cung cấp). Nhà cung cấp SunJSSE đem đến nhiều tiêu chuẩn với JSSE cung cấp SSLContext,KeyManagerFactory,và các công cụ TrustManagerFactory,cũng như các công cụ cho các lớp engine theo chuẩn bảo mật Java(java.security) API.Các công cụ được cung cấp bởi SunJSSE là : Lớp engine đƣợc thực hiện Giải thuật hoặc giao thức KeyFactory “RSA” KeyPairGenerator “RSA” KeyStore “PKCS12” Signature “MD2withRSA”,”MD5withRSA”,”SHA1withRSA” KeyManagerFactory “SunX509”,”NewSunX509” TrustManagerFactory “SunPKIX”(aka “X509”/”PKIX”),”SunX509” SSLContext “SSLv3”(aka “SSL”),”TSLv1”(aka “TLS”) Secure Socket Layer 37
PTIT 2009 Đề tài môn Bảo mật thông tin II.3.1 Lớp SSLContext : Javax.net.ssl.SSLContext là 1 lớp engine cho việc thực thi của 1 giao thức SSL.Một thực thể của lớp này hành động như 1 factory cho các SSL socket factories và SSL engine.Một SSLContext giữ tất cả các thông tin trạng thái được chia sẻ qua tất cả các đối tượng được tạo dưới ngữ cảnh này.Ví dụ,trạng thái phiên được kết hợp với SSLContext khi nó thỏa thuận thông qua giao thức bắt tay bằng socket được tạo bởi socket factories cung cấp bởi ngữ cảnh.Những phiên được lưu có thể được tái sử dụng và chia sẻ bởi các socket khác được tạo dưới cùng ngữ cảnh. Mỗi thực thể được cấu hình thông qua phương thức khởi tạo init với các khóa,chuỗi chứng thực,và các chứng thực CA gốc được tin cậy mà nó cần để biểu diễn xác thực.Cấu hình này được cung cấp dưới dạng các manager đáng tin cậy và khóa.Những manager này cung cấp hỗ trợ cho việc xác thực và các khía cạnh thỏa thuận khóa của các cipher suite được hỗ trợ bởi ngữ cảnh. Hiện tại chỉ hỗ trợ X509 dựa trên các manager . Việc tạo 1 đối tượng SSLContext Giống như các provider JCA dựa trên các lớp engine,các đối tượng SSLContext được tạo sử sụng phương thức factory getInstanse của lớp SSLContext.Những phương thức tĩnh này mỗi cái trả về 1 thực thể mà thực hiện ít nhất 1 giao thức SSL được yêu cầu.Thực thể trả về cũng có thể thực hiện giao thức khác.Ví dụ,getInstance(“SSLv3”) có thể trả về 1 thực thể mà thực hiện “SSLv3” và “TLSv1”.Phương thức getSupportedProtocols trả về 1 danh sác các giao thức hỗ trợ khi 1 SSLSocket,SSLServerSocket hoặc SSLEngine được tạo từ ngữ cảnh này.Bạn có thể kiểm soát cái mà các giao thức thực sự dùng cho kết nối SSL bằng cách sử dụng phương thức setEnabledProtocols(String[] protocols). Note: 1 đối tượng SSLContext được tạo ra tự động,được khởi tạo và đánh dấu tĩnh đối với lớp SSLSocketFactory khi bạn gọi SSLSocketFactory.getDefault.Vì vậy,bạn không cần phải tạo trực tiếp và khởi tạo 1 đối tượng SSLContext(nếu bạn không muốn ghi đè lên thuộc tính mặc định). Để tạo 1 đối tượng SSLContext bằng cách gọi 1 phương thức factory getInstance,bạn có thể xác định tên giao thức.bạn cũng có thể xác định các mà nhà cung cấp muốn bạn cung cấp cách thực hiện giao thức yêu cầu: public static SSLContext getInstance(String protocol); public static SSLContext getInstance(String protocol,String provider); public static SSLContext getInstance(String protocol,Provider provider); Nếu chỉ có 1 tên giao thức được xác định,hệ thống sẽ xác định nếu có 1 cách thực hiện của giao thức được yêu cầu sẵn có trong môi trường,và nếu có nhiều hơn 1,nếu có 1 cái là được thích hợp hơn cả… Nếu cả 1 tên giao thức và nhà cung cấp đều được chỉ định,hệ thống sẽ xác định nếu có 1 cách thực thi lên các giao thức trong provider được yêu cầu, và đưa ra 1 ngoại lê nếu không có. Một giao thức là 1 chuỗi(như “SSL”) mô tả giao thức SSL mong muốn.Tên giao thức chung danh cho các đối tượng SSLContext: Secure Socket Layer 38
PTIT 2009 Đề tài môn Bảo mật thông tin Protocol Comment SSL Hỗ trợ những version của SSL; có thể hỗ trợ một số version khác SSLv2 Hỗ trợ SSL version 2 hoặc cao hơn SSLv3 Hỗ trợ SSL version 3; có thể hỗ trợ một số version khác TLS Hỗ trợ những version của TLS; có thể hỗ trợ một số version khác TLSv1 Hỗ trợ TLS version 1; có thể hỗ trợ một số version khác Sau đây là 1 vài ví dụ về thu được 1 SSLContext: SSLContext sc = SSLContext.getInstance("SSL"); SSLContext đc tạo mới nên được khởi tạo bằng cách gọi phương thức init: public void init(KeyManager[] km , TrustManager[] tm , SecureRandom random); Nếu tham số KeyManager[] là null,thì 1 KeyManager rỗng sẽ được định nghĩa cho ngữ cảnh này.Nếu tham số TrustManager[] là null,các provider bảo mật được cài đặt sẽ được tìm kiếm cho việc thực hiện có độ ưu tiên cao nhất của TrustManagerFactory,từ đó 1 TrustManager thích hợp sẽ được thu đượcc.Theo cách đó,tham số SecureRandom sẽ là null,trong trường hợp ta thực hiện mặc định. Nếu ta dùng ngữ cảnh được khởi tạo mặc định(như SSLContext được tạo bởi SSLSocketFactory .getDefault() hoặc SSLServerSocketFactory.getDefault()),1 KeyManager mặc định và 1 TrustManager được tạo ra.Ta chon việc thực hiện SecureRandom mặc định. II.3.2 TrustManager Interface : Trách nhiệm cơ bản của TrustManager là xác định thử xem giấy ủy quyền xác thực được đưa ra có phải là đáng tin cậy.Nếu giấy ủy quyền không đáng tin,kết nối sẽ bị kết thúc.Để xác thực thực thể từ xa của 1 điểm đầu cuối socket bảo mật,bạn cần phải khởi tạo 1 đối tượng SSLContext với 1 hoặc nhiều TrustManager.Bạn cần vượt qua 1 TrustManager cho mỗi cơ chế xác thực mà được hỗ trợ.Nếu giá trị null được gửi vào việc khởi tạo,1 trust manager sẽ được tạo ra cho bạn.Thông thường,có 1 trust manager đơn hỗ trợ xác thực dựa trên chứng thực khóa công khai X.509 (như X509TrustManager).Một vài secure socket implement cũng hỗ trợ xác thực dựa trên việc chia sẻ khóa bí mật,như Kerberos,hoặc 1 vài cơ chế khác. TrustManager được tạo hoặc là bằng TrustManagerFactory,hoặc bằng việc cung cấp 1 thực hiện cụ thể của interface. II.3.3 Lớp TrustManagerFactory : Javax.net.ssl.TrustManagerFactory là 1 lớp engine dùng cho 1 provider dựa trên dịch vụ mà hành động như 1 factory cho 1 hay nhiều kiểu đối tượng TrustManager .Vì nó là provider cơ sở,các factory bổ sung có thể được thực hiện và cấu hình mà cung cấp các trust manager thêm vào và luân phiên mà cung cấp nhiều dịch vụ phức tạp hoặc thực hiện các policy xác thực được cài đặt cụ thể. Tạo 1 TrustManagerFactory: Secure Socket Layer 39
PTIT 2009 Đề tài môn Bảo mật thông tin Bạn tạo 1 thực thể của lớp này theo kiểu tương tự với SSLContext,ngoại trừ việc thông qua 1 chuỗi tên giải thuật thay vì tên 1 giao thức với phương thức getInstance: public static TrustManagerFactory getInstance(String algorithm); public static TrustManagerFactory getInstance(String algorithm, String provider); public static TrustManagerFactory getInstance(String algorithm, Provider provider); Chuỗi tên giải thuật mẫu là: “PKIX” Gọi hàm theo mẫu sau : TrustManagerFactory tmf = TrustManagerFactory.getInstance("PKIX", "SunJSSE"); Việc gọi ở trên sẽ tạo ra 1 thực thể của trust manager factory PKIX của nhà cung cấp SunJSSE.Factory này sau đó có thể dùng để tạo trust manager mà cung cấp kiểm tra tính hợp lệ đường dẫn chứng thực X.509 PKIX cơ sở. Khi khởi tạo 1 SSLContext,bạn có thể dùng các trust manager được tạo ra từ 1 trust manager factory,hoặc bạn có thể viết trust manager của chính bạn,có thể sử dụng CertPath API.Bạn không cần phải dùng trust manager factory nếu bạn thực hiện 1 trust manager sử dụng giao diện X509TrustManager. 1 factory được tạo mới nên được khởi tạo bằng cách gọi 1 trong những phương thức init: public void init(KeyStore ks); public void init(ManagerFactoryParameters spec); Bạn nên gọi bất của phương thức init nào phù hợp với TrustManagerFactory bạn đang dùng(Hỏi nhà cung cấp). Đối với nhiều factory,như “SunX509” TrustManagerFactory từ nhà cung cấp SunJSSE,KeyStore chỉ là thông tin được yêu cầu để khởi tạo TrustManagerFactory và vì vậy phương thức init đầu tiên là phương thức phù hợp để gọi.TrustManagerFactory sẽ truy vấn KeyStore cho thông tin theo đó chứng thực từ xa nên được tin cậy trong suốt quá trình kiểm tra xác thực. Trong 1 vài trường hợp nhà cung cấp cần các tham số khởi tạo KeyStore.Các user của nhà cung cấp đặc biệt được mong đợi để thông qua việc thực hiện ManagerFactoryParameters phù hợp như đã định nghĩa bởi nhà cung cấp.Nhà cung cấp sau đó có thể gọi các phương thức cụ thể trong việc thực hiện ManagerFactoryParameters để thu được thông tin cần thiết. Ví dụ,giả sử nhà cung cấp TrustManagerFactory yêu cầu các tham số khởi tạo B,R và S từ bất cứ ứng dụng nào mà mong để dùng nhà cung cấp đó.Giống như tất cả các nhà cung cấp yêu cầu các tham số khởi tạo như KeyStore,nhà cung cấp sẽ yêu cầu ứng dụng cung cấp các thực thể của 1 lớp mà việc thực hiện 1 sub-interface ManagerFactoryParameters riêng biệt.Trong ví dụ của chúng ta,giả sử nhà cung cấp yêu cầu rằng việc thực hiện ứng dụng gọi và tạo thực thể của MyTrustManagerFactoryParams và gửi nó vào phương thức init thứ 2.Ở đây là những gì MyTrustManagerFactoryParams có thể thể hiện: public interface MyTrustManagerFactoryParams extends ManagerFactoryParameters { public boolean getBValue(); public float getRValue(); public String getSValue(): } Secure Socket Layer 40
PTIT 2009 Đề tài môn Bảo mật thông tin Một vài trustmanager có thể tạo 1 quyết định đáng tin cậy mà không phải khởi tạo tường minh với 1 đối tượng KeyStore hoặc bất kỳ tham số nào khác.ví dụ,chúng có thể truy cập nguyên liệu đáng tin cậy từ dịch vụ danh mục cục bộ thông qua LDAP,có thể sử dụng 1 trạng thái chứng thực trực tuyến từ xa hoặc có thể truy cập nguyên liệu tin cậy mặc định từ 1 vị trí cục bộ chuẩn. Hỗ trợ PKIX TrustManager: Trust manager factory CertPath dựa trên X.509 được gọi là “SunPKIX” được thêm vào.SunPKIX là có sẵn cùng với trust manager factory X.509 mặc định mà đơn giản được biết như là “SunX509”. Trong J2SE 5,bây giờ SunPKIX là X509TrustManagerFactory mặc định.Nó được chọn bởi các thuộc tính ssl.TrustManagerFactory.algorithm trong file java.security(để trở lại sử dụng trust manager cũ,theo thủ tục trong Customizing the Default Key and Trust Manager để thay đổi thuộc tính từ PKIX đến SunX5.09).Chú ý rằng sự thay đổi này chỉ ảnh hưởng đến các ứng dụng mà sử dụng trust mananager mặc định,nó ko ảnh hưởng đến các ứng dụng mà trust manager cụ thể tường minh với SSLContext.init(…,TrustManager[],…).Cách khác,SunPKIX factory có thể được truy cập một cách có lập trình bằng cách gọi TrustManagerFactory.getInstance(“SunPKIX”). PKIX trust manager factory sử dụng CertPath PKIX implementation từ 1 nhà cung cấp bảo mật được cài đặt.,1 nhà cung cấp “SUN” CertPath được cung cấp với bộ J2SE 5 Development Kit.Trust manager factory có thể được khởi tạo sử dụng phương thức init(KeyStore ks) thông thường,hoặc bằng cách gửi vào các tham số CertPath cho PKIX trust manager sử dụng lớp được giới thiệu mới javax.net.ssl.CertpathTrustmanagerparameters. Đây là ví dụ về lam cách nào để lấy trust manager để sử dụng 1 lưu trữ chứng thực LDAP riêng biệt và kích hoạt bộ kiểm tra thu hồi. import javax.net.ssl.*; import java.security.cert.*; import java.security.KeyStore; ... // Tạo tham số PKIX KeyStore anchors = KeyStore.getInstance("JKS"); anchors.load(new FileInputStream(anchorsFile)); CertPathParameters pkixParams = new PKIXBuilderParameters(anchors, new X509CertSelector()); // Chỉ định nơi LDAP certificate để dùng LDAPCertStoreParameters lcsp = new LDAPCertStoreParameters("ldap.imc.org", 389); pkixParams.addCertStore(CertStore.getInstance("LDAP", lcsp)); // Chỉ định rằng việc kiểm tra thu hồi thì được kích hoạt pkixParams.setRevocationEnabled(true); // Gói chúng lại như thông số Trust manager ManagerFactoryParameters trustParams = Secure Socket Layer 41
PTIT 2009 Đề tài môn Bảo mật thông tin new CertPathTrustManagerParameters(pkixParams); // Tạo TrustManagerFactory cho PKIX phục vụ cho trust manager TrustManagerFactory factory = TrustManagerFactory.getInstance("PKIX"); // Chuyển thông số cho factory để được chuyển cho việc thực thi CertPath factory.init(trustParams); // Dùng factory SSLContext ctx = SSLContext.getInstance("TLS"); ctx.init(null, factory.getTrustManagers(), null); Nếu phương thức init(KeyStore ks) được dùng,các tham số PKIX mặc định được dùng với ngoại lệ rằng bộ kiểm tra thu hồi bị vô hiêu.Nó có thể được kích hoạt bằng cách lập thuộc tính hệ thống com.sun.net.ssl.checkRevocation thành true.Chú ý rằng việc thiết lập này yêu cầu CertPath implementation tự nó có thể xác định vị trí thông tin thu hồi.PKIX implementation trong nhà cung cấp SUN có thể làm những điều này trong nhiều trường hợp nhưng yêu cầu rằng thuộc tính hệ thống com.sun.security.enableCRLDP được lập thành true. II.3.4 X509TrustManager Interface : Interface javax.net.ssl.X509TrustManager là mở rộng của interface cơ bản TrustManger .Interface này phải được thực hiện bằng 1 trust manager khi sử dụng X.509 dựa trên xác thực. Để hỗ trợ xác thực X.509 của điểm đầu cuối socket ở xa thông qua JSSE,và thực thể của interface này phải được gửi vào phương thức init của đối tượng SSLContext. Tạo một X509TrustManager Bạn có thể hoặc là tự bạn thực hiện giao diện này trực tiếp hoặc thu nhận 1 từ 1 nhà cung cấp dựa trênTrustManagerFactory (như được cung cấp bởi nhà cung cấp SunJSSE).bạn có thể cũng thực hiện giao diện của bạn mà ủy quyền cho 1 factory tạo ra trust manager.Ví dụ,bạn có thể làm điều này để lọc kết quả quyết định tin cậy và truy vấn 1 user đầu cuối thông qua 1 giao diện đồ họa người dùng. Chú ý: nếu 1 tham số null KeyStore được gửi vào SunJSSE “SunX509” hoặc “SunPKIX” TrustManagerFactory,factory sử dụng các bước theo sau để cố gắng tìm kiếm nguyên liệu tin cậy: 1.Nếu là thuộc tính hệ thống: javax.net.ssl.trustStore được định nghĩa,sau đó TrustManagerFactory nỗ lực để tìm 1 file sử dụng tên file cụ thể bằng thuộc tính hệ thống,và sử dụng file đó cho KeyStore.Nếu thuộc tính hệ thống javax.net.ssl.trustStorePassword cũng được định nghĩa,giá trị của nó được dùng để kiểm tra tính toàn vẹn dữ liệu trong truststore trước khi mở nó. Nếu javax.net.ssl.trustStore được định nghĩa nhưng các file xác định không tồn tại,thì 1 TrustManager mặc định sử dụng 1 keystore rỗng được tạo. 2. Nếu thuộc tính hệ thống javax.net.ssl.trustStore không được xác định,thì nếu file: <java-home>/lib/security/jssecacerts tồn tại,file đó được dùng. Secure Socket Layer 42
PTIT 2009 Đề tài môn Bảo mật thông tin 3. Nếu file: <java-home>/lib/security/cacerts tồn tại,file đó được dùng. (Nếu các file này đều không tồn tại,điều này có thể xảy ra ổn thỏa,vì có các cipher suite SSL mà ngầm định,mà không làm bất cứ xác thực nào và vì vậy không cần 1 truststore.) Factory tìm kiếm 1 file cụ thể cùng với thuộc tính bảo mật javax.net.ssl.trustStore hoặc cho file jssecacerts trước khi kiểm tra 1 file cacerts để mà bạn có thể cung cấp 1 tập JSSE cụ thể của chứng thực gốc đáng tin cậy mở rộng từ chúng mà có thể được trình diễn trong cacerts cho các mục đích code-signing. Tạo ra X509TrustManager của riêng bạn: Nếu hành vi được cung cấp X509TrustManager không phù hợp với tình huống của bạn,bạn có thể tạo ra X509TrustManager của riêng bạn bằng cách hoặc là tạo và đăng ký TrustManagerFactory của riêng bạn hoặc là bằng cách thực hiện giao diện X509TrustManager trực tiếp. Lớp MyX509TrustManager sau đây làm tăng hành vi SunJSSE X509 TrustManager mặc định bằng cách cung cấp xác thực có thể thay đổi 1 cách logic khi SunJSSE X509 TrustManager mặc định hỏng: class MyX509TrustManager implements X509TrustManager { /* * X509TrustManager mặc định được trả về bởi SunX509. Chúng ta sẽ ủy quyền * quyết định cho nó, và phải dùng đến tính logic trong Class nếu * X509TrustManager mặc định không tin tưởng nó. */ X509TrustManager sunJSSEX509TrustManager; MyX509TrustManager() throws Exception { // Tạo một JSSE X509TrustManager mặc định. KeyStore ks = KeyStore.getInstance("JKS"); ks.load(new FileInputStream("trustedCerts"), "passphrase".toCharArray()); TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509", "SunJSSE"); tmf.init(ks); TrustManager tms [] = tmf.getTrustManagers(); /* * Lặp lại trustmanagers được trả về, tìm kiếm * một trường hợp của X509TrustManager. Nếu tìm thấy, * dùng nó như là trust manager mặc định của chúng ta. */ for (int i = 0; i < tms.length; i++) { if (tms[i] instanceof X509TrustManager) { sunJSSEX509TrustManager = (X509TrustManager) tms[i]; return; } } /* * Tìm vài cách khác để khởi tạo hoặc là chúng ta sẽ phải làm hỏng * việc xây dựng. */ throw new Exception("Couldn't initialize"); } /* Secure Socket Layer 43
PTIT 2009 Đề tài môn Bảo mật thông tin * Ủy nhiệm đến trust manager mặc định. */ public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException { try { sunJSSEX509TrustManager.checkClientTrusted(chain, authType); } catch (CertificateException excep) { // Làm bất cứ xử lý đặc biệt ở đây hoặc xem lại ngoại lệ } } /* * Ủy quyền cho trust manager mặc định. */ public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { try { sunJSSEX509TrustManager.checkServerTrusted(chain, authType); } catch (CertificateException excep) { /* * Có thể pop up một dialog box hỏi có hay không tin tưởng * chuỗi cert */ } } /* * Chỉ đơn giản thông qua việc này. */ public X509Certificate[] getAcceptedIssuers() { return sunJSSEX509TrustManager.getAcceptedIssuers(); } } Một khi bạn tạo ra 1 trust manager như thế,gán nó cho 1 SSLContext thông qua phương thức khởi tạo.SocketFactories tương lai được tạo từ SSLContext này sẽ sử dụng TrustManager mới của bạn khi tạo các quyết định đáng tin cậy. TrustManager[] myTMs = new TrustManager []{new MyX509TrustManager() }; SSLContext ctx = SSLContext.getInstance("TLS"); ctx.init(null, myTMs, null); Cập nhật keyStore động: Bạn có thể làm tăng MyX509TrustManager để điều khiển cập nhật keystore động.Khi một checkClientTrusted hoặc checkServerTrusted kiểm tra có lỗi và không thiết lập 1 chuỗi chứng thực đáng tin cậy,bạn có thể thêm vào chứng thực đáng tin cậy được yêu cầu cho keystore.Bạn cần tạo 1 sunX509TrustManager mới từ TrustManagerFactory được khởi tạo với keystore được cập nhật.Khi bạn thiết lập 1 kết nối mới(sử dụng SSLContext khởi tạo trước đó),chứng chỉ thêm vào mới sẽ được gọi để tạo các quyết định đáng tin cậy. II.3.5 KeyManager Interface : Trách nhiệm chính của của KeyManager là chọn giấy ủy quyền chứng thực mà sẽ kết luận cuối cùng rằng được gửi đi đến host ở xa.Để xác thực bản thân bạn(điểm đầu cuối socket bảo mật cục bộ) đến 1 điểm đầu cuối ở xa,bạn cần khởi tạo 1 đối tượng SSLContext với 1 hoặc nhiều KeyManagers.Bạn cần gửi 1 KeyManager đối với mỗi cơ chế xác thực sẽ được hỗ trợ.Nếu giá trị null được gửi vào việc khỏi tạo SSLContext,1 KeyManager rỗng sẽ được tạo.Nếu ngữ cảnh mặc định bên trong được dùng(như SSLContext được tạo bởi SSLSocketFactory.getDefalut() hoặc SSLServerSocketFactory.getDefault()),1 KeyManager mặc định được tạo.Điển hình,có 1 key manager đơn hỗ Secure Socket Layer 44
PTIT 2009 Đề tài môn Bảo mật thông tin trợ xác thực dựa trên các chứng thực khóa công khai X.509.Một vài secure socket implement cũng có thể hỗ trợ xác thực dựa trên các khóa bí mật được chia sẻ,Kerberos,hay các cơ chế khác. Các KeyManager được tạo ra hoặc bằng KeyManagerFactory,hoặc bằng việc cung cấp 1 thực thi cụ thể của interface. II.3.6 Lớp KeyManagerFactory : Javax.net.ssl.KeyManagerFactory là 1 lớp engine cho người cung cấp dựa trên dịch vụ mà hành động như 1 factory cho 1 hoặc nhiều kiểu đối tượng KeyManager.Người cung cấp SunJSSE thực thi 1 factory có thể trả về 1 key manager X.509 cơ sở.Vì đó là nhà cung cấp cơ sở,các factory thêm vào có thể được thực hiện và cấu hình để cung cấp các key manager có thể thêm vào hay thay đổi. Tạo 1 KeyManagerFactory Bạn tạo 1 thực thể của lớp này theo 1 kiểu tương tự như SSLContext,ngoại trừ gửi vào chuỗi tên giải thuật thay vì tên của giao thức phương thức getInstance: public static KeyManagerFactory getInstance(String algorithm); public static KeyManagerFactory getInstance(String algorithm, String provider); public static KeyManagerFactory getInstance(String algorithm, Provider provider); 1 chuỗi tên giải thuật mẫu như sau: “SunX509” Gọi phương thức như sau: KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509", "SunJSSE"); Cách gọi ở trên sẽ tạo ra 1 thực thể của key manager factory mặc định của nhà cung cấp SunJSSE, mà cung cấp X509 cơ sở dựa trên các khóa xác thực. 1 factory được tạo mới nên được khởi tạo bằng cách gọi 1 trong những phương thức init sau: public void init(KeyStore ks, char[] password); public void init(ManagerFactoryParameters spec); Bạn nên gọi bất cứ cái gì mà phương thức init phù hợp cho KeyManagerFactory bạn đang sử dụng.(Hỏi nhà cung cấp ) Đối với nhiều factory,như “SunX509” mặc định KeyManagerFactory từ nhà cung cấp SunJSSE, KeyStore và mật khẩu chỉ là thông tin được yêu cầu để khởi tạo KeyManagerFactory và vì vậy phương thức init đầu tiên là phương thức thích hợp để gọi.KeyManagerFactory sẽ truy vấn KeyStore vì các thông tin trên khóa bí mật và liên kết các chứng chỉ khóa công khai nên được dùng cho việc xác thực đến 1 điểm đầu cuối socket từ xa.Tham số password xác định mật khẩu sẽ dùng với các phương thức cho truy cập khóa từ KeyStore.Tất cả các khoá trong KeyStore phải được bảo vệ bằng mật khẩu giống nhau. Trong 1 vài trường hợp,các tham số khởi tạo như KeyStore và mật khẩu có thể cần thiết đối với nhà cung cấp.Người sử dụng của nhà cung cấp riêng biệt đó được mong đợi vượt qua việc thực thi của ManagerFactoryParameters phù hợp như được định nghĩa bởi nhà cung cấp.Sau đó nhà cung cấp có thể gọi các phương thức cụ thể trong việc thực thi ManagerFactoryParameters để thu được thông tin cần thiết. Secure Socket Layer 45
PTIT 2009 Đề tài môn Bảo mật thông tin Một vài factory có thể cung cấp truy cập đến nguyên liệu xác thực mà không phải khởi tạo với 1 đối tượng KeyStore hoặc bất kỳ tham số nào khác.Ví dụ,họ có thể truy cập nguyên liệu khóa như là 1 phần của cơ chế login như là 1 cơ chế dựa trên JAAS(Java Authentication and Authorization Service) Như đã dẫn ở trên, nhà cung cấp SunJSSE hỗ trợ 1 factory “SunX509” mà phải được khởi tạo với 1 tham số KeyStore. II.3.7 X509KeyManager Interface : Interface javax.net.ssl.X509Manager mở rộng interface cơ sở KeyManager.Nó phải được thực hiện bởi 1 key manager cho X509 dựa trên xác thực.Để hỗ trợ xác thực X509 để điều khiển các điểm đầu cuối socket thông qua JSSE, 1 thực thể của interface này phải được gửi vào phương thức init của đối tượng SSLContext. Tạo 1 X509KeyManager: Bạn có thể hoặc là thực thi interface này 1 cách trực tiếp hoặc nhận nó từ 1 nhà cung cấp dựa trên KeyManagerFactory(như các interface được cung cấp bởi nhà cung cấp SunJSSE).Bạn cũng có thể thực thi của riêng bạn ủy quyền đến 1 factory sinh ra key manger.Ví dụ,bạn có thể làm điều này để lọc các key kết quả và truy vấn user đầu cuối thông qua 1 interface đồ họa người dùng. Chú ý: Nếu không có tham số KeyStore được gửi qua SunJSSE mặc định “SunX509” KeyManagerFactory,factory cố gắng tìm nguyên liệu khóa bằng cách tham khảo các thuộc tính hệ thống: javax.net.ssl.keyStore javax.net.ssl.keyStorePassword Nếu những thuộc tính này xác định 1 file với 1 password phù hợp,factory sử dụng file này cho KeyStore.Nếu file đó ko tồn tại,thì 1 KeyManager mặc định sử dụng 1 keystore rỗng được tạo. Thông thường,qua trình diễn ra trên server trong giao thức bắt tay sẽ cần 1 keystore cho KeyManager của nó để nhận giấy ủy nhiệm để xác thực với client.Tuy nhiên,nếu 1 trong số cipher suite ngầm định được chọn,keystore KeyManager của server không cần thiết.Và,nếu server không yêu cầu client xác thực,quá trình diễn ra khi client không cần keystore KeyManager.Vì vậy,trong những tình huống này nó có thể ổn nếu không có giá trị thuộc tính hệ thống javax.net.ssl.keyStore nào được định nghĩa. Tạo X509KeyManager của riêng bạn: Nếu hành vi mặc định X509KeyManager không phù hợp với tình huống của bạn,bạn có thể tạo X509KeyManager của mình theo cách tương tự với việc tạo X509TrustManager. II.3.8 Mối liên hệ TrustManagers và KeyManagers : Tóm lại,sau đây là các trách nhiệm sơ khảo của mỗi kiểu manager: Type Function Xác định thử xem xác thực credentials ở xa nào(và cả TrustManager kết nối) nên được tin cậy KeyManager Xác định xác thực credentials nào để gửi cho host ở xa. Secure Socket Layer 46
PTIT 2009 Đề tài môn Bảo mật thông tin II.4 Các Class và Interface hỗ trợ thứ cấp : Những lớp này được cung cấp như là 1 phần của JSSE API để hỗ trợ việc tạo,sử dụng và quản lý các socket bảo mật.Chúng hầu như không được sử dụng bởi những ứng dụng socket bảo mật hơn là các lớp hỗ trợ và các lớp lõi.Các lớp và các interface hỗ trợ thứ cấp là 1 phần của các gói javax.net.ssl và javax.security.cert II.4.1 SSLSessionContext Interface : Javax.net.ssl.SSLSessionContext là 1 nhóm của SSLSession kết hợp với 1 thực thể đơn.Thí dụ,nó có thể kết hợp với 1 server hay client tham gia vào nhiều session đồng thời.Các phương thức trên giao diện này kích hoạt sự liệt kê các session trong 1 context và cho phép kiểm tra các session đặc biệt với session id của chúng. 1 SSLSessionContext có thể được nhận từ 1 SSLSession bằng cách gọi SSLSession phương thức getSessionContext. Context có thể không hợp lệ trong 1 vài môi trường,mà trong trường hợp đó phương thức getSessionContext trả về giá trị null. II.4.2 SSLSessionBindingListener Interface : Javax.net.ssl.SSLSessionBindingListener là 1 interface được thực hiện bởi các đối tượng muốn được chú ý khi chúng được kết nối hoặc không đc kết nối từ 1 SSLSession. II.4.3 Lớp SSLSessionBindingEvent : Javax.net.ssl.SSLSessionBindingEvent là 1 sự kiện giao tiếp với 1 SSLSessionBindingListener khi nó được kết nối hoặc không kết nối từ 1 SSLSession. II.4.4 HandShakeCompletedListener Interface : javax.net.ssl.handShakeCompletedListener là 1 interface được thực hiện bởi bất kì lớp nào muốn nhận thông tin chú ý của việc hoàn thành giao thức bắt tay SSL trên kết nối SSLSocket được đưa ra. II.4.5 Lớp SSLHandShakeCompletedEvent : Javax.net.ssl.HandShakeCompletedEvent là 1 sự kiện giao tiếp với HandShakeCompletedListener nhờ vào sự hoàn thành của 1 giao thức bắt tay SSL trên 1 kết nối SSLSocket được đưa ra. II.4.6 HostnameVerifier Interface : Nếu việc xác nhận hostname chuẩn của SSL/TLS implementation thất bại theo kiểu logic,thì implementation sẽ gọi phương thức verify của lớp mà thực hiện interface này và được đánh dấu với thực thể HttpsURLConnection.Nếu lớp gọi lại có thể xác định hostname được chấp nhận được đưa ra các tham số,nó sẽ ghi lại kết nối được cho phép.Hồi đáp không được chấp nhận sẽ là cho kết nối bị hủy bỏ. Ví dụ: public class MyHostnameVerifier implements HostnameVerifier { public boolean verify(String hostname, SSLSession session) { // pop up một dialog box tương tác // hay thêm một logic theo dõi bổ sung if (good_address) { return true; } else { return false; } } } //...đã hủy... HttpsURLConnection urlc = (HttpsURLConnection) Secure Socket Layer 47
PTIT 2009 Đề tài môn Bảo mật thông tin (new URL("https://www.sun.com/")).openConnection(); urlc.setHostnameVerifier(new MyHostnameVerifier()); II.4.7 Lớp X509Certificate : Nhiều giao thức socket bảo mật biểu diễn xác thực sử dụng các chứng thực khóa công khai, cũng được gọi là các chứng thực X.509 .Đây là cơ chế xác thực mặc định dành cho giao thức SSL và TLS. Lớp trừu tượng java.security.cert.X509Certificate cung cấp 1 cách chuẩn để truy cập các thuộc tính của các chứng thực X.509 Chú ý: lớp javax.security.cert.X509Certificate được hỗ trợ chỉ để tương thích trở lại với phiên bản cũ (1.0.x , 1.1.x) của JSSE. Các ứng dụng mới nên sử dụng java.security.cert.X509Certificate, không phải javax.security.cert.X509Certificate Secure Socket Layer 48
PTIT 2009 Đề tài môn Bảo mật thông tin Chương III : III.1 Các phƣơng pháp tấn công SSL dựa trên kỹ thuật tấn công MITM III.1.1 Diffie Hellman MITM Attack : Trong quá trình HankShake, nếu Client và Server quyết định sử dụng thuật toán trao đổi khóa Anonymous Diffie Hellman thì trong phase 2 và phase 3 ở bước Server Key Exchange và Client Key Exchange sẽ xảy ra sự trao đổi các tham số (g,p,gamod p) cùa thuật toán tương tự như sau: và không có bất kỳ sự xác thực nào.Do đó attacker có thể lợi dụng điểm yếu này để thực hiện tấn công: Lúc này attaker sẽ dùng 2 khóa, 1 khóa giao dịch với Client và khóa còn lại giao dịch với Server.Cả Client và Server đều không nhận thấy có sự thay đổi bất thường Secure Socket Layer 49
PTIT 2009 Đề tài môn Bảo mật thông tin III.1.2 SSLSniff & SSLStrip MITM Attack : Đây là 2 kiểu tấn công đánh vào tâm lý người dùng Giao dịch https thông thƣờng SSLSniff MITM Attack Với Client, Attaker sẽ tạo ra 1 digital certificate giả mạo Server,digital certificate này khá giống với digital certificate của Server và chỉ khác ở 1 số trường.Đặc biệt là trường PU,attacker thay thế PU của Server bằng PU của mình.Với Server, attacker tiến hành giao dịch như 1 Client thông thường.Khi giao dịch,trên Client sẽ xuất hiện những warning nhưng hầu hết người dùng đều bỏ qua những cảnh báo này.Kết quả là mọi thông tin trong quá trình giao dịch đều bị “nghe lén” bởi attacker SSL Strip MITM Attack Đại đa số người dùng khi truy cập web đều không gõ chuỗi ký tự “http://” hoặc “https://” .Vì vậy người dùng thường sử dụng SSL 1 cách gián tiếp thông qua các HyperLinks và Redirection Messages(được xử lý bởi browser).Attacker can thiệp vào kết nối giữa Client và Server,thay thế các HyperLinks “https://....” thành “http://....” và các Redirection Messages tới các trang “https://....” thành các trang “http://....”Kết quả là attacker thực hiện kết nối http thông thường với Client và https với Server,vì không có SSL trong kết với Client nên attacker có thể đọc mọi thông tin Secure Socket Layer 50
PTIT 2009 Đề tài môn Bảo mật thông tin III.2 Demo tấn công SSLStrip :  Máy Server chạy chương trình ClassFileServer: a. Chương trình được viết theo dạng TCP Server b. Xử lý đa luồng c. Dùng JSSE hỗ trợ bởi ngôn ngữ Java mở SSLServerSocket cho yêu cầu kết nối port 443  Máy attacker sử dụng Cain để tấn công Cain dùng phương pháp arp poisoning, gởi liên tục các gói arp reply về phía Victim và Gateway Router mỗi 30s.Điều này làm sai lệch bảng arp trên victim và Client: i. Trên máy Victim bảng arp xuất hiện entry có thông tin: Internet Address : 1.1.1.1 (Gateway) Physical Address : 00-0c-29-61-2e-d3 (Attacker) ii. Trên Gateway Router bảng arp xuất hiện entry có thông tin: Internet Address : 1.1.1.2 (Victim) Physical Address : 00-0c-29-61-2e-d3 (Attacker) Lúc này mọi thông tin qua lại giữa Victim và GateWay đều qua Attacker.Khi Victim thực hiện kết nối https với Server thì trong quá trình HandShake tại phase 2 ở bước certifiate,chương trình Cain trên máy Attacker tạo ra 1 certificate giả mạo và gởi cho Client đồng thời tiếp nhận Server‟s certificate như Client bình thường.Khi nhận certificate giả mạo,browser trên Client sẽ thông báo sercurity alert nhưng phần lớn người dùng đều bỏ qua dẫn đến việc Attacker có thể dễ dàng can thiệp vào quá trình HankShake giữa Client và Server.Kết quả là Attacker có thể đọc được mọi thông tin mã hóa của Client và Server. Tuy nhiên nếu Client đặt địa chỉ gateway là chính nó 1.1.1.2 và Gateway bật cơ chế ARP Proxy thì lúc này quá trình tấn công bị thất bại . Attacker chỉ nhận được những gói tin từ Gateway trả về cho Client ,còn những gói tin có địa chỉ đích là webserver thì Client sẽ gửi đi với destination mac address là của Gateway vì vậy Attacker không thể thu được.Nhìn chung cách phòng tránh tốt nhất nhằm hạn chế tấn công MITM chính là sự thận trọng của người dùng đầu cuối và sự thường xuyên kiểm tra giám sát trong mạng nội bộ. Secure Socket Layer 51
PTIT 2009 Đề tài môn Bảo mật thông tin Chương IV : IV.1 Các ứng dụng phổ biến của SSL : Tuy đến nay vẫn còn tồn tại một số lỗ hổng có thể bị khai thác nhưng SSL vẫn là giao thức bảo mật cao nhất mà chưa một giao thức bảo mật nào có thể thay thế vai trò của nó . Nó phổ biến đến mức nếu thấy tên một giao thức có hậu tố “s” thì người ta biết ngay giao thức ứng dụng đó được kết hợp kèm với SSL. Sau đây là một số port phổ biến của những ứng dụng đi kèm SSL được IANA công nhận : Name Port Description Nsiiop 261 Dịch vụ IIOP trên TLS/SSL Https 443 HTTP trên TLS/SSL Smtps 465 SMTP trên TLS/SSL Nntps 563 NNTP trên TLS/SSL Ldaps 636 LDAP trên TLS/SSL Ftps-data 989 FTP-dữ liệu trên TLS/SSL Ftps 990 FTP-điều khiển trên TLS/SSL Telnets 992 TELNET trên TLS/SSL Imaps 994 IRC trên TLS/SSL Pop3s 995 POP3 trên TLS/SSL Ngoài một số ứng dụng phổ biến hiện nay của SSL như bảo mật trong Remote Desktop Protocol cho kết nối Terminal Service, Http cho Outlook Web Access hay Smtp/Imap/Pop3 cho mail , ứng dụng quan trọng của SSL mà không thể không nhắc tới là SSL VPN. Đó là lý do tại sao không chỉ các nhà cung cấp thiết bị mạng phần cứng đang đua nhau trong việc phát triển các sản phẩm hổ trợ SSL VPN mà cả những nhà cung cấp thiết bị mạng “mềm” như Microsoft cũng đưa nó vào sản phẩm Windows Server 2008 và Windows Vista Service Pack 1 của mình với cơ chế Secure Socket Tunneling Protocol (SSTP). Secure Socket Layer 52
PTIT 2009 Đề tài môn Bảo mật thông tin Sau đây chúng ta sẽ tìm hiểu một vài điểm cơ bản của SSTP:  SSTP là cơ chế kết nối VPN client to gateway bằng HTTP over Secure Socket Layer (HTTP over SSL) port 443. Thông thường, trong một hệ thống mạng hiện nay dù là các Firewall hay Proxy server đều cho phép truy cập HTTP và HTTPS. Vì vậy, dù ở bất cứ đâu các máy Client đều có thể kết nối VPN bằng cơ chế SSTP và đảm bảo bảo mật được gói tin vì áp dụng phương pháp mã hóa SSL.  SSTP được tích hợp hỗ trợ NAP để bảo vệ nguồn tài nguyên mạng tốt hơn bằng cách thi hành các chính sách về system health.  SSTP hỗ trợ IPV6 - đường hầm SSTP và IPV6 dựa trên việc kết nối SSTP thông qua IPV6.  Hơn nữa, SSTP thiết lập HTTP riêng lẻ thông qua session SSL từ SSTP client đến SSTP server. Dùng HTTP thông qua SSL Session sẽ giảm thiểu được chi phí và cân bằng tải tốt hơn.  SSTP không hổ trợ site to site. Sau đây là bảng so sánh tóm tắt SSTP với 2 cơ chế VPN phổ biến hiện nay – PPTP và L2TP/IPSec : Thuộc tính PPTP L2TP/IPSec SSTP Dạng kết nối Cố định Cố định Tạm thời Kiểu thiết bị Quản lý được Quản lý được Không quản lý được Kiểm soát truy cập Không chi tiết Không chi tiết Chi tiết Dạng kết nối thích hợp Client-to-Site Site-to-Site Client-to-Site Yêu cầu Client Phần mềm Client Phần mềm Client Browser Tƣơng thích Kém Kém Tốt Firewall/NAT Đóng gói GRE L2TP over UDP SSTP over TCP Cơ chế mã hóa Microsoft Point to Point IPSec ESP với 3DES hoặc SSL với RC4 hoặc AES Encryption (MPPE) với AES RC4 Tunnel maintenance PPTP L2TP SSTP protocol Cơ chế xác thực Radius,CHAP,PAP, Radius, Active Directory Radius, Active Directory MS-CHAP,MS-MAP ,RSA,Secure ID, X509 ,RSA,Secure ID, X509 Quá trình chứng thực Trước khi quá trình mã Sau khi IPSec session Sau khi SSL session được user hóa bắt đầu được khởi tạo khởi tạo Yêu cầu certificate cho Không Certificate của cả VPN Certificate của VPN server khởi tạo VPN tunnel server và client và root CA certificate trên client Ứng dụng Mọi ứng dụng trên nền IP Mọi ứng dụng trên nền IP Trên nền web, mail, TerminalService,CIFS Secure Socket Layer 53
PTIT 2009 Đề tài môn Bảo mật thông tin IV.2 Triển khai SSL : Nhìn chung khi lựa chọn giải pháp SSL cho bảo mật thì người quản trị phải xem xét đến nhiều khía cạnh như : độ khả thi ,chi phí triển khai , nhân sự , khả năng duy trì , độ ảnh hưởng đến hệ thống , .v.v. Khi triển khai ta cần chắc chắn chương trình quản lý ứng dụng của server và client đều hỗ trợ SSL và đã cập nhật những update / bản vá để đảm bảo không bị kẻ xấu lợi dụng . Đăng ký certificate nên lựa chọn từ những CA lớn và có uy tín. Sau đây là trình bày tóm tắt các bước cấu hình chính của một webserver IIS 6.0 của Microsoft chạy SSL với certificate đăng ký từ VeriSign ,từ đó ta có thể áp dụng triển khai cho các ứng dụng khác : 1. Tạo Request Certificate 2. Đăng ký SSL Certificate từ VeriSign.com 3. Cấu hình Trusted Root Certification Authority 4. Import SSL Certificate cho Web Server  1.Tạo Request Certificate : Trong IIS 6.0 Manager , mở Folder WebSites , right click website muốn xin certificate ( ở ví dụ chọn Default Web Site => Properties => Tab Directory Security => Server Certificate => Create a new certificate => Prepare a request now ,but send it later Secure Socket Layer 54
PTIT 2009 Đề tài môn Bảo mật thông tin => Name and Security Settings để default => điền thông tin về Organizition => Common name : điền tên miền trang web mà đã đăng ký với DNS hoặc nếu muốn chỉ mang ý nghĩa local thì điền NetBios name ( ở ví dụ điền www.ptit.com vì lúc sau khi đã đăng ký thành công sẽ dùng DNS của chính mình) => điền thông tin Country ,State ,City => Browse đến nới muốn tạo và đặt tên cho certificate request => xem lại summary => Finish => OK  2.Đăng ký SSL Cerificate từ VeriSign.com : Mở trang web www.verisign.com => chọn Free Trial SSL => Nhập các thông tin cá nhân theo mẫu ,cần điền chính xác mail để nhận kết quả => Tiếp tục nhập Teachnical Contact => Quay về nơi đặt certificate request ,copy nội dung Secure Socket Layer 55
PTIT 2009 Đề tài môn Bảo mật thông tin => Paste nội dung vào Paste Certificate Signing Request (CSR) ,chọn Server Platform là Microsoft , version là IIS 6.0 ,chọn mục đích sử dụng certificate này là Web Server =>Đặt câu hỏi bí mật và câu trả lời (chỉ có tác dụng nếu sau này muốn quay lại sửa thông tin về certificate này) => Xem lại summary và acceptance =>Finish Secure Socket Layer 56
PTIT 2009 Đề tài môn Bảo mật thông tin  3.Cấu hình Trusted Root Certification Authority : Vì trial root CA này là chưa chính thức nên ta phải đi cấu hình Trustted Root CA, nếu ta mua một certificate chính thức thì không cần làm bước này . => Vào mail đã dùng đăng ký certificate ,mở thư trả lời , down load Trial SSL Intermediate CA certificate => Chọn link VeriSign CA Certificate => Chọn Secure Site Trial Root CA Certificate => Copy toàn bộ Root CA certificate Secure Socket Layer 57
PTIT 2009 Đề tài môn Bảo mật thông tin => Trong máy dán nội dung trên vào file txt rồi đổi thành ca.cer => Mở IE option/tab content/chọn Certificate/chọn Import chỉ đến file ca.cer /chọn Automatically select the certificate store based on the type of certificate/Finish hoặc cũng có thể trong Run gõ certmgr.msc/mở Trusted Root Certificate Authorities/right click Certificate/All Task/Import file ca.cer như trong IE Secure Socket Layer 58
PTIT 2009 Đề tài môn Bảo mật thông tin  4.Import SSL certificate cho web server : Mở mail khi nảy,copy toàn bộ Trial SSL certificate =>Trong máy dán nội dung đó vào file mycert.txt =>Trong IIS manager Properties Default Web Site/tab Dictionary Security/Server Certificate => Chọn Process the pending request and install the certificate => Chỉ đến file mycert.txt Secure Socket Layer 59
PTIT 2009 Đề tài môn Bảo mật thông tin => SSL port để default 443 => Finish =>Trong tab chọn Edit => Check Require Secure Channel (SSL) để cho server luôn chạy bằng cơ chế SSL => Trong tab Home Dictionary chọn A redirect to URL và điền https://www.ptit.com => OK Secure Socket Layer 60
PTIT 2009 Đề tài môn Bảo mật thông tin => Trỏ DNS đến DNS của mình =>Test Secure Socket Layer 61
PTIT 2009 Đề tài môn Bảo mật thông tin Tham Khảo :  Cryptography and Network Security Principles and Practices, Fourth Edition –By William Stallings  JDK 5.0 Documentation  Information Security Principles and Practice – By Mark Stamp  Internet Security Cryptographic Principles, Algorithms and Protocols –By Man Young Rhee  Beginning Cryptography with Java – By David hook  Java Network Programming, 3rd Edition- By Elliotte Rusty Harold  MCP 70-299: Implementing and Administering Security in a Microsoft Windows Server 2003 Network.  http://www.blackhat.com/ (BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf)  http://www.thoughtcrime.org/  http://www.oxid.it/  http://en.wikipedia.org/  http://msopenlab.com/ Secure Socket Layer 62

More Related Content

PPTX
TIM HIEU SSL VA UNG DUNG TREN WEB SERVER
byconglongit90
 
PDF
Bảo mật ứng dụng web
byabesoon
 
PDF
Luận văn: Bảo mật và an toàn Thông tin trong Thương mại Điện tử
byViết thuê trọn gói ZALO 0934573149
 
PDF
Báo cáo tốt nghiệp - XÂY DỰNG CHƯƠNG TRÌNH QUẢN LÝ NHÀ HÀNG VỪA VÀ NHỎ SỬ DỤ...
byDuc Tran
 
PDF
Bài giảng an toàn ứng dụng web và csdl PTIT
byNguynMinh294
 
PDF
Đồ án Quản lý thư viện trường đại học Sao Đỏ
byAnastasia Smitham
 
DOCX
[Báo cáo] Bài tập lớn Kỹ thuật phần mềm ứng dụng: Thiết kế hệ thống quản lý p...
byThe Nguyen Manh
 
PDF
NGHIÊN CỨU XÂY DỰNG ỨNG DỤNG CHO HỆ ĐIỀU HÀNH iOS
byVàng Cao Thanh
 
TIM HIEU SSL VA UNG DUNG TREN WEB SERVER
byconglongit90
 
Bảo mật ứng dụng web
byabesoon
 
Luận văn: Bảo mật và an toàn Thông tin trong Thương mại Điện tử
byViết thuê trọn gói ZALO 0934573149
 
Báo cáo tốt nghiệp - XÂY DỰNG CHƯƠNG TRÌNH QUẢN LÝ NHÀ HÀNG VỪA VÀ NHỎ SỬ DỤ...
byDuc Tran
 
Bài giảng an toàn ứng dụng web và csdl PTIT
byNguynMinh294
 
Đồ án Quản lý thư viện trường đại học Sao Đỏ
byAnastasia Smitham
 
[Báo cáo] Bài tập lớn Kỹ thuật phần mềm ứng dụng: Thiết kế hệ thống quản lý p...
byThe Nguyen Manh
 
NGHIÊN CỨU XÂY DỰNG ỨNG DỤNG CHO HỆ ĐIỀU HÀNH iOS
byVàng Cao Thanh
 

What's hot

DOC
Giáo trình an toàn thông tin ths.nguyễn công nhật[bookbooming.com]
bybookbooming1
 
DOC
Phan tich thiet ke he thong thong tin
byNguyễn Duy Hưng
 
PDF
Đề tài: Xây Dựng Chương Trình Quản Lý Nhà Hàng Coffee SEN
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Đề tài: Tìm hiểu hệ thống phát hiện xâm nhập IDS-SNORT, 9đ
byDịch vụ viết bài trọn gói ZALO: 0909232620
 
PDF
Hệ điều hành (chương 1)
byrealpotter
 
PPT
MATMA - Chuong2
bySai Lemovom
 
PDF
Giáo trình mạng máy tính PTIT
byNguynMinh294
 
DOC
PHÂN TÍCH THIẾT KẾ HỆ THỐNG BÁN HÀNG QUA MẠNG
byThùy Linh
 
DOCX
Đề tài: Nhận dạng mặt người trên matlab, HOT, 9đ
byDịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
PDF
Báo cáo phân tích thiết kế mạng
byjackjohn45
 
PPT
Bai giang atbmtt
byHà Vũ
 
PDF
Chuẩn hóa lược đồ quan hệ
byHưởng Nguyễn
 
DOCX
[Đồ án môn học] - Đề tài: Nghiên cứu xây dựng giải pháp thu thập và quản lý ...
byÝ Như Lê
 
PPT
Thuật toán mã hóa rsa
byBảo Điệp
 
PDF
Tài liệu tổng kểt môn mạng máy tính
byJojo Kim
 
DOCX
Báo cáo xây dựng và phát triển phần mềm
byytthuan
 
DOCX
Đồ án kiểm thử phần mềm
byNguyễn Anh
 
DOCX
Báo cáo snort
byanhkhoa2222
 
PPTX
firewall
byKim Chan
 
DOCX
Kịch bản demo phát hiện xâm nhập sử dụng snort ids
byLinh Hoang
 
Giáo trình an toàn thông tin ths.nguyễn công nhật[bookbooming.com]
bybookbooming1
 
Phan tich thiet ke he thong thong tin
byNguyễn Duy Hưng
 
Đề tài: Xây Dựng Chương Trình Quản Lý Nhà Hàng Coffee SEN
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Đề tài: Tìm hiểu hệ thống phát hiện xâm nhập IDS-SNORT, 9đ
byDịch vụ viết bài trọn gói ZALO: 0909232620
 
Hệ điều hành (chương 1)
byrealpotter
 
MATMA - Chuong2
bySai Lemovom
 
Giáo trình mạng máy tính PTIT
byNguynMinh294
 
PHÂN TÍCH THIẾT KẾ HỆ THỐNG BÁN HÀNG QUA MẠNG
byThùy Linh
 
Đề tài: Nhận dạng mặt người trên matlab, HOT, 9đ
byDịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
Báo cáo phân tích thiết kế mạng
byjackjohn45
 
Bai giang atbmtt
byHà Vũ
 
Chuẩn hóa lược đồ quan hệ
byHưởng Nguyễn
 
[Đồ án môn học] - Đề tài: Nghiên cứu xây dựng giải pháp thu thập và quản lý ...
byÝ Như Lê
 
Thuật toán mã hóa rsa
byBảo Điệp
 
Tài liệu tổng kểt môn mạng máy tính
byJojo Kim
 
Báo cáo xây dựng và phát triển phần mềm
byytthuan
 
Đồ án kiểm thử phần mềm
byNguyễn Anh
 
Báo cáo snort
byanhkhoa2222
 
firewall
byKim Chan
 
Kịch bản demo phát hiện xâm nhập sử dụng snort ids
byLinh Hoang
 

Viewers also liked

PDF
Md5
bybkaa09303
 
DOC
Tìm hiểu về giao thức mạng tcp ip
byleduyk11
 
PDF
SSL Secure socket layer
byAhmed Elnaggar
 
DOCX
7. tìm hiểu hàm băm md5 và ứng dụng
bySai Lemovom
 
PPTX
Web application-security
byVisla Team
 
PPT
Introduction to Secure Sockets Layer
byNascenia IT
 
PPTX
Ssl and tls
byRana assad ali
 
PPTX
Secure Socket Layer
byAbhishek Gupta
 
PPTX
Secure Socket Layer
byPina Parmar
 
PPT
Secure Socket Layer
byNaveen Kumar
 
PDF
TLS/SSL Protocol Design 201006
byNate Lawson
 
PDF
Modern stream cipher
byHoang Nguyen
 
DOC
Datotnghiep openvpn
byThanh Nguyen
 
PPTX
Introduction to SSL/TLS
bykeithrozario
 
PDF
7222 chu ky_so_giao_thuc_chung_thuc_h39_lt_20130409025611
byletranganh
 
PDF
TLS and SSL v3 vulnerabilities
byKim Jensen
 
PDF
Cai Dat SSL tren WEB SERVER
byconglongit90
 
PPT
Ssl project it-slideshares.blogspot.com
byphanleson
 
PPTX
Cross-validation aggregation for forecasting
byDevon Barrow
 
PDF
Tìm hiểu về ssl project
byVcoi Vit
 
Md5
bybkaa09303
 
Tìm hiểu về giao thức mạng tcp ip
byleduyk11
 
SSL Secure socket layer
byAhmed Elnaggar
 
7. tìm hiểu hàm băm md5 và ứng dụng
bySai Lemovom
 
Web application-security
byVisla Team
 
Introduction to Secure Sockets Layer
byNascenia IT
 
Ssl and tls
byRana assad ali
 
Secure Socket Layer
byAbhishek Gupta
 
Secure Socket Layer
byPina Parmar
 
Secure Socket Layer
byNaveen Kumar
 
TLS/SSL Protocol Design 201006
byNate Lawson
 
Modern stream cipher
byHoang Nguyen
 
Datotnghiep openvpn
byThanh Nguyen
 
Introduction to SSL/TLS
bykeithrozario
 
7222 chu ky_so_giao_thuc_chung_thuc_h39_lt_20130409025611
byletranganh
 
TLS and SSL v3 vulnerabilities
byKim Jensen
 
Cai Dat SSL tren WEB SERVER
byconglongit90
 
Ssl project it-slideshares.blogspot.com
byphanleson
 
Cross-validation aggregation for forecasting
byDevon Barrow
 
Tìm hiểu về ssl project
byVcoi Vit
 

Similar to Giao thức bảo mật SSL

PDF
Ceh lab book_tieng_viet_phan1
byquang
 
DOC
Đề tài: Phương pháp bảo mật bằng công nghệ bức tường lửa, 9đ
byDịch vụ viết bài trọn gói ZALO 0917193864
 
PDF
giai-phap-an-ninh-trong-kien-truc-quan-tri-mang-snmp
byPham Huynh
 
PDF
BÀI GIẢNG An ninh mạng máy tính.pdf
byNuioKila
 
DOC
Nghiên cứu một số vấn đề về bảo mật ứng dụng Web trên Internet.doc
byDỊCH VỤ VIẾT ĐỀ TÀI TRỌN GÓI ZALO/ TEL: 0909.232.620
 
PDF
Lab security+ Bài 11: SSL
byxeroxk
 
PPT
Ch15
byKhôi Nguyễn Xuân
 
DOCX
Isas semina
byhoangt_ti22
 
DOC
Đồ Án Tốt Nghiệp Về Kiến Trúc Mạng Và Các Giao Thức Truyền Thông Mạng.doc
byDỊCH VỤ VIẾT ĐỀ TÀI TRỌN GÓI ZALO/ TEL: 0909.232.620
 
PDF
AntoanbaomatQQQQQQQQQ
byViet Tran
 
PDF
Tailieu.vncty.com webmail
byTrần Đức Anh
 
PDF
Bao mat ung_dung_web
byViet Nam
 
PDF
Bao mat ung_dung_web
byDuy Vọng
 
PPTX
Ssl it-slideshares.blogspot.com
byphanleson
 
DOCX
Báo cáo thực tập tốt nghiệp
bytrong1763
 
PDF
ssl1
byMít Tơ Róm
 
PDF
Ssl report
byDiodeZ
 
PDF
Part 35 certificate authority -www.key4_vip.info
bylaonap166
 
PPTX
Chương 0. GIỚI THIỆUuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu.pptx
bynpduyanh04
 
DOCX
Cau hoi an ninh internet version 3 (1)
byHiếu Hiếu
 
Ceh lab book_tieng_viet_phan1
byquang
 
Đề tài: Phương pháp bảo mật bằng công nghệ bức tường lửa, 9đ
byDịch vụ viết bài trọn gói ZALO 0917193864
 
giai-phap-an-ninh-trong-kien-truc-quan-tri-mang-snmp
byPham Huynh
 
BÀI GIẢNG An ninh mạng máy tính.pdf
byNuioKila
 
Nghiên cứu một số vấn đề về bảo mật ứng dụng Web trên Internet.doc
byDỊCH VỤ VIẾT ĐỀ TÀI TRỌN GÓI ZALO/ TEL: 0909.232.620
 
Lab security+ Bài 11: SSL
byxeroxk
 
Ch15
byKhôi Nguyễn Xuân
 
Isas semina
byhoangt_ti22
 
Đồ Án Tốt Nghiệp Về Kiến Trúc Mạng Và Các Giao Thức Truyền Thông Mạng.doc
byDỊCH VỤ VIẾT ĐỀ TÀI TRỌN GÓI ZALO/ TEL: 0909.232.620
 
AntoanbaomatQQQQQQQQQ
byViet Tran
 
Tailieu.vncty.com webmail
byTrần Đức Anh
 
Bao mat ung_dung_web
byViet Nam
 
Bao mat ung_dung_web
byDuy Vọng
 
Ssl it-slideshares.blogspot.com
byphanleson
 
Báo cáo thực tập tốt nghiệp
bytrong1763
 
ssl1
byMít Tơ Róm
 
Ssl report
byDiodeZ
 
Part 35 certificate authority -www.key4_vip.info
bylaonap166
 
Chương 0. GIỚI THIỆUuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu.pptx
bynpduyanh04
 
Cau hoi an ninh internet version 3 (1)
byHiếu Hiếu
 

More from conglongit90

PPTX
Tối ưu hóa
byconglongit90
 
PPT
Php03 php trong-laptrinhwebdong
byconglongit90
 
PPT
Php01 tong quan
byconglongit90
 
PPT
Php04 ph pva-mysql
byconglongit90
 
PPT
Php05 xay dungungdung
byconglongit90
 
PPT
Php02 ngon nguphp
byconglongit90
 
Tối ưu hóa
byconglongit90
 
Php03 php trong-laptrinhwebdong
byconglongit90
 
Php01 tong quan
byconglongit90
 
Php04 ph pva-mysql
byconglongit90
 
Php05 xay dungungdung
byconglongit90
 
Php02 ngon nguphp
byconglongit90
 

Recently uploaded

PDF
10 CHUYÊN ĐỀ TRỌNG TÂM NÂNG CAO HÓA HỌC LỚP 12 ÔN THI HỌC SINH GIỎI THEO FORM...
byNguyen Thanh Tu Collection
 
PDF
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TÌM HIỂU THẾ GIỚI TỰ NHIÊN DƯỚI GÓC ĐỘ VẬT LÍ C...
byNguyen Thanh Tu Collection
 
PPTX
lupus ban đỏ hệ thống, bài giảng sau đại học
bysitran8
 
PPTX
bài thuyết trình địa lý về vịnh hạ long.pptx
byAnhTh387267
 
PPTX
THOÁI HÓA KHỚP- SAU ĐAI HỌC- CHUYÊN ĐÊ CHUYÊN KHOA
bysitran8
 
PPTX
CHƯƠNG 2 TRIẾT HỌC MÁC LÊ NINNNNNNNNNNNN
bykhoaonichan1102
 
PDF
GIÁO ÁN KẾ HOẠCH BÀI DẠY HÓA HỌC 12 - CẢ NĂM - CHÂN TRỜI SÁNG TẠO THEO CÔNG V...
byNguyen Thanh Tu Collection
 
PPTX
Bài tập thiết kế trang âm khán phòng - Môn âm học kiến trúc
bySolidusBriseSoleil
 
PDF
Dược lý học bài thuốc điều trị sốt zéthmtu
bykhanhvu215206
 
PPT
2.Bai 2_Keo nen dung tam_14.9.2025 434325325.ppt
bydoantrungboc
 
PDF
10 CHUYÊN ĐỀ TRỌNG TÂM NÂNG CAO HÓA HỌC LỚP 12 ÔN THI HỌC SINH GIỎI THEO FORM...
byNguyen Thanh Tu Collection
 
PPTX
Hướng dẫn sử dụng - Người hướng dẫn.pptx
byssuserc70ba6
 
PDF
Lớp 7A10 - Bài thi An toàn giao thông cho nụ cười ngày mai.pdf
byQucHHunhnh
 
DOCX
LỊCH CÔNG TÁC TUẦN 15 (Từ ngày 15/12/2025 đến 21/12/2025)
byQucHHunhnh
 
DOCX
LỊCH CÔNG TÁC TUẦN 15 (Từ ngày 15/12/2025 đến 21/12/2025)
byQucHHunhnh
 
PDF
Đề ôn thi VNMF lớp 2 chặng 3 cấp Trường năm 2025 - 2026
byBồi Dưỡng HSG Toán Lớp 3
 
PDF
Đề ôn thi VNMF lớp 1 chặng 3 cấp Trường năm 2025 - 2026
byBồi Dưỡng HSG Toán Lớp 3
 
PDF
Đề ôn thi VNMF lớp 4 chặng 3 cấp Trường năm 2025 - 2026
byBồi Dưỡng HSG Toán Lớp 3
 
DOCX
Giáo dục STEM trong dạy học cấp tiểu học trên môi trường số
bylamluanvan.net Viết thuê luận văn
 
10 CHUYÊN ĐỀ TRỌNG TÂM NÂNG CAO HÓA HỌC LỚP 12 ÔN THI HỌC SINH GIỎI THEO FORM...
byNguyen Thanh Tu Collection
 
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TÌM HIỂU THẾ GIỚI TỰ NHIÊN DƯỚI GÓC ĐỘ VẬT LÍ C...
byNguyen Thanh Tu Collection
 
lupus ban đỏ hệ thống, bài giảng sau đại học
bysitran8
 
bài thuyết trình địa lý về vịnh hạ long.pptx
byAnhTh387267
 
THOÁI HÓA KHỚP- SAU ĐAI HỌC- CHUYÊN ĐÊ CHUYÊN KHOA
bysitran8
 
CHƯƠNG 2 TRIẾT HỌC MÁC LÊ NINNNNNNNNNNNN
bykhoaonichan1102
 
GIÁO ÁN KẾ HOẠCH BÀI DẠY HÓA HỌC 12 - CẢ NĂM - CHÂN TRỜI SÁNG TẠO THEO CÔNG V...
byNguyen Thanh Tu Collection
 
Bài tập thiết kế trang âm khán phòng - Môn âm học kiến trúc
bySolidusBriseSoleil
 
Dược lý học bài thuốc điều trị sốt zéthmtu
bykhanhvu215206
 
2.Bai 2_Keo nen dung tam_14.9.2025 434325325.ppt
bydoantrungboc
 
10 CHUYÊN ĐỀ TRỌNG TÂM NÂNG CAO HÓA HỌC LỚP 12 ÔN THI HỌC SINH GIỎI THEO FORM...
byNguyen Thanh Tu Collection
 
Hướng dẫn sử dụng - Người hướng dẫn.pptx
byssuserc70ba6
 
Lớp 7A10 - Bài thi An toàn giao thông cho nụ cười ngày mai.pdf
byQucHHunhnh
 
LỊCH CÔNG TÁC TUẦN 15 (Từ ngày 15/12/2025 đến 21/12/2025)
byQucHHunhnh
 
LỊCH CÔNG TÁC TUẦN 15 (Từ ngày 15/12/2025 đến 21/12/2025)
byQucHHunhnh
 
Đề ôn thi VNMF lớp 2 chặng 3 cấp Trường năm 2025 - 2026
byBồi Dưỡng HSG Toán Lớp 3
 
Đề ôn thi VNMF lớp 1 chặng 3 cấp Trường năm 2025 - 2026
byBồi Dưỡng HSG Toán Lớp 3
 
Đề ôn thi VNMF lớp 4 chặng 3 cấp Trường năm 2025 - 2026
byBồi Dưỡng HSG Toán Lớp 3
 
Giáo dục STEM trong dạy học cấp tiểu học trên môi trường số
bylamluanvan.net Viết thuê luận văn
 

Giao thức bảo mật SSL

  • 1.
    HỌC VIỆN CÔNGNGHỆ BƯU CHÍNH VIỄN THÔNG TPHCM KHOA CÔNG NGHỆ THÔNG TIN II  ĐỀ TÀI MÔN BẢO MẬT THÔNG TIN Giáo viên hướng dẫn : Ths.Lê Phúc Sinh viên thực hiện : Huỳnh Anh Hào Võ Thị Thu Nguyệt Lê Thanh Phong Nguyễn Thị Thanh Thảo Thành phố Hồ Chí Minh 12/2009
  • 2.
    PTIT 2009 Đề tài môn Bảo mật thông tin MỤC LỤC Giới Thiệu CHƢƠNG I : SECURE SOCKET LAYER & TRANSPORT LAYER SECURITY ........................................... 5 I.1 Tại sao sử dụng SSL ............................................................................................................................................ 5 I.2 Kiến trúc SSL....................................................................................................................................................... 9 I.3 Giao thức SSL Record ....................................................................................................................................... 10 I.4 Giao thức SSL Change Cipher Spec .................................................................................................................. 13 I.5 Giao thức SSL Alert........................................................................................................................................... 13 I.6 Giao thức SSL Handshake ................................................................................................................................. 15 I.6.1 Giai đoạn 1 : Thiết lập khả năng bảo mật .............................................................................................. 16 I.6.2 Giai đoạn 2 : Xác thực server và trao đổi khóa...................................................................................... 18 I.6.3 Giai đoạn 3 : Xác thực client và trao đổi khóa ...................................................................................... 19 I.6.4 Giai đoạn 4 : Kết thúc ............................................................................................................................ 19 I.7 Tính toán mã hóa ............................................................................................................................................... 20 I.7.1 Việc tạo Master Secret ........................................................................................................................... 20 I.7.2 Việc sinh các tham số mã hóa ................................................................................................................ 21 I.8 Transport Layer Security ................................................................................................................................... 22 I.8.1 Version number ..................................................................................................................................... 22 I.8.2 Message Authentication Code ............................................................................................................... 22 I.8.3 Hàm tính số ngẫu nhiên ......................................................................................................................... 23 I.8.4 Mã cảnh báo........................................................................................................................................... 24 I.8.5 Cipher suite ............................................................................................................................................ 25 I.8.6 Các dạng client certificate ..................................................................................................................... 25 I.8.7 Certificate Verify và Finished Message................................................................................................. 26 I.8.8 Tính toán mã hóa ................................................................................................................................... 26 I.8.9 Phần đệm ............................................................................................................................................... 26 CHƢƠNG II : JAVA SECURE SOCKET EXTENSION API ............................................................................. 27 II.1 Quan hệ giữa các Class ..................................................................................................................................... 27 II.2 Các Class và Interface chính ............................................................................................................................. 28 II.2.1 Lớp SocketFactory và ServerSocketFactory ........................................................................................ 28 II.2.2 Lớp SSLSocketFactory và SSLServerSocketFactory .......................................................................... 28 II.2.3 Lớp SSLSocket và SSLServerSocket ................................................................................................... 29 Secure Socket Layer 2
  • 3.
    PTIT 2009 Đề tài môn Bảo mật thông tin II.2.4 Non-blocking I/O với SSLEngine ........................................................................................................ 30 II.2.5 Quá trình khởi động.............................................................................................................................. 31 II.2.6 Phát sinh và xử lý dữ liệu SSL/TLS ..................................................................................................... 32 II.2.7 Trạng thái hoạt động............................................................................................................................. 34 II.2.8 Blocking Tasks ..................................................................................................................................... 35 II.2.9 Kết thúc ................................................................................................................................................ 35 II.2.10 SSLSession Interface .......................................................................................................................... 36 II.2.11 Lớp HttpsURLConnection ................................................................................................................. 36 II.3 Các Class và Interface hỗ trợ ............................................................................................................................ 37 II.3.1 Lớp SSLContext ................................................................................................................................... 38 II.3.2 TrustManager Interface ........................................................................................................................ 39 II.3.3 Lớp TrustManagerFactory.................................................................................................................... 39 II.3.4 X509TrustManager Interface ............................................................................................................... 42 II.3.5 KeyManager Interface .......................................................................................................................... 44 II.3.6 Lớp KeyManagerFactory ..................................................................................................................... 45 II.3.7 X509KeyManager Interface ................................................................................................................. 46 II.3.8 Mối liên hệ TrustManagers và KeyManagers ..................................................................................... 46 II.4 Các Class và Interface hỗ trợ thứ cấp................................................................................................................ 47 II.4.1 SSLSessionContext Interface ............................................................................................................... 47 II.4.2 SSLSessionBindingListener Interface .................................................................................................. 47 II.4.3 Lớp SSLSessionBindingEvent ............................................................................................................. 47 II.4.4 HandShakeCompletedListener Interface .............................................................................................. 47 II.4.5 Lớp SSLHandShakeCompletedEvent .................................................................................................. 47 II.4.6 HostnameVerifier Interface .................................................................................................................. 47 II.4.7 Lớp X509Certificate ............................................................................................................................. 48 CHƢƠNG III : SSL ATTACK ................................................................................................................................ 49 III.1 Các phương pháp tấn công SSL dựa trên kỹ thuật tấn công MITM ................................................................ 49 III.1.1 Diffie Hellman MITM Attack ............................................................................................................. 49 III.1.2 SSL Sniff & SSLSTrip MITM Attack ................................................................................................ 46 III.2 Demo tấn công SSL Strip ................................................................................................................................ 51 CHƢƠNG IV : SSL CAPABILITY ........................................................................................................................ 52 IV.1 Các ứng dụng phổ biến của SSL ..................................................................................................................... 52 IV.2 Triển khai SSL ................................................................................................................................................ 54 Tham khảo Secure Socket Layer 3
  • 4.
    PTIT 2009 Đề tài môn Bảo mật thông tin Giới thiệu : Mục tiêu thực hiện đề tài này của những thành viên tham gia là đi sâu tìm hiểu về :  Cấu trúc cũng như cơ chế hoạt động của SSL.  Lập trình xây dựng một web server chạy SSL.  Cách thức tấn công một phiên giao dịch SSL.  Khả năng ứng dụng SSL trong bảo mật thông tin. Đây là lần đầu thực hiện một đề tài lớn nên còn nhiều thiếu sót , mong Thầy và các bạn đóng góp ý kiến để đề tài được hoàn thiện hơn. Chúng em xin cảm ơn sự hướng dẫn nhiệt tình của Thầy Ths.Lê Phúc đã giúp chúng em hoàn thành đề tài này. Secure Socket Layer 4
  • 5.
    PTIT 2009 Đề tài môn Bảo mật thông tin Chương I : I.1 Tại sao sử dụng SSL : Ngày nay việc bảo mật thông tin là yếu tố quan trọng để quyết định sự sống còn của một tổ chức ,một công ty hay doanh nghiệp . Với sự phát triển nhanh chóng của công nghệ đã mang lại nhiều tiện ích cho người dùng nhưng đồng thời cũng đặt ra một nhu cầu hết sức cấp thiết về sự an toàn và bảo mật .Và SSL chính là giải pháp tốt nhất hiện nay đáp ứng những nhu cầu đó và nó được coi như là “lá chắn cuối cùng” trong bảo mật thương mại điện tử. Giao thức SSL ban đầu được phát triển bởi Netscape.Version 1.0 thì đã không bao giờ được công bố rộng rãi.Version 2.0 được công bố vào tháng 2/1995 nhưng chứa nhiều lỗ hỏng bảo mật và sau cùng đưa đến mô hình SSL version 3.0 được ban hành năm 1996.Bản sau cùng này được dùng cho TLS version 1.0 và được IETF xác định như một giao thức chuẩn trong RFC 2246 vào tháng 1/1999. Ngày nay Visa, MasterCard, American Express cũng như nhiều công ty giải pháp tài chính hàng đầu khác trên thế giới đã và đang ứng dụng SSL trong thương mại điện tử. Việc truyền các thông tin nhạy cảm trên mạng rất không an toàn vì những vấn đề sau: Bạn không thể luôn luôn chắc rằng bạn đang trao đổi thông tin với đúng đối tượng cần trao đổi. Dữ liệu mạng có thể bị chặn ,vì vậy dữ liệu có thể bị 1 đối tượng thứ 3 khác đọc trộm, thường được biết đến như attacker . Nếu attacker có thể chặn dữ liệu, attacker có thể sửa đổi dữ liệu trước khi gửi nó đến người nhận. SSL giải quyết các vấn đề trên.SSL giải quyết vấn đề đầu tiên bằng cách cho phép 1 cách tùy chọn mỗi bên trao đổi có thể chắc chắn về định danh của phía đối tác trong 1 quá trình gọi là authentication (xác thực).Một khi các bên đã được xác thực,SSL cung cấp 1 kết nối được mã hóa giữa 2 bên để truyền bảo mật các message .Việc mã hóa trong quá trình trao đổi thông tin giữa 2 bên cung cấp sự riêng tư bí mật,vì vậy mà giải quyết được vấn đề thứ 2.Thuật toán mã hóa được sử dụng với SSL bao gồm hàm băm mã hóa,tương tự như 1 checksum.Nó đảm bảo rằng dữ liệu không bị thay đổi trong quá trình truyền dẫn.Hàm băm mã hóa giải quyết vấn đề thứ 3,tính toàn vẹn dữ liệu. Chú ý rằng,cả xác thực và mã hóa đều là tùy chọn, và phụ thuộc vào cipher suites (các bộ mã hóa) được đàm phán giữa 2 đối tượng. Một ví dụ rõ ràng nhất mà trong đó bạn nên sử dụng SSL là trao đổi thông tin giao dịch qua mạng (e- commerce).Trong trao đổi e-commerce,thật dại dột khi giả định rằng bạn có thể chắc chắn về định danh của server mà bạn đang trao đổi thông tin.Ai đó có thể dễ dàng tạo ra 1 Website giả hứa hẹn các dịch vụ tuyệt vời ,chỉ để cho bạn nhập vào đó số tài khoản.SSL cho phép bạn, client,xác thực về định danh của server.Nó cũng cho phép server xác thực định danh của client,mặc dù trong các giao tác Internet,việc này hiếm khi được làm. Secure Socket Layer 5
  • 6.
    PTIT 2009 Đề tài môn Bảo mật thông tin Một khi client và server đã hài lòng với định danh của mỗi bên đối tác.SSL cung cấp tính bảo mật và tính toàn vẹn thông qua các thuật toán mã hóa mà nó sử dụng.Điều này cho phép các thông tin nhạy cảm,như số tài khoản,được truyền đi 1 cách an toàn trên Internet. Trong khi SSL cung cấp tính xác thực,tính bảo mật và toàn vẹn dự liệu,nó không cung cấp non-repudiation (tính không từ chối).Non-repudiation có nghĩa là khi 1 đối tượng gửi đi 1 message ,thì sau đó không thể phủ nhận việc mình đã gửi message đó.Khi 1 chữ kí số tương đương được liên kết với 1 message,việc trao đổi này sau đó có thể được chứng minh.SSL 1 mình nó không cung cấp non-repudiation. Tiến trình SSL: Việc trao đổi trên mạng sử dụng SSL bắt đầu với việc trao đổi thông tin qua lại giữa client và server.Sự trao đổi thông tin này gọi là SSL handshake. Ba mục tiêu chính của SSL handshake là: Đàm phán cipher suite. Xác thực định danh (tùy chọn). Hình thành cơ chế bảo mật thông tin, bằng cách thỏa thuận các cơ chế mã hóa. Đàm phán Cipher suite : Một phiên SSL bắt đầu với việc đàm phán giữa client và server xem cipher suite nào mà chúng sẽ sử dùng.Một cipher suite là 1 tập các thuật toán mã hóa và kích thước khóa mà máy tính có thể dùng để mã hóa dữ liệu.Một cipher suite bao gồm thông tin về các thuật toán trao đổi khóa công khai và các thuật toán thỏa thuận khóa,và các hàm băm mã hóa.Client nói với server các cipher suite nào nó có sẵn và server lựa chọn cipher suite tốt nhất có thể chấp nhận. Xác thực server : Trong SSL,bước xác thực là tùy chọn,nhưng trong ví dụ về giao tác e-commerce trên Web, client theo thông thường sẽ muốn xác thực server.Việc xác thực server cho phép client chắc chắn rằng chính server này đại diện cho đối tượng mà client tin tưởng. Để chứng minh server thuộc về tổ chức mà nó khẳng định là nó đại diện,server phải trình chứng chỉ khóa công khai của nó cho client.Nếu chứng chỉ này là hợp lệ ,client có thể chắc chắn về định danh của server. Thông tin trao đổi qua lại giữa client và server cho phép chúng thỏa thuận 1 khóa bí mật chung.Ví dụ,với RSA,client dùng khóa công khai của server,có được từ chứng chỉ khóa công khai, để mã hóa thông tin khóa bí mật.Client gửi thông tin khóa bí mật đã được mã hóa đến server.Chỉ có server mới có thể giải mã cái message này bởi vì quá trình giải mã phải cần đến khóa riêng của server. Gửi dữ liệu đã mã hóa: Bây giờ,cả client và server có thể truy cập đến khóa bí mật chung.Với mỗi message ,chúng dùng đến hàm băm mã hóa,đã được chọn trong bước thứ nhất của tiến trình này,và chia sẻ thông tin bí mật,để tính toán 1 HMAC nối thêm vào message.Sau đó,chúng dùng khóa bí mật và thuật toán khóa bí mật đã được đàm phán ở bước đầu tiên của tiến trình này để mã hóa dữ liệu và HMAC an toàn.Client và server giờ đây có thể trao đổi thông tin với nhau 1 cách an toàn với các dữ liệu đã băm và mã hóa. Giao thức SSL: Secure Socket Layer 6
  • 7.
    PTIT 2009 Đề tài môn Bảo mật thông tin Phần trước cung cấp sự mô tả sơ lược về SSL handshake, là sự trao đổi thông tin giữa client và server trước khi gửi các message đã được mã hóa.Phần này mô tả chi tiết hơn.Hình sau minh họa chuỗi tuần tự các message được trao đổi trong SSL handshake.Các message mà chỉ được gửi trong 1 trường hợp nào đó được đánh dấu là tùy chọn. Hình II: Các message SSL Client Server 1.Client hello 2.Server hello 3.Certificate tùy chọn 4.Certificate request tùy chọn 5.Server key exchange tùy chọn 6.Server hello done 7.Certificate tùy chọn 8.Client key exchange 9.Certificate verify tùy chọn 10.Change cipher spec 11.Finish 12.Change cipher spec 13.Finished 14.Encrypted data 14.Encrypted data 15.Close messages 15.Close message Các message SSL được gửi theo thứ tự sau: 1) Client hello: client gửi đến server các thông tin bao gồm phiên bản SSL cao nhất và 1 danh sách các cipher suite mà nó hỗ trợ. (TLS 1.0 được chỉ ra như là SSL3.1).Thông tin cipher suite bao gồm các thuật toán mã hóa và kích thước khóa. 2) Server hello: server chọn ra phiên bản SSL cao nhất và cipher suite tốt nhất mà cả client và server hỗ trợ, và gửi thông tin này về cho client. 3) Certificate: server gửi cho client 1 chứng chỉ hoặc 1 chuỗi chứng chỉ.Về cơ bản,1 chuỗi chứng chỉ bắt đầu bằng chứng chỉ khóa công khai của server và kết thúc bằng chứng chỉ gốc của tổ chức có thẩm quyền chứng chỉ.Message này là tùy chọn,nhưng nó được dùng bất cứ khi nào xác thực server là cần thiết. 4) Certificate request: nếu server cần xác thực client,nó gửi cho client 1 yêu cầu xem chứng chỉ.Trong các ứng dụng internet,message này hiếm khi được gửi đi. Secure Socket Layer 7
  • 8.
    PTIT 2009 Đề tài môn Bảo mật thông tin 5) Server key exchange: server gửi cho client 1 message trao đổi khóa server trong khi khóa công khai được gửi ở phần 3) bên trên thì không đủ cho trao đổi khóa. 6) Server hello done: server nói với client rằng nó hoàn thành các message đàm phán ban đầu. 7) Certificate: nếu server cần chứng chỉ từ client trong message 4, client gửi chuỗi chứng chỉ của nó,cũng giống như server làm trong message 3. 8) Client key exchange: client sinh ra thông tin được dùng để tạo ra khóa trong mã hóa đối xứng.Với RSA, client mã hóa thông tin khóa này bằng khóa công khai của server rồi gửi nó đến server. 9) Certificate verify: message này được gửi khi client trình ra chứng chỉ như trên.Mục tiêu của nó là cho phép server hoàn thành tiến trình xác thực client.Khi message này được dùng,client gửi thông tin với chữ kí số tạo bằng hàm băm mã hóa.Khi server giải mã thông tin này bằng khóa công khai của client,server có thể xác thực client. 10) Change cipher spec: client gửi message bảo server thay đổi kiểu mã hóa. 11) Finished: client nói với server rằng nó sẵn sàng để bắt đầu trao đổi dữ liệu an toàn. 12) Change cipher spec: server gửi message bảo client thay đổi kiểu mã hóa. 13) Finished: server nói với client rằng nó sẵn sàng để bắt đầu trao đổi dữ liệu an toàn.Kết thúc SSL handshake. 14) Encrypted data: client và server trao đổi với nhau,sử dụng thuật toán mã hóa đối xứng và hàm băm mã hóa đã đàm phán ở message 1 và 2,và dùng khóa bí mật mà client gửi cho server trong message 8. 15) Closed messages : Kết thúc 1kết nối,mỗi bên gửi 1 message close-notify để thông báo đầu kia biết kết nối bị đóng. Nếu các tham số được sinh ra trong 1 phiên SSL được lưu lại,các tham số này có thể thỉnh thoảng được dùng lại cho các phiên SSL sau.Việc lưu lại các tham số phiên SSL cho phép các trao đổi bảo mật về sau được bắt đầu nhanh chóng hơn. Lựa chọn Cipher suite và xóa Entity verification: Giao thức SSL/TLS định nghĩa 1 chuỗi các bước đặc biệt để bảo đảm 1 kết nối “được bảo vệ”.Tuy nhiên,việc lựa chọn Cipher suite sẽ tác động trực tiếp đến loại bảo mật mà kết nối có được.Ví dụ,nếu 1 cipher suite nặc danh được chọn,ứng dụng không có cách nào để kiểm tra định danh của đầu xa.Nếu 1 suite-không có mã hóa, được chọn,tính bí mật của dữ liệu không thể được bảo vệ.Thêm vào đó,giao thức SSL/TLS không chỉ rõ rằng những tài liệu chứng nhận nhận được phải khớp với những cái mà đầu kia gửi.Nếu kết nối theo cách nào đó mà bị redirect đến 1 kẻ xấu,nhưng tài liệu chứng nhận của kẻ xấu này khi trình ra thì được chấp nhận dựa trên những tư liệu tin tưởng hiện tại,kết nối này sẽ được xét là hợp lệ. Khi dùng SSLSockets/SSLEngines,nên luôn luôn kiểm tra tài liệu chứng nhận của đầu xa trước khi gửi bất kì dữ liệu nào.Các lớp SSLSockets và SSLEngines không tự động kiểm tra hostname trong URL có khớp với hostname trong tài liệu chứng nhận của đầu kia hay không.Một ứng dụng có thể bị khai thác bằng URL spoofing nếu hostname không được kiểm tra. Các giao thức như HTTPS cần thiết phải kiểm tra hostname.Các ứng dụng có thể dùng HostnameVerifier để viết chồng lên luật hostname HTTPS mặc định . Secure Socket Layer 8
  • 9.
    PTIT 2009 Đề tài môn Bảo mật thông tin I.2 Kiến trúc SSL : SSL được thiết kế để dùng TCP cung cấp 1 dịch vụ bảo mật đầu cuối-đến-đầu cuối đáng tin cậy.SSL không phải là một giao thức đơn mà là 2 lớp giao thức,như minh họa dưới đây. Hình I.1 : Chồng giao thức SSL SSL Handshake SSL Change Cypher SSL Alert Protocol HTTP Protocol Spec Protocol SSL Record Protocol TCP IP SSL Record Protocol cung cấp các dịch vụ bảo mật cơ bản cho nhiều giao thức khác nhau ở các lớp trên.Trong thực tế, Hyper Text Transfer Protocol (HTTP),cung cấp dịch vụ trao đổi cho tương tác Web client/server,có thể hoạt động trên đỉnh của SSL.Ba giao thức lớp trên được định nghĩa như là các phần của SSL: Handshake Protocol, Change Cypher Spec Protocol và Alert Protocol.Các giao thức mang tính đặc trưng-SSL này được dùng trong phần quản lý trao đổi SSL và được xét đến trong phần sau. Hai khái niệm SSL quan trọng là SSL session (phiên SSL) và SSL connection ( kết nối SSL) ,được định nghĩa như sau: Connection ( kết nối): 1 kết nối là 1 transport _ trong định nghĩa mô hình phân lớp OSI_ cung cấp 1 loại dịch vụ thích hợp.Với SSL,những kết nối như vậy là những mối quan hệ ngang hàng.Các kết nối thì trao đổi nhanh chóng.Mỗi kết nối gắn với 1 phiên. Session (phiên): 1 phiên SSL là 1 liên kết giữa 1 client và 1 server.Các phiên được tạo ra bằng Handshake Protocol (giao thức bắt tay).Các phiên định nghĩa 1 tập các tham số bảo mật bằng mật mã,có thể được chia sẻ giữa nhiều kết nối.Các phiên được dùng để tránh những đàm phán tốn kém_về các tham số bảo mật mới_cho mỗi kết nối. Giữa bất kì 1 cặp của nhóm nào (các ứng dụng như HTTP trên client hay server),có thể có nhiều kết nối bảo mật .Về lý thuyết ,có thể có nhiều phiên đồng thời giữa các nhóm,nhưng đặc trưng này không được dùng trong thực tiễn. Thực sự có nhiều trạng thái gắn với mỗi phiên.Một khi 1 phiên được thành lập,có trạng thái hoạt động hiện thời cho cả đọc và ghi, (như nhận và gửi..).Thêm vào đó, trong suốt quá trình Handshake Protocol, trạng thái treo đọc và ghi được tạo ra.Dựa trên kết luận thành công của Handshake Protocol,các trạng thái treo trở thành trạng thái hiện thời. -Một trạng thái phiên được định nghĩa bởi các thông số sau (các định nghĩa lấy từ đặc trưng SSL): Session Identifier : 1 chuỗi byte bất kì được chọn bởi server để nhận dạng trạng thái phiên là hoạt động (active) hay phục hồi lại (resumable). Peer certificate: một chứng chỉ X509.v3.Thành phần này của trạng thái có thể là null. Compression method: thuật toán được dùng để nén dữ liệu trước khi mã hóa. Secure Socket Layer 9
  • 10.
    PTIT 2009 Đề tài môn Bảo mật thông tin Cypher spec : chỉ ra thuật toán mã hóa dữ liệu (như rỗng,AES…) và thuật toán băm (như MD5 hay SHA- 1) sử dụng để tính toán MAC.Nó cũng định nghĩa các thuộc tính mã hóa như hash-size. Master secret : 48 byte bí mật được chia sẻ giữa client và server. Is resumable : một cờ chỉ ra rằng phiên này có thể được dùng để khởi tạo các kết nối khác hay không. -Một trạng thái kết nối được định nghĩa bởi các tham số sau: Server and client random: các chuỗi byte được chọn bởi server và client cho mỗi kết nối. Server write MAC secret: khóa bí mật được sử dụng bởi phép tính MAC trên dữ liệu, được gửi bởi server. Client write MAC secret: khóa bí mật được sử dụng bởi phép tính MAC trên dữ liệu,được gửi bởi client. Server write key: khóa mã hóa quy ước cho dữ liệu được mã hóa bởi server và giải mã bởi client. Client write key :khóa mã hóa quy ước cho dữ liệu được mã hóa bởi client và giải mã bởi server. Initialization vectors: khi 1 khối mã trong mode CBC được dùng, một vector khởi tạo (IV) được duy trì cho mỗi key.Phần này được khởi tạo trước tiên bởi SSL Handshake Protocol.Sau đó,khối mã hóa cuối cùng từ mỗi record được để dành lại để dùng làm IV cho record sau . Sequence number : mỗi bên duy trì các sequence number riêng cho mỗi message được truyền hoặc được nhận trong mỗi kết nối.Khi 1 bên gửi hoặc nhận một change cypher spec message,sequence number thích hợp được thiết lập về 0.Sequence number không thể vượt quá 264-1. I.3 Giao thức SSL Record : SSL Record Protocol cung cấp 2 dịch vụ cho kết nối SSL: Confidentiality (tính cẩn mật): Handshake Protocol định nghĩa 1 khóa bí mật được chia sẻ, khóa này được sử dụng cho mã hóa quy ước các dữ liệu SSL. Message integrity (tính toàn vẹn thông điệp):Handshake Protocol cũng định nghĩa 1 khóa bí mật được chia sẻ, khóa này được sử dụng để hình thành MAC (mã xác thực message). Hình sau chỉ ra toàn bộ hoạt động của SSL Record Protocol.SSL Record Protocol nhận 1 message ứng dụng sắp được truyền đi,phân mảnh dữ liệu thành nhiều block,nén dữ liệu 1 cách tùy chọn,áp dụng vào 1 MAC,mã hóa,thêm vào header,và truyền khối kết quả thu được trong 1 segment TCP.Dữ liệu nhận được được giải mã,kiểm tra ,giải nén,sắp xếp lại và phân phối đến người sử dụng ở lớp cao hơn. Secure Socket Layer 10
  • 11.
    PTIT 2009 Đề tài môn Bảo mật thông tin Hình I.2 : Hoạt động của SSL Record Protocol Dữ liệu ứng dụng: Phân mảnh: Nén: Thêm MAC: Mã hóa: Gắn SSL Record header: 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 đến1 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. Secure Socket Layer 11
  • 12.
    PTIT 2009 Đề tài môn Bảo mật thông tin  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.  SSLCompressed.fragment: phân mảnh đã được nén (nếu nén không được dùng, 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 AES 128,256 RC4-40 40 IDEA 128 RC4-128 128 RC2-40 40 DES-40 40 DES 56 3DES 168 Fortezza 80 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: Content Type (8 bit): giao thức lớp trên được dùng để xử lí phân mảnh đi kèm. 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. 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. 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. 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. Secure Socket Layer 12
  • 13.
    PTIT 2009 Đề tài môn Bảo mật thông tin Hình sau minh họa định dạng SSL record. I.4 Giao thức SSL Change Cipher Spec : Giao thức SSL Change Cipher Spec là giao thức đơn giản nhất trong ba giao thức đặc trưng của SSL mà sử dụng giao thức SSL Record . Giao thức này bao gồm một message đơn 1 byte giá trị là 1. Mục đích chính của message này là sinh ra trạng thái tiếp theo để gán vào trạng thái hiện tại,và trạng thái hiện tại cập nhật lại bộ mã hóa để sử dụng trên kết nối này. I.5 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. Secure Socket Layer 13
  • 14.
    PTIT 2009 Đề tài môn Bảo mật thông tin 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. Secure Socket Layer 14
  • 15.
    PTIT 2009 Đề tài môn Bảo mật thông tin I.6 Giao thức SSL Handshake : Phần „khó nuốt‟ 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 Hình I.5a Hình I.5a 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 Server_hello version, random, session id, cipher suite, compression method 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 I.5b 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ó bốn giai đoạn. Secure Socket Layer 15
  • 16.
    PTIT 2009 Đề tài môn Bảo mật thông tin Hình I.5b Cơ chế giao thức SSL Handshake I.6.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 và sử dụng suốt quá trình trao đổi khóa để ngăn tấn công lập lại. Secure Socket Layer 16
  • 17.
    PTIT 2009 Đề tài môn Bảo mật thông tin 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óa „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ý. Certificate được sử dụng để xác thực khóa công khai. Điều này như là sự bảo đảm nhất của ba lựa chọn Diffie-Hellman bởi vì nó là kết quả của sự tạm thời và khóa xác thực. Anonymous Diffie-Hellman: thuật toán Diffie-Hellman cơ bản được sử dụng, không chứng thực.Nghĩa là mỗi lần một bên gửi thông số Diffie-Hellman công khai của nó cho bên kia thì không xác thực.Điều này gần như là có thể bị tấn công bởi tấn công Man-in-the-middle ,trong đó kẻ tấn công điều khiển cả nhóm anonymous Diffie-Hellman. Fortezza: phương pháp định nghĩa cho lược đồ Fortezza. Định nghĩa kèm theo cho một phương pháp trao đổi khóa là CipherSpec , bao gồm những trường sau : CipherAlgorithm: một vài thuật toán kể đến : RC4, RC2, DES, 3DES, DES40, IDEA, Fortezza. MACAlgorithm: MD5 hoặc SHA-1. CipherType: luồng hoặc khối. Secure Socket Layer 17
  • 18.
    PTIT 2009 Đề tài môn Bảo mật thông tin IsExportable: True hoặc False. HashSize: 0, 16 (cho MD5), hay 20 (cho SHA-1) bytes. Key Material: thứ tự của các bytes mà chứa dữ liệu được dùng trong sinh khóa . IV Size: kích thước của giá trị khởi tạo cho mã hóa Cipher Block Chaining (CBC). I.6.2 Giai đoạn 2 – Xác thực server và trao đổi khóa : Server bắt đầu giai đoạn này bằng cách gửi certificate của nó nếu nó cần được xác thực; thông điệp chứa một hoặc một chuỗi certificate(chứng thực) X.509. Thông điệp chứng thực được yêu cầu cho bất kì một phương pháp trao đổi khóa nào được thỏa thuận, ngoại trừ anonymous Diffie-Hellman.Chú ý rằng nếu fixed Diffie-Hellman được dùng,thì thông điệp chứng thực có chức năng như là thông điệp trao đổi khóa của server vì nó chứa các tham số Diffie-Hellman công khai của server. Sau đó một thông điệp server_key_exchange được gửi đi nếu nó được yêu cầu.Nó không được yêu cầu trong 2 trường hợp sau:  (1) Server đã gửi một certificate với các tham số fixed Diffie-Hellman.  (2) Trao đổi khoá RSA được dùng. Thông điệp server_key_exchange cần cho các trường hợp sau: - Anonymous Diffie-Hellman : Nội dung thông điệp bao gồm hai giá trị Diffie-Hellman toàn cục(một số nguyên tố và một số nguyên tố cùng nhau với số đó) cùng với khóa Diffie- Hellman của server. - Ephemeral Diffie-Hellman : nội dung thông điệp bao gồm 3 tham số Diffie-Hellman cung cấp cho anonymous Diffie-Hellman,cùng với một chữ kí của các tham số này. - Trao đổi khóa RSA,mà theo đó server sử dụng RSA nhưng có một khóa chữ kí chỉ của RSA. Theo đó,client không thể gửi đi cách đơn giản một khóa bí mật được mã hóa với khóa công khai/bí mật RSA phụ và sử dụng thông điệp server_key_exchanged để gửi khóa công khai.Nội dung thông điệp bao gồm hai tham số của khóa công khai RSA phụ(số mũ và số dư) cùng với một chữ ký của các tham số này. - Fortezza: một vài chi tiết thêm về chữ kí được đảm bảo. Như thường lệ,một chữ kí được tạo ra bởi việc lấy mã băm của một thông điệp và mã hóa nó với khóa bí mật của bên gửi. Trong trường hợp này mã băm được định nghĩa: Hash (ClientHello.random||ServerHello.random||ServerParams) Vì vậy mã băm bao gồm không chỉ các thông số Diffie-Hellman hay RSA,mà còn có hai số ngẫu nhiên từ thông điệp hello khởi tạo.Điều này đảm bảo chống lại tấn công replay và misrepresentation(giả dạng).Trong trường hợp chữ kí DSS,mã băm được biểu diễn sử dụng giải thuật SHA-1. Trong trường hợp chữ kí RSA,cả mã băm MD5 và SHA-1 đều được tính toán, và sự nối nhau của hai mã băm(36 byte) được mã hoá với khóa bí mật của server. Kế đến, một nonanonymous server(server không dùng anonymous Diffie-Hellman) có thể yêu cầu một certificate từ client.Một thông điệp certificate_request bao gồm hai thông số certificate_type và certificate_authorities. Kiểu certificate chỉ ra giải thuật khóa công khai,và nó dùng: - RSA,chỉ dùng chữ kí - DSS,chỉ dùng chữ kí - RSA cho Diffie-Hellman thích hợp, trong trường hợp này chữ kí được dùng chỉ để xác thực,bằng cách gửi dùng certificate được kí với RSA. Secure Socket Layer 18
  • 19.
    PTIT 2009 Đề tài môn Bảo mật thông tin - DSS cho fixed Diffie-Hellman, một lần nữa,chỉ dùng để xác thực. - RSA cho ephemeral Diffie-Hellman. - DSS cho ephemeral Diffie-Hellman. - Fortezza. Thông số thứ 2 của thông điệp certificate_request là một danh sách các tên của những CA đặc biệt được chấp nhận. Thông điệp cuối cùng trong giai đoạn 2, và là một phần luôn được yêu cầu,là thông điệp Server_done,mà được gửi cho server để chỉ ra điểm cuối của thông điệp cuối của server_hello và các message đi kèm.Sau khi gửi thông điệp,server sẽ chờ hồi đáp của client.Thông điệp này không có tham số. I.6.3 Giai đoạn 3 – Xác thực client và trao đổi khóa :  Trong khi nhận thông điệp server_done, client sẽ xác nhận xem server cung cấp một chứng chỉ hợp lệ hay chưa nếu được yêu cầu và kiểm tra xem các thông số của server_hello được chấp nhận hay không.Nếu tất cả đều thoả mãn, client gửi một hay nhiều message trở lại cho server. Nếu server yêu cầu một certificate,client bắt đầu giai đoạn này bằng cách gửi 1 thông điệp certificate.Nếu khống có certificate phù hợp nào hợp lệ, client gửi một cảnh báo no_certificate thay thế.  Kế đến là thông điệp client_key_exchange phải được gửi đi trong giai đoạn này.Nội dung của thông điệp phụ thuộc vào kiểu trao đổi khóa. Như sau: - RSA: client sinh một trường 48 byte pre-master secret và mã hóa với khóa công khai từ chứng thực của server hoặc khóa RSA phụ từ thông điệp server_key_exchange. Nó dùng để tính toán một master secret(sẽ được nói sau). - Ephemeral hoặc Anonymous Diffie-Hellman: các tham số Diffie-hellman công khai của client được gửi đi. - Fixed Diffie-Hellman: các tham số Diffie-Hellman công khai của client được gửi đi trong một thông điệp certificate,vì vậy nội dung của thông điệp là null. - Fortezza: các tham số Fortezza của client được gửi đi.  Cuối cùng,trong giai đoạn này,client sẽ gửi 1 message certificate_verify để cung cấp xác thực tường minh của một chứng chỉ client.Thông điệp này chỉ được gửi theo sau bất kì một client certificate nào đã đánh dấu là có khả năng(nghĩa là tất cả certificate ngoại trừ những cái chứa tham số fixed Diffie-Hellman). Thông điệp này đánh dấu một mã băm dựa trên các thông điệp có trước,được định nghĩa như sau: CertificateVerify.signature.md5_hash MD5(master_secret || pad_2 || MD5(handshake_messages || master_secret || pad_1)); Certificate.signature.sha_hash SHA(master_secret || pad_2 || SHA(handshake_messages || master_secret || pad_1));  Với pad_1 và pad_2 là các giá trị được định nghĩa sớm hơn cho MAC, handshake_messages xem xét đến tất cả các thông điệp giao thức bắt tay được gửi đi hay được nhận bắt đầu từ client_hello nhưng không bao gồm thông điệp này,và master_secret là khóa bí mật được tính toán mà quá trình xây dựng sẽ được tìm hiểu sau. Nếu khóa bí mật của user là DSS, thì nó được dùng để mã hóa mã băm SHA-1. Nếu khóa bí mật của user là RSA, nó được dùng để mã hóa chuỗi mã băm MD5 và SHA-1.  Trong trường hợp khác, mục đích là để xác minh quyền sở hữu của client với khóa bí mật cho chứng thực client.Cho dù là bất cứ ai đang lạm dụng certificate của client thì cũng sẽ không thể gửi message này. I.6.4 Giai đoạn 4 – Kết thúc :  Giai đoạn này hoàn thành thiết lập của một kết nối an toàn,Client gửi một thông điệp change_cipher_spec và chép CipherSpec đệm vào CipherSpec hiện tại.Chú ý rằng thông điệp này không được xem là một phần của giao thức bắt tay nhưng được gửi đi sử dụng giao thức Change Cipher Spec. Client sau đó ngay lập tức gửi thông điệp kết thúc theo giải thuật mới, với các khóa và các bí mật.Thông điệp kết thúc xác minh xem quá trình trao đổi khóa và xác thực có thành công hay không.nội dung của thông điệp hoàn tất là một chuỗi của hai giá trị băm : Secure Socket Layer 19
  • 20.
    PTIT 2009 Đề tài môn Bảo mật thông tin MD5(master_secret || pad2 || MD5(handshake_messages || Sender || master_secret || pad1)) SHA(master_secret || pad2 || SHA(handshake_messages || Sender || master_secret || pad1))  Tại đó bên gửi là một mã mà xác định rằng bên gửi là client , và handshake_messages là tất cả dữ liệu từ tất cả thông điệp bắt tay trở lên nhưng không bao gồm thông điệp này.  Khi đáp lại hai thông điệp này,server gửi thông điệp change_cipher_spec của chính nó, chuyển đổi trạng thái treo cho cipherSpec hiện tại và gửi thông điệp kết thúc của nó đi.Ở điểm này quá trình bắt tay hoàn thành và client và server có thể bắt đầu trao đổi dữ liệu lớp ứng dụng. I.7 Tính toán mã hóa : Gồm việc tạo ra 1 shared master secret bằng cách trao đổi khóa, và sự sinh ra các tham số mật mã từ master secret. I.7.1 Việc tạo Master Secret : Shared master secret là 1 giá trị one-time 48 byte (384 bits) được sinh ra cho phiên này bằng cách trao đổi khóa an toàn.Việc tạo ra gồm hai bước: - Đầu tiên, một pre-master-secret được trao đổi - Thứ hai, master_secret được tính toán bằng cả hai nhóm. Đối với trao đổi pre_master_secret, có hai khả năng xảy ra:  RSA: 48 byte pre_master_secret được sinh ra bởi client, mã hóa với khóa RSA công khai của server, và gửi cho server.Server giải mã ciphertext sử dụng khóa bí mật của nó để phục hồi lại pre_master_secret.  Diffie-Hellman: cả client và server sinh ra khóa công khai Diffie-Hellman. Sau đó, những khóa này được trao đổi, mỗi bên biểu diễn việc tính toán Diffie-Hellman để tạo ra shared_pre_master_secret. Cả 2 bên tính toán master_secret như sau: master_secret = MD5 (pre_master_secret || SHA ('A' || pre_master_secret ||ClientHello.random || ServerHello.random)) || MD5 (pre_master_secret || SHA ('BB' || pre_master_secret || ClientHello.random || ServerHello.random)) || MD5 (pre_master_secret || SHA ('CCC' || pre_master_secret || ClientHello.random || ServerHello.random)) Với ClientHello.random và ServerHello.random là 2 giá trị số ngẫu nhiên được trao đổi trong thông điệp hello khởi tạo ban đầu. Secure Socket Layer 20
  • 21.
    PTIT 2009 Đề tài môn Bảo mật thông tin I.7.2 Việc sinh các tham số mã hóa : CipherSpec yêu cầu một khóa xác thực của client, một khóa xác thực của server, và một khóa mật mã của client, một khóa mật mã của server, một vector khởi tạo IV của client, một vector khởi tạo IV của server, mà được sinh ra từ master_secret theo thứ tự đó.Những tham số này được sinh ra từ master_secret bằng cách băm master_secret thành chuỗi liên tục các byte bảo mật với chiều dài vừa đủ của những tất cả các tham số cần thiết . Việc sinh nguyên liệu khóa từ master_secret sử dụng cùng định dạng cho việc sinh ra master_secret từ pre_master_secret: key_block = MD5(master_secret || SHA('A' || master_secret || ServerHello.random || ClientHello.random)) || MD5(master_secret || SHA('BB' || master_secret || ServerHello.random || ClientHello.random)) || MD5(master_secret || SHA('CCC' || master_secret || ServerHello.random || ClientHello.random)) || . . Cho đến khi đủ số output được phát sinh.Kết quả của cấu trúc giải thuật này là hàm sinh số ngẫu nhiên. Ta có thể xem master_secret như giá trị ngẫu nhiên đưa hạt giống sinh số ngẫu nhiên vào trong hàm sinh số ngẫu nhiên.Các số ngẫu nhiên client và server có thể được nhìn như là các giá trị không đáng tin cậy(salt value) làm phức tạp sự giải mã các mật mã. Secure Socket Layer 21
  • 22.
    PTIT 2009 Đề tài môn Bảo mật thông tin I.8 Transport Layer Security : I.8.1 Version Number : Định dạng của một record TLS giống định dạng của record SSL, và các trường trong phần header cũng có ý nghĩa giống nhau.Một sự khác biệt là trong các giá trị phiên bản TLS hiện tại,bản chính là 3 và bản phụ là 1. I.8.2 Message Authentication Code : Có 2 điểm khác biệt giữa SSLv3 và TLS MAC schemes: giải thuật thực tế và phạm vi của phép tính MAC. TLS tạo ra việc sử dụng giải thuật HMAC được định nghĩa trong RFC 2104.Nhớ lại,HMAC được định nghĩa như sau: HMACK(M) = H[(K+ opad)||H[(K+ ipad)||M]] Với : H: hàm băm nhúng(dành cho TLS, hoặc MD5 hoặc SHA-1) M: thông điệp đầu ra đối với HMAC K+ : khóa bí mật đệm các số 0 vào phía bên trái để kết quả bằng với chiều dài khối mã băm (đối với MD5, và SHA-1, chiều dài khối bằng 512 bits) Secure Socket Layer 22
  • 23.
    PTIT 2009 Đề tài môn Bảo mật thông tin Ipad =00110110(36H) lặp lại 64 lần (512 bits) Opad =01011100(5CH) lặp lại 64 lần (512 bits) SSLv3 dùng cùng giải thuật, ngoại trừ các byte đệm được nối vào vào khóa bí mật hơn là được XOR với khóa bí mật được đệm vào chiều dài khối.Mức độ an toàn cùng giống trong cả 2 trường hợp. Đối với TLS, phép tính toán MAC hoàn thành các trường hợp được chỉ ra trong đẳng thức sau: HMAC_hash(MAC_write_secret, seq_num || TLSCompressed.type || TLSCompressed.version || TLSCompressed.length || TLSCompressed.fragment) Phép toán MAC bao gồm tất cả các trường được hàm chứa bởi phép tính toán SSLv3, cộng với trường TLSCompresses.version, mà là version của giao thức đang được dùng. I.8.3 Hàm tính số nhẫu nhiên : TLS tạo cách sử dụng hàm tạo số ngẫu nhiên dùng cho PRF để mở rộng các secret(phần bí mật) thành các khối dữ liệu cho mục đích sinh khóa hay phê chuẩn.Đối tượng là để tạo ra cách sử dụng các giá trị shared secret nhỏ có liên hệ với nhau, nhưng để phát sinh các khối dài hơn theo cách an toàn khỏi sự tấn công dựa trên hàm băm và MACx.PRF dựa trên hàm mở rộng dữ liệu sau: P_hash(secret, seed) = HMAC_hash(secret, A(1) || seed) || HMAC_hash(secret, A(2) || seed) || HMAC_hash(secret, A(3) || seed) || ... Với A() được định nghĩa: A(0)=seed A(i) =HMAC_hash(secret,A(i-1)) Secure Socket Layer 23
  • 24.
    PTIT 2009 Đề tài môn Bảo mật thông tin Hàm mở rộng dữ liệu tạo cách sử dụng giải thuật HMAC, với hoặc MD5 hoặc SHA-1 như là trên cơ sở hàm băm.Như ta có thể thấy,P_hash có thể lặp đi lặp lại nhiều lần như sự cần thiết để tạo ra số lượng dữ liệu được yêu cầu.Ví dụ, nếu P_SHA-1 được dùng để sinh ra 64 byte dữ liệu,nó sẽ được lặp đi lặp lại 4 lần tạo ra 80 byte dữ liệu,mà 16 byte cuối bị loại bỏ.Trong trường hợp này,P_MD5 cũng sẽ được lặp lại 4 lần,tạo ra chính xác 64 bytes dữ liệu.Chú ý rằng mỗi lần lặp lại sẽ gọi 2 hàm thực thi HMAC, mỗi một cái sẽ quay sang gọi 2 hàm thực thi trên cơ sở giải thuật hàm băm. Để tạo ra PRF an toàn đến mức có thể,nó sử dụng 2 giải thuật băm theo cách mà sẽ đảm bảo sự an toàn của nó nếu giải thuật vẫn còn bảo mật.PRF được định nghĩa : hash(ClientHello.random || ServerHello.random || ServerParams) PRF lấy khi đầu vào một giá trị bí mật, một nhãn xác định, và một giá trị hạt giống(seed) và tạo ra một output có chiều dài tùy ý.Output được tạo bằng cách phân cắt giá trị bí mật thành hai nửa (S1 và S2 và biểu diễn P_hash ở mỗi nửa,sử dụng MD5 ở một nửa và SHA-1 ở nửa khác.Hai kết quả được thực hiện bởi phép XOR để tạo ra output, cho mục đích này,P_MD5 nhìn chung phải lặp lại nhiều lần hơn P_SHA-1 để tạo một lượng dữ liệu ngang bằng cho input bằng hàm XOR) I.8.4 Mã cảnh báo : TLS hỗ trợ tất cả các mã alert code được định nghĩa trong SSLv3 với ngoại lệ no_certificate. Một số các code thêm vào được định nghĩa trong TLS, sau đây là một số cảnh báo mức nguy hiểm:  decryption_failed : một cipher text được giải mã theo cách sai, hoặc nó không phải là phép nhân của chiều dài khối hoặc giá trị đệm của nó,khi kiểm tra là không đúng. Secure Socket Layer 24
  • 25.
    PTIT 2009 Đề tài môn Bảo mật thông tin  record_overflow:một TLS record được nhận với một payload(ciphertext) có chiều dài 214+2048 bytes, hoặc ciphertext được giải mã với chiều dài lớn hơn 214+1024 byte.  unknown_ca : một chuỗi certificate hợp lệ hoặc 1 phần chuỗi được nhận,nhưng certificate không được chấp nhận bởi vì CA certificate không thể được cấp phát hoặc không thể tạo ra kết nối với 1 CA hiểu biết,tin cậy.  access_defined: một certificate hợp lệ được nhận, vì khi access_control được thừa nhận, sender quyết định không thực thi với thỏa thuận.  decord_error : một thông điệp không thể được giải mã vì 1 trường bị thiếu range đặc biệt hoặc chiều dài của message không đúng.  export_restriction : một thỏa thuận không được chấp nhận với việc xuất ra các hạn chế trên chiều dài khóa bị phát hiện.  protocol_version: phiên bản giao thức mà client nỗ lực thỏa thuận được nhận thấy nhưng không hỗ trợ.  insufficient_security: trả về thay thế handshake_failure khi thỏa thuận bị thất bại 1 cách đặc biệt bởi vì server yêu cầu cipher nhiều bảo mật hơn những cái khác được hỗ trợ bởi client.  internal_error: một lỗi bên trong không liên hệ với cấp tương đương hoặc sự sửa lỗi của giao thức tạo ra không thể để tiếp tục. Phần còn lại của các cảnh báo mới bao gồm:  decrypt_error: toán hạng mã hóa bắt tay bị hư, bao gồm không thể xác minh 1 chữ kí,mã hóa 1 trao đổi khóa hay công nhận 1 thông điệp hoàn tất.  user_canceled: quá trình bắt tay này bị hoãn lại vì 1 số lí do không liên quan đến sự thất bại giao thức.  no_renegotiation: gửi đi bởi client trong phần đáp lại client hello sau khi thiết lập bắt tay.hoặc những thông điệp này sẽ có kết quả bình thường trong việc thỏa thuận lại,nhưng cảnh báo này chỉ ra rằng sender không thể thỏa thuận.Thông điệp này luôn luôn là 1 cảnh báo(warning). I.8.5 Cipher suite : Có nhiều sự khác nhau nhỏ giữa các cipher suite sẵn có dưới SSLv3 và dưới TLS:  Trao đổi khóa:TLS hỗ trợ tất cả các công nghệ trao đổi khóa của SSLv3 với ngoại lệ của Fortezza.  Các giải thuật mã hóa đối xứng:TLS bao gồm tất cả các giải thuật mã hóa đối xứng được tìm thấy trong SSLv3,với ngoại lệ của Fortezza. I.8.6 Các dạng client certificate : TLS định nghĩa cá kiểu certificate sau đây được yêu cầu trong thông điệp certificate_request:rsa_sign,dss_sign,rsa_fixed_dh, và dss_fixed_dh. Tất cả những kiểu này được định nghĩa trong SSLv3. Thêm vào đó,SSLv3 bao gồm rsa_ephemeral_dh, dss_ephemeral_dh và fortezza_kea. Ephemeral Diffie-Hellman bao gồm đánh dấu các tham số Difie-Hellman với hoặc RSA hoặc DSS, với TLS, rsa_sign và kiểu đánh dấu riêng không cần thiết để đánh dấu các tham số Diffie-Hellman.TLS không bao gồm hê thống Fortezza. Secure Socket Layer 25
  • 26.
    PTIT 2009 Đề tài môn Bảo mật thông tin I.8.7 Certificate Verify và Finished Message : Trong thông điệp TLS_certificate_verify, mã băm MD5 và SHA-1 được tính toán chỉ trên các thông điệp bắt tay(handshake_message).Nhớ lại rằng SSLv3 tính toán hàm băm còn bao gồm master_secret và đệm.Các trường thêm vô này thất bại trong việc cộng thêm bảo mật không được thêm vào. Khi các thông điệp hoàn tất trong SSLv3, thông điệp kết thúc trong TLS là 1 mã băm dựa trên shared_master_secret, thông điệp bắt tay ở trước, và một nhãn xác định client hay server, việc tính toán có đôi chút khác biệt. Đối với TLS ta có: PRF(master_secret, finished_label, MD5(handshake_messages)|| SHA-1(handshake_messages)) Với finished_label là chuỗi “client_finished” đối với client và “server finished” đối với server. I.8.8 Tính toán mã hóa : Pre_master_secret đối với TLS được tính toán cùng 1 cách như trong SSLv3.Như trong SSLv3, master_secret trong TLS được tính toán như 1 hàm băm của pre_master_secret và hai số ngẫu nhiên hello.Công thức của phép tính toán TLS khác với công thức tính của SSLv3,được định nghĩa như sau: master_secret = PRF(pre_master_secret, "master secret", ClientHello.random || ServerHello.random) Giải thuật biểu diễn cho đến khi 48 byte của output số ngẫu nhiên được tạo ra.Phép tính toán của khối vật liệu key(MAC secret keys,khóa mã hóa phiên, và ma trận khởi tạo IVs) được định nghĩa như sau: key_block = PRF(master_secret,"key expansion",SecurityParameters.server_random || SecurityParameters.client_random) Cho đến khi đủ output được sinh ra.Như với SSLv3,key_block là 1 hàm của master_secret và client và server random numbers, nhưng với TLS giải thuật thực tế là khác biệt. I.8.9 Phần đệm : Trong SSL, phần đệm thêm vào trước để mã hóa dữ liệu user là số lượng nhỏ nhất được yêu cầu để mà kích thước tổng của dữ liệu được mã hóa là một phép nhân của chiều dài khối của cipher.Trong TLS, padding có thể là bất kì số lượng nào mà có kết quả trong một tổng mà là một phép nhân của chiều dài khối của cipher lên đến 1 giá trị lớn nhất là 255 byte.Ví dụ, nếu 1 plaintext (hoặc văn bản nén được dùng) cộng với MAC+padding length byte là dài 79 byte.Sau đó chiều dài padding,tính theo byte, có thể là 1,9,17 và hơn nữa,đến 249. Chiều dài phần đệm tùy biến có thể chống lại các tấn công dựa trên một phép phân tích các chiều dài của các thông điệp trao đổi. Secure Socket Layer 26
  • 27.
    PTIT 2009 Đề tài môn Bảo mật thông tin Chương II : II.1 Quan hệ giữa các Class : Để liên lạc một cách bảo mật, cả hai đầu của kết nối phải kích hoạt SSL. Trong JSSE API, những lớp đầu cuối của kết nối là SSLSocket và SSLEngine . Trong biểu đồ bên dưới, những class lớn được dùng để tạo SSLSocket/SSLEngines được sắp xếp theo trật tự logic. Một SSLSocket thì được tạo bởi một SSLSocketFactory hoặc một SSLServerSocket cho việc nhận vào một kết nối inbound.( mặt khác, một SSLServerSocket được tạo bởi một SSLServerSocketFactory) . Cả các đối tượng SSLSocketFactory và SSLServerSocketFactory được tạo bởi SSLContext. Một SSLEngine được tạo một cách trực tiếp bởi SSLContext, và dựa vào ứng dụng để quản lý tất cả I/O. Ghi chú: Khi sử dụng SSLSockets/SSLEngines ta nên kiểm tra xác thực đầu cuối trước khi gửi dữ liệu. Lớp SSLSocket/SSLEngine sẽ không tự động xác minh, ví dụ hostname trong một URL trùng với hostname trong xác thực đầu cuối. Ứng dụng có thể bị lợi dụng URL spoofing nếu hostname không được xác minh Có hai cách để sử dụng và khởi tạo một SSLContext: Secure Socket Layer 27
  • 28.
    PTIT 2009 Đề tài môn Bảo mật thông tin Đơn giản nhất là gọi phương thức tĩnh getDefault trên lớp SSLSocketFactory hoặc SSLServerSocketFactory . Những phương thức này tạo một SSLContext mặc định với một KeyManager, TrustManager và một bộ khởi tạo số bí mật ngẫu nhiên. (Một KeyManagerFactory và TrustManagerFactory mặc định được sử dụng để tạo KeyManager và TrustManager tương ứng.) Key material được tìm thấy trong keystore/truststore mặc định, được định rõ bởi tính chất hệ thống mô tả trong Customizing the Default Key and Trust Stores, Store Types, and Store Passwords. Phương thức trao đổi bên gọi phần lớn điều khiển cách hoạt động của context được tạo thì gọi là phương thức tĩnh getInstance trên lớp SSLContext , sau đó khởi tạo context bằng cách gọi phương thức riêng init của trường hợp . Một thực thể của phương thức init mang ba phần sau: một dãy đối tượng KeyManager, một dãy đối tượng TrustManager và một bộ sinh số bí mật ngẫu nhiên SecureRandom. Đối tượng KeyManager và TrustManager được tạo bởi việc bổ sung các interface(s) thích hợp hoặc dùng lớp KeyManagerFactory và TrustManagerFactory để phát sinh các bổ sung. KeyManagerFactory và TrustManagerFactory có thể được khởi tạo với mỗi key material chứa trong KeyStore qua phương thức TrustManagerFactory/KeyManagerFactory init. Cuối cùng phương thức getTrustManagers (trong TrustManagerFactory) và phương thức getKeyManagers (trong KeyManagerFactory) có thể được gọi để sử dụng những chuỗi của trust hoặc key managers,một cho mỗi loại của trust hoặc key material. Mỗi một kết nối SSL được khởi tạo thì một SSLSession được tạo chứa các thông tin đa dạng, như là ID khởi tạo, bộ mã hóa được dùng , .v.v. . SSLSession khi đó được dùng thể hiện mối liên hệ xảy ra bên trên và thông tin trạng thái giữa hai thực thể . Mỗi kết nối SSL bao gồm 1 phiên tại một thời điểm nhưng phiên đó thì lại có thể được dùng bởi nhiều kết nối giữa những thực thể đó,đồng thời hoặc theo thứ tự. II.2 Các Class và Interface chính : II.2.1 Lớp SocketFactory và ServerSocketFactory : Lớp trừu tượng javax.net.SocketFactory được dùng để tạo socket. Nó phải là subclassed của các factories khác, mà tạo những subclasses riêng biệt của sockets và vì vậy cung cấp một framework tổng quát cho phần thêm vào của chức năng public socket-level. (xem ví dụ SSLSocketFatory ) Lớp javax.net.ServerSocketFactory thì tương tự lớp SocketFactory, nhưng nó chỉ dành riêng cho việc tạo server sockets. Socket factories là cách đơn giản để các chính sách liên quan đến sockets được xây dựng,việc thiết lập sockets theo một cách nào đó thì không yêu cầu cấu hình riêng biệt cho code mà đòi hỏi: Vì sự đa hình của factories và sockets, những dạng khác nhau của sockets có thể cùng dùng code ứng dụng mà bỏ qua các dạng khác nhau của factories. Factories có thể tự tùy chỉnh thông số với các thông số sử dụng trong xây dựng socket. Ví dụ factories tự điều chỉnh để trả về sockets với những timeouts mạng khác nhau hoặc thông số security đã cấu hình . Sockets trả về ứng dụng subclasses của java.net.Socket (hay javax.net.ssl.SSLSocket), cho nên ta có thể trình bày một APIs mới cho những đặc trưng như nén , bảo mật ,đánh dấu record,lựa chọn thống kê, hay vượt tường lữa. II2.2 Lớp SSLSocketFactory và SSLServerSocketFactory : Một javax.net.ssl.SSLSocketFactory hoạt động như một factory cho việc tạo secure sockets. Lớp này là một phân lớp trừu tượng của javax.net.SocketFatory Secure Socket Layer 28
  • 29.
    PTIT 2009 Đề tài môn Bảo mật thông tin Secure socket factories đóng gói chi tiết của việc tạo và cấu hình ban đầu secure sockets. Bao gồm xác thực keys, công nhận certificate đầu bên kia, kích hoạt bộ mã hóa và tương tự. Lớp javax.net.ssl.SSLServerSocketFactory thì tương tự lớp SSLSocketFactory, nhưng được sử dụng riêng cho việc tạo server sockets. Tạo một SSLSocketFactory : Có ba cách cơ bản để tạo SSLSocketFactory: Lấy factory mặc định bằng việc gọi phương thức tĩnh SSLSocketFactory.getDefault. Nhận một factory như là 1 thông số API .Đó là code cần tạo sockets nhưng không quan tâm chi tiết như thế nào sockets được cấu hình có thể bao gồm 1 phương thức với 1 thông số SSLSocketFactory được gọi bởi clients để chỉ rõ SSLSocketFactory dùng để tạo sockets,vd : javax.net.ssl.HttpsURLConnection. Xây dựng một factory mới với cách chạy được cấu hình riêng biệt. Factory mặc định được cấu hình đặc trưng để hổ trợ chứng thực server chỉ khi sockets được tạo bởi một factory mặc định không rò rĩ bất cứ thông tin nào về về client hơn một TCP socket bình thường làm. Nhiều lớp tạo và dùng sockets thì không cần biết chi tiết của cách tạo sockets.Việc tạo sockets qua một sockets factory được lướt qua như một thông số như là một cách tốt để cách ly chi tiết của cấu hình socket và tăng sự tái dụng của lớp mà tạo và dùng sockets. Bạn có thể tạo một socket factory mới bằng việc triển khai socket factory subclass của bạn hay sử dụng lớp khác mà hoạt động như một factory cho socket factories. Một ví dụ là lớp SSLContext mà được cung cấp trong JSSE như là một lớp cung cấp cấu hình cơ sở. II.2.3 Lớp SSLSocket và SSLServerSocket : Lớp javax.net.ssl.SSLSocket là một subclass của lớp chuẩn java.net.Socket . Nó hỗ trợ tất cả phương thức socket chuẩn và thêm những phương thức bổ sung đặc trưng vào secure sockets. Cá biệt của lớp này là đóng gói SSLContext bên dưới những gì mà nó tạo. Có những APIs điều khiển việc tạo secure socket sessions cho một socket riêng biệt nhưng việc quản lý trust và key không được che đậy một cách trực tiếp. Lớp javax.net.ssl.SSLServerSocket thì tương tự lớp SSLSocket ,nhưng được dùng đặc trưng cho cho việc tạo server sockets. Để ngăn spoofing đầu bên,bạn nên luôn xác minh đầu cuối cho một SSLSocket. Ghi chú bổ sung : do sự phức tạp của giao thức SSL và TLS ,nó khó để dự đoán có hay không bytes vào trên một kết nối là handshake hay dữ liệu ứng dụng,và như thế nào dữ liệu có thể tác động trạng thái kết nối hiện tại (ngoại trừ trường hợp quá trình bị block). Trong thực thi của Sun JSSE, phương thức available()trên đối tượng đạt được từ SSLSocket.getInputStream()trả về tổng số của bytes dữ liệu ứng dụng giải mã thành công từ kết nối kết nối SSL nhưng lúc này chưa đọc bởi ứng dụng. Tạo một SSLSocket : SSLSocket có thể tạo được bằng hai cách. Thứ nhất, một SSLSocket có thể tạo bởi SSLSocketFactory qua một vài phương thức createSocket trên lớp đó. Cách thứ hai tạo SSLSockets qua phương thức accept trên lớp SSLServerSocket . Secure Socket Layer 29
  • 30.
    PTIT 2009 Đề tài môn Bảo mật thông tin II.2.4 Non-blocking I/O với SSLEngine : SSL/TLS đang ngày càng phổ biến. Nó được dùng trong các ứng dụng đa dạng trên một diện rộng các nền máy tính . Theo đà sự phổ biến hiện nay dẫn đến yêu cầu sử dụng nó với những I/O và mô hình chuỗi khác nhau để mà thỏa mãn hiệu suất , khả năng , theo dõi và những yêu cầu khác của ứng dụng.Đó là sự đòi hỏi sử dụng nó trong trong những kênh I/O blocking và non-blocking , I/O không đồng bộ, các luồng input và output đa dạng , và những bộ đệm byte.Đó là sự yêu cầu nó trong môi trường nhạy cảm có độ biến đổi và hiệu suất cao mà yêu cầu quản lý hàng ngàn network connections. Trước J2SE 5 , JSSE API hổ trợ chỉ một khái niệm trừu tượng transport đơn : luồng sockets nền thông qua SSLSocket. Trong khi dạng này tương thích với nhiều ứng dụng , nó không gặp phải những yêu cầu của ứng dụng mà cần dùng I/O khác nhau hay mô hình liên kết. Trong 1.5.0 , một khái niệm trừu tượng mới được giới thiệu để cho phép ứng dụng sử dụng giao thức SSL/TLS trong một đường vận chuyển độc lập , vì vậy những ứng dụng tự do chọn cách thức vận chuyển và mô hình tính toán tốt nhất mà nó cần. Nó còn thích nghi với nhiều mô hình liên kết. Điếu này cho phép một cách hiệu quả I/O và liên kết vào ứng dụng . Bởi vì tính linh hoạt này , ứng dụng bây giờ phải quản lý I/O và liên kết ( những topic phức tạp vào trong chính nó) cũng như nắm rõ giao thức SSL/TLS. Một khái niệm trừu tượng mới cho ra một API cao cấp : người dùng nên sử dụng SSLSocket. Một người mới tiếp xúc API có thể tự hỏi “ Tại sao không chỉ có một SSLSocketChannel mà thuộc java.nio.channels.SocketChannel?" Có hai lý do chính sau : Có nhiều câu hỏi khó về một SSLSocketChannel thì nên như thế nào gồm cả hệ thống phân lớp của nó và nó nên liên kết với Selectors và những dạng khác của SocketChannels như thế nào.Mỗi đề xuất thì mang lại nhiều câu hỏi hơn là trả lời . Nó được giải thích rằng khái niệm trừu thượng API mới mở rộng để làm việc với SSL/TLS yêu cầu cùng một các phép phân tích quan trọng và có thể dẫn đến những APIs lớn và phức tạp. Bất kỳ việc thực thi JSSE nào cho một API mới sẽ tự do chọn lựa I/O và chiến lược tính toán tốt nhất , nhưng ẩn đi những chi tiết không thích hợp cho yêu cầu điều khiển ứng dụng đó. Bất kỳ sự thực thi đặc trưng nên tách rời với các phân đoạn ứng dụng. Bằng việc trừu tượng I/O và dữ liệu xữ lý như những chuỗi bytes, kết quả được giải quyết và API mới có thể sử dụng với bất cứ mô hình I/O nào hiện nay và sắp tới.Trong khi giải pháp này làm I/O và CPU chuyển giao trách nhiệm cho người lập trình , việc thực thi JSSE thì bị ngăn không cho trở nên không sử dụng được bởi vì những chi tiết bên trong không thể cấu hình hay thay đổi. Người dùng những API ngôn ngữ lập trình lập trình Java khác như JGSS và SASL sẽ thông báo những điều tương tự rằng ứng dụng thì cũng chịu trách nhiệm cho dữ liệu vận chuyển. SSLEngine Lớp chính trong khái niệm mới này là javax.net.ssl.SSLEngine .Nó đóng gói một SSL/TLS cơ chế trạng thái và cách vận hành trên bộ đệm byte inbound và outbound hổ trợ bởi người dùng của SSLEngine. Lược đồ sau sẽ minh họa luồng dữ liệu của data từ ứng dụng , đến SSLEngine , đến cơ chế vận chuyển và quay về Secure Socket Layer 30
  • 31.
    PTIT 2009 Đề tài môn Bảo mật thông tin Tầng ứng dụng ở bên trái cung cấp dữ liệu ứng dụng (plaintext) trong một application buffer và chuyển nó cho SSLEngine . SSLEngine xử lý dữ liệu chứa trong buffer hoặc bất cứ dữ liệu handshaking nào để tạo ra dữ liệu đã mã hóa SSL/TLS vào đặt vào network buffer cung cấp bởi ứng dụng. Ứng dụng thì sau đó chịu trách nhiệm cho việc vận chuyển tương ứng (bên phải) để gửi nội dung của network buffer đến đầu bên.Lúc nhận dữ liệu đã mã hóa SSL/TLS từ đầu bên ( thông qua tầng vận chuyển) , ứng dụng đưa dữ liệu vào trong network buffer và chuyển nó đến SSLEngine . SSLEngine xử lý nội dung network buffer để tạo ra dữ liệu handshaking hay dữ liệu ứng dụng. Về tổng thể , SSLEngine có thể là một trong năm trạng thái : 1. Creation – sẵn sàng để cấu hình. 2. Initial handshaking - thực thi chứng thực và thương lượng thông số truyền thông. 3. Application data – sẵn sàng cho trao đổi dữ liệu. 4. Rehandshaking - tái thương lượng thông số truyền thông / chứng thực;dữ liệu handshaking có thể đã được gắn vào dữ liệu ứng dụng. 5. Closure – sẵn sàng đóng kết nối. Năm trạng thái này được miêu tả chi tiết hơn trong tài liệu lớp SSLEngine II.2.5 Quá trình khởi động : Để tạo một SSLEngine , bạn sử dụng phương thức SSLContext.createSSLEngine() . Bạn phải cấu hình cơ chế hoạt động như một client hoặc một server, cũng như đặt các thông số cấu hình khác như là cipher suites được dùng và có yêu cầu chứng thực client không. Đây là một ví dụ mà tạo một SSLEngine . Chú ý rằng tên server và số port thì không được dùng cho liên lạc với server – tất các vận chuyển là trách nhiệm của ứng dụng.Chúng gợi ý cho người cung cấp JSSE sử dụng việc cache SSL session, và cho việc thực thi Kerberos-cipher suite cơ bản để định rõ ủy quyền server nào nên được chọn. import javax.net.ssl.*; import java.security.*; // Khởi tạo SSLContext với key material char[] passphrase = "passphrase".toCharArray(); // Khởi tạo lần đầu key và trust material. KeyStore ksKeys = KeyStore.getInstance("JKS"); Secure Socket Layer 31
  • 32.
    PTIT 2009 Đề tài môn Bảo mật thông tin ks.load(new FileInputStream("testKeys"), passphrase); KeyStore ksTrust = KeyStore.getInstance("JKS"); ks.load(new FileInputStream("testTrust"), passphrase); // KeyManager's quyết định key material nào được dùng. KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509"); kmf.init(ksKeys, passphrase); // TrustManager's quyết định có cho phép kết nối không. TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509"); tmf.init(ksTrust); sslContext = SSLContext.getInstance("TLS"); sslContext.init( kmf.getKeyManagers(), tmf.getTrustManagers(), null); // Chúng ta đã sẵn sàng cho một engine SSLEngine engine = sslContext.createSSLengine(hostname, port); // Sử dụng như một client engine.setUseClientMode(true); II.2.6 Phát sinh và xử lý dữ liệu SSL/TLS : Hai phương thức chính SSLEngine wrap() và unwrap() thì chịu trách nhiệm cho việc phát sinh và sử dụng dữ liệu network tương ứng. phụ thuộc vào trạng thái SSLEngine, dữ liệu này có thể là dữ liệu handshake hay ứng dụng. Mỗi SSLEngine có một vài giai đoạn trong suốt thời gian sống của nó. Trước khi dữ liệu ứng dụng có thể được gửi/nhận , giao thức SSL/TLS yêu cầu một handshake để khởi tạo thông số mã hóa. Handshake này yêu cầu một loạt các bước tới và lui bởi SSLEngine. SSL Process có thể cung cấp thêm chi tiết về handshake của chính nó. Suốt quá trình handshacking ban đầu, wrap() và unwrap() khởi tạo và sử dụng dữ liệu handshake, và ứng dụng thì chịu trách nhiệm cho việc vận chuyển dữ liệu. Chuỗi wrap()/unwrap() được lập lại cho đến khi hanshake được hoàn tất. Mỗi quá trình hoạt động SSLEngine khởi tạo một SSLEngineResult, của trường SSLEngineResult.HandshakeStatus nào được dùng để xác định cơ chế nào cần xảy ra tiếp theo để tiến tới handshake . Một handshake điển hình có thể như sau: Client SSL/TLS message HSStatus wrap() ClientHello NEED_UNWRAP unwrap() ServerHello/Cert/ServerHelloDone NEED_WRAP wrap() ClientKeyExchange NEED_WRAP wrap() ChangeCipherSpec NEED_WRAP wrap() Finished NEED_UNWRAP unwrap() ChangeCipherSpec NEED_UNWRAP unwrap() Finished FINISHED Bây giờ thì việc handshaking đã hoàn thành, trạng thái tiếp theo sẽ gọi wrap()để thử dùng dữ liệu ứng dụng và packages cho vận chuyển. unwrap()thì làm ngược lại. Để gửi dữ liệu đến đầu bên , ứng dụng trước hết phải cung cấp dữ liệu mà nó muốn gửi đến SSLEngine thông qua SSLEngine.wrap() để thu được dữ liệu đã mã hóa SSL/TLS tương ứng.Ứng dụng sau đó gửi dữ liệu cho đầu bên theo cơ chế vận chuyển mà nó đã chọn . Khi ứng dụng nhận được dữ liệu đã mã hóa SSL/TLS qua cơ chê Secure Socket Layer 32
  • 33.
    PTIT 2009 Đề tài môn Bảo mật thông tin vận chuyển, nó cung cấp dữ liệu này cho SSLEngine thông qua SSLEngine.unwrap() để thu được dữ liệu plaintext mà đầu kia muốn gửi. Đây là một thí dụ của một ứng dụng SSL mà sử dụng một non-blocking SocketChannel để liên lạc với bên kia(Nó có thể được tạo thẳng và có thể hay đổi bẳng việc dùng một Selector với non-blocking SocketChannel.) Đoạn code sau sẽ gửi chuỗi "hello" đến đầu bên kia, bằng việc viết mã nó sử dụng SSLEngine đã tạo trong ví dụ trước.Nó sử dụng thông tin từ SSLSession để định nghĩa độ lớn của byte buffers là bao nhiêu. // Tạo một non-blocking socket channel SocketChannel socketChannel = SocketChannel.open(); socketChannel.configureBlocking(false); socketChannel.connect(new InetSocketAddress(hostname, port)); // Hoàn tất việc kết nối while (!socketChannel.finishedConnect()) { // làm bất cứ gì cho đến khi kết nối hoàn tất } // Tạo byte buffers cho việc giữ ứng dụng và dữ liệu đã mã hóa SSLSession session = engine.getSession(); ByteBuffer myAppData = ByteBuffer.allocate(session.getApplicationBufferSize()); ByteBuffer myNetData = ByteBuffer.allocate(session.getPacketBufferSize()); ByteBuffer peerAppData = ByteBuffer.allocate(session.getApplicationBufferSize()); ByteBuffer peerNetData = ByteBuffer.allocate(session.getPacketBufferSize()); // Làm Handshake ban đầu doHandshake(socketChannel, engine, myNetData, peerNetData); myAppData.put("hello".getBytes()); myAppData.flip(); while (myAppData.hasRemaining()) { // Sinh ra dữ liệu mã hóa SSL/TLS (dữ liệu handshake hoặc ứng dụng) SSLEngineResult res = engine.wrap(myAppData, myNetData); // Xử lý trạng thái của bên gọi if (res.getStatus() == SSLEngineResult.Status.OK) { myAppData.compact(); // Gửi dữ liệu mã hóa SSL/TLS cho đầu bên kia while(myNetData.hasRemaining()) { int num = socketChannel.write(myNetData); if (num == -1) { // điều khiển đóng channel } else if (num == 0) { // Nếu không byte nào được viết thì thử lại lần nữa } } } // Điều khiển những trạng thái khác: BUFFER_OVERFLOW, CLOSED ... Secure Socket Layer 33
  • 34.
    PTIT 2009 Đề tài môn Bảo mật thông tin } Đoạn code sau đọc dữ liệu từ cùng non-blocking SocketChannel và lấy dữ liệu plaintext ra từ nó bằng cách dùng SSLEngine đã tạo trước đó.Mỗi vòng lặp của đoạn code có thể hoặc không sinh ra bất cứ dữ liệu paintext nào,phụ thuộc vào có hay không handshaking thì đang được xử lý. // Đọc dữ liệu mã hóa SSL/TLS từ đầu bên int num = socketChannel.read(peerNetData); if (num == -1) { // Điều khiển đóng channel } else if (num == 0) { // Không đọc được bytes nào ,thử lại . . . } else { // Xử lý dữ liệu vào peerNetData.flip(); res = engine.unwrap(peerNetData, peerAppData); if (res.getStatus() == SSLEngineResult.Status.OK) { peerNetData.compact(); if (peerAppData.hasRemaining()) { // Dùng peerAppData } } // Điều khiển các trạng thái khác: BUFFER_OVERFLOW, BUFFER_UNDERFLOW, CLOSED ... } II.2.7 Trạng thái của quá trình hoạt động : Để chỉ ra trạng thái của engine và những hành động mà ứng dụng nên có , phương thức SSLEngine.wrap() và SSLEngine.unwrap()trả lại một SSLEngineResult cụ thể,như trong ví dụ trước. SSLEngineResult chứa hai phần của thông tin trạng thái : trạng thái tổng thể cúa bộ máy và trạng thái handshaking. Những trạng thái tổng thể có thể có được biểu diễn bởi SSLEngineResult.Status enum. Một vài ví dụ của trạng thái này bao gồm Ok, có nghĩa la không có lỗi, và BUFFER_UNDERFLOW, có nghĩa là input buffer có dữ liệu chưa đủ, chỉ ra rằng ứng dụng cần thu thêm dữ liệu từ đầu bên (ví dụ như đọc thêm dữ liệu từ network). Những trạng thái handshaking có thể có thì được biểu diễn bởi the SSLEngineResult.HandshakeStatus enum.Chúng biểu diễn việc handshaking có hoàn thành hay chưa, có hay không bên gọi cần thu thêm dữ liệu handshaking từ đầu bên, gửi thêm dữ liệu handshaking cho đầu bên và vân vân. Mỗi kết quả của hai trạng thái cho phép engine chỉ ra rằng ứng dụng phải mang hai hành động : một là trả lời handshaking và một là biểu diễn trạng thái tổng thể của phương thức wrap()/unwrap() .Cho một ví dụ ,có thể engine , như là một kết quả của lệnh gọi đơn SSLEngine.unwrap() , trả về SSLEngineResult.Status.OK để chỉ ra rằng dữ liệu nhận vào đã xử lý thành công và SSLEngineResult.HandshakeStatus.NEED_UNWRAP chỉ ra rằng ứng dụng cần thu thêm dữ liệu mã hóa SSL/TLS từ đầu bên và cung cấp nó cho SSLEngine.unwrap() lần nữa để mà handshaking có thể tiếp tục.Như bạn thấy , ở ví dụ trước thì được đơn giản rất nhiều, chúng cần được phát triển đầy đủ để điều khiển chính xác tất cả trạng thái này. Secure Socket Layer 34
  • 35.
    PTIT 2009 Đề tài môn Bảo mật thông tin II.2.8 Blocking Tasks : Suốt quá trình Handshaking, SSLEngine có thể bắt gặp các tasks mà có thể block hay chiếm một thời gian dài.Cho ví dụ như một TrustManager có thể cần kết nối đến một dịch vụ phê chuẩn certificate từ xa, hay một KeyManager có thể cần thúc giục user để xác định certificate nào dùng để chứng thực client.Để giữ cho trạng thái tự nhiên của SSLEngine, khi engine gặp phải việc, nó sẽ trả về SSLEngineResult.HandshakeStatus.NEED_TASK. Trong lúc nhận trạng thái này,ứng dụng cần gọi SSLEngine.getDelegatedTask() để lấy task, sau đó sử dụng kiểu threading dành riêng cho yêu cầu của nó, xử lý task.Ứng dụng có thể thu thread từ một thread pool để xử lý task mà thread chính thường là đang đi điều khiển I/O khác. Đây là một ví dụ mà thực thi mỗi task trong một thread được tạo mới. if (res.getHandshakeStatus() == SSLEngineResult.HandshakeStatus.NEED_TASK) { Task có thể hoạt động; while ((task=engine.getDelegatedTask()) != null) { new Thread(task).start(); } } Engine sẽ block những lệnh call wrap/unwrap sẽ có cho đến khi tất tasks đang đứng bên ngoài được hoàn tất . II.2.9 Kết thúc : Cho một shutdown có trật tự của một kết nối SSL/TLS , giao thức SSL/TLS yêu cầu chuyển giao của close message.Vì vậy, khi một ứng dụng được thực hiện với kết nối SSL/TLS,nó nên thu close message trước tiên từ SSLEngine, sau đó truyền chúng cho đầu bên dùng cơ chế vận chuyển, và cuối cùng shut down cơ chế vận chuyển.Đây là một thí dụ // Chỉ ra ứng dụng được thực hiện với engine engine.closeOutbound(); while (!engine.isOutboundDone()) { // Nhận close message SSLEngineResult res = engine.wrap(empty, myNetData); // Kiển tra trạng thái // Gửi close message cho đầu bên while(myNetData().hasRemaining()) { int num = socketChannel.write(myNetData); if (num == -1) { // điều khiển đóng channel } else if (num == 0) { // không đọc được byte nào,thử lại lần nữa } myNetData().compact(); } } // Đóng transport socketChannel.close(); Thêm vào đó ứng dụng kết thúc SSLEngine một cách dứt khoát , SSLEngine có thể được đóng bởi đầu bên kia ( thông qua việc nhận một close message trong khi nó xử lý dữ liệu handshake) hoặc bằng cách SSLEngine bắt gặp một lỗi trong khi xử lý ứng dụng hoặc dữ liệu handshake, chỉ ra bởi một SSLException..Trong trường hợp như thế ,ứng dụng nên gọi SSLEngine.wrap()để lấy close message và gửi nó cho đầu bên đến khi SSLEngine.isOutboundDone() trả về true, như trong ví dụ trước , hoặc SSLEngineResult.getStatus() trả về CLOSED. Secure Socket Layer 35
  • 36.
    PTIT 2009 Đề tài môn Bảo mật thông tin Thêm vào việc shutdown có thứ tự thì cũng có kết thúc không theo thứ tự mà liên kết vận chuyển được cắt đứt trước khi close message được trao đổi.Trong ví dụ trước, ứng dụng có thể nhận -1 khi thử đọc hoặc viết non- blocking SocketChannel. Khi lấy hết dữ liệu nhận vào, bạn nên gọi engine.closeInbound(), mà sẽ xác minh với SSLEngine rằng đầu bên kia đã đóng hoàn toàn phối cảnh SSL/TLS ,và khi đó ứng dụng sẽ vẫn thử shutdown hoàn toàn bằng việc dùng kết quả ở trên.Hiển nhiên, không giống như SSLSocket, ứng dụng dùng SSLEngine phải dính líu tới nhiều chuyển tiếp trạng thái, tình trạng và lập trình hơn việc dùng SSLEngine. Hãy xem NIO-based HTTPS server để biết thêm thông tin về việc viết một ứng dụng SSLEngine cơ bản . II.2.10 SSLSession Interface : Một javax.net.ssl.SSLSession biểu diễn một ngữ cảnh bảo mật được thương lượng giữa hai đầu của một kết nối SSLSocket/SSLEngine. Mỗi một session thì được sắp xếp, nó có thể được chia sẻ bởi SSLSocket/Engines sắp tới kết nối giữa cùng cả hai bên. Session chứa cipher suite mà sẽ được dùng cho liên lạc một secure socket cũng như một non-authoritative gợi ý đến địa chỉ network của đầu bên, và thông tin quản lý như thời gian khởi tạo và lần dùng sau cùng. Session cũng chứa một shared master secret thương lượng giữa các bên về tạo khóa bí mật cho việc mã hóa và đảm bảo sự toàn vẹn của liên lạc thông qua một SSLSocket/SSLEngine. Giá trị của master secret này được biết chỉ được biết cho việc thực thi secure socket bên dưới và nó không bị lộ qua SSLSession API. II.2.11 Lớp HttpsURLConnection : Giao thức https thì tương tự như http, nhưng https trước hết khởi tạo một secure channel thông qua SSL/TLS sockets và xác thực đầu cuối trước khi yêu cầu hoặc nhận dữ liệu . javax.net.ssl.HttpsURLConnection mở rộng lớp java.net.HttpsURLConnection, và thêm vào hỗ trợ cho đặc trưng riêng https . Xem lớp java.net.URL ,java.net.URLConnection,java.net.HttpURLConnection , và javax.net.ssl.HttpURLConnection , để biết thêm thông tin về như thế nào https URLs được xây dựng và sử dụng . Trong lúc nhận một HttpsURLConnection, bạncó thể cấu hình một số thông số của http/https trước khi khởi tạo kết nối network trên thực tế thông qua phương thức URLConnection.connect. Những chú ý chi tiết là: Tùy chỉnh SSLSocketFatory chỉ định Tùy chỉnh HostnameVerifier chỉ định Tùy chỉnh SSLSocketFactory chỉ định Trong một vài trường hợp , nó thì muốn chỉ định SSLSocketFactory rằng một HttpsURLConnection sử dụng riêng. Ví dụ bạn có thể muốn đào xuyên qua một dạng proxy mà không được hổ trợ bởi việc thực thi không đầy đủ . SSLSocketFactory mới có thể trả về những sockets mà đóng vai trò tất cả các tunneling cần thiết , vì vậy cho phép HttpsURLConnection dùng các proxy bổ sung. Lớp HttpsURLConnection có một SSLSocketFactory mặc định mà chỉ định khi nào lớp được load .( Trong trường hợp nó là factory được trả về từ phương thức SSLSocketFactory.getDefault.) Trường hợp đặc biệt có thể có của HttpsURLConnection sẽ thừa hưởng SSLSocketFactory mặc định của hiện tại cho đến khi một SSLSocketFactory mặc định mới được chỉ định cho lớp thông qua phương thức tĩnh HttpsURLConnection.setDefaultSSLSocketFactory. Mỗi trường hợp của HttpsURLConnection thì được tạo , SSLSocketFactory được kế thừa trong trường hợp này có thể được gửi qua bên gọi qua phương thức setSSLSocketFactory . Lưu ý rằng việc thay đổi SSLSocketFactory tĩnh mặc định thì không tác động lên trường hợp đang có của HttpsURLConnections, một lệnh gọi phương thức setSSLSocketFactory thì cần thiết để thay đổi trường hợp đang có. Secure Socket Layer 36
  • 37.
    PTIT 2009 Đề tài môn Bảo mật thông tin Một cách khác có thể thu mỗi trường hợp hoặc mỗi lớp SSLSocketFactory bằng việc tạo một lệnh gọi phương thức getSSLSocketFactory/getDefaultSSLSocketFactory , tương ứng từng cái một. Tùy chỉnh HostnameVerifier chỉ định Nếu hostname của URL không trùng với hostname trong xác minh được nhận như một phần của SSL/TLS handshake, nó có thể xảy ra URL spoofing.Nếu việc thực thi không thể xác minh hostname với lý do chắc chắn, việc thực thi SSL sẽ thực thi một lệnh gọi lại HostnameVerifier chỉ định của trường hợp cho kiểm tra. Việc xác nhận hostname có thể thực thi ở bất cứ bước nào cần thiết để làm quyết định, như là thực thi việc so sánh mẫu hostname xen kẽ hay có lẽ pop up một dialog box tương tác. Một việc xác minh không thành công bởi việc kiểm tra hostname sẽ đóng kết nối sẽ đóng kết nối.(Xem RFC 2818 để biết thêm thông tin liên quan đến việc xác minh hostname.) Phương thức setHostnameVerifier/setDefaultHostnameVerifier hoạt động cùng một kiểu phương thức setSSLSocketFactory/setDefaultSSLSocketFactory , trong đó có chỉ định trên mỗi trường hợp và mỗi lớp cơ bản, và giá tri hiện thời có thể được thu bởi một lệnh gọi phương thức getHostnameVerifier/getDefaultHostnameVerifier . II.3 Các Class và Interface hỗ trợ : Các lớp hỗ trợ và giao diện trong section này được cung cấp để hỗ trợ việc tạo ra và thiết lập các đối tượng SSLContext,mà được dùng để tạo các đối tượng SSLSocketFactory,SSLServerSocketFactory,và SSLEngine.Các lớp hỗ trợ và các giao diện là 1 phần của gói javax.net.ssl 3 trong số các lớp này mô tả trong section này(SSLContext,KeyManagerFactory,và TrustManagerFactory) là các lớp engine(cơ cấu).1 lớp engine là 1 lớp API dùng cho các giải thuật xác định(hoặc các giao thức,trong trường hợp của SSLContext),cho cái mà các công cụ có thể được cung cấp trong một hay nhiều gói Cryptographic Service Provider(nhà cung cấp). Nhà cung cấp SunJSSE đem đến nhiều tiêu chuẩn với JSSE cung cấp SSLContext,KeyManagerFactory,và các công cụ TrustManagerFactory,cũng như các công cụ cho các lớp engine theo chuẩn bảo mật Java(java.security) API.Các công cụ được cung cấp bởi SunJSSE là : Lớp engine đƣợc thực hiện Giải thuật hoặc giao thức KeyFactory “RSA” KeyPairGenerator “RSA” KeyStore “PKCS12” Signature “MD2withRSA”,”MD5withRSA”,”SHA1withRSA” KeyManagerFactory “SunX509”,”NewSunX509” TrustManagerFactory “SunPKIX”(aka “X509”/”PKIX”),”SunX509” SSLContext “SSLv3”(aka “SSL”),”TSLv1”(aka “TLS”) Secure Socket Layer 37
  • 38.
    PTIT 2009 Đề tài môn Bảo mật thông tin II.3.1 Lớp SSLContext : Javax.net.ssl.SSLContext là 1 lớp engine cho việc thực thi của 1 giao thức SSL.Một thực thể của lớp này hành động như 1 factory cho các SSL socket factories và SSL engine.Một SSLContext giữ tất cả các thông tin trạng thái được chia sẻ qua tất cả các đối tượng được tạo dưới ngữ cảnh này.Ví dụ,trạng thái phiên được kết hợp với SSLContext khi nó thỏa thuận thông qua giao thức bắt tay bằng socket được tạo bởi socket factories cung cấp bởi ngữ cảnh.Những phiên được lưu có thể được tái sử dụng và chia sẻ bởi các socket khác được tạo dưới cùng ngữ cảnh. Mỗi thực thể được cấu hình thông qua phương thức khởi tạo init với các khóa,chuỗi chứng thực,và các chứng thực CA gốc được tin cậy mà nó cần để biểu diễn xác thực.Cấu hình này được cung cấp dưới dạng các manager đáng tin cậy và khóa.Những manager này cung cấp hỗ trợ cho việc xác thực và các khía cạnh thỏa thuận khóa của các cipher suite được hỗ trợ bởi ngữ cảnh. Hiện tại chỉ hỗ trợ X509 dựa trên các manager . Việc tạo 1 đối tượng SSLContext Giống như các provider JCA dựa trên các lớp engine,các đối tượng SSLContext được tạo sử sụng phương thức factory getInstanse của lớp SSLContext.Những phương thức tĩnh này mỗi cái trả về 1 thực thể mà thực hiện ít nhất 1 giao thức SSL được yêu cầu.Thực thể trả về cũng có thể thực hiện giao thức khác.Ví dụ,getInstance(“SSLv3”) có thể trả về 1 thực thể mà thực hiện “SSLv3” và “TLSv1”.Phương thức getSupportedProtocols trả về 1 danh sác các giao thức hỗ trợ khi 1 SSLSocket,SSLServerSocket hoặc SSLEngine được tạo từ ngữ cảnh này.Bạn có thể kiểm soát cái mà các giao thức thực sự dùng cho kết nối SSL bằng cách sử dụng phương thức setEnabledProtocols(String[] protocols). Note: 1 đối tượng SSLContext được tạo ra tự động,được khởi tạo và đánh dấu tĩnh đối với lớp SSLSocketFactory khi bạn gọi SSLSocketFactory.getDefault.Vì vậy,bạn không cần phải tạo trực tiếp và khởi tạo 1 đối tượng SSLContext(nếu bạn không muốn ghi đè lên thuộc tính mặc định). Để tạo 1 đối tượng SSLContext bằng cách gọi 1 phương thức factory getInstance,bạn có thể xác định tên giao thức.bạn cũng có thể xác định các mà nhà cung cấp muốn bạn cung cấp cách thực hiện giao thức yêu cầu: public static SSLContext getInstance(String protocol); public static SSLContext getInstance(String protocol,String provider); public static SSLContext getInstance(String protocol,Provider provider); Nếu chỉ có 1 tên giao thức được xác định,hệ thống sẽ xác định nếu có 1 cách thực hiện của giao thức được yêu cầu sẵn có trong môi trường,và nếu có nhiều hơn 1,nếu có 1 cái là được thích hợp hơn cả… Nếu cả 1 tên giao thức và nhà cung cấp đều được chỉ định,hệ thống sẽ xác định nếu có 1 cách thực thi lên các giao thức trong provider được yêu cầu, và đưa ra 1 ngoại lê nếu không có. Một giao thức là 1 chuỗi(như “SSL”) mô tả giao thức SSL mong muốn.Tên giao thức chung danh cho các đối tượng SSLContext: Secure Socket Layer 38
  • 39.
    PTIT 2009 Đề tài môn Bảo mật thông tin Protocol Comment SSL Hỗ trợ những version của SSL; có thể hỗ trợ một số version khác SSLv2 Hỗ trợ SSL version 2 hoặc cao hơn SSLv3 Hỗ trợ SSL version 3; có thể hỗ trợ một số version khác TLS Hỗ trợ những version của TLS; có thể hỗ trợ một số version khác TLSv1 Hỗ trợ TLS version 1; có thể hỗ trợ một số version khác Sau đây là 1 vài ví dụ về thu được 1 SSLContext: SSLContext sc = SSLContext.getInstance("SSL"); SSLContext đc tạo mới nên được khởi tạo bằng cách gọi phương thức init: public void init(KeyManager[] km , TrustManager[] tm , SecureRandom random); Nếu tham số KeyManager[] là null,thì 1 KeyManager rỗng sẽ được định nghĩa cho ngữ cảnh này.Nếu tham số TrustManager[] là null,các provider bảo mật được cài đặt sẽ được tìm kiếm cho việc thực hiện có độ ưu tiên cao nhất của TrustManagerFactory,từ đó 1 TrustManager thích hợp sẽ được thu đượcc.Theo cách đó,tham số SecureRandom sẽ là null,trong trường hợp ta thực hiện mặc định. Nếu ta dùng ngữ cảnh được khởi tạo mặc định(như SSLContext được tạo bởi SSLSocketFactory .getDefault() hoặc SSLServerSocketFactory.getDefault()),1 KeyManager mặc định và 1 TrustManager được tạo ra.Ta chon việc thực hiện SecureRandom mặc định. II.3.2 TrustManager Interface : Trách nhiệm cơ bản của TrustManager là xác định thử xem giấy ủy quyền xác thực được đưa ra có phải là đáng tin cậy.Nếu giấy ủy quyền không đáng tin,kết nối sẽ bị kết thúc.Để xác thực thực thể từ xa của 1 điểm đầu cuối socket bảo mật,bạn cần phải khởi tạo 1 đối tượng SSLContext với 1 hoặc nhiều TrustManager.Bạn cần vượt qua 1 TrustManager cho mỗi cơ chế xác thực mà được hỗ trợ.Nếu giá trị null được gửi vào việc khởi tạo,1 trust manager sẽ được tạo ra cho bạn.Thông thường,có 1 trust manager đơn hỗ trợ xác thực dựa trên chứng thực khóa công khai X.509 (như X509TrustManager).Một vài secure socket implement cũng hỗ trợ xác thực dựa trên việc chia sẻ khóa bí mật,như Kerberos,hoặc 1 vài cơ chế khác. TrustManager được tạo hoặc là bằng TrustManagerFactory,hoặc bằng việc cung cấp 1 thực hiện cụ thể của interface. II.3.3 Lớp TrustManagerFactory : Javax.net.ssl.TrustManagerFactory là 1 lớp engine dùng cho 1 provider dựa trên dịch vụ mà hành động như 1 factory cho 1 hay nhiều kiểu đối tượng TrustManager .Vì nó là provider cơ sở,các factory bổ sung có thể được thực hiện và cấu hình mà cung cấp các trust manager thêm vào và luân phiên mà cung cấp nhiều dịch vụ phức tạp hoặc thực hiện các policy xác thực được cài đặt cụ thể. Tạo 1 TrustManagerFactory: Secure Socket Layer 39
  • 40.
    PTIT 2009 Đề tài môn Bảo mật thông tin Bạn tạo 1 thực thể của lớp này theo kiểu tương tự với SSLContext,ngoại trừ việc thông qua 1 chuỗi tên giải thuật thay vì tên 1 giao thức với phương thức getInstance: public static TrustManagerFactory getInstance(String algorithm); public static TrustManagerFactory getInstance(String algorithm, String provider); public static TrustManagerFactory getInstance(String algorithm, Provider provider); Chuỗi tên giải thuật mẫu là: “PKIX” Gọi hàm theo mẫu sau : TrustManagerFactory tmf = TrustManagerFactory.getInstance("PKIX", "SunJSSE"); Việc gọi ở trên sẽ tạo ra 1 thực thể của trust manager factory PKIX của nhà cung cấp SunJSSE.Factory này sau đó có thể dùng để tạo trust manager mà cung cấp kiểm tra tính hợp lệ đường dẫn chứng thực X.509 PKIX cơ sở. Khi khởi tạo 1 SSLContext,bạn có thể dùng các trust manager được tạo ra từ 1 trust manager factory,hoặc bạn có thể viết trust manager của chính bạn,có thể sử dụng CertPath API.Bạn không cần phải dùng trust manager factory nếu bạn thực hiện 1 trust manager sử dụng giao diện X509TrustManager. 1 factory được tạo mới nên được khởi tạo bằng cách gọi 1 trong những phương thức init: public void init(KeyStore ks); public void init(ManagerFactoryParameters spec); Bạn nên gọi bất của phương thức init nào phù hợp với TrustManagerFactory bạn đang dùng(Hỏi nhà cung cấp). Đối với nhiều factory,như “SunX509” TrustManagerFactory từ nhà cung cấp SunJSSE,KeyStore chỉ là thông tin được yêu cầu để khởi tạo TrustManagerFactory và vì vậy phương thức init đầu tiên là phương thức phù hợp để gọi.TrustManagerFactory sẽ truy vấn KeyStore cho thông tin theo đó chứng thực từ xa nên được tin cậy trong suốt quá trình kiểm tra xác thực. Trong 1 vài trường hợp nhà cung cấp cần các tham số khởi tạo KeyStore.Các user của nhà cung cấp đặc biệt được mong đợi để thông qua việc thực hiện ManagerFactoryParameters phù hợp như đã định nghĩa bởi nhà cung cấp.Nhà cung cấp sau đó có thể gọi các phương thức cụ thể trong việc thực hiện ManagerFactoryParameters để thu được thông tin cần thiết. Ví dụ,giả sử nhà cung cấp TrustManagerFactory yêu cầu các tham số khởi tạo B,R và S từ bất cứ ứng dụng nào mà mong để dùng nhà cung cấp đó.Giống như tất cả các nhà cung cấp yêu cầu các tham số khởi tạo như KeyStore,nhà cung cấp sẽ yêu cầu ứng dụng cung cấp các thực thể của 1 lớp mà việc thực hiện 1 sub-interface ManagerFactoryParameters riêng biệt.Trong ví dụ của chúng ta,giả sử nhà cung cấp yêu cầu rằng việc thực hiện ứng dụng gọi và tạo thực thể của MyTrustManagerFactoryParams và gửi nó vào phương thức init thứ 2.Ở đây là những gì MyTrustManagerFactoryParams có thể thể hiện: public interface MyTrustManagerFactoryParams extends ManagerFactoryParameters { public boolean getBValue(); public float getRValue(); public String getSValue(): } Secure Socket Layer 40
  • 41.
    PTIT 2009 Đề tài môn Bảo mật thông tin Một vài trustmanager có thể tạo 1 quyết định đáng tin cậy mà không phải khởi tạo tường minh với 1 đối tượng KeyStore hoặc bất kỳ tham số nào khác.ví dụ,chúng có thể truy cập nguyên liệu đáng tin cậy từ dịch vụ danh mục cục bộ thông qua LDAP,có thể sử dụng 1 trạng thái chứng thực trực tuyến từ xa hoặc có thể truy cập nguyên liệu tin cậy mặc định từ 1 vị trí cục bộ chuẩn. Hỗ trợ PKIX TrustManager: Trust manager factory CertPath dựa trên X.509 được gọi là “SunPKIX” được thêm vào.SunPKIX là có sẵn cùng với trust manager factory X.509 mặc định mà đơn giản được biết như là “SunX509”. Trong J2SE 5,bây giờ SunPKIX là X509TrustManagerFactory mặc định.Nó được chọn bởi các thuộc tính ssl.TrustManagerFactory.algorithm trong file java.security(để trở lại sử dụng trust manager cũ,theo thủ tục trong Customizing the Default Key and Trust Manager để thay đổi thuộc tính từ PKIX đến SunX5.09).Chú ý rằng sự thay đổi này chỉ ảnh hưởng đến các ứng dụng mà sử dụng trust mananager mặc định,nó ko ảnh hưởng đến các ứng dụng mà trust manager cụ thể tường minh với SSLContext.init(…,TrustManager[],…).Cách khác,SunPKIX factory có thể được truy cập một cách có lập trình bằng cách gọi TrustManagerFactory.getInstance(“SunPKIX”). PKIX trust manager factory sử dụng CertPath PKIX implementation từ 1 nhà cung cấp bảo mật được cài đặt.,1 nhà cung cấp “SUN” CertPath được cung cấp với bộ J2SE 5 Development Kit.Trust manager factory có thể được khởi tạo sử dụng phương thức init(KeyStore ks) thông thường,hoặc bằng cách gửi vào các tham số CertPath cho PKIX trust manager sử dụng lớp được giới thiệu mới javax.net.ssl.CertpathTrustmanagerparameters. Đây là ví dụ về lam cách nào để lấy trust manager để sử dụng 1 lưu trữ chứng thực LDAP riêng biệt và kích hoạt bộ kiểm tra thu hồi. import javax.net.ssl.*; import java.security.cert.*; import java.security.KeyStore; ... // Tạo tham số PKIX KeyStore anchors = KeyStore.getInstance("JKS"); anchors.load(new FileInputStream(anchorsFile)); CertPathParameters pkixParams = new PKIXBuilderParameters(anchors, new X509CertSelector()); // Chỉ định nơi LDAP certificate để dùng LDAPCertStoreParameters lcsp = new LDAPCertStoreParameters("ldap.imc.org", 389); pkixParams.addCertStore(CertStore.getInstance("LDAP", lcsp)); // Chỉ định rằng việc kiểm tra thu hồi thì được kích hoạt pkixParams.setRevocationEnabled(true); // Gói chúng lại như thông số Trust manager ManagerFactoryParameters trustParams = Secure Socket Layer 41
  • 42.
    PTIT 2009 Đề tài môn Bảo mật thông tin new CertPathTrustManagerParameters(pkixParams); // Tạo TrustManagerFactory cho PKIX phục vụ cho trust manager TrustManagerFactory factory = TrustManagerFactory.getInstance("PKIX"); // Chuyển thông số cho factory để được chuyển cho việc thực thi CertPath factory.init(trustParams); // Dùng factory SSLContext ctx = SSLContext.getInstance("TLS"); ctx.init(null, factory.getTrustManagers(), null); Nếu phương thức init(KeyStore ks) được dùng,các tham số PKIX mặc định được dùng với ngoại lệ rằng bộ kiểm tra thu hồi bị vô hiêu.Nó có thể được kích hoạt bằng cách lập thuộc tính hệ thống com.sun.net.ssl.checkRevocation thành true.Chú ý rằng việc thiết lập này yêu cầu CertPath implementation tự nó có thể xác định vị trí thông tin thu hồi.PKIX implementation trong nhà cung cấp SUN có thể làm những điều này trong nhiều trường hợp nhưng yêu cầu rằng thuộc tính hệ thống com.sun.security.enableCRLDP được lập thành true. II.3.4 X509TrustManager Interface : Interface javax.net.ssl.X509TrustManager là mở rộng của interface cơ bản TrustManger .Interface này phải được thực hiện bằng 1 trust manager khi sử dụng X.509 dựa trên xác thực. Để hỗ trợ xác thực X.509 của điểm đầu cuối socket ở xa thông qua JSSE,và thực thể của interface này phải được gửi vào phương thức init của đối tượng SSLContext. Tạo một X509TrustManager Bạn có thể hoặc là tự bạn thực hiện giao diện này trực tiếp hoặc thu nhận 1 từ 1 nhà cung cấp dựa trênTrustManagerFactory (như được cung cấp bởi nhà cung cấp SunJSSE).bạn có thể cũng thực hiện giao diện của bạn mà ủy quyền cho 1 factory tạo ra trust manager.Ví dụ,bạn có thể làm điều này để lọc kết quả quyết định tin cậy và truy vấn 1 user đầu cuối thông qua 1 giao diện đồ họa người dùng. Chú ý: nếu 1 tham số null KeyStore được gửi vào SunJSSE “SunX509” hoặc “SunPKIX” TrustManagerFactory,factory sử dụng các bước theo sau để cố gắng tìm kiếm nguyên liệu tin cậy: 1.Nếu là thuộc tính hệ thống: javax.net.ssl.trustStore được định nghĩa,sau đó TrustManagerFactory nỗ lực để tìm 1 file sử dụng tên file cụ thể bằng thuộc tính hệ thống,và sử dụng file đó cho KeyStore.Nếu thuộc tính hệ thống javax.net.ssl.trustStorePassword cũng được định nghĩa,giá trị của nó được dùng để kiểm tra tính toàn vẹn dữ liệu trong truststore trước khi mở nó. Nếu javax.net.ssl.trustStore được định nghĩa nhưng các file xác định không tồn tại,thì 1 TrustManager mặc định sử dụng 1 keystore rỗng được tạo. 2. Nếu thuộc tính hệ thống javax.net.ssl.trustStore không được xác định,thì nếu file: <java-home>/lib/security/jssecacerts tồn tại,file đó được dùng. Secure Socket Layer 42
  • 43.
    PTIT 2009 Đề tài môn Bảo mật thông tin 3. Nếu file: <java-home>/lib/security/cacerts tồn tại,file đó được dùng. (Nếu các file này đều không tồn tại,điều này có thể xảy ra ổn thỏa,vì có các cipher suite SSL mà ngầm định,mà không làm bất cứ xác thực nào và vì vậy không cần 1 truststore.) Factory tìm kiếm 1 file cụ thể cùng với thuộc tính bảo mật javax.net.ssl.trustStore hoặc cho file jssecacerts trước khi kiểm tra 1 file cacerts để mà bạn có thể cung cấp 1 tập JSSE cụ thể của chứng thực gốc đáng tin cậy mở rộng từ chúng mà có thể được trình diễn trong cacerts cho các mục đích code-signing. Tạo ra X509TrustManager của riêng bạn: Nếu hành vi được cung cấp X509TrustManager không phù hợp với tình huống của bạn,bạn có thể tạo ra X509TrustManager của riêng bạn bằng cách hoặc là tạo và đăng ký TrustManagerFactory của riêng bạn hoặc là bằng cách thực hiện giao diện X509TrustManager trực tiếp. Lớp MyX509TrustManager sau đây làm tăng hành vi SunJSSE X509 TrustManager mặc định bằng cách cung cấp xác thực có thể thay đổi 1 cách logic khi SunJSSE X509 TrustManager mặc định hỏng: class MyX509TrustManager implements X509TrustManager { /* * X509TrustManager mặc định được trả về bởi SunX509. Chúng ta sẽ ủy quyền * quyết định cho nó, và phải dùng đến tính logic trong Class nếu * X509TrustManager mặc định không tin tưởng nó. */ X509TrustManager sunJSSEX509TrustManager; MyX509TrustManager() throws Exception { // Tạo một JSSE X509TrustManager mặc định. KeyStore ks = KeyStore.getInstance("JKS"); ks.load(new FileInputStream("trustedCerts"), "passphrase".toCharArray()); TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509", "SunJSSE"); tmf.init(ks); TrustManager tms [] = tmf.getTrustManagers(); /* * Lặp lại trustmanagers được trả về, tìm kiếm * một trường hợp của X509TrustManager. Nếu tìm thấy, * dùng nó như là trust manager mặc định của chúng ta. */ for (int i = 0; i < tms.length; i++) { if (tms[i] instanceof X509TrustManager) { sunJSSEX509TrustManager = (X509TrustManager) tms[i]; return; } } /* * Tìm vài cách khác để khởi tạo hoặc là chúng ta sẽ phải làm hỏng * việc xây dựng. */ throw new Exception("Couldn't initialize"); } /* Secure Socket Layer 43
  • 44.
    PTIT 2009 Đề tài môn Bảo mật thông tin * Ủy nhiệm đến trust manager mặc định. */ public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException { try { sunJSSEX509TrustManager.checkClientTrusted(chain, authType); } catch (CertificateException excep) { // Làm bất cứ xử lý đặc biệt ở đây hoặc xem lại ngoại lệ } } /* * Ủy quyền cho trust manager mặc định. */ public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { try { sunJSSEX509TrustManager.checkServerTrusted(chain, authType); } catch (CertificateException excep) { /* * Có thể pop up một dialog box hỏi có hay không tin tưởng * chuỗi cert */ } } /* * Chỉ đơn giản thông qua việc này. */ public X509Certificate[] getAcceptedIssuers() { return sunJSSEX509TrustManager.getAcceptedIssuers(); } } Một khi bạn tạo ra 1 trust manager như thế,gán nó cho 1 SSLContext thông qua phương thức khởi tạo.SocketFactories tương lai được tạo từ SSLContext này sẽ sử dụng TrustManager mới của bạn khi tạo các quyết định đáng tin cậy. TrustManager[] myTMs = new TrustManager []{new MyX509TrustManager() }; SSLContext ctx = SSLContext.getInstance("TLS"); ctx.init(null, myTMs, null); Cập nhật keyStore động: Bạn có thể làm tăng MyX509TrustManager để điều khiển cập nhật keystore động.Khi một checkClientTrusted hoặc checkServerTrusted kiểm tra có lỗi và không thiết lập 1 chuỗi chứng thực đáng tin cậy,bạn có thể thêm vào chứng thực đáng tin cậy được yêu cầu cho keystore.Bạn cần tạo 1 sunX509TrustManager mới từ TrustManagerFactory được khởi tạo với keystore được cập nhật.Khi bạn thiết lập 1 kết nối mới(sử dụng SSLContext khởi tạo trước đó),chứng chỉ thêm vào mới sẽ được gọi để tạo các quyết định đáng tin cậy. II.3.5 KeyManager Interface : Trách nhiệm chính của của KeyManager là chọn giấy ủy quyền chứng thực mà sẽ kết luận cuối cùng rằng được gửi đi đến host ở xa.Để xác thực bản thân bạn(điểm đầu cuối socket bảo mật cục bộ) đến 1 điểm đầu cuối ở xa,bạn cần khởi tạo 1 đối tượng SSLContext với 1 hoặc nhiều KeyManagers.Bạn cần gửi 1 KeyManager đối với mỗi cơ chế xác thực sẽ được hỗ trợ.Nếu giá trị null được gửi vào việc khỏi tạo SSLContext,1 KeyManager rỗng sẽ được tạo.Nếu ngữ cảnh mặc định bên trong được dùng(như SSLContext được tạo bởi SSLSocketFactory.getDefalut() hoặc SSLServerSocketFactory.getDefault()),1 KeyManager mặc định được tạo.Điển hình,có 1 key manager đơn hỗ Secure Socket Layer 44
  • 45.
    PTIT 2009 Đề tài môn Bảo mật thông tin trợ xác thực dựa trên các chứng thực khóa công khai X.509.Một vài secure socket implement cũng có thể hỗ trợ xác thực dựa trên các khóa bí mật được chia sẻ,Kerberos,hay các cơ chế khác. Các KeyManager được tạo ra hoặc bằng KeyManagerFactory,hoặc bằng việc cung cấp 1 thực thi cụ thể của interface. II.3.6 Lớp KeyManagerFactory : Javax.net.ssl.KeyManagerFactory là 1 lớp engine cho người cung cấp dựa trên dịch vụ mà hành động như 1 factory cho 1 hoặc nhiều kiểu đối tượng KeyManager.Người cung cấp SunJSSE thực thi 1 factory có thể trả về 1 key manager X.509 cơ sở.Vì đó là nhà cung cấp cơ sở,các factory thêm vào có thể được thực hiện và cấu hình để cung cấp các key manager có thể thêm vào hay thay đổi. Tạo 1 KeyManagerFactory Bạn tạo 1 thực thể của lớp này theo 1 kiểu tương tự như SSLContext,ngoại trừ gửi vào chuỗi tên giải thuật thay vì tên của giao thức phương thức getInstance: public static KeyManagerFactory getInstance(String algorithm); public static KeyManagerFactory getInstance(String algorithm, String provider); public static KeyManagerFactory getInstance(String algorithm, Provider provider); 1 chuỗi tên giải thuật mẫu như sau: “SunX509” Gọi phương thức như sau: KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509", "SunJSSE"); Cách gọi ở trên sẽ tạo ra 1 thực thể của key manager factory mặc định của nhà cung cấp SunJSSE, mà cung cấp X509 cơ sở dựa trên các khóa xác thực. 1 factory được tạo mới nên được khởi tạo bằng cách gọi 1 trong những phương thức init sau: public void init(KeyStore ks, char[] password); public void init(ManagerFactoryParameters spec); Bạn nên gọi bất cứ cái gì mà phương thức init phù hợp cho KeyManagerFactory bạn đang sử dụng.(Hỏi nhà cung cấp ) Đối với nhiều factory,như “SunX509” mặc định KeyManagerFactory từ nhà cung cấp SunJSSE, KeyStore và mật khẩu chỉ là thông tin được yêu cầu để khởi tạo KeyManagerFactory và vì vậy phương thức init đầu tiên là phương thức thích hợp để gọi.KeyManagerFactory sẽ truy vấn KeyStore vì các thông tin trên khóa bí mật và liên kết các chứng chỉ khóa công khai nên được dùng cho việc xác thực đến 1 điểm đầu cuối socket từ xa.Tham số password xác định mật khẩu sẽ dùng với các phương thức cho truy cập khóa từ KeyStore.Tất cả các khoá trong KeyStore phải được bảo vệ bằng mật khẩu giống nhau. Trong 1 vài trường hợp,các tham số khởi tạo như KeyStore và mật khẩu có thể cần thiết đối với nhà cung cấp.Người sử dụng của nhà cung cấp riêng biệt đó được mong đợi vượt qua việc thực thi của ManagerFactoryParameters phù hợp như được định nghĩa bởi nhà cung cấp.Sau đó nhà cung cấp có thể gọi các phương thức cụ thể trong việc thực thi ManagerFactoryParameters để thu được thông tin cần thiết. Secure Socket Layer 45
  • 46.
    PTIT 2009 Đề tài môn Bảo mật thông tin Một vài factory có thể cung cấp truy cập đến nguyên liệu xác thực mà không phải khởi tạo với 1 đối tượng KeyStore hoặc bất kỳ tham số nào khác.Ví dụ,họ có thể truy cập nguyên liệu khóa như là 1 phần của cơ chế login như là 1 cơ chế dựa trên JAAS(Java Authentication and Authorization Service) Như đã dẫn ở trên, nhà cung cấp SunJSSE hỗ trợ 1 factory “SunX509” mà phải được khởi tạo với 1 tham số KeyStore. II.3.7 X509KeyManager Interface : Interface javax.net.ssl.X509Manager mở rộng interface cơ sở KeyManager.Nó phải được thực hiện bởi 1 key manager cho X509 dựa trên xác thực.Để hỗ trợ xác thực X509 để điều khiển các điểm đầu cuối socket thông qua JSSE, 1 thực thể của interface này phải được gửi vào phương thức init của đối tượng SSLContext. Tạo 1 X509KeyManager: Bạn có thể hoặc là thực thi interface này 1 cách trực tiếp hoặc nhận nó từ 1 nhà cung cấp dựa trên KeyManagerFactory(như các interface được cung cấp bởi nhà cung cấp SunJSSE).Bạn cũng có thể thực thi của riêng bạn ủy quyền đến 1 factory sinh ra key manger.Ví dụ,bạn có thể làm điều này để lọc các key kết quả và truy vấn user đầu cuối thông qua 1 interface đồ họa người dùng. Chú ý: Nếu không có tham số KeyStore được gửi qua SunJSSE mặc định “SunX509” KeyManagerFactory,factory cố gắng tìm nguyên liệu khóa bằng cách tham khảo các thuộc tính hệ thống: javax.net.ssl.keyStore javax.net.ssl.keyStorePassword Nếu những thuộc tính này xác định 1 file với 1 password phù hợp,factory sử dụng file này cho KeyStore.Nếu file đó ko tồn tại,thì 1 KeyManager mặc định sử dụng 1 keystore rỗng được tạo. Thông thường,qua trình diễn ra trên server trong giao thức bắt tay sẽ cần 1 keystore cho KeyManager của nó để nhận giấy ủy nhiệm để xác thực với client.Tuy nhiên,nếu 1 trong số cipher suite ngầm định được chọn,keystore KeyManager của server không cần thiết.Và,nếu server không yêu cầu client xác thực,quá trình diễn ra khi client không cần keystore KeyManager.Vì vậy,trong những tình huống này nó có thể ổn nếu không có giá trị thuộc tính hệ thống javax.net.ssl.keyStore nào được định nghĩa. Tạo X509KeyManager của riêng bạn: Nếu hành vi mặc định X509KeyManager không phù hợp với tình huống của bạn,bạn có thể tạo X509KeyManager của mình theo cách tương tự với việc tạo X509TrustManager. II.3.8 Mối liên hệ TrustManagers và KeyManagers : Tóm lại,sau đây là các trách nhiệm sơ khảo của mỗi kiểu manager: Type Function Xác định thử xem xác thực credentials ở xa nào(và cả TrustManager kết nối) nên được tin cậy KeyManager Xác định xác thực credentials nào để gửi cho host ở xa. Secure Socket Layer 46
  • 47.
    PTIT 2009 Đề tài môn Bảo mật thông tin II.4 Các Class và Interface hỗ trợ thứ cấp : Những lớp này được cung cấp như là 1 phần của JSSE API để hỗ trợ việc tạo,sử dụng và quản lý các socket bảo mật.Chúng hầu như không được sử dụng bởi những ứng dụng socket bảo mật hơn là các lớp hỗ trợ và các lớp lõi.Các lớp và các interface hỗ trợ thứ cấp là 1 phần của các gói javax.net.ssl và javax.security.cert II.4.1 SSLSessionContext Interface : Javax.net.ssl.SSLSessionContext là 1 nhóm của SSLSession kết hợp với 1 thực thể đơn.Thí dụ,nó có thể kết hợp với 1 server hay client tham gia vào nhiều session đồng thời.Các phương thức trên giao diện này kích hoạt sự liệt kê các session trong 1 context và cho phép kiểm tra các session đặc biệt với session id của chúng. 1 SSLSessionContext có thể được nhận từ 1 SSLSession bằng cách gọi SSLSession phương thức getSessionContext. Context có thể không hợp lệ trong 1 vài môi trường,mà trong trường hợp đó phương thức getSessionContext trả về giá trị null. II.4.2 SSLSessionBindingListener Interface : Javax.net.ssl.SSLSessionBindingListener là 1 interface được thực hiện bởi các đối tượng muốn được chú ý khi chúng được kết nối hoặc không đc kết nối từ 1 SSLSession. II.4.3 Lớp SSLSessionBindingEvent : Javax.net.ssl.SSLSessionBindingEvent là 1 sự kiện giao tiếp với 1 SSLSessionBindingListener khi nó được kết nối hoặc không kết nối từ 1 SSLSession. II.4.4 HandShakeCompletedListener Interface : javax.net.ssl.handShakeCompletedListener là 1 interface được thực hiện bởi bất kì lớp nào muốn nhận thông tin chú ý của việc hoàn thành giao thức bắt tay SSL trên kết nối SSLSocket được đưa ra. II.4.5 Lớp SSLHandShakeCompletedEvent : Javax.net.ssl.HandShakeCompletedEvent là 1 sự kiện giao tiếp với HandShakeCompletedListener nhờ vào sự hoàn thành của 1 giao thức bắt tay SSL trên 1 kết nối SSLSocket được đưa ra. II.4.6 HostnameVerifier Interface : Nếu việc xác nhận hostname chuẩn của SSL/TLS implementation thất bại theo kiểu logic,thì implementation sẽ gọi phương thức verify của lớp mà thực hiện interface này và được đánh dấu với thực thể HttpsURLConnection.Nếu lớp gọi lại có thể xác định hostname được chấp nhận được đưa ra các tham số,nó sẽ ghi lại kết nối được cho phép.Hồi đáp không được chấp nhận sẽ là cho kết nối bị hủy bỏ. Ví dụ: public class MyHostnameVerifier implements HostnameVerifier { public boolean verify(String hostname, SSLSession session) { // pop up một dialog box tương tác // hay thêm một logic theo dõi bổ sung if (good_address) { return true; } else { return false; } } } //...đã hủy... HttpsURLConnection urlc = (HttpsURLConnection) Secure Socket Layer 47
  • 48.
    PTIT 2009 Đề tài môn Bảo mật thông tin (new URL("https://www.sun.com/")).openConnection(); urlc.setHostnameVerifier(new MyHostnameVerifier()); II.4.7 Lớp X509Certificate : Nhiều giao thức socket bảo mật biểu diễn xác thực sử dụng các chứng thực khóa công khai, cũng được gọi là các chứng thực X.509 .Đây là cơ chế xác thực mặc định dành cho giao thức SSL và TLS. Lớp trừu tượng java.security.cert.X509Certificate cung cấp 1 cách chuẩn để truy cập các thuộc tính của các chứng thực X.509 Chú ý: lớp javax.security.cert.X509Certificate được hỗ trợ chỉ để tương thích trở lại với phiên bản cũ (1.0.x , 1.1.x) của JSSE. Các ứng dụng mới nên sử dụng java.security.cert.X509Certificate, không phải javax.security.cert.X509Certificate Secure Socket Layer 48
  • 49.
    PTIT 2009 Đề tài môn Bảo mật thông tin Chương III : III.1 Các phƣơng pháp tấn công SSL dựa trên kỹ thuật tấn công MITM III.1.1 Diffie Hellman MITM Attack : Trong quá trình HankShake, nếu Client và Server quyết định sử dụng thuật toán trao đổi khóa Anonymous Diffie Hellman thì trong phase 2 và phase 3 ở bước Server Key Exchange và Client Key Exchange sẽ xảy ra sự trao đổi các tham số (g,p,gamod p) cùa thuật toán tương tự như sau: và không có bất kỳ sự xác thực nào.Do đó attacker có thể lợi dụng điểm yếu này để thực hiện tấn công: Lúc này attaker sẽ dùng 2 khóa, 1 khóa giao dịch với Client và khóa còn lại giao dịch với Server.Cả Client và Server đều không nhận thấy có sự thay đổi bất thường Secure Socket Layer 49
  • 50.
    PTIT 2009 Đề tài môn Bảo mật thông tin III.1.2 SSLSniff & SSLStrip MITM Attack : Đây là 2 kiểu tấn công đánh vào tâm lý người dùng Giao dịch https thông thƣờng SSLSniff MITM Attack Với Client, Attaker sẽ tạo ra 1 digital certificate giả mạo Server,digital certificate này khá giống với digital certificate của Server và chỉ khác ở 1 số trường.Đặc biệt là trường PU,attacker thay thế PU của Server bằng PU của mình.Với Server, attacker tiến hành giao dịch như 1 Client thông thường.Khi giao dịch,trên Client sẽ xuất hiện những warning nhưng hầu hết người dùng đều bỏ qua những cảnh báo này.Kết quả là mọi thông tin trong quá trình giao dịch đều bị “nghe lén” bởi attacker SSL Strip MITM Attack Đại đa số người dùng khi truy cập web đều không gõ chuỗi ký tự “http://” hoặc “https://” .Vì vậy người dùng thường sử dụng SSL 1 cách gián tiếp thông qua các HyperLinks và Redirection Messages(được xử lý bởi browser).Attacker can thiệp vào kết nối giữa Client và Server,thay thế các HyperLinks “https://....” thành “http://....” và các Redirection Messages tới các trang “https://....” thành các trang “http://....”Kết quả là attacker thực hiện kết nối http thông thường với Client và https với Server,vì không có SSL trong kết với Client nên attacker có thể đọc mọi thông tin Secure Socket Layer 50
  • 51.
    PTIT 2009 Đề tài môn Bảo mật thông tin III.2 Demo tấn công SSLStrip :  Máy Server chạy chương trình ClassFileServer: a. Chương trình được viết theo dạng TCP Server b. Xử lý đa luồng c. Dùng JSSE hỗ trợ bởi ngôn ngữ Java mở SSLServerSocket cho yêu cầu kết nối port 443  Máy attacker sử dụng Cain để tấn công Cain dùng phương pháp arp poisoning, gởi liên tục các gói arp reply về phía Victim và Gateway Router mỗi 30s.Điều này làm sai lệch bảng arp trên victim và Client: i. Trên máy Victim bảng arp xuất hiện entry có thông tin: Internet Address : 1.1.1.1 (Gateway) Physical Address : 00-0c-29-61-2e-d3 (Attacker) ii. Trên Gateway Router bảng arp xuất hiện entry có thông tin: Internet Address : 1.1.1.2 (Victim) Physical Address : 00-0c-29-61-2e-d3 (Attacker) Lúc này mọi thông tin qua lại giữa Victim và GateWay đều qua Attacker.Khi Victim thực hiện kết nối https với Server thì trong quá trình HandShake tại phase 2 ở bước certifiate,chương trình Cain trên máy Attacker tạo ra 1 certificate giả mạo và gởi cho Client đồng thời tiếp nhận Server‟s certificate như Client bình thường.Khi nhận certificate giả mạo,browser trên Client sẽ thông báo sercurity alert nhưng phần lớn người dùng đều bỏ qua dẫn đến việc Attacker có thể dễ dàng can thiệp vào quá trình HankShake giữa Client và Server.Kết quả là Attacker có thể đọc được mọi thông tin mã hóa của Client và Server. Tuy nhiên nếu Client đặt địa chỉ gateway là chính nó 1.1.1.2 và Gateway bật cơ chế ARP Proxy thì lúc này quá trình tấn công bị thất bại . Attacker chỉ nhận được những gói tin từ Gateway trả về cho Client ,còn những gói tin có địa chỉ đích là webserver thì Client sẽ gửi đi với destination mac address là của Gateway vì vậy Attacker không thể thu được.Nhìn chung cách phòng tránh tốt nhất nhằm hạn chế tấn công MITM chính là sự thận trọng của người dùng đầu cuối và sự thường xuyên kiểm tra giám sát trong mạng nội bộ. Secure Socket Layer 51
  • 52.
    PTIT 2009 Đề tài môn Bảo mật thông tin Chương IV : IV.1 Các ứng dụng phổ biến của SSL : Tuy đến nay vẫn còn tồn tại một số lỗ hổng có thể bị khai thác nhưng SSL vẫn là giao thức bảo mật cao nhất mà chưa một giao thức bảo mật nào có thể thay thế vai trò của nó . Nó phổ biến đến mức nếu thấy tên một giao thức có hậu tố “s” thì người ta biết ngay giao thức ứng dụng đó được kết hợp kèm với SSL. Sau đây là một số port phổ biến của những ứng dụng đi kèm SSL được IANA công nhận : Name Port Description Nsiiop 261 Dịch vụ IIOP trên TLS/SSL Https 443 HTTP trên TLS/SSL Smtps 465 SMTP trên TLS/SSL Nntps 563 NNTP trên TLS/SSL Ldaps 636 LDAP trên TLS/SSL Ftps-data 989 FTP-dữ liệu trên TLS/SSL Ftps 990 FTP-điều khiển trên TLS/SSL Telnets 992 TELNET trên TLS/SSL Imaps 994 IRC trên TLS/SSL Pop3s 995 POP3 trên TLS/SSL Ngoài một số ứng dụng phổ biến hiện nay của SSL như bảo mật trong Remote Desktop Protocol cho kết nối Terminal Service, Http cho Outlook Web Access hay Smtp/Imap/Pop3 cho mail , ứng dụng quan trọng của SSL mà không thể không nhắc tới là SSL VPN. Đó là lý do tại sao không chỉ các nhà cung cấp thiết bị mạng phần cứng đang đua nhau trong việc phát triển các sản phẩm hổ trợ SSL VPN mà cả những nhà cung cấp thiết bị mạng “mềm” như Microsoft cũng đưa nó vào sản phẩm Windows Server 2008 và Windows Vista Service Pack 1 của mình với cơ chế Secure Socket Tunneling Protocol (SSTP). Secure Socket Layer 52
  • 53.
    PTIT 2009 Đề tài môn Bảo mật thông tin Sau đây chúng ta sẽ tìm hiểu một vài điểm cơ bản của SSTP:  SSTP là cơ chế kết nối VPN client to gateway bằng HTTP over Secure Socket Layer (HTTP over SSL) port 443. Thông thường, trong một hệ thống mạng hiện nay dù là các Firewall hay Proxy server đều cho phép truy cập HTTP và HTTPS. Vì vậy, dù ở bất cứ đâu các máy Client đều có thể kết nối VPN bằng cơ chế SSTP và đảm bảo bảo mật được gói tin vì áp dụng phương pháp mã hóa SSL.  SSTP được tích hợp hỗ trợ NAP để bảo vệ nguồn tài nguyên mạng tốt hơn bằng cách thi hành các chính sách về system health.  SSTP hỗ trợ IPV6 - đường hầm SSTP và IPV6 dựa trên việc kết nối SSTP thông qua IPV6.  Hơn nữa, SSTP thiết lập HTTP riêng lẻ thông qua session SSL từ SSTP client đến SSTP server. Dùng HTTP thông qua SSL Session sẽ giảm thiểu được chi phí và cân bằng tải tốt hơn.  SSTP không hổ trợ site to site. Sau đây là bảng so sánh tóm tắt SSTP với 2 cơ chế VPN phổ biến hiện nay – PPTP và L2TP/IPSec : Thuộc tính PPTP L2TP/IPSec SSTP Dạng kết nối Cố định Cố định Tạm thời Kiểu thiết bị Quản lý được Quản lý được Không quản lý được Kiểm soát truy cập Không chi tiết Không chi tiết Chi tiết Dạng kết nối thích hợp Client-to-Site Site-to-Site Client-to-Site Yêu cầu Client Phần mềm Client Phần mềm Client Browser Tƣơng thích Kém Kém Tốt Firewall/NAT Đóng gói GRE L2TP over UDP SSTP over TCP Cơ chế mã hóa Microsoft Point to Point IPSec ESP với 3DES hoặc SSL với RC4 hoặc AES Encryption (MPPE) với AES RC4 Tunnel maintenance PPTP L2TP SSTP protocol Cơ chế xác thực Radius,CHAP,PAP, Radius, Active Directory Radius, Active Directory MS-CHAP,MS-MAP ,RSA,Secure ID, X509 ,RSA,Secure ID, X509 Quá trình chứng thực Trước khi quá trình mã Sau khi IPSec session Sau khi SSL session được user hóa bắt đầu được khởi tạo khởi tạo Yêu cầu certificate cho Không Certificate của cả VPN Certificate của VPN server khởi tạo VPN tunnel server và client và root CA certificate trên client Ứng dụng Mọi ứng dụng trên nền IP Mọi ứng dụng trên nền IP Trên nền web, mail, TerminalService,CIFS Secure Socket Layer 53
  • 54.
    PTIT 2009 Đề tài môn Bảo mật thông tin IV.2 Triển khai SSL : Nhìn chung khi lựa chọn giải pháp SSL cho bảo mật thì người quản trị phải xem xét đến nhiều khía cạnh như : độ khả thi ,chi phí triển khai , nhân sự , khả năng duy trì , độ ảnh hưởng đến hệ thống , .v.v. Khi triển khai ta cần chắc chắn chương trình quản lý ứng dụng của server và client đều hỗ trợ SSL và đã cập nhật những update / bản vá để đảm bảo không bị kẻ xấu lợi dụng . Đăng ký certificate nên lựa chọn từ những CA lớn và có uy tín. Sau đây là trình bày tóm tắt các bước cấu hình chính của một webserver IIS 6.0 của Microsoft chạy SSL với certificate đăng ký từ VeriSign ,từ đó ta có thể áp dụng triển khai cho các ứng dụng khác : 1. Tạo Request Certificate 2. Đăng ký SSL Certificate từ VeriSign.com 3. Cấu hình Trusted Root Certification Authority 4. Import SSL Certificate cho Web Server  1.Tạo Request Certificate : Trong IIS 6.0 Manager , mở Folder WebSites , right click website muốn xin certificate ( ở ví dụ chọn Default Web Site => Properties => Tab Directory Security => Server Certificate => Create a new certificate => Prepare a request now ,but send it later Secure Socket Layer 54
  • 55.
    PTIT 2009 Đề tài môn Bảo mật thông tin => Name and Security Settings để default => điền thông tin về Organizition => Common name : điền tên miền trang web mà đã đăng ký với DNS hoặc nếu muốn chỉ mang ý nghĩa local thì điền NetBios name ( ở ví dụ điền www.ptit.com vì lúc sau khi đã đăng ký thành công sẽ dùng DNS của chính mình) => điền thông tin Country ,State ,City => Browse đến nới muốn tạo và đặt tên cho certificate request => xem lại summary => Finish => OK  2.Đăng ký SSL Cerificate từ VeriSign.com : Mở trang web www.verisign.com => chọn Free Trial SSL => Nhập các thông tin cá nhân theo mẫu ,cần điền chính xác mail để nhận kết quả => Tiếp tục nhập Teachnical Contact => Quay về nơi đặt certificate request ,copy nội dung Secure Socket Layer 55
  • 56.
    PTIT 2009 Đề tài môn Bảo mật thông tin => Paste nội dung vào Paste Certificate Signing Request (CSR) ,chọn Server Platform là Microsoft , version là IIS 6.0 ,chọn mục đích sử dụng certificate này là Web Server =>Đặt câu hỏi bí mật và câu trả lời (chỉ có tác dụng nếu sau này muốn quay lại sửa thông tin về certificate này) => Xem lại summary và acceptance =>Finish Secure Socket Layer 56
  • 57.
    PTIT 2009 Đề tài môn Bảo mật thông tin  3.Cấu hình Trusted Root Certification Authority : Vì trial root CA này là chưa chính thức nên ta phải đi cấu hình Trustted Root CA, nếu ta mua một certificate chính thức thì không cần làm bước này . => Vào mail đã dùng đăng ký certificate ,mở thư trả lời , down load Trial SSL Intermediate CA certificate => Chọn link VeriSign CA Certificate => Chọn Secure Site Trial Root CA Certificate => Copy toàn bộ Root CA certificate Secure Socket Layer 57
  • 58.
    PTIT 2009 Đề tài môn Bảo mật thông tin => Trong máy dán nội dung trên vào file txt rồi đổi thành ca.cer => Mở IE option/tab content/chọn Certificate/chọn Import chỉ đến file ca.cer /chọn Automatically select the certificate store based on the type of certificate/Finish hoặc cũng có thể trong Run gõ certmgr.msc/mở Trusted Root Certificate Authorities/right click Certificate/All Task/Import file ca.cer như trong IE Secure Socket Layer 58
  • 59.
    PTIT 2009 Đề tài môn Bảo mật thông tin  4.Import SSL certificate cho web server : Mở mail khi nảy,copy toàn bộ Trial SSL certificate =>Trong máy dán nội dung đó vào file mycert.txt =>Trong IIS manager Properties Default Web Site/tab Dictionary Security/Server Certificate => Chọn Process the pending request and install the certificate => Chỉ đến file mycert.txt Secure Socket Layer 59
  • 60.
    PTIT 2009 Đề tài môn Bảo mật thông tin => SSL port để default 443 => Finish =>Trong tab chọn Edit => Check Require Secure Channel (SSL) để cho server luôn chạy bằng cơ chế SSL => Trong tab Home Dictionary chọn A redirect to URL và điền https://www.ptit.com => OK Secure Socket Layer 60
  • 61.
    PTIT 2009 Đề tài môn Bảo mật thông tin => Trỏ DNS đến DNS của mình =>Test Secure Socket Layer 61
  • 62.
    PTIT 2009 Đề tài môn Bảo mật thông tin Tham Khảo :  Cryptography and Network Security Principles and Practices, Fourth Edition –By William Stallings  JDK 5.0 Documentation  Information Security Principles and Practice – By Mark Stamp  Internet Security Cryptographic Principles, Algorithms and Protocols –By Man Young Rhee  Beginning Cryptography with Java – By David hook  Java Network Programming, 3rd Edition- By Elliotte Rusty Harold  MCP 70-299: Implementing and Administering Security in a Microsoft Windows Server 2003 Network.  http://www.blackhat.com/ (BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf)  http://www.thoughtcrime.org/  http://www.oxid.it/  http://en.wikipedia.org/  http://msopenlab.com/ Secure Socket Layer 62