Làm cách nào để tôi vá / khắc phục lỗ hổng SSLv3 POODLE (CVE-2014-3566)?


157

Sau cuộc tấn công BEASTlỗi Heartbleed , giờ tôi đã nghe về một lỗ hổng mới trong SSL / TLS có tên là POODLE . Làm thế nào để tôi bảo vệ bản thân khỏi bị khai thác?

  • Có phải máy chủ hoặc khách hàng cũng bị ảnh hưởng?
  • Đây có phải là OpenSSL / GnuTLS cụ thể không?
  • Những loại dịch vụ 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.


2
Thông tin chi tiết có thể được tìm thấy ở đây
Lỗ

1
@Braiam Vâng, tôi biết, Thomas tuyệt vời một lần nữa! Tuy nhiên, đó là một câu hỏi và trả lời theo định hướng mật mã. Câu hỏi và trả lời này trên AU được cho là cung cấp thông tin thực tế và theo định hướng Ubuntu. :-)
gertvdijk

10
Huh? Làm thế nào để bạn mong đợi một giải pháp thiết thực hơn "Nếu bạn không cài đặt các bản vá thì Níðhöggr sẽ nuốt chửng lá lách của bạn."
Braiam

2
@Braiam Trước hết: không có bản 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ị hơn là lưu trữ máy chủ web DIY-Ubuntu. Các thiết bị như bộ cân bằng tải thường cung cấp các bản cập nhật firmware để thay đổi cài đặt mặc định hoặc sẽ cung cấp chức năng để có thể định 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 / xóa tất cả các mã liên quan đến SSLv3, do đó bạn hoàn toàn không cần phải chạm vào bất cứ thứ gì.
Braiam

Câu trả lời:


209

Thông tin cơ bản

SSL được thiết kế để bảo đảm mức độ vận chuyển trên internet. Đối với 'web' hay còn gọi là HTTP, bạn sẽ biết đâ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 chuyển được sử dụng rộng rãi đầu tiên nhưng được phát hiện không an toàn sau đó không lâu. Người kế vị 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 sự hỗ trợ. Hầu hết nếu không phải tất cả các trình duyệt web 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òn được sử dụng từ lâu). 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ó lẽ rất hạn chế. CloudFlare thông báo rằng í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: vô hiệu hóa SSLv3.

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

Có, thông 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 vô hiệu hóa 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 nó thông qua các cập nhật bảo mật thường xuyên trong trình quản lý gói của bạn.

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

Việc vô hiệu hóa hoàn toàn SSLv3 theo mặc định trong Ubuntu ở cấp độ triển khai có thể sẽ phá vỡ một số thứ ngoài đó đối với việc sử dụng SSL không HTTPS không dễ bị tổn thương, vì vậy tôi cho rằng các nhà bảo trì sẽ không làm điều đó và chỉ bản vá SCSV này sẽ đượ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 được vấn đề?

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

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 khi cần với cuộc 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 một số máy chủ hoàn toàn không cung cấp TLS, mà 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 bị tấn công.

Nếu bạn phải truy cập 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ả máy chủ và máy khách đều cần bản vá SCSV này.

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

Được rồi, vậy làm cách nào để tắt SSLv3?

Xem bên dưới trong các phần cụ thể của ứng dụng: Firefox, Chrome, Apache, Nginx và Postfix hiện được bảo hiểm.

Có phải máy chủ hoặc khách hàng cũng bị ảnh hưởng?

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

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

Là người dùng, bạn nên tắt SSLv3 trong trình duyệt của mình ngay bây giờ để bảo mật chính 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ỗi thực thi. Điều này có nghĩa là bạn thực sự không thể vá nó (trừ khi bạn thay đổi thiết kế của SSLv3 cũ).

Và vâng, có một bản phát hành bảo mật OpenSSL mới , 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 vô hiệu hóa SSLv3 hoàn toàn.

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

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

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

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

Các vectơ tấn công hiện tại, như được hiển thị bởi các nhà nghiên cứu, hoạt động với việc kiểm soát bản rõ đượ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. Vectơ này không áp dụng cho các tình huống không phải HTTPS mà không sử dụng trình duyệt.

Ngoài ra, thông thường, máy khách SSL không cho phép phiên bị hạ cấp xuống SSLv3 (có TLSv1 + được 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 rất ngược và chúng thực hiện. Sự kết hợp với kiểm soát bản rõ và cách thức cụ thể của một tiêu đề HTTP được xây dựng làm cho nó có thể khai thác được.

Kết luận: vô hiệu hóa SSLv3 cho HTTPS ngay bây giờ , vô hiệu hóa 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 bảo mật phục hồi bản rõ 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 khóa phiên hoặc khóa chứng chỉ).

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

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

Là người dùng, ngoài việc vô hiệu hóa SSLv3 trong trình duyệt của bạn, không thực sự. Vâng, chỉ luô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à kiểm tra với bài kiểm tra SSL Labs của Qualys . Thực sự không khó để có được xếp hạng 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 đề xuất 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?

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

Bắt lớn: Cả máy khách và máy chủ đều cần bản vá này để hoạt động. Vì vậy, theo tôi, trong khi bạn đang cập nhật cả máy khách và máy chủ, bạn vẫn nên nâng cấp lên TLSv1 +.

Tuy nhiên, làm ơn, làm ơn, hãy rút SSLv3 trong mạng của bạn ngay bây giờ. Nỗ lực nâng cấp các tiêu chuẩn bảo mật và bỏ qua SSLv3.

Tôi đã nghe nói về hỗ trợ SCSV để loại bỏ cuộc 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, 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 nó thông qua các cập nhật bảo mật thường xuyên 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ụ: mạng nội bộ / ngoại tuyến).

Máy chủ của bạn dễ bị tấn công 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 thất bại, nó bị vô hiệu hóa. Khi thất bại, 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ó sẽ xuất ra ' SSLv3: No supported ciphers found'. Điều chỉnh cho tên máy chủ / cổng của bạn.

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

    ./cipherscan myhostname.tld
    

    không nên liệt kê bất cứ điều gì với SSLv3 trong cột 'giao thức'.


Trình duyệt Firefox

Mở about:config, tìm security.tls.version.minvà đặt giá trị thành 1. Sau đó khởi động lại trình duyệt của bạn để loại bỏ mọi kết nối SSL đang mở.

Firefox từ phiên bản 34 trở đi sẽ vô hiệu hóa SSLv3 theo mặc định và do đó không yêu cầu phải có hành động ( nguồn ). Tuy nhiên, tại thời điểm viết bài, 33 mới đượ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.desktoptập tin, vd

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ụ như 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 đó, đảm bảo đóng hoàn toàn trình duyệt (ứ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 lặp lại mỗi lần cập nhật gói google-chrome này, ghi đè lên .desktoptệp trình khởi chạy này . Trình duyệt Google Chrome hoặc Chromium với 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ủ HTTPD Apache

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 các hệ thống Debian và Ubuntu, tệp là /etc/apache2/mods-av Available / ssl.conf . Trên CentOS và Fedora, tệp là /etc/httpd/conf.d/ssl.conf . Bạn sẽ cần thêm dòng sau vào cấu hình Apache của mình bằng 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 cải thiện cấu hình ciphersuite cho máy chủ web của mình như được giải thích trong 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ủ, vd

sudo service apache2 restart

Trên CentOS và Fedora:

systemctl restart httpd

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

Bây giờ hãy kiểm tra nó: Nếu trang web của bạn có sẵn công khai, hãy kiểm tra nó bằ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 cải thiện cấu hình ciphersuite cho máy chủ web của mình như được giải thích trong 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ủ, vd

sudo service nginx restart

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

Bây giờ hãy kiểm tra nó: Nếu trang web của bạn là công khai, có sẵn, hãy kiểm tra nó bằng công cụ SSL Labs của Qualys .


Máy chủ web Lighttpd

Các 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 vô hiệu hóa CHỈ SSLv2. 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 đó, một bản sửa lỗi đơn giản không có sẵn cho các bản phân phối đó. Do đó, 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 Ubuntu phiên bản 12.04 hoặc Debian 6, gói lighttpd được cập nhật có sẵn từ kho lưu trữ openSUSE: http://doad.opensuse.org/repos khu / server: / http / Debian_6.0

Gói dành cho Debian 6 (bóp) nhưng cũng hoạt động vào ngày 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 bằng a sudo service lighttpd restartvà thực hiện kiểm tra bắt tay ssl3 như được mô tả trong các phần trước để đảm bảo rằng thay đổi đã được thực hiện thành công.

Lấy từ http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL .


Hậu tố SMTP

Đối với 'SSL cơ hội' (chính sách mã hóa không được thi hành và cũng có thể chấp nhận được), 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 đơn giản, vì vậy nếu bạn cần bảo mật máy chủ của mình, bạn vẫn nên sử dụng chế độ 'SSL bắt buộc'.

Để chế độ 'SSL bắt buộc' đã được định cấu hình, chỉ cần thêm / thay đổi cài đặt smtpd_tls_mandatory_prot Protocol cho các kết nối gửi đến và giao thức smtp_tls_mandatory_prot cho các kết nối đi:

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

Tùy chọn, nếu bạn cũng muốn tắt SSLv3 để mã hóa cơ hội (mặc dù điều đó 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 hài lòng với Sendmail, vui lòng xác minh.)

Các tùy chọn này được cấu hình trong LOCAL_CONFIGphần của bạnsendmail.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 phần 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 loại khác. Bạn nên vô hiệu hóa nó và sử dụng STARTTLS thay vào đó để buộc TLS. Chỉnh sửa /etc/courier/imapd-ssltệp cấu hình của bạn để 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.cfgtập tin và tìm binddòng của bạn . Nối no-sslv3. Ví dụ:

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

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

Con rối sử dụng SSL qua HTTPS nhưng nó không được sử dụng bởi các máy khách của 'trình duyệt', chỉ là các tác nhân rối 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à chỉ vô hiệu hóa SSLv3.

Đề nghị của tôi là sử dụng mô đun Puppetmodule Puppetmodule Puppet để thiết lập Master Puppet mà tôi đã giết SSLv3 một thời gian trước đây.


7
Câu trả lời này đã được tạo ra rất rất nhanh sau khi phát hành công khai lỗ hổng. Có thể vẫn còn lỗi - như mọi khi, vui lòng chỉnh sửa / cải thiện.
gertvdijk

1
Nginx config không nên có dấu hai chấm sau chỉ thị ssl_prot Protocol
Michelle

1
Được rồi, đối với Firefox tôi tin rằng đây là những gì đang diễn ra.
fuglede

4
Bài đăng trên blog Mozilla Security này đề nghị cài đặt tiện ích bổ sung này thay vì điều chỉnh tùy chọn thủ công.
Legoscia

1
@muru Đây là một khởi đầu trong việc tiêu diệt SSLv3 ở cấp độ tường lửa. blog.g3rt.nl/take-down-sslv3-USE-iptables.html
gertvdijk

4

Có thể không được ubuntu cụ thể nhưng để làm việc xung quanh vulnerablity Poodle trong Node.js bạn có thể thiết lập secureOptionsđể require('constants').SSL_OP_NO_SSLv3khi 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


1
IMO bạn không nên để lộ HTTP (S) bằng Node / Python / Ruby hoặc bất cứ thứ gì tương tự. Đặt một HTTPd đàng hoàng trước nó như Apache / Nginx / ...
gertvdijk

Vâng, bạn không nên tiếp xúc trực tiếp. Các ngôn ngữ không tốt với HTTP lớp tcp, nhưng chúng làm rung chuyển các ổ cắm. Hãy để nginx đọc nó từ một ổ cắm. :-)
jrg

4
Điều này không xứng đáng để bỏ phiếu. Có rất nhiều trường hợp 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 khung để xây dựng các ứng dụng mạng có thể mở rộng. Và khi bạn tuyên bố rằng bạn nên đặt Node.js phía sau máy chủ Apache (và thậm chí gọi nó là "đàng hoàng") đã nói rõ rằng bạn hoàn toàn không biết bạn đang nói gì. 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ỉ ở chủ đề không ổn định về công nghệ bỏ phiếu trẻ con mà bạn không hiểu.
Thứ 3,

@ 3rdEden Vâng, có lẽ nhận xét của tôi là một chút khái 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 đánh giá thấp, 2) Nhận xét của tôi là một 'IMO' nhẹ nhàng, 3) Có lẽ đó chỉ là nền tảng của tôi về bảo mật, nhưng tôi đã học được rằng người ta không nên đưa khung ứng dụng trực tiếp tới 80/443 cho thế giới sản xuất. (trừ khi cho mục đích trình diễn). 4) Tôi không thấy bài đăng của bạn là 'câu trả lời' cho câu hỏi dành cho khách truy cập Ubuntu hỏi chung; nó chỉ rất rất cụ thể đối với một trường hợp triển khai Node.js cụ thể.
gertvdijk

0

"Sửa" cho chuyển phát nhanh vô hiệu hóa tls 1.1 và tls 1.2. Dường như không có cách nào để 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 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ật mã không sử dụng mật mã khối.


-1

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, nên sẽ không có bản vá. Cách duy nhất để giảm thiểu điều này là vô hiệu hóa 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
-1 bao gồm RC4 và ECDSA không chức năng vì hầu hết mọi người đều có chứng chỉ RSA. Xin vui lòng chỉ đọc về cách cấu hình máy chủ của bạn đúng cách. wiki.mozilla.org/Security/Server_Side_TLS
gertvdijk

2
@gertvdijk Tôi đồng ý với bạn về RC4, nhưng không bao gồm các bộ ECDSA. Sẽ vô hại nếu bạn chỉ có chứng chỉ RSA và giúp bạn tránh những rắc rối khi sửa cấu hình nếu sau này bạn nhận được 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òn lại cho cấu hình dựa trên chứng chỉ RSA thông thường. Nó sẽ hoạt động trong hầu hết các trình duyệt, nhưng người ta có thể phải đối mặt vớ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 nó ở một nơi cụ thể để tương thích. Tôi ghét phải làm điều đó vì nó yếu, nhưng ít nhất nó không thực sự bị hỏng ...
Brian Knoblauch
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.