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. Wietse
