They end up biting you in the butt. Matt Green’s post is a nice explanation of the FREAK exploit. You can read his post for the technical details, which, really, aren’t that interesting except that they show how making it easy for governments to defeat crypto systems will inevitably end badly.
Back in the 90’s the U.S. government classified crypto systems as munitions and prohibited their export. It was entirely unworkable, of course1. Foreigners wishing to download crypto-enabled applications easily skirted the simple checks used to verify they were in the U.S. and domestic companies moved their crypto development off shore and imported the results—the government had no problem with importing crypto. Nevertheless it was illegal to export systems with an effective key length greater than 40 bits2.
That meant that browser makers had to use weak SSL encryption for exported browsers. To handle those browsers, servers could negotiate with their clients to use the weaker encryption if necessary. Eventually, even the government saw the futility of trying to control software-based encryption and relented. The weak encryption option was forgotten and everyone assumed it was just a slightly silly piece of history.
Sadly, lots of servers having the option are still around (36.7% of servers still support it according to a recent scan) and that’s what the FREAK exploit uses in its man-in-the-middle attack. It sits in the middle and negotiates the weak encryption. It’s a bit more complicated but only a bit. Again, see Green’s post for the details.
The point is that this exploit is possible only because the government insisted on a backdoor years ago. Such things always fall victim to the law of unintended consequences and that’s something we should remember when some nosy Parker comes along insisting that the government needs a window into our communications.
Footnotes:
Phil Zimmermann, the author of PGP, famously avoided the export restrictions by publishing the source code as a dead tree book, which enjoyed first amendment protections.
For browsers, this implies an RSA key of 512 bits. Numbers that size are easily factorable in a few hours and since the keys are often reused for the life of a server invocation, represent very little security.