☰

使用 --ssl-mode=REQUIRED 到給定的 --host 測試 mysql shell 是否真的可以在不先提供使用者名稱、密碼、資料庫名稱的情況下運作？

tag-icon • tag-icon security encryption mysql ssl
使用 --ssl-mode=REQUIRED 到給定的 --host 測試 mysql shell 是否真的可以在不先提供使用者名稱、密碼、資料庫名稱的情況下運作？

我正在尋找一種可能性mysql客戶端僅測試--ssl-mode=REQUIRED指令是否給定--host 100% 確保，不會破壞使用者名稱、密碼和資料庫名稱透過網路以明文形式。使用如下參數運行該模式--ssl--check-handshake-only-then-disconnect-and-report：

這是針對一個虛擬主機的場景：

  • 沒有關於伺服器上 SSL 可用性的適當/可用/可靠的文檔，
  • 和/或沒有或只有複雜的存取 mysql 伺服器及其配置資訊。

經過我迄今為止的研究，我認為有不可能進行 100% 無風險的 SSL/TLS 握手測試運行這是顯然沒有風險，因為它無需提供使用者名稱、密碼、資料庫名稱即可運作。

的文檔--ssl-模式=必需非常簡單明了地解決了這個問題：

必需：如果伺服器支援加密連接，則建立加密連接。如果無法建立加密連接，則連線嘗試將會失敗。

人們只需相信 mysql 客戶端（又稱“shell”）它確實按以下順序運行：

  1. 確保--ssl-mode=REQUIRED在給定情況下有效，否則會過早退出並顯示明確的錯誤訊息。
  2. 只有當握手和加密協商順利時，客戶端才會提交提供的使用者名稱、密碼、資料庫名稱。
  3. 並且沒有新的開發人員會在該條件檢查中完全引入錯誤...

  • 這對於熟悉並信任他們的 mysql 客戶端和設定的熟練/日常用戶來說可能就足夠了。

  • 但對於新用戶或需要懷疑的人來說，這並不是最佳選擇，因為他們確實需要 100% 無風險檢查的可能性。

真正的「無風險連接/握手測試模式」顯然是無風險的，因為它也可以在不提交任何具體憑證的情況下工作，這將非常令人放心。

  • 在我註冊之前https://bugs.mysql.com並在那裡提交功能請求
  • 我在這裡問，是否存在我不知道的可能性。

答案1

如果您只是想測試客戶端在無法建立 SSL 時是否拋出錯誤，那麼一種快速而骯髒的方法是將兩者結合起來：

  • 只需使用虛假的用戶名和密碼連接
  • 強制客戶端使用錯誤的密碼使 ssl 握手失敗，例如--ssl-cipher SEED-SHA

您應該始終看到“SSL 失敗”錯誤，而不是“密碼錯誤”。嘗試--ssl-mode=REQUIRED開啟和關閉以驗證它是否引發錯誤或回退到明文。

如果你想檢查伺服器是否支援 SSL（以及支援程度），那麼像 nmap 這樣的東西會更好。確保您有 nmap 的更新版本，然後使用類似以下內容來檢查 SSL 狀態，例如：

nmap --script ssl-enum-ciphers MyServerName -p 3306

如果沒有意外，您始終可以使用資料包擷取/wireshark 來驗證連線是否在 SSL 之前發送憑證，儘管它有一個學習曲線。

正如您所提到的，如果您可以與控制伺服器的任何人一起使用以下選項，那麼這很簡單：

  • 使用基於憑證的身份驗證，因此不會傳輸任何秘密
  • 在伺服器端需要 ssl（如果是面向互聯網的，則應該要求）
  • 在連接到 MySql 之前使用 VPN 或 SSH 控制連接

但這並不總是可能的

結果nmap- 這感覺像是適合這項工作的工具！

nmap --script ssl-enum-ciphers  customerid-mysql.services.mywebhost.com -p 3306
Starting Nmap 7.93 ( https://nmap.org ) at 2022-12-16 01:39 CET
Nmap scan report for customerid-mysql.services.mywebhost.com (XXX.XX.X.XX)
Host is up (0.016s latency).
rDNS record for XXX.XX.X.XX: web20.mywebhost.com

PORT     STATE SERVICE
3306/tcp open  mysql
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 4096) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 4096) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 4096) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 4096) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       Key exchange (dh 2048) of lower strength than certificate key
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 3.23 seconds

與mysql結合的結果--ssl-cipher--ssl-mode

$ mysql --ssl-cipher SEED-SHA  -h customerID-mysql.services.mywebhost.com -u fakeUser -p --ssl-mode=DISABLED 
Enter password: 
ERROR 1045 (28000): Access denied for user 'fakeUser'@'XX.XXX.XX.XX' (using password: YES)
  • ❌ 伺服器接受明文。
  • ✅ 但我們只破壞了假數據。
  • ✅ 沒有造成任何傷害。已確定最大風險。
$ mysql --ssl-cipher SEED-SHA  -h customerID-mysql.services.mywebhost.com -u fakeUser -p --ssl-mode=REQUIRED 
Enter password: 
ERROR 2026 (HY000): SSL connection error: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
  • ✅ 伺服器因密碼錯誤而中止。
  • ℹ️ 從理論上我們知道這在發送憑證之前就開始了。
  • ✅ 因此，對於那些具備專業知識的人來說，這是一個足夠好的預測試。
$ mysql --ssl-cipher SEED-SHA  -h customerID-mysql.services.mywebhost.com -u fakeUser -p --ssl-mode=PREFERRED
Enter password: 
ERROR 2026 (HY000): SSL connection error: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
  • ✅ 此外，當我們用 PREFERRED 誘惑伺服器但提供了錯誤的密碼時，伺服器會採取安全的選擇並終止。
  • ✅ 感覺很冷。另外，我不明白為什麼 --ssl-cipher SEED-SHA 是一個錯誤的密碼，以及在什麼條件下進行測試。
$ mysql  -h customerID-mysql.services.mywebhost.com -u fakeUser -p --ssl-mode=REQUIRED 
Enter password: 
ERROR 1045 (28000): Access denied for user 'fakeUser'@'77.119.77.94' (using password: YES)
  • ❓ 不知道如何解釋：
  • ❌雖然我要求協議繼續（至少提交用戶名，幸運的是，這只是「fakeUser」。
  • ❓但是這個請求中也發送了密碼嗎？

相關內容