Chương 2 GIẢI PHÁP NÂNG CAO KHẢ NĂNG ATTT CỦA HÀ NỘI PORTAL
3.1 GIAO THỨC SSL
SSL là giao thức đa mục đích được thiết kế để tạo ra các giao tiếp giữa hai chương trình ứng dụng trên một cổng định trước (socket 443) nhằm mã hoá toàn bộ thông tin gửi/ nhận. Giao thức SSL được hình thành và phát triển đầu tiên năm 1994 bởi nhóm nghiên cứu Netscape dẫn dắt bởi Elgamal và nay đã trở thành chuẩn bảo mật cài đặt trên Internet.
SSL được thiết kế độc lập với tầng ứng dụng để đảm bảo tính bí mật, an toàn và chống giả mạo luồng thông tin qua Internet giữa hai ứng dụng bất kỳ, thí dụ giữa webserver và các trình duyệt khách (browsers), do đó được sử dụng rộng rãi trong nhiều ứng dụng khác nhau trên môi trường Internet. Toàn bộ cơ chế và hệ thống thuật toán mã hoá sử dụng trong SSL được phổ biến công khai, trừ khoá phiên (session key) được sinh ra tại thời điểm trao đổi giữa hai ứng dụng là ngẫu nhiên và bí mật đối với người quan sát trên mạng máy tính. Ngoài ra, giao thức SSL còn đòi hỏi ứng dụng chủ phải được chứng thực bởi một đối tượng thứ ba (CA) thông qua chứng chỉ điện tử (digital certificate) dựa trên mật mã công khai (ví dụ RSA).
SSL được thiết kế như là một giao thức riêng cho vấn đề bảo mật có thể hỗ trợ cho rất nhiều ứng dụng. Giao thức SSL hoạt động bên trên TCP/IP và bên dưới các ứng dụng tầng cao hơn như là HTTP (HyperText Transfer Protocol), LDAP (Lightweight Directory Access Protocol) hoặc IMAP (Internet Messaging Access Protocol). Hiện nay SSL được sử dụng chính cho các giao dịch trên Web.
SSL cho phép một server có hỗ trợ SSL tự xác thực với một Client cũng hỗ trợ SSL, cho phép client tự xác thực với server, và cho phép cả hai máy thiết lập một kết nối được mã hoá.
Các phiên bản
SSLv2: phiên bản đầu tiên của giao thức SSL do Netscape Corporation thiết kế. SSLv3: phiên bản SSL version 3.0 do Netscape Corporation thiết kế, đã có trợ giúp chain certificate (chứng chỉ nhóm) và được hỗ trợ cho tất cả các trình duyệt phổ thông.
TLSv1: giao thức Transport Layer Security version 1.0 dựa trên cơ sở của SSLv3, thiết kế bởi IETF, nhưng hiện chưa hỗ trợ cho tất cả các trình duyệt thông dụng.
3.1.2 Các khả năng của SSL 1/. Chứng thực SSL 1/. Chứng thực SSL
Chứng thực Server:
Cho phép client xác thực được server muốn kết nối. Lúc này, phía trình duyệt sử dụng các kỹ thuật mã hóa công khai để chắc chắn rằng chứng chỉ và publicID của server là có giá trị và được cấp phát bởi một CA (Certificate Authority) trong danh sách các CA đáng tin cậy của client.
Chứng thực Client:
Cho phép server xác thực được client muốn kết nối. Phía server cũng sử dụng các kỹ thuật mã hoá khoá công khai để kiểm tra chứng chỉ của client và publicID là đúng, được cấp phát bởi một CA trong danh sách các CA đáng tin cậy của Server.
2/. Mã hoá kết nối
Tất cả các thông tin trao đổi giữa client và server được mã hoá trên đường truyền nhằm nâng cao khả năng bảo mật. Điều này rất quan trọng đối với cả hai bên khi có các giao dịch mang tính riêng tư. Ngoài ra tất cả các dữ liệu được gửi đi trên một kết nối SSL đã được mã hoá còn được bảo vệ nhờ cơ chế tự động phát hiện các xáo trộn, thay đổi trong dữ liệu.
Giao thức SSL gồm hai tầng. Tầng thấp nhất là tầng SSL Record Protocol. SSL Record Protocol được sử dụng để đóng gói một vài giao thức ở mức cao hơn. Một trong những giao thức được đóng gói đó là SSL Handshake Protocol, giao thức này cho phép server và client thực hiện việc xác thực lẫn nhau, thoả thuận một thuật toán mã hoá và các khoá mật mã trước khi giao thức ứng dụng gửi hoặc nhận dữ liệu.
3/. Các thuộc tính cơ bản Kết nối an toàn
Quá trình mã hóa dữ liệu được áp dụng sau khi quá trình bắt tay (handshake) đầu tiên xác định được một khoá bí mật. Mật mã đối xứng được sử dụng cho quá trình mã hoá dữ liệu (ví dụ DES, RC4…). Đảm bảo thông tin không thể bị truy cập bởi đối tượng thứ ba.
Danh tính của người bên kia có thể được xác thực bằng mật mã khoá công khai (ví dụ RSA, DSS…).
Kết nối tin cậy
Việc vận chuyển các thông điệp bao gồm một quá trình kiểm tra tính toàn vẹn của thông điệp sử dụng một hàm kiểm tra MAC có khoá. Các hàm băm an toàn (ví dụ SHA, MD5…) được sử dụng cho quá trình thực hiện hàm MAC, nhằm đảm bảo thông tin không bị sai lệch và thể hiện chính xác thông tin gốc gửi đến.
Khả năng tƣơng tác giữa các phần tử
Các nhà lập trình độc lập có thể phát triển các ứng dụng sử dụng SSL 3.0 sau khi trao đổi các tham số mật mã mà không phải biết mã chương trình của các ứng dụng khác.
Khả năng mở rộng
SSL cung cấp một framework mà trong đó các phương pháp mã hoá và khóa công khai kết hợp lại chặt chẽ với nhau.
3.1.3 Các giao thức trong SSL
3.1.3.1 Giao thức bản ghi (Record Protocol)
Secure Sockets Layer sử dụng giao thức bản ghi (Record Protocol) để đóng gói tất cả các thông điệp. Hình vẽ mô tả vị trí của Record Layer trong kiến trúc SSL. Nó cung cấp một định dạng chung cho các thông điệp Alert, ChangeCipherSpec, Handshake hay thông điệp của các giao thức ứng dụng như HTTP, Telnet….
Vị trí giao thức bản ghi trong giao thức SSL
Giao thức bản ghi là một tầng giao thức. Đối với mỗi tầng giao thức nói chung, một gói dữ liệu sẽ bao gồm các trường độ dài, mô tả và nội dung dữ liệu. Giao thức bản ghi nhận dữ liệu cần gửi từ tầng trên phân nhỏ thành từng block (khối), nén dữ liệu, bổ sung dữ liệu kiểm tra, mã hoá và gửi.
Khi nhận dữ liệu về, tiến trình được thực hiện ngược lại: giải mã, kiểm tra, giải nén và sắp xếp lại rồi gửi lên tầng trên. Các giai đoạn trong giao thức này được minh hoạ trong hình vẽ. Dữ liệu tầng ứng dụng có thể là dữ liệu của giao thức SSL handshake, giao thức SSL ChangeCipherSpec, giao thức SSL Alert hoặc dữ liệu của các ứng dụng khác như HTTP, Telnet…
Để phân biệt được từng loại dữ liệu đó trong mỗi frame dữ liệu của SSL record đều có phần header (phần nội dung thêm vào đầu thông điệp) để phân biệt.
Các giai đoạn thi hành của giao thức bản ghi
Bước đầu tiên là fragmentation (phân mảnh). Mỗi thông điệp tầng trên được phân nhỏ thành các khối 214 byte (16384) hoặc nhỏ hơn. Tiếp theo là compression
(nén), điều này là tuỳ chọn. Nén phải không làm mất dữ liệu và không thể gia tăng kích thước dữ liệu hơn 1024 byte. Trong SSLv3, không có thuật toán nén nào được chỉ định, thì thuật toán nén mặc định là null.
Bước tiếp theo trong quá trình xử lý là tính toán MAC (Message Authentication Code) - mã xác thực thông điệp qua dữ liệu đã được nén, biến đổi cấu trúc SSLCompressed thành cấu trúc SSLCiphertext.
Bước cuối cùng của tiến trình SSL Record Protocol là thêm vào phần đầu một header bao gồm các trường :
Protocol (1 byte) :Thể hiện giao thức tầng cao hơn được sử dụng trong thông điệp SSL Record Layer
Version (2 byte) :Phiên bản chính và phụ của đặc tả SSL mà thông điệp tuân theo. Phiên bản hiện tại của SSL là 3.0.
Length (2 byte) :Số 16 bít thể hiện độ dài của giao thức tầng cao hơn. Đặc tả SSL quy định số này không được vượt quá 214
Protocol Message (n byte) : Thông điệp của giao thức tầng cao hơn, có thể dài đến 214 (16384) byte kể cả mã xác thực. SSL Record Layer có thể nối nhiều thông điệp tầng cao hơn trong một thông điệp SSL Record Layer đơn (phải có cùng giao thức tầng cao hơn).
Cấu trúc một thông điệp SSL Record
SSL định nghĩa bốn giao thức tầng cao khác nhau mà Record Layer có thể hỗ trợ là : ChangeCipherSpec protocol (20), Alert protocol (21), Handshake protocol (22), Application protocol data (23).
1/. Giao thức ChangeCipherSpec
Giao thức ChangeCipherSpec gồm các quá trình chuyển tiếp các tín hiệu trong chiến lược mật mã. Giao thức này bao gồm một thông điệp, được mã hoá và được nén theo CipherSpec hiện tại.
Thông điệp ChangeCipherSpec
Phần sẫm màu là Record Layer header, với giá trị protocol là 20, version 3.0, và chiều dài 1. Bản thân thông điệp ChangeCipherSpec chỉ gồm 1 byte, giá trị 1.
Client và server sẽ gửi thông điệp ChangeCipherSpec để báo tin cho bên kia biết được các bản ghi sau này sẽ được bảo vệ dưới CipherSpec với các khoá mà hai bên đã thoả thuận. Khi nhận được thông điệp này, bên nhận sẽ chuyển trạng thái chuẩn bị đọc thành trạng thái đọc hiện tại. Sau khi trao đổi khoá (Key Exchange) và chứng chỉ để xác thực thông điệp (CertificateVerify) thì client sẽ gửi thông điệp này, server sẽ gửi lại cho client một thông điệp tương tự sau khi server xử lý xong thông điệp mà client gửi cho. Khi thông điệp ChangeCipherSpec bất thường xuất hiện thì một unexpected_message sẽ được tạo ra. Khi sử dụng lại các phiên trước đây, thông điệp ChangeCipherSpec sẽ được gửi sau các thông điệp hello.
2/.Giao thức cảnh báo (Alert Protocol)
Các hệ thống sử dụng giao thức Alert để báo hiệu một lỗi hoặc một cảnh báo xảy ra trong quá trình truyền thông giữa hai bên, và SSL gán cho kiểu giao thức của Alert là 21. Alert Protocol cũng giống như tất cả các giao thức SSL khác, sử dụng Record Layer định dạng thông điệp của nó. Các thông điệp alert truyền tải các thông báo lỗi hay cảnh báo trong quá trình thiết lập cũng như trao đổi dữ liệu của một phiên liên lạc. Cũng như các loại thông điệp khác, thông điệp alert cũng được mã hoá và nén. Mỗi thông điệp trong giao thức này bao gồm hai byte.
Byte đầu tiên lưu giá trị cảnh báo (1) hay lỗi (2). Nếu là lỗi, SSL sẽ ngay lập tức đóng kết nối. Các kết nối khác trên cùng phiên có thể vẫn tiếp tục, nhưng không kết nối mới nào trong phiên này có thể được thiết lập. Byte thứ hai bao gồm một mã thể hiện kiểu cảnh báo cụ thể. Tiếp theo đây là các đặc tả lỗi và cảnh báo cụ thể cùng với giá trị của nó.
Định dạng thông điệp Alert
*Kiểu Closure Alert
Client và server phải biết được khi nào kết nối đang kết thúc để tránh cách tấn công cắt cụt (truncation attack). Hoặc mỗi bên tham gia có đưa ra các thông điệp thông báo đóng kết nối.
close_notify (0) : thông báo cho bên nhận biết được bên gửi sẽ không gửi bất kỳ thông điệp nào nữa trên kết nối. Sau khi nhận được thông báo này thì bất kỳ dữ liệu nào nhận được đều bị loại bỏ.
*Kiểu Error Alert
Quá trình xử lý lỗi trong SSL Hanshake Protocol là rất đơn giản. Khi một lỗi được phát hiện thì bên phát hiện ra lỗi sẽ gửi một thông điệp cho bên kia, sau đó cả hai bên đóng kết nối ngay lập tức. Các servers và clients phải bỏ qua bất kỳ số định danh phiên, khoá, các bí mật của kết nối bị hỏng này. Sau đây là một số thông báo lỗi.
unexpected_message (10) : một thông điệp không phù hợp đã được nhận
bad_record_mac (20) : thông báo này được trả lại nếu một bản ghi nhận được có MAC không đúng
decompression_failure (30) : hàm thực hiện giải mã nhận đầu vào không phù hợp (ví dụ dữ liệu mở rộng vượt quá kích thước cho phép).
handshake_failure (40) : thông báo cho biết bên gửi không thể thoả thuận một tập các tham số an toàn được đưa vào trong các tuỳ chọn.
no_certificate (41): thông báo này có thể gửi đi để đáp lại yêu cầu cần xác thực nếu việc xác thực không phù hợp.
bad_certificate (42) : việc xác thực bị ngắt, ví dụ chữ ký dùng cho xác thực không phù hợp.
unsupported_certificate (43) : việc xác thực là kiểu không được hỗ trợ.
certificate_revoked (44) : bên tham gia huỷ bỏ việc xác thực
certificate_expired (45) : việc xác thực đã hết hạn hoặc hiện tại không có giá trị.
certificate_unknown (46) : xuất hiện các vấn đề khác trong quá trình xử lý việc xác thực.
illegal_parameter (47) : một trường trong handshake ngoài giới hạn hoặc không nhất quán với các trường khác.
3.1.3.2 .Giao thức bắt tay (Handshake Protocol)
SSL Handshake Protocol là một phần quan trọng của SSL, nó cung cấp ba dịch vụ cho các kết nối SSL giữa client và server. Handshake Protocol cho phép client/server thống nhất về phiên bản giao thức, xác thực mỗi bên bằng cách thi hành một MAC và thoả thuận về một thuật toán mã hoá và các khoá lập mã cho việc bảo vệ các dữ liệu gửi đi trong một SSL record trước khi giao thức ứng dụng truyền đi hay nhận được byte dữ liệu đầu tiên.
Vị trí giao thức bắt tay
Giao thức bắt tay (Handshake Protocol) bao gồm một dãy các thông điệp được trao đổi bởi client và server. Hình vẽ minh hoạ sự trao đổi các thông điệp handshake cần thiết để thiết lập một kết nối logic giữa client và server. Nội dung và ý nghĩa mỗi thông điệp được mô tả chi tiết trong các phần sau.
Tiến trình bắt tay
“ * “ cho biết đây là tuỳ chọn hoặc là các thông điệp phụ thuộc tuỳ vào tình huống cụ thể sẽ không gửi đi.
Tiến trình của giao thức bắt tay :
1/. Client gửi tới server số phiên bản SSL của client, các tham số của thuật toán mã hoá, sinh dữ liệu ngẫu nhiên (đó chính là digital signature) và các thông tin khác mà server cần để thiết lập kết nối với client.
2/. Server gửi tới client số phiên bản SSL của server đang dùng, các tham số của thuật toán mã hoá, sinh dữ liệu ngẫu nhiên và các thông tin khác mà client cần để thiết lập kết nối với server có sử dụng SSL. Server cũng gửi chứng chỉ (certificate) của mình tới client, nếu client yêu cầu tài nguyên của server mà cần sự xác thực client thì server sẽ yêu cầu chứng chỉ của client.
3/. Client sử dụng một số thông tin mà server gửi đến để xác thực server. Nếu như server không được xác thực thì người dùng sẽ được cảnh báo và kết nối không được thiết lập. Còn nếu như xác thực được server thì phía client sẽ thực hiện tiếp bước 4. 4/. Sử dụng tất cả các thông tin được tạo ra trong giai đoạn bắt tay ở trên, client (cùng với sự cộng tác của server và phụ thuộc vào thuật toán được sử dụng) sẽ tạo ra
premaster secret cho phiên làm việc, mã hoá bằng khoá công khai (public key) mà server gửi đến trong chứng chỉ ở bước 2, và gửi đến server.
5/. Nếu server có yêu cầu xác thực client (tuỳ chọn trong quá trình bắt tay), client sẽ ký trên dữ liệu, dữ liệu này là duy nhất đối với quá trình bắt tay và đều được lưu trữ bởi client và server. Trong trường hợp này, client sẽ gửi cả dữ liệu được ký, chứng chỉ số của mình cùng với premaster secret đã được mã hoá tới server.
6/. Nếu server yêu cầu xác thực client, server sẽ cố gắng để xác thực client. Trường hợp client không được xác thực, phiên làm việc sẽ bị ngắt. Còn nếu client được xác thực thành công, server sẽ sử dụng khoá riêng (private key) để giải mã premaster secret, sau đó thực hiện một số bước để tạo ra master secret.
7/. Client và server sử dụng master secret để tạo ra các session key (khoá phiên), đó chính là các khoá đối xứng được sử dụng để mã hoá và giải mã các thông tin trong phiên làm việc và kiểm tra tính toàn vẹn dữ liệu-xác định sự thay đổi về dữ liệu giữa thời điểm gửi và nhận.
8/. Client sẽ gửi một thông điệp tới server thông báo rằng các thông điệp tiếp theo sẽ được mã hoá bằng session key. Sau đó gửi kèm theo một thông điệp riêng biệt xác định quá trình bắt tay phía server đã kết thúc.
9/. Lúc này giai đoạn “bắt tay” đã hoàn thành, và phiên làm việc SSL bắt đầu. Cả hai phía client và server sẽ sử dụng các session key để mã hoá và giải mã thông tin trao đổi giữa hai bên, và kiểm tra tính toàn vẹn dữ liệu.
10/. Khi client và server quyết định sử dụng lại phiên trước hoặc tạo một bản sao của phiên đang tồn tại (thay vì phải thoả thuận các tham số an toàn mới), thì luồng thông điệp hoạt động như sau : client gửi một ClientHello có sử dụng Session ID của phiên được dùng lại server kiểm tra nơi lưu trữ phiên (session cache) tương ứng. Nếu có, server sẽ thiết lập lại kết nối dưới trạng thái phiên được chỉ định, server sẽ gửi một