Sử dụng các tham số DH tùy chỉnh để giải mã TLS

Có một số cách để giải mã TLS, ví dụ: trong môi trường doanh nghiệp. Tôi không thấy việc sử dụng các tham số DH "cửa hậu" được đề cập ở đâu đó mặc dù theo hiểu biết của tôi, nó sẽ hoạt động về nguyên tắc: Làm thế nào để một mô đun không phải số nguyên tố cho Diffie-Hellman cho phép tạo ra một cửa hậu?

CPU máy tính để bàn gần đây có thể giải mã lưu lượng truy cập trong (gần như) thời gian thực không? Nó có phụ thuộc vào mật mã hoặc phiên bản TLS không? Có bất kỳ lợi thế/bất lợi nào khi sử dụng tùy chọn này không? Tôi đoán việc đánh cắp các tham số tùy chỉnh cũng tương tự như việc đánh cắp thông tin cá nhân và bạn mất PFS?

CPU máy tính để bàn gần đây có thể giải mã lưu lượng truy cập trong (gần như) thời gian thực không?

Nếu bạn đang hỏi cụ thể về các nhóm DH cửa sau, thì tốt, nếu bạn đang sử dụng phiên bản TLS cho phép máy chủ [1] đề xuất một nhóm DH không chuẩn (và khách hàng sẽ chấp nhận nhóm đó; những người lành mạnh sẽ không) , thì vâng, nó có thể đề xuất một nhóm cực kỳ yếu (ví dụ: nhóm mà $p-1$ không có thừa số lớn) và điều này sẽ làm cho việc khôi phục bí mật dùng chung (và do đó là các khóa lưu lượng) trở nên dễ dàng.

'Các nhóm DH yếu' như vậy là không thể nếu bạn đang thực hiện một phiên bản TLS lành mạnh (hoặc khách hàng từ chối chấp nhận một số tùy chọn khá kỳ quặc); mặt khác, nếu bạn đang thực hiện DH, bạn chỉ cần yêu cầu máy chủ sử dụng giá trị riêng DH có thể đoán được (ví dụ: một giá trị là chức năng của máy chủ hello cookie); kẻ tấn công có thể sử dụng nó để nghe lén.

Mặt khác, nếu bạn đang kiểm soát máy chủ, thì tại sao phải bận tâm? Máy chủ có các khóa lưu lượng trong tay; nếu kẻ thù kiểm soát điều đó, sẽ dễ dàng hơn nếu máy chủ cung cấp khóa phiên cho bất kỳ ai đang nghe.

[1]: Tôi nghĩ đó là máy chủ đề xuất nhóm DH trong TLS 1.2; nếu không, chỉ cần trao đổi máy khách và máy chủ trong đối số trên.

Trong giao thức TLS, máy chủ quyết định nhóm để trao đổi khóa: nhóm Diffie-Hellman trường hữu hạn hoặc đường cong elip. Máy chủ phải chọn trong các ràng buộc do máy khách đưa ra. Trong TLS 1.3, các nhóm được xác định từ một danh sách nhỏ các nhóm tiêu chuẩn. Các phiên bản trước của giao thức cho phép máy chủ mô tả một nhóm tùy chỉnh. Đối với các đường cong elip, điều này hiếm khi được hỗ trợ: hầu hết các phần mềm chỉ hỗ trợ các đường cong được đặt tên. Nhưng đối với trường hữu hạn Diffie-Hellman, máy khách thường chỉ hạn chế kích thước của nhóm và máy chủ sẽ gửi giá trị số của các tham số. Mặc dù hầu hết các phần mềm ngày nay đều hỗ trợ tiện ích mở rộng NamedGroup, nhưng hầu hết các máy khách sẽ chấp nhận các giá trị số để tương thích ngược. Vì vậy, một khách hàng có thể bị lừa chấp nhận các tham số FFDH được mở cửa sau.

Tuy nhiên, điều này hầu như không liên quan như một mối đe dọa bảo mật, bởi vì máy chủ chọn các tham số. Nếu máy chủ muốn thỏa hiệp việc trao đổi khóa, nó cũng có thể thực hiện trao đổi khóa hoàn toàn mạnh và sau đó ghi lại bí mật được chia sẻ ở đâu đó. Vì vậy, để các tham số FFDH yếu trở thành mối lo ngại về bảo mật, phải có một mô hình bảo mật cực kỳ khó xảy ra:

• Máy chủ đang chạy mã có cửa hậu (hoặc có cấu hình có cửa hậu) và bạn không thể phát hiện ra rằng cửa hậu đã được chèn vào.
• Mã có cửa hậu chỉ nằm trong một phần nhỏ của ngăn xếp TLS và bạn tin chắc rằng không có cửa hậu nào ở nơi khác có thể trực tiếp tiết lộ văn bản gốc hoặc bí mật được chia sẻ chẳng hạn.

Về cơ bản, FFDH có cửa hậu trong TLS chỉ có thể là máy chủ tự bắn vào chân mình. Việc nghe trộm lưu lượng giữa các máy chủ khác là không thích hợp. Máy chủ có cửa hậu và bạn không cần đến nó, hoặc máy chủ không có cửa hậu và điều đó sẽ không mang lại lợi ích gì cho bạn.