Đề tài Kiến trúc SSLTLS

Header Page of 113 Đề tài: Kiến trúc SSL/TLS Mục Lục : Trang 1- Giới thiệu sơ lược SSL/TLS: 2- Ứng dụng: 3- Bảo mật: 4- Cách viết mật mã (Cryptography) : 5- Mã hóa khóa đối xứng( secret key): 6- Mã hóa không đối xứng(Asymmetric key encryption): 7- Bảng tóm tắt(Digests): 8- Chứng chỉ( Certificates): 9- Lỗ hổng bảo mật SSL: A- Hướng công số : B- Hướng công số : C- Hướng công số : Footer Page of 113 3 4 6 11 Header Page of 113 1-Giới thiệu sơ lược SSL/TLS: SSL (Secure Socket Layer) giao thức phát triển Netscape.Version 1.0 không công khai, version 2.0 phát hành tháng năm 1995 có nhiều lỗ hổng bảo mật nên SSL version 3.0 phát hành vào năm 1996 SSL: giao thức sử dụng rộng rãi cho truyền đạt thông tin mạng.Giao thức SSL dự phòng dịch vụ cho ứng dụng mạng: Data privacy: Client/Server session thành mật mã Client authentication: Server kiểm tra đồng Client Server authentication: Client kiểm tra đồng Server Message integrity(tính nguyên vẹn gói tin) : Data sửa truyền TLS 1.0 (Transport Layer Security) lần định nghĩa RFC 2246 Tháng năm 1999 nâng cấp từ SSL v3.0 Như nêu RFC, khác biệt giao thức SSL 3.0 không đáng kể Nó dùng nhiều thuật toán “cryptographic” TLS v1.1 cập nhật từ v 1.0 RFC 4346 tháng năm 2006 Phiên có số khác biệt: Được bảo vệ chống lại công Cipher Block Chaining (CBC) Khởi tiềm ẩn Initialization Vector (IV) thay IV rõ ràng Thay đổi giải lỗi padding Hỗ trợ cho IANA đăng ký thông số TLS v1.2 cập nhật RFC 5246 tháng ,2008 Phiên dựa đặc điểm kỹ thuật v1.1, khác biệt lớn bao gồm: Sự kết hợp MD5/SHA-1 PseudoRandom Function (PRF) thay thuật toán mật mã-bộ-PRFs định Sự kết hợp MD5/SHA-1 kỹ thuật số nguyên tố ký thay băm nhất, xác định lĩnh vực Nâng cao khách hàng khả máy chủ để xác định thuật toán băm chữ ký họ chấp nhận Mở rộng hỗ trợ cho mật mã xác thực Mở rộng định nghĩa TLS Advanced Encryption Standard (AES) CipherSuites thêm vào Footer Page of 113 Header Page of 113 2-Ứng dụng: Trong ứng dụng thiết kế, TLS thường thực đầu trang giao thức vận tải tầng nào, đóng gói ứng dụng giao thức cụ thể HTTP, FTP, SMTP, NNTP, XMPP Một sử dụng bật TLS để bảo vệ World Wide Web lưu lượng vận chuyển HTTP để hình HTTPS Đáng ý ứng dụng thương mại điện tử quản lý tài sản Ngày nhiều, Simple Mail Transfer Protocol (SMTP) bảo vệ TLS (RFC 3207) Các ứng dụng sử dụng giấy chứng nhận công để xác minh nhận dạng thiết bị đầu cuối TLS có số lợi vốn có tường lửa NAT traversal mà làm cho dễ dàng để quản trị cho quần thể truy cập lớn từ xa TLS phương pháp tiêu chuẩn để bảo vệ Session Initiation Protocol (SIP) ứng dụng tín hiệu TLS sử dụng để cung cấp chứng thực mã hoá tín hiệu SIP kết hợp với VoIP SIP khác dựa ứng dụng 3- Bảo mật: TLS / SSL có loạt biện pháp bảo mật: Các khách hàng sử dụng quyền hạn giấy chứng nhận (CA's) khóa công khai để xác nhận chữ ký số CA chứng máy chủ Nếu chữ ký số xác minh, khách hàng chấp nhận chứng máy chủ chứng hợp lệ phát hành CA tin cậy Các khách hàng xác minh CA phát hành vào danh sách CAs tin cậy Các khách hàng kiểm tra giấy chứng nhận thời gian hiệu lực máy chủ Quá trình thẩm định dừng lại ngày thời gian vượt thời hạn hiệu lực Đánh số tất ghi ứng dụng với trình tự sử dụng dãy số 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” hai đối tượng trao đổi thông tin với Một hàm ngẫu nhiên chia liệu đầu vào nửa xử lý với độ khó hàm hashing(MD5 SHA-1), XORs chúng tạo MAC.Chúng có bảo vệ dự phòng thuật toán bị công kích SSL v3 cải tiến SSLv2 nhờ thêm vào sở mã hóa SHA-1,và nâng cấp them xác thực chứng chỉ(CA).Cải tiến thêm Footer Page of 113 Header Page of 113 SSLv3 bao gồm luồng giao thức bắt tay tăng thêm việc chống đỡ lại việc công “man-in-the-middle” 4-Cách viết mật mã (Cryptography) : Mật mã thuật ngữ ám để chuyển thông điệp mà có người nhận độc tin nhắn Mật mã học sử dụng để xác minh người gửi tin nhắn, để xác minh tin nhắn không sửa đổi trình truyền SSL sử dụng thuật toán mã hóa khác để đảm bảo thông tin liên lạc an toàn Có bốn khái niệm mã hóa sử dụng 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 chữ kí điện tử Chứng 5-Mã hóa khóa đối xứng( secret key) Khoá mật mã đối xứng sử dụng chìa khóa cho hai mã hóa giải mã liệu.Như thể hình bên gói tin “plain text” đơn giản thông qua thuật toán mã hóa “ciphertext”, chúng đọc, an toàn Kết 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” cách sử dụng khóa Footer Page of 113 Header Page of 113 Thuật toán mã hóa đối xứng có hai loại: mã hóa khối mã hóa luồng Mã hóa khối theo truyền thống phổ biến Chúng hoạt động cách chia liệu thành khối có kích thước cố định, sau mã hóa khối riêng Phần liệu lại độ dài “plaintext” nhiều khối mật mã kích thước.Ngược lại, thuật toán mã hóa luồng mã hóa phát số ngẫu nhiên Họ sử dụng hạt giống chìa khóa để sản xuất dòng bit ngẫu nhiên gọi keystream Để mã hóa liệu, có chữ thô đơn giản XORs với keystream Bảo mật mã hóa khóa đối xứng phụ thuộc vào kích thước khóa Khóa lớn, có nhiều khó khăn cho kẻ đột nhập để phá vỡ mật mã Tuy nhiên, khóa dài nhiều thời gian người nhận giải mã, dẫn đến 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 “public key” “private key” để mã hóa giải mã liệu Các “public key” công khai, Footer Page of 113 Header Page of 113 sử dụng để giải mã Chỉ có “private key” giải mã liệu Ngoài ra, “private key” dùng để mã hóa liệu Một vấn đề lớn với mật mã khóa riêng làm hai máy định khóa riêng an toàn Đối với trang web thương mại điện tử amazon.com, bạn gán khóa riêng để khách hàng trước Mật mã hóa khóa công khai giải vấn đề này.Một khách hang gửi liệu mã hóa đến server sử dụng khóa công khai để mã hóa.Vì vậy, khách hàng giao tiếp an toàn với máy server Giải mã khóa bí mật nhanh nhiều để thực máy tính so với giải mã khóa công khai.Trong thực tế chúng sử dụng với nhau,do khóa công khai sử dụng để mã hóa khóa bí mật tạo ngẫu nhiên,và khóa bí mật sử dụng để mã hóa thông điệp thực tế.Đây gọi mã hóa “hybrid”, sử dụng giao thức SSL 7-Bảng tóm tắt(Digests) Bảng tóm tắt sử dụng để đảm bảo gói tin hợp lệ không bị sửa đổi 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 tạo áp dụng hàm băm(hash) gói tin gốc.Rất khó để tìm gói tin có bảng tóm tắt giống Footer Page of 113 Header Page of 113 Cả hai gói tin bảng tóm tắt mã hóa gửi đến người nhận.Sau giải mã ,người nhận kiểm tra bảng tóm tắt gói tin so sánh với bảng tóm tắt nhận để đảm bảo toàn vẹn thông điệp Nếu kẻ xâm nhập sửa đổi trình truyền liệu mã hóa, có khả liệu giải mật mã bảng tóm tắt hợp lệ 8-Chứng chỉ( Certificates) Một chứng tập tin sử dụng để xác định an toàn.Một chứng bao gồm thông tin: Tên máy tính Tổ chức / công ty Vị trí máy (thành phố, tiểu bang quốc gia) Khung thời gian giấy chứng nhận 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 giao tiếp cách an toàn với máy khác Các công ty địa điểm cung cấp thông tin máy Đây minh họa giai đoạn Authentication phiên SSL Footer Page of 113 Header Page of 113 9- Lỗ hổng bảo mật SSL: SSL (Secure Sockets Layer) giao thức dùng để đảm bảo an toàn cho thông tin liên lạc Internet Các nhà nghiên cứu tiết lộ số kiểu công dùng để làm thương tổn việc trao đổi thông tin an toàn website trình duyệt (tấn công cho phép tin tặc đánh cắp mật khẩu, chiếm đoạt phiên giao dịch ngân hàng trực tuyến hay chí đưa cập nhật trình duyệt Firefox có chứa mã độc) Vấn đề nằm cách nhiều trình duyệt thực thi SSL hệ thống hạ tầng khóa công khai X.509 (dùng để quản lý chứng thức số SSL sử dụng để định xem website có đáng tin cậy hay không) Nhà nghiên cứu bảo mật có nickname Moxie Marlinspike giới thiệu kiểu công “null-termination certificate” làm gián đoạn phiên duyệt SSL client server (trong kiểu công này, viết “www.paypal.com\0.thoughtcrime.org” hiểu thành “www.paypal.com”) Loại công kiểu “man-in-the-middle” phát được, lan rộng ảnh hưởng tới Internet Explorer, Firefox 3.0, phần mềm mạng riêng ảo VPN (virtual private network), trình e-mail client IM (instant messaging) Để bịt lỗ hổng cần cập nhật, sửa chữa cho hệ thống X.509 Tổng quan lỗ hổng nằm thiếu "ăn rơ" TLS/SSL protocol HTTP hay SMTP Khai thác lỗ hổng kẻ công chèn thêm đoạn plaintext vào TLS/SSL encrypted stream client server mà client server phát Giả định:  Ngân hàng A có cung cấp dịch vụ Internet Banking địa https://www.ebank.com Máy chủ của họ chạy phần mềm có lỗ hổng mà bàn Chúng ta gọi máy chủ server * Để tăng cường an ninh, ngân hàng A yêu cầu khách hàng (gọi client) sử dụng tính có liên quan đến giao dịch tài nằm khu vực https://www.ebank.com/account/, (browser của) họ phải có cài đặt client certificate cho ngân hàng A cung cấp Lưu ý nhiều ngân hàng VN thực nha * Ngoài ngân hàng A hỗ trợ khách hàng truy cập (Safari trên) iPhone, lúc khách hàng 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 họ để sử dụng ciphersuite Footer Page of 113 Header Page of 113 yếu ciphersuite mà họ sử dụng cho khách hàng thông thường Có thể lợi dụng công khách hàng ngân hàng A theo hướng công mà tác giả nêu Àh lưu ý là loại công MITM, nghĩa attacker phải có quyền theo dõi, điều chỉnh liệu truyền qua lại client server Attacker làm việc thông qua công vào giao thức ARP hay DNS A-Hướng công số : * Bước 1: client truy cập vào https://www.ebank.com Lúc client kết nối đến attacker, gửi CLIENT_HELLO để bắt đầu giao thức TLS/SSL Attacker tạm dừng kết nối lưu msg CLIENT_HELLO lại để dùng bước * Bước 2: attacker mở kết nối đến server thật Hai bên bắt tay theo giao thức TLS/SSL để tạo thành session Sau hoàn tất bắt tay, attacker gửi HTTP request, như: POST /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n * Bước 3: server thấy có request đến khu vực /account/ nên tạm thời dừng xử lý request lại nói trên, yêu cầu attacker phải đưa client certificate cho xem Cái hay đây, attacker (private key của) certificate client, *proxy* certificate từ client lên server, mà không bị bên phát Server bắt đầu trình xác thực việc gửi msg HELLO_REQUEST ngược lại cho attacker Attacker nhận msg gửi CLIENT_HELLO mà lưu bước ngược lại cho server Rồi thế, attacker đứng giữa, chuyển msg qua lại client server trình xác thực client certificate kết thúc thành công Lưu ý có loại msg mà attacker gửi Loại thứ msg mà phải giải mã/mã hóa trước gửi Ví dụ nhận "Certificate" từ phía client mã hóa msg lại, gửi cho server Loại thứ hai msg mà không đọc (vì key), làm việc nhận từ client gửi qua server ngược lại * Bước 4: trình xác thực client certificate kết thúc thành công, server tiếp tục xử lý request attacker trên, trả kết lại cho attacker Footer Page of 113 Header Page 10 of 113 (lưu ý attacker không đọc kết này) Điểm yếu Như thấy, attacker gửi request bước 3, lúc chưa xác thực Nói cách khác, lúc request unauthenticated request Việc xác thực diễn sau đó, sau xác thực server lại quay lại xử lý tiếp unauthenticated request attacker Lưu ý, bước này, để tránh bị tình nghi, attacker tiếp tục trả kết cho client để đóng kết nối lại cách êm đẹp B-Hướng công số : tất hướng công hướng đến chôm credential client để gửi authenticated request đến server Credential certificate (như hướng số 1) hay cookie/session (như hướng số số 3) Nếu áp dụng cho HTTPS, nhìn góc độ đó, hướng công giống với công CSRF(Cross Site Request Forgery) Nên ứng dụng bạn có phương thức phòng chống CSRF hay ứng dụng bạn không chấp nhận thay đổi state GET, tạm thời có lo lắng Đối với hướng số 1, lợi dụng client certificate để gửi authenticated request Ở trường hợp server không xác thực certificate sử dụng hướng cống số Hướng công có bước: * Bước số 1: tương tự hướng công số * Bước 2: attacker mở kết nối đến server thật Hai bên bắt tay theo giao thức TLS/SSL để tạo thành session Sau hoàn tất bắt tay, attacker gửi HTTP request, 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: Footer Page 10 of 113 10 Header Page 11 of 113 * Bước số 3: server thấy có request đến /iphone/ nên tạm thời dừng xử lý request lại và, nói phần giả định, server bắt đầu trình renegotiate lại để chọn ciphersuite yếu Vấn đề server buffer lại toàn nhóm unauthenticated request này, mà renegotiate xong lại quay lại xử lý hết tất Trong trình renogotiation, vai trò attacker tương tự bước số hướng công số 1, nghĩa *proxy* msg qua lại client server, 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 thân gửi tiếp HTTP request dạng: GET /index HTTP/1.1\r\n Cookie: AuthMe=Now\r\n \r\n Chuyện bất ngờ diễn Server gom nhóm unauthenticated request bước (do attacker gửi) authenticated request (do client gửi) xử lý chung lần Nguyên nhân server xử lý cờ keep-alive request Thành lúc nhóm request trở thành sau (màu cam attacker gửi, màu xanh 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 Ở header X-ignore-this vô hiệu hóa request GET /index HTTP/1.1 client, đồng thời chôm cookie client để gắn vào unauthenticated request GET /account/transfer?amount=1000&receiver=attacker Rất hay! C- Hướng công số : Footer Page 11 of 113 11 Header Page 12 of 113 Đây hướng công mạnh nhất, không cần server phải có cấu hình đặc biệt để thực Sự khác biệt công với hai hướng công vừa trường hợp này, client bắt đầu quy trình renegotiation Ý tưởng thực công giống với hướng 2, khác bước số 2, attacker không gửi GET /iphone/login mà gửi trực tiếp request hắn, kèm theo "X-ignore-this" header Ngay sau gửi request đó, attacker forward CLIENT_HELLO thu bước sang cho phía server để bắt đầu quy trình renegotiation Khi renegotiate xong, client gửi request ban đầu đến server, lúc toàn request trông sau (phần màu cam attacker gửi, phần màu xanh 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 client chôm cookie để biến request attacker thành authenticated Không cần keepalive, không cần server phải có cấu hình đặc biệt cả! http://en.wikipedia.org/wiki/Transport_Layer_Security http://www.instantssl.com/ssl-certificate-products/what_is_ssl.html http://www.safescrypt.com/faq/faqsslbasics.html#Top http://www.visolve.com/security/ssl_intro.php http://www.vnsecurity.net/t/tls/ “SSL and TLS Essentials” – Securing the Web –Stephen Thomas Footer Page 12 of 113 12 ... vấn đề lớn với mật mã khóa riêng làm hai máy định khóa riêng an toàn Đối với trang web thương mại điện tử amazon.com, bạn gán khóa riêng để khách hàng trước Mật mã hóa khóa công khai giải vấn đề. .. World Wide Web lưu lượng vận chuyển HTTP để hình HTTPS Đáng ý ứng dụng thương mại điện tử quản lý tài sản Ngày nhiều, Simple Mail Transfer Protocol (SMTP) bảo vệ TLS (RFC 3207) Các ứng dụng sử dụng... phiên giao dịch ngân hàng trực tuyến hay chí đưa cập nhật trình duyệt Firefox có chứa mã độc) Vấn đề nằm cách nhiều trình duyệt thực thi SSL hệ thống hạ tầng khóa công khai X.509 (dùng để quản lý