The TL;DR: You should not run a website that requires a login without enabling HTTPS on that web site and forcing the use of HTTPS for, at the very least, the login and administration pages. Logging in without HTTPS may allow somebody to steal your password and hack your web site. You should arrange to get a free certificate from Let’s Encrypt (letsencrypt.org) and install it or arrange to have it installed on your web server before making your web site live. If you need a web host that makes this easy, I use and recommend DreamHost because they make securing your web site easy and free (unlike others…*cough*BlueHost*cough*).
What is HTTPS?
HTTP is HyperText Transer Protocol. HTTP is the language web browsers and web servers use to get web pages in front of your eyes. HTTPS is HTTP Secure or HTTP over SSL/TLS.
HTTPS provides the following benefits:
- Privacy: HTTPS traffic is encrypted between the web server and your web browser which means it just looks like random nonsense to anybody else. This prevents your login name and password (among other things) from being stolen over WiFi by the guy sitting next to you in the coffee shop or by anybody else that happens to be in between you and your web server. Hint: There are a lot of people/devices between you and your web server.
- Authentication: HTTPS with a proper certificate gives you assurance that you are in fact connecting to the server you think you are connecting to. Without authentication your traffic could be intercepted by another server pretending to be your server. This can result in, among other things, you entering your password into a fake web page that looks like your web page but was actually put there by somebody to steal your password.
- Integrity: HTTPS provides a mechanism that allows your web browser and the web server to notice if the data has been tampered with in transit. Without the integrity provided by HTTPS, an attacker can change your web pages in the time between when the web server sends them and the web site visitor receives them. For example, the attacker could change the password submission code to send the password to them instead of to your web server, or could change the pages your visitors see.
- Forward Secrecy: If configured appropriately and both browser and server support it, HTTPS can use what is called an ephemeral or one-time-use key for the data encryption. As part of setting up the connection, the web server and web browser use the server’s permanent private/public key pair to securely agree on the ephemeral key. This means that if you lose track of the private key later, an attacker won’t be able to use it to decrypt any of your past communication.
How do i get HTTPS on my web site?
The simplest way is to have your web host do it for you. Unfortunately, depending on your web host this can end up costing you more money. At this time, I use and recommend DreamHost because they offer free SSL/TLS certificates by integrating the Let’s Encrypt service into their system and they don’t require you to also purchase a static IP address to enable SSL/TLS.
You then have to make sure your web site actually uses the HTTPS version. By default both HTTP and HTTPS are probably available. If you are using DreamHost and WordPress, for example, you need to modify your .htaccess to force the use of HTTPS. An example of how to do that with WordPress is here: Force HTTPS on All Pages of Your WordPress site
If you are hosting your own web site and have full control of the web server, I recommend Let’s Encrypt as a method to easily install and maintain your SSL/TLS certificates. Unfortunately there are too many variables for me to tell you exactly how to set this up in your situation.
In general, setting up HTTPS is a 4 step process (Let’s Encrypt takes care of the first 2 for you):
- Acquire a domain-specific certificate from a trusted Certificate Authority (CA). You should use a trusted CA and not a self-signed certificate because, unless you really know what you are doing and are willing to put up with a lot of inconvenience, the self-signed cert is much easier to fake than a CA-signed one.
- Install the certificate in your web server. This is just a matter of putting the certificate file in the right place with the proper permissions. See your web server documentation.
- Enable HTTPS in the web server configuration. See your web server documentation.
- Disable non-HTTPS by forcing all connections to go over HTTPS in the web server configuration. Some would argue that forcing HTTPS is not necessary because not all web pages you download need to be secret. I would then argue back about Authentication and Integrity (see above) which you absolutely can’t get with plain HTTP. Also, if your web server forces you to use HTTPS you can’t accidentally use the non-secure version when you are logging in.
But isn’t the CA system compromised/untrustworthy?
Probably, and if it isn’t it could easily be. But, using a certificate from a “trusted” certificate authority cuts the risk drastically.
Some background: Your web browser trusts certificates that come from “known trustworthy” Certificate Authorities and warns you about others. A trusted Certificate Authority (CA) will only give you a certificate for a domain if you can prove that you actually control that domain. It is true, however, that a CA is able to issue a certificate for any domain at any time if it chooses to, so we must trust them to do what they say they will. In general we trust the CAs that our browsers/operating systems trust. If you look into the list of trusted CAs, there are some dubious ones in there. Certain governments and corporations could certainly arrange to compromise this system. But, it’s what we have for the moment.
On the bright side, there is some technology being adopted that will allow us to trust the CAs a little less than we must now. It will be an interesting next few years.
A note on SSL/TLS: The commonly used term “SSL” stands for Secure Sockets Layer. SSL has been replaced by TLS (Transport Layer Security) which is simply an incremental improvement over SSL. The term SSL is often still used even when the speaker really means TLS (which is why I write it as SSL/TLS).