Skip to content

All about TLS-encrypted spam: Part II

By Ken Simpson | 2 minute read

By 1943, Bombes began arriving at the Navys Nebraska Avenue Communications Annex at a rate of four per week. The WAVES in Dayton began transferring with the machines and were trained to operate the Bombes. By the end of the war, 121 Bobles ran 24 hours per day, searching for Enigma rotor settings. The machines could search 456,976 setting in 20 minutes.

Last week I blogged about the recent surprising rise in the volume of TLS-encrypted spam sent by botnets (primarily the Rustock botnet). This week I’d like to discuss some of the problems caused by TLS-encrypted spam – for both receivers of email, and for service providers whose customers have the ability to send on port 25.

For receivers: More encryption means higher load, and that’s about all

Probably the most noticeable effect on email receivers caused by an increase in encryption of spam will be higher than normal load on external mail gateways. Decryption of TLS-encrypted SMTP sessions eats up a great deal more CPU than receiving email over a non-encrypted session. There are reports (although I can’t provide sources due to confidentiality requirements) of the increased load from TLS-encrypted spam causing major disruptions within some of the largest email receiving entities.

As more spam bots take advantage of TLS encryption, we fully expect that the load issues seen by the largest receivers will spread to large enterprise installations and university campuses. But small receivers will see no noticeable impact even if 100% of spam is encrypted.

For sending networks: Can’t stop what you can’t see

Sending networks are even more helpless in the face of TLS-encrypted spam – at least when it comes to stopping spam from leaking out of their networks and doing the “right thing” for the rest of the Internet. TLS ensures that sending networks cannot look at the content of spam messages as they exit the network, unless the sending network wishes to “break” the SSL encryption by responding to connections with a certificate that senders will find does not match the intended receiving domain. If sending networks can’t inspect messages to look for spam, then they can’t stop the spam from going out.

What to do about TLS-encrypted spam?

In my next post, I will postulate on a few potential counter attacks to TLS-encrypted spam – for both sending networks and receivers. Until then, please write to let us know what you’re seeing out there.

Cut your support tickets and make customers happier