A while ago I wrote a blog outlining the need for HTTPS for not only confidentiality, but integrity as well. Recently this very topic surfaced on Twitter with some thinking that HTTPS only provides security to data sent to the server (primarily confidentially). Their logic is such that the content is static and public, that they don't need HTTTPS. Well here's the truth, even in this case you still need it.
HTTPS Is Not Just About A Green Padlock
It's a coniencidence that this whole debate surfaced this week. I was in the process of putting together a presentation which attempts to highlight the need for HTTPS. In this presentation I will be presenting (well attempting to anyway) a live demo of what exactly a MiTM could achieve when HTTPS is not used, as well as enforced. One of the things I will be showing is the ability to alter the content sent back to the user (integrity), as well as the ability to view data sent back to the user (confidentiality). Ironically it is becoming harder and harder to find real world examples, so in this case those opponents of HTTPS are in fact helping me by providing the very real world examples which I have been looking for.
HTTPS Is Technical
Another argument levied against HTTPS is that it is not easy to implement and configure on a server. This is true to some extent. But with the advent of protocols such as the ACME protocol (developed by Let's Encrypt), they are now making it incredibly easy to do. For this very blog, the Ghost installation script generates a Let's Encrypt certificate, configures the web server to use it, and sets up a from job to ensure that the certificate is renewed before the current certificate expires. Guess how much configuration I had to give? My service hostname as well as my organizational information. Well I'm sorry, but I think this is something so simple to do, that any non technical person could do it. All the technical work and knowledge is carried out by the script itself.
So the next point I might hear is that the system which they are using does not suppose these degree of automation and technical abstraction. Well if you are technical enough to configure a web server, you are technical enough to generate and configure a certificate. There are plenty of resources online which one can refer to for help and guidance.
What if you are not using a self hosted solution? Well then it should be up to the service provider to provide this functionality. In this day and age they do not have an excuse not to. Most non technical people would likely opt for this scenario.
The Internet Is Changing
The Internet is chaning and evolving. Secure by default is where things are heading, and for good reason too. There is a slow and steady migration towards HTTPS becoming the defacto communication channel. As of July this year, Chrome will mark all sites served over HTTP as insecure. Firefox will now only support new features over HTTPS. Technology changes, if this were not the case we would never improve and evolve it. One example was about someone having a blog from 1997 which will now be marked insecure. Well yes it is. To maintain security one needs to keep up to date, just ask the likes of Equifax.
Summary
There is no doubt that the Internet is making great stride towards moving to HTTPS. Many of the big names of the tech industry are helping with this push. Many of these players have little or no financial motivation for this. They just want to make the web a more secure place. I think anyone would be hard pressed to try argue against this. Over the coming weeks I plan to have posts detailing some of the potential attacks which an attacker can perform when no HTTPS is used, or has been poorly implemented.
