MySQL por VPN: verifique o servidor, não só a criptografia
Criptografar para o host errado continua errado. Compare os valores de ssl-mode e depois execute uma ligação que nomeie o servidor pretendido e o comprove.
Guarda uma ligação para 10.20.4.15, a VPN cai e o cliente continua a ligar-se. Não é uma boa notícia. Um endereço privado é uma localização dentro de qualquer contexto de encaminhamento em que esteja, e muitas redes usam os mesmos intervalos. O cliente chegou a um servidor MySQL, só que talvez não ao seu.
A correção tem duas metades, e só uma delas é sobre a rede. Mantenha a ligação no caminho pretendido e faça o cliente autenticar o servidor com quem fala. A primeira metade é onde uma VPN ajuda; a segunda tem de ser configurada.
Criptografado para quê, exatamente?
O TLS protege a conversa de qualquer pessoa no meio e não diz nada sobre quem o endpoint afirma ser, a menos que o cliente o verifique. Um certificado que valida contra uma autoridade de confiança prova que o certificado veio dessa autoridade. Não prova que o certificado foi emitido para o nome de anfitrião que pretendia alcançar, e são perguntas diferentes.
Não é uma lacuna teórica. Portais cativos, erros de VRF errado e planos de endereços sobrepostos produzem todos um servidor perfeitamente disposto a negociar TLS consigo. Se o cliente só exige criptografia, a sessão é privada e aponta para a base de dados errada.
Portanto, a pergunta relevante não é se a ligação está criptografada, mas se está criptografada para a identidade que pretendia. No cliente MySQL, essa distinção vive inteiramente na definição ssl-mode.
Os cinco valores de ssl-mode na prática
Existem cinco valores, e apenas um deles responde à pergunta deste manual. A tabela lista o que cada um garante realmente, em vez do que o nome sugere.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
Só a última linha responde à pergunta deste artigo. PREFERRED merece destaque próprio, porque um cliente que cai silenciosamente para texto simples é pior do que um que recusa: acredita que tem criptografia e a captura de pacotes não concorda.
Uma ligação que pode executar hoje
O comando abaixo é a forma a usar, com dois marcadores: o nome de base de dados aprovado e um ficheiro CA obtido por um canal aprovado. Nenhum deles deve ser retirado do que o servidor lhe oferece no primeiro contacto.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password sem valor pede entrada, o que mantém o segredo fora da lista de processos e fora do histórico da sua shell. É um hábito pequeno com um grande retorno em anfitriões de salto partilhados, onde uma linha de comandos é visível para outros utilizadores.
Quando isto falha, o texto do erro distingue os casos melhor do que a intuição. Uma falha de CA significa que a cadeia não valida e deve olhar para qual CA assinou o certificado do servidor. Uma falha de nome de anfitrião significa que a cadeia está bem e o nome não corresponde, o que normalmente significa que se ligou ao servidor correto com o nome errado, e não ao servidor errado.
O aparecimento de um pedido não é prova de que uma palavra-passe já foi transmitida, e uma ligação falhada não prova que nada saiu do cliente. Se estiver a reconstruir um evento passado, identifique o cliente, a configuração, o plugin de autenticação e a fase que falhou. Estimar a exposição a partir da mensagem de erro final é adivinhar.
Quando o nome vem de um túnel
O encaminhamento de porta local quebra a verificação de identidade de uma forma que surpreende as pessoas. Se encaminhar uma porta local para a base de dados e se ligar a localhost, o cliente valida o certificado contra localhost, e não foi emitido qualquer certificado para esse nome. A ligação pode ser perfeitamente segura e a verificação falhará mesmo assim, o que é a verificação a funcionar como pretendido.
Há duas respostas honestas. Dê ao endpoint encaminhado um nome que resolva para o endereço de loopback e apareça no certificado do servidor, ou use o nome de anfitrião de ponta a ponta para que o cliente verifique a identidade real. O primeiro é cómodo para programadores e exige trabalho de certificados; o segundo é mais fácil de raciocinar e muitas vezes o padrão correto para automatização. Desativar a verificação para que o encaminhamento funcione deita fora a propriedade que tentava acrescentar.
A aceitação são três condições
Escreva o teste de aceitação como três afirmações separadas: a ligação usou a rota pretendida, a criptografia era exigida e não preferida, e a identidade do servidor foi verificada contra material de confiança. Um ícone verde de VPN não estabelece nenhuma delas.
Para clientes com GUI e para MariaDB, consulte a documentação do próprio fornecedor em vez de assumir que a grafia do indicador se transfere. A documentação do MySQL sobre ligações criptografadas cobre as diferenças entre modos e o requisito de distribuição de CA, e é a referência a consultar antes de alterar uma cadeia de ligação de produção.