If I have a java client that connects to a server, but in the java client code where the connection is built, it skips hostname verification disabled. When a client tries to connect to serverA.com, what is the impact if hostname verification is not enabled? Checking online, it mentions that a MITM attack is possible, however, how is this possible ? If the rogue server presents a certificate, even if there hostname is not checked, still the certificated should be signed from a CA trusted by the client no? I can't think of a way how this attack could be possible. Am I mistaken in my analysis or am I missing something?
-
One of the CAs that the client will surely like is Let's Encrypt, that provides free TLS certificates.– ThoriumBRCommented Mar 18 at 15:52
Add a comment
|
2 Answers
still the certificated should be signed from a CA trusted by the client no?
yes, but there is a caveat: everyone can get its own certificate from a CA your client trusts as long as they can prove my domain ownership. Since your client app do not care about a domain in certificate, then all it costs to me:
- Register new arbitrary domain
- Validate new domain ownership with CA (it is a matter of adding DNS record)
- Get perfectly valid and legitimate TLS certificate from CA for my own domain
- Assign this certificate to my own web server
- Re-route requests from your phone to my server
- ??????
- PROFIT
Your client application will be presented with a certificate issued from a trusted CA. Since host name validation is off, client will think it talks to a legitimate server, while in reality it doesn't.
In other words, host name validation in TLS sessions is no less important than validating the trust of server certificate's chain.
-
okay but how wil the re-route happen? If I am trying to connect to serverA.com, and your registered domain is fakeserver.com (with a valid certificate issues by trusted CA), how can you can do a MITM if you are fakeserver.com and I am connceting to serverA.com? Commented Mar 18 at 10:38
-
4traffic re-routing is a different topic and there are various ways. I may control any point in a route between client and server (I'm controlling one of routers). Or I can control the traffic between your client and DNS, so when your client queries IP for serverA.com, I return IP of my fakeserver.com. You have no control over public networks, and anyone who does can establish a successful MiTM against your application. ISP is the most obvious example.– Crypt32Commented Mar 18 at 10:50
-
DNS spoofing and ARP spoofing (or "poisoning") are the most common means of gaining a MitM position if you don't already have one, and they are easy if you're on the same network as the victim. There are other options (and of course entities like ISPs that are already in a MitM position) but I must stress that these are the easy options. Commented Mar 19 at 6:25
-
If the Java is running on a phone, remember that there are fake cell towers: sometimes run by police; sometimes run out of embassies; conceivably others, too. Commented Mar 22 at 16:02
While Crypt32 already listed the steps for a possible attack, I think it's important to stress that TLS without hostname verification is equivalent to not checking the certificate at all and therefore useless -- unless you make the unrealistic assumption that you'll only ever deal with completely passive attackers which capture the network traffic but never interfere with the communication.
Obtaining a domain certificate from a trusted CA and can be done in a matter of seconds, sometimes even for free. So this is obviously not a challenge for attackers. If the client still accepts arbitrary hostnames, then you might as well drop certificate validation altogether and let the client trust any certificate they get. This is clearly a bad idea, because an active attacker could present their own certificate and make the client use an encryption key known to the attacker, rendering the encryption useless.
Then you question whether man-in-the-middle attacks are possible at all. First off, the whole point of TLS is to prevent those attacks. If you assume they never happen, you might as well ditch TLS altogether. Again, this would be a bad idea. Depending on how exactly client and server connect to each other, there are plenty of devices and services involved in this connection: modems, wi-fi access points, cellular towers, switches, routers, DNS servers, proxy servers etc. If just one of them gets compromised or abused, a man-in-the-middle attack is potentially possible -- note this doesn't necessarily require rerouting the traffic. The actors which might be interested in doing that range from criminals to legitimate businesses like Comcast.
-
Very clear thank you. But one line that I didn't understand: "This is clearly a bad idea, because an active attacker could present their own certificate and make the client use an encryption key known to the attacker, rendering the encryption useless." can you please elaborate ? What do you mean by making the client use an encryption key known to the attacker? In my understanding to the attack in my case, the attacker is acting as a TLS endpoint and thus will receive the data and it will be decrypted when it is received( noting that it is encrypted in transit between client and attacker) Commented Mar 19 at 8:05
-
If the client accepts a certificate from a man-in-the-middle attacker, then the attacker (instead of the legitimate server) will participate in the TLS handshake, posing as the server. During this handshake, both parties agree on the key for encrypting the traffic, so the attacker can trick the client into using a key which the attacker knows. This makes the encryption useless, because the attacker can read all (sensitive) data which the client is trying to send to the server. Of course what should happen is that the client and server agree on a key and protect the traffic from the attacker.– Ja1024Commented Mar 19 at 9:03
-
OP, what
'Ja' . str(2^10)describes here is a classic 'man in the middle' attack. See en.wikipedia.org/wiki/Man-in-the-middle_attack for some interesting reading on how this attack works, and why proper certificate authentication is vital for mitigating this type of attack.– mti2935Commented Mar 19 at 14:29