A few users have asked why our servers would continue to support older encryption technology such as RC4, for example. In this help article we answer the question.
Firstly: It is incorrect to say that we generally support older encryption technology. Rather, we only do so in a particular, exceptional case – for communication with poorly-maintained email systems, with which otherwise only unencrypted communication could occur. In this case, a weakly-encrypted connection is preferable to a completely unencrypted connection.
In all other contexts we do not use older encryption technology such as RC4.
In client-to-server communication, such as communication with our users (retrieving emails with IMAP or POP3, submitting emails with SMTP, the website and webmail interface with HTTPS) we therefore always exclusively use the newest and most secure encryption methods. This is integrated with perfect forward secrecy. Old and insecure methods such as RC4 and plain text transfer are not supported. This can be verified on the independent Qualys test site, for example. If someone is claiming that the Posteo servers use RC4 and other outdated technology here, this does not reflect the reality.
Contact with outdated email servers
With server-to-server communication it is a completely different story. Here, it’s about communication between the Posteo email servers and other providers’ email servers. Some of these email servers are, from a technical perspective, maintained so poorly that they only offer outdated encryption protocols for communication.
Purely for these exceptional cases, we have some outdated ciphers such as RC4 available to our receiving and sending servers (MX servers). Otherwise, only unencrypted communication would be possible with such outdated systems, which would be a lot more insecure.
The best possible encryption is always negotiated
Sending and receiving emails works with the so-called “opportunistic” encryption method, STARTTLS. Here, emails servers negotiate with each other whether they can communicate with one another using encryption – and if so, with which strength of encryption. The servers always agree on the highest strength of encryption that both servers support. The best possible encryption is therefore always negotiated. If the servers can not find an encryption protocol that both simultaneously support, it is agreed that the email will be transferred unencrypted. This is a principle in the worldwide transfer of emails between servers. If we were no longer to implement older encryption protocols on an interim basis, the worst case scenario would occur in an email exchange with older email servers: The data would be transferred via an unencrypted connection and unauthorised parties could eavesdrop on the cables without issue, and without having to undertake an attack on the connection.
All those who criticise that specific encryption protocols are a means of attack should consider this. In terms of encryption with STARTTLS and older systems, there are only two possibilities – either an encryption that could be attacked, or an unencrypted transfer in plain text.
For this reason, as a rule, providers very cautiously consider when an outdated protocol for the exchange of emails via STARTTLS is to be permanently removed from the encryption offering. In the interest of our users, we can currently not yet take responsibility for removing RC4 for STARTTLS from the offering. There are still too many poorly-maintained email systems and switching it off would promptly lead to more than half a million unencrypted connections per year, which can until now still be encrypted with a lower level of encryption. We continually evaluate our encryption procedure and remove older processes from our email servers’ offering if they are no longer relevant for the use of STARTTLS between emails servers.
Such decisions have a lot to do with responsibility. Reverting from an encrypted connection to unencrypted plain text is the worst of all options. We therefore also offer our users a TLS-sending guarantee, which guarantees to prevent sending an email in the event of reversion to an unencrypted connection.
Our deliberate approach here completely conforms with the recommendations of the IETF (Internet Engeneering Task Force). In chapter 5.2 of the email standard document RFC 7525 “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”, it specifically allows maintaining older encryption technologies for opportunistic encryption methods in order to prevent unencrypted plain text transfer: “(…) some of the recommendations in this document might be too strict, since adhering to them could cause fallback to cleartext, a worse outcome than using TLS with an outdated protocol version or cipher suite.”
The IETF is therefore aware that STARTTLS is a special case. In other contexts, on the other hand, it, like Posteo, categorically refuses the use of older technology such as RC4 – even prohibiting it. If someone states online that we do not comply with this prohibition, this is a false assumption. The prohibition in RFC 7465 “Prohibiting RC4 Cipher Suites” explicitly does not refer to email exchange with STARTTLS, but rather, sensibly, to encryption between TLS client and TLS server. In this area, we do not use outdated protocols. Posteo conforms to the standards. If someone claims that the prohibition is general, they have not bothered reading the abstract of RFC 7465. There, it is specified which standards the prohibition applies to, which RFCs the prohibition concerns. It states, “This document updates RFCs 5246, 4346, and 2246.” The RFCs referenced here do not refer to opportunistic encryption with STARTTLS, but rather to forced TLS encryption with HTTPS, for example. This is a small but important detail that is sometimes overlook in heated debates online.
Guaranteed security with DANE and Posteo’s TLS-sending guarantee
DANE was developed, among other things, to improve STARTTLS between email servers, to guarantee encryption and to authenticate. Our TLS-sending guarantee also allows you to prevent plain text transfer – as with DANE – if no encryption can be established. Outgoing email communication with DANE and the TLS-sending guarantee is therefore strongly configured as per TLS guidelines, so that better encryption comes about. In addition, DANE offers active protection against man-in-the-middle attacks.
If you are the operator of an email server, we therefore urgently advise you to make sure that the newest and most secure encryption methods are offered. If you have configured sending with DANE, we assume that you do not use encryption technologies that are considered insecure (e.g. SSLv3 and RC4). The Posteo webmail interface shows you to which of your contacts you can send emails with the best possible security of DANE. Posteo users can recognise this via a small, green DANE symbol above an email address.