Câu hỏi Làm cách nào để tôi vá lỗ hổng bảo mật SSLv3 POODLE (CVE-2014-3566)?


Sau Đòn tấn công BEAST và Lỗi Heartbleed, bây giờ tôi đã nghe nói về một lỗ hổng mới trong SSL / TLS được gọi là POODLE. Làm thế nào để bảo vệ bản thân mình khỏi bị khai thác?

  • Chỉ có máy chủ hoặc khách hàng bị ảnh hưởng?
  • Đây có phải là OpenSSL / GnuTLS cụ thể không?
  • Loại dịch vụ nào bị ảnh hưởng? Chỉ HTTPS hoặc IMAPS, SMTPS, OpenVPN, v.v ...?

Vui lòng cho tôi xem các ví dụ về cách tránh lỗ hổng này.


158
2017-10-14 23:49


gốc


Tìm thêm thông tin tại đây SSL3 "Poodle" Lỗ hổng - Braiam
@ Bradra Vâng tôi biết, Thomas rực rỡ một lần nữa! Tuy nhiên, đó là một Q & A theo định hướng mật mã. Điều này Q & A trên AU là nghĩa vụ phải cung cấp thông tin theo định hướng thực tế và Ubuntu. :-) - gertvdijk
Huh? Làm thế nào để bạn mong đợi một giải pháp thực tế hơn "Nếu bạn không cài đặt các bản vá lỗi sau đó Níðhöggr sẽ nuốt lá lách của bạn." - Braiam
@Braiam Trước hết: không có miếng vá (đọc câu trả lời của tôi). Tôi nghĩ rằng Thomas đang đề cập đến các thiết bị chứ không phải là máy chủ lưu trữ web DIY-Ubuntu. Các thiết bị như cân bằng tải thường cung cấp các bản cập nhật firmware để thay đổi các thiết lập mặc định hoặc sẽ cung cấp chức năng để có thể cấu hình nó. Tuy nhiên, trong Ubuntu, tất cả tùy thuộc vào người dùng / quản trị viên. - gertvdijk
Trên thực tế có: các nhà cung cấp có thể vô hiệu hóa / loại bỏ tất cả các mã liên quan SSLv3, do đó bạn không cần phải chạm vào bất cứ điều gì, ở tất cả. - Braiam


Các câu trả lời:


Thông tin cơ bản

SSL được thiết kế để đảm bảo mức độ vận chuyển trên internet. Đối với 'web' aka HTTP, bạn sẽ biết điều này là HTTPS, nhưng nó cũng được sử dụng cho các giao thức ứng dụng khác. SSLv2 là giao thức bảo mật vận tải được sử dụng rộng rãi đầu tiên nhưng không được bảo mật lâu sau đó. Những người kế thừa SSLv3 và TLSv1 hiện được hỗ trợ rộng rãi. TLSv1.1 và TLSv1.2 mới hơn và cũng nhận được nhiều hỗ trợ. Hầu hết nếu không phải tất cả các trình duyệt web được phát hành từ năm 2014 đều có hỗ trợ cho nó.

Phát hiện gần đây của các kỹ sư Google chỉ ra rằng SSLv3 không nên được sử dụng nữa (như SSLv2 không được sử dụng trong một thời gian dài trước đây). Các khách hàng không thể kết nối với trang web / dịch vụ của bạn có thể rất hạn chế. CloudFlare công bố ít hơn 0,09% khách truy cập của họ vẫn dựa vào SSLv3.

Giải pháp đơn giản: tắt SSLv3.

Ubuntu có cung cấp bất kỳ cập nhật nào không?

Có, qua usn-2385-1 với việc bổ sung tính năng SCSV, nhưng nó không giảm thiểu hoàn toàn vấn đề vì nó không tắt SSLv3 và bản vá sẽ chỉ hoạt động nếu cả hai mặt của kết nối đã được vá. Bạn sẽ nhận được thông qua các cập nhật bảo mật thông thường trong trình quản lý gói của bạn.

Do đó vẫn BẠN phải tự hành động để tắt SSLv3 (có thể định cấu hình). Các phiên bản máy khách / trình duyệt trong tương lai sẽ vô hiệu hóa SSLv3 nhiều khả năng nhất. Ví dụ. Firefox 34 sẽ làm như vậy.

Vô hiệu hóa SSLv3 hoàn toàn theo mặc định trong Ubuntu trên cấp độ thực thi có thể sẽ phá vỡ một số thứ ngoài việc sử dụng SSL HTTPS không dễ bị tổn thương, vì vậy tôi cho rằng những người bảo trì sẽ không làm điều đó và chỉ có bản vá SCSV này mới được áp dụng.

Tại sao bản cập nhật SCSV trong OpenSSL qua usn-2385-1 không giảm thiểu vấn đề?

Thực sự, hãy ngừng hỏi những câu hỏi như vậy và chỉ bỏ qua một vài đoạn và tắt SSLv3. Nhưng hey, nếu bạn không bị thuyết phục, ở đây bạn đi:

POODLE cho thấy SSLv3 với mật mã CBC bị hỏng, việc triển khai SCSV không thay đổi điều đó. SCSV chỉ đảm bảo bạn không hạ cấp từ một số giao thức TLS xuống bất kỳ giao thức TLS / SSL thấp hơn nào nếu cần với tấn công Man-in-the-Middle cần thiết cho các trường hợp thông thường.

Nếu bạn phải truy cập vào một số máy chủ không cung cấp TLS, nhưng chỉ có SSLv3, thì trình duyệt của bạn không thực sự có lựa chọn và phải nói chuyện với máy chủ bằng SSLv3, sau đó dễ bị tấn công mà không có bất kỳ cuộc tấn công hạ cấp nào.

Nếu bạn phải truy cập vào một số máy chủ cung cấp TLSv1 + và SSLv3 (không khuyến khích) và bạn muốn chắc chắn rằng kết nối của bạn sẽ không bị hạ cấp xuống SSLv3 bởi kẻ tấn công, thì cả hai máy chủ và máy khách cần bản vá SCSV này.

Để giảm thiểu hoàn toàn vấn đề, việc vô hiệu hóa SSLv3 của bạn là đủ và bạn có thể chắc chắn rằng bạn sẽ không bị hạ cấp. Và bạn sẽ không thể nói chuyện với máy chủ chỉ SSLv3.

Ok, vậy làm cách nào để tắt SSLv3?

Xem phần bên dưới trong các phần ứng dụng cụ thể: Firefox, Chrome, Apache, Nginx và Postfix được đề cập đến ngay bây giờ.

Chỉ có máy chủ hoặc khách hàng bị ảnh hưởng?

Lỗ hổng tồn tại nếu cả máy chủ và máy khách đều chấp nhận SSLv3 (ngay cả khi cả hai đều có khả năng TLSv1 / TLSv1.1 / TLS1.2 do một cuộc tấn công hạ cấp).

Là quản trị viên máy chủ, bạn nên tắt SSLv3 hiện nay để bảo mật cho người dùng của bạn.

Là người dùng, bạn nên tắt SSLv3 trong trình duyệt của mình hiện nay để tự bảo vệ mình khi truy cập các trang web vẫn hỗ trợ SSLv3.

Đây có phải là OpenSSL / GnuTLS / trình duyệt cụ thể không?

Không. Đó là lỗi giao thức (thiết kế), không phải là lỗi triển khai. Điều này có nghĩa là bạn không thể thực sự vá nó (trừ khi bạn đang thay đổi thiết kế của SSLv3 cũ).

Và có, có một Bản phát hành bảo mật OpenSSL, nhưng đọc bên dưới (Nhưng tôi thực sự cần hỗ trợ SSLv3 ... vì lý do X, Y, Z!) về lý do tại sao bạn nên tập trung vào việc tắt hoàn toàn SSLv3.

Tôi có thể giết SSLv3 trên cấp độ mạng (tường lửa) không?

Vâng, vâng, có thể. Tôi đặt điều này trong một bài đăng blog riêng biệt để có thêm suy nghĩ và công việc. Chúng tôi có thể có một số phép thuật iptables quy tắc bạn có thể sử dụng!

Bài đăng trên blog của tôi: Làm thế nào để gỡ bỏ SSLv3 trong mạng của bạn bằng cách sử dụng iptables cho POODLE?

Nó có liên quan đến HTTPS chỉ hoặc cũng cho IMAP / SMTP / OpenVPN và các giao thức khác có hỗ trợ SSL không?

Các vector tấn công hiện tại, như được hiển thị bởi các nhà nghiên cứu, làm việc với việc kiểm soát plaintext được gửi đến máy chủ bằng cách sử dụng Javascript đang chạy trên máy của nạn nhân. Vector này không áp dụng cho các trường hợp không phải HTTPS mà không sử dụng trình duyệt.

Ngoài ra, thông thường một máy khách SSL không cho phép phiên bị hạ cấp xuống SSLv3 (có TLSv1 + được nhìn thấy trong các khả năng bắt tay), nhưng các trình duyệt muốn tương thích ngược và họ thực hiện. Sự kết hợp với việc kiểm soát bản rõ và cách cụ thể mà một tiêu đề HTTP được xây dựng làm cho nó có thể khai thác được.

Kết luận: tắt SSLv3 cho HTTPS hiện nay, tắt SSLv3 cho các dịch vụ khác trong cửa sổ dịch vụ tiếp theo của bạn.

Tác động là gì? Tôi có cần thu hồi và tạo lại chứng chỉ máy chủ của mình không? (Như với Heartbleed)

Không, bạn không cần phải xoay chứng chỉ của mình cho việc này. Lỗ hổng này cho thấy việc khôi phục văn bản thô từ dữ liệu phiên, nó không cung cấp quyền truy cập vào bất kỳ bí mật nào (không phải khoá phiên hoặc khóa chứng chỉ).

Kẻ tấn công hầu như chỉ có khả năng ăn cắp các tiêu đề văn bản thô sơ như cookie phiên để thực hiện tấn công phiên. Một ràng buộc bổ sung là sự cần thiết cho một (đầy đủ) hoạt động Tấn công MitM.

Tôi có thể làm gì khác để cải thiện cấu hình SSL của mình nói chung không?

Là người dùng, bên cạnh việc tắt SSLv3 trong trình duyệt của bạn, không thực sự. Vâng, chỉ cần luôn cài đặt các bản cập nhật bảo mật mới nhất.

Đối với máy chủ, hãy làm theo Hướng dẫn máy chủ TLS của Mozilla. Và thử nghiệm với Kiểm tra SSL Labs của Qualys. Nó thực sự không khó để có được một đánh giá A + trên trang web của bạn. Chỉ cần cập nhật các gói của bạn và thực hiện các khuyến nghị từ hướng dẫn của Mozilla.

Nhưng tôi thực sự cần hỗ trợ SSLv3 ... vì lý do X, Y, Z! Giờ thì sao?

Vâng, có một bản vá mà phá vỡ các cuộc tấn công hạ cấp của TLSv1 khách hàng có khả năng, được gọi là bảo vệ dự phòng SSLv3. Nó cũng sẽ cải thiện tính bảo mật của TLSv1 +, bằng cách này (hạ cấp tấn công khó hơn / không thể). Nó được cung cấp như một backport từ một phiên bản OpenSSL mới hơn trong tư vấn bảo mật Ubuntu usn-2385-1.

Big catch: Cả khách hàng và máy chủ đều cần bản vá này để hoạt động. Vì vậy, theo ý kiến ​​của tôi trong khi bạn đang cập nhật cả khách hàng và máy chủ, bạn chỉ nên nâng cấp lên TLSv1 +.

Tuy nhiên, xin vui lòng, xin vui lòng, chỉ cần nghỉ hưu SSLv3 trong mạng của bạn cho bây giờ. Đặt nỗ lực nâng cấp các tiêu chuẩn bảo mật và chỉ cần vặn SSLv3.

Tôi đã nghe về sự hỗ trợ của SCSV để loại bỏ tấn công hạ cấp giao thức. Tôi có cần nó không?

Chỉ khi bạn thực sự cần SSLv3 vì một số lý do kỳ lạ, nhưng nó cũng cải thiện tính bảo mật trong TLSv1 +, vì vậy có, tôi khuyên bạn nên cài đặt nó. Ubuntu cung cấp bản cập nhật cho tính năng này trong usn-2385-1. Bạn sẽ nhận được thông qua các cập nhật bảo mật thông thường trong trình quản lý gói của bạn.

Kiểm tra lỗ hổng cho các trang web được lưu trữ riêng tư (ví dụ: intranet / offline).

Máy chủ của bạn dễ bị tấn công đơn giản nếu chúng hỗ trợ SSLv3. Một số tùy chọn ở đây:

  • Với OpenSSL s_client:

    openssl s_client -connect <server>:<port> -ssl3
    

    Nếu kết nối thành công, sslv3 được bật. Nếu nó không thành công, nó bị vô hiệu hóa. Khi nó không thành công, bạn sẽ thấy một cái gì đó như:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
    
  • Sử dụng nmap:

    nmap --script ssl-enum-ciphers -p 443 myhostname.tld
    

    Nó nên xuất 'SSLv3: No supported ciphers found'. Điều chỉnh cho tên máy chủ / cổng của bạn.

  • Sử dụng cipherscan. Sao chép / tải xuống tệp nhị phân và thực thi nó:

    ./cipherscan myhostname.tld
    

    Nó nên không phải liệt kê mọi thứ với SSLv3 trong cột 'giao thức'.


Trình duyệt Firefox

Mở about:config, tìm thấy security.tls.version.min và đặt giá trị thành 1. Sau đó khởi động lại trình duyệt của bạn để thả bất kỳ kết nối SSL mở nào.

Firefox từ phiên bản 34 trở đi sẽ tắt SSLv3 theo mặc định và do đó không yêu cầu hành động nào (nguồn). Tuy nhiên, tại thời điểm viết bài, 33 chỉ được phát hành và 34 được đặt cho ngày 25 tháng 11.


Google Chrome (Linux)

Chỉnh sửa /usr/share/applications/google-chrome.desktop tệp, ví dụ:

sudo nano /usr/share/applications/google-chrome.desktop

Chỉnh sửa tất cả các dòng bắt đầu với Exec= bao gồm --ssl-version-min=tls1.

Ví dụ. một dòng như

Exec=/usr/bin/google-chrome-stable %U

trở thành

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

Sau đó, hãy đảm bảo đóng hoàn toàn trình duyệt (các ứng dụng Chrome có thể giữ cho trình duyệt của bạn hoạt động ở chế độ nền!).

Lưu ý: Bạn có thể cần phải lặp lại điều này mỗi lần cập nhật gói google-chrome, ghi đè lên điều này .desktop tệp trình khởi chạy. Trình duyệt Google Chrome hoặc Chromium có SSLv3 bị tắt theo mặc định chưa được công bố tại thời điểm viết.


Máy chủ Apache HTTPD

Nếu bạn đang chạy một máy chủ web Apache hiện đang cho phép SSLv3, bạn sẽ cần chỉnh sửa cấu hình Apache. Trên hệ thống Debian và Ubuntu, tệp /etc/apache2/mods-available/ssl.conf. Trên CentOS và Fedora tập tin là /etc/httpd/conf.d/ssl.conf. Bạn sẽ cần phải thêm dòng sau vào cấu hình Apache của bạn với các chỉ thị SSL khác.

SSLProtocol All -SSLv2 -SSLv3

Điều này sẽ cho phép tất cả các giao thức ngoại trừ SSLv2 và SSLv3.

Trong khi bạn đang ở đó, bạn có thể muốn xem xét việc cải thiện cấu hình ciphersuite cho máy chủ web của bạn như được giải thích trên Hướng dẫn máy chủ TLS của Mozilla. Thêm ví dụ:

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"

Sau đó kiểm tra xem cấu hình mới có đúng không (không có lỗi chính tả, v.v.):

sudo apache2ctl configtest

Và khởi động lại máy chủ, ví dụ:

sudo service apache2 restart

Trên CentOS và Fedora:

systemctl restart httpd

Thêm thông tin: Tài liệu Apache

Bây giờ hãy thử nghiệm: Nếu trang web của bạn có sẵn công khai, hãy thử nghiệm trang web bằng cách sử dụng Công cụ SSL Labs của Qualys.


Máy chủ Nginx

Nếu bạn đang chạy Nginx, chỉ cần bao gồm dòng sau trong cấu hình của bạn trong số các chỉ thị SSL khác:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Trong khi bạn đang ở đó, bạn có thể muốn xem xét việc cải thiện cấu hình ciphersuite cho máy chủ web của bạn như được giải thích trên Hướng dẫn máy chủ TLS của Mozilla. Thêm ví dụ:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;

Và khởi động lại máy chủ, ví dụ:

sudo service nginx restart

Tài liệu tham khảo: Tài liệu Nginx

Bây giờ hãy thử nghiệm: Nếu trang web của bạn công khai, có sẵn, hãy thử nghiệm trang web bằng cách sử dụng Công cụ SSL Labs của Qualys.


Lighttpd webserver

Phiên bản Lighttpd> 1.4.28 hỗ trợ tùy chọn cấu hình để tắt SSLv2 và v3. Lighttpd phát hành trước 1.4.28 cho phép bạn tắt SSLv2 ONLY. Xin lưu ý rằng Ubuntu 12.04 LTS và cài đặt trước đó ở lighttpd v1.4.28 tốt nhất và do đó, bản sửa lỗi đơn giản không có sẵn cho những bản phân phối đó.  Do đó, bản sửa lỗi này chỉ nên được sử dụng cho các phiên bản Ubuntu lớn hơn 12.04.

Đối với phiên bản Ubuntu 12.04 hoặc Debian 6, gói lighttpd đã cập nhật có sẵn từ kho lưu trữ openSUSE: http://download.opensuse.org/repositories/server:/http/Debian_6.0

Gói này dành cho Debian 6 (squeeze) nhưng cũng hoạt động trên 12.04 (chính xác)

Chỉnh sửa của bạn /etc/lighttpd/lighttpd.conf để thêm các dòng sau sau ssl.engine = "enable" chỉ thị

ssl.use-sslv2          = "disable"
ssl.use-sslv3          = "disable"

Sau đó, bạn nên khởi động lại dịch vụ lighttpd với một sudo service lighttpd restart và thực hiện kiểm tra bắt tay ssl3 như được mô tả trong phần trước để đảm bảo rằng thay đổi đã được thực hiện thành công.

Được lấy từ http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL.


Postfix SMTP

Đối với 'SSL cơ hội' (chính sách mã hóa không được thi hành và đồng bằng cũng được chấp nhận), bạn không cần phải thay đổi bất cứ điều gì. Ngay cả SSLv2 cũng tốt hơn đồng bằng, vì vậy nếu bạn cần bảo mật máy chủ của mình, bạn nên sử dụng chế độ 'bắt buộc SSL'.

Đối với chế độ 'SSL bắt buộc' đang được định cấu hình, chỉ cần thêm / thay đổi smtpd_tls_mandatory_protocols thiết lập cho các kết nối gửi đến và smtp_tls_mandatory_protocols cho các kết nối gửi đi:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

Tùy chọn, nếu bạn muốn vô hiệu hóa SSLv3 cho mã hóa cơ hội là tốt (mặc dù nó không cần thiết như đã giải thích ở trên), hãy làm như vậy:

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

và khởi động lại Postfix:

sudo service postfix restart

Gửi thư

(Chỉnh sửa chưa được xác minh bởi người dùng ẩn danh, tôi không cảm thấy thoải mái với Sendmail, vui lòng xác minh.)

Các tùy chọn này được định cấu hình trong LOCAL_CONFIG phần của bạn sendmail.mc

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

Dovecot

Trong Dovecot v2.1 +, thêm thông tin sau vào /etc/dovecot/local.conf (hoặc một tệp mới trong /etc/dovecot/conf.d):

ssl_protocols = !SSLv2 !SSLv3

và khởi động lại Dovecot:

sudo service dovecot restart

Đối với các phiên bản cũ hơn, bạn sẽ phải vá mã nguồn.


Chuyển phát nhanh-imap (imapd-ssl)

Courier-imap cho phép SSLv3 theo mặc định trên Ubuntu 12.04 và các phiên bản khác. Bạn nên vô hiệu hóa nó và sử dụng STARTTLS thay vì để buộc TLS. Chỉnh sửa của bạn /etc/courier/imapd-ssl tệp cấu hình để phản ánh các thay đổi sau

IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"

Máy chủ HAProxy

SSL được hỗ trợ trong HAProxy> = 1.5.

Chỉnh sửa /etc/haproxy.cfg và tìm thấy bind hàng. Nối thêm no-sslv3. Ví dụ:

bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3

Tài liệu tham khảo: Tài liệu HAProxy


OpenVPN

Xuất hiện để không bị ảnh hưởng (nguồn).

OpenVPN sử dụng TLSv1.0, hoặc (với> = 2.3.3) tùy chọn TLSv1.2 và do đó không bị ảnh hưởng bởi POODLE.


Con rối

Puppet sử dụng SSL qua HTTPS nhưng nó không được sử dụng bởi các trình duyệt 'trình duyệt', chỉ là các tác nhân Puppet không dễ bị tấn công bởi vectơ tấn công được hiển thị. Tuy nhiên, cách tốt nhất là tắt SSLv3.

Đề xuất của tôi là sử dụng stephenrjohnson / puppetmodule Mô-đun con rối để thiết lập chủ con rối của bạn trong đó Tôi đã giết SSLv3 một thời gian trước.


210
2017-10-14 23:49



Câu trả lời này được tạo ra rất nhanh chóng sau khi phát hành lỗ hổng công khai. Có thể có lỗi trong đó - như mọi khi, cảm thấy tự do để chỉnh sửa / cải thiện. - gertvdijk
Cấu hình Nginx không được có dấu hai chấm sau chỉ thị ssl_protocols - Michelle
Được rồi, với Firefox tôi tin điều này là những gì đang xảy ra. - fuglede
Bài đăng trên blog của Mozilla Security này đề xuất cài đặt tiện ích này thay vì tinh chỉnh tùy chọn theo cách thủ công. - legoscia
@muru Đây là một khởi đầu về việc giết SSLv3 trên mức tường lửa. blog.g3rt.nl/take-down-sslv3-using-iptables.html - gertvdijk


Có thể không phải là ubuntu cụ thể nhưng để làm việc xung quanh lỗ hổng Poodle trong Node.js bạn có thể thiết lập secureOptions đến require('constants').SSL_OP_NO_SSLv3 khi bạn tạo một máy chủ https hoặc tls.

Xem https://gist.github.com/3rd-Eden/715522f6950044da45d8 để biết thêm thông tin


4
2017-10-15 08:59



IMO bạn không nên để lộ HTTP (S) với Node / Python / Ruby hoặc bất cứ thứ gì như thế trực tiếp. Đặt một HTTPd phong nha trước mặt nó như Apache / Nginx / ... - gertvdijk
Vâng, bạn không nên để lộ trực tiếp. Các ngôn ngữ không tốt với HTTP lớp tcp, nhưng chúng lại làm thay đổi ổ cắm. Hãy nginx đọc nó từ một ổ cắm. :-) - jrg♦
Điều này không xứng đáng với một cuộc bỏ phiếu xuống. Có rất nhiều trường hợp mà tls được sử dụng bên cạnh việc lưu trữ một máy chủ http. - psanford
@gertvdijk & jrg Node.js không phải là ngôn ngữ. Đó là một khuôn khổ để xây dựng các ứng dụng mạng có thể mở rộng. Và khi bạn nói rằng bạn nên đặt Node.js đằng sau một máy chủ Apache (và thậm chí gọi nó là "phong nha") đã làm cho nó rõ ràng rằng bạn hoàn toàn không có ý tưởng những gì bạn đang nói về. Nói rằng họ không tốt với tpc / http rõ ràng là thiên vị cá nhân. Xin vui lòng chỉ ở lại trên chủ đề unstead công nghệ bỏ phiếu trẻ con xuống bạn không hiểu. - 3rdEden
@ 3rdEden Vâng, có lẽ nhận xét của tôi là một chút tổng quát, nhưng đây là một vài lưu ý tôi muốn thực hiện. 1) Tôi không downvote, 2) bình luận của tôi là một 'IMO' nhẹ nhàng, 3) Có lẽ nó chỉ là nền tảng của tôi về an ninh, nhưng tôi đã học được rằng không nên để lộ một khung ứng dụng trực tiếp lên 80/443 với thế giới sản xuất. (trừ khi có mục đích trình diễn). 4) Tôi không thấy bài viết của bạn là một câu trả lời cho câu hỏi cho khách truy cập Ask Ubuntu chung; nó chỉ rất cụ thể đối với một trường hợp cụ thể của việc triển khai Node.js. - gertvdijk


Các "sửa chữa" cho chuyển phát nhanh vô hiệu hóa tls 1.1 và tls 1.2. Có vẻ như không phải là cách để chạy chuyển phát nhanh với tls 1.1 trở lên. Quét PCI trên máy chủ của bạn có thể quay trở lại với đề xuất:

Định cấu hình máy chủ SSL / TLS để chỉ sử dụng TLS 1.1 hoặc TLS 1.2 nếu được hỗ trợ. Định cấu hình máy chủ SSL / TLS để chỉ hỗ trợ các bộ mã hóa không sử dụng mật mã khối.


0
2018-02-27 14:45





Vì POODLE Vulnerability là một lỗ hổng thiết kế trong chính giao thức và không phải là lỗi thực thi, sẽ không có các bản vá lỗi. Chỉ có cách để giảm thiểu điều này là tắt SSLv3 trong máy chủ apache. Thêm các dòng dưới đây vào ssl.conf và thực hiện khởi động lại apache duyên dáng.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

-1
2017-10-15 22:55



-1 cho bao gồm RC4 và ECDSA phi chức năng vì hầu hết mọi người đều có chứng chỉ RSA. Vui lòng chỉ đọc về cách định cấu hình máy chủ của bạn đúng cách. wiki.mozilla.org/Security/Server_Side_TLS - gertvdijk
@gertvdijk Tôi đồng ý với bạn về RC4, nhưng nó không đau khi bao gồm các bộ ECDSA. Nó vô hại nếu bạn chỉ có một RSA cert và tiết kiệm cho bạn những rắc rối của việc sửa chữa cấu hình của bạn nếu sau này bạn nhận được một chứng chỉ ECDSA. - Matt Nordhoff
@MattNordhoff Đủ công bằng, nhưng ý tôi là không có nhiều mật mã được để lại cho một cấu hình dựa trên chứng chỉ RSA thông thường. Nó sẽ làm việc trong hầu hết các trình duyệt, nhưng có thể gặp phải các vấn đề tương thích. - gertvdijk
Chắc chắn loại bỏ RC4 khỏi danh sách này, điều đó không an toàn. Ở lại với phần còn lại nếu bạn có thể. 3DES yếu, nhưng tôi đã bật tính năng này ở một nơi cụ thể để tương thích. Tôi ghét làm điều đó vì nó yếu, nhưng ít nhất nó không bị hỏng ... - Brian Knoblauch