UPDATED April 2, 2015: This was an April Fools Joke. Read. Laugh. Learn. If you’re building web services, you should most definitely be using HTTPS.
As a security company, we frequently get questions here at Stormpath from developers regarding security best practices. One of the most common questions we get is:
Should I run my site over HTTPS?
Unfortunately, regardless of where you go on the internet, you’ll mostly ready the same advice: encrypt everything!, use SSL for all sites!, etc. The reality, of course, is that this is not usually good advice.
There are many circumstances where HTTP is better than HTTPS. HTTP is, in fact, a much better and more useful protocol than HTTPS, which is why we often recommend it to our customers. Here’s why…
HTTPS as a protocol is riddled with problems. Numerous, well-known issues with the protocol and popular implementations make it unsuitable for a wide variety of web services.
One of the primary blockers for HTTPS adoption is the fact that the HTTPS protocol is painfully slow.
By its very nature, HTTPS is meant to securely encrypt communications between two parties. This requires both parties continuously spend valuable CPU cycles:
- Initially saying “hello” and determining what sorts of encryption to use
- Validating SSL certificates.
- Running crypto code for each request to validate / verify the request / response.
While this doesn’t sound like much, crypto code is very CPU intensive. It makes heavy usage of the floating point CPU registers, which taxes your CPU and slows down request processing.
Here’s a very informative ServerFault thread showing just how big of a slowdown you can expect using a simple Ubuntu sever with Apache2:
Here are the results:
Even in a very simple example like the one shown above, HTTPS can reduce the speed of your web server by more than 40 times! That’s a HUGE drag to web performance.
In environments today, where it’s common to build your application as a composition of REST APIs — using HTTPS is a sure way to slow down your site, reduce your application’s performance, unnecessarily hammer your server CPUs, and generally annoy your users.
For many speed sensitive applications it’s often much better to just use plain HTTP.
A lot of people are under the impression that HTTPS will make their site secure. This isn’t true.
HTTPS only encrypts traffic between you and a server — once the HTTPS information transit has terminated, everything is fair game.
This means that if your computer is already infected with malware, or you’ve been tricked into running some malicious software — all the HTTPS in the world won’t do anything for you.
Furthermore, if any exploits exist on the HTTPS server, an attacker can simply wait until the HTTPS transaction has finished, then grab whatever data necessary at another layer (the web service layer, for example).
SSL certificates themselves are also frequently abused. The way they work in web browsers, for instance, is quite error prone:
- Each browser vendor (Mozilla, Google, etc.) independently audits and approves root certificate providers to ensure they are securely handling SSL certs.
- Once approved, these root SSL certs are put into the browser’s “trusted” cert list, which means that any SSL certs signed by these providers is implicitly
- These providers are then free to screw things up and cause all sorts of security issues — like what happened with DigiNotar in 2011.
In the above case, a popular certificate authority mistakenly signed numerous fake and fraudulent certificates, directly compromising the security of (millions?) of Mozilla users.
While HTTP doesn’t offer encryption of any type, at least you know what you’redealing with.
If you’re building a web service that is meant to be consumed through insecure devices (like mobile apps), you might be under the impression that since your service is running over HTTPS, users are unable to intercept and read your private messages.
If that’s what you thought, you’d be wrong.
Users can easily setup a proxy on their computer to intercept and inspect all HTTPS traffic, thereby bypassing your very own SSL certificate checks, and allowing your private information to be directly leaked.
This blog post walks you through intercepting and reading private HTTPS messages on mobile devices.
Think you’re doing it right? Don’t count on it! Even large companies like Uber have had their mobile apps reverse engineered, despite their HTTPS usage. If you’re in the mood, I can’t recommend reading this article enough.
It’s time to accept the fact that no matter what you do, attackers will be able to read your traffic in one way or another. Instead of wasting engineering time trying to fix and patch common SSL issues, spend your time working on your core product or service and just use HTTP wisely.
It’s well known that HTTPS isn’t invulnerable. There have been numerous HTTPS exploits over the years:
It’s inevitable that there will be more attacks in the future. If you pair this with the fact that the NSA is spending insane amounts of money to capture and store SSL traffic for future decryption — it seems pointless to use HTTPS considering that your private traffic will almost certainly be made public at some point in the future.
The last main point I want to cover is that HTTPS is expensive. To purchase a certificate that browsers and web clients will recognize, you have to purchase an SSL certificate from a root certificate authority.
SSL Certificates can range from a few dollars per year to thousands — and if you’re building a distributed application that relies on multiple microservices, you’ll need more than just one.
This can quickly add up to a lot of money, which is particularly expensive for people building smaller projects, or looking to launch a new service on a tight budget.
On the flip side, let’s stop being negative for a moment, and instead focus on the positive: what makes HTTP great. Most developers don’t appreciate its’ benefits.
While HTTP itself doesn’t offer any security whatsoever, by properly setting up your infrastructure and network, you can avoid almost all security issues.
Firstly, for all internal HTTP services you might be using, ensure that your network is private and can’t be publicly sniffed for packets. This means you’ll probably want to deploy your HTTP services inside of a very secure network like Amazon’s EC2.
By deploying public cloud servers on EC2, you’re guaranteed to have top-notch network security, to prevent any other AWS customers from sniffing your network traffic.
Something not many people think about, when obsessing over HTTP’s lack of security and encryption is how well it scales.
Most modern web applications scale via queueing.
You have a web server which accepts incoming requests, then farms individual jobs out to a cluster of servers on the same network which perform more CPU and memory intensive tasks.
To handle queueing, people typically use a system like RabbitMQ or Redis. Both are excellent choices — but what if you could get all the benefits of queueing without using any infrastructure except your network?
With HTTP, you can!
Here’s how it works:
- Setup a network where both your web server and all worker servers share a
- Make your worker servers listen for ALL packets on the network, and passively sniff network traffic.
- When you receive incoming HTTP traffic to your web server, your worker servers can simply read those incoming requests (in plain text, since HTTP isn’t encrypted), and start the processing work IMMEDIATELY!
The above system works exactly like a distributed queue, is fast, efficient, and simple.
Using HTTPS, the above scenario would be impossible, but, by using HTTP, you can dramatically speed up your applications while removing your need for infrastructure services — a big win.
The last point I’d like to mention in favor of using HTTP instead of HTTPS for your next project is: insecurity.
Yes, HTTP provides no security for your users — but is security even really necessary?
Not only do most ISPs monitor network traffic, but it’s become quite apparent over the past couple of years that the government has been storing and decrypting network traffic for a long time.
Worrying about using HTTPS is like putting a padlock on a fence that is 1 foot high: it’s basically impossible to secure your applications — so why bother?
By developing services that rely on HTTP alone, you’re not giving your users a false sense of security, tricking them into thinking they are secure when, in fact, they most likely aren’t.
By building your apps on HTTP, you’re simplifying your life, and increasing transparency with your users. Consider it!
Happy April Fools’ Day!
I hope you didn’t really think I would recommend against using HTTPS! I want to be perfectly clear: if you’re building any sort of web application, use HTTPS!
It doesn’t matter what sort of application or service you’re building, if it’s not using HTTPS, you are doing it wrong.
Now, let’s talk about why HTTPS is awesome.
HTTPS is a great protocol with an excellent track record. While there have been several exploits over the years, they’ve all been relatively minor, and furthermore, they’ve been patched quickly.
And yes, while the NSA is most certainly storing SSL traffic somewhere, the odds that they’re able to decrypt even a small amount of SSL traffic is infinitely small — this would require fast, fully functional quantum computers and would cost an insane amount of money. Odds are, nothing like this exists, so you can sleep easily at night knowing that the SSL on your site is actually protecting user data in transit.
I mentioned above that “painfully slow” HTTPS was, but the truth is almost completely the opposite.
While HTTPS certainly requires more CPU for terminating SSL connections — this processing power is negligible at best on modern computers. The odds that you’ll ever hit an SSL bottleneck are effectively 0.
You’re far more likely to have a bottleneck with your application or web server performance.
While HTTPS isn’t a one-size-fits-all solution to web security, without it you’re guaranteed to be insecure.
All web security relies on you having HTTPS. If you don’t have it, then no matter how strongly you hash your passwords or how much data encryption you do, an attacker can simply monitor a client’s network connection, read their credentials — then BAM — game over.
So — while you can’t rely on HTTPS to solve all of your security problems, you absolutely, 100% need to use it for all services you build — otherwise there’s absolutely no way to secure your application.
Furthermore, while certificate signing is most definitely not a perfect practice, each browser vendor has pretty strict and rigorous rules for certificate authorities. It’s VERY hard to become a trusted certificate authority, and keeping yourself in good standing is equally tough.
Mozilla (and the other vendors) do an excellent job of pruning bad root authorities, and are generally awesome stewards of internet security.
Earlier, I mentioned that it’s quite easy to man-in-the-middle SSL traffic by creating your own SSL certificates, trusting them, and then intercepting traffic.
While this is most definitely possible, it’s fairly easy to prevent via SSL Certificate Pinning.
Essentially, by following the guidelines in the article linked to above, you can force your clients to trust only a true and valid SSL certificate, effectively preventing all sorts of SSL MITM attacks before they can even start =)
If you’re deploying an SSL service to an untrusted location (like a mobile or desktop app), you should most definitely look into using SSL Certificate Pinning.
While it’s true that historically, HTTPS has been expensive — this is no longer the case. You can currently purchase very cheap SSL certificates from a number of web hosts.
Furthermore, the EFF (Electronic Frontier Foundation) is just about to launch a completely free SSL certificate provider: https://letsencrypt.org/
It’s launching in 2015, and will invariably change the game for all web developers. Once Let’s Encrypt goes live, you’ll be able to encrypt 100% of your sites and services for no cost at all.
Be sure to check out their site and subscribe for updates!
Earlier, when I talked about how HTTP security doesn’t matter, especially if your network is locked down — I was lying to you.
While network security matters, so does transit encryption!
If an attacker is able to gain access to any of your internal services all HTTP traffic will be intercepted and read, regardless of how ‘secure’ your network may be. This is a very bad thing.
This is why HTTPS is critically important on both public AND private networks.
BONUS: If you’re deploying services on AWS, DON’T COUNT ON YOUR NETWORK TRAFFIC BEING PRIVATE! AWS networks are PUBLIC, meaning that other AWS customers can potentially sniff your private network traffic — be very careful.
When I mentioned earlier how you could replace queuing infrastructure with HTTP — I wasn’t really wrong, but OH MAN. What a horrible idea!
Relying on poor security practices to “scale” your service is a bad, horrible, awful, VERY BAD idea.
Please don’t do it (unless it’s a proof-of-concept, in which case it’d make for a very cool demo to say the least)!
If you’re building web services, you should most definitely be using HTTPS.
It’s easy, cheap and builds user trust, so there’s no excuse not to. As developers, it’s our job to help protect user security — and one of the best ways to do that is to force HTTPS side-wide.
I hope you enjoyed this article, and got a good laugh or two.
If you liked this article, you might also like last year’s Apil Fools’ post as well: Why You Might Want to Store Your Passwords in Plain Text.