☰

Проверьте, что оболочка MySQL с --ssl-mode=REQUIRED для указанного --host ДЕЙСТВИТЕЛЬНО работает без предварительного указания имени пользователя, пароля и имени базы данных?

tag-icon • tag-icon security encryption mysql ssl
Проверьте, что оболочка MySQL с --ssl-mode=REQUIRED для указанного --host ДЕЙСТВИТЕЛЬНО работает без предварительного указания имени пользователя, пароля и имени базы данных?

Я ищу возможность вклиент mysqlтолько для проверки того, относится ли --ssl-mode=REQUIREDдиректива к данному--host гарантировано на 100%, без потенциальной порчи имени пользователя, пароля и имени базы данныхв открытом виде через Интернет. Запуск этого режима с аргументом типа: --ssl--check-handshake-only-then-disconnect-and-report.

Это касается сценария, когда в отношении вашего веб-хостинга:

  • нет надлежащей/доступной/надежной документации о доступности SSL на сервере,
  • и/или отсутствие или затрудненный доступ к серверу MySQL и его конфигурационной информации.

После проведенных мною исследований я думаю, что естьнет возможности для 100% безопасного тестового запуска SSL/TLS-рукопожатиякоторыйочевидно, что это безопасно, так как это работает без указания имени пользователя, пароля, имени базы данных.

Документация для--ssl-mode=ОБЯЗАТЕЛЬНОотвечает на этот вопрос очень просто и кратко:

ОБЯЗАТЕЛЬНО: Установите зашифрованное соединение, если сервер поддерживает зашифрованные соединения. Попытка подключения не удается, если зашифрованное соединение не может быть установлено.

Нужно просто довериться клиенту MySQL (он же «оболочка»), что он действительно работает в таком порядке:

  1. убедитесь, что это --ssl-mode=REQUIREDработает в данной ситуации, в противном случае произойдет преждевременный выход с явным сообщением об ошибке.
  2. Только после успешного установления связи и согласования шифрования клиент отправляет указанные имя пользователя, пароль и имя базы данных.
  3. И что ни один новый разработчик никогда не внесет ошибку именно в это условие проверки...

  • Этого может быть достаточно для опытных/обычных пользователей, которые знают и доверяют своему клиенту и настройкам MySQL.

  • Но не является оптимальным вариантом для новых пользователей или скептиков, которым действительно нужна возможность 100%-ной проверки без риска.

По-настоящему «безопасный режим тестирования соединения/рукопожатия», который, очевидно, безопасен, поскольку работает без предоставления каких-либо конкретных учетных данных, был бы весьма обнадеживающим.

  • Прежде чем я зарегистрируюсь наhttps://bugs.mysql.comи отправьте запрос на функцию там
  • Я спрашиваю, может ли быть такая возможность, о которой я не знаю.

решение1

Если вы просто хотите проверить, выдает ли клиент ошибку, когда не удается установить SSL, то быстрый и грязный способ — объединить эти два способа:

  • просто подключитесь с помощью поддельного имени пользователя и пароля
  • заставить клиента отказать в ssl-рукопожатии с плохим шифром, например--ssl-cipher SEED-SHA

Вы всегда должны видеть ошибку "SSL failure", а не "bad password". Попробуйте включить --ssl-mode=REQUIREDи выключить, чтобы проверить, выдает ли он ошибку или возвращается к открытому тексту.

Если вы хотите проверить, поддерживает ли сервер SSL (и в какой степени), то лучше подойдет что-то вроде nmap. Убедитесь, что у вас обновленная версия nmap, затем используйте что-то вроде этого, чтобы проверить статус SSL, например:

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

И если ничего другого не поможет, вы всегда можете проверить, что соединения не отправляют учетные данные до SSL, с помощью захвата пакетов / Wireshark, хотя это требует обучения.

Как вы упомянули, это просто, если вы можете работать с тем, кто контролирует сервер, с такими опциями, как:

  • использовать аутентификацию на основе сертификатов, чтобы никакие секреты не передавались
  • требуется SSL на стороне сервера (который должен быть востребован, если он имеет выход в Интернет)
  • управляйте соединениями с помощью VPN или SSH перед подключением к MySql

но это не всегда возможно

Результаты 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»).
  • ❓Но был ли отправлен пароль в этом запросе?

Связанный контент