Soledad Penades: Securing your self-hosted website with Let’s Encrypt, part 4: hardening default setups and avoiding known vulnerabilities |
In part 3, we looked at how to finally use Let’s Encrypt to issue and renew certificates for our domains. But I also finished with a terrifying cliffhanger: basic HTTPS setups can be vulnerable to attacks! Gasp…!
Let me start by clarifying that I am not a security expert and if someone breaks into your system I will take no responsibility whatsoever, lalalala…
There are two main culprits:
SSL, the initial protocol used for encryption, has been proved insecure (see: POODLE). It is recommended that people use the newer TLS protocol instead.
Servers such as nginx will offer SSL by default if the value is not explicitly set in the server configuration file. Also, many configuration samples you find around the internetssss will place the weaker versions of the protocol first!
Remember when we talked about negotiating the HTTPS connection and how browsers would try and choose the first protocol they supported from the list the server offered? If we put the weaker versions first in our offerings, then browsers will consider those first! Not the best idea…
So: use TLS, which is safer (and maybe faster), and also offer safer protocols first… or just don’t offer the insecure protocols at all.
For example, this would be a good change for your nginx configuration:
- ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; # nginx default
+ ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
See how we removed SSL, and then reversed the order of the TLS versions to offer the latest versions first.
There’s a caveat: older clients might not be able to access your site if they do not implement any of the protocols your server offers.
Likewise, the issue with offering older ciphers is that some of them have been broken, and if you offer encryption with those you might be making it easy for the communications to be deciphered. Not what you want!
But where there are just SSL and TLS and a few version numbers to choose from for protocols, there’s an incredibly LONG LIST of ciphers and combinations and sizes you can choose for your server. Should you use ECDHE-ECDSA-AES256-GCM-SHA384 or maybe ECDHE-RSA-AES256-GCM-SHA384? Or perhaps ECDHE-ECDSA-CHACHA20-POLY1305? (Chacha! Chachacha!
Комментировать | « Пред. запись — К дневнику — След. запись » | Страницы: [1] [Новые] |