Informazioni sullo sfondo
SSL è progettato per proteggere il livello di trasporto su Internet. Per "il web" aka HTTP lo saprai come HTTPS, ma è anche usato per altri protocolli applicativi. SSLv2 è stato il primo protocollo di sicurezza del trasporto ampiamente utilizzato ma non è stato trovato sicuro poco dopo. I successori SSLv3 e TLSv1 sono ora ampiamente supportati. TLSv1.1 e TLSv1.2 sono più recenti e ottengono anche molto supporto. La maggior parte se non tutti i browser Web rilasciati dal 2014 ne hanno il supporto.
La recente scoperta degli ingegneri di Google sottolinea che SSLv3 non dovrebbe più essere utilizzato (come SSLv2 è deprecato molto tempo fa). I client che non saranno in grado di connettersi al tuo sito / servizio sono probabilmente molto limitati. CloudFlare ha annunciato che meno dello 0,09% dei visitatori fa ancora affidamento su SSLv3.
Soluzione semplice: disabilitare SSLv3.
Ubuntu fornisce aggiornamenti?
Sì, tramite usn-2385-1 con l'aggiunta della funzione SCSV, ma non mitiga completamente il problema in quanto non disabilita SSLv3 e la patch funzionerà solo se entrambi i lati della connessione sono stati patchati. Lo riceverai tramite i tuoi regolari aggiornamenti di sicurezza nel gestore dei pacchetti.
Così, ancora TU devi agire da soli per disabilitare SSLv3 (è configurabile). Le versioni future di client / browser disabiliteranno molto probabilmente SSLv3. Ad esempio, Firefox 34 lo farà.
Disabilitare SSLv3 completamente di default in Ubuntu a livello di implementazione probabilmente romperà alcune cose anche per l'uso di SSL non HTTPS che non è così vulnerabile, quindi presumo che i manutentori non lo faranno e verrà applicata solo questa patch SCSV.
Perché l'aggiornamento SCSV in OpenSSL tramite usn-2385-1 non mitiga il problema?
Davvero, smetti di porre tali domande e salta solo alcuni paragrafi e disabilita SSLv3. Ma hey, se non sei convinto, ecco qui:
POODLE mostra che SSLv3 con cifrature CBC è rotto, l'implementazione di SCSV non cambia questo. SCSV si assicura solo di non effettuare il downgrade da un protocollo TLS a un protocollo TLS / SSL inferiore se necessario con l'attacco Man-in-the-Middle richiesto nei soliti casi.
Se devi accedere ad alcuni server che non offrono affatto TLS, ma solo SSLv3, il tuo browser non ha davvero scelta e deve parlare con il server usando SSLv3, che è quindi vulnerabile senza alcun attacco di downgrade.
Se devi accedere ad un server che offre anche TLSv1 + e SSLv3 (che è sconsigliato) e vuoi essere sicuro che la tua connessione non verrà declassata a SSLv3 da un attaccante, allora sia il server che il client necessitano di questa patch SCSV.
Per mitigare completamente il problema, la disabilitazione di SSLv3 è sufficiente e puoi essere sicuro di non essere sottoposto a downgrade. E non sarai in grado di parlare con server solo SSLv3.
Ok, quindi come posso disabilitare SSLv3?
Vedi sotto nelle sezioni specifiche dell'applicazione: Firefox, Chrome, Apache, Nginx e Postfix sono coperti per ora.
Sono interessati solo i server o anche i client?
La vulnerabilità esiste se sia il server che il client accettano SSLv3 (anche se entrambi sono in grado di TLSv1 / TLSv1.1 / TLS1.2 a causa di un attacco di downgrade).
Come amministratore del server dovresti disabilitare SSLv3 ora per la sicurezza dei tuoi utenti.
Come utente, dovresti disabilitare SSLv3 nel tuo browser ora per proteggerti quando visiti siti Web che supportano ancora SSLv3.
OpenSSL / GnuTLS / browser è specifico?
No. È un bug di protocollo (design), non un bug di implementazione. Questo significa che non puoi davvero patcharlo (a meno che tu non stia cambiando il design del vecchio SSLv3).
E sì, c'è una nuova versione di sicurezza OpenSSL , ma leggi di seguito ( Ma ho davvero bisogno del supporto SSLv3 ... per la ragione X, Y, Z! ) Sul perché dovresti concentrarti meglio sulla disabilitazione di SSLv3 del tutto.
Posso uccidere SSLv3 a livello di rete (firewall)?
Beh, sì, probabilmente. L'ho messo in un post sul blog separato per ulteriori pensieri e lavori. Potremmo avere delle iptablesregole magiche che puoi usare!
Il mio post sul blog: come rimuovere SSLv3 nella tua rete usando iptables per POODLE?
È rilevante solo per HTTPS o anche per IMAP / SMTP / OpenVPN e altri protocolli con supporto SSL?
L'attuale vettore di attacco, come mostrato dai ricercatori, funziona con il controllo del testo in chiaro inviato al server usando Javascript eseguito sulla macchina della vittima. Questo vettore non si applica agli scenari non HTTPS senza l'utilizzo di un browser.
Inoltre, normalmente un client SSL non consente il downgrade della sessione a SSLv3 (avendo TLSv1 + visto nelle funzionalità di handshake), ma i browser vogliono essere molto retrocompatibili e lo fanno. La combinazione con il controllo del testo in chiaro e il modo specifico in cui viene costruita un'intestazione HTTP la rende sfruttabile.
Conclusione: disabilitare SSLv3 per HTTPS ora , disabilitare SSLv3 per altri servizi nella finestra di servizio successiva.
Qual è l'impatto? Devo revocare e rigenerare il mio certificato del server? (Come con Heartbleed)
No, non è necessario ruotare i certificati per questo. La vulnerabilità espone il recupero in chiaro dai dati della sessione, non fornisce accesso ad alcun segreto (né la chiave di sessione o chiave di certificato).
Molto probabilmente un utente malintenzionato è in grado di rubare solo le intestazioni di testo come i cookie di sessione per eseguire il dirottamento della sessione . Un ulteriore vincolo è la necessità di un attacco MitM completo (attivo) .
C'è qualcos'altro che posso fare per migliorare la mia configurazione SSL in generale?
Come utente, oltre a disabilitare SSLv3 nel tuo browser, non proprio. Bene, installa sempre sempre gli ultimi aggiornamenti di sicurezza.
Per i server, seguire la guida del server TLS di Mozilla . E prova con il test SSL Labs di Qualys . Non è poi così difficile ottenere una valutazione A + sul tuo sito. Basta aggiornare i pacchetti e implementare i consigli dalla guida di Mozilla.
Ma ho davvero bisogno del supporto SSLv3 ... per la ragione X, Y, Z! E adesso?
Bene, c'è una patch che aggira l'attacco di downgrade dei client compatibili con TLSv1, chiamato SSLv3 Fallback Protection. Migliorerà anche la sicurezza di TLSv1 +, a proposito (l'attacco di downgrade è più difficile / impossibile). È offerto come backport da una versione OpenSSL più recente nell'advisory Security Ubuntu usn-2385-1 .
Grande problema: sia i client che i server hanno bisogno di questa patch per funzionare. Quindi, a mio avviso, mentre aggiorni client e server, dovresti comunque aggiornare a TLSv1 +.
Tuttavia, per favore, per favore, ritirate SSLv3 nella vostra rete per ora. Sforzati di aggiornare gli standard di sicurezza e abbandonare SSLv3.
Ho sentito parlare del supporto SCSV per eliminare l'attacco di downgrade del protocollo. Ne ho bisogno?
Solo se hai davvero bisogno di SSLv3 per qualche strana ragione, ma migliora anche la sicurezza in TLSv1 +, quindi sì, ti consiglio di installarlo. Ubuntu fornisce un aggiornamento per questa funzione in usn-2385-1 . Lo riceverai tramite i tuoi regolari aggiornamenti di sicurezza nel gestore dei pacchetti.
Test di vulnerabilità per siti ospitati privatamente (ad es. Intranet / offline).
I tuoi server sono vulnerabili semplicemente se supportano SSLv3. Diverse opzioni qui:
Con OpenSSL s_client:
openssl s_client -connect <server>:<port> -ssl3
Se la connessione ha esito positivo, sslv3 è abilitato. Se fallisce, è disabilitato. Quando fallisce dovresti vedere qualcosa come:
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Utilizzando nmap:
nmap --script ssl-enum-ciphers -p 443 myhostname.tld
Dovrebbe essere visualizzato ' SSLv3: No supported ciphers found'. Regola il nome host / la porta.
Utilizzando cipherscan . Clona / scarica il file binario ed eseguilo:
./cipherscan myhostname.tld
Dovrebbe Non elencare nulla con SSLv3 sotto la colonna 'protocolli'.
Browser Firefox
Apri about:config, trova security.tls.version.mine imposta il valore su 1. Quindi riavviare il browser per eliminare eventuali connessioni SSL aperte.
Firefox dalla versione 34 in poi disabiliterà SSLv3 per impostazione predefinita e quindi non richiede alcuna azione ( sorgente ). Tuttavia, al momento della stesura di questo documento, 33 è appena uscito e 34 è fissato per il 25 novembre.
Google Chrome (Linux)
Modifica il /usr/share/applications/google-chrome.desktopfile, ad es
sudo nano /usr/share/applications/google-chrome.desktop
Modifica tutte le righe che iniziano con Exec=per includere --ssl-version-min=tls1.
Ad esempio una linea come
Exec=/usr/bin/google-chrome-stable %U
diventa
Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U
Quindi assicurati di chiudere completamente il browser (le app di Chrome potrebbero mantenere il browser attivo in background!).
Nota: potrebbe essere necessario ripetere questo aggiornamento di ogni pacchetto Google-Chrome, sovrascrivendo questo .desktopfile di avvio. Un browser Google Chrome o Chromium con SSLv3 disabilitato per impostazione predefinita non è ancora stato annunciato al momento della scrittura.
Server HTTPD Apache
Se si esegue un server Web Apache che attualmente consente SSLv3, sarà necessario modificare la configurazione di Apache. Sui sistemi Debian e Ubuntu il file è /etc/apache2/mods-available/ssl.conf . Su CentOS e Fedora il file è /etc/httpd/conf.d/ssl.conf . Sarà necessario aggiungere la seguente riga alla configurazione di Apache con altre direttive SSL.
SSLProtocol All -SSLv2 -SSLv3
Ciò consentirà tutti i protocolli tranne SSLv2 e SSLv3.
Mentre ci sei, potresti prendere in considerazione l'idea di migliorare la configurazione di ciphersuite per il tuo server web come spiegato nella guida del server TLS di Mozilla . Aggiungi ad esempio:
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"
Quindi controlla se la nuova configurazione è corretta (nessun errore di battitura, ecc.):
sudo apache2ctl configtest
E riavviare il server, ad es
sudo service apache2 restart
Su CentOS e Fedora:
systemctl restart httpd
Ulteriori informazioni: documentazione di Apache
Ora testalo: se il tuo sito è pubblicamente disponibile, testalo utilizzando lo strumento Labs SSL di Qualys .
Server Nginx
Se stai eseguendo Nginx, includi solo la seguente riga nella tua configurazione tra le altre direttive SSL:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Mentre ci sei, potresti prendere in considerazione l'idea di migliorare la configurazione di ciphersuite per il tuo server web come spiegato nella guida del server TLS di Mozilla . Aggiungi ad esempio:
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;
E riavviare il server, ad es
sudo service nginx restart
Riferimento: documentazione Nginx
Ora testalo: se il tuo sito è pubblicamente disponibile, testalo usando lo strumento SSL Labs di Qualys .
Web server Lighttpd
Le versioni Lighttpd> 1.4.28 supportano un'opzione di configurazione per disabilitare SSLv2 e v3. Le versioni di Lighttpd precedenti alla 1.4.28 consentono di disabilitare SOLO SSLv2. Si prega di notare che Ubuntu 12.04 LTS e precedenti si installano nella migliore versione di lighttpd v1.4.28 e quindi una soluzione semplice non è disponibile per quelle distribuzioni. Pertanto, questa correzione dovrebbe essere utilizzata solo per le versioni di Ubuntu successive alla 12.04.
Per Ubuntu versione 12.04 o Debian 6, un pacchetto lighttpd aggiornato è disponibile dal repository openSUSE:
http://download.opensuse.org/repositories/server:/http/Debian_6.0
Il pacchetto è destinato a Debian 6 (squeeze) ma funziona anche su 12.04 (preciso)
Modifica il tuo /etc/lighttpd/lighttpd.confper aggiungere le seguenti righe dopo la ssl.engine = "enable"direttiva
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
Quindi è necessario riavviare il servizio lighttpd con a sudo service lighttpd restarted eseguire un test di handshake ssl3 come descritto nelle sezioni precedenti per assicurarsi che la modifica sia stata implementata correttamente.
Tratto da http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL .
Postfix SMTP
Per "SSL opportunistico" (la politica di crittografia non applicata e semplice è accettabile anche), non è necessario modificare nulla. Anche SSLv2 è meglio del semplice, quindi se hai bisogno di proteggere il tuo server dovresti comunque usare la modalità 'SSL obbligatorio'.
Per la modalità "SSL obbligatorio" già configurata, basta aggiungere / modificare l' impostazione smtpd_tls_mandatory_protocols per le connessioni in entrata e smtp_tls_mandatory_protocols per le connessioni in uscita:
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3
Facoltativamente, se si desidera disabilitare SSLv3 anche per la crittografia opportunistica (anche se non è necessario come spiegato sopra), farlo in questo modo:
smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3
e riavvia Postfix:
sudo service postfix restart
Inviare una mail
(Modifica non verificata da utente anonimo, non mi sento a mio agio con Sendmail, per favore verifica.)
Queste opzioni sono configurate nella LOCAL_CONFIGsezione del tuosendmail.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
In Dovecot v2.1 +, aggiungi quanto segue al tuo /etc/dovecot/local.conf(o un nuovo file in /etc/dovecot/conf.d):
ssl_protocols = !SSLv2 !SSLv3
e riavvia Dovecot:
sudo service dovecot restart
Per le versioni precedenti dovrai correggere il codice sorgente .
Courier-imap (imapd-ssl)
Courier-imap consente SSLv3 per impostazione predefinita su Ubuntu 12.04 e altri. È necessario disabilitarlo e utilizzare STARTTLS invece di forzare TLS. Modifica il tuo /etc/courier/imapd-sslfile di configurazione per riflettere le seguenti modifiche
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!>"
Server HAProxy
SSL è supportato in HAProxy> = 1.5.
Modifica il /etc/haproxy.cfgfile e trova la tua bindlinea. Append no-sslv3. Per esempio:
bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3
Riferimento: documentazione HAProxy
OpenVPN
Sembra essere inalterato ( fonte ).
OpenVPN utilizza TLSv1.0 o (con> = 2.3.3) facoltativamente TLSv1.2 e quindi non è influenzato da POODLE.
Fantoccio
Puppet utilizza SSL su HTTPS ma non viene utilizzato dai client "browser", ma solo dagli agenti Puppet che non sono vulnerabili al vettore di attacco mostrato. Tuttavia, è consigliabile disabilitare solo SSLv3.
La mia raccomandazione è di usare il modulo marionetta stephenrjohnson / puppetmodule per configurare il tuo burattinaio in cui ho ucciso SSLv3 qualche tempo fa.