☰

¿Pruebe que el shell mysql con --ssl-mode=REQUIRED para el --host REALMENTE funciona sin proporcionar primero el nombre de usuario, la contraseña y el nombre de la base de datos?

tag-icon • tag-icon security encryption mysql ssl
¿Pruebe que el shell mysql con --ssl-mode=REQUIRED para el --host REALMENTE funciona sin proporcionar primero el nombre de usuario, la contraseña y el nombre de la base de datos?

Estoy buscando una posibilidad en elcliente mysqlcomprobar únicamente si la --ssl-mode=REQUIREDdirectiva a un determinado--host está 100% garantizado, sin estropear potencialmente el nombre de usuario, la contraseña y el nombre de la base de datosen texto plano a través de Internet. Ejecutando ese modo con un argumento como: --ssl--check-handshake-only-then-disconnect-and-report.

Esto es para un escenario en el que con respecto al servidor web de uno:

  • uno no tiene documentación adecuada/disponible/confiable sobre la disponibilidad de SSL en el servidor,
  • y/o acceso nulo o sólo complicado al servidor mysql y su información de configuración.

Después de mi investigación hasta ahora, creo que hayno hay posibilidad de realizar una prueba de protocolo de enlace SSL/TLS 100 % sin riesgoscual esobviamente sin riesgos ya que funciona sin proporcionar nombre de usuario, contraseña, nombre de base de datos.

La documentación para--ssl-mode=REQUERIDOaborda esto de manera muy simple y breve:

OBLIGATORIO: Establezca una conexión cifrada si el servidor admite conexiones cifradas. El intento de conexión falla si no se puede establecer una conexión cifrada.

Uno simplemente tiene que confiar en que el cliente mysql (también conocido como "shell") realmente opera en ese orden:

  1. asegúrese de que --ssl-mode=REQUIREDfuncione en la situación dada; de lo contrario, salga prematuramente con un mensaje de error explícito.
  2. Sólo cuando la negociación de protocolo de enlace y cifrado funcionó bien, el cliente envía el nombre de usuario, la contraseña y el nombre de la base de datos proporcionados.
  3. Y que ningún desarrollador nuevo introducirá un error exactamente en esa verificación de condición...

  • Esto puede ser suficiente para usuarios versados/cotidianos, que conocen y confían en su cliente y configuración mysql.

  • Pero no es óptimo para nuevos usuarios o escépticos que realmente necesitan la posibilidad de realizar una verificación 100% libre de riesgos.

Un "modo de prueba de conexión/apretón de enlace verdaderamente sin riesgos", que obviamente no tiene riesgos porque también funciona sin enviar ninguna credencial concreta, sería muy tranquilizador.

  • Antes de registrarme enhttps://bugs.mysql.comy envíe una solicitud de función allí
  • Pregunto aquí si puede haber una posibilidad que no conozco.

Respuesta1

Si solo desea probar que el cliente arroja un error cuando no se puede establecer SSL, entonces una forma rápida y sucia es combinar estos dos:

  • simplemente conéctese con un nombre de usuario y contraseña falsos
  • obligar al cliente a fallar el protocolo de enlace SSL con un cifrado incorrecto como--ssl-cipher SEED-SHA

Siempre debería ver el error de "fallo de SSL" y no de "contraseña incorrecta". Pruebe con --ssl-mode=REQUIREDencendido y apagado para verificar si arroja un error o vuelve al texto sin cifrar.

Si desea comprobar si el servidor admite SSL (y en qué medida), entonces algo como nmap será mejor. Asegúrese de tener una versión actualizada de nmap, luego use algo como esto para verificar el estado de SSL, por ejemplo:

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

Y al menos, siempre puede verificar que las conexiones no envíen credenciales antes de SSL con una captura de paquetes/wirehark, aunque tiene una curva de aprendizaje.

Como mencionas, esto es simple si puedes trabajar con quien controla el servidor, con opciones como:

  • Utilice autenticación basada en certificados, por lo que nunca se transfieren secretos.
  • requiere ssl en el lado del servidor (que debe solicitarse si está conectado a Internet)
  • controlar las conexiones con VPN o SSH antes de conectarse a MySql

pero no siempre es posible

Resultados de nmap- ¡Esta parece la herramienta adecuada para el trabajo!

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

Resultados de mysqlcombinado con --ssl-ciphery--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)
  • ❌ El servidor acepta texto sin formato.
  • ✅ Pero sólo hemos estropeado datos falsos.
  • ✅ No se produce ningún daño. Riesgo máximo establecido.
$ 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
  • ✅ El servidor aborta con un cifrado incorrecto.
  • ℹ️ Por teoría sabemos que esto se activa antes de que se envíen las credenciales.
  • ✅ Entonces esta es una prueba previa bastante buena, para aquellos que tienen los conocimientos.
$ 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
  • ✅ Además, cuando tentamos al servidor con PREFERRED pero proporcionamos un cifrado incorrecto, el servidor toma la opción segura y finaliza.
  • ✅Se siente escalofriante. Además, no entiendo por qué --ssl-cipher SEED-SHA es exactamente un cifrado incorrecto y con qué condiciones se prueba.
$ 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)
  • ❓ No estoy seguro de cómo interpretar esto:
  • ❌ Aunque REQUERÍ que el protocolo continúa (al menos envía el nombre de usuario, que afortunadamente todavía es solo 'fakeUser'.
  • ❓¿Pero también se envió la contraseña en esta solicitud?

información relacionada