Time and time again, surveillance happens. Time and time again, encryption is under attack. And then there’s a debacle with certificates after the next.

But just because encryption as well as its surrounding systems are under attack does not mean that the solution to this ongoing issue is as difficult as it seems – encryption and correct configuration is all that’s needed. The main challenge is missing knowledge. Knowledge of what to do in order to not fall into one of the many configuration traps. To mitigate that, there are several websites that attempt to spread the knowledge of proper encryption. I am not going into the details as to why encryption is important because whoever reads this is probably past that point already.

Ciphers and Protocols

The cipher is the biggest risk when talking about erroneous configuration. Cryptographically weak ciphers, ciphers that are too short, Diffie-Hellman groups that are too small, protocols that are too outdated, too insecure and that’s not even all of it. Luckily, people are aware that these are frequent issues when setting up encryption so there are two good websites that help administrators, regardless of whether they’re private users or business users.

There’s Cipherli.st that offers good configurations along with explanations. Among many others, it supports Apache, nginx, Lighthttpd, Postfix, Exim and Zarafa.

If you want to test your configuration, at least that of a web server, that accesses the web, I recommend Ivan Ristic’s SSL Labs. The platform offers a quick and good overview over the current situation, the TLS/SSL Configuration.

If you want to better understand what has to be configured why and how, you’re best off reading Michael Schneider’s article Transport Layer Security Done Right.

Divert Traffic to 443

Often, websites are available in encrypted and unencrypted versions. A user has to have gotten a bit lucky and have accessed the encrypted version once in order to realize that it actually exists. If, in addition to all that, the user has installed the extension HTTPS Everywhere, the browser will always access that encrypted version. Server owners should support the user in their transition from the unencrypted version to the encrypted one and redirect them automatically. This raises the bar for attackers right off the bat.

There’s another problem, though. Every time the user accesses the website – assuming that most users don’t have HTTPS Everywhere installed and that most users enter http in front of the URL – the server performs a redirect. An attacker can launch a man-in-the-middle attack every time and remove SSL. This attack is known as the SSL-Strip-Attack. To defend against this, a browser can be instructed by the server to only access HTTPS from now on using Strict-Transport-Security in the header.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

max-age stands for the validity of the header in seconds. Generally speaking: The longer, the better. includeSubDomains and preload are options. The former ensures that subdomains also are generally only accessed using HTTPS. The latter takes care of the requirements to be added to the Google Chrome preload list. Once a domain is on that list, the browser always uses HTTPS to access the site. Firefox, Safari, Internet Explorer 11 and Microsoft Edge are using the same list.

The Certificate

One of the arguments that are frequently brought up against encryption is that it costs money to get a certificate. Especially non-profit organizations voice this concern frequently. But, while it’s still young, there’s a Certificate Authority (CA) that offers free certificates and is, unlike CAcert, accepted by all major browsers. The new CA is called Let’s Encrypt. It offers a free, automated CA that is run by a group of enthusiasts. Other Certificate Authorities are following suit and offer free certificates as well. Some configuration errors such as wildcard certificates and extended validation can’t happen with Let’s Encrypt as these features aren’t supported. The same goes for certificates signed with MD5 and SHA-1. In addition to all that, there’s a minimal length of 2048bit and 4096bit is possible. Certificates are delivered with a script that ensures that certificates don’t expire but are renewed in short intervals.

Pin Up Certificates

All who have a clean certificate as well as good cipher and protocol configurations, have a distinct advantage over unencrypted communication. There is one thing to observe, though: As long as the certificate isn’t issued by a valid CA for a website, it’s impossible for a user to discern whether or not the certificate has been issued without permission, as seen in the case of Google and Symantec, or if the certificate is actually valid.

The solution to these issues is the new HTTP Response Header Public-Key-Pinning. The only way to circumvent this in a way that makes any kind of sense is during the very first handshake. Subsequently the browser pins the cryptographic identity of the server to the URL and saves it locally. Should an attacker try to launch a man-in-the-middle attack, even with a valid rogue certificate, the browser will recognize the attack.

Public-Key-Pins: max-age=5184000; pin-sha256="base64-kodierter-SPKI-Fingerprints" [; includeSubdomains][; report-uri="URI"]

In addition, the option includeSubdomains can be set. This will set the header and the SPKI, analogous to the strict transport security header, for subdomains. The RFC defines an option that will report errors or potential attacks directly. This option is called report-uri=URI.

More notes regarding Public Key Pinning are on Mozillas developer page.

About the Author

Veit Hailperin has been working in information security since 2010. His research focuses on network and application layer security and the protection of privacy. He presents his findings at conferences.

Links

• http://arstechnica.com/security/2015/10/how-the-nsa-can-break-trillions-of-encrypted-web-and-vpn-connections/
• http://www.heise.de/ix/artikel/Rote-Telefone-506074.html
• http://www.mycrypto.net/encryption/encryption_crack.html
• http://www.theregister.co.uk/2015/10/29/google_symantec_dodgy_certs/
• http://www.zeit.de/politik/deutschland/2015-07/wikileaks-nsa-soll-kanzleramt-belauscht-haben
• https://cipherli.st
• https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
• https://hstspreload.appspot.com/
• https://letsencrypt.org/
• https://tools.ietf.org/html/rfc7469
• https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
• https://www.cacert.org
• https://www.reddit.com/r/technology/comments/3twmfv/dell_ships_laptops_with_rogue_root_ca_exactly/
• https://www.ssllabs.com