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ố iptables
quy 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
Nó 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.min
và đặ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.desktop
tậ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 .desktop
tệ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 restart
và 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_CONFIG
phầ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-ssl
tệ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.cfg
tập tin và tìm bind
dò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.