Wietse Venema has a nice analysis showing how an attack on Postfix doesn’t work. The core point here is that in turn-based protocols the common implementation is such that the server (or client – let’s call it an agent) will consume input from the OpenSSL layer character by character, in effect. This means that OpenSSL in turn will only consume a single SSL packet at a time, in order to provide input to the agent. The agent will then send output before reading further input. That output will be encrypted to the man-in-the-middle, because the OpenSSL layer has not yet processed the packets with the renegotiation in them. The victim will be unable to read the output, so the attacker has no option but to consume it. This means the attacker can execute arbitrary commands before handing over to the victim, but he can only hijack the very first command the victim sends – by sending an incomplete command himself, followed by the renegotiation. This makes it hard to kid the victim into doing anything interesting before something goes awry with the protocol and one end or the other gives up.
This defence only works if the application layer does not greedily consume from the OpenSSL layer – if you read everything OpenSSL has got, then the renegotiate will occur before you start sending responses.
Wietse thinks this means that Postfix can’t be attacked in any interesting way. My experience of making such claims has been unfortunate, so I’ll reserve judgement. My advice is still to upgrade to 0.9.8l if you can (or whatever fix your vendor is offering for this issue). If you need 0.9.8m in a hurry because you need renegotiation and can update both ends, let me know.
However, I rather suspect (but definitely don’t know) this will save many turn-based protocols from severe attacks, though I’m prepared to bet there are interesting corner cases.
Incidentally, Adam Langley pointed out to me that if protocols had included a sentinel character – i.e. a character that could only ever appear at the start of a command, then some attacks against HTTP would fail, and also even the hijacking of the victim’s first command would not be possible in SMTP, though arbitrary prefixing would work, still. Simply numbering the commands sent would fix that, though – and defeat some injection attacks (not that these are currently possible in SSL). These kinds of measures would be interesting defences in depth for future protocols. Keeping a running hash sounds like a better idea to me, though.