Đề tài Kiến trúc SSL/TLS

Đề tài: Kiến trúc SSL/TLS Mục Lục : Trang 1- Giới thiệu sơ lược về SSL/TLS: 2 2- Ứng dụng: 3 3- Bảo mật: 3 4- Cách viết mật mã (Cryptography) : 4 5- Mã hóa khóa đối xứng( secret key): 4 6- Mã hóa không đối xứng(Asymmetric key encryption): 5 7- Bảng tóm tắt(Digests): 6 8- Chứng chỉ( Certificates): 6 9- Lỗ hổng bảo mật của SSL: 7 A- Hướng tấn công số 1 : 8 B- Hướng tấn công số 2 : 9 C- Hướng tấn công số 3 : 11 1-Giới thiệu sơ lược về SSL/TLS: SSL (Secure Socket Layer) là giao thức được phát triển bởi Netscape.Version 1.0 không được công khai, version 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 version 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) : Data 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 RFC 2246 trong 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 v1.1 đã được cập nhật từ v 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 Initialization 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. 2-Ứng dụng: 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 Initiation Protocol (SIP) ứng dụng tín hiệu. TLS có thể được sử dụng để cung cấp chứng thự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 . 3- 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ời hạ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 nhau tạo MAC.Chúng sẽ có bảo vệ dự phòng nếu thuật toán ở đây có thể bị công kích được. SSL v3 được cải tiến trên SSLv2 nhờ được thêm vào cơ sở mã hóa của SHA-1,và nâng cấp them xác thực của chứng chỉ(CA).Cải tiến thêm trong SSLv3 bao gồm luồng giao thức bắt tay và tăng thêm việc chống đỡ lại việc tấ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ười nhận mới có thể độc tin nhắn. Mật mã học cũng được sử dụng để xác minh người gửi tin nhắn, và để xác minh một tin nhắn không được sửa đổi trong quá 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ạc an 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 cộng) Gói tin vắn tắt và chữ kí điện tử Chứng chỉ 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ách chia dữ liệu thành các khối có kích thước cố định, và sau đó mã hóa từng khối riêng. Phần dữ liệu còn lại độ dài của “plaintext” là nhiều khối mật mã cùng kí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ác số 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ất mộ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. 6-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ải mã dữ liệu. Ngoài ra, “private key” có thể được dùng để mã hóa dữ liệu. Một vấn đề lớn với mật mã khóa riêng là làm thế nào hai máy quyết định về một khóa riêng an toàn. Đối với các trang web thương mại điện tử như amazon.com, bạn không thể gán khóa riêng để mỗi khách hàng có thể trước. Mật mã hóa khóa công khai giải quyết vấn đề này.Một khách hang gửi dữ liệu được mã hóa đến server sử dụng khóa công khai để mã hóa.Vì vậy, bất kỳ khách hàng có thể giao tiếp an toàn với các máy server. Giải mã khóa bí mật là nhanh hơn nhiều để thực hiện trên một máy tính hơn so với giải mã khóa công khai.Trong thực tế chúng được sử dụng với nhau,do đó một khóa công khai được sử dụng để mã hóa một khóa bí mật được tạo ngẫu nhiên,và khóa bí mật được sử dụng để mã hóa thông điệp thực tế.Đây được gọi là mã hóa “hybrid”, và được sử dụng bởi các giao thức SSL. 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 128 bit.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 tin gố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 khi giả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óm tắ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 đổi trong quá trình truyền dữ liệu đã được mã hóa, có khả năng là các dữ liệu giải mậ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ột chứng chỉ thì bao gồm các thông tin: Tên máy tính Tổ chức / công ty Vị 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 riêng để liên lạc an toàn Giấy chứng nhận quyền tên Giấy chứng nhận quyền chữ ký 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. Các công ty và địa điểm cung cấp thông tin về máy. Đây là minh họa giai đoạn Authentication của 1 phiên SSL 9- 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 cho thô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ấn công có thể được dùng để làm thương tổn việc trao đổi thông tin an toàn giữa website 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 khai X.509 (dùng để quản lý các chứng thức số được SSL sử dụng để quyết định xem 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ệu kiểu tấn công “null-termination certificate” làm gián đoạn phiên duyệt SSL giữ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-mail client và IM (instant messaging). Để bịt lỗ hổng này thì cần cập nhật, sửa chữa cho 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ác protocol 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 encrypted stream giữa client và server mà cả client và server đều không thể phát hiện được. Giả định: Ngâ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ằm trong khu vực https://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 (Safari trên) iPhone, lúc đó khách hàng sẽ được chuyển đến https://www.ebank.com/iphone/. Do iPhone có processor yếu, nên ngân hàng A cấu hình máy chủ web của họ để sử dụng một bộ ciphersuite yếu hơn bộ ciphersuite mà họ sử dụng cho các khách hàng thông thườ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ấn cô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 client và server. Attacker có thể làm việc này thông qua các tấn công vào các giao thức ARP hay DNS. A-Hướng tấn công số 1 : * Bước 1: client truy cập vào https://www.ebank.com. Lúc này client sẽ kết nố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 giao thứ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ư: POST /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n * Bước 3: server thấy có một request đến khu vực /account/ nên nó tạm thời dừng xử lý request này lại và như đã nói ở trên, nó yêu cầu attacker phải đưa client 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ái certificate đó 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_REQUEST ngược lại cho attacker. Attacker nhận được msg này thì hắn gửi CLIENT_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ắn phải giải mã/mã hóa trước khi gửi đi. Ví dụ như hắn nhận "Certificate" từ phía client 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ệc là 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ồi thì server lại quay lại xử lý tiếp cái unauthenticated request 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ấn cô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 ứng dụng của bạn không chấp nhận thay đổi state bằng GET, thì tạm thời cũng khô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 authenticated request. Ở trường hợp các server không xác thực bằng certificate sẽ sử dụng hướ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 giao thứ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\n Host: ebank.com\r\n Connection: keep-alive\r\n \r\n GET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n Host: ebank.com\r\n Connection: close\r\n X-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ình renegotiate 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 xong thì 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ước số 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ữa client 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\n Cookie: AuthMe=Now\r\n \r\n Chuyện bất ngờ diễn ra ở đây. Server nó sẽ gom nhóm unauthenticated request ở bước 2 (do attacker gửi) và cái authenticated request này (do client gử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\n Host: ebank.com\r\n Connection: keep-alive\r\n \r\n GET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n Host: ebank.com\r\n Connection: close\r\n X-ignore-this:GET /index HTTP/1.1\r\n Cookie: AuthMe=Now\r\n \r\n Ở đây cái header X-ignore-this đã vô hiệu hóa cái request GET /index HTTP/1.1 của client, đồng thời chôm luôn cookie của client để gắn vào cái unauthenticated request GET /account/transfer?amount=1000&receiver=attacker. Rất hay! C- Hướng tấn công số 3 : Đây là hướng tấn công mạnh nhất, không cần server phải có cấu hình đặc biệt gì để thực hiện. Sự khác biệt cơ bản giữa tấn công này với hai hướng tấn công vừa rồi là trong trường hợp này, client bắt đầu quy trình renegotiation. Ý tưởng thực hiện tấn công rất giống với hướng 2, chỉ khác nhau ở bước số 2, attacker sẽ không gửi GET /iphone/login nữa mà gửi trực tiếp luôn request của hắn, kèm theo một cái "X-ignore-this" header. Ngay sau khi gửi cái request đó, attacker sẽ forward cái CLIENT_HELLO thu được ở bước 1 sang cho phía server để bắt đầu quy trình renegotiation. Khi đã renegotiate xong, client sẽ gửi request ban đầu của mình đến server, lúc này toàn bộ request sẽ trông như sau (phần màu cam của attacker gửi, phần màu xanh của client gửi): GET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n Host: ebank.com\r\n Connection: close\r\n X-ignore-this: GET /index HTTP/1.1\r\n Cookie: AuthMe=Now\r\n \r\n Tương tự ở trên, X-ignore-this đã vô hiệu hóa request của client và chôm cookie để biến request của attacker thành authenticated. Không cần keep-alive, không cần server phải có cấu hình đặc biệt gì cả! “SSL and TLS Essentials” – Securing the Web –Stephen Thomas