OctoPerf is fully HTTPS. There
is a reasons for it. Setting up HTTPS for all our websites (Documentation, Application and Website) is a little bit tedious and pricey1. It took us two days to complete the operation but the result is satisfying for number of reasons.
Why is HTTP so dangerous
HTTPS ensures that the communication between our servers and our customers is fully encrypted. Lots of people are using a Wifi connection to go on the internet. For example, if you connect from a HotSpot from Starbucks Coffee, the Wifi connection is completely unsecure. Any login or password transiting with non-secure HTTP protocol can be easily intercepted.
Software like Wireshark can sniff the network packets transiting over the Wifi connection, even if the communication is not targeted for your computer. It switches the network card to promiscuous mode: the Wifi card accepts any packet over the air.
Plain HTTP WireShark Capture.
How does HTTPS work
When surfing on an HTTPS secured website, the connection is encrypted from client to server. Only the server can decrypt what the client has encrypted. To make things short:
- The server sends a public key to the client,
- The client encrypts the request to send with the public key, and sends itself its own public key within,
- The server decrypts the request sent by the client using a private key, it encrypts the response using the client provided public key,
- Then the client decrypts the server response using its private key.
Okay, it’s probably more complicated than that. But, we’re surely on the right track.
Only public keys are transmitted over the wire. Intercepting the public keys only gives the attacker the opportunity to encrypt content, not decrypt. If you want to know more in-depth how HTTPS works, I suggest you to watch this video.
CIA is more or less known as the Central Intelligence Agency. Here it’s a whole different. We’ll keep things simple here as it’s not the purpose to dive deep into the security subject. CIA means:
- Confidentiality: no one other than the emitter and the receiver should be able to read the data,
- Integrity: data should remain intact among transport,
- Availability: Denial service attacks should be prevented.
HTTPS meets CIA whereas HTTP don’t. In other words, when communicating in plain HTTP, attacks can:
- intercept the data and read it on the fly,
- modify the intercepted data,
- avoid data to be served by using D.O.S. (Denial Of Service) attacks.
Privacy is important
It’s our responsibility to protect our users from account hijacking and, in general, from as many threats as possible. Digital Nomads are more exposed than others to unsecure HTTP network interception:
Digital nomads are individuals who leverage telecommunications technologies to perform their work duties, and more generally conduct their lifestyle in a nomadic manner.
Even if you are connecting from a secure network connection at home, your DSL connection is not safe. You’re not safe from Goverments spying the internet communications by connecting directly on a giant optical fiber. Take a look at PRISM, a global internet surveillance program by the NSA. Wikipedia enabled HTTPS by default for non-logged users in August 2013. We think it should have been done years before.
The line between public and private information is becoming thinner. Even if the companies who are collecting information about you don’t have any bad intention, everyone has a legal right to privacy. Companies and goverments use publicly available information to profile you. Any non-secure website you visit maybe be used to get more details about you (news you read, videos you watch, music you listen).
Possible Plain HTTP Attacks
The following sections show you the possible attacks a hacker may conduct. All those attacks imply MITM (Man in the Middle) attacking technique.
The attacker passively (without altering data) listens to data being transported over the network.
Sniffing HTTP traffic passively
This usually happens by modifying user’s proxy settings or with DNS spoofing.
Phishing aims to redirect the user to a pirate server which serves a fake copy of the website the user wants to explore.
The user is redirected to a fake website
The fake website aims to collect any sensitive information like logins, passwords. These information are usually sold by the hackers.
Now that we have seen how HTTP is vulnerable to account hijacking and identity theft, we are going to see how HTTPS improves the situation.
By using an HTTPS protected server, attackers cannot fake the remote server. The Man-In-The-Middle attack is not possible anymore.
The attacker cannot fake the remote server
Analytics works better
Google Analytics cannot provide information about HTTPS referrals when your site is non-HTTPS. If your user is coming from an HTTPS website on your HTTP one, you won’t have any referral information. This is a good reason to switch over HTTPS. Other website receiving traffic from you will probably switch to HTTPS too.
HTTPS Improves SEO
It’s a know fact: Google ranks HTTPS secured website slightly better.
(..) we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal (..) But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.
— Zineb Ait Bahajji and Gary Illyes, Webmaster Trends Analysts
HTTPS with SPDY is faster
At least, with SPDY. SPDY is now obsolete but will be the standard when the internet will switch to HTTP/2. HTTP vs HTTPS shows how fast HTTPS+SPDY can be compared to plain HTTP when loading many images.
HTTPS with SPDY 78% faster than plain HTTP in this test.
And the bad
Yes, HTTPS has some counter parts. Should we compromise our users security for a slight performance increase? We don’t think so.
HTTPS increases server cpu usage
At least, this is true until HTTP/2 will be the standard. With HTTP/2, there is only a single SSL key exchange for all the requests made to a same server. This saves a lot of SSL overhead.
There is a performance penalty both on client on server side. Both client and server need to encrypt / decrypt the traffic causing a higher cpu usage. Although, you shouldn’t give over switching to HTTPS just because of higher server usage. You should profile your server performances with HTTPS switched on to evaluated the real performance impact.
SSL encryption processing time is usually insignificant compared to server processing time to generate the page content. Servers which are serving static web pages that can be easily cached suffer much more from the performance penalty.
IsTLSFastYet, which is a website in favor of using SSL TLS certificates, aims to show that TLS SSL encryption performance penalty is negligible:
On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that. Adam Langley, Google
HTTPS increases page load time
Beware, this won’t be true anymore with HTTP/2.
SSL Performance penalty VS total load time for a static resource from Amazon CloudFront.
In the example graphic above, we see that 32ms on a total of 226ms are spent in SSL layer on client side. Roughly 14% of the time is spent in SSL layer. The client side machine is a Core I5 3570k (3.8Ghz Quad-core with 16GBytes RAM) using Google Chrome. Multiply this by the number of resources to gather, and it starts to be significant.
We’re not telling you that HTTPS is bad because it consumes more resources. We just want to be honest about what to expect when switching to HTTPS. It wouldn’t have been fair to show you only the pros and not the cons. Every improvement comes with a trade-off.
How to improve HTTPS Speed
The best way to improve HTTPS requests speed is to:
- decrease the server processing time: the time gained is traded with the time lost during SSL encryption / decryption,
- use a Content Delivery Network (CDN) for static resources to serve them quicker than from a central server,
- increase server cpu speed to decrease SSL encryption processing time,
- have an HTTP/2 / SPDY compliant server. This is by far the most impacting performance improvement.
For example, enabling SPDY on an Apache Server is as simple as installing and enabling mod_spdy. HTTP/2 Apache module is also under active development. The next Apache big release should support HTTP/2 by default.
HTTPS Quality Check Tool
Our Website owned an A SSL grade