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 alterar o 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 renderam mais informações:
Alguns lugares parecem sugerir que hoje em dia é necessário diminuir SECLEVELde 1 para 0 para que isso funcione, por exemplo, para certificados SHA1, o que eu fiz, mas ainda sem charuto.
O suporte TLS 1.0 e 1.1 temnãofoi removido no OpenSSL 3 (eu verifiquei), então 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.
Responder1
Eu sabia que isso era possível e provavelmente uma confusão de configuração... 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...)
Eu 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ãoerradoe eles trabalham comcorretoconfiguração. 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.
OcompletoA solução 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.
Trecho de openssl.cnfum novo sistema em funcionamento:
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