There are several different ways for MITM/hacking proxies to handle SSL. They can create a self signed root cert that the attacker/user accepts once, they can do a per site snake oil cert, or they can simply downgrade the attacker/user to HTTP (a la Moxie’s sslstrip). Any of those work, and it’s kind of a matter of preference and circumstance as to which is better. But what if I’m running a site and I want to see if the user coming in is using a hacking proxy? There’s a few techniques to do that.
First of all there’s really not all that much you can do within SSL itself to create more than binary options (there are some exceptions to that rule, and I’ll post about that later) but those binary options are actually just enough. Let’s say I have several sites. One of which is a banking site. The others just have something as simple as a tracking pixel on them. Firstly, the time difference between when the user pulls the SSL certificate and actually instantiates the site might indicate whether they are going directly to the site or if they had to take some time to accept a self signed-per site certificate (a la Burp Suite).
Now if the MITM proxy uses a standard root signing certificate one of those sites with the tracking pixels on them can use the same standard root signing certificate (since it’s sitting right there in the tool and can probably easily be ripped out and re-tasked to be used on the banking’s tracking pixel site) to sign it’s own SSL session. If the user pulls it down anyway, even with the mis-match error, you know they are either using or have used that particular MITM proxy.
Another pixel might be protected by a snake oil SSL certificate. If that image is pulled anyway, despite the mis-match error, there is a good chance they are using something like an sslstrip or something like a root signing authority. Because the image is pulled and it shouldn’t be, you know there must be something off here.
Lastly, you can have another completely valid SSL signed site. If they are using something like Burp Suite it will give them a certificate mismatch error and it won’t pull the image (at least not immediately), even though it should. Although the image may get pulled eventually, as the hacker goes through the annoying manual process of adding the cert in or okaying it, the time frames will be so great compared to pulling images on the same site that it should be obvious that they aren’t an average user.
Of course these techniques have strange effects on certain browsers, like the iPhone Safari browser as I talked about before. But if the user is claiming to be one of the common standard browsers, this technique should work - although I’d test it thoroughly before deploying it.