Làm cách nào để vô hiệu hóa SSLv3 trong máy chủ SSH OpenSSH để tránh POODLE?

Trước lỗ hổng POODLE mới được phát hiện , tôi muốn tắt SSLv3 trên tất cả các máy chủ SSH của mình. Làm thế nào để tôi đạt được điều này với OpenSSH?

Đây không phải là vấn đề đối với OpenSSH vì nó không sử dụng SSL.

Họ khác nhau về những thứ xung quanh đường hầm. Theo truyền thống, SSL sử dụng chứng chỉ X.509 để thông báo khóa công khai của máy chủ và máy khách; SSH có định dạng riêng. Ngoài ra, SSH đi kèm với một bộ giao thức cho những gì đi vào bên trong đường hầm (ghép nhiều lần chuyển, thực hiện xác thực dựa trên mật khẩu trong đường hầm, quản lý thiết bị đầu cuối ...) trong khi không có điều đó trong SSL, hay chính xác hơn là khi những thứ như vậy được sử dụng trong SSL, chúng không được coi là một phần của SSL (ví dụ: khi thực hiện xác thực HTTP dựa trên mật khẩu trong đường hầm SSL, chúng tôi nói rằng đó là một phần của "HTTPS", nhưng nó thực sự hoạt động theo cách tương tự những gì xảy ra với SSH).

Về mặt khái niệm, bạn có thể lấy SSH và thay thế phần đường hầm bằng phần từ SSL. Bạn cũng có thể lấy HTTPS và thay thế điều SSL bằng SSH-with-data-Transport và hook để trích xuất khóa công khai của máy chủ từ chứng chỉ của nó. Không có sự bất khả thi về mặt khoa học và nếu được thực hiện đúng cách, bảo mật sẽ vẫn như cũ. Tuy nhiên, không có bộ quy ước rộng rãi hoặc các công cụ hiện có cho điều đó.

Để chứng minh thêm, tôi sẽ hướng bạn đến RFC 4253 , thảo luận về "Giao thức lớp vận chuyển lớp vỏ bảo mật (SSH)". Đây là lớp vận chuyển tùy chỉnh của SSH, nó không sử dụng cùng một lớp mà HTTPS / SSL sử dụng.

Tài liệu này mô tả giao thức lớp vận chuyển SSH, thường chạy trên TCP / IP. Giao thức có thể được sử dụng làm cơ sở cho một số dịch vụ mạng an toàn. Nó cung cấp mã hóa mạnh mẽ, xác thực máy chủ và bảo vệ tính toàn vẹn. Nó cũng có thể cung cấp nén.

Cuối cùng, câu hỏi và trả lời này từ trang SE bảo mật có tiêu đề: SSL3 Hồi Poodle xông dễ bị tổn thương có điều này để nói về cuộc tấn công POODLE.

Cuộc tấn công Poodle hoạt động trong bối cảnh được chọn rõ, như BEAST và CRIME trước đó. Kẻ tấn công quan tâm đến dữ liệu được bảo vệ bằng SSL và anh ta có thể:

• tiêm dữ liệu của chính mình trước và sau giá trị bí mật mà anh ta muốn có được;
• kiểm tra, chặn và sửa đổi các byte kết quả trên dây.

Kịch bản chính và duy nhất hợp lý khi gặp các điều kiện như vậy là bối cảnh Web: kẻ tấn công chạy điểm truy cập WiFi giả và tiêm một số Javascript của chính mình như một phần của trang Web (HTTP, không phải HTTPS) mà nạn nhân duyệt. Javascript độc ác khiến trình duyệt gửi yêu cầu đến trang web HTTPS (giả sử là trang Web của ngân hàng) mà trình duyệt của nạn nhân có cookie. Kẻ tấn công muốn cookie đó.

Vì vậy, không có hành động nào cần được thực hiện cho OpenSSH trước mối đe dọa đặc biệt này.

Người giới thiệu

• POODLE đã xảy ra như thế nào
• Phân loại mật mã / MAC / Kex có sẵn trong SSH?
• Cấu hình bảo mật của mật mã / MAC / Kex có sẵn trong SSH

Đọc thêm

• Tính dễ bị tổn thương của SSL3 Poodle