TLS is mandatory when you publish services on the Internet – hardly anyone doubts that these days. Even websites without a log-in area and sensitive content are now delivered via HTTPS, unlike ten years ago. With free certificates from Let’s Encrypt and automatic renewal, TLS can now be set up quite adequately in just a few simple steps. But if you want more than passable and go deeper into the topic, it gets complicated. If you take a closer look in the settings of web servers or reverse proxies, you will come across the configuration of the so-called cipher suites and you will notice: TLS is not the same as TLS and the options offered are not necessarily self-explanatory. Is TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 the setting of choice, or is TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 preferable? The question can only be answered properly after a trip into cryptography.
The following information does not only apply to web servers, mail servers (with IMAP and SMTP) or exotic ones such as MQTT servers should only be operated with secure TLS settings. If you have many services to publish, you are well advised to use a reverse proxy that handles the TLS processing centrally for HTTP and all other protocols. In the settings of the servers or reverse proxies with TLS function, you can always activate several cipher suites at the same time. In a perfect world, a single cipher suite would suffice, preferably the one with the longest keys and best practices. The fact that server operators have to think about the topic at all is because not all clients (mail programs, browsers, …) understand the latest and best procedures and the servers do not always have the latest and best technology. Partly because the developers haven’t yet included the latest crypto libraries, partly because users are running hopelessly outdated software and find updates a nuisance anyway.
Therefore, a server that masters TLS can always support several methods and agree on one method with the client. The initiative comes from the client, which tells the server which procedures it knows. The server then decides which of the offered methods to use. The problem: If you accept both secure and insecure methods in order not to exclude very old clients, an attacker who sits as a man-in-the-middle between client and server can force a vulnerable method. To do this, it manipulates the list of supported processes that the client sends to the server (a so-called downgrade attack). The consideration is therefore to allow as few (and only safe) procedures as possible and at the same time to exclude as few people as possible.
- Access to all content from heise+
- exclusive tests, guides & backgrounds: independent, critically well-founded
- Read c’t, iX, MIT Technology Review, Mac & i, Make, c’t photography directly in your browser
- Register once – read on all devices – can be canceled monthly
- first month free, then monthly from €9.95
- Weekly newsletter with personal reading recommendations from the editor-in-chief
Start FREE month
Start your FREE month now
already subscribed to heise+?
Sign up and read
Register now and read the article immediately
More information about heise+