Bir Apache sunucusunun SSL şifreleme paketinde RC4'ü devre dışı bırakma

Lütfen kendi cevabımdaki DÜZENLEME bölümlerine bakınız; bu muammanın bir açıklamasını içerirler .

CentOS 6.5 VPS üzerinde çalışan bir Apache 2.2.9 sunucusu için RC4'ü devre dışı bırakmaya çalışıyorum ve başarılı olamıyorum.

Kısa süre önce satın alınmış, işletme tarafından onaylanmış bir sertifika yüklenir ve SSL bağlantıları düzgün çalışır, ancak bazı eğiticilerin belirttiği gibi "güvenliği sertleştirmek" için mümkün olan en iyi şekilde yapılandırmak istedim.

Qualys SSL Labs ile yapılandırmayı kontrol ettiğinizde, sonuçlar sayfasında "Bu sunucu zayıf olan RC4 şifresini kabul ediyor. Sınıf B ile sınırlı."

Ancak, ben ssl.conf:

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

Bu sorunun cevabında verilen komut dosyasını test-ssl-ciphers.sh adlı bir dosyaya kaydettim ve IP adresini geri döngü adresine değiştirdim. Bunun sonucu ./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)

Bu satırların her biri, komut dosyasına göre sunucunun belirtilen şifre kombinasyonunu desteklemediği anlamına gelen "HAYIR" içerir.

Ayrıca, komut grep -i -r "RC4" /etc/httpdbana yalnızca yukarıda belirtilen ssl.conf dosyasını verir.

Ayrıca, openssl ciphers -Vşifre takımımda çalışan hiçbir RC4 şifresi göstermiyor, bu da yapılandırma dizesi verildiğinde mantıklı.

Bu nedenle neden SSL kontrol web sitelerinin bana "sunucu RC4 kabul ettiğini" söylediğini neden kayboldum. Hatta aşağıdaki şifreleri kabul edilmiş olarak listeliyorlar:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA

Muhtemel bir açıklaması olan var mı? Ne yanlış bir şey yapıyorum? Belki de RC4 veya "kabul" desteğinin yapılandırıldığı başka bir yer var mı?

Teşekkürler.

[ EDIT ] Evde sanal bir makinede CentOS 6.6 kullanarak, komut dosyasını geri döngü adresi yerine etki alanı adını kullanarak VPS'imle tekrar çalıştırdım. Bu kurulum, şifrelerin listesinin VM'deki openssl örneği tarafından sağlandığını ima eder: YES veren şifrelerde hala RC4 yok.

Yenilenen sertifikayı kurarken, sorunun HTTPS için gerekli olan tüm veri kümesini (sertifika, özel anahtar, CA zinciri, vb.) ISPConfig'de (etki alanı ve her alt etki alanı için) belirtmekten kaynaklandığını keşfettim.

Başka bir ifadeyle, veri kümesinin kaldırılması, A etki alanını derecelendirmek ve aynı zamanda RC4 hakkındaki uyarıları kaldırmak için Qualys testine yol açtı. Ayrıntıları geri koymak, uyarıların geri gelmesine ve notun tekrar B'de sınırlanmasına neden olur, bu da nedensellik bağlantısına dair şüphelere yer bırakmaz.

Sanki her vhost için detayların verilmesi, bir şekilde bazı varsayılanların ssl.conf'da belirttiğim şifre paketini geçersiz kıldığı yeni bir ortam yaratmış gibi. Tuhaf.

Çözüm, her hayalet için Apache Direktifleri metin alanına SSLCipherSuite spesifikasyonunu eklemektir . Bu bana bir A notu alır yapılandırma var:

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): Bu sorun hakkında ek bir bulgu: belirlenmesi SSLCipherSuitezorunludur. Sunucu düzeyinde belirtilse de, bu ana yönergenin neden sanal ana bilgisayar yapılandırmaları için otomatik olarak geçerli olmadığını anlayamıyorum . CentOS 6.9'da Apache 2.2.15 kullanıyorum.

EDIT (2018-06-18): Daha fazla bilgi. Sadece bu fark ettik SSLCipherSuitetaban mod_ssl yapılandırma dosyasındaki (CentOS 6, dosya bulunur: yönergesi tek bir zaman belirtilebilir ve tüm sanal konaklar için geçerli olacaktır /etc/httpd/conf.d/ssl.conf, sadece direktif belirtmek gerekir) dışında arasında varsayılan sanal ana bilgisayar. Apache 2.2 belgeleri bu direktifin varsayılan değerinin olduğunu belirtir SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP. RC4 şifresinin geldiği yer budur: "global" bağlamda hiçbir spesifikasyon olmadığı için benim için geçerli olan herhangi bir spesifikasyon yokken, varsayılan değer geçerlidir. Bu anlayış benim için bir sır olan şeyi bitiriyor. İronik olarak, bu açıklamayı bulduğumda CentOS 7'ye geçmek üzereyim! HTH.

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

Kötü bir fikir. Tüm SSLv3 şifrelemelerini devre dışı bırakmak TLS1.0 ve TLS1.1 ile kullanılabilen şifrelemelerin devre dışı bırakılmasına neden olur ve TLS1.2 ile yeni tanıtılan birkaç şifreyi bırakır (sunucunuz TLS1.2'yi destekliyorsa)

Bu nedenle neden SSL kontrol web sitelerinin bana "sunucu RC4 kabul ettiğini" söylediğini neden kayboldum. Hatta aşağıdaki şifreleri kabul edilmiş olarak listeliyorlar:

Yerel ve harici testlerin aynı sunucuya (IP adresi) eriştiğinden emin olun. Ben daha example.comfarklı bir ana bilgisayar üzerinde birçok site gördüm www.example.comve böylece testler farklı.

Qualys SSL laboratuvarları varsayılan ana bilgisayarlara vb. Çok hassas görünüyor. Bu IP adresindeki TÜM HTTPS VirtualHost'larınızın aynı ayarları (sertifika dosyalarının yanı sıra) kullandığını kontrol edin, bazı Qualys testlerinin hedeflenen VirtualHost'umla test edildiğinde benzer bir sorun yaşadım ve bazı testler varsayılan bir VirtualHost aldı. Hedeflenen hayaletimde yalnızca bir şifre etkinleştirildi, ancak Qualys varsayılan hayaletten çok daha büyük bir liste buluyordu.

Ayrıca burada SSL testleri hakkında daha ayrıntılı bilgi veren daha iyi görünümlü bir komut dosyası buldum .

Sadece bu benim sitelerden biri için bakıyordu. @ AbVog'un cevabına dayanarak, direktiflerimin aslında sadece varsayılan vhost'un içinde olduğunu buldum. Direktifleri küresel bağlama taşıdığımda her şey iyiydi.

Bir yana, https://cipherli.st/ ile de karşılaştım . Apache için mevcut öneri aşağıdaki gibidir:

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)" 

Apache / 2.4.25 şifreli Fedora 25'te kripto politikaları tarafından ele alınmaktadır (bkz. / Etc / cryptopolicies / arka uçlar). Varsayılan kurulumda RC4 tamamen devre dışıdır, bu nedenle Apache kurulumunda şifreleri kurcalamaya gerek yoktur. En son ssl.conf dosyasını varsayılan olarak yüklenmediği, ancak conf.d dizininde ssl.conf.rpmnew olarak bıraktığınızdan emin olmanız dışında.

SSL'yi yapılandırmak için ServerName ve DocumentRoot sertifikalarını belirtmem gerekiyordu. Squirrelmail için bu.

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"