Ssl

在 ClientHello 中根據客戶端 TLS 版本更改證書

  • February 6, 2019

我有一個場景,一些舊客戶端只能支持 MD5 和 SHA1 簽名。顯然,這些通常被認為已棄用,但我仍然需要支持它們。無法升級這些客戶端(韌體更新不再發布,理想情況下我想砍掉所有這些設備,但這也不可行)。

假設我仍然可以獲得 MD5 或 SHA1 簽名證書。

是否可以在任何(https)伺服器上根據客戶端在首次連接時發送的 ClientHello 塊中包含的傳入 TLS 版本提供不同的證書?

我相信應該可以通過編寫一個小的“代理”來讀取從客戶端傳入的前幾個字節,然後在最壞的情況下將連接拼接到服務不同請求的備用埠,但如果可能的話,我更願意如果存在支持此類功能的現有 Web 伺服器,請避免這種情況。

旁白:據我了解,SSL/TLS 協議確實包含針對降級攻擊的保護,因此,如果伺服器支持 1.2 並且客戶端也支持 1.2,那麼如果降級到 1.0,那麼連接應該終止(如果是主動人為-中間攻擊)。我相信這應該可以降低提供 MD5 或 SHA1 簽名證書的風險,至少在仍然支持舊 SSL/TLS 版本的情況下可以做到這一點。

Nginx 及其 lua 擴展和它的 ssl 部分可以根據握手的開始選擇要公開的證書,以及客戶端發送的內容,ClientHello但可能不是您確切需要的內容(支持的算法列表)。

完整文件位於https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/ssl.mdhttps://github.com/openresty/lua-nginx-module/# ssl_certificate_by_lua_block

它指出:

它對於根據每個請求設置 SSL 證書鍊和相應的私鑰特別有用。

還可以使用來自客戶端的 SSL 握手請求做一些有趣的事情,例如使用 SSLv3 協議甚至選擇性地拒絕舊的 SSL 客戶端。

您可以通過函式raw_client_addr和輕鬆訪問客戶端或伺服器 IP(對於多宿主 IP) raw_server_addr,以及客戶端通過讀取 SNI 部分嘗試訪問的主機名server_name。根據文件,我看不到可以訪問客戶端 ClientHello 的其他部分,但是如果您可以根據 IP 區分您的客戶端,或者如果您有兩個單獨的伺服器名稱,則您可能已經找到了上述解決方案可以綁定到特定的證書。

閱讀https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_ssl_certby.c我看不到訪問客戶端發送的密碼套件列表的特定方法。然而,這段程式碼從 openssl 庫中獲取所有底層的“SSL”資訊,所以我懷疑你想要的在技術上是可行的,但只需要編碼。

現在還有兩點:

1)“假設我仍然可以獲得 MD5 或 SHA1 簽名證書。”

這可能很難。至少來自預設操作下的公共已知 CA。CAB 論壇要求(https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf)在第 38 頁上有:

訂戶證書

摘要算法:SHA1 *、SHA-256、SHA-384 或 SHA-512

  • 根據第 7.1.3 節中定義的標準,SHA-1 可以與 RSA 密鑰一起使用。

進而:

7.1.3. 算法對象標識符

自 2016 年 1 月 1 日起,CA 不得使用 SHA-1 雜湊算法頒發任何新的訂閱者證書或從屬 CA 證書。

2)“據我了解,SSL/TLS 協議確實包含針對降級攻擊的保護,因此如果伺服器支持 1.2,而客戶端也支持 1.2,那麼如果降級到 1.0,那麼連接應該終止(如果有活動的 man-中間攻擊)。”

是的,但前提是使用 extension TLS_FALLBACK_SCSV,並且可能在現有會話期間禁止客戶端重新協商。有關解釋,請參閱https://crypto.stackexchange.com/questions/19673/how-does-tls-fallback-scsv-help#19674,但引用它的核心部分:

本質上,TLS_FALLBACK_SCSV 允許客戶端以不觸發伺服器錯誤的方式在降級連接嘗試中發送隱藏的版本號。

https://en.wikipedia.org/wiki/Transport_Layer_Security上的維基百科頁面也詳細討論了有關降級攻擊的內容。

順便說一句,這在 TLS 1.3 中得到了改進,引用了 4.1.3。來自 RFC8446 的伺服器您好:

TLS 1.3 在伺服器的隨機值中嵌入了降級保護機制。協商 TLS 1.2 或更低版本以

響應 ClientHello 的 TLS 1.3 伺服器必須

在其 ServerHello 中專門設置其隨機值的最後 8 個字節。

對於所有握手模式,已完成的 MAC(以及簽名,如果存在)可防止降級攻擊。此外,

如第 4.1.3 節所述,在隨機隨機數中使用某些字節

允許檢測到降級到以前的 TLS 版本。看

$$ BBFGKZ16 $$有關 TLS 1.3 和降級的更多詳細資訊。

引用自:https://unix.stackexchange.com/questions/498769