thông tin về cái mới (CVE-2020-1968) trong giao thức TLS, có tên mã
và cho phép, trong một số trường hợp hiếm hoi, xác định khóa chính sơ bộ (tiền chính), khóa này có thể được sử dụng để giải mã các kết nối TLS, bao gồm HTTPS, khi chặn lưu lượng chuyển tuyến (MITM). Cần lưu ý rằng cuộc tấn công rất khó thực hiện trong thực tế và mang tính chất lý thuyết nhiều hơn. Để thực hiện một cuộc tấn công, cần có cấu hình cụ thể của máy chủ TLS và khả năng đo rất chính xác thời gian xử lý của máy chủ.
Sự cố xuất hiện trực tiếp trong đặc tả TLS và chỉ ảnh hưởng đến các kết nối sử dụng mật mã dựa trên giao thức trao đổi khóa DH (Diffie-Hellman, TLS_DH_*"). Với mật mã ECDH, vấn đề này không xảy ra và chúng vẫn được bảo mật. Chỉ các giao thức TLS tối đa phiên bản 1.2 mới dễ bị tấn công; TLS 1.3 không bị ảnh hưởng bởi sự cố. Lỗ hổng này xảy ra trong quá trình triển khai TLS sử dụng lại khóa bí mật DH trên các kết nối TLS khác nhau (hành vi này xảy ra trên khoảng 4.4% máy chủ Top 1M của Alexa).
Trong OpenSSL 1.0.2e và các bản phát hành trước đó, khóa chính DH được sử dụng lại trong tất cả các kết nối máy chủ trừ khi tùy chọn SSL_OP_SINGLE_DH_USE được đặt rõ ràng. Kể từ OpenSSL 1.0.2f, khóa chính DH chỉ được sử dụng lại khi sử dụng mật mã DH tĩnh ("DH-*", ví dụ: "DH-RSA-AES256-SHA"). Lỗ hổng này không xuất hiện trong OpenSSL 1.1.1 vì nhánh này không sử dụng khóa chính DH và không sử dụng mật mã DH tĩnh.
Khi sử dụng phương thức trao đổi khóa DH, cả hai bên của kết nối sẽ tạo ra các khóa riêng ngẫu nhiên (sau đây gọi là khóa “a” và khóa “b”), dựa trên đó các khóa chung (ga mod p và gb mod p) được tính toán và gửi. Sau khi mỗi bên nhận được khóa chung, một khóa chính chung (gab mod p) sẽ được tính toán, khóa này được sử dụng để tạo khóa phiên. Cuộc tấn công Raccoon cho phép bạn xác định khóa chính thông qua phân tích kênh bên, dựa trên thực tế là thông số kỹ thuật TLS lên đến phiên bản 1.2 yêu cầu loại bỏ tất cả byte rỗng hàng đầu của khóa chính trước khi tính toán liên quan đến nó.
Bao gồm cả khóa chính bị cắt bớt sẽ được chuyển đến hàm tạo khóa phiên, dựa trên các hàm băm với độ trễ khác nhau khi xử lý các dữ liệu khác nhau. Việc đo chính xác thời gian của các hoạt động chính được thực hiện bởi máy chủ cho phép kẻ tấn công xác định manh mối (oracle) giúp đánh giá xem khóa chính có bắt đầu từ đầu hay không. Ví dụ: kẻ tấn công có thể chặn khóa chung (ga) do máy khách gửi, truyền lại nó đến máy chủ và xác định
liệu khóa chính kết quả có bắt đầu từ XNUMX hay không.
Bản thân việc xác định một byte của khóa không mang lại bất cứ điều gì, nhưng bằng cách chặn giá trị “ga” được máy khách truyền trong quá trình đàm phán kết nối, kẻ tấn công có thể tạo ra một tập hợp các giá trị khác được liên kết với “ga” và gửi chúng đến máy chủ trong các phiên đàm phán kết nối riêng biệt. Bằng cách tạo và gửi các giá trị “gri*ga”, kẻ tấn công có thể, thông qua việc phân tích các thay đổi về độ trễ trong phản hồi của máy chủ, xác định các giá trị dẫn đến việc nhận khóa chính bắt đầu từ XNUMX. Sau khi xác định được các giá trị như vậy, kẻ tấn công có thể tạo ra một bộ phương trình cho và tính toán khóa chính ban đầu.
Lỗ hổng OpenSSL mức độ nguy hiểm thấp và bản sửa lỗi đã giảm xuống thành chuyển các mật mã có vấn đề “TLS_DH_*” trong bản phát hành 1.0.2w sang danh mục mật mã có mức độ bảo vệ không đủ (“mật mã ssl yếu”), tính năng này bị tắt theo mặc định . Các nhà phát triển Mozilla đã làm điều tương tự, trong thư viện NSS được sử dụng trong Firefox, bộ mật mã DH và DHE. Kể từ Firefox 78, các mật mã có vấn đề đã bị vô hiệu hóa. Hỗ trợ Chrome cho DH đã ngừng hoạt động vào năm 2016. Các thư viện BearSSL, BoringSSL, Botan, Mbed TLS và s2n không bị ảnh hưởng bởi sự cố vì chúng không hỗ trợ mật mã DH hoặc các biến thể tĩnh của mật mã DH.
Các vấn đề bổ sung được ghi chú riêng () trong ngăn xếp TLS của thiết bị F5 BIG-IP, giúp cuộc tấn công trở nên thực tế hơn. Đặc biệt, những sai lệch trong hoạt động của các thiết bị khi có byte XNUMX ở đầu khóa chính đã được xác định, có thể được sử dụng thay vì đo độ trễ chính xác của các phép tính.
Nguồn: opennet.ru