È possibile impostare un protocollo SSL in Apache per un singolo VirtualHost (barboncino)?


13

Sto cercando di testare una patch per la vulnerabilità del barboncino che comporta la disabilitazione di SSLv3 sul mio server web. Per testarlo prima in un ambiente non di produzione, sto impostando SSLProtocol su un VirtualHost per un altro server di prova. La mia configurazione è simile a questa:

<VirtualHost *:443>
    SSLEngine On
    SSLProtocol All -SSLv2 -SSLv3
    ServerName test.mysite.com
    # bunch of other stuff omitted
</VirtualHost>

Tuttavia, anche dopo aver riavviato Apache, il mio sito di test è ancora considerato vulnerabile. Questo dovrebbe funzionare? Mi chiedo se devo impostarlo nella configurazione ssl globale o se c'è qualcos'altro di sottile che sta causando che l'impostazione non funzioni e / o funzioni.

Risposte:


16

È possibile impostare SSLProtocol solo per il primo VirtualHost nel file di configurazione. Tutte le successive voci di VirtualHost erediteranno tale impostazione dalla prima voce e ignoreranno silenziosamente la propria impostazione a causa di un bug OpenSSL .

Esiste una segnalazione di bug corrispondente per mod_ssl , ma come descritto nella segnalazione di bug, il problema deve essere risolto in OpenSSL (il certificato è ereditato ma non i protocolli).

Le suite di cifratura devono essere impostate in modo indipendente per ciascun VirtualHost, altrimenti finirai con l'elenco predefinito, incluso un sacco di cifre non sicure. Inoltre, tenere presente che i client meno recenti che non supportano l'indicazione del nome server (SNI) utilizzeranno sempre l'host predefinito (a meno che non venga bloccatoSSLStrictSNIVHostCheck ), il che può confondere i test.

In breve, dovresti essere in grado di specificare suite di cifratura personalizzate e certificati per ciascun host virtuale, ma fino a quando il bug non viene corretto non aspettarti un comportamento corretto con i protocolli personalizzati per ciascun host virtuale.

Ho riscontrato questo problema con Apache 2.4 e modssl con OpenSSL 1.0.1k e mi aspetto che Apache 2.2 sia soggetto agli stessi problemi.

Aggiornamento (ottobre 2016): il bug OpenSSL è stato contrassegnato come risolto il 13 ottobre 2016. Tuttavia, faceva parte di una chiusura di massa di problemi aperti e sebbene fosse stata fornita una "correzione parziale", il problema non era mai stato completamente risolto.

Aggiornamento (aprile 2018): il bug OpenSSL reinviato ora ha una patch disponibile (dal 9 aprile 2018). Questa patch cambierà il comportamento delle istanze di Apache configurate con più host virtuali SNI:

Rifiuta connessioni non conformi al protocollo SSL vhost

Questo è stato sviluppato e testato con 2.4.27 e in produzione con quella versione. La patch è stata modificata per 2.4.33 e leggermente testata.

In questo modo viene verificata la versione della connessione rispetto al protocollo SSL configurato per l'host virtuale che corrisponde alla SNI. Poiché la connessione viene inizialmente stabilita con il protocollo SSL configurato per l'host predefinito per la porta, l'host predefinito deve includere tutti i protocolli che saranno supportati da qualsiasi host virtuale.

Questa patch aggiunge un ulteriore stato di ritorno di APR_EMISMATCH alla funzione init_vhost in modo che il callback ssl_callback_ServerNameIndication registrato con OpenSSL possa restituire un avviso irreversibile SSL_AD_PROTOCOL_VERSION. Questo ha lo scopo di produrre la stessa risposta a ClientHello della specifica di un protocollo SSL che non include la versione in questione. Poiché il callback SNI viene chiamato durante l'elaborazione di ClientHello e prima che venga prodotta una risposta, sembra fare esattamente questo.

Se vedi improvvisamente messaggi del seguente formato:

Rejecting version [version] for servername [hostname]

Quindi dovresti ricontrollare il SSLProtocoltuo host predefinito.


Le informazioni aggiuntive aggiunte da @anx in merito SSLStrictSNIVHostChecksono molto apprezzate. Tuttavia, si dovrebbe anche notare dalla documentazione citata che Se impostato su attivo in qualsiasi altro host virtuale, i client ignari SNI non sono autorizzati ad accedere a questo particolare host virtuale .
vallismortis,

5

È possibile disporre di protocolli SSL diversi per ciascun Vhost se sono in ascolto su un IP diverso.

Esempio con un host specifico che consente a TLSv1 e tutti gli altri che consentono solo TLSv1.1 e TLSv1.2 e uno che consente solo TLSv1.2:

<VirtualHost *:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3 -TLSv1
  ServerName test.mysite.com
  # bunch of other stuff omitted
</VirtualHost>

<VirtualHost 10.0.0.2:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3
  ServerName test2.mysite.com
</VirtualHost>

<VirtualHost 10.0.0.3:443>
  SSLEngine On
  SSLProtocol TLSv1.2
  ServerName test2.mysite.com
</VirtualHost>

Inoltre, se è necessario solo a scopo di test, è possibile utilizzare un'altra porta anziché un altro IP, ad esempio una porta HTTPS alternativa comune 8443.
Esa Jokinen,

0

Se si utilizza Server Name Indication (SNI) con il proprio vhost, infatti, non è possibile definire più versioni SSL.

Tuttavia, se si utilizza un server dedicato, è probabilmente possibile aggiungere un altro indirizzo IP al server. In questo modo, sarai in grado di utilizzare una versione SSL diversa per IP. Devi solo modificare le impostazioni del tuo vhost come previsto IP: 443.


-2

Oppure puoi usare:

SSLProtocol TLSv1 TLSv1.1 TLSv1.2

Sono stato testato su molti server e funziona per me! Puoi testare il tuo sito in questo sito Web


4
Questa linea SSLProtocol sembra funzionare solo perché Apache non se ne lamenta. In realtà, viene utilizzato solo il protocollo SSL nella prima voce di VirtualHost.
vallismortis il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.