it-swarm-vi.com

Có cách nào để giảm thiểu BEAST mà không vô hiệu hóa AES hoàn toàn không?

Dường như cách dễ nhất để bảo vệ người dùng chống lại cuộc tấn công BEAST vào TLS <= 1.0 là thích RC4 hoặc thậm chí vô hiệu hóa tất cả các bộ mật mã (CBC) khác hoàn toàn, ví dụ: bằng cách chỉ định một cái gì đó như

SSLCipherSuite RC4-SHA:HIGH:!ADH

trong cấu hình mod_ssl của Apache.

Tuy nhiên, sự cố với CBC dường như đã được khắc phục trong TLS> = 1.1; Có cách nào để (bật lại) kích hoạt các mật mã này cho các khách hàng yêu cầu hỗ trợ TLS 1.1 hoặc 1.2 không? Dường như có một cách giải quyết:

SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

thực hiện thủ thuật bằng cách chỉ định các bộ mật mã chỉ khả dụng trong TLS> = 1.1. Điều đó dường như có tác dụng phụ trong việc ngăn khách hàng TLS> = 1.1 sử dụng bất kỳ bộ mật mã "cũ" nào.

Có thực sự không có cách nào để nói rõ ràng với mod_ssl sử dụng các mật mã chế độ CBC cho TLS> = 1.1, nhưng chỉ RC4 cho SSL/TLS <= 1.0? Đó dường như là một sự kết hợp tối ưu của bảo mật và khả năng tương thích.

24
lxgr

Một cách để giảm thiểu BEAST là không làm gì . Điều đó xảy ra rằng mặc dù lỗ hổng được sử dụng trong BEAST vẫn còn đó, nhưng việc khai thác nó khá khó khăn. Nó đòi hỏi khả năng thực hiện các yêu cầu tên miền chéo, với mức độ kiểm soát cao đối với dữ liệu được gửi trong yêu cầu; đặc biệt, nó cần dữ liệu "nhị phân". Duong và Rizzo không tìm ra cách lập bản đồ tấn công trên đồng bằng <img> tags (Javascript thù địch tạo ra các thẻ như vậy, với đường dẫn do kẻ tấn công chọn: đường dẫn nhận được yêu cầu, nhưng nó chỉ ở dạng văn bản). Trong phần trình diễn của mình, họ có thể sử dụng hai lỗ tên miền chéo, một lỗ trong phiên bản nháp của WebSockets, lỗ còn lại trong việc thực hiện Java từ Oracle. Do đó, cả hai lỗ đều đã được sửa bây giờ, BEAST không áp dụng nữa (trừ khi bạn không cập nhật trình duyệt của mình trong hơn một năm, trong trường hợp đó bạn có thể gặp vấn đề lớn hơn).

Vì dựa vào sự không tồn tại của các lỗ hổng tên miền chéo, tốt nhất là, mỏng manh, các nhà cung cấp trình duyệt cũng đã bao gồm một số biện pháp đối phó bổ sung, với tách bản ghi . Khi trình duyệt muốn gửi một khối n byte dữ liệu, thay vì đặt nó vào một bản ghi SSL, nó sẽ chia nó thành hai bản ghi, đầu tiên rất nhỏ Ranh giới hồ sơ không có ý nghĩa ngữ nghĩa trong SSL/TLS, vì vậy bạn có thể thực hiện việc phân tách như vậy mà không thay đổi ý nghĩa. Tuy nhiên, mỗi bản ghi kết thúc bằng một MAC được tính trên dữ liệu bản ghi và một số thứ tự và sử dụng một khóa có nguồn gốc từ trao đổi khóa ban đầu. Điều này bằng cách nào đó hoạt động như một trình tạo số giả ngẫu nhiên. Do đó, bản ghi nhỏ "mô phỏng" thế hệ IV ngẫu nhiên làm cho TLS 1.1+ miễn nhiễm với BEAST.

Lý tưởng nhất là sự phân chia sẽ là 0/n: một bản ghi không có dữ liệu (nhưng vẫn có MAC), theo sau là bản ghi với dữ liệu thực tế. Các bản ghi có độ dài bằng không được phép (theo tiêu chuẩn ) nhưng việc triển khai máy khách và máy chủ bị lỗi không chấp nhận chúng (cụ thể là IE 6.0); thay vào đó, các trình duyệt sử dụng một 1/n-1 split, điều này cũng tốt cho việc đánh bại BEAST, nhưng cũng hoạt động với hầu hết tất cả các máy khách và máy chủ SSL/TLS hiện có. Ít nhất Chrome và Firefox đã đẩy nó năm ngoái .

Giải pháp tốt là TLS 1.1 + nhưng ngay cả trên SSL 3.0 và TLS 1.0, vấn đề BEAST có thể được coi là cố định, ít nhất là trong bối cảnh Web. Do đó, sử dụng AES, và hãy hạnh phúc.

15
Thomas Pornin

OpenSSL có giảm thiểu cho BEAST được bật theo mặc định kể từ 0.9.6d, miễn là phiên bản OpenSSL của bạn là phiên bản này trở lên và bạn chưa đặt SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS không cần hạn chế mật mã hoặc vô hiệu hóa TLS 1.0.

10
mgorven

Tôi hiểu rằng TLS <1.1 với bất kỳ mật mã khối nào trong chế độ CBC đều dễ bị BEAST. Một lần nữa, theo hiểu biết của tôi, các tùy chọn duy nhất của bạn là sử dụng TLS 1.1 trở lên hoặc sử dụng mật mã luồng.

Hoặc, tất nhiên, bạn có thể sử dụng một giao thức khác không bị ảnh hưởng bởi BEAST, như SSH :)

0
atk