¿Los cifrados seguros rompen los certificados de varios dominios?

1

En los últimos días, tuve medio éxito con la protección de mis sitios web. Hasta ahora, he logrado lo siguiente:

  1. Obtenga un certificado de letsencrypt.org, asegurando los dominios example1.com, example2.com y example3.com (el tamaño de la clave RSA es 4096 bits, example1.com es el CN del certificado, example2.com y example3.com son subjectAltNames)

  2. Configure Apache para utilizar solo TLSv1.2

  3. Configure Apache para usar solo cifrados que estoy considerando seguro (es decir, sin RC4, sin SHA1, sin cifrados con CBC y así sucesivamente) y que proporcionan PFS (es decir, solo cifrados que ofrecen intercambio de claves DHE o ECDHE)

  4. Configure los hosts virtuales en Apache para que haya un host HTTP y un host HTTPS para example1.com, pero todavía solo hosts HTTP para example2. com y example3.com

Tenga en cuenta que los tres dominios / hosts virtuales se ejecutan en la misma dirección IP y que uso el módulo Apache SSL (mod_ssl).

Esta configuración funciona en el sentido de que puedo ver enlace , enlace , enlace y enlace exactamente como se pretende desde el actual (las versiones más recientes) de IE 11, FF y Chrome (actualmente no estoy interesado en hacer que las cosas funcionen con otros navegadores).

Los siguientes son los fragmentos relevantes de mi configuración de Apache.

Archivo de configuración para 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>

Archivo de configuración para example2.com (como el anterior, pero sin la sección de host virtual 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>

El archivo de configuración para example3.com es similar al de example2.com con todas las apariciones de "example2" reemplazadas por "example3".

El problema:

Tan pronto como agregue la sección de host virtual SSL para example2.com y / y example3.com, ni FF ni Chrome se conectarán a cualquiera de los sitios HTTPS, es decir, esto rompe enlace que anteriormente ha estado funcionando. En otras palabras, si cambio el archivo de configuración example2.com a

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

y haga lo mismo con example3.com, esto rompe todos los sitios HTTPS. A veces, IE, FF y Chrome podrán conectarse a uno de estos sitios HTTPS, pero no se puede predecir a cuál y bajo qué circunstancias (quizás sea una cuestión de caché, no estoy completamente seguro).

He olfateado el tráfico respectivo con Wireshark, pero desafortunadamente, eso no condujo a nada: Apache simplemente aborta el protocolo de enlace de la conexión SSL con el código de error 40 / "falla del protocolo de enlace".

Lo extraño es que todas las conexiones HTTPS (es decir, enlace , enlace y enlace ) funcionan de manera confiable con los tres navegadores si elimino la directiva SSLCipherSuite de cada archivo de configuración.

Soy consciente de que SNI necesitaría TLSv1, pero creo que esto no es un problema de SNI. De acuerdo con varios artículos, no necesito SNI incluso cuando ejecuto varios hosts SSL virtuales en la misma dirección IP si todos los nombres de dominio (nombres de host virtual) están en el mismo certificado , y esa es exactamente mi situación. Me gustaría subrayar una vez más que utilizando la directiva

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

en los tres archivos de configuración no es un error tipográfico, ya que ese certificado contiene los tres nombres de dominio.

Por lo tanto, podría complacer a alguien lo que está sucediendo allí y quizás dar algunas sugerencias sobre cómo lograr mi objetivo (conjunto de cifrado del lado del servidor y protocolo de restricción TLS como se muestra arriba, todos los nombres de dominio en un certificado, todos los hosts virtuales (dominios) en la misma dirección IP)? Ya he realizado pruebas con Apache 2.2 y 2.4, pero sin éxito.

    
pregunta Binarus 17.12.2015 - 20:13
fuente

2 respuestas

2

Se espera que establezca esto:

SSLCompression off
SSLHonorCipherOrder on
SSLInsecureRenegotiation off
SSLOptions +StrictRequire 

y cosas así a nivel mundial en /etc/apache2/mods-enabled/ssl.conf o un archivo correspondiente en su sistema. Sé que a Apache no le gusta que esto se configure varias veces en cada host virtual.

Y, por cierto, deberías eliminar DHE-DSS cifrados, de lo contrario, se desactivarán automáticamente. Se basan en DSA: no desea tener un certificado de DSA para respaldarlos.

    
respondido por el Vilican 17.12.2015 - 20:28
fuente
0

Bueno, parece que soy uno de los imbéciles más grandes del planeta. Ha sucedido lo siguiente:

He editado mis archivos de configuración de Apache usando el editor "nano" en Linux. He realizado la configuración para el primer host virtual (example1.com) escribiendo muchas cosas a mano o agregando pequeños fragmentos a través de copiar y pegar pieza por pieza.

Al crear los archivos de configuración para los otros hosts virtuales, he copiado grandes porciones del primer archivo de configuración en los otros. Hice esto usando un mouse en una ventana de terminal.

Como no había hecho nano para envolver las líneas, solo mostraba la primera parte de cada línea (hasta el borde derecho de la ventana correspondiente). Al copiar las líneas "desbordadas", solo se copió esa primera parte porque el terminal proporciona el método de copiar y pegar con el mouse y no el nano.

Solo había una línea en los archivos donde eso importaba. ¿Podrías adivinar cuál? Por supuesto, la más larga, es decir, la suite de cifrado.

Eso significa que en los archivos de configuración para cada host virtual, excepto el primero, la cadena de la suite de cifrado se cortó en algún punto intermedio porque solo la primera parte se copió desde la ventana del editor. No lo reconocí porque la ventana del editor nano tenía el mismo tamaño cada vez, y por lo tanto, la línea de la suite de cifrado se veía igual cada vez (la parte que faltaba estaba fuera de la ventana).

Por extraño que parezca, Apache no se quejó de la cadena de cifrado dañada (que en este caso finalizó con un guión) al iniciarse. Desde que activé LogLevel Debug y regularmente estudié todos los archivos de registro de Apache, realmente hubiera esperado ver algún mensaje sobre la cadena de la suite de cifrado con formato incorrecto. Pero no había absolutamente nada.

En otras palabras, ahora he alcanzado mi objetivo, y la configuración que he descrito anteriormente funciona a la perfección. Me disculpo por la confusión.

¿Qué podríamos aprender de eso?

1) Un Aphache vhost puede no funcionar como se esperaba incluso cuando su configuración no tiene errores, pero cuando hay errores en las otras vhost configuraciones.

2) SIEMPRE active el ajuste de línea en cualquier editor, cosa que siempre hago cuando trabajo con programas de Windows; de hecho, nano / Linux es el único editor donde regularmente me olvido de hacerlo (aunque también estoy usando otros editores de Linux).

    
respondido por el Binarus 18.12.2015 - 20:03
fuente

Lea otras preguntas en las etiquetas