0

Scenario: Let's say a MITM was able to plant a faked, self-signed certificate on my client (Android app), instead of the self-signed certificate of my server.

When now my app tries to connect to the server, using:

URL url = new URL("https://www.hardcoded.unchangeable.uri.toserver");
HttpsURLConnection urlConnection = (HttpsURLConnection)url.openConnection();
urlConnection.setSSLSocketFactory(context.getSocketFactory());
urlConnection.connect();
...

Is the MITM able to reroute the request to his server?

If not I'm safe, I would just see a handshake exception, wouldn't I?

1

So we're assuming here that the attacker has a certificate which your device would see as "trusted" and is a position to intercept and modify traffic from your device before it reaches the server.

In that case, at a basic level, it would be likely that they could redirect the client to a server under their control. When your device makes the DNS request to resolve "https://www.hardcoded.unchangeable.uri.toserver" the MITM attacker can intercept that and reply with an IP address under their control.

Your client then starts an HTTPS connection with the attackers server. As the attacker has planted the fake signed certificate on your device (assuming here they've put a trusted root onto the device) they can just sign the certificate on the server that they redirect the client to with that root and your device will see it as "trusted".

The best way to mitigate this attack is to have your application make use of "certificate pinning" where it will only trust specific certificates, as opposed to trusting any certificate with the correct host name, which has been signed by a trusted root cerftificate which is installed on the device.

4
  • With "correct host name" you mean the common name wrote into the certificate and which is www.hardcoded.unchangeable.uri.toserver? And the attacker is able to pretend being this host? In my case I am pinning the cert, unfortunately I would also pin the fake cert. – DividedBy0 Apr 2 '16 at 19:12
  • if the attacker has a Certificate Authority installed on the device then they can create certificates on the device with any name they like, which the device will trust. The key to pinning is that you're not pinning the name, you're pinning a specific certificate. The attacker isn't able to recreate that, therefore can't bypass the pinning. This doc. owasp.org/index.php/Certificate_and_Public_Key_Pinning#Android from OWASP may help to explain the concept. – Rory McCune Apr 2 '16 at 20:06
  • So the pinning can take place only on the android phone itself and there is always a risk using a self-signed certificate, unless it is already preinstalled on the phone? As soon it is downloaded there is no guarantee that it could be intercepted and faked? – DividedBy0 Apr 3 '16 at 10:33
  • And as follow up, when I got such a trustworthy preinstalled and pinned certificate on the phone, marked as trust anchor, when I need to change the cert, I could build up a chain based upon it and so ensure that the new certificate can't get faked? – DividedBy0 Apr 3 '16 at 10:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.