Postfix
work-in-progressEarly November 2009 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. The initial discussions were focused on the impact on HTTP applications.
While looking at the impact of this for SMTP mail, Wietse 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
This writeup comes with a little tutorial on SMTP over TLS, and on TLS renegotiation attacks.
The impact of TLS-based attacks on SMTP 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, including Postfix, will not detect the SMTP-level after-effects from a TLS renegotiation attack. Victor and Wietse 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.
Postscreen is the code name for a new daemon that sits in front of Postfix and that does connection-level filtering. The program is currently part of the Postfix 2.7 experimental release.
The major goals of the program are:
Keep the zombies away from the Postfix SMTP server. According to the 2008 annual report by MessageLabs, 81% of all email was spam, and 90% of spam was sent by botnets.
Improve Postfix scalability by moving potentially time-consuming operations such as DNS blocklist lookups and SMTP protocol checks out of the SMTP server.
Early results for seven days of spam were presented at the 2009 Mailserver conference in Berlin:
Anomalies in spammer SMTP client implementations. Spammers are in a hurry to send spam, and therefore they cut corners in the SMTP protocol. Postscreen currently detects SMTP clients that start talking too early (pregreeters). As spammers become smarter, Postscreen will need to examine more aspects of client SMTP behavior. This will build on the dummy SMTP protocol engine that already exists in the smtp-sink stress-test program.
Parallel lookups from several popular DNS blocklists, and the relative proportions of client IP addresses that each list flagged as spam.
Geolocation and time-of-day patterns for spam connections to servers in Europe and the USA. Geolocation is done off-line, based on logfile analysis.
Data were collected with help by Ralf Hildebrandt. Ralf reported that by dropping all pregreeter connections to one server, he reduced the frequency of the "all server ports busy" condition from several times a day to once a week.
There is a lengthy history of prior work in this field. For example, OpenBSD spamd, MailChannels TrafficControl, and work by Michael Tokarev in the early 2000s.