Giai đoạn này được dung để bắt đầu một kết nối logic và thiết lập khả năng bảo mật mà sẽ liên kết với nó.Việc trao đổi thì được khởi tạo bởi client bằng việc gửi một client_hello message với những thông số sau đây:
• Version: version SSL mới nhất mà client biết.
• Random: một cấu trúc sinh ra ngẫu nhiên từ client, bao gồm một nhãn thời gian 32 bit và 28 bytes sinh bởi một bộ sinh số ngẫu nhiên an toàn. Những giá trị này phục vụ cho lần này vsử dụng suốt quá trình trao đổikhóa để ngăn tấn công lập lại.
• Session ID: một ID của phiên có chiều dài thay đổi được.SessionID khác 0 nghĩa là client muốn cập nhật tham số của một kết nối đang tồn tại hay tạo một kết nối mới trên phiên này.SessionID = 0 chỉ ra rằng client muốn thiết lập một kết nối mới trên một phiên mới.
• CipherSuite: đây là 1 danh sách mà chứa những bộ biên dịch của những thuật toán mã hóa được hỗ trợ bởi client, tham khảo theo thứ tự giảm dần. Mỗi thành phần trong danh sách (mỗi bộ mã hóa) định nghĩa cả một khóa trao đổi và một CipherSpec, những thông số này sẽ được bàn đến sau.
• Compression Method: đây là danh sách của những phương thức nén mà client hỗ trợ.
Sau khi gửi client_hello message, client chờ nhận server_hello message mà chứa cùng thông số với client_hello message.Với server_hello message, những thỏa thuận kèm theo được áp dụng. Trường Version chứa version thấp hơn được đề nghị bởi client và cao nhất được hổ trợ bởi sever.Trường Random được sinh ra bởi server và độc lập với trường Random của client. Nếu trường SessionID của client khác 0, thì giá trị tương tự được dùng bởi server,ngược lại thì trường SessionID của server chứa giá trị của một phiên mới. Trường CipherSuite chứa bộ mã hóa chọn bởi server từ những đề xuất của
client. Trường Compression chứa phương thức nén chọn bởi server từ những đề xuất của client.
Thành phần đầu tiên của thông số Cipher Suite là phương thức trao đổi khóa (ví dụ như bằng cách nào những khóa mã hóa cho việc mã hóa thông thường và MAC được trao đổi ).Những phương thức trao đổi khóa sau được hỗ trợ:
• RSA: khóa bí mật được mã hóa với khóa công khai RSA của bên nhận. Một public-key certificate cho khóa bên nhận phải được tạo sẵn.
• Fixed Diffie-Hellman: đây là sự trao đổi khóa Diffie-Hellman trong certificate của server chứa các thông số công khai Diffie-Hellman được ký bởi Certificate Authority (CA) .Nghĩa là certificate khóa công khai chứa các thông số khóa công khai Diffie-Hellman. Client chứa sẵn các thông số khóa công khai Diffie- Hellman đó trong certificate nếu chứng thực client được yêu cầu hoặc trong một message trao đổi khóa.Phương thức này mang lại kết quả một khóa bí mật cố định giữa hai đầu, dựa trên tính toán Diffie- Hellman sử dụng khóa công khai cố định.
• Ephemeral Diffie-Hellman: Phương pháp được sử dụng để tạo khó “ephemeral” (tạm thời,1 lần)– khóa tạm thời. Trong trường hợp này, khóa công khai Diffie- Hellman được trao đổi,được ký sử dụng khóa bí mật RSA hoặc DSS của bên gửi.Bên nhận có thể sử dụng khóa công khai tương ứng để xác minh chữ ký.
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.
• 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).
2.2.4.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:
• Server đã gửi một certificate với các tham số fixed Diffie-Hellman.
• Trao đổi khoá RSA được dùng.
• 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ạora 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 DiffieHellman) 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.
• 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ố.
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 || D5(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.
2.2.4.4. Giai đoạn 4 : Kết thúc kết nối bảo mật:
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:
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.
CHƯƠNG III: DEMO PHƯƠNG PHÁP TẤN CÔNG WEB HTTP & GIẢI PHÁP PHÒNG CHỐNG VÀ
TRIỂN KHAI SSL.
3.1. Mục tiêu của Demo:
• Chỉ ra sự không an toàn khi 1 website không được cài đặt giao thức SSL bảo mật HTTPS
• Chỉ ra phương pháp phòng chống và triển khai cài đặt SSL để đảm bảo sự an toàn cho website
3.2. Mô hình của Demo:
Thiết bị:
Truy cập website trên Server
Bắt gói tin
Máy Server Máy Victim
- Máy Attacker: Cài Win 7, IP: 192.168.47.51/24 và cài Wireshark để bắt gói tin. - Máy Server : Cài Win Server 2003, IP: 192.168.47.130/24, dựng 1 trang web có
nội dung.
- Máy Victim: Cài Win XP, IP: 192.168.47.131/24, truy cập vào web của Server .
3.3. Công cụ và phần mềm sử dụng trong Demo:
• Trên máy Attacker cài phần mềm WireShark 1.6.4 dùng để bắt gói tin
• Trên máy Server cài Openssl 1.0.0.e để tự tạo Certificate MyCA và MyServer
3.4. Các bước thực hiện:
3.4.1. Phương pháp tấn công web HTTP:
Khi máy Victim truy cập đến trang Web trên máy Server thì máy Attacker sẽ bắt được các gói tin, mở gói tin HTTP/1.1 200 OK (text/html) ta sẽ thấy được nội dung trang web mà máy Victim vừa truy cập.
3.4.2. Giải pháp phòng chống và triển khai SSL:3.4.2.1. Tự tạo chứng thực CA cho chính mình 3.4.2.1. Tự tạo chứng thực CA cho chính mình Bước 1: Tạo cặp khóa MyCA
Tạo khóa riêng X509 cho CA, mã hóa dạng Base64 – Mục đích là sẽ dùng khóa riêng này kí nhận cho code signing certificate. Khi tạo, cần cung cấp mật khẩu cho khóa riêng này.
Lệnh: Openssl> genrsa -des3 -out MyCA.key 1024 Pass phrase for MyCA.key : là “thanhtung”
Tạo chứng chỉ X509 cho CA có chứa public key, mã hóa dạng Base64 – Bạn cung cấp các thông tin cho CA, bao gồm tên đại diện cho CA, mã quốc gia, tên thành phố, email và mật khẩu của khóa riêng đã tạo ở trên.
Lệnh: Openssl > req -new -config openssl.cfg -x509 -days 365 -key MyCA.key -out MyCA.crt
Pass phrase for MyCA.key: là ‘thanhtung’
Bước 3: Chuyển sang dạng PKCS#12 để có thể import vào IIS
Lệnh: Openssl> pkcs12 -export -in MyCA.crt -inkey MyCA.key -out MyCA.pfx
Pass phrase for MyCa.key: là ‘thanhtung’ Export Password: ‘123456’
3.4.2.2. Tạo chứng thực cho máy chủ (server)Bước 1: Tạo cặp khóa MyServer: Bước 1: Tạo cặp khóa MyServer:
Lệnh: Openssl> genrsa -des3 -out MyServer.key 1024 Pass phrase for MyServer.key : ‘123456789’
Bước 2: Tạo yêu cầu chứng thực (certificate signing request): Lệnh: Openssl> req -config openssl.cfg -out MyServer.csr -key
MyServer.key –new
Pass phrase for MyServer.key : ‘123456789’ \
Bước
(certificate request) với khóa bí mật của MyCA và tạo chứng thực cho MyServer
Lệnh: Openssl> x509 -CAcreateserial -CAserial MyCA.srl -in MyServer.csr -days 370 -req -extfile openssl.cfg -extensions v3_req –CA MyCA.crt -CAkey MyCA.key -out MyServer.crt Pass phrase for MyCA.key : ‘thanhtung’
Bước 4: Chuyển sang dạng PKCS#12 để có thể import vào IIS Lệnh: Openssl> pkcs12 -export -in MyServer.crt -inkey
MyServer.key -out MyServer.pfx Pass phrase for MyServer.key : ‘123456789’ Export Password: ‘123456’
3.4.2.3. Cài đặt MyCA và MyServerBước 1: Chạy MMC: Bước 1: Chạy MMC:
Menu Start/Run.../mmc
Certificates/Add/Computer Account/Next/Finish/Close/OK
Bước 2: Cài CA Certificate (MyCA)
+Console root/Certificates/Trusted Root Certification Authorities/
Right-click vào Certificates/All Tasks/Import...
Sau đó gõ password: 123456 và bấm next mặc định đến finish.
Bước 3: Cài End-Use Certificate (MysServer)
Console root /Certificates/Personal/Right-click Certificates/All Tasks/Import...
Bước 4: Cho IIS dùng MyServer
Menu Start/Settings/Control Panel/Administratove Tools/Internet Services Manager
Chuột phải vào Default Web Site/Properties/Directory Security
Bước 5: Kiểm tra
Mở Internet Explorer của máy victim, truy cập vào trang web đã thiết lập SSL , nếu thấy biểu tượng ổ khóa ở bên dưới góc phải màn hình là ta đã thành công.
Website trên Server từ http đã được chuyển thành công qua https
3.5. Kết quả Demo:
Trên máy Attacker dùng Wireshark kiểm tra thì chỉ thấy các gói tin đã mã hóa. Nội dung trang web đã được mã hóa không thể đọc được.Chúng ta đã bảo đảm được an toàn cho web
Xác thực Server và trao đổi khóa
Kết thúc kết nối bảo mật
Mục tiêu đạt được
Tìm hiểu về cấu trúc của SSL Một số cơ chế bảo mật của SSL Một số ứng dụng của SSL
Xây dựng 1 Web server chạy SSL
Vì SSl là một giao thức hiện tại rất ít được ứng dụng tại Việc Nam nên nguồn tài liệu chủ