Nghiên cứu giao thức bảo mật web SSL

Nghiên cứu giao thức bảo mật web SSL

MỤC LỤC

LỜI MỞ ĐẦU

Ngày nay, công nghệ thông tin phát triển giúp con người

dễ dàng cập nhật thông tin trên Internet nói chung và các ứng dụng trên nền tảng web nói riêng Với internet chúng ta

có các dịch vụ sử dụng như mail, mạng xã hội, thanh toán trực tuyến … trong đó chứa các thông tin cá nhân nhạy cảm của các người dùng như mật khẩu truy cập, tài khoản ngân hàng Vì vậy việc để lộ thông tin gây tổn thất rất lớn cho cả người sử dụng lẫn doanh nghiệp.Các hacker có thể lợi dụng các lỗ hổng về hệ thống hoặc sai lầm của người dùng để khai thác các thông tin

Chính vì những lý do đó chúng tôi chọn đề tài “Nghiên cứu giao thức bảo mật Web SSL” làm đề tài nghiên cứu Nội

dung gồm có 3 chương:

Chương 1.Tổng quan về SSL.Trình bày khái quát về lịch

sử phát triển, mục đích và kiến trúc cũng như hoạt động của SSL

Chương 2.Các kiểu tấn công và cách phòng tránh.Chương này chỉ rõ các kiểu tấn công xảy ra và đưa ra

cách phòng tránh thích hợp

Chương 3.Triển khai SSL cho ứng dụng Web.Hướng

dẫn cài đặt cấu hình “https” cho Web server

Với hiểu biết và kinh nghiệm còn hạn chế nên chắc chắn vẫn không thể tránh khỏi những thiếu sót, chúng em mong nhận được sự đóng góp ý kiến của thầy, cô và các bạn để đề tài được hoàn thiện hơn

Tháng 4 năm 2014

Nhóm báo cáo

đã 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ử

1.1.2 Nhiệm vụ của SSL

Những mục đích chính của việc phát triển SSL là:

• Xác thực server và client với nhau: SSL hỗ trợ sử

dụng các kỹ thuật mã hoá khoá chuẩn (mã hoá sử dụng khoá công khai) để xác thực các đối tác truyền thông với nhau Hầu hết các ứng dụng hiện nay xác thực các client bằng cách sử dụng chứng chỉ số, SSL cũng có thể

sử dụng phương pháp này để xác thực client

• Đảm bảo toàn vẹn dữ liệu: trong một phiên làm việc,

dữ liệu không thể bị làm hỏng dù vô tình hay cố ý

• Bảo vệ tính riêng tư: dữ liệu trao đổi giữa client và

server phải được bảo vệ, tránh bị đánh cắp trên đường truyền và chỉ có đúng người nhận mới có thể đọc được các dữ liệu đó Các dữ liệu được bảo vệ bao gồm các

những dữ liệu liên quan đến chính hoạt động giao thức (các thông tin trao đổi trong quá trình thiết lập phiên làm việc SSL) và các dữ liệu thực trao đổi trong phiên làm việc.

Việc truyền các thông tin nhạy cảm trên mạng rất không

• 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 một 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 một 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 một kết nối được mã hóa giữa hai 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 hai bên cung cấp sự riêng tư bí mật,vì vậy mà giải quyết được vấn đề thứ hai.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ư một 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ứ ba,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 hai đố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 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”

(e-mà bạn đang trao đổi thông tin.Ai đó có thể dễ dàng tạo ra một 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

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

1.2 Kiến trúc của SSL

SSL được thiết kế để dùng TCP cung cấp một dịch vụ bảo mật end-to-end đáng tin cậy SSL không phải là một giao

thức đơn mà là gồm 4 giao thức con như hình minh họa dưới đây:

Hình 1.1 Chồng giao thức SSL

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 SSL Bao giao thức lớp trên được định nghĩa như 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 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 và SSL connection được định nghĩa như sau:

• Connection: 1 kết nối là 1 transport 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 hang Các kết nối thì trao đổi nhanh chóng và mỗi kết nối gắn với 1 phiên

• Session: 1 phiên SSL là 1 liên kết giữa 1 client và 1

server Các phiên 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ó 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ác đặ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.Thêm vào đó, trong suốt quá trình Handshake Protocol, 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 :

• 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

• 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

• Cypher spec: chỉ ra thuật toán mã hóa dữ liệu và

thuật toán băm 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ỉ rằng phiên bả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 đượ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

1.3 Hoạt động của SSL

Hình 1.2 Hoạt động của giao thức SSL

Điểm cơ bản của 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ụ như webserver và các trình duyệt khách, 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ế hoạt động và hệ thống thuật toán mã hóa

sử dụng trong SSL được phổ biến công khai, trừ khóa chia sẻ tạm thời (session key) được sinh ra tại thời điểm trao đổi giữa hai ứng dụng là tạo ngẫu nhiên và bí mật đối với người quan sát trên mạng máy tính

1.3.1 Giao thức SSL Record

SSL Record cung cấp 2 dịch vụ cho kết nối SSL

• Confidentiality(bí 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(toàn vẹn): 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

Hình sau chỉ ra toàn bộ hoạt động của SSL Record Protocol SSL RP 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

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 hoặc ít hơn

Tiếp theo, nén tùy chọn Nén không được làm 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 Trong SSLv3 không có thuật toán nào được chỉ rõ, vì vậy thuật toán nén mặc định là null

Bước tiếp theo 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 1 khóa bí mật được chia sẻ

Sau đó, 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 quá 214=2048

Các thuật toán trao đổi khóa như KEA, RSA key exchange được sử dụng để 2 bên client và server xác lập khóa đối xứng mà họ sẽ sử dụng trong suốt phiên giao dịch SSL.Và thuật toán được sử dụng phổ biến là RSA key exchange.

Các phiên bản SSL 2.0 và 3.0 hỗ trợ hầu hết các bộ mã hóa.Người quản trị có thể tùy chọn bộ mã hóa sẽ dùng cho

cả client và server Khi một client và server trao đổi thông tin trong giai đoạn bắt tay, họ sẽ xác định bộ mã hóa mạnh nhất có thể và sử dụng chúng trong phiên giao dịch SSL

Bước cuối cùng là gắn thêm vào 1 header, bao gồm

• Compressed length (16bit): chiều dài theo byte của

phân mảnh plaintext Giá trị lớn nhất là 214+2048

1.3.2 SSL Change Cipher Spec

Giao thức SSL CCS 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

• unexpected_message : message không thích hợp.

• bad_record_mac: MAC không chính xác.

• decompresstion_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

• 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 như sau:

• close_nitify: 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

• 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 không hợp lệ.

• unsupport_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ử lý certificate làm cho nó không thể chấp nhận

1.3.4 Giao thức SSL 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 (1byte): chỉ ra một trong mười dạng message.

• Length (3byte): độ dài của message theo bytes.

• Content (>=0bytes): tham số đi kèm với message

này, được liệt kê trong hình dưới

Bảng 1.1 Các kiểu message giao thức SSL handshake

Hình 1.3 sau đây 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ó 4 giai đoạn

Hình 1.3.Cơ chế giao thức Handshake.

a Giai đoạn – Thiết lập khả năng bảo mật

Giai đoạn này được dùng để 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

• Session ID: một ID của một phiên có chiều dài thay

đổi được Session ID 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 Session ID = 0 chỉ ra rằng client muốn thiết lập một kết nố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 server.Trường Random được sin ra bởi server và độc lập với trường Random của client.Nếu trường Session ID 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 Session ID 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.

Thành phần đầu tiên của thông số CipherSuite 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ả 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 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”- 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ượn đồ

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 như RC4, RC2,

DES, 3DES, IDEA, DES40, 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) byte.

• 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ướng của giá trị khởi tạo cho mã hóa

CipherBlock Chaining – CBC

b 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 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 dượ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 khóa 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 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ố DH cung cấp cho Anonymous DH 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í của RSA Theo đó client không thử gửi đi cách đơn giản một khóa bí mật 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_exchangeed để gửi khóa công khai.

c 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 1 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 thỏa mãn, client gửi một hay nhiều message trở lại 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 hợp

lệ, client gửi mộ 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à kiểu trao đổi khóa như sau:

• RSA: client sinh ra 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ủ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

• Ephemeral: các tham số DH công khai của client được gửi đi

• Fixed DH: các tham số DH 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

d 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 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 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

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 quá trình trao đổi dữ liệu ở lớp ứng dụng

CHƯƠNG 2.CÁC KIỂU TẤN CÔNG VÀ CÁCH

PHÒNG CHỐNG

2.1 Các kiểu tấn công SSL

Trên lý thuyết thì SSL có độ an toàn cao, nhưng trên thực

tế thì nó vẫn bị tấn công, và một số cách tấn công đó là:

2.1.1 Kiểu Man in the middle ( MITM )

a Diffie Hellman MITM Attack

Trong kiểu tấn công này, kẻ phá hoại ngăn chặn lưu lượng trao đổi qua lại giữa client và server, chẳng hạn như giả mạo DNS trả lời hay như đổi hướng của ARP, sau đó đóng vai client đối với server và ngược lại

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

b SSLSniff và SSLStrip MITM Attack

Đây là 2 kiểu tấn công đánh vào tâm lý người dùng

Hình 2.1.Giao dịch https thông thường

Hình 2.2.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

Hình 2.3.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

Có hai tin dành cho nhà quản trị muốn bảo vệhệ thống chống lại các cuộc tấn công:

• Tin tốt là web browser cảnh báo người dùng khi nhận dạng của web server không thể được kiểm chứng, và có thể chỉ ra cuộc tấn công man-in-middle bằng cách hiện một hộp tin nhắn cảnh báo

• Tin xấu là, trong thực tế, người dùng thường bỏ qua các tin nhắn

Do đó nếu web browser của người dùng chấp nhận kết nối tới các website SSL mà nhân dạng không thể kiểm tra được, chúng ta chỉ có thể tin tưởng vào ý thức của người dùng, và tin rằng họ sẽ nhấn nút “Proceed” nếu cảnh báo hiện ra

2.1.2 Tấn công Brute-force trên các khoá session

Bằng cách thử-sai miền không gian các giá trị có thể của khoá Nhưng số phép thử-sai tǎng lên khi độ dài khoá tǎng

và dẫn đến vượt quá khả nǎng và công suất tính toán, kể cả các siêu máy tính hiện đại nhất Thí dụ, với độ dài khoá là 40bit, thì số phép thử sẽ là 240=1,099,511,627,776 tổ hợp.Kiểu tấn công này được dùng khi kẻ phá hoại biết hoặc nắm được một phần đoạn văn bản gửi trong session SSL/TLS, chẳng hạn như “GET/HTTP/1.0” Và kẻ tấn công có thể nghe lén cuộc nói chuyện trong phiên này (như dùng tcpdump, Ethereal hoặc các chức năng khác) Sau đó hắn giải mã đoạn bắt được bằng việc dùng các khoá có thể, cố gắng tìm các biến thể của nó trong dữ liệu đã được mã hoá của SSL/TLS Nếu như khoá được tìm ra, đoạn tin nhắn đó có thể được

dùng để giải mã toàn bộ phần văn bản trong phiên giao dịch đó.

Tin tốt là số lượng khoá lớn nhất phải được kiểm tra là 2^128 khi mã hoá đối xứng 128-bit được dùng Ngày nay, chúng ta tin tưởng nó đủ sức bảo vệ các session nhiều lần trong năm Tuy nhiên, từ khi CPUs ngày càng tăng kích thước chúng ta không thể dự đoán được các khoá đồng bộ 12-bit có thể xem như là an toàn được hay không nữa Cụ thể các hacker có thể truy cập vào một số lượng lớn các siêu máy tính

Trong trường hợp bộ mã hoá theo lớp xuất khẩu (40 bit,

và một số bộ mở rộng là 56 bits) chẳng hạn như tấn công brute force có thể thành công trong một lượng thời gian, đôi khi thậm chí là vài ngày, phụ thuộc vào con số của CPU Nếu

có thể dùng bộ mã hoá mạnh thì bạn nên dùng một cách dứt khoát thay

2.2 Cách phòng chống

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ộ

Theo dõi kết nối an toàn HTTPS:

• Khi bạn thực hiện tấn công MITM nó sẽ lấy đi khía cạnh

an toàn của kết nối, thứ có thể xác định được trong trình duyệt

• Điều này có nghĩa rằng nếu bạn đăng nhập vào tài khoản ngân hàng trực tuyến và thấy rằng nó chỉ là một kết nối HTTP chuẩn thì chắc chắn có thứ gì đó sai ở đây