Thanks to Thierry Zoller for mentioning me in the FTP section of his whitepaper summary of the TLS renegotiation attacks on various protocols. I’m glad he also spells my name right – you’d be surprised how many people get that wrong, although I’m sure Thierry gets his own share of people unable to spell his name.
The whitepaper itself contains some really nice and simple documentation of the SSL MITM renegotiation attack, and how it works. It’s well worth reading if you’re looking for some insight into how this works.
First, though, a couple of corrections to Thierry’s summary – while he’s working on revising his whitepaper, I’ll post them here:
I think that where FTPS has problems that are thrown into sharp relief with the SSL MITM renegotiation attacks I’ve been discussing for a while now, it has had those problems before. If an attacker can monitor and modify the FTP control channel (because the client requested CCC and the server allowed it), the attacker can easily upload whatever data they like in place of the client’s bona fide upload.
The renegotiation attack simply makes it easier for the attacker to hide the attack. It’s the use of CCC which facilitates the MITM attack, far more than the renegotiation does.
To address one further comment I’ve heard with regard to SSL MITM attacks, I hear “yeah, but getting to be a man-in-the-middle is so difficult anyway, that even a really simple attack is unlikely”. That’s a true comment – for the most part, there is little chance of a man-in-the-middle attack occurring on the general Internet in a bulk situation. The ‘last mile’ of home wireless, coffee bars and other public wireless hangouts, or the possibility of DNS hijacking, HOSTS file editing, broadband router hacking, or just plain viruses and worms, are the place where most man-in-the-middle entry points exist.
However, if you’re going to assert that it’s truly unlikely that an attacker can insert himself into your network stream, you basically have no reason whatever to use SSL / TLS – without a potential for that interception and modification of your traffic, there’s really no need to authenticate it, encrypt it, or monitor its integrity along the path.
The fact that a protocol or application uses SSL /TLS means that it tacitly assumes the existence of a man in the middle. If SSL / TLS allows a man-in-the-middle attack at all, it fails in its basic raison d’etre.
Next post, I promise something other than SSL renegotiation attacks.