Có bất kỳ lợi ích bảo mật nào khi triển khai các nhóm SSH DH tùy chỉnh cho các hệ thống chỉ dành cho khách hàng không?

16

Một chiến lược giảm thiểu được đề xuất chống lại các cuộc tấn công liên quan đến Logjam trên SSH là tạo các nhóm SSH Diffie-Hellman tùy chỉnh bằng cách sử dụng một cái gì đó như (bên dưới là cho OpenSSH)

ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates

tiếp theo là thay thế tệp moduli trên toàn hệ thống bằng tệp đầu ra moduli-2048. ( ssh-keygen -Gđược sử dụng để tạo các số nguyên tố DH-GEX của ứng viên và ssh-keygen -Tđể kiểm tra các ứng cử viên được tạo ra để đảm bảo an toàn.)

Đây rõ ràng là một điều hợp lý để làm trên các máy chủ SSH, nếu không sẽ sử dụng các nhóm nổi tiếng cho vay tiền để tính toán trước, nhưng có bất kỳ lợi ích bảo mật nào khi triển khai các nhóm SSH DH tùy chỉnh trên các hệ thống chỉ dành cho khách hàng không? (Nghĩa là, các hệ thống kết nối với máy chủ SSH, nhưng không bao giờ hoạt động như một máy chủ SSH.)

Tôi chủ yếu quan tâm đến các câu trả lời liên quan đến OpenSSH trên Linux, nhưng các câu trả lời chung chung hơn cũng sẽ được đánh giá cao.

ssh ssh-keys logjam

— một CVn
nguồn

18

Bạn có thể nếu bạn thực sự muốn, nhưng tôi không muốn tạo lại các tham số DH 2048 bit cho OpenSSH. Có nhiều điều quan trọng hơn bạn cần làm để bảo mật SSH, như vô hiệu hóa tiền điện tử yếu .

Những gì tôi sẽ làm là xóa những cái hiện có ít hơn 2048 bit.

awk '$5 >= 2000' /etc/ssh/moduli > /etc/ssh/moduli.strong && \
mv /etc/ssh/moduli.strong /etc/ssh/moduli

Trong trường hợp bạn không nhận thấy, OpenSSH xuất xưởng với một số lượng lớn các mô đun được tạo trước, tất cả các cách lên tới 8192 bit. Mặc dù chúng tôi chắc chắn quan tâm đến các số nguyên tố 1024 bit ngày hôm nay, nhưng các số 2048 bit được cho là an toàn cho tương lai gần. Và trong khi điều đó cuối cùng sẽ thay đổi, nó có thể là vào tuần tới, nhưng nhiều khả năng sẽ rất lâu sau khi chúng tôi trở thành người nghỉ hưu ...

Ngoài ra còn có một chút tò mò trong ssh-keygentrang người đàn ông:

Điều quan trọng là tệp này chứa các mô đun có độ dài bit và cả hai đầu của một kết nối đều chia sẻ các mô đun chung.

Điều này dường như lập luận chống lại việc thay thế các mô-đun hiện có, mặc dù nó không thực sự cung cấp lý do thực sự cho việc đó.

— Michael Hampton
nguồn

Liên quan: Diffie-Hellman sử dụng một mô-đun khác nhau ở cả hai mặt trên Mật mã học . Theo hiểu biết hạn chế của tôi, có vẻ như nếu không có mô-đun chia sẻ có độ dài mong muốn, thì Diffie-Hellman với một nhóm có độ dài đó là không thể trong trường hợp chung và có thể không thể thực hiện được trong bất kỳ trường hợp cụ thể nào. Do đó, có các mô đun được chia sẻ giữa hai điểm cuối là một yêu cầu toán học của giao thức trao đổi khóa Diffie-Hellman và cố gắng thực hiện trao đổi khóa Diffie-Hellman giữa hai điểm cuối không có mô đun chung sẽ thất bại.

— một CVn

2

RFC 4419 [ tools.ietf.org/html/rfc4419] chính xác là cho phép máy chủ cung cấp các tham số DH tùy chỉnh. Máy chủ sẽ gửi các tham số ứng cử viên của nó cho máy khách và nếu máy khách đồng ý, cả hai bên đều sử dụng các tham số do máy chủ cung cấp để tạo bí mật chung được sử dụng làm khóa phiên. Vì vậy, sẽ rất ổn nếu máy chủ và máy khách không có cùng mục trong tệp moduli của chúng.

— Brian Minton

2

Câu trả lời là: Không. Không có lợi ích. :)

/etc/ssh/moduli tập tin chỉ được sử dụng cho phía máy chủ.

Bạn không cần phải lo lắng về tệp đó cho phía máy khách SSH:

Bạn có thể theo dõi việc thực hiện SSH client và kiểm tra xem nó không mở tệp đó.

$ strace -e openat ssh user@localhost

— Adi Roiban
nguồn