error SSL3 al solicitar la conexión mediante TLS 1.2

15

Me he encontrado con varios hosts que lanzan errores de protocolo de enlace SSL3 a pesar de que solicito explícitamente TLS 1.2. ¿Por qué es esto? ¿Estoy usando el cliente openssl incorrecto?

$ openssl s_client -tls1_2 -connect i-d-images.vice.com:443
CONNECTED(00000003)
140735150146384:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
140735150146384:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
---
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
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1444078671
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
    
pregunta richid 05.10.2015 - 23:12
fuente

2 respuestas

31

En SSL / TLS, el cliente no solicita una versión de protocolo específica; el cliente anuncia la versión de protocolo máxima que admite, y luego el servidor elige la versión de protocolo que se usará. Su cliente no dice "vamos a usar TLS 1.2"; dice "Sé hasta TLS 1.2".

Un cliente puede tener sus propios requisitos adicionales, pero no hay espacio para indicarlos en el mensaje ClientHello . Si el cliente solo desea TLS 1.2, debe anunciar "hasta TLS 1.2" en su ClientHello , y también cerrar la conexión si el servidor responde con un mensaje que dice algo más que "Hagamos TLS 1.2". En su caso, las cosas ni siquiera llegaron a ese punto: el servidor respondió con una alerta fatal 40 ("handshake_failure", consulte el estándar ). Como señala @ dave_thompson_085, esto se debe a la falta de SNI : esta es una extensión por la cual el cliente documenta en su ClientHello message the name del servidor de destino. Algunos servidores necesitan SNI porque alojan varios sitios habilitados para SSL en la misma dirección IP y necesitan ese parámetro para saber qué certificado deben usar. La herramienta de línea de comandos openssl s_client puede enviar un SNI con una opción explícita -servername .

Como lo explicó @Steffen, SSL 3.0 y todas las versiones de TLS son bastante similares y usan el mismo formato de registro (al menos en la etapa temprana del protocolo de enlace), por lo que OpenSSL tiende a reutilizar las mismas funciones. Tenga en cuenta que dado que el servidor no responde con un ServerHello en absoluto, la versión del protocolo aún no se ha elegido, y SSL 3.0 sigue siendo, al menos conceptualmente, una posibilidad en ese punto inicial del protocolo de enlace.

    
respondido por el Thomas Pornin 06.10.2015 - 14:11
fuente
6

ssl3_read_bytes y ssl3_writes_bytes tratan con marcos estilo SSL3. Estos son los mismos con las versiones posteriores, es decir, TLS1.x. Por lo tanto, las mismas funciones se utilizan, aunque sus nombres puedan sugerir una cosa diferente. No hay una función específica tls1_read_bytes o similar.

    
respondido por el Steffen Ullrich 05.10.2015 - 23:31
fuente

Lea otras preguntas en las etiquetas