= Postfix/Impact_of_SSL_renegotiation_attacks_on_SMTP_mail = From http://archives.neohapsis.com/archives/postfix/2009-11/0252.html <> ---- == Wietse == Last week there was big news about a security hole in the TLS protocol that allows a man-in-the-middle to prepend data to a fully-secure TLS session. That is, the server certificate verifies, and therefore no-one can read or modify the network traffic. Or so we thought. * http://www.ietf.org/mail-archive/web/tls/current/msg03928.html * http://www.ietf.org/mail-archive/web/tls/current/msg03942.html This hole was already known and a consortium of industry partners was already working on solutions. Meanwhile, a draft proposal has been published for a TLS protocol change. While looking at the possible impact for SMTP mail, I came up with an attack that redirects and modifies SMTP mail that is sent over a fully-secure TLS connection; Victor came up with an attack that changes the first command in a TLS session. You can find a preliminary analysis at: * http://www.porcupine.org/postfix-mirror/smtp-renegotiate.pdf It comes with a little tutorial on SMTP over TLS, and on TLS renegotiation attacks. The impact of all this should not be over-stated. Presently, most SMTP clients don't verify the TLS certificates of SMTP servers. Such clients are already vulnerable to ordinary man-in-the-middle attacks, and TLS renegotiation introduces no new threats for them. The Postfix SMTP server with OpenSSL is not affected by the TLS renegotiation attack that redirects and modifies SMTP mail, due to accidental details of the Postfix and OpenSSL implementations. Other SMTP server implementations may be affected (my report describes some of the requirements). There may of course be other attacks that I wasn't aware of when I wrote the analysis. Most SMTP client implementations will not detect that a TLS renegotiation attack has happened, including the Postfix SMTP client. Victor and I have looked into a number of workarounds that can be implemented in the SMTP client, pending a bugfix in the TLS protocol and in TLS implementations. Some of these workarounds may end up in Postfix. == Dude == Thank you both gentlemen for your hard work on this. I've got possibly lame question. I assume STARTTLS is affected, but is also 'wrapper mode' vulnerable to this attack? I mean the mode in which client and server immediately estabilish encrypted channel, before issuing any SMTP command. == Wietse == It was left as an exercise for the reader. 1. At the top of the attack diagram, delete the plaintext phase (the "SMTP 220 welcome", "SMTP hello" and "SMTP starttls" command and reply boxes). 1. Insert "SMTP 220 welcome" as the first server response after the renegotiation TLS handshake. This attack works when the server's TLS engine renegotiates the session before it encrypts the server's "SMTP 220 welcome". In the Postfix SMTP server, wrappermode would not be affected for the same reason that Postfix SMTP server STARTTLS is not affected. Also, the same SMTP client defenses apply for detecting server replies that are sent too soon.