This blog does not support proper HTTPS connection yet.
It bugs me. This is 2018. Everyone is educated about how bad a non-secure connection is. I just wrote the privacy policy but let’s be honest, no privacy policy can save a website that basically asks everyone to broadcast their comments. Not to mention that I am the only guy who has to actually log in this website in order to use it. Inputting my password via an insecure channel is very bad.
So here starts my little research in how to get a proper HTTPS support, in the modern way.
Getting Apache to use HTTPS
This part is easy. Basically, one needs to do the following things:
- Create a new virtual host at port 443, and enable SSL engine;
- Set up a redirection at the original port 80, so that any attempt to access this website will be using https anyways.
- Enable the SSL module.
- Enable the socache_shmcb module. We really should have a module management system, but we don’t have one, so we manage the needed modules manually. Some software still behaves as if it is 1988.
A Simple Example
Assuming a configuration like this
<VirtualHost *:80>
ServerName www.example.com
# blablabla
</VirtualHost>Changing it to the following is sufficient
<VirtualHost *:80>
ServerName www.example.com
Redirect / https://www.example.com/
</VirtualHost>
<VirtualHost *:443>
ServerName www.example.com
SSLEngine on
# blablabla
</VirtualHost>But according to the default configuration file on my Gentoo machine, the following setup is at least worth considering:
## SSLProtocol:
# Don't use SSLv2 anymore as it's considered to be broken security-wise.
# Also disable SSLv3 as most modern browsers are capable of TLS.
SSLProtocol ALL -SSLv2 -SSLv3
## SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
# This list of ciphers is recommended by mozilla and was stripped off
# its RC4 ciphers. (bug #506924)
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES
128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:HIGH:!RC4:
!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK
## SSLHonorCipherOrder:
# Prefer the server's cipher preference order as the client may have a
# weak default order.
SSLHonorCipherOrder On (this section is last updated in 2019; you might want to find more recent advice on how to enforce safe variants of SSL.)
Getting a certificate
But the tricky part is that a proper SSL server needs a pair of keys signed by a trusted certificate authority. This is traditionally a charged service, but people now figure out that having websites that do not support secure connections is an existential threat to the web ecosystem… so they started the service Let’s Encrypt. They provide free and automated certificates. They can only do domain validation, because that is the only kind of certificate that can be issued automatically.
So they created a tool called certbot. certbot runs on the server and performs all the kinds of validation stuff and creates the certificate that I am now using.
Conclusion
Still, I wonder why HTTPs servers are not the Ubuntu default. Gentoo at least provides a dual-host default that provides an HTTP and an HTTPS server simultaneously and serving the same thing. Ubuntu’s default is two modules away from basic and necessary functionality! Anyway, it still follows that configuring servers is becoming easier and easier.