Secure SMTP email delivery over SSL/TLS
Our online community is full of hard-working hackers and eavesdroppers. So, your e-mails could always be read in transit, if not encrypted. This snooping is easier to do than you think.
Want to know how? Here you go:
Whenever you connect to your mail box through POP or IMAP, your email-password pair is sent as plain text. It means, anyone sharing your wireless connection or able to watch your ISP’s traffic can easily read it. Once read, those cyber criminals can:
- steal your valuable information
- intrude into other connected accounts
- scam you to send money by changing your details
- sent out spam mails from your account to get you blacklisted
There are many other worst cases you can think of. So, you definitely need more secure ways to send/receive emails, don’t you?
Though the S/MIME method is considered more secure as it encrypts even before the SMTP transfer happens, it is avoided by most of the websites and businesses due to the complexity it adds. Therefore, TLS & SSL are considered most optimal.
TLS is used by many new-age mail servers to authenticate and secure the email traffic. It provides a standardized method to encrypt internet traffic at the transport layer.
Why do we Need TLS with SMTP?
SMTP was designed to be a simple mail transfer protocol, which sends plain text over the internet. It is more like sending a postcard. The engineers, who designed it, were more focused to help the e-mail users in communicating through a better medium. They emphasized on real users but neglected the threats and hackers in the process. So, there is always the possibility of eavesdropping or information theft. As banks prefer to use HTTPS over HTTP due to the security it offers, SMTP with TLS is what most businesses and server administrators prefer in the case of e-mail communications.
See how TLS works:
TLS utilizes a handshaking mechanism to establish the connection (See image). The procedure, it follows for setting up connection is:
- Sender 1 initiates conversation.
- Sender 2 to replies with certificate, key exchange and other requested details to prove that it’s the right recipient.
- If the data is verified, sender 1 shares it certificate and key exchange details with changing its cipher specification to start a TLS/SSL connection. Otherwise, an alert is generated.
- Rest communication happens through a secure encrypted channel.
TLS uses a symmetric key for bulk encryption or for the back-to-back sessions so that the communication can happen fast. DES, 3-DES, AES, RC2 and RC4 encryption standards are generally used for this purpose. However, the authentication and information exchange takes place using the asymmetric i.e. public key. RSA (Rivest-Shamir-Adleman) is the most common algorithm, used for this purpose.
Encryption has its own advantages when seen from the security and confidentiality perspective. Such as:
- The message cannot be read during transit.
- Altering the messages while passing through the channel is not possible.
- Injection of extra information is not doable by third-party snoopers.
- No possibility of identity thefts.
Level of Security with TLS
TLS encrypts the content being sent. It implies that the mail content is secure, until the time it is in the transmission channel. However, it does not protect it before sending and after the receipt, unlike PGP or S/MIME. The conclusion is: TLS offers unbreakable transmission security, which is most important. If any mishap happens, it will be due to one of the exchanging parties i.e. either the sender or the receiver.
Configuring TLS with SMTP:
You can configure TLS with SMTP in three ways basically. Note that it is not necessary that every server (or your server) supports TLS. Previously, most of the public and free servers did not support TLS but it’s not like that now. For example, Gmail’s 85%+ mail traffic is e-mail encrypted. It requires configuring the email servers with valid SSL certification to configure them with SMTP TLS.
Disclaimer: If you are using Pepipost Server, we do support TLS 🙂
Now there are two main methods of configuring the server:
1. Opportunistic TLS
Opportunistic TLS is when you are configuring a server with TLS for the SMTP send and receive, without making it a compulsion. If the recipient’s email server is not supporting TLS, it steps down the conventional SMTP and still delivers it.
When to use it?
Using the opportunistic method is good if you have to deal with a wide range of customers, vendors, businesses and more. It is because implementing security, whenever possible, is a better alternative than negotiating it in every case (especially when delivering the message is more important).
2. Forced TLS
This type of TLS configuration refuses to deliver the e-mail if your recipient is not supporting TLS.
When to use it?
It could be used for business-specific confidential data when end-to-end communication is needed. When you are automating the transactional messages and dealing with a variety of customers (who are using diverse mail servers), it is not advisable to use Forced TLS.
How Pepipost implements TLS?
Pepipost delivers emails to ISPs through TLS. When recipient mail server does not support TLS, we do via regular SMTP. In short, we deploy the opportunistic TLS. Pepipost, as an additional security implementation, also injects SSL header via SMTP.
The best part is – most of our traffic passes through TLS, as the number of TLS-enabled servers in increasing day by day. Also, most of the public email clients used by your customers, like Gmail, Outlook and Yahoo supports TLS encryption.
Conclusion: SMTP and TLS or Only SMTP?
It is the right step to pick an ESP which implements secure TLS with SMTP over the conventional e-mail clients. This way, you can stay relaxed that the sent mail is delivering to your customers’ mailbox in a secure manner, whenever possible. Also, the security during transmission is also assured.