Vulnerabilities in STARTTLS implementations
Vulnerabilities in implementations of the STARTTLS protocol for establishing an encrypted TLS connection could allow commands to be injected into a connection. According to a description by the discoverer of the problem, Postfix developer Wietse Venema, the key point is that commands are injected into the connection before it has been secured/encrypted, but are only executed once the secure connection has been established.
Venema illustrates the problem with an example involving securing SMTP with TLS. A client sends "STARTTLS\r\n"; using a man-in-the-middle attack an attacker changes this to "STARTTLS\r\nRSET\r\n". The client and server then establish a TLS connection. The server now regards the injected RSET command that was added during the unprotected phase as if it has been transferred subsequent to the TLS connection being established. The RSET command in this example is relatively innocuous as it is a harmless protocol reset command, but other commands could be injected in a similar fashion.
According to Venema, injected commands could be used to read email or discover user names and passwords. This in principle works for all protocols which use TLS in which a connection switches from being insecure to being secure – e.g. POP3, IMAP, NMTP and FTP. Not all STARTTLS implementations are vulnerable. According to a US-CERT list, IPswitch products, Kerio, Postfix, Qmail, Sun and SCO are all affected. The situation is unclear for many vendors and products. For Postfix, the problem is fixed in versions 2.7.3, 2.6.9, 2.5.12 and 2.4.16.
Venema notes that many implementations are vulnerable to man-in-the-middle attacks anyway, because, although they establish a secure connection, the validity of the server certificate is not established or is insufficiently checked.