Estoy configurando un servidor node.js:
https.createServer({
...
ciphers: 'ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH',
honorCipherOrder: true
}, app).listen(443);
Esto es capaz de lograr una calificación de SSLLabs A, lo cual es bueno. Ahora, parece que todas las negociaciones en la simulación de handshake se realizan usando TLS_RSA_WITH_RC4_128_SHA
.
RC4 es resistente a BESTIA. Si somos vulnerables a BESTIA no podemos obtener una calificación de A.
Me gustaría admitir PFS (secreto de reenvío) si el cliente lo admite.
Según mi lectura, "debo generar cierta aleatoriedad" al generar los parámetros de Diffie-Hellman y obtener eso en mis certificados de alguna manera, antes de que el servidor implemente correctamente ECDHE para el secreto hacia adelante. Leí en algún lugar que ECDHE requiere menos CPU que DHE, por lo que es una ventaja.
Bueno, tengo muchas preguntas. Pero voy a preguntar el primero:
¿Por qué debo generar "algunos aleatoriedad " para adjuntar a los certificados, ¿para qué sirve y qué hace realmente el comando? La página OpenSSL en dhparam no me dice mucho acerca de lo que realmente hace.
He visto esta respuesta y estoy buscando una explicación más clara (o al menos referencias a lecturas relevantes) !).
Según Cifres OpenSSL parece que ECDHE es un cifrado TLS 1.2. En página PFS de Qualys dice que ECDHE es compatible con todos los principales navegadores modernos, y sin embargo, solo veo iOS6 en los resultados de mi prueba de SSLLabs que se conecta a través de TLS1.2. Supongo que puedo tomar la sección de "simulación de apretón de manos" con un grano de sal.
Otra pregunta es por qué SSLLabs califica con una A si dejo la entrada HIGH
en la lista de cifrado: esto haría que el servidor admitiera una conexión, por ejemplo. TLS_RSA_WITH_AES_128_CBC_SHA
(el informe lo indica), que es vulnerable a BEAST! Tal vez porque nunca se probó con un "cliente" que no informa de compatibilidad con RC4.
Una pregunta más: en la página Cifres de OpenSSL, la lista debajo de las suites de cifrado TLS 1.2 incluye:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDHE-RSA-AES128-SHA256
¿Esto indica que si me conecto con ECDHE que ahora también es vulnerable a BEAST debido al uso de CBC? P.ej. Debería cambiar esto para hacer lo que hace Google: ECDHE con RC4. Pero la página de Ciphers no incluye nada que se parezca a ECDHE-RSA-RC4-SHA. Sin embargo, hay un ECDHE-ECDSA-RC4-SHA. ¿Cómo es esto diferente? Edit: esta respuesta SO menciona que ECDSA es algo separado de RSA. Me gustaría replicar lo que está haciendo Google con ECDHE_RSA + RC4 + SHA, ya que parece ser la combinación perfecta de rendimiento y seguridad.
Más notas (por favor, dígame si he entendido mal las cosas, especialmente las declaraciones disfrazadas de preguntas):
La resistencia de BESTIA se controla mediante la selección del cifrado simétrico (RC4 vs AES, etc.). ¿Los modos de AES que no utilizan CBC no son compatibles con muchos clientes? Entonces, ¿deberíamos evitar AES por completo ...? El PFS se puede obtener mediante el uso del intercambio de claves Diffie-Hellman, y solo los modos que incluyen DHE
o ECDHE
satisfacen esto. Sólo OpenSSL admite el secreto hacia delante perfecto. RC4 es más rápido que AES. RC4 es mejor que AES (debido a BESTIA)?
Otra edición: Veamos ... aquí es una indicación de que BEAST no es algo para ser < Em> también se preocupa de manera realista, aunque afecta negativamente la calificación de SSLLabs. Esa gran "A" se ve tan bien ... Veamos ... Probablemente debería poner los cifrados RC4_128 en el comienzo de la cadena de cifrado si, por ninguna otra razón, no se ha demostrado que estén "rotas", y están Más rápido que AES en general. De todos modos me he alejado mucho del tema original que es ECDHE. ¿Y cómo hacer que los parámetros DH funcionen correctamente con Node / Express?