TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 có dễ bị Zombie POODLE/GOLDENDOODLE tấn công không?

Tôi nhận được nhiều báo cáo hỗn hợp về vấn đề này. Tôi có một máy chủ lưu trữ web và nhiều công cụ quét SSL (bao gồm cả công cụ được điều hành bởi Phòng thí nghiệm SSL của Qualsys), nói rằng bộ mật mã TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 KHÔNG dễ bị Zombie POODLE/GOLDENDOODLE tấn công, đồng thời tôi có một công ty tuân thủ PCI chỉ ra rằng nó Là dễ bị tổn thương. Thật không may, cả hai đều không sẵn sàng nhúc nhích về vấn đề này hoặc cung cấp nhiều chi tiết hơn những gì tôi đã đề cập ở đây.

Tôi không biết nhiều về tiền điện tử, nhưng tôi biết đủ rằng chỉ riêng việc có "CBC" trong tên của bộ mật mã đã gợi ý rằng nó thực hiện chuỗi khối mật mã và mở rộng ra có nghĩa là nó có khả năng vô tình tiết lộ một lời tiên tri đệm , và do đó dễ bị Zombie POODLE tấn công. Nếu đúng như vậy thì tại sao tất cả các công cụ quét SSL mà tôi đã sử dụng lại đề xuất khác?

Ngoài ra, tôi nhận ra rằng có những lập luận hợp lệ chống lại việc sử dụng TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 nói chung, nhưng điều đó nằm ngoài phạm vi của câu hỏi này, vì tôi thực sự chỉ quan tâm đến việc liệu nó có dễ bị Zombie POODLE/GOLDENDOODLE tấn công cụ thể hay không.

Bộ mật mã chỉ ra rằng CBC đệm PKCS#7 được sử dụng với xác minh MAC chỉ được thực hiện sau khi giải mã. Điều đó có nghĩa là nó dễ bị tấn công bởi các oracle bản rõ trước khi xác minh MAC.

Việc hủy đệm chủ yếu gặp rủi ro không phải vì các tiên tri đệm có nhiều khả năng rò rỉ thông tin hơn so với các tiên tri văn bản gốc khác, mà đơn giản là vì việc hủy đệm thường diễn ra trước khi MAC được phục hồi.

Thủ thuật triển khai là không bỏ đệm một cách rõ ràng vì độ dài của văn bản gốc đã được biết trước và để thực hiện so sánh (tốt nhất là hằng số thời gian) của thẻ xác thực do HMAC tạo trước khi bất kỳ byte văn bản gốc nào được sử dụng.

Nếu việc triển khai không được biết thì công ty tuân thủ PCI đã đúng, nhưng nó sẽ gây ra rủi ro. Đây là một lỗi có thể tránh được tương đối dễ dàng bằng cách sử dụng TLS 1.3 hoặc TLS 1.2 bằng cách sử dụng chế độ hoạt động GCM hoặc CCM cho AES.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 là một giao thức (một tập con của họ giao thức TLS). Zombie POODLE và GOLDENDOODLE là các lỗ hổng trong một số triển khai của giao thức này. Vì vậy, nếu công ty tuân thủ tuyên bố, chỉ biết rằng máy chủ của bạn chấp nhận bộ mật mã này, rằng máy chủ của bạn có thể dễ bị tấn công, thì họ đã đúng. Nếu công ty tuân thủ tuyên bố rằng ngay sau khi máy chủ của bạn chấp nhận bộ mật mã này, thì nó dễ bị tấn công, thì họ đã nhầm.

Các cuộc tấn công này dựa trên phân tích các phản hồi lỗi được gửi bởi máy chủ TLS khi nó nhận được thông tin đầu vào không hợp lệ (có thể đến từ một ứng dụng khách độc hại hoặc một kẻ trung gian. (Phân tích này cũng bao gồm khả năng không có phản hồi như thời gian của phản hồi.) Cả hai đều đệm tấn công oracle. Tất cả các bộ mật mã TLS sử dụng CBC đều dễ bị tấn công tiên tri đệm nếu được triển khai một cách ngây thơ. Hầu như mọi triển khai TLS đều dễ bị tấn công Mười ba may mắn khi nó được tiết lộ vào năm 2013 và một số vẫn có thể dễ bị tổn thương trước các biến thể của nó, nhưng OpenSSL và một số ngăn xếp TLS chính khác hiện triển khai các biện pháp đối phó để bảo vệ hoàn toàn khỏi các cuộc tấn công tiên tri đệm nếu được triển khai đúng cách.Các biện pháp đối phó đó về bản chất là chậm và tinh vi, vì vậy bạn có thể không muốn dựa vào chúng, nhưng đối với mức độ bảo mật dự kiến ​​cho việc tuân thủ PCI, thì chúng là đủ.

Nếu máy chủ của bạn sử dụng OpenSSL hoặc ngăn xếp TLS của Windows hoặc hầu hết các triển khai TLS chính thì sẽ an toàn. (Tuy nhiên, OpenSSL dễ bị tấn công bởi một cuộc tấn công tương tự khác được phát hiện cùng lúc, được đặt tên là â0-length OpenSSLâ vì nó rất cụ thể đối với hành vi của OpenSSL.) Điều bạn cần lo lắng chủ yếu là một số hộp trung gian giải mã lưu lượng TLS ( tường lửa, cân bằng tải, â¦). Mặc dù vậy, miễn là bạn áp dụng tất cả các bản vá lỗi bảo mật, bạn sẽ ổn thôi (và nếu chương trình cơ sở mới nhất vẫn dễ bị tổn thương, hãy từ bỏ nhà cung cấp của bạn ngay lập tức).

Trong mọi trường hợp, bạn có thể sử dụng máy quét được cung cấp bởi các nhà nghiên cứu đã phát hiện ra các cuộc tấn công để kiểm tra hệ thống của bạn. Đây là cùng một máy quét mà Qualys (và chắc chắn là những người khác) sử dụng, vì vậy nếu Qualys nói rằng hệ thống của bạn không dễ bị tấn công, thì bạn không gặp vấn đề về bảo mật: vấn đề duy nhất của bạn là thuyết phục kiểm toán viên của mình.

Nếu kiểm toán viên của bạn ở bất kỳ nơi nào gần đủ năng lực, thì họ nên chạy máy quét này hoặc sử dụng dịch vụ chạy máy quét này và kết luận rằng hệ thống của bạn không dễ bị tấn công. Nhưng đánh giá bằng phản ứng của họ, họ có thể kém năng lực hơn. Một kiểm toán viên giỏi sẽ biết và có thể giải thích mọi thứ tôi đã viết ở đây. Điều kỳ lạ là kiểm toán viên chỉ đề cập đến hai cuộc tấn công đó nhằm vào các bộ mật mã dựa trên CBC chứ không phải các bộ mật mã cũ hơn như BEAST, Lucky Thirteen, v.v.

Bạn quan tâm đến việc hỗ trợ bộ mật mã CBC đến mức nào? Mặc dù chúng có thể được triển khai một cách an toàn, nhưng điều đó yêu cầu tất cả các máy chủ và hộp trung gian chặn TLS của bạn phải có chất lượng cao và đi kèm với một hình phạt về hiệu suất. nếu bạn không cần chúng, tôi khuyên bạn nên vô hiệu hóa chúng. Nói chung, đối với TLS, sự cân bằng tốt giữa bảo mật và khả năng tương thích là chỉ sử dụng các bộ mật mã dựa trên chữ ký (ví dụ:với ECDHE hoặc có thể là DHE trong tên của họ, ngoài RSA hoặc ECDSA), với AEAD (CCM, GCM hoặc CHACHA20_POLY1305). Một số bộ mật mã khác có thể an toàn, nhưng có nguy cơ lỗ hổng triển khai cao hơn.

Vì vậy, chiến lược của tôi với kiểm toán viên này sẽ là:

1. Kiểm tra xem bạn có thực sự muốn bộ mật mã CBC không. Nếu không, hãy vô hiệu hóa chúng và nói với kiểm toán viên của bạn rằng điểm này vẫn chưa được thảo luận.
2. Nếu bạn cần bộ mật mã CBC, hãy nhắc kiểm toán viên rằng đây là những lỗ hổng triển khai và lập luận rằng Qualys nói rằng việc triển khai dễ bị tấn công. Nếu họ vẫn chưa bị thuyết phục, hãy tự chạy trình quét tiên tri đệm và mời kiểm toán viên của bạn cùng làm như vậy.
3. Nếu kiểm toán viên thực sự không nghe thấy gì, bạn có thể không còn lựa chọn nào khác ngoài việc thay đổi kiểm toán viên. Tại thời điểm này, chúng tôi đã đi xa khỏi mật mã và bước vào lĩnh vực kinh doanh.