In response to the recent Protect the Graph Facebook post about ‘Massive Growth in SMTP STARTTLS Deployment’:
Toyin Adelakun, a VP at Sestus writes:
“STARTTLS offers a transparent and modest improvement upon plaintext Internet application protocols — such as SMTP and POP between e-mail servers — by instructing the initiating server to use TLS encryption by default if the other end supports it. It has obvious upsides in cases where the “if the other end supports it” condition is met. It has downsides, however, as:
The communication — e-mail or other data — is sent unencrypted if both ends cannot agree TLS support; and
worse, with most implementations, the unencrypted communication is sent without explicit notification to the end-user that encryption is not being used. Thus, STARTTLS may lull users into a false sense of security, in terms of the confidentiality of the data sent by their applications.
Nonetheless, users and organisations with privacy concerns will find it laudable that the likes of Facebook (e.g. via STARTTLS) and Google (through its search-ranking rewarding of TLS) are encouraging the widespread use of encryption. “
Richard Cassidy, Senior Solutions Architect at Alert Logic says:
“In the context of E-Mail, Quite simply “STARTTLS” is a mechanism designed to “upgrade” an insecure connection between a mail client and mail server to ensure encryption is used before further data (e-mails) is submitted in a session. Previously if you wanted a secure channel for e-mail transfer between the client and server, you would have to specifically configure the mail client and server to communicate over the encrypted versions of either IMAP, POP3 or SMTP. This scaled ok within corporate organisations but presented a challenge for users of hosted e-mail platforms that simply didn’t understand how to configure their clients to run over the secure versions of their chosen e-mail protocol. I know from experience that many ISP’s attempted to enforce encrypted-only connections for e-mail clients, but ran into all sorts of challenges supporting non-technical users who simply hadn’t a clue how to configure their e-mail client to comply with the ISP’s requirements. In the end they either gave up or the clients choose another provider that didn’t have such stipulations.
With STARTTLS the client to server or server to server connection now ‘automatically' attempts to choose a encryption standard supported by both ends of the connection to transfer subsequent data streams. In terms of user benefit, it’s all about simplicity to attempt to ensure encrypted communication of data between client and server, even if the client configures their e-mail on non-encrypted ports. STARTTLS was designed to bring the intelligence within the protocol and remove the need for the user to do anything other than simply download and read e-mails as they’ve always done from the dawn of e-time.
Will it protect data from hackers and any state led “sniffing” attempts? We’ll that depends on many factors and ultimately cannot be assured, unfortunately. Yes it’s great that protocols are being developed and implemented to ‘attempt’ (being the operative word!) to “automate” better security between client/server and server/server communication channels, but STARTTLS starts out as an unencrypted communication between both ends and relies on both parties “agreeing” to use encryption in the first place; if one end of the conversation doesn’t agree – say in the case of a MITM attack where an attacker strips out the clients STARTTLS negotiation message to use encryption – then naturally the fallback is to unencrypted communication between client/server and thus clear-text download of your e-mail over the internet. Then there’s a host of backward compatibility issues for old e-mail client and server programs, which in summary means that some clients would ignore (because they don’t support) the servers request to use STARTTLS and just send data unencrypted anyway (in most cases username and password for login) over the internet. Granted most clients today now support STARTTLS, but this still doesn’t remove the fact that negotiation may fail for a host of reasons and both sides may default to unencrypted transfers. Furthermore the user - in most cases - isn’t notified that their data is being transferred unencrypted!
STARTTLS is a great attempt to implement security where the client/server may default to unencrypted data transfer, but has the capability to run encryption; this can only be a positive move and I am glad to see many of the main social media services and largest e-mail service providers make a move towards implementing STARTTLS across their services. Is it positive? Absolutely! When it works as expected it works very well indeed, but overall it’s less secure given that it’s a great deal more susceptible to MITM and backward compatibility issues between client/server and server/server.”