Início / server / Perguntas / 1143995
Accepted
InterLinked
Asked: 2023-09-19 09:21:09 +0800 CST

TLS 1.0 quebrado com Debian/OpenSSL mais recente

  • 772

Estou migrando um servidor rodando Debian 10 para um servidor rodando Debian 12 (e um kernel 6.x), e a última coisa que parece não estar funcionando é o TLS 1.0, que estou tentando descobrir.

Estou ciente de que alterei SECLEVELe MinProtocolconforme descrito aqui: https://stackoverflow.com/a/61568390/6110631 , mas isso não funcionou, por algum motivo.

No sistema de trabalho, tenho:

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = ALL:@SECLEVEL=1

Tentei adicionar isso da mesma maneira no novo sistema, mas o TLS 1.0 ainda parece não funcionar. No servidor Apache (que depende do aplicativo), posso ver:

AH02039: Certificate Verification: Error (68): CA signature digest algorithm too weak

Eu esperava isso, pois imaginei que o TLS 1.0 estaria desabilitado por padrão, então brinquei mais com a configuração. Nenhuma alteração que fiz pareceu funcionar, e ao fazer capturas de pacotes da perspectiva do cliente por meio de um espelho de porta, pude ver que toda a negociação TLS estava falhando completamente (logo após o Client Hello, Alert (Level: Fatal, Description: Protocol Version).

Sondando com openssl s_client, parece que algo está muito quebrado com o TLS 1.0.

No servidor Debian 10 existente, recebo:

# 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-----

No entanto, no novo servidor Debian 12, recebo:

# 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

O TLS 1.2 ainda funciona corretamente, mas entendo isso para TLS 1.0 e TLS 1.1.

Eu tentei usar DEFAULT:@SECLEVEL=1e ALL:@SECLEVEL=1outras combinações de sec nível 1, sec nível 0, ALL, DEFAULT, LEGACY, etc. Nenhum deles parece funcionar. Tenho reiniciado regularmente o Apache e todo o servidor entre as alterações.

Também tentei adicionar isso à configuração do Apache, então tenho o seguinte:

Protocols h2 http/1.1
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ALL:@SECLEVEL=0
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off

Outras perguntas/respostas relacionadas, que infelizmente não produziram mais informações:

Alguns lugares parecem sugerir que hoje em dia você precisa diminuir SECLEVELde 1 para 0 para que isso funcione, por exemplo, para certificados SHA1, o que eu fiz, mas ainda sem charuto.

O suporte a TLS 1.0 e 1.1 não foi removido no OpenSSL 3 (eu verifiquei), portanto deve ser suportado, com a configuração adequada.

Todas as soluções documentadas não parecem estar funcionando para mim, e não pareço estar mais perto depois de perder o dia inteiro depurando isso. Existe alguma outra solução que alguém encontrou para fazer as cifras mais antigas funcionarem? Estou especificando ALLcifras em ambos os níveis 0 e 1, e ele não parece estar me obedecendo, então isso parece um tanto bizarro.

ssl

1 respostas

  1. Best Answer

    Eu sabia que isso era possível e provavelmente uma configuração complicada... na verdade, era isso mesmo.

    Definir SECLEVEL como 0 é realmente necessário, mas eu tinha isso em vários lugares e não atualizei em todos eles.

    Em particular, o virtualhost específico ainda tinha o SSLCipherSuite ALL:@SECLEVEL=1, que funcionava bem com versões mais antigas do OpenSSL, mas agora precisa ser o SSLCipherSuite ALL:@SECLEVEL=0.

    (Eu tinha definido isso na configuração geral do Apache, bem como em /etc/ssl/openssl.cf`, mas como isso foi definido no nível do virtualhost, estava substituindo isso. Todos os outros virtualhosts já estavam no nível 0 , e por acaso eu estava testando usando aquele virtualhost que foi substituído por 1, naturalmente...)

    Quero reiterar que as pessoas que dizem que o TLS 1.0 não é compatível com kernels recentes, Apache ou OpenSSL (como em um comentário a esta pergunta) estão erradas e funcionam com a configuração correta . Este parece ser um equívoco comum.

    Atualmente, o cliente final ainda não está se conectando (falha de handshake TLS), então algo ainda está errado, mas openssl s_clientagora negocia corretamente, ao contrário de antes, o que é um progresso.

    A solução completa também foi perceber que tanto o certbot quanto o acme.sh, por padrão, agora preferem o ECDSA e, portanto, você precisa solicitar explicitamente o RSA para obter as cifras ausentes. O servidor antigo "funcionou" bem porque os certificados estavam renovando do mesmo tipo.

    • 0

relate perguntas