Utilizando el comando openssl, ¿cómo puedo saber si está usando TLS 1.0?

Question

Utilizando el comando openssl, ¿cómo puedo saber si está usando TLS 1.0?

#1 de Steffen Ullrich (6 votos)
#2 de jwilleke (3 votos)
#3 de dave_thompson_085 (2 votos)

5

Debido a un análisis de seguridad, me dijeron que no usara TLS1.0. Encontré un enlace que me dio los comandos que debo usar para verificar si se usa / habilita un protocolo específico. El comando que ejecuté (con salida es)

(Salida de TLS1.0 deshabilitada)

$ openssl s_client -connect localhost:8443 -tls1
CONNECTED(00000003)
139874418423624:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL alert number 40
139874418423624:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1505770082
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

El enlace dice que si el protocolo está habilitado, dirá "Conectado", o "Fallo de intercambio". Sin embargo, como puede ver los mensajes anteriores, dice que ambos configuran Tomcat para usar TLS1.2.

Mi configuración en el archivo server.xml:

<Connector port="8443" protocol="HTTP/1.1"
   maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
   keystoreFile="/glide/bigdata/bdapi/keys/bdapi_keystore.jks"
   keystorePass="bdapi123" clientAuth="false" sslProtocol="TLSv1.2" 
   sslEnabledProtocols="TLSv1.2"/>

Si permito que Tomcat use TLS1.0, todavía veo CONECTADO pero también veo la información del certificado.

(Salida de TLS1.0 habilitada)

openssl s_client -connect localhost:8443 -tls1
CONNECTED(00000003)
<snip snip>
<snip snip>
(certificate info)
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
<snip snip>
<snip snip>
(certificate info)
---
Server certificate
-----BEGIN CERTIFICATE-----
<snip snip>
<snip snip>
(public key)
-----END CERTIFICATE-----
<snip snip>
<snip snip>
(certificate info)
---
No client certificate CA names sent
Server Temp Key: ECDH, secp521r1, 521 bits
---
SSL handshake has read 2121 bytes and written 357 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 59C0448146B0A18DE52D99C630C896E12BA9861702AB2582C2AA0658E6458B04
    Session-ID-ctx: 
    Master-Key: <some random key>
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1505772673
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
read:errno=0

¿Cómo interpreto la salida de openssl? ¿Deshabilité exitosamente TLS1.0 con la configuración anterior o como dice "CONECTADO" en ambas salidas, no lo deshabilité y fallaré el análisis de seguridad nuevamente?

tls openssl tomcat

pregunta Classified 19.09.2017 - 00:44

fuente

3 respuestas

3

Aunque estas herramientas no responden directamente a su pregunta específica, pueden proporcionar los resultados que está buscando. Si tiene una conexión a Internet, pruebe alguno de estos:

Si no hay conexión a Internet, intente:

respondido por el jwilleke 20.09.2017 - 11:37

fuente

2

Sí, ese sitio web es incorrecto ; CONNECTED significa que la conexión TCP fue exitosa, pero no dice nada sobre el protocolo de enlace TLS (o con suerte no SSL). Si no obtiene CONECTADO, pero obtiene algunas líneas que terminan con connect: errno=$n (¡incluso si el número es 0!) Significa que ni siquiera pudimos intentar un apretón de manos y, por lo tanto, no tenemos información de lo que el servidor admite.

Aunque puede aprender a leer los mensajes de error y otra información que openssl apaga, el indicador clave es la línea que comienza New, al comienzo del último bloque de salida (después de --- unas pocas líneas antes %código%); si muestra una versión de protocolo real y cifra el handshake exitoso, si tiene SSL-Session: the handshake fallado , como el tuyo.

Tenga en cuenta que el protocolo de enlace puede fallar por razones distintas a la versión del protocolo. Si esta prueba es exitosa para 1.0, puede estar seguro de que el servidor es compatible con 1.0, pero si esta prueba falla, definitivamente no prueba que el servidor no sea compatible con 1.0. Tendrá que aprender realmente sobre TLS para distinguirlos. Como Steffen publicó con mucha mayor extensión mientras escribía esto, pero decidí que mis párrafos 2 y 4 todavía podrían ayudar.

FWIW también observa que las pruebas para SSLv2 que usan solo (NONE) no son válidas en las versiones 1.0.0 hasta donde la lista de cifrado predeterminada evita la conexión SSLv2 incluso en servidores que admiten SSLv2. Sin embargo, cualquier persona que todavía esté preocupada por SSLv2 en un servidor real (no en un laboratorio de pruebas o en un museo) está en serios problemas.

respondido por el dave_thompson_085 19.09.2017 - 07:23

fuente

Lea otras preguntas en las etiquetas tls openssl tomcat

¿Por qué mi navegador no confía en CAcert? Responda desde "nsa.gov" mientras hace ping en "gen.lib.rus.ec"

score 6 · Accepted Answer

TL; TR: Está lejos de ser trivial verificar desde el cliente que un servidor no es compatible con TLS 1.0. Puede estar seguro de que el servidor admite TLS 1.0 si obtiene una conexión exitosa con TLS 1.0. Pero no puede estar seguro de que el servidor no admita TLS 1.0 si este intento falla.

Como ya se dio cuenta, la información que se proporciona en el enlace que cita es al menos parcialmente incorrecta. Además, están incompletos. Comprobar si un servidor tiene realmente TLS 1.0 deshabilitado no es tan simple. Para comprender qué se debe verificar para estar realmente seguro de que es mejor tener al menos una comprensión básica de cómo funciona el protocolo de enlace TLS. Tenga en cuenta que la mayoría de lo que digo aquí también es válido para SSL, que es principalmente el nombre anterior para la misma familia de protocolos ahora conocida como TLS.

Inicialmente, el cliente necesita crear una conexión TCP con el servidor. Esto no tiene nada que ver con TLS en si mismo. Y ya si la conexión TCP se realiza correctamente, obtendrá CONNECTED(00000003) . Si no lo CONECTA, entonces el servidor podría estar inactivo o podría no estar accesible desde su sitio, por ejemplo, porque un firewall está bloqueando el acceso. Por lo tanto, no obtener el CONECTADO no dice nada sobre la capacidad del servidor para admitir TLS 1.0 .

Una vez creada la conexión TCP, comienza la parte TLS. En el caso más simple, el cliente envía al comienzo del protocolo de enlace TLS dentro del mensaje de ClientHello la mejor versión TLS que puede y los cifrados que admite. El servidor responde con el mejor protocolo SSL / TLS que admite, que es igual o inferior a la versión de protocolo ofrecida por el cliente. Y el servidor elige el cifrado común según lo que ofrece el cliente y lo que está configurado para ser aceptable para el servidor. En su caso específico, el cliente ofrece TLS 1.0 como el mejor protocolo (debido a la opción -tls1 ) y el conjunto de cifrado predeterminado. El protocolo de enlace fallará si el servidor no admite TLS 1.0 o inferior O si el servidor no admite ninguno de los cifrados ofrecidos por el cliente. Debido a la última parte , es posible que el servidor falle con su cliente específico, incluso si el servidor tiene TLS 1.0 habilitado porque al servidor no le gustan las cifras ofrecidas por el cliente .

Y se vuelve más complejo. Es común que los servidores admitan varios certificados en la misma dirección IP en la actualidad. Esto se hace incluyendo el nombre de host de destino mediante la extensión SNI TLS dentro de ClientHello al comienzo del protocolo de enlace TLS. Si no hay una extensión SNI o si la extensión no coincide con ningún nombre de host configurado, el servidor generalmente enviará algún certificado predeterminado o abortará el protocolo de enlace. Debido a la última parte , es posible que el servidor falle con su cliente específico, incluso si el servidor tiene TLS 1.0 habilitado porque no se usó la extensión SNI o si se usó con el nombre de host incorrecto . openssl s_client no usará SNI de manera predeterminada, por lo que su intento simplemente podría haber fallado simplemente debido a la falta de una extensión SNI. Debe usar la opción -servername para esto y, por supuesto, debe usar un nombre de host configurado correctamente en el servidor con esta opción.

Y hasta ahora solo tratamos con pilas TLS sanas y una conexión directa al servidor. Si la pila de TLS está rota o si hay algún middlebox roto entre ellos (como balanceadores de carga, cortafuegos, etc.), es posible que el handshake falle accidentalmente o a propósito, aunque el servidor sea compatible con TLS 1.0. Y si tiene alguna terminación SSL frente a su servidor (algunos firewalls, balanceadores de carga o un CDN) ni siquiera probará las propiedades del servidor sino del sistema que se encuentra frente a él.

En otras palabras: si obtiene una conexión TLS 1.0 exitosa con el servidor, puede estar seguro de que el servidor o algún terminador SSL que se encuentra frente a él es compatible con TLS 1.0. Si la conexión TLS 1.0 falla, no significa que el servidor no admita TLS 1.0.