- S1: The site or MiTM adversary presents an invalid, self-signed certificate;
- S2 – not an attack, but still incorrect implementation: The site or adversary presents an expired certificate.
- S3: The site or adversary presents a certificate with a wrong Common Name (CN) and/or SubjectAltName, signed by a root CA.
It is trivial to check case S1. Configure application to use Fiddler as a proxy, but do not trust Fiddler Root Certificate
.
Now open the application in test (let’s imagine it is a PayPal client for Android), get it to use Fiddler as a proxy and try to run it.
If it works (highly improbable in our days), then SSL chain of trust is broken and the client does not check whether the certificate is signed by a trusted Certificate Authority.
S2 - Expired certificates case is slightly trickier.
Probably the simplest thing to do would be to use the app so that Fiddler creates the certificate, then, without closing the app, change the local system clock to three years in the future.
Alternatively, if you're using the CertEnroll generator, you can type
prefs set fiddler.certmaker.ValidDays -364
in the QuickExec box so that the certificates generated expire nearly a year before the current date.
If you do that, don't forget to remove the preference and use the "Remove Interception Certificates" Action in the HTTPS tab to remove the "bad" certificates after you're done testing (or everything else will break too!)
This is how the browser (Google Chrome) reacts on this type of SSL errors:
Make sure
that our PayPal client does not work either!
And last, but not least, let’s check S3 case – how the application in test would react to a certificate with a wrong Common Name (CN)
To do that, open Fiddler.
Click Rules > Customize Rules. Scroll to OnBeforeRequest.
Inside that function, add the following:
if (oSession.HTTPMethodIs("CONNECT") &&
oSession.HostnameIs("paypal.com"))
{
oSession["X-OverrideCertCN"] = "badhostname.com";
}
Save the file and restart the client if it had previously established any connections to https:// paypal.com.
It is recommended to ignore server certificate error in Fiddler – otherwise it will nag us with the SSL error, the script in the Fiddler itself caused:
Take a look
how unhappy the browser is!
Now open the testing applications and see how it would behave!
If it works correctly, there is a chance, that the developers found this brilliant piece of code in the Internet and put it in the program carelessly:
static class myHostnameVerifier implements HostnameVerifier {
public boolean verify(String hostname, SSLSession session) {
return true;
}
}
If the application successfully passed these simple checks, rest safe and assured: only Kazakhstan government is able to sniff your traffic!