¿Puede (y debe) TLS ser estricto con respecto a los sistemas de cifrado que admite?

Navega tus respuestas
6

Al intentar establecer un canal TLS en outlook.com para retransmitir el tráfico SMTP, se producen fallas en la conexión y debo continuar sin cifrado.

Un ejemplo de dicha conexión: 

openssl s_client  -starttls smtp -crlf -connect x-com.mail.eo.outlook.com:25 -CApath /etc/ssl/certs/ -cipher DHE-RSA-AES256-SHA  
CONNECTED(00000003)
139677700306600:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 343 bytes and written 137 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Según el recorte anterior, intento TLS utilizando DHE-RSA-AES256-SHA. ¿No debería haber una renegociación hasta que las dos partes acuerden y establezcan una conexión TLS? ¿Qué pasaría si una de las partes no es capaz de usar todos los cifrados y algoritmos necesarios?

    
pregunta Georgios 03.11.2015 - 15:09
fuente

2 respuestas

12

Por favor, no confunda la negociación de TLS con un bazar donde todas las partes negocian y renegocian hasta encontrar una solución común. Dado que cada mensaje necesita tiempo para la entrega, sería demasiado lento. Por lo tanto, solo hay una oferta por parte del cliente que incluye todos los cifrados que el cliente está dispuesto a admitir, en el orden preferido por el cliente. Si el servidor tiene soporte para cualquiera de estos sistemas de cifrado, elegirá la mejor opción según los servidores o los clientes. Si no hay superposición la negociación falla de forma permanente.

En su caso, el servidor acepta los siguientes cifrados (según lo determinado por esta herramienta) ): 

ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
AES256-SHA256
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA

Dado que solo ofrece un solo cifrado DHE-RSA-AES256-SHA y este cifrado no es compatible con el servidor, la negociación falla.

    
respondido por el Steffen Ullrich 03.11.2015 - 15:15
fuente
4

Sí, TLS debe ser estricto con respecto a las suites de cifrado que admite. Sin la selección cuidadosa de la suite de cifrado, corre el riesgo de negociar con una suite de cifrado insegura que pueda verse comprometida. Si otra parte no admite un conjunto de cifrado que cumpla con sus estándares y usted valora mucho la seguridad en esa conexión, no debe permitir que su sistema funcione con conjuntos de cifrado de menor calidad.

Sin embargo, las implementaciones sensibles de TLS también admiten múltiples conjuntos de cifrado para aumentar las posibilidades de compatibilidad con otras partes. A pesar de las muchas revelaciones recientes de debilidades en varias suites de cifrado, aún quedan varias que se consideran seguras. Siempre que solo controle un lado de la conversación, sería ridículo restringir su sistema para que solo admita un conjunto de cifrado y luego esperar que todo Internet funcione de acuerdo con sus estándares individuales.

Lo que está sucediendo aquí es usted <<> eligiendo admitir solo un conjunto de cifrado, y el otro sistema está eligiendo no para apoyar ese. (Solo el propietario del otro sistema puede decir por qué, pero supongo que podría tener algo que ver con Logjam ). Sin embargo, el otro Es probable que el sistema admita varias otras suites de cifrado que son igual de seguras (si no más) que la que ha seleccionado. (Parece que @SteffenUllrich tiene la lista). Elija uno de los que le resulte más cómodo y configure su sistema para permitirlo.

O simplemente no uses TLS para esa conexión.

O simplemente no hables con ese servidor en absoluto.

Tu elección.

    
respondido por el Iszi 03.11.2015 - 15:43
fuente

Lea otras preguntas en las etiquetas

¿Qué sucede si alguien roba la clave privada de una autoridad de certificación? [duplicar] Java UUID.randomUUID () o SecureRandom para el segmento de identificación en la URL?