Le crittografie protette interrompono i certificati multi-dominio?

Naviga le tue risposte
1

Nei giorni scorsi, ho avuto il successo a metà strada con la sicurezza dei miei siti web. Finora, ho raggiunto il seguente:

  1. Ottieni un certificato da letsencrypt.org, proteggendo i domini example1.com, example2.com ed example3.com (la dimensione della chiave RSA è 4096 bit, example1.com è il CN del certificato, example2.com e example3.com sono subjectAltNames)

  2. Configura Apache per utilizzare solo TLSv1.2

  3. Configura Apache per usare solo cifrari che considero sicuri (cioè senza RC4, senza SHA1, senza cifrari con CBC e così via) e che forniscono PFS (cioè solo cifrari che offrono scambio di chiavi DHE o ECDHE)

  4. Configura gli host virtuali in Apache in modo che sia presente un host HTTP e un host HTTPS per example1.com, ma ancora solo host HTTP per esempio2. com e example3.com

Si noti che tutti e tre i domini / host virtuali sono in esecuzione sullo stesso indirizzo IP e che io uso il modulo Apache SSL (mod_ssl).

Questa configurazione funziona nel senso che posso visualizzare link , link , link e link esattamente come previsto all'interno dell'attuale (più recente) versioni di IE 11, FF e Chrome (attualmente non sono interessato a far funzionare le cose con altri browser).

I seguenti sono i frammenti rilevanti dalla mia configurazione di Apache.

File di configurazione per example1.com: 

<Directory /home/www/example1>
  Require all granted
  AllowOverride none
  Options IncludesNOEXEC
  DirectoryIndex index.shtml
</Directory>    

<VirtualHost example1.com:80>

  ServerAdmin ...
  DocumentRoot /home/www/example1
  ServerName example1.com
  ServerAlias *.example1.com
  CustomLog ...
  ErrorLog ...

</VirtualHost>

<VirtualHost example1.com:443>

  ServerAdmin ...
  DocumentRoot /home/www/example1
  ServerName example1.com
  ServerAlias *.example1.com
  CustomLog ...
  ErrorLog ...

  SSLEngine on
  SSLCompression off
  SSLHonorCipherOrder on
  SSLInsecureRenegotiation off
  SSLOptions +StrictRequire

  SSLCertificateFile /etc/letsencrypt/live/example1.com/cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/example1.com/privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/live/example1.com/chain.pem

  SSLProtocol TLSv1.2
  SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256

</VirtualHost>

File di configurazione per esempio2.com (come sopra, ma senza la sezione host virtuale SSL): 

<Directory /home/www/example2>
  Require all granted
  AllowOverride none
  Options IncludesNOEXEC
  DirectoryIndex index.shtml
</Directory>    

<VirtualHost example2.com:80>

  ServerAdmin ...
  DocumentRoot /home/www/example2
  ServerName example2.com
  ServerAlias *.example2.com
  CustomLog ...
  ErrorLog ...

</VirtualHost>

Il file di configurazione per esempio3.com è simile a quello di example2.com con tutte le occorrenze di "esempio2" sostituite da "esempio3".

Il problema:

Non appena aggiungo la sezione host virtuale SSL per example2.com o / e example3.com, né FF né Chrome si connetteranno a qualsiasi dei siti HTTPS, cioè questo si rompe link che in precedenza funzionava. In altre parole, se cambio il file di configurazione example2.com in 

<Directory /home/www/example2>
  Require all granted
  AllowOverride none
  Options IncludesNOEXEC
  DirectoryIndex index.shtml
</Directory>    

<VirtualHost example2.com:80>

  ServerAdmin ...
  DocumentRoot /home/www/example2
  ServerName example2.com
  ServerAlias *.example2.com
  CustomLog ...
  ErrorLog ...

</VirtualHost>

<VirtualHost example2.com:443>

  ServerAdmin ...
  DocumentRoot /home/www/example2
  ServerName example2.com
  ServerAlias *.example2.com
  CustomLog ...
  ErrorLog ...

  SSLEngine on
  SSLCompression off
  SSLHonorCipherOrder on
  SSLInsecureRenegotiation off
  SSLOptions +StrictRequire

  SSLCertificateFile /etc/letsencrypt/live/example1.com/cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/example1.com/privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/live/example1.com/chain.pem

  SSLProtocol TLSv1.2
  SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256

</VirtualHost>

e fai la stessa cosa per example3.com, questo interrompe tutti i siti HTTPS. A volte, IE, FF e Chrome saranno in grado di connettersi a uno di questi siti HTTPS, ma non è possibile prevedere quale e in quali circostanze (forse una cosa cache - non ne sono completamente sicuro).

Ho annusato il traffico rispettivo con Wireshark, ma sfortunatamente questo non ha portato a nulla: Apache interrompe l'handshake della connessione SSL con il codice di errore 40 / "handshake failure".

La cosa strana è che tutte le connessioni HTTPS (cioè link , link e link ) funzionano in modo affidabile con tutti e tre i browser se rimuovo la direttiva SSLCipherSuite da ogni file di configurazione.

Sono consapevole che SNI avrebbe bisogno di TLSv1, ma la mia sensazione è che questo non sia un problema SNI. Secondo molti articoli, io non ho bisogno di SNI anche quando eseguo più host SSL virtuali sullo stesso indirizzo IP se tutti i nomi di dominio (nomi di host virtuali) sono nello stesso certificato e questa è esattamente la mia situazione Mi piacerebbe sottolineare ancora una volta che usando la direttiva 

SSLCertificateFile /etc/letsencrypt/live/example1.com/cert.pem

in tutti e tre i file di configurazione non è un refuso poiché quel certificato contiene i tre nomi di dominio in esso contenuti.

Quindi, potrebbe piacere a qualcuno spiegare cosa sta succedendo lì e forse dare qualche suggerimento su come raggiungere il mio obiettivo (server cipher suite e restrizione del protocollo TLS come mostrato sopra, tutti i nomi di dominio in un certificato, tutti gli host virtuali (domini) allo stesso indirizzo IP)? Ho già fatto test con Apache 2.2 e 2.4, ma senza risultati.

    
posta Binarus 17.12.2015 - 20:13
fonte

2 risposte

2

Si prevede di impostare questo: 

SSLCompression off
SSLHonorCipherOrder on
SSLInsecureRenegotiation off
SSLOptions +StrictRequire

e cose del genere a livello globale in /etc/apache2/mods-enabled/ssl.conf o un file corrispondente nel tuo sistema. So che ad Apache non piace che venga impostato più volte in ogni vhost.

E a proposito, dovresti rimuovere DHE-DSS cipher, altrimenti saranno disabilitati automaticamente. Fanno affidamento su DSA: non si desidera avere un certificato DSA per supportarli.

    
risposta data 17.12.2015 - 20:28
fonte
0

Bene, sembra che io sia uno dei più grandi idioti del pianeta. È successo quanto segue:

Ho modificato i miei file di configurazione di Apache usando l'editor "nano" in Linux. Ho configurato la configurazione per il primo host virtuale (example1.com) digitando molte cose a mano o aggiungendo piccoli frammenti tramite copia e incolla pezzo per pezzo.

Durante la creazione dei file di configurazione per gli altri host virtuali, ho copiato grandi porzioni dal primo file di configurazione agli altri. L'ho fatto usando un mouse in una finestra di terminale.

Poiché non avevo fatto nano per avvolgere le linee, mostrava solo la prima parte di ogni riga (fino al bordo destro della rispettiva finestra). Copiando le righe "straripanti", solo la prima parte era stata copiata perché la copia e incolla via mouse è fornita dal terminale e non fornita da nano.

C'era solo una riga nei file in cui ciò contava. Potresti indovinare quale? Naturalmente, il più lungo, cioè la suite di crittografia.

Ciò significa che nei file di configurazione per ogni host virtuale tranne il primo, la stringa della suite di crittografia era stata tagliata da qualche parte nel mezzo perché solo la prima parte era stata copiata dalla finestra dell'editor. Non l'ho riconosciuto perché la finestra dell'editor nano aveva la stessa dimensione ogni volta, e quindi la linea della suite di crittografia sembrava sempre la stessa (la parte mancante era fuori dalla finestra).

Stranamente, Apache non si lamentava della stringa della suite di cifrari criptata (che in questo caso finiva con un trattino) all'avvio. Da quando ho attivato LogLevel Debug e regolarmente ho studiato tutti i file di log di Apache, mi sarei davvero aspettato di vedere un messaggio sulla stringa della suite di crittografia malformata. Ma non c'era assolutamente nulla.

In altre parole, ora ho raggiunto il mio obiettivo e la configurazione che ho descritto sopra funziona come un incantesimo. Mi scuso per la confusione.

Che cosa possiamo imparare da questo?

1) Un vhost di Apache potrebbe non funzionare come previsto anche quando la sua configurazione è senza errori, ma quando ci sono errori nelle altre configurazioni di vhost.

2) Attiva SEMPRE il ritorno a capo in qualsiasi editor: una cosa che faccio sempre quando lavoro con programmi Windows; infatti, nano / Linux è l'unico editor in cui mi dimentico regolarmente di farlo (anche se sto usando anche altri editor di Linux).

    
risposta data 18.12.2015 - 20:03
fonte

Leggi altre domande sui tag

registrazione di suite di crittografia lato client disponibili da Apache tomcat? Perché Facebook e così via sono considerati server di autorizzazione tipici in OpenId?