Technical All about TLS-encrypted spam: Part III By Ken Simpson | 4 minute read In my two previous posts, I wrote about how the Rustock botnet is now sending a great deal of spam via TLS-encrypted connections and the variety of problems this new trend in spamming activity is causing and will cause for the Internet community. I mused that Rustock is probably encrypting spam because this allows its traffic to remain un-inspected by network analysis tools that perform man-in-the-middle analysis of SMTP traffic. In my second post, I discussed some of the problems that encrypted spam is causing for major email receivers, including increased TLS encryption load. In this post, I will cover off a few things that receiving and sending networks can do to reduce the impact and amount of TLS-encrypted spam traversing the Internet. Fortunately, this is one of those spam problems where it’s not only up to the receivers to fix the problem. What can email senders and receivers do to stop TLS-encrypted spam? The only way to stop spammers from using TLS encryption is for the receiving mail server to tell the spambot that it does not support encryption. To understand how this is accomplished, let’s first have a look at how the ESMTP protocol advertises SMTP extension mechanisms, one of which is the STARTTLS command that initiates an encrypted session. Advertising is not always a good idea When an SMTP client (i.e. the machine sending email) issues the EHLO command at the start of an ESMTP connection, the SMTP server responds with a list of extension commands it supports. The SMTP client can then issue any of the commands listed. A typical response might look like the following: 250-ESMTP Server Ready 250-SIZE 0 250-DSN 250-STARTTLS 250 TLS The STARTTLS command listed above allows the SMTP client to issue the command “STARTTLS”, after which a bunch of random looking garbage representing the actual TLS encrypted session is exchanged back and forth across the TCP connection. If the mail server does not list STARTTLS when the EHLO command is issued, then the SMTP client may not send the STARTTLS command. This effectively prevents encryption from happening. Interesting side-note: Most of the major consumer-oriented email receivers of the world do not ever advertise STARTTLS. I tested Hotmail, Gmail, Yahoo!, and AOL and found that none of them support TLS. Microsoft’s Exchange Hosted Services (formerly Frontbridge) does advertise STARTTLS. So does Symantec’s MessageLabs service. These are both enterprise-oriented services whose customers are most certainly more demanding of privacy and security than the typical customer of a consumer-oriented email service like Hotmail. Senders and receivers both play a part Email receivers who are concerned about encryption load can either completely disable TLS-encryption, or can be selective about whom they offer it to. If your email receiving system has a reputation system attached to it, you can implement a policy whereby STARTTLS is only advertised to IP addresses that have established a positive reputation – everyone else has to send in the clear, leaving less decryption burden on your CPUs. Sending networks (e.g. ISPs, hosting companies, university campuses… basically anyone with lots of machines that can send on port 25) can also filter STARTTLS, assuming they have the right technology in place in the network. I don’t usually trumpet MailChannels technology in this blog, but in this case I’m going to go out on a limb and suggest that sending networks consider using a <a href=”/product/outbound.html”>transparent SMTP proxy</a> such as Traffic Control in the outbound path of their port-25 traffic. We – and a few others – can selectively block the STARTTLS response when senders from within the sending network are trying to connect to mail servers to deliver their deadly encrypted payload. Conclusions Incidentally, it seems like Rustock has calmed down w.r.t. sending encrypted spam of late. In the last 24 hours, only a tiny fraction of the connections emanating from our outbound filtering customer networks have been encrypted. Have we seen the end of this experiment or will we see a resurgence in the use of encryption by spammers? Only time will tell.