☰

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 協商都徹底失敗（在 Client Hello 之後，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 的虛擬主機進行測試，自然...）

我確實想重申，那些說最新核心、Apache 或 OpenSSL 不支援 TLS 1.0 的人（例如在對此問題的評論中）是錯誤的他們確實與正確的配置。這似乎是一個常見的誤解。

目前，最終客戶端仍然沒有連線（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

相關內容