Như chúng ta đã biết có hai giao thức bảo mật quan trọng lớp vận chuyển (Layer Transport) có tầm quan trọng cao nhất đối với sự bảo mật của các trình ứng dụng trên Web: đó là hai giao thức SSL và TLS. SSL (Secure Socket Layer) là giao thức được phát triển bởi Netscape. Phiên bản 1.0 không được công khai, phiên bản 2.0 được phát hành tháng 2 năm 1995 nhưng vẫn có nhiều lỗ hổng về bảo mật nên SSL phiên bản 3.0 được phát hành vào năm 1996. SSL: là một giao thức sử dụng rộng rãi cho truyền đạt thông tin trong mạng. Giao thức SSL dự phòng dịch vụ tiếp theo cho ứng dụng của mạng: + Data privacy: ClientServer session thành các mật mã. + Client authentication: Server có thể kiểm tra sự đồng nhất của Client. + Server authentication: Client có thể kiểm tra sự đồng nhất của Server. + Message integrity(tính nguyên vẹn của gói tin) : Dữ liệu không thể sửa trong khi truyền. TLS 1.0 (Transport Layer Security) lần đầu tiên được định nghĩa trong RFC2246 tháng 1 năm 1999 như là một nâng cấp từ SSL v3.0. Như đã nêu trong RFC, sự khác biệt này giữa các giao thức SSL 3.0 là không đáng kể. Nó dùng nhiều các thuật toán “cryptographic”.TLS phiên bản 1.1 đã được cập nhật từ phiên bản 1.0 trong RFC 4346 trong tháng 4 năm 2006. Phiên bản này có 1 số khác biệt: Được bảo vệ chống lại tấn công Cipher Block Chaining (CBC). Khởi tiềm ẩn
Trang 1TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
***************
BÁO CÁO BÀI TẬP LỚN MÔN:
AN NINH CƠ SỞ DỮ LIỆU
Đề tài 5.2: Trình bày công nghệ TLS
Giảng viên:PGS T.S Trịnh Nhật Tiến Học viên: Nguyễn Thị Hoàn
Mã học viên: 100201052 Lớp: K17_CHTTT
Hà Nội – 12/2013
Trang 2Như chúng ta đã biết có hai giao thức bảo mật quan trọng lớp vận chuyển (Layer Transport) có tầm quan trọng cao nhất đối với sự bảo mật của các trình ứng dụng trên Web: đó là hai giao thức SSL và TLS.
SSL (Secure Socket Layer) là giao thức được phát triển bởi Netscape Phiên bản 1.0 không được công khai, phiên bản 2.0 được phát hành tháng 2 năm 1995 nhưng vẫn có nhiều lỗ hổng về bảo mật nên SSL phiên bản 3.0 được phát hành vào năm 1996
SSL: là một giao thức sử dụng rộng rãi cho truyền đạt thông tin trong mạng Giao thức SSL dự phòng dịch vụ tiếp theo cho ứng dụng của mạng:
+ Data privacy: Client/Server session thành các mật mã
+ Client authentication: Server có thể kiểm tra sự đồng nhất của Client
+ Server authentication: Client có thể kiểm tra sự đồng nhất của Server
+ Message integrity(tính nguyên vẹn của gói tin) : Dữ liệu không thể sửa trong khi truyền
TLS 1.0 (Transport Layer Security) lần đầu tiên được định nghĩa trong RFC2246 tháng 1 năm 1999 như là một nâng cấp từ SSL v3.0 Như đã nêu trong RFC, sự khác biệt này giữa các giao thức SSL 3.0 là không đáng kể Nó dùng nhiều các thuật toán
“cryptographic”.TLS phiên bản 1.1 đã được cập nhật từ phiên bản 1.0 trong RFC 4346 trong tháng 4 năm 2006 Phiên bản này có 1 số khác biệt: Được bảo vệ chống lại tấn công Cipher Block Chaining (CBC) Khởi tiềm ẩn
Trang 3Initialization Vector (IV) đã được thay thế bằng một IV rõ ràng.Thay đổi trong giải quyết các lỗi padding Hỗ trợ cho IANA đăng ký của các thông số.TLS v1.2 được cập nhật trong RFC 5246 tháng 4 ,2008 Phiên bản này dựa trên những đặc điểm kỹ thuật của v1.1,
sự khác biệt lớn bao gồm:Sự kết hợp MD5/SHA-1 trong PseudoRandom Function (PRF)
đã được thay thế bằng những thuật toán mật mã-bộ-PRFs định.Sự kết hợp MD5/SHA-1 trong kỹ thuật số các nguyên tố đã ký được thay thế bằng một băm duy nhất, xác định trong một lĩnh vực mới.Nâng cao tại các khách hàng và khả năng của máy chủ để xác định những thuật toán băm và chữ ký của họ sẽ chấp nhận Mở rộng hỗ trợ cho sự mật mã xác thực Mở rộng định nghĩa TLS và Advanced Encryption Standard (AES)CipherSuites được thêm vào
Trong các ứng dụng thiết kế, TLS thường được thực hiện trên đầu trang của bất kỳ giao thức vận tải tầng nào, đóng gói ứng dụng giao thức cụ thể như HTTP, FTP, SMTP, NNTP, và XMPP.Một sử dụng nổi bật của TLS là để bảo vệ World Wide Web lưu lượng vận chuyển bằng HTTP để hình HTTPS Đáng chú ý là các ứng dụng thương mại điện tử
và quản lý tài sản Ngày càng nhiều, các Simple Mail Transfer Protocol (SMTP) cũng được bảo vệ bởi TLS (RFC 3207) Các ứng dụng này sử dụng giấy chứng nhận công chính để xác minh nhận dạng của thiết bị đầu cuối.TLS có một số lợi thế vốn có trong tường lửa và NAT traversal mà làm cho nó dễ dàng hơn để quản trị cho quần thể truy cập lớn từ xa TLS cũng là một phương pháp tiêu chuẩn để bảo vệ Session InitiationProtocol (SIP) ứng dụng tín hiệu. TLS có thể được sử dụng để cung cấp chứngthực và mã hoá của tín hiệu SIP kết hợp với VoIP và SIP khác dựa trên ứng dụng
Trang 43- Bảo mật:
TLS / SSL có một loạt các biện pháp bảo mật:Các khách hàng có thể sử dụng quyền hạn của giấy chứng nhận (CA's) khóa công khai để xác nhận chữ ký số của CA trên chứng chỉ máy chủ Nếu các chữ ký số có thể được xác minh, khách hàng chấp nhận chứng chỉ máy chủ như là một chứng chỉ hợp lệ phát hành bởi một CA tin cậy.Các khách hàng xác minh rằng CA phát hành là vào danh sách các CAs tin cậy.Các khách hàng sẽ kiểm tra giấy chứng nhận thời gian hiệu lực của máy chủ Quá trình thẩm định dừng lại nếu ngày hiện tại và thời gian vượt quá thờihạn hiệu lực.Đánh số tất cả các bản ghi ứng dụng với một trình tự và sử dụng dãy sốnày trong Message Authentication Codes (MACs).Một gói thư trao đổi thông tin kết thúc bắng việc bắt tay trả lời “Finished”giữa cả hai đối tượng trao đổi thông tin với nhau.Một hàm ngẫu nhiên chia dữ liệu đầu vào ra một nửa và mỗi một bộ xử lývới độ khó hàm hashing(MD5 và SHA-1), thì XORs của chúng sẽ cùng nhautạo MAC.Chúng sẽ có bảo vệ dự phòng nếu thuật toán ở đây có thể bị côngkích được.SSL v3 được cải tiến trên SSLv2 nhờ được thêm vào cơ sở mã hóa củaSHA-1,và nâng cấp them xác thực của chứng chỉ(CA).Cải tiến thêm trongSSLv3 bao gồm luồng giao thức bắt tay và tăng thêm việc chống đỡ lại việctấn công “man-in-the-middle”
4 Cách viết mật mã (Cryptography) :
Mật mã là thuật ngữ ám chỉ để chuyển một thông điệp mà chỉ có ngườinhận mới có thể độc tin nhắn Mật mã học cũng được sử dụng để xác minhngười gửi tin nhắn, và để xác
Trang 5minh một tin nhắn không được sửa đổi trongquá trình truyền.SSL sử dụng thuật toán mã hóa khác nhau để đảm bảo thông tin liên lạcan toàn Có bốn khái niệm mã hóa được sử dụng bởi SSL:Mã hóa khóa đối xứng ( khóa bí mật) Mã hóa khóa không đối xứng (khóa công khai) Gói tin vắn tắt và chữ kí điện tử
5-Mã hóa khóa đối xứng( secret key)
Khoá mật mã đối xứng sử dụng một chìa khóa duy nhất cho cả hai mã hóa và giải mã dữ liệu.Như thể hiện trong hình bên dưới các gói tin “plain text”đơn giản là thông qua các thuật toán mã hóa “ciphertext”, chúng không thể đọc, và do đó an toàn Kết quả là thông tin an toàn đến người nhận Những người nhận giải mã thông điệp trở lại “plaintext” bằng cách sử dụng cùng một khóa
Thuật toán mã hóa đối xứng có hai loại: mã hóa khối và mã hóa luồng.Mã hóa khối theo truyền thống phổ biến nhất Chúng hoạt động bằng cáchchia dữ liệu thành các khối có kích thước cố định, và sau đó mã hóa từng khốiriêng Phần dữ liệu còn lại độ dài của
“plaintext” là nhiều khối mật mã cùngkích thước.Ngược lại, thuật toán mã hóa luồng được mã hóa bằng bộ phát cácsố ngẫu nhiên Họ sử dụng một hạt giống bắt đầu từ một chìa khóa để sản xuấtmột dòng các bit ngẫu nhiên được gọi là keystream này Để mã hóa
dữ liệu,một trong những có các chữ thô và đơn giản XORs nó với keystream này.Bảo mật của mã hóa khóa đối xứng phụ thuộc vào kích thước của khóa.Khóa càng lớn, càng có nhiều khó khăn cho kẻ đột nhập để phá vỡ mật mã.Tuy nhiên, khóa dài còn mất nhiều thời gian để cho người nhận giải mã, và cóthể dẫn đến sự xuống cấp hiệu suất
Trang 66-Mã hóa không đối xứng(Asymmetric key (public key)encryption)
Trong mã hóa không đối xứng,một cặp khóa bao gồm 1 “public key” và 1“private key”
để mã hóa và giải mã dữ liệu Các “public key” công khai,nhưng không thể được sử dụng
để giải mã Chỉ có “private key” có thể giảimã dữ liệu Ngoài ra, “private key” có thể được dùng để mã hóa dữ liệu
7-Bảng tóm tắt(Digests)
Bảng tóm tắt sử dụng để đảm bảo rằng một gói tin là hợp lệ và không bịsửa đổi trong quá trình truyền.Một bảng tóm tắt ngắn,thường khoảng 128bit.Bản tóm tắt được tạo ra bằng các áp dụng một hàm băm(hash) trên gói tingốc.Rất khó để có thể tìm ra 2 gói tin có bảng tóm tắt giống nhau.Cả hai gói tin và bảng tóm tắt được mã hóa và gửi đến người nhận.Sau khigiải mã ,người nhận kiểm tra bảng tóm tắt của gói tin và so sánh với bảng tómtắt nhận được để đảm bảo toàn vẹn thông điệp Nếu kẻ xâm nhập một sửa đổitrong quá trình truyền dữ liệu đã được mã hóa, có khả năng là các dữ liệu giảimật mã sẽ không
có một bảng tóm tắt hợp lệ
8-Chứng chỉ( Certificates)
Một chứng chỉ là một tập tin được sử dụng để xác định sự an toàn.Mộtchứng chỉ thì bao gồm các thông tin:Tên máy tínhTổ chức / công tyVị trí của máy (thành phố, tiểu bang và quốc gia)Khung thời gian giấy chứng nhận là hợp lệ Khóa công khai / khóa bí mật để liên lạc an toàn Các khoá công khai cho phép máy này giao tiếp một cách an toàn với các máy khác
Trang 79- Lỗ hổng bảo mật của SSL:
SSL (Secure Sockets Layer) là giao thức dùng để đảm bảo an toàn chothông tin liên lạc trên Internet Các nhà nghiên cứu đã tiết lộ một số kiểu tấncông có thể được dùng để làm thương tổn việc trao đổi thông tin an toàn giữawebsite và trình duyệt (tấn công có thể cho phép tin tặc đánh cắp mật khẩu,chiếm đoạt 1 phiên giao dịch ngân hàng trực tuyến hay thậm chí là đưa ra một bản cập nhật trình duyệt Firefox có chứa mã độc) Vấn đề nằm trong cách nhiều trình duyệt thực thi SSL và trong hệ thống hạ tầng khóa công khaiX.509 (dùng để quản lý các chứng thức số được SSL sử dụng để quyết địnhxem website có đáng tin cậy hay không) Nhà nghiên cứu bảo mật có nickname là Moxie Marlinspike giới thiệukiểu tấn công “null-termination certificate” làm gián đoạn phiên duyệt SSLgiữa client và server (trong kiểu tấn công này, nếu viết“www.paypal.com\ 0.thoughtcrime.org” sẽ được hiểu thành“www.paypal.com”) Loại tấn công kiểu “man-in-the-middle” này không thểphát hiện được, nếu lan rộng sẽ ảnh hưởng tới Internet Explorer, Firefox 3.0,phần mềm mạng riêng ảo VPN (virtual private network), các trình e-mailclient và IM (instant messaging) Để bịt lỗ hổng này thì cần cập nhật, sửa chữacho
hệ thống X.509
Tổng quan thì lỗ hổng này nằm ở sự thiếu "ăn rơ" giữa TLS/SSL và cácprotocol trên nó như HTTP hay SMTP Khai thác lỗ hổng này thì kẻ tấn công có thể chèn thêm một đoạn plaintext bất kỳ vào TLS/SSL encryptedstream giữa client và server mà cả client và server đều không thể pháthiện được
. Giả định:
Trang 8Ngân hàng A có cung cấp dịch vụ Internet Banking ở địa chỉ https://www.ebank.com.Máy chủ của của họ chạy phần mềm có lỗ hổng mà chúng ta đang bàn ở đây Chúng ta gọi máy chủ này là server.* Để tăng cường an ninh, ngân hàng
A yêu cầu khi khách hàng (gọi làclient) sử dụng các tính năng có liên quan đến giao dịch tài chính nằmtrong khu vựchttps://www.ebank.com/account/,thì (browser của) họphải có cài đặt client certificate cho ngân hàng A cung cấp Lưu ý lànhiều ngân hàng ở VN thực hiện cái này lắm nha.* Ngoài ra ngân hàng A còn hỗ trợ khách hàng truy cập bằng (Safaritrên) iPhone, lúc đó khách hàng sẽ được chuyển đếnhttps://www.ebank.com/iphone/.Do iPhone có processor yếu, nên ngânhàng A cấu hình máy chủ web của họ để sử dụng một bộ ciphersuiteyếu hơn bộ ciphersuite mà họ
sử dụng cho các khách hàng thôngthường.Có thể lợi dụng tấn công các khách hàng của ngân hàng A theo 3 hướng tấncông mà các tác giả nêu ra Àh lưu ý là đây là loại tấn công MITM, nghĩa làattacker phải có quyền theo dõi, điều chỉnh dữ liệu truyền qua lại giữa clientvà server Attacker có thể làm việc này thông qua các tấn công vào các giaothức ARP hay DNS
A-Hướng tấn công số 1 :
* Bước 1: client truy cập vàohttps://www.ebank.com.Lúc này client sẽ kếtnối đến attacker, và gửi CLIENT_HELLO để bắt đầu giao thức TLS/SSL.Attacker sẽ tạm dừng cái kết nối này và lưu msg CLIENT_HELLO lại đểdùng trong bước 3.* Bước 2: attacker
mở kết nối đến server thật Hai bên sẽ bắt tay theo giaothức TLS/SSL để tạo thành một
Trang 9session Sau khi hoàn tất bắt tay, attacker gửimột HTTP request, đại loại như:POST /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\
Bước 3: server thấy có một request đến khu vực /account/ nên nó tạm thờidừng xử lý request này lại và như đã nói ở trên, nó yêu cầu attacker phải đưaclient certificate cho nó xem Cái hay ở đây, mặc dầu attacker không có(private key của) certificate của client, nhưng hắn vẫn có thể *proxy* cáicertificate đó từ client lên server, mà không bị bên nào phát hiện cả.Server bắt đầu quá trình xác thực bằng việc gửi một msg HELLO_REQUESTngược lại cho attacker Attacker nhận được msg này thì hắn gửiCLIENT_HELLO mà hắn đã lưu ở bước 1 ngược lại cho server Rồi cứ thế,attacker đứng giữa, chuyển msg qua lại giữa client và server cho đến khi quátrình xác thực bằng client certificate kết thúc thành công.Lưu ý là có 2 loại msg mà attacker sẽ gửi Loại thứ nhất là những msg mà hắnphải giải mã/mã hóa trước khi gửi đi Ví dụ như hắn nhận
"Certificate" từ phíaclient thì hắn sẽ mã hóa cái msg này lại, rồi mới gửi cho server Loại thứ hai lànhững msg mà hắn không đọc được (vì không có key), hắn chỉ làm mỗi việclà nhận từ client thì gửi qua server và ngược lại.* Bước 4: quá trình xác thực client certificate đã kết thúc thành công, server tiếp tục xử lý cái request của attacker ở trên,
và trả kết quả lại cho attacker (lưu ý là attacker sẽ không đọc được kết quả này).Điểm yếu
là ở đây Như chúng ta thấy, khi attacker gửi request ở bước 3, lúcđó hắn chưa được xác thực. Nói cách khác, lúc này request của hắn là unauthenticated request Việc xác thực diễn ra sau đó, và sau khi xác thực rồithì server lại quay lại xử lý tiếp cái unauthenticated
Trang 10request của attacker.Lưu ý, ở bước này, để tránh bị tình nghi, attacker có thể tiếp tục trả kết quả vềcho client để đóng kết nối lại một cách êm đẹp
B-Hướng tấn công số 2 :tất cả 3 hướng tấn công này đều hướng đến chôm credential của client đểgửi các authenticated request đến server Credential ở đây có thể làcertificate (như ở hướng số 1) hay cookie/session (như ở hướng số 2 và số3)
Nếu chỉ áp dụng cho HTTPS, nhìn ở một góc độ nào đó, các hướng tấncông này rất giống với tấn công CSRF(Cross Site Request Forgery
)
Nên nếuứng dụng của bạn đã có các phương thức phòng chống CSRF
rồi hay nếu ứngdụng của bạn không chấp nhận thay đổi state bằng GET, thì tạm thời cũngkhông phải có gì lo lắng
Đối với hướng số 1, lợi dụng client certificate để gửi một authenticatedrequest Ở trường hợp các server không xác thực bằng certificate sẽ sử dụnghướng tấn cống số 2.Hướng tấn công này cũng có 4 bước:* Bước số 1: tương tự như hướng tấn công số 1.* Bước 2: attacker mở kết nối đến server thật Hai bên sẽ bắt tay theo giaothức TLS/SSL để tạo thành một session.Sau khi hoàn tất bắt tay, attacker gửi một HTTP request, đại loại như:GET /iphone/login HTTP/1.1\r\nHost: ebank.com\r\nConnection: keep-alive\r\n\r\ nGET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\nHost: ebank.com\
Trang 11r\nConnection: close\r\nX-ignore-this:* Bước số 3: server thấy có request đến /iphone/ nên nó tạm thời dừng xử lýrequest này lại và, như đã nói ở phần giả định, server sẽ bắt đầu quá trìnhrenegotiate lại để chọn một bộ ciphersuite yếu hơn Vấn đề ở đây là server sẽbuffer lại toàn bộ nhóm unauthenticated request này, khi mà renegotiate xongthì lại quay lại xử lý hết tất cả.Trong quá trình renogotiation, vai trò của attacker cũng tương tự như ở bướcsố 3 của hướng tấn công số 1, nghĩa là hắn cũng chỉ *proxy* msg qua lại giữaclient và server, cho đến khi quá trình renegotiate kết thúc thành công.* Bước số 4: lúc này, client thấy đã handshake xong rồi, nên bản thân nó sẽgửi tiếp cái HTTP request của nó ở dạng:GET /index HTTP/1.1\r\nCookie: AuthMe=Now\r\n\r\nChuyện bất ngờ diễn ra ở đây Server nó sẽ gom nhóm unauthenticatedrequest ở bước 2 (do attacker gửi) và cái authenticated request này (do clientgửi) rồi xử lý chung một lần Nguyên nhân server xử lý như thế là do cái cờ keep-alive ở request đầu tiên Thành ra lúc này nhóm request trở thành như sau (màu cam là attacker gửi, màu xanh là client gửi):GET /iphone/login HTTP/1.1\r\nHost: ebank.com\r\nConnection: keep-alive\r\n\r\nGET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\nHost: ebank.com\r\ nConnection: close\r\nX-ignore-this:GET /index HTTP/1.1\r\nCookie: AuthMe=Now\r\ n\r\nỞ đây cái header X-ignore-this đã vô hiệu hóa cái request
GET /indexHTTP/1.1
của client, đồng thời chôm luôn cookie của client để gắn vào cáiunauthenticated request GET /account/transfer?amount=1000&receiver=attacker