☰

最初にユーザー名、パスワード、データベース名を指定せずに、指定された --host に --ssl-mode=REQUIRED を指定して mysql シェルが本当に機能することをテストしますか?

tag-icon • tag-icon security encryption mysql ssl
最初にユーザー名、パスワード、データベース名を指定せずに、指定された --host に --ssl-mode=REQUIRED を指定して mysql シェルが本当に機能することをテストしますか?

私は可能性を探していますMySQLクライアント--ssl-mode=REQUIRED特定の指令が--host ユーザー名、パスワード、データベース名が危険にさらされることなく、100%保証されますインターネット経由でプレーンテキストで送信されます。次のような引数でそのモードを実行します--ssl--check-handshake-only-then-disconnect-and-report。

これは、Web ホストに関するシナリオです。

  • サーバー上でSSLが利用可能かどうかに関する適切な/利用可能な/信頼できるドキュメントがない、
  • および/または、mysql サーバーとその構成情報へのアクセスがまったくないか、または複雑です。

これまでの研究から、私は100%リスクのないSSL/TLSハンドシェイクテストの実行は不可能それはユーザー名、パスワード、データベース名を入力しなくても動作するため、明らかにリスクはありません。。

ドキュメント--ssl-mode=必須この点について非常に簡潔かつ簡潔に説明しています。

必須: サーバーが暗号化接続をサポートしている場合は、暗号化接続を確立します。暗号化接続を確立できない場合、接続試行は失敗します。

MySQL クライアント (別名「シェル」) が実際にその順序で動作することを信頼するだけです。

  1. 特定の状況で動作することを確認し--ssl-mode=REQUIRED、動作しない場合は明示的なエラー メッセージを表示して途中で終了します。
  2. ハンドシェイクと暗号化ネゴシエーションが正常に完了した場合にのみ、クライアントは提供されたユーザー名、パスワード、データベース名を送信します。
  3. そして、新しい開発者がまさにその条件チェックでバグを持ち込むことは決してありません...

  • これは、MySQL クライアントとセットアップを熟知し、信頼している熟練した日常的なユーザーにとっては十分かもしれません。

  • しかし、100% リスクのないチェックの可能性を本当に必要としている新規ユーザーや懐疑的な人にとっては、最適とは言えません。

具体的な資格情報を送信しなくても機能するため明らかにリスクがない、真に「リスクのない接続/ハンドシェイク テスト モード」があれば、非常に安心できます。

  • 登録する前に参考文献機能リクエストを送信してください
  • ここで私が知らない可能性があるかどうか尋ねます。

答え1

SSL を確立できないときにクライアントがエラーをスローすることをテストしたいだけの場合は、次の 2 つを組み合わせるのが簡単な方法です。

  • 偽のユーザー名とパスワードで接続するだけです
  • 次のような不正な暗号を使用して、クライアントに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」のみです)。
  • ❓しかし、このリクエストでパスワードも送信されましたか?

関連情報