Điểm:0

Sử dụng AES-CBC trong TLS1.2

lá cờ us

AES-CBC vẫn còn lỗ hổng trong TLS1.2 hay lỗ hổng chỉ hoạt động đối với các phiên bản TLS thấp hơn? Nếu không, tại sao nó lại bị xóa trong TLS 1.3?

kelalaka avatar
lá cờ in
Điều này có trả lời câu hỏi của bạn không? [Tại sao AES CBC bị xóa trong TLS 1.3?](https://crypto.stackexchange.com/questions/52566/why-was-aes-cbc-removed-in-tls-1-3)
Maarten Bodewes avatar
lá cờ in
Nói tóm lại: sẽ không an toàn nếu bạn sử dụng bất kỳ triển khai AES-CBC mặc định nào, điều này đủ tệ để loại trừ nó.
lá cờ us
@MaartenBodewes có triển khai mặc định nào được chỉ định ở đâu đó không? Phần nào của việc triển khai mặc định sẽ dễ bị tổn thương?
Maarten Bodewes avatar
lá cờ in
Những báo cáo ngoại lệ đệm PKCS#7. TLS sử dụng MAC-sau đó-mã hóa, do đó, nó dễ bị tổn thương trước các cuộc tấn công tiên tri đệm.
lá cờ us
@MaartenBodewes vậy nói chung TLS 1.2 vẫn cho phép sử dụng triển khai AES-CBC mặc định không an toàn?
Maarten Bodewes avatar
lá cờ in
$$ Đúng vậy.
dave_thompson_085 avatar
lá cờ cn
(@MaartenBodewes) đối với lời tiên tri đệm 'lucky13', có một TÙY CHỌN cho mã hóa-then-MAC, rfc7366 vào năm 2014, nhưng tôi không biết về bất kỳ triển khai nào đã thêm EtM mà không thêm 1.3, tất nhiên là tốt hơn . Lỗ hổng _other_ của CBC trong 1.0 và SSL3, bị lộ IV, bị BEAST tấn công (dẫn đến việc mọi người chuyển sang TO!! RC4 trong một thời gian), đã được sửa trong 1.1 (và 1.2).
Maarten Bodewes avatar
lá cờ in
@dave_thompson_085 Tôi đang đề cập đến cuộc tấn công chung chống lại CBC bằng phần đệm trong giao thức đó. Các cuộc tấn công cụ thể về thời gian chỉ hữu ích khi lời tiên tri đệm không có sẵn trực tiếp dựa trên các điều kiện lỗi, v.v. Và vâng, tôi không thể nhớ đã nhìn thấy EtM ở bất cứ đâu...
Gilles 'SO- stop being evil' avatar
lá cờ cn
@dave_thompson_085 OpenSSL bắt đầu thêm hỗ trợ cho mã hóa-then-MAC [năm 2013](https://github.com/openssl/openssl/commit/5e3ff62c345c976cd1ffbcc5e6042f55264977f5), GnuTLS [năm 2014](https://gitlab.com/gnutls /gnutls/-/tree/e93cef18471962b001dac0f792cb569f1a4cde58), Mbed TLS [năm 2014](https://github.com/ARMmbed/mbedtls/commit/699cafaea27c72ea68aa85bd8a4e18afb879e272). Nó không được hỗ trợ phổ biến, nhưng nó cũ hơn TLS 1.3. Tuy nhiên, nó mới hơn TLS 1.2, đây là phiên bản đầu tiên có giải pháp thay thế tốt cho CBC (GCM).
Điểm:2
lá cờ cn

Tôi chỉ có thể nghĩ về một điểm yếu của AES-CBC trong TLS 1.1 trở lên, đó là Lucky Thirteen tấn công. Đây là một cuộc tấn công vào một cách được thiết kế kém để đệm các tin nhắn khiến nó đặc biệt dễ bị tổn thương đến một tấn công tiên tri đệm do sử dụng MAC-sau đó-mã hóa (với sơ đồ đệm khiến cuộc tấn công khá dễ dàng).

Cuộc tấn công ban đầu dựa vào việc có được một decryption_failed cảnh báo khi phần đệm bị sai, đó là đã sửa trong TLS 1.1 bằng cách tiếp tục với một khóa phiên ngẫu nhiên do lỗi đệm (và việc triển khai TLS 1.0 cũng đã áp dụng biện pháp đối phó này). Tuy nhiên, việc triển khai TLS 1.2 ngây thơ tiếp tục dễ bị tấn công thông qua thời gian: điều mà kẻ tấn công cần biết là có bao nhiêu byte đệm chính xác và thời gian cần thiết để xử lý thông báo làm rò rỉ thông tin này trừ khi người triển khai rất cẩn thận .

Các phiên bản hiện đại của triển khai TLS chính thống bảo vệ chống lại Lucky Thirteen, vì vậy nhìn chung bạn có thể sử dụng bộ mật mã CBC một cách an toàn. Tuy nhiên, có một chi phí thực hiện cho biện pháp đối phó này: việc thực hiện về cơ bản phải xử lý tất cả các độ dài đệm có thể, trong đó có tới 256, sau đó kết hợp các kết quả. Xin lưu ý rằng các triển khai cũ hơn hoặc triển khai không được thiết kế để bảo mật cao vẫn có thể dễ bị tấn công.

Một số triển khai TLS (ít nhất là OpenSSL, GnuTLS và Mbed TLS) hỗ trợ phần mở rộng mã hóa-then-MAC mà hoàn toàn bảo vệ chống lại lỗ hổng này.

Trong mọi trường hợp, lý do duy nhất để sử dụng Bộ mật mã CBC là nói chuyện với các hệ thống cũ không hỗ trợ bộ mật mã AEAD (sử dụng GCM, CCM hoặc Chacha-Poly). Bộ mật mã AEAD nhanh hơn và ít gặp rủi ro bảo mật hơn. Thông thường, lý do bộ mật mã CBC vẫn tồn tại là vì lợi ích của các hệ thống có công cụ mã hóa không thể nâng cấp một cách hiệu quả (ví dụ: vì nó đã được chứng nhận và không ai muốn trả tiền để chứng nhận việc triển khai GCM hoặc CCM). Nếu lý do để tránh GCM và Chacha-poly là do khả năng tăng tốc AES, thì CCM sẽ tận dụng lợi thế đó và thường sẽ nhanh hơn bộ mật mã CBC (yêu cầu tính toán HMAC).

Bộ mật mã CBC đã bị xóa trong TLS 1.3 bởi vì chúng khó triển khai chính xác (và không thể triển khai với cả hiệu suất cao và tính bảo mật cao) và lý do duy nhất để giữ chúng là khả năng tương thích với các hệ thống cũ hơn. Với phiên bản giao thức mới hơn, không có lý do quan trọng nào để giữ chúng. Và bởi vì TLS 1.3 nhằm mục đích loại trừ tất cả các cơ chế mật mã khó thực hiện một cách an toàn, bộ mật mã CBC chắc chắn phải ra đời.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.