Vô hiệu hóa RC4 trong bộ mật mã SSL của máy chủ Apache

Xin vui lòng, xem các phần EDIT trong câu trả lời của riêng tôi; chúng chứa một lời giải thích cho câu hỏi hóc búa này .

Tôi đang cố gắng vô hiệu hóa RC4 cho máy chủ Apache 2.2.9 chạy trên VPS CentOS 6.5 và tôi dường như không thể thành công.

Một chứng chỉ xác thực doanh nghiệp đã mua gần đây đã được cài đặt và các kết nối SSL đang hoạt động tốt nhưng tôi muốn định cấu hình mọi thứ tốt nhất có thể, để "tăng cường bảo mật" như một số hướng dẫn đưa ra.

Kiểm tra cấu hình với Qualys SSL Labs, trang kết quả hiển thị "Máy chủ này chấp nhận mật mã RC4, yếu. Lớp được giới hạn ở B."

Tuy nhiên, tôi đã đặt cái này trong ssl.conf:

 SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3

Tôi đã lưu tập lệnh được đưa ra trong câu trả lời cho câu hỏi này trong một tệp có tên test-ssl-ciphers.sh và thay đổi địa chỉ IP thành địa chỉ loopback. Đây là kết quả của ./test-ssl-ciphers.sh | grep -i "RC4":

Testing ECDHE-RSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ECDHE-ECDSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing AECDH-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ADH-RC4-MD5...NO (sslv3 alert handshake failure)
Testing ECDH-RSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ECDH-ECDSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing RC4-SHA...NO (sslv3 alert handshake failure)
Testing RC4-MD5...NO (sslv3 alert handshake failure)
Testing RC4-MD5...NO (sslv3 alert handshake failure)
Testing PSK-RC4-SHA...NO (no ciphers available)
Testing KRB5-RC4-SHA...NO (no ciphers available)
Testing KRB5-RC4-MD5...NO (no ciphers available)
Testing EXP-ADH-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-KRB5-RC4-SHA...NO (no ciphers available)
Testing EXP-KRB5-RC4-MD5...NO (no ciphers available)

Mỗi dòng này chứa "KHÔNG", theo kịch bản, có nghĩa là máy chủ không hỗ trợ kết hợp mật mã được chỉ định.

Hơn nữa, lệnh chỉ grep -i -r "RC4" /etc/httpdcung cấp cho tôi tệp ssl.conf đã đề cập ở trên.

Ngoài ra, chạy openssl ciphers -Vtrên bộ mật mã của tôi cho thấy không có mật mã RC4 nào cả, điều này có ý nghĩa với chuỗi cấu hình.

Do đó, bằng cách nào đó tôi đã mất lý do tại sao các trang web kiểm tra SSL lại nói với tôi rằng "máy chủ chấp nhận RC4". Họ thậm chí liệt kê các mật mã sau đây được chấp nhận:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA

Có ai có một lời giải thích có thể? Tôi đang làm gì sai? Có lẽ có một nơi khác mà sự hỗ trợ của RC4 hoặc "chấp nhận" được cấu hình?

Cảm ơn.

[ EDIT ] Sử dụng CentOS 6.6 trong máy ảo tại nhà, tôi chạy lại đoạn script với VPS của mình bằng tên miền thay vì địa chỉ loopback. Thiết lập này ngụ ý rằng danh sách các mật mã được cung cấp bởi cá thể openssl trong VM: Tôi vẫn không có RC4 trong số các mật mã mang lại CÓ.

Trong khi cài đặt chứng chỉ được gia hạn, tôi phát hiện ra rằng sự cố xảy ra do chỉ định (cho tên miền và cho từng tên miền phụ) trong ISPConfig toàn bộ bộ dữ liệu cần thiết cho HTTPS: chứng chỉ, khóa riêng, chuỗi CA, v.v.

Đặt khác nhau, loại bỏ tập dữ liệu dẫn đến kiểm tra Qualys để xếp loại miền A và đồng thời xóa các cảnh báo về RC4. Đặt các chi tiết trở lại dẫn đến các cảnh báo quay trở lại và lớp được giới hạn ở B một lần nữa, điều này không có chỗ cho nghi ngờ về liên kết nhân quả.

Như thể việc cung cấp các chi tiết cho mỗi vhost bằng cách nào đó đã tạo ra một môi trường mới trong đó một số mặc định đã ghi đè lên bộ mật mã mà tôi đã chỉ định trong ssl.conf. Kỳ dị.

Giải pháp là thêm đặc tả SSLCodesSuite trong văn bản Chỉ thị Apache cho mỗi vhost. Đây là những gì tôi có trong cấu hình giúp tôi đạt điểm A:

SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder on
# Compression is disabled by default on my distribution (CentOS 6)
# SSLCompression off 
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

EDIT (2017-05-16): Một phát hiện bổ sung về vấn đề này: việc chỉ định SSLCipherSuitelà bắt buộc. Tôi không thể hiểu tại sao chỉ thị cụ thể đó, mặc dù được chỉ định ở cấp máy chủ không tự động áp dụng cho các cấu hình máy chủ ảo . Tôi đang chạy Apache 2.2.15 trên CentOS 6.9.

EDIT (2018-06-18): Thêm thông tin. Tôi vừa mới phát hiện ra rằng SSLCipherSuitechỉ có thể được xác định một lần duy nhất và nó sẽ áp dụng cho tất cả các host ảo: trong file cấu hình cơ sở mod_ssl (trên CentOS 6, các tập tin được tìm thấy tại /etc/httpd/conf.d/ssl.conf), bạn chỉ cần có để xác định các chỉ bên ngoài của Virtualhost mặc định. Tài liệu Apache 2.2 nói rằng giá trị mặc định của lệnh này là SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP. Tôi cho rằng đây là nơi mật mã RC4 xuất phát: trong trường hợp không có bất kỳ đặc điểm kỹ thuật nào, đó là trường hợp đối với tôi vì không có thông số kỹ thuật nào trong bối cảnh "toàn cầu", giá trị mặc định được áp dụng. Sự hiểu biết này kết thúc những gì đã là một bí ẩn đối với tôi. Trớ trêu thay, tôi sắp chuyển sang CentOS 7 khi tôi tìm thấy lời giải thích này! HTH.

SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3
                                                                    ^^^^^^^

Ý kiến ​​tồi. Vô hiệu hóa tất cả các mật mã SSLv3 dẫn đến việc vô hiệu hóa các mật mã có thể sử dụng được với TLS1.0 và TLS1.1 và chỉ để lại một số mật mã mới được giới thiệu với TLS1.2 (nếu máy chủ của bạn hỗ trợ TLS1.2)

Do đó, bằng cách nào đó tôi đã mất lý do tại sao các trang web kiểm tra SSL lại nói với tôi rằng "máy chủ chấp nhận RC4". Họ thậm chí liệt kê các mật mã sau đây được chấp nhận:

Đảm bảo rằng bạn kiểm tra cục bộ và kiểm tra bên ngoài đều truy cập vào cùng một máy chủ (địa chỉ IP). Tôi đã thấy rất nhiều trang web example.comtrên một máy chủ khác so với www.example.comcác thử nghiệm khác nhau.

Các phòng thí nghiệm SSL của Qualys có vẻ rất nhạy cảm với các máy chủ mặc định, v.v. Hãy kiểm tra xem TẤT CẢ các Máy chủ ảo HTTPS của bạn trên địa chỉ IP đó có sử dụng cùng một cài đặt không một số thử nghiệm dường như chọn Virtualhost mặc định. Vhost được nhắm mục tiêu của tôi chỉ có một mật mã được kích hoạt nhưng Qualys đang tìm một danh sách lớn hơn nhiều từ vhost mặc định.

Tôi cũng tìm thấy một tập lệnh trông đẹp hơn ở đây cung cấp thông tin kỹ lưỡng hơn về các bài kiểm tra SSL.

Chỉ cần xem qua điều này cho một trong các trang web của tôi. Trên cơ sở câu trả lời của @ AbVog, tôi thấy rằng các chỉ thị của tôi thực sự chỉ nằm trong vhost mặc định. Khi tôi chuyển các chỉ thị đến bối cảnh toàn cầu, tất cả đều tốt.

Bên cạnh đó, tôi cũng đã xem qua https://codesli.st/ , nơi có một danh sách tốt về cấu hình SSL cho một loạt các gói khác nhau. Các khuyến nghị hiện tại cho apache như sau:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff

# Requires Apache >= 2.4
SSLCompression off 
SSLSessionTickets Off
SSLUseStapling on 
SSLStaplingCache "shmcb:logs/stapling-cache(150000)" 

Trên Fedora 25 của tôi với các mật mã Apache / 2.4.25 được xử lý bởi các chính sách tiền điện tử (xem / etc / cryptopol Nether / backends). Thiết lập mặc định có RC4 bị vô hiệu hóa hoàn toàn, do đó không cần phải giả mạo bằng mật mã trong thiết lập Apache. Ngoại trừ việc đảm bảo rằng bạn sử dụng ssl.conf mới nhất vì nó không được cài đặt theo mặc định mà được để lại dưới dạng ssl.conf.rpmnew trong thư mục conf.d.

Để định cấu hình SSL, tôi chỉ phải xác định chứng chỉ, ServerName và DocumentRoot. Đối với Squirrelmail đó là.

SSLCertificateFile /etc/letsencrypt/live/mail.xxxx.dk/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.xxxx.dk/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/mail.xxxx.dk/chain.pem
SSLCACertificateFile /etc/letsencrypt/live/mail.xxxx.dk/fullchain.pem
ServerName mail.xxxx.dk:443
DocumentRoot "/usr/share/squirrelmail"