Posted on

TLS used in web browsers is vulnerable to cookie grabbing

I heard something really worrying yesterday – someone’s got a proof-of-concept that defeats TLS (previously known as SSL) encryption. Security researchers Thai Duong and Juliano Rizzo are planning to demonstrate this at Ekoparty in Argentina this week.

Fortunately this isn’t as bad as it sounds as it doesn’t actually involve breaking TLS, but it’s still pretty bad. It only applies to some web browsers, but it does allow the theft of supposedly encrypted login cookies and it seems to me a very practical method, although details aren’t officially published as yet. Basically, it involves putting some Javascript on a web site which causes the browser to fetch something from the site being targeted – say Paypal. The browser sends the request, encrypted along with the login cookie – compressed and then encrypted using TLS. You can’t read what’s in the TLS packets, but you can see how long they are.

Fundamentally, compression works by removing repeated information found in the uncompressed data. Therefore if you have repetition, the data compresses better. By making a number of requests for differing data (like bogus image file names) you’ll know by the size of the compressed packet if data in the unknown login cookie contains data repeated in the file requested simply because the combined encrypted packet will get shorter. In other words, because the unknown cookie and known file request are compressed into the same packet, you can determine whether there is any repetition simply by comparing the size of the compressed data – when it gets shorter you’ve got a match. Apparently you need make as few a six bogus requests for each letter in the login cookie to work out its contents.

You obviously need to be eavesdropping on the line, and your victim must be running your Javascript on their browser, but as TLS is there to prevent eavesdropping then this is a serious failure. It’s not the fault of TLS, but that of browser protocol writers, hoping that implementing TLS gives them security without further consideration.

Some people have suggested that this attack would be difficult to implement in practice, but I disagree. Why not simply hijack the DNS at an Internet Cafe (with a fake DCHP server) and force everyone to run the Javascript from the first web site they tried to open, and either snoop the WiFi or sniff the packets off the wire using traditional methods of circumventing switches.

Apparently this flaw doesn’t affect IE, but the others were vulnerable until tipped off about it. Make sure you’re running a current version

Posted on

Certificate “Errors” on Internet Explorer 9 – and how to stop them

Like recent versions of Internet Explorer, Version 9 has a Microsoft-style way of handling SSL certificates. It won’t let lusers access anything over a secure connection if there’s anything wrong with the certificate the remote end has presented. On the face of it, this is all very reasonable, as you don’t want the lusers being tricked by nasty criminals. But in reality it’s not as simple as that.

A bit of background, because everyone should make an informed choice about this…

SSL (or TLS) has two purposes – authentication and encryption. When you send data over SSL then two things occur. Firstly it’s only readable by the receiving computer (i.e. it’s encrypted), and secondly you know you’re talking to the right server (the link is authenticated – both computers recognise each other). The computers don’t exactly exchange passwords, but they have a way of recognising each other’s SSL certificate. Put simply, if two computers need to talk they have a copy of each other’s certificate stored on their disk  and they use to make sure they’re not talking to an impostor (gross over-simplification, but it’s a paradigm that works). Should one computer not have the certificate needed to authenticate the other end it will be supplied, and this is supplied certificate is checked to see if its “signed” by an “signing authority” using a certificate it does already have has. In other words, the unknown remote certificate arrives and the computer checks with a “signing authority” certificate to see if it’s been signed, and is therefore to be trusted. If it’s okay, it’s stored and used.

Now here’s where it breaks in Microsoft-land: For your computer’s certificate (the one it sends) to be signed by a “signing authority”, money has to change hands. Quite a lot of money, in fact. If it’s not signed, the recipient will have no way of knowing it’s really you.

In the rest of the world (where SSL came from), on receipt of an unknown certificate,  you’d see a message saying that the remote computer says it can be recognised using the supplied certificate, but I’ve never seen it before: Do we trust it? In most cases the answer would be “yes” and the two computers become known to each other on subsequent connections. It’s okay to do this – it’s normal. Something like this happens on Windows with Firefox and other browsers, but not, apparently, Internet Explorer. Not until you did a bit deeper, anyway. Actually, Internet Explorer 9 can be made to recognise unsigned security certificates, and here’s how.

First off, we really need to know what we’re about to do. What are the symptoms? The address bar goes red and you get a page saying there’s a problem with the certificate every time you visit a “site”. You can click on something to proceed anyway, but the implication is that you’re heading for your doom. The “error” message you see is normally for one of three reasons, and reading it might be enlightening. On a bad day you might get all three! But taking them in turn:

“The security certificate presented by this website was not issued by a trusted certificate authority.”

This just means that no one has paid to have this certificate signed by anyone of Microsoft’s liking. It may be a private company-wide certificate, or that belonging to a piece of network equipment such as a router. If it’s a web site belonging to your bank or an on-line shop, then you should be worried! Otherwise, if there’s a reason why someone isn’t paying to have their certificate approved (indirectly) by Microsoft, make your own decision as to whether you trust it.

Please generate and paste your ad code here. If left empty, the ad location will be highlighted on your blog pages with a reminder to enter your code. Mid-Post

So how do you get around it? Actually it’s pretty simple but Microsoft aren’t giving out any clues! The trick is to run Internet Explorer as Administrator (not just when logged in as Administrator).  In current versions of Windows you do this by right-clicking on IE in the start menu and selecting “Run as Administrator” from the pop-up menu. If you don’t, the following won’t work.

Go to the site who’s certificate you wish to import, and proceed to view the site in spite of the warnings. Then in the address bar you’ll see “Certificate error”. Click on this and you’ll see an option to “View Certificate”, and (assuming you’re in Administrator mode) there’s be a button the “General” tab to “Install Certificate”. Follow the prompts. For maximum effectiveness(!) choose the option to “Place all certificates in…” and browse to the “Trusted Root Certification Authorities”. This probably isn’t necessary in most cases, but if you do this it’ll cover you for pretty much every use. Your PC will happily accept anything from the remote machine hereafter; so make sure you’re importing the right certificate!

“The security certificate presented by this website has expired or is not yet valid.”

This means the certificate is out-of-date, or exceptionally, too new. In most cases encountering a certificate that isn’t valid suggests that your computer’s clock has reset itself to 1980. If this sounds plausible, just proceed to use the certificate anyway (there’s a clear option on the screen to do this). You’ll still get a scary red address bar, then it’s up to the server operator to fix this, but before you get on the ‘phone and give them what for, make sure you’re computer’s idea of the time and date is actually correct.

“The security certificate presented by this website was issued for a different website’s address”

This third case is a bit more tricky. Basically the name of the computer is embedded into the certificate, but you might be referring to it by another name (i.e. an alias). Or it could be using a pinched certificate. If you’re talking to a network router like a Draytek 2820 by going to its IP address and it’s giving you a built-in certificate, it would have no way of knowing what name or address the router is ultimately going end up on. The certificate is bound to be wrong in this respect. However, fishing around in the Internet Explorer options, under Advanced (and right down near the bottom) there’s a check-box – “Warn about certificate name mismatches”. Un-check it and it’ll stop squawking. Unfortunately it’s either on or off; you can’t set it to ignore a mis-match for particular names only. Because of the risk that someone might be impersonating your bank, you’d probably be best to leave this one checked and put up with the red warnings.

Final word of warning

Some people reading this will reckon this advice is reckless. Why circumvent a security feature? Simple – if the authentication part of SSL isn’t working you still want it for the encryption. In an ideal world everyone would have signed certificates so you can verify everything you talk and know it’s what it claims to be the first time you meet it. Subsequent visits will be authenticated with your newly installed certificate, so if something turns up impersonating it alter it’ll be detected. In the real world you probably want your data encrypted regardless. A signed certificate is better, but not that much better.

Hassling everyone over security certificates, as Microsoft is doing, may be justifiable on some levels, but as far as I’m concerned, anything that makes the use of encrypted data paths more difficult or expensive to use than they need be is a bad thing. They’re throwing the baby out with the bathwater.