This article is 101 into HTTPS.
Took me whole Sunday to understand how HTTPS, SSL/TLS, Certs and encryption works. At first, after ssllabs and ssldecoder tests, I thought that issuing correct cert will enable correct SSL/TLS protocol and cipher suite. WRONG.
Even after reading how D-H can be cracked (another explanation of you are up to reading a lot), I though I need to have knowledge of cryptography to be able to configure secure connection. No, not needed at all either. Without going deep into cryptography either or having maths knowledge, you just need to know which algorithms are insecure to use. Anyway there are plenty examples to learn from or just copy into your config, as long as you know what you are doing. Anyhow, after you set up your website, you can do various tests as mentioned above and even this one too — From weakdh.org.
Three components. Theory to Practice
This blog is proof of this article.
1. Secure protocol
Your web server is responsible for connection protocol between server and client. I would suggest to make this a first step to enable your server accept https connection over 443 port. I have done it on my Apache through ssl.conf by enabling SSLEngine and configuring vhost to listen on port 443. My CentOS server came with root certificate available out of box, so all worked — I was able to browse my page over https. Obviously, certificate is untrusted, as self-signed, hence tests failed (no A grade achieved and lots of errors) plus no system hardening done.
Done: traffic going through secure link
Flaws: weak cypher suites enabled which means information can be decoded, and untrusted certificate used which means MITM attack is potentially possible.
2. Configure cipher settings
In the same file, and same — server’s responsibility to use strong cipher suites, we configure server to use your preferred algorithms and not to use known weak ones. Web and news are full of information about, but you can also refer to tests. At the very least I disabled RC4, SHA1 and some others algorithms. You may enlist cipher suites in your config file or can go easy and quick way by mentioning to use only “high” and “medium” algorithms and disabling weak ones.
This is one of the shared examples you may use to accomplish first two steps, it is also good example showing you how to use it with Letsencrypt certs. Apache Configuration Example
Done: only strong cypher suites used, plus information going through secure link (as from above).
Flaws: MITM attack still potentially possible, error due to not trusted certificate.
When we finally completed server side configuration, it is time to obtain trusted CA-signed certificate.
Short theory: certificate is file placed on your web server and required for client (browser or human) to “trust” that the webpage is genuine and safe to go into, send your password through. Of course you can use root or self-signed certificate which you can create yourself on the same server you are hosting your webpage, as long as you have SSH access to it; or any other server/PC where the required tool is installed. There is one more important thing to mention that issued certificate should be strong as well, make sure you avoid using SHA1 when creating your own certificate, use at least SHA256 instead. If you use your own self-signed certificate file, test will not be successful but connection and information exchange can be still secure.
As per community, Namecheap is one of good choices to go buy cert from. Normally you probably would buy certificate for your domain or subdomain, that would cost in range of £10 per year. You can only use it for your domain or subdomain. Or you could buy so called “wildcard” certificate for your whole domain, and it would work for any subdomains too, although if you are not business, the price is quite high enough.
Another way. There is new service called Let’s Encrypt www.letsencrypt.org with help of which you can quickly obtain 3-months certificate for free. On their webpage you can find easy and brief explanation how their technology works. Great technology and modern approach.
As this article is to clarify and explain on high level how this all works, I would give a good advice for organizing or designing configuration: what is in any way related to virtual host, move it into virtual host configuration. The configuration which will be used globally, only that configuration can remain outside vhost configuration. Please see good config examples.
Now you know simple theory and three major things-to-do behind setting up secure connection for your server. One moment I cannot stop recommending enough is: follow best practices when configuring systems and always look into system hardening. Use ssllabs and ssldecoder tests while in process of configuring your server to find what have you missed or what else can you improve. It will tell you any weak configuration related to any of three settings explained above.