How we broke our mail server... and why it was on purpose

When talking to our clients, we found that e-mail security is a very individual topic. Depending on the background, infrastructure and the type of sensitive data our clients deal with, their view on secure e-mail communication differs a lot. So we decided to find a common ground to start from: We set up a mail server so malformed that no one would deny that it is completely insecure.

Now what is the most important step when building the worst-configured mail server ever? Right, a server. We found that a simple server instance hosted by AWS, Amazon‘s cloud computing service, would perfectly meet our requirements. The server comes with a free static IP that makes it locatable for mail clients in the DNS system. We equipped it with Postfix, an open-source mail transfer agent, on top of a Ubuntu operating system, and soon it was ready for use.

Now comes the fun part: Which elements of the server configuration offer security – and how can we ruinate them? Having talked to SMTP servers all over the world for more than seven years now, we saw any kind of error. But even if this may not be your everyday business, we can assure you that you are familiar with some of these misconfigurations as well. Remember the last time your web browser warned you about a „Potential Security Risk Ahead“?

The small print below the message gives you a hint what is wrong with the TLS certificate of the website you are trying to access.

As mail servers do also use TLS certificates to secure their communication, we have a starting point. Depending on your browser, you can read the following error codes. (Our examples are taken from Firefox web browser and we added a short explanation):

• UNKNOWN_ISSUER – The certificate issuer is unknown, the certificate is self-signed or the server is not sending the correct intermediate certificates.
• EXPIRED_CERTIFICATE – The certificate is not valid anymore.
• BAD_CERT_DOMAIN – The hostname in the website‘s security certificate differs from the website you are trying to visit.
• WEAK_SIGNATURE_ALGORITHM – The signature algorithm the certificate uses is not secure. So your web browser warns you about insecure connections. But what about your e-mail client? To figure this out, we must give it a reason:

Let us create our certificate of shame using OpenSSL, an open-source software library that implements everything about the TLS protocol. We can provoke all of the errors above using just one command:

$ faketime '1970-01-01 00:00:00' openssl req -newkey rsa:1024 -x509 -sha1 -days 1 -nodes -out ssl-cert.crt -keyout ssl.cert.key -subj "/C=DE/ST=Saxony/L=Chemnitz/0=CA/OU=CA/CN=abc.xy"

The req command we hand to the OpenSSL command line tool usually creates a new certificate request. If we wanted to set up a good certificate, we would send that request to a certificate authority, so they sign our certificate and thereby validate it as trusted. Creating an untrusted certificate is much easier though: Parameter -x509 just signs our certificate by itself, so we have a (by other parties) unknown and therefore untrusted issuer - ourself.

With the -subj parameter we set the subject of our certificate, which is the domain it is issued for. Here we must make sure that it does not fit the domain of our mail server to get the BAD_CERT_DOMAIN error. Instead of the real domain name of our mail server, „evaluation.comcrypto.de“, our certificate is issued for fake domain „abc.xy“.

Next, we make sure that our certificate is definitely not valid anymore. The faketime command makes OpenSSL believe that we create our certificate at midnight on January 1, 1970. As our certificate is only valid for one day (parameter -days), it expired about 50 years ago.

Until now our certificate is objectionable because the domain it is issued for is not trusted. But even if a mail client could be sure about who it is talking to – with the correct domain name and a CA that vouches for it – how can it be sure that nobody else can eavesdrop the conversation? This takes us from the authentication part of the TLS protocol to the part about cryptography.

Let us get back to our initial problem: What requirements must be fulfilled to protect the data you are sending by e-mail?

Think of the door to your apartment. It protects your most personal and sensitive data from people who should not see them. When you leave for work in the morning, what will you do to protect it? Do you turn the key twice? Do you feel alright if you just let the door snap into the lock? Would it be secure if you turned the key, but left it under your doormat? Whatever your standard procedure is: Definitely, you would not leave the door open, would you?

At comcrypto, we decided to turn the key twice in every case: If you send mails using MXG, it only considers a TLS connection secure if it satisfies the cryptographic recommendations of the BSI, the Federal Office of Information Security in Germany. Thereby we guarantee a minimum security level for every transaction of data – regardless of the type of data or to whom it is directed.

So how can we spoil the crypto part of our TLS connection? Some of the cryptographic properties can be set when creating our TLS certificate. Again, take a look at our OpenSSL command. Along the way we generated our own RSA private key using parameter -newkey with an RSA key length of 1024 bits. The BSI recommends to use RSA keys of at least 2000 bits length, so our key is just too short to be safe.

Using command -sha1, we force signatures to be generated using the SHA1 hash function. Since this function turned out not to be collision resistant, signatures created with this algorithm can be forged. This is how we get the WEAK_SIGNATURE_ALGORITHM error.

Now we ruined everything we could about our TLS certificate. Finally, let us proceed to the TLS handshake to see what else we can break. During the TLS handshake, the mail server you communicate with announces the maximum TLS version it supports. We make our server support TLS version 1.0 only, which is no longer recommended by BSI as it uses the outdated SHA1 signature algorithm.