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.