Disabilitazione di RC4 nella suite di crittografia SSL di un server Apache

Per favore, vedi le sezioni EDIT nella mia risposta; contengono una spiegazione a questo enigma .

Sto cercando di disabilitare RC4 per un server Apache 2.2.9 in esecuzione su un VPS CentOS 6.5 e non riesco a riuscirci.

Viene installato un certificato convalidato dall'azienda acquistato di recente e le connessioni SSL funzionano correttamente, ma volevo configurare le cose nel miglior modo possibile, per "rafforzare la sicurezza", come affermano alcuni tutorial.

Controllando la configurazione con Qualys SSL Labs, la pagina dei risultati mostra "Questo server accetta il codice RC4, che è debole. Grado limitato a B."

Tuttavia, l'ho inserito in ssl.conf:

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

Ho salvato lo script fornito nella risposta a questa domanda in un file chiamato test-ssl-ciphers.sh e ho cambiato l'indirizzo IP in un indirizzo di loopback. Questo è il risultato di ./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)

Ognuna di queste righe contiene "NO", che, secondo lo script, significa che il server non supporta la combinazione di cifratura specificata.

Inoltre, il comando grep -i -r "RC4" /etc/httpdmi dà solo il file ssl.conf sopra menzionato.

Inoltre, l'esecuzione openssl ciphers -Vsulla mia suite di cifratura non mostra affatto cifrature RC4, il che ha senso data la stringa di configurazione.

Pertanto, in qualche modo mi sono perso il motivo per cui i siti Web di controllo SSL mi stanno dicendo che "il server accetta RC4". Elencano persino le seguenti cifre come accettate:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA

Qualcuno ha una possibile spiegazione? Cosa sto facendo di sbagliato? Forse c'è un altro posto in cui configurare il supporto di RC4 o "accettazione"?

Grazie.

[ EDIT ] Usando un CentOS 6.6 in una macchina virtuale a casa, ho eseguito di nuovo lo script sul mio VPS usando il suo nome di dominio anziché l'indirizzo di loopback. Questa configurazione implica che l'elenco di cifre sia fornito dall'istanza openssl nella VM: non ho ancora RC4 tra le cifre che danno SÌ.

Durante l'installazione del certificato rinnovato, ho scoperto che il problema era causato specificando (per il dominio e per ogni sottodominio) in ISPConfig l'intero set di dati necessari per HTTPS: certificato, chiave privata, catena CA, ecc.

In altre parole, la rimozione del set di dati ha portato al test Qualys per valutare il dominio A e allo stesso tempo rimuovere gli avvisi su RC4. La reimpostazione dei dettagli comporta il ritorno degli avvertimenti e il voto di nuovo in B, che non lascia spazio a dubbi sul legame di causalità.

È come se il conferimento dei dettagli per ciascun vhost avesse in qualche modo creato un nuovo ambiente in cui alcune impostazioni predefinite hanno sovrascritto la suite di crittografia che ho specificato in ssl.conf. Strano.

La soluzione è aggiungere la specifica SSLCipherSuite nell'area di testo delle direttive Apache per ciascun vhost. Questo è quello che ho nella configurazione che mi fa ottenere un voto 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): un'ulteriore scoperta su questo problema: la specifica di SSLCipherSuiteè obbligatoria. Non riesco a capire perché quella direttiva specifica, sebbene sia specificata a livello di server, non si applica automaticamente alle configurazioni dell'host virtuale . Sto eseguendo Apache 2.2.15 su CentOS 6.9.

EDIT (18/06/2018): ulteriori informazioni. Ho appena scoperto che la SSLCipherSuitedirettiva può essere specificata una sola volta e si applicherà a tutti gli host virtuali: nel file di configurazione mod_ssl di base (su CentOS 6, il file si trova in /etc/httpd/conf.d/ssl.conf), devi semplicemente specificare la direttiva al di fuori di l'host virtuale predefinito. La documentazione di Apache 2.2 afferma che il valore predefinito di questa direttiva è SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP. Ritengo che sia da qui che deriva la cifra di RC4: in assenza di specifiche, come è stato per me dal momento che nessuna specifica era nel contesto "globale", si applica il valore predefinito. Questa comprensione pone fine a quello che è stato un mistero per me. Ironia della sorte, sto per passare a CentOS 7 quando trovo questa spiegazione! HTH.

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

Cattiva idea. La disabilitazione di tutte le cifre SSLv3 comporta la disabilitazione delle cifre utilizzabili con TLS1.0 e TLS1.1 e lascia solo alcune cifre appena introdotte con TLS1.2 (se il server supporta TLS1.2)

Pertanto, in qualche modo mi sono perso il motivo per cui i siti Web di controllo SSL mi stanno dicendo che "il server accetta RC4". Elencano persino le seguenti cifre come accettate:

Assicurarsi che entrambi i test locale e esterno accedano allo stesso server (indirizzo IP). Ho visto molti siti in cui si example.comtrova un host diverso rispetto a quello www.example.come quindi i test differiscono.

I laboratori SSL Qualys sembrano molto sensibili agli host predefiniti, ecc. Verifica che TUTTI i tuoi VirtualHost HTTPS su quell'indirizzo IP utilizzino le stesse identiche impostazioni (a parte i file dei certificati), ho avuto un problema simile in cui alcuni dei test Qualys testati contro il mio VirtualHost di destinazione e alcuni dei test sembravano raccogliere un VirtualHost predefinito. Il mio vhost di destinazione aveva un solo codice abilitato ma Qualys stava trovando un elenco molto più grande dal vhost predefinito.

Ho anche trovato uno script più bello qui che fornisce informazioni più approfondite sui test SSL.

Stavo solo cercando questo per uno dei miei siti. Sulla base della risposta di @ AbVog, ho scoperto che le mie direttive erano in realtà solo all'interno del vhost predefinito. Quando ho spostato le direttive nel contesto globale, tutto è andato bene.

Per inciso, mi sono anche imbattuto in https://cipherli.st/ che ha un buon elenco di configurazioni SSL per diversi pacchetti. L'attuale raccomandazione per apache come segue:

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

Sul mio Fedora 25 con Apache / 2.4.25 le cifre sono gestite dalle cripto-politiche (vedi / etc / cryptopolicies / backend). L'impostazione predefinita ha RC4 completamente disabilitato, quindi non è necessario manomettere i codici nell'impostazione di Apache. Tranne per assicurarsi di utilizzare l'ultimo ssl.conf poiché non è installato di default ma lasciato come ssl.conf.rpmnuovo nella directory conf.d.

Per configurare SSL ho dovuto solo specificare i certificati, ServerName e DocumentRoot. Per Squirrelmail che è.

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"