Enforcing Email Security with TLS when Communicating with Banks

LuxSci has had many requests from clients who have to communicate with various banks and other security-conscious organizations asking that LuxSci “enforce the encryption of email when sent to those organizations’  email servers via TLS”.  This is such a common request, that I wanted to explain what it means, why it is good, how LuxSci does this by default, and the extra step that LuxSci can take to lock down things even more for you.

What is TLS encryption for email and why is it needed?

In this context, SMTP TLS (which stands for “Transport Layer Security“) is a way that email servers, when talking to each other so that one can send [transport to] the other your email message, can encrypt the complete message content so that it cannot be eavesdropped upon.  This means that no one listening to Internet traffic between the sending server at LuxSci and the recipient server at the bank (or vice versa) could see what is in the message.

Most email servers do not support TLS email encryption, though more and more are starting to enable it.  Why don’t they support it?  Because it requires buying and installing special certificates, configuring the server in a not-out-of-the-box fashion, and it takes more effort by the email servers to process the encryption.

Many bank and other organizations with tight security policies actually require that all companies doing business with them always use such encryption to protect email communications between them.  In a sense, it is like building a tunnel between the two companies through which the email flows and into which no outsider can peer.

In general, TLS encryption for email is an extremely good idea as it goes a long way towards protecting people from identity theft, and other kinds of security problems.  If it is coupled with enforced use of TLS or SSL (How do SSL and TLS work?) when you connect to your email server to check or send email (over POP, IMAP, SMTP, and/or WebMail), then all of  your message data and login credentials are really protected quite well.

LuxSci does TLS automatically

Every email server either supports TLS or does not … and they advertise this in a way that other servers can easily see/discover.

Inbound Email: All of LuxSci’s email servers (including all of those used for email filtering) support TLS for inbound email … so anyone sending an email to a LuxSci user can employ TLS if the sending side supports it and decides to use it.  All banks and other organizations that have strict security policies will automatically use TLS encryption when communicating with any other server that supports it.

Outbound Email: All our LuxSci’s email servers will automatically encrypt email when they are talking to another email server that says it supports TLS.  In fact, if something goes wrong because the recipient server’s TLS is not configured properly (it happens), LuxSci will NOT send the message until the issue is fixed (or we provide an exemption for that particular server).  This means that LuxSci will ALWAYS send email securely  to servers that support secure email, and that includes banks and other organizations with strict security policies.

What all this means for a LuxSci user is that email traffic to and from other places that support email encryption will always be encrypted no matter what.  This all happens behind the scenes for all LuxSci users — there is nothing to configure or order or setup.  It just happens, as it should.

Taking things a step further?

So, what else could the high-security organizations ask for?  We find that they often ask us to “enforce” encryption to their domains.  This means that if, for some reason, their email server becomes misconfigured and no longer says that it supports encryption … that LuxSci will refrain from saying … “ok, then let’s talk insecurely” … as it normally would.

For organizations who want LuxSci to refrain from sending any insecure messages to their servers under any conditions, LuxSci can easily enact a global policy for their domains.  All we require is a request by the organization in question to enable this higher level of security enforcement.  Why?  Because if any of their servers then or in the future fail to support encryption, then some or all email from LuxSci will not make it to them.  This has to be their choice.

And another step further?

Of course, TLS encryption is great, and combined with SSL or TLS when checking and sending your email from your computer it does wonders for security.  However, it is not the best you can do.  For example:

• It doesn’t protect messages sent to people whose email servers do not support encryption
• It does not enforce any kind of security on the recipients once the email is delivered to their servers
• It does not ensure that the messages cannot be read by unauthorized people
• it does not protect the content of the messages when stored on email servers or in backups

These are just a few of the obvious issues (for a more complete discussion, see The Case for Secure Email).

What can be done?  You could use an email encryption solution that either:

1. Encrypts the message content before sending and which requires the recipient to decrypt it to read it.  PGP and S/MIME are the most common technologies for this, and they are or can be integrated into most email clients, or

2. The email can be saved in a secure database where the recipient can pick it up securely after verifying his/her identity.

LuxSci’s SecureLine service provides users with both of these options, which can be used as needed for any or all recipients.  LuxSci also makes it easy to lock down your account with maximal security settings — like forced use of SSL, strong passwords, etc.