☰

TLS 1.0 与较新的 Debian/OpenSSL 不兼容

tag-icon • tag-icon ssl apache-2.4 openssl
TLS 1.0 与较新的 Debian/OpenSSL 不兼容

我正在将运行 Debian 10 的服务器迁移到运行 Debian 12（和 6.x 内核）的服务器，最后一个似乎不起作用的是 TLS 1.0，我一直在尝试弄清楚。

我知道要改变SECLEVEL和MinProtocol如下所述：https://stackoverflow.com/a/61568390/6110631，但由于某种原因，这并没有起作用。

在工作系统上，我有：

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

我尝试在新系统上以相同的方式添加它，但 TLS 1.0 似乎仍然不起作用。在 Apache 服务器（依赖应用程序）中，我可以看到：

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

我多少预料到了这一点，因为我认为默认情况下 TLS 1.0 将被禁用，因此我进一步调整了配置。我所做的任何更改似乎都没有效果，通过端口镜像从客户端角度进行数据包捕获后，我可以看到所有 TLS 协商都彻底失败了（在客户端问候之后）Alert (Level: Fatal, Description: Protocol Version)。

经过探究openssl s_client，似乎 TLS 1.0 存在一些严重问题。

在现有的 Debian 10 服务器上，我得到：

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

但是，在新的 Debian 12 服务器上，我得到：

# 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 仍能正常工作，但我在 TLS 1.0 和 TLS 1.1 中也遇到了这种情况。

我尝试过使用DEFAULT:@SECLEVEL=1，ALL:@SECLEVEL=1以及 sec level 1、sec level 0、ALL、DEFAULT、LEGACY 等其他组合。似乎都不起作用。在更改之间，我会定期重新启动 Apache 和整个服务器。

我也尝试将其添加到 Apache 配置中，因此我得到以下内容：

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

不幸的是，其他相关的问题/答案并未提供更多见解：

有几个地方似乎确实暗示，现在，你必须将值SECLEVEL从 1 降低到 0 才能使其工作，例如对于 SHA1 证书，我已经这样做了，但仍然没有成功。

TLS 1.0 和 1.1 支持不是已在 OpenSSL 3 中删除（我确实检查过了），因此通过适当的配置它应该受到支持。

所有记录的解决方案似乎都对我不起作用，而且在浪费了一整天时间调试这个问题之后，我似乎没有任何进展。是否有人找到了其他解决方案来让旧密码正常工作？我指定了ALL0 级和 1 级的密码，但它似乎不听我的，所以这看起来很奇怪。

答案1

我知道这是可能的，而且很可能是配置混乱......事实上，事实就是这样。

将 SECLEVEL 设置为 0 确实是必要的，但我在多个地方都这样做了，但并没有在所有地方都更新它。

特别是，特定的虚拟主机仍然具有SSLCipherSuite ALL:@SECLEVEL=1，它可以与旧版本的 OpenSSL 配合使用，但现在需要SSLCipherSuite ALL:@SECLEVEL=0。

（我已经在常规 Apache 配置以及 /etc/ssl/openssl.cf 中设置了它，但由于它是在虚拟主机级别设置的，因此它会覆盖它。所有其他虚拟主机恰好已经处于级别 0，而我恰好使用被覆盖为 1 的一个虚拟主机进行测试，自然而然……）

我想重申的是，那些说 TLS 1.0 不支持最新内核、Apache 或 OpenSSL 的人（比如在对这个问题的评论中）是错误的他们确实与正确的配置。这似乎是一个常见的误解。

目前，最终客户端仍然无法连接（TLS 握手失败），因此仍然有些不对劲，但openssl s_client现在可以正常协商，与以前不同，这是一个进步。

这满的解决方案还意识到 certbot 和 acme.sh 现在默认都首选 ECDSA，因此您需要明确请求 RSA 来获取缺失的密码。旧服务器“工作”良好，因为证书正在更新为相同类型。

openssl.cnf来自新工作系统的片段：

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

相关内容