Estoy migrando un servidor que ejecuta Debian 10 a un servidor que ejecuta Debian 12 (y un kernel 6.x), y lo último que parece no funcionar es TLS 1.0, que he estado tratando de resolver.
Soy consciente de cambiar el SECLEVELy MinProtocolcomo se describe aquí:https://stackoverflow.com/a/61568390/6110631, pero esto no ha funcionado, por alguna razón.
En el sistema de trabajo, tengo:
[system_default_sect]
MinProtocol = TLSv1.0
CipherString = ALL:@SECLEVEL=1
Intenté agregar esto de la misma manera en el nuevo sistema, pero TLS 1.0 todavía no parece funcionar. En el servidor Apache (que depende de la aplicación), puedo ver:
AH02039: Certificate Verification: Error (68): CA signature digest algorithm too weak
De alguna manera esperaba esto, ya que pensé que TLS 1.0 estaría deshabilitado de forma predeterminada, así que jugué más con la configuración. Ningún cambio que hice pareció funcionar, y al realizar capturas de paquetes desde la perspectiva del cliente a través de un espejo de puerto, pude ver que toda la negociación TLS estaba fallando por completo (justo después de Client Hello, Alert (Level: Fatal, Description: Protocol Version).
Probando con openssl s_client, parece que algo está muy roto con TLS 1.0.
En el servidor Debian 10 existente, obtengo:
# openssl version
OpenSSL 1.1.1n 15 Mar 2022
# openssl s_client -connect OLDHOST -tls1
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = OLDHOST
verify return:1
---
Certificate chain
0 s:CN = OLDHOST
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
Sin embargo, en el nuevo servidor Debian 12, aparece:
# openssl version
OpenSSL 3.0.9 30 May 2023 (Library: OpenSSL 3.0.9 30 May 2023)
# openssl s_client -connect NEWHOST -tls1
CONNECTED(00000003)
140101680407744:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../ssl/record/rec_layer_s3.c:1544:SSL alert number 80
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 136 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1695085443
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
TLS 1.2 todavía funciona correctamente, pero obtengo esto para TLS 1.0 y TLS 1.1.
Intenté usar DEFAULT:@SECLEVEL=1y ALL:@SECLEVEL=1otras combinaciones de nivel de segundo 1, nivel de segundo 0, TODOS, DEFAULT, LEGACY, etc. Ninguno de ellos parece funcionar. He estado reiniciando Apache y todo el servidor periódicamente entre cambios.
También intenté agregar eso a la configuración de Apache, así que tengo lo siguiente:
Protocols h2 http/1.1
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ALL:@SECLEVEL=0
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
Otras preguntas/respuestas relacionadas, que lamentablemente no han aportado más información:
Algunos lugares parecen implicar que hoy en día hay que bajar SECLEVELde 1 a 0 para que esto funcione, por ejemplo, para los certificados SHA1, lo cual he hecho, pero todavía no hay cigarros.
La compatibilidad con TLS 1.0 y 1.1 ya está disponible.nose eliminó en OpenSSL 3 (lo verifiqué), por lo que debería ser compatible con la configuración adecuada.
Todas las soluciones documentadas no parecen funcionar para mí y no parece que esté más cerca después de perder todo el día depurando esto. ¿Existe alguna otra solución que alguien haya encontrado para hacer funcionar los cifrados más antiguos? Estoy especificando ALLcifrados en los niveles 0 y 1, y no parece obedecerme, por lo que esto parece bastante extraño.
Respuesta1
Sabía que esto era posible, y probablemente un error de configuración... de hecho, eso es lo que era.
De hecho, es necesario establecer SECLEVEL en 0, pero lo tenía en varios lugares y no lo había actualizado en todos.
En particular, el virtualhost específico todavía tenía SSLCipherSuite ALL:@SECLEVEL=1, que funcionaba bien con versiones anteriores de OpenSSL, pero ahora debe ser SSLCipherSuite ALL:@SECLEVEL=0.
(Había configurado esto en la configuración general de Apache, así como en /etc/ssl/openssl.cf`, pero como estaba configurado en el nivel de host virtual, lo anulaba. Todos los demás hosts virtuales ya estaban en el nivel 0 , y casualmente estaba probando usando el único host virtual que fue anulado a 1, naturalmente...)
Quiero reiterar que las personas que dicen que TLS 1.0 no es compatible con kernels recientes, Apache u OpenSSL (como en un comentario a esta pregunta) sonequivocadoy ellos trabajan concorrectoconfiguración. Esto parece ser un error común.
Actualmente, el cliente final aún no se conecta (falla en el protocolo de enlace TLS), por lo que algo aún no funciona, pero openssl s_clientahora negocia correctamente, a diferencia de antes, que es un progreso.
ElllenoLa solución también fue darse cuenta de que tanto certbot como acme.sh ahora prefieren ECDSA de forma predeterminada, por lo que es necesario solicitar explícitamente a RSA para obtener los cifrados que faltan. El antiguo servidor "funcionó" bien porque los certificados se renovaban del mismo tipo.
Fragmento de openssl.cnfun nuevo sistema que funciona:
cat /etc/ssl/openssl.cnf | grep -v "#"
openssl_conf = openssl_init
[openssl_init]
providers = provider_sect
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
MinProtocol = TLSv1.0
CipherString = ALL@SECLEVEL=0