Domanda Come posso applicare una patch / soluzione a una vulnerabilità SSLv3 POODLE (CVE-2014-3566)?


Dopo il Attacco BEAST e Insetto di cuore, ora ho sentito parlare di una nuova vulnerabilità in SSL / TLS chiamata BARBONCINO. Come posso proteggermi dall'essere sfruttati?

  • Sono interessati solo i server o anche i client?
  • Questo è OpenSSL / GnuTLS specifico?
  • Che tipo di servizi sono interessati? Solo HTTPS o anche IMAPS, SMTPS, OpenVPN, ecc.?

Per favore, mostrami degli esempi su come evitare questa vulnerabilità.


158
2017-10-14 23:49


origine


Ulteriori informazioni possono essere trovate qui Vulnerabilità "Poodle" SSL3 - Braiam
@Breiam Sì, lo so, il brillante Thomas di nuovo! Tuttavia, si tratta di un Q & A molto orientato alla crittografia. Questo Q & A su AU dovrebbe fornire informazioni pratiche e orientate a Ubuntu. :-) - gertvdijk
Eh? Come ti aspetti una soluzione più pratica di "Se non installi i cerotti allora Níðhöggr divorerà la tua milza". - Braiam
@ Braam Prima di tutto: non c'è nessuna patch (leggi la mia risposta). Penso che Thomas si riferisca agli apparecchi piuttosto che al server web DIY-Ubuntu. Appliance come bilanciamento del carico di solito offrono aggiornamenti del firmware per la modifica delle impostazioni predefinite o offriranno funzionalità per essere in grado di configurarlo. Tuttavia, in Ubuntu è tutto a carico dell'utente / amministratore. - gertvdijk
In realtà c'è: i fornitori possono disabilitare / rimuovere tutto il codice relativo a SSLv3, quindi non è necessario toccare nulla. - Braiam


risposte:


Informazioni di base

SSL è progettato per garantire il livello di trasporto su Internet. Per "il web", noto anche come HTTP, questo verrà riconosciuto come HTTPS, ma verrà utilizzato anche per altri protocolli di applicazione. SSLv2 è stato il primo protocollo di sicurezza per il trasporto ampiamente utilizzato, ma è stato trovato insicuro non molto tempo dopo. Successori SSLv3 e TLSv1 sono ampiamente supportati ora. TLSv1.1 e TLSv1.2 sono più recenti e stanno ottenendo molto supporto. La maggior parte se non tutti i browser Web rilasciati dal 2014 hanno il supporto per questo.

La recente scoperta da parte dei tecnici di Google sottolinea che SSLv3 non dovrebbe essere più 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 annunciato meno dello 0.09% dei visitatori si affida ancora a SSLv3.

Soluzione semplice: disabilita SSLv3.

Ubuntu fornisce aggiornamenti?

Sì, via USN-2385-1 con l'aggiunta della funzione SCSV, ma non attenua completamente il problema in quanto non disabilita SSLv3 e la patch funzionerà solo se sono stati riparati entrambi i lati della connessione. Lo riceverai tramite i tuoi regolari aggiornamenti di sicurezza nel tuo gestore di pacchetti.

Quindi, ancora TU devi agire da solo per disabilitare SSLv3 (è configurabile). Le versioni future di client / browser disabiliteranno molto probabilmente SSLv3. Per esempio. Firefox 34 lo farà.

Disabilitare completamente SSLv3 per impostazione predefinita in Ubuntu a livello di implementazione probabilmente romperà alcune cose anche per usi SSL non HTTPS che non sono così vulnerabili, 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 attenua il problema?

Davvero, smetti di fare domande del genere e salta alcuni paragrafi e disabilita SSLv3. Ma hey, se non sei convinto, ecco qua:

POODLE mostra che SSLv3 con cifrari CBC è rotto, l'implementazione di SCSV non lo modifica. SCSV si limita a non eseguire il downgrade da qualche protocollo TLS a nessun protocollo TLS / SSL inferiore, se necessario, con l'attacco Man-in-the-Middle richiesto per i casi normali.

Se devi accedere ad alcuni server che non offrono affatto TLS, ma solo SSLv3, allora il tuo browser non ha realmente scelta e deve parlare al server usando SSLv3, che è quindi vulnerabile senza alcun attacco di downgrade.

Se devi accedere ad alcuni server che offrono TLSv1 + e SSLv3 (che è scoraggiato) e vuoi essere sicuro che la tua connessione non verrà declassata a SSLv3 da un utente malintenzionato, quindi entrambi il server e il client hanno bisogno di questa patch SCSV.

Per mitigare completamente il problema, la disabilitazione di SSLv3 è sufficiente e si può essere certi che non verrà eseguito il downgrade. E non sarai in grado di parlare con i server SSLv3-only.

Ok, allora come disabilito 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 adesso per la sicurezza dei tuoi utenti.

Come utente, devi disabilitare SSLv3 nel tuo browser adesso per proteggere te stesso quando visiti siti Web che supportano ancora SSLv3.

Questo OpenSSL / GnuTLS / browser è specifico?

No. È un bug di protocollo (design), non un bug di implementazione. Ciò significa che non puoi realmente applicarlo (a meno che tu non stia cambiando il design del vecchio SSLv3).

E sì, c'è un nuovo Rilascio di sicurezza OpenSSL, ma leggi sotto (Ma ho davvero bisogno del supporto SSLv3 ... per la ragione X, Y, Z!) sul perché è meglio concentrarsi sulla disabilitazione di SSLv3 del tutto.

Posso uccidere SSLv3 a livello di rete (firewall)?

Bene, sì, probabilmente. Lo metto in un post sul blog separato per ulteriori riflessioni e lavoro. Potremmo avere un po 'di magia iptables regola che puoi usare!

Il mio post sul blog: Come eliminare SSLv3 nella 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 utilizzando Javascript in esecuzione sulla macchina della vittima. Questo vettore non si applica agli scenari non HTTPS senza utilizzare 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 compatibili con le versioni precedenti e lo fanno. La combinazione con il testo in chiaro di controllo e il modo specifico con cui viene costruita un'intestazione HTTP lo rende sfruttabile.

Conclusione: disabilitare SSLv3 per HTTPS adesso, 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 del testo normale dai dati della sessione, non fornisce l'accesso ad alcun segreto (né la chiave di sessione né la chiave del certificato).

È molto probabile che un utente malintenzionato sia solo in grado di rubare le intestazioni di testo in chiaro come i cookie di sessione per poter essere eseguito sessione di dirottamento. Un ulteriore vincolo è la necessità di un pieno (attivo) Attacco MitM.

C'è 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 gli ultimi aggiornamenti di sicurezza.

Per i server, segui Guida del server TLS di Mozilla. E prova con Test dei laboratori SSL di Qualys. Non è davvero così difficile ottenere una valutazione A + sul tuo sito. Aggiorna i pacchetti e implementa i consigli dalla guida di Mozilla.

Ma ho davvero bisogno del supporto SSLv3 ... per la ragione X, Y, Z! Ora cosa?

Bene, c'è una patch che aggira l'attacco di downgrade dei client abilitati a TLSv1, chiamato la protezione di sicurezza SSLv3. A proposito, migliorerà anche la sicurezza di TLSv1 + (l'attacco downgrade è più difficile / impossibile). È offerto come backport da una versione OpenSSL più recente nel advisory sulla sicurezza di Ubuntu USN-2385-1.

Big catch: sia i client che i server hanno bisogno di questa patch per funzionare. Quindi, a mio parere mentre aggiorni sia i client che i server, dovresti comunque effettuare l'aggiornamento a TLSv1 +.

Tuttavia, per favore, per ora basta ritirare SSLv3 nella tua rete. Sforzati di aggiornare gli standard di sicurezza e metti da parte 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 funzionalità in USN-2385-1. Lo riceverai tramite i tuoi regolari aggiornamenti di sicurezza nel tuo gestore di pacchetti.

Test della vulnerabilità per i 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 del tipo:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
    
  • utilizzando nmap:

    nmap --script ssl-enum-ciphers -p 443 myhostname.tld
    

    Dovrebbe produrre 'SSLv3: No supported ciphers found'. Regola per il tuo nome host / porta.

  • utilizzando cipherscan. Clona / scarica il file binario ed eseguilo:

    ./cipherscan myhostname.tld
    

    Dovrebbe non elenca qualsiasi cosa con SSLv3 nella colonna 'protocolli'.


Browser Firefox

Aperto about:config, trova security.tls.version.min e impostare il valore su 1. Quindi riavvia il browser per eliminare tutte le connessioni SSL aperte.

Firefox dalla versione 34 in poi disabiliterà SSLv3 di default e quindi non richiede alcuna azione (fonte). Tuttavia, al momento della scrittura, 33 è appena uscito e il 34 è fissato per il 25 novembre.


Google Chrome (Linux)

Modifica il /usr/share/applications/google-chrome.desktop file, ad es.

sudo nano /usr/share/applications/google-chrome.desktop

modificare tutte le linee Iniziare con Exec= includere --ssl-version-min=tls1.

Per 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 attivo il tuo browser in background!).

Nota: potrebbe essere necessario ripetere questo ogni aggiornamento del pacchetto google-chrome, sovrascrivendolo .desktop file di avvio. Un browser Google Chrome o Chromium con SSLv3 disabilitato per impostazione predefinita non è ancora stato annunciato al momento della scrittura.


Apache HTTPD Server

Se si sta eseguendo un server Web Apache che attualmente supporta SSLv3, sarà necessario modificare la configurazione di Apache. Il file è su Debian e Ubuntu /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 il miglioramento della configurazione di ciphersuite per il tuo webserver come spiegato in precedenza Guida del server TLS di Mozilla. Aggiungi per 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, ecc.):

sudo apache2ctl configtest

E riavvia il server, ad es.

sudo service apache2 restart

Su CentOS e Fedora:

systemctl restart httpd

Ulteriori informazioni: Documentazione di Apache

Ora provalo: se il tuo sito è pubblicamente disponibile, testalo usando Strumento SSL di Qualys Labs.


Server Nginx

Se stai utilizzando Nginx, includi semplicemente 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 il miglioramento della configurazione di ciphersuite per il tuo webserver come spiegato in precedenza Guida del server TLS di Mozilla. Aggiungi per 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 riavvia il server, ad es.

sudo service nginx restart

Riferimento: Documentazione di Nginx

Ora provalo: se il tuo sito è pubblico, disponibile, testalo usando Strumento SSL di Qualys Labs.


Lighttpd webserver

Le versioni Lighttpd> 1.4.28 supportano un'opzione di configurazione per disabilitare SSLv2 e v3. Le versioni Lighttpd precedenti alla 1.4.28 consentono di disabilitare SOLO SSLv2. Si prega di notare che Ubuntu 12.04 LTS e precedenti installare al meglio lighttpd v1.4.28 e quindi una semplice correzione non è disponibile per quelle distribuzioni.  Pertanto questa soluzione dovrebbe essere utilizzata solo per le versioni di Ubuntu maggiori di 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.conf aggiungere le seguenti righe dopo il ssl.engine = "enable" direttiva

ssl.use-sslv2          = "disable"
ssl.use-sslv3          = "disable"

Quindi dovresti riavviare il servizio lighttpd con a sudo service lighttpd restart ed eseguire un test di handshake ssl3 come descritto nelle sezioni precedenti per assicurarsi che la modifica sia stata implementata con successo.

Preso 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 che semplice, quindi se hai bisogno di proteggere il tuo server dovresti comunque utilizzare la modalità 'obbligatorio SSL'.

Per la modalità 'SSL obbligatorio' già configurata, basta aggiungere / modificare il smtpd_tls_mandatory_protocols impostazione 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 nel LOCAL_CONFIG sezione del tuo sendmail.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 riavviare Dovecot:

sudo service dovecot restart

Per le versioni precedenti dovrai farlo correggi il codice sorgente.


Courier-imap (imapd-ssl)

Courier-imap consente SSLv3 di default su Ubuntu 12.04 e altri. Devi disabilitarlo e utilizzare invece STARTTLS per forzare TLS. Modifica il tuo /etc/courier/imapd-ssl file 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!>"

HAProxy Server

SSL è supportato in HAProxy> = 1.5.

Modifica il /etc/haproxy.cfg file e trova il tuo bind linea. Aggiungere 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 pertanto non viene influenzato da POODLE.


Fantoccio

Puppet utilizza SSL su HTTPS ma non viene utilizzato dai client "browser", solo gli agenti di Puppet che non sono vulnerabili al vettore di attacco mostrato. Tuttavia, è consigliabile disabilitare semplicemente SSLv3.

La mia raccomandazione è di usare il stephenrjohnson / puppetmodule Modulo Puppet per configurare il tuo master Puppet in cui Ho ucciso SSLv3 qualche tempo fa.


210
2017-10-14 23:49



Questa risposta è stata creata molto rapidamente dopo il rilascio pubblico della vulnerabilità. Ci possono essere degli errori ancora lì - come sempre, sentiti libero di modificare / migliorare. - gertvdijk
Nginx config non dovrebbe avere i due punti dopo la direttiva ssl_protocols - Michelle
Bene, per Firefox credo Questo è quello che sta succedendo. - fuglede
Questo post del blog sulla sicurezza di Mozilla suggerisce l'installazione questo componente aggiuntivo invece di modificare manualmente le preferenze. - legoscia
@muru Ecco un inizio sull'uccisione di SSLv3 a livello di firewall. blog.g3rt.nl/take-down-sslv3-using-iptables.html - gertvdijk


Potrebbe non essere specifico di Ubuntu ma per aggirare la vulnerabilità di Poodle in Node.js è possibile impostare il file secureOptions a require('constants').SSL_OP_NO_SSLv3 quando crei un server https o tls.

Vedere https://gist.github.com/3rd-Eden/715522f6950044da45d8 per ulteriori informazioni


4
2017-10-15 08:59



IMO non dovresti esporre HTTP (S) con Node / Python / Ruby o qualcosa del genere direttamente. Metti un HTTPd decente di fronte ad esso come Apache / Nginx / ... - gertvdijk
Sì, non dovresti esporre direttamente. Le lingue non sono così buone con il protocollo TCP di Tcp, ma hanno problemi con le prese. Lascia che nginx lo legga da un socket. :-) - jrg♦
Questo non meritava un voto negativo. Ci sono molti casi in cui viene utilizzato tls oltre a ospitare un server http. - psanford
@gertvdijk & jrg Node.js non è una lingua. È un framework per la creazione di applicazioni di rete scalabili. E come affermi che dovresti mettere Node.js dietro un server Apache (e anche chiamarlo "decente") già chiarisce che non hai assolutamente idea di cosa stai parlando. Affermare che non sono buoni con tpc / http è ovviamente un pregiudizio personale. Per favore, rimani sull'argomento senza tener conto di una tecnologia di voto infantile che non capisci. - 3rdEden
@ 3rdEden Bene, forse la mia osservazione è stata un po 'generalizzante, ma qui ci sono alcune note che vorrei fare. 1) Non ho fatto downvote, 2) il mio commento è stato un 'IMO' gentile, 3) Forse è solo il mio background in sicurezza, ma ho imparato che non si deve esporre un framework applicativo direttamente a 80/443 al mondo in produzione. (salvo a scopo dimostrativo). 4) Non vedo come il tuo post sia una 'risposta' alla domanda per il visitatore generale Ask Ubuntu; è solo molto molto specifico per un determinato caso specifico delle distribuzioni di Node.js. - gertvdijk


La "correzione" per corriere disabilita tls 1.1 e tls 1.2. Non sembra essere un modo per eseguire il corriere con tls 1.1 o superiore. Una scansione PCI sul tuo server potrebbe tornare con la raccomandazione:

Configurare i server SSL / TLS per utilizzare TLS 1.1 o TLS 1.2 solo se supportati. Configurare i server SSL / TLS per supportare solo pacchetti di crittografia che non utilizzano crittografi a blocchi.


0
2018-02-27 14:45





Poiché la vulnerabilità di POODLE è un difetto di progettazione nel protocollo stesso e non un bug di implementazione, non ci saranno patch. L'unico modo per mitigare questo è disabilitare SSLv3 nel server Apache. Aggiungi le linee sottostanti in ssl.conf ed esegui il riavvio di Apache.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

-1
2017-10-15 22:55



-1 per includere RC4 e ECDSA non funzionale poiché la maggior parte delle persone ha certificati RSA. Si prega di leggere su come configurare correttamente il server. wiki.mozilla.org/Security/Server_Side_TLS - gertvdijk
@gertvdijk Sono d'accordo con te su RC4, ma non fa male includere le suite ECDSA. È innocuo se hai solo un certificato RSA e ti risparmia la fatica di aggiustare la tua configurazione se successivamente ottieni un certificato ECDSA. - Matt Nordhoff
@MattNordhoff Giusto abbastanza, ma quello che voglio dire è che non ci sono molti cifrari per una normale configurazione basata su certificati RSA. Funzionerà nella maggior parte dei browser, ma uno potrebbe affrontare problemi di compatibilità. - gertvdijk
Sicuramente sbarazzarsi di RC4 da questa lista, non è sicuro. Resta con i restanti se puoi. 3DES è debole, ma l'ho acceso in un punto particolare per compatibilità. Odio farlo perché è debole, ma almeno non è in realtà rotto ... - Brian Knoblauch