Ben Laurie blathering

Turn-based Protocols Somewhat Safe

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.


  1. Wietse says “most SMTP clients don’t verify server certificates”.

    There are actually two cases to consider: server-to-server SMTP, and message submission.

    The server-to-server case is a complete disaster area. Most MXs that offer STARTTLS have invalid certificates, so outgoing SMTP servers cannot in practice verify server certificates. Even if the MXs had valid certificates they are not securely tied to application-level identities: the certificate verifies the MX’s hostname, not its mail domain. An on-path attacker can spoof the results of the sender’s DNS MX lookup to redirect their email without triggering TLS certificate verification errors. The current vulnerability provides no benefits to the attacker.

    The situation for message submission is much more cheerful. Server certificates are usually valid. Clients are configured with the server host name that appears in the certificate – no MX record indirection that makes certificate verification pointless in the server-to-server case. Many clients are configured to verify the server’s identity (though MUAs make it far too easy for users to set the “ignore man-in-the-middle attacks” option). So does the current vulnerability let the attacker do anything useful?

    In SMTP message submission, and in POP and IMAP and XMPP, the first traffic after TLS negotiation is a multi-round client authentication exchange. I don’t see how an attacker gets any benefit from performing a blind prefix injection attack in this situation. So I think these client-server protocols are essentially safe wrt this vulnerability.

    Wietse also fails to mention that the first SMTP command after STARTTLS must be EHLO, and that this is a pipelining synchronization point. Servers that check these requirements properly are safe, and you don’t have to look at tricky cross-layer framing and reassembly behaviour to see this.

    Comment by Tony Finch — 11 Nov 2009 @ 0:50

  2. 0.9.8m is perfect for openvpn (which renegotiates hourly) in my case, could I get a copy please?

    Comment by krzee — 11 Nov 2009 @ 10:00

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress