Início / computer / Perguntas / 1757941
Accepted
porg
Asked: 2022-12-16 09:29:42 +0800 CST

Teste esse shell mysql com --ssl-mode=REQUIRED para dado --host REALMENTE funciona sem primeiro fornecer nome de usuário, senha, nome do banco de dados?

  • 772

Estou procurando uma possibilidade no cliente mysql para testar apenas se a --ssl-mode=REQUIREDdiretiva para um determinado --host é 100% garantida, sem potencialmente estragar o nome de usuário, a senha e o nome do banco de dados em texto simples pela Internet. Executando esse modo com um argumento como: --ssl--check-handshake-only-then-disconnect-and-report.

Isso é para um cenário em que, em relação ao host da web:

  • não há documentação adequada/disponível/confiável sobre a disponibilidade de SSL no servidor,
  • e/ou nenhum ou apenas acesso complicado ao servidor mysql e suas informações de configuração.

Depois de minha pesquisa até agora, acho que não há possibilidade de executar um teste de handshake SSL/TLS 100% sem risco, o que obviamente é sem risco, pois funciona sem fornecer nome de usuário, senha, nome do banco de dados .

A documentação para --ssl-mode=REQUIRED aborda isso de forma simples e resumida:

NECESSÁRIO: Estabeleça uma conexão criptografada se o servidor suportar conexões criptografadas. A tentativa de conexão falhará se uma conexão criptografada não puder ser estabelecida.

Basta confiar no cliente mysql (também conhecido como "shell") que ele realmente opera nessa ordem:

  1. certifique-se de que --ssl-mode=REQUIREDfunciona na situação especificada, caso contrário, saia prematuramente com uma mensagem de erro explícita.
  2. somente quando o handshake e a negociação de criptografia funcionarem bem, o cliente enviará o nome de usuário, a senha e o nome do banco de dados fornecidos.
  3. E que nenhum novo desenvolvedor jamais introduzirá um bug exatamente nessa verificação de condição ...

  • Isso pode ser suficiente para usuários versados/diários, que conhecem e confiam em seu cliente mysql e configuração.

  • Mas abaixo do ideal para novos usuários ou céticos que precisam ser céticos, que realmente precisam de uma possibilidade de uma verificação 100% sem risco.

Um verdadeiro "modo de teste de conexão/aperto de mão sem risco", que obviamente é sem risco porque também funciona sem apresentar nenhuma credencial concreta, seria muito reconfortante.

  • Antes de me registrar em https://bugs.mysql.com e enviar uma solicitação de recurso lá
  • Pergunto aqui se pode haver uma possibilidade que desconheço.
security

1 respostas

  1. Best Answer

    Se você deseja apenas testar se o cliente gera um erro quando o SSL não pode ser estabelecido, uma maneira rápida e suja é combinar estes dois:

    • basta conectar-se com um nome de usuário e senha falsos
    • forçar o cliente a falhar no handshake SSL com uma cifra ruim como--ssl-cipher SEED-SHA

    Você sempre deve ver o erro de "falha de SSL" e não de "senha incorreta". Tente --ssl-mode=REQUIREDligar e desligar para verificar se ele gera um erro ou retorna ao texto não criptografado.

    Se você quiser verificar se o servidor oferece suporte a SSL (e em que grau), algo como nmap será melhor. Certifique-se de ter uma versão atualizada do nmap e, em seguida, use algo como isto para verificar o status do SSL, por exemplo:

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

    E, se nada mais, você sempre pode verificar se as conexões não enviam credenciais antes do SSL com uma captura de pacote / wireshark, embora tenha uma curva de aprendizado.

    Como você mencionou, isso é simples se você puder trabalhar com quem controla o servidor, com opções como:

    • use autenticação baseada em certificado, para que nenhum segredo seja transferido
    • requer SSL no lado do servidor (o que deve ser exigido se for voltado para a Internet)
    • controlar conexões com VPN ou SSH antes de conectar ao MySql

    mas nem sempre é possível

    Resultados de nmap- Parece a ferramenta adequada para o trabalho!

    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 com --ssl-ciphere--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)
    • ❌ O servidor aceita texto simples.
    • ✅ Mas estragamos apenas dados falsos.
    • ✅ Nenhum dano causado. Risco máximo estabelecido.
    $ 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
    • ✅Servidor aborta com cifra ruim.
    • ℹ️ Pela teoria, sabemos que isso ocorre antes que as credenciais sejam enviadas.
    • ✅ Portanto, este é um pré-teste bom o suficiente, para quem tem o know-how.
    $ 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
    • ✅ Além disso, quando tentamos o servidor com PREFERRED, mas fornecemos uma cifra incorreta, o servidor faz a escolha segura e encerra.
    • ✅ Sente arrepios. Também não entendo por que --ssl-cipher SEED-SHA é exatamente uma cifra ruim e com quais condições isso é testado.
    $ 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)
    • ❓ Não sei como interpretar isso:
    • ❌ Apesar de EXIGIR o protocolo continua (pelo menos envia o nome de usuário, que felizmente ainda é apenas 'fakeUser'.
    • ❓Mas a senha também foi enviada neste pedido?
    • 1

relate perguntas