I work on a very common case. I configured two servers: an OpenVPN and a MySQL (172.16.X.X) server hidden behind it. Let’s assume everything is perfectly configured and patched server side.


  • MySQL server has no public network interface
  • MySQL has no TLS configured. It does not use PAM authentication via PAM plugin. It accepts authentications from anywhere.
  • It uses a NAT to access the internet (NAT is done by OpenVPN server).
  • OpenVPN pushes its routes (172.16.X.X) allowing connected clients to find the MySQL server.

On the client side (192.168.X.X), I have several users who will connect to MySQL server through the VPN, using their own local OpenVPN client. With the previous assumption, unless I’m a fool (which is a possibility, you tell me), no MITM attacker would be able to get the MySQL password.


  • Clients have no pre-configured route for the distant VPN network (172.16.X.X).

Probable scenario

Let’s imagine: as a user, I try to connect this MySQL “hidden” server and it fails, because ooops… my openVPN software failed to start the tunnel without notice.

Now a malicious machine can be somewhere in the local network - people uses laptops anywhere these days - sniffing my miserable attempt to connect to a non-existing MySQL (172.16.X.X) server.


Will any MySQL client software send cleartext credentials to the default route, even if no MySQL server is found?

Is it possible for an attacker who knows the genuine MySQL server (172.16.X.X) exists to impersonate it by setting up a rogue MySQL server on the local network (192.168.X.X)?

If yes, how can I mitigate this scenario (hint: with a few resources, I work for a very small company)?

Thank you for your help!

  • Hi. You have many questions and may find this question gets closed for being too broad.
    Nov 23, 2017 at 12:12
  • Hi @ISMSDEV. I understand. I removed an question which can constitute another post if I’m not able to figure it out by myself.
    – Gui-Don
    Nov 23, 2017 at 13:25

3 Answers 3


To answer this question you must first understand the mysql-na handshake through to authentication.

If you are using default username & password authentication where the password is stored as sha1(sha1(password) hash in mysql.users then authentication works as follows (there's more steps but to keep this brief it's roughly the following):

  1. Client connects to server
  2. Server sends greeting, version and the supported capabilities of the server as well as a SALT to be used for the session
  3. Client requests authentication to begin, then sends SHA1(password) XOR(SALT + sha1(sha1(passsword)))

So first off credentials are not sent in the clear using this method, they are however if you use mysql_pam plugin as these are passed to PAM for authentication completion.

However using mysql-na you must be aware that and if an adversary can sniff a successful client-server auth handshake, then they can use the mysql-unsha vulnerability (https://github.com/cyrus-and/mysql-unsha1) to gain access without knowing the actual password.

With this clarified let's address you questions specifically

  • Will any MySQL client software send cleartext credentials to the default route?

This depends entirely on your mysql configuration if you are using PAM to authenticate then it is likely you will see credentials "on the wire", to be 100% on this it's worth running a packet capture on the server and inspecting the resulting pcap with wireshark / tshark.

  • If the network exists in my routing table?

As per above, depends on your MySQL configuration by default you should not see credentials in cleartext but this does not prevent attackers gaining access via mysql-unsha.

  • If the IP I try to reach exists locally?

Please clarify are you speaking about your VPN client machine LAN ? this depends on your routes and whether the VPN allows split-tunneling.

  • If the IP I try to reach exists locally and runs a MySQL server?

Again this needs to be clarified it's far too vague.

  • If yes, how can I mitigate this scenario (hint: with a few resources, I work for a very small company)?

Your questions need to be made clear, first and foremost so that you can communicate them out to third parties clearly and consistently, the take aways here for you are.

Under default configuration MySQL will use Mysql-NA for authentication which is username + password, this is not in the clear as only hashes are exchanges HOWEVER this is vulnerable to the mysql-unsha attack as outlined above which could allow an attacker to authenticate as a user which they have observed authenticating without knowing the original password only the sha1(password) hash.

  • Thank you. I was unaware of the unsha vulnerability, I will have a look at it. You are also right about the vagueness of my question, I edited/truncated it, hoping to make it clearer. However, if I understand correctly, you said that authentication packets will be sent on the default route. I guess you are assuming that a rogue MySQL machine exists on the local (non-VPN) network and that the client machine has the route to find it. (actually, this was the vague part of my question: can MySQL client leaks something to the network even if no MySQL server is found?).
    – Gui-Don
    Nov 23, 2017 at 14:31
  • @Gui-Don if the mysql client <-> server communication is not active then there is nothing to leak, if mysql client <-> server communication uses TLS it is highly unlikely to observe anything on the network which would classify as a leak however do be aware MySQL by default "fails open" when TLS negotiation fails, to work around this use the REQUIRE SSL privilege when granting users access.
    – Oneiroi
    Feb 6, 2018 at 14:27

MySQL is using a protocol on top of TCP for connections between remote systems. This means that a TCP connection need to be created successfully before any data gets transferred, which includes sending authentication information.

This means that under the assumption that the database is only reachable by VPN and that no one can impersonate the database no credentials will be leaked this way.

But if it is unknown if this assumption is true in your network. If it is not true then credentials might be leaked. The risk of this can not be estimated without knowing more about your network setup and security measures and also how attractive you are a a target, i.e. how much an attacker will invest. But, you can reduce the risk for example connecting to the database with TLS additionally to using a VPN.

  • Thank you. From your answer, I understand that before sending any data, TCP handshake should be successful. That makes sense. Now you also say that data could be leaked if the specific case a machine impersonate the database. As a client, I am on the network. MySQL server is on the (distant) network. OpenVPN automatically pushes routes, so if not connected, my local machine gets no route to the network. If I understand correctly, there’s no (easy) way an attacker could impersonate the database in this situation, right?
    – Gui-Don
    Nov 23, 2017 at 13:38
  • @Gui-Don: this depends on your network. If you have a default gateway then data for 172.16.25/24 gets sent to this gateway. If the attacker gets control of this gateway or a system behind the gateway (and the gateway is forwarding data for 172.16.25/24 ) he might manage to impersonate a system in the 172.16.25/24 network. Nov 23, 2017 at 15:05

It's very unlikely, but in some very difficult cases someone can get your credentials. Possible, but improbable.

  1. Attacker assumes control of your gateway

    By controlling the gateway, he can intercept any connection attempt and modify them.

  2. Your tunnel fails and you try to connect

    Attacker now can know you have an MySQL server somewhere, an can add a routing entry on the gateway pointing to a server he controls, using the same IP.

  3. Attacker sniffs your password

    IF you try to connect again, AND the VPN is off, AND the attacker sniffed the last try, AND the attacker have a routing entry on the gateway poiting to a server he controls, AND he is running a sniffer, then he can get your credentials.

Very unlikely, will take a lot of preparation, depends on luck (or lack of), requires gateway control, but possible.

  • You successfully understood my hazy question ;) Now I understand it’s not trivial for an attacker, because it needs gateway control (OpenVPN or local gateway) to push a malicious routing entry. Gateway control is pretty much a game over from a security standpoint anyway.
    – Gui-Don
    Nov 23, 2017 at 14:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .