An Experiment on Returning to HTTP
Around a month ago, I left Cloudflare and went back to HTTP-only sites. Not HTTPS. I did it for my own reasons, mostly performance-related. This is a long, somewhat technical post on my musings about HTTP and why I went back. If you're looking for lighter fare, start here.
I stumbled across Dave Winer's post about http vs https this weekend, http://scripting.com/2018/02/23.html. He brings a different perspective than I expected. However, it made me think about writing this post. My reasons aren't necessarily Dave's reasons, but I generally agree with him. I'm also going to skip a lot of nuance here, because as a past network engineer, I can go pretty deep and end up at the bottom of a rabbit hole pretty quickly, thereby losing everyone.
Sticking with HTTP
I have something like 40 domain names I've collected over the years, since 1994. I learned in the early 2000s, never let a domain name expire, because you have no idea what its worth in the future. Domain names as equities; buy and hold for the long view.
HTTP is fast and easy to setup on your own. In most cases, it's zero cost beyond the cost of the server you're renting/buying. My web servers handle both HTTP/1.1 and HTTP/2 just fine.
HTTPS is expensive, especially for an individual; with 40 domain names. Let's Encrypt is zero cost, but very limited. No wildcards. And rate-limits to renewal every week. In testing, I ran into this limit right away. Maybe when they have wildcards, it's worth a revisit. An alternative to a centralized CA, is DANE/TLSA. There's a long abstract about how to use the new DANE/TLSA standards to host SSL without needing a 3rd part Certificate Authority, https://tools.ietf.org/id/draft-dukhovni-dane-ops-00.html. I'll work on doing this over time.
And yes, I was part of the "solution" of HTTPS everywhere with the EFF. It makes you feel better, having an "encrypted conversation with a website", but for the most part, you don't need HTTPS. 99.9% of the users of HTTPS sites don't check the certificates, and have no way of knowing anything is safe, despite the lock icon in their browser. I lived without a Certificate Authority for a year and tried to validate every cert I encountered. And then there's any validated CA in your browser can validate any cert. And to top it all off, plenty of SSL decryption/machine in the middle solutions exist commercially to invalidate any authentication between your browser and the website. It's a mess, to say the least. This is why I'm looking at DANE/TLSA as mentioned in the last paragraph.
Logically, there's nothing worth securing on my websites. I don't ask for login credentials, I don't ask for sensitive information. There are no ads or any commerce of any kind on my sites. The one part of a site which needs HTTPS, has it, with a self-signed certificate. Since I'm the only one who logs in there, I'm my own Certificate Authority and don't care what the browsers warn. This blog is hosted by Wordpress, and they force HTTPS everywhere. If I migrate my blog off Wordpress, then it won't be HTTPS anymore.
Sure, someone in the middle can modify the content or inject ads, etc, but in reality, it's pretty uncommon. A VPN on your end would fix most of those issues if it's such a great concern.
For my sites, HTTPS was a lie. I used Cloudflare and they fronted the HTTPS certificates, but connected to my web server over HTTP.
Leaving Cloudflare
Cloudflare is a great CDN which you can use for zero dollars. You hand over DNS to them and you are then on their network. Two things became evident quickly, one my site was slower than native and two, my domains rarely get attacked/DDoS'd. A tertiary frustration was the limited DNS types they support on the free account. However, you get what you pay for and I didn't expect too much. SSHFP and TLSA would've been nice.
The "Time to First Byte" was slower, because Cloudflare is based on "pull on request". As in, they copy the requested html/javascript from the server when a client asked for it. They don't mirror it and host it globally. I didn't expect they would, but I didn't expect the site to be slower than native either. Again, this is all zero dollars here.
Here's a past experiment with various content delivery networks and hosting mirrors of sites around the world.
Cloudflare's biggest gain is in the DNS resolution. It's very fast, because they do mirror your domains around the world, unlike the html and such on your websites.
Cloudflare's other advantage was DDoS protection. At the free level, this is was for the websites only. My server could get DDoS'd on another port, like SSH, and they will do nothing about it, again because it's a free account. My hosting provider now offers DDoS protection at the machine level, so I don't need double protection here.
Let's work on an example, omfdogs.is.
OMFGDOGS.IS
Let's start with an example: http://omfgdogs.is. It's a silly site I setup 12 years ago. It was super popular for about a week. It survived the Slashdot effect just fine. My firewall did more to limit connections than did the HTTP server. When you type omfgdogs.is into your browser bar, here's what happens:
- Your browser asks the operating system for a dns resolve of the name to its IP address (either v4 or v6).
- Your local DNS, probably your ISP or your router, checks to see if it's in cache, and if not, asks the root of .is where omfgdogs resides.
- My DNS server is in Iceland, so the resolution has to go to the server in Iceland, ask it to lookup omfgdogs.is and respond with an IP address.
- Once your browser has the IP address, it then makes an HTTP/1.1 or HTTP/2 GET request to my web server. You can watch this happen in real time in most browsers by clicking 'view page source' or 'inspect element', click the network tab, and watch the headers and timing.
- My web server responds with two files, the html itself and the image file of the dogs running.
- And then your browser has to render the HTML and display the running dogs.
There is more happening behind the scenes, like TCP setup, connections, etc, but at a high-level, that's what happens. At the same time, you see there are 6 places where performance can run into issues.
Cloudflare used to take care of #1-3 easily. Now, here's a sample of what happens when you visit http://omfgdogs.is from around the world:
Unsurprisingly, the further you are from Iceland, the longer it takes the DNS request to complete. In fact, for most of those requests, DNS is 50% or more of the connect time. Try it for yourself, https://latency.apex.sh/?url=omfgdogs.is&compare=
Here's what it looks like on my laptop while in San Francisco,
This is the output of the "host -v www.omfgdogs.is" command. It reports that it took 293 milliseconds to get the IP address of the domain.
And here's what the browser sees when requesting the site,
The best way to make the site seem faster to the user is to increase the speed of the DNS resolution. Here's a fine article talking about speeding up Time to First Byte (TTFB), https://www.keycdn.com/blog/a-slow-website-time-to-first-byte-ttfb/.
Summary
In essence, what have I done? I've traded a slower DNS resolution for a faster TTFB overall, and a slightly faster serving of omfgdogs.is to you. I've also regained fine control of my DNS and taken responsibility for performance of my sites. Google will punish my SEO rankings as a result, since I'm not HTTPS on all sites.
Like anything in life, it's an experiment. C'est la vie.