Is it time for 100% https?

Last week, the Chrome team announced that from July 2018, all pages that are served over HTTP will be marked as unsecured. This was warmly received by the majority of the community. Mozilla is likely to issue a similar statement in the next few months.

However, I also saw voices (on the Polish internet, by the way) saying that this is an exaggeration. That for a simple, static page you don’t need https. In addition, there have been a few cases in the history of the internet where switching to HTTPS was an enterprise on the scale of landing in Normandy. This was mainly the case for large content sites, such as Guardian, which have been operating for years. Others fear longer response times and increased CPU usage. After all, there are voices saying that the internet is not ready. Are there really cases where https is more western than it’s worth?

This will change the designation of pages served after HTTP (source: security.googleblog.com)

What is https?

In order to be able to talk about whether this is an exaggeration or not, we need to tell ourselves what the HTTPS protocol is and what problems it solves.

You all probably know that HTTPS is an encrypted version of HTTP. Currently, this encryption is most often done using the TLS protocol-the successor to SSL. When someone says SSL, he probably means TLS. SSL is history and I will not talk about it. To establish a secure connection, the client and server use the TLS Handshake subprotocol. The initial handshake itself looks like this:

As you can see, the client first receives a certificate from the server, the validity of which must be confirmed on its side. It is important here that the certificate is signed by a trusted Certification Authority (CA) – this is the only way the client has a basis to confirm that it was sent by a real siteand not, for example, an attacker.

In the second step, the client sends a key to the server that will be used to further encrypt the data. This key does not fly over the network as plain text, but is encrypted with the public key that was attached to the certificate. The server reads the key sent by the client on its side using the private key (so asymmetric encryption is used at this stage) and confirms that everything went OK. That concludes the handshake.

Once executed, https uses the TLS Record subprotocol to transmit data (this subprotocol was also used for greeting underneath). The data is encrypted with a symmetric key generated during the handshake procedure.due to the fact that only the browser and the server know the key, it is not possible to obtain meaningful data from eavesdropped communication. HTTPS it also protects against modifying messages during transport.

During https communication, the name of the host to which the browser connects can be revealed (which will still be sent as plaintext at the time of the DNS query and will be discoverable in the IP layer of each request) and the local time on the computer and server. So not too much 🙂

Is this even worth a candle?

Even if you serve a simple, static HTML page with a topic that is not at all a reason for the visitor to be ashamed, the practice shows that there is something to protect yourself from.

It’s about injecting unwanted content to your website with the help of man in the middle attack. This “man in the middle” will really be the internet provider, proxy or Wi-Fi network operator. Many operators around the world, such as Comcast, Rogers, and connect broadband, have used HTTP sites to display system messages, incentives to buy TV packages, and advertisements. In wi-fi networks, the situation looks worse, because some of them are created in order to injection of malware.

You’ll think, ” not my problem.” However, I think it’s nice to take care of the basic safety of people who visit your site.

In addition, most of the new and interesting features of browsers work only with https. For example, geolocation, push notifications, Web Share API, Bluetooth API, Payment Request API, amp or service Workery. HTTP / 2 will not work without encryption. That’s why for modern sites, using HTTPS is something completely natural. There are still sites that don’t use the new, great ficers, so let’s see if there are any contraindications to abandoning unencrypted calls.

But https is all trouble! So a couple of myths about this

SSL certificate is expensive

Nope

Certificates are available on the market for several tens of zlotys, which means it costs less than an hour of your work. In addition, such an initiative as let’s encrypt was created-that is, the certification center, which issues its certs for free. The development of the project is supervised by the Linux Foundation, and sponsors are many large IT companies. This is not a bush company. Let’s encrypt provides a pretty cool client for generating and renewing certificates. It’s really not complicated 🙂

HTTPS will slow down my service

It depends on the settings, but in general it is not

Yes, https requires additional roundtrips. This can be very painful if the roundtrip is long (on 3G it can be up to several hundred Ms). However, some believe that HTTPS slows down strongly. Yes, in times of slow internet, high pings and weak servers this was a problem. That’s not true anymore. In addition, we currently have a few tricks that will save a little time. This is HSTS, TLS false start or TLS session Resumption.

Support for encryption and decryption requires computing power, but this is negligible. In 2010 Gmail enabled HTTPS for all resources and after this transition SSL/TLS was responsible for less than 1% of CPU usage.

Thanks to HTTPS you can pull too real ace of Spades – HTTP / 2. There are a lot of benchmarks available on the web on real sites, which confirm that the new protocol allows you to load web pages much faster. It is often possible to reduce by several tens of percent the time it takes to load the entire page. It is able to make amends for the time spent on the handshake procedure.

HTTPS is hard to set up

No.

Even if you have not yet encountered TLS certificates or https setting, it does not hurt. On the internet there is a lot of material on this subject. And I assure you, these are not instructions with a billion steps and easy to find. So you don’t have to be an admin or a DevOps to be able to do it, just follow the instructions.

Difficulties can arise when using archaic systems, load balancers, etc. And this is a much bigger problem than the lack of HTTPS!

I don’t use HTTPS because I see a lot of content from third-party sources that don’t use it either.

Okay, that’s a problem.

You will have problems downloading scripts or iframes that are served over HTTP on a page from https. It is slightly better with pictures-this is something that will be displayed, but a warning will appear in the console. You can use the Content-Security-policy-report-only header to prevent the warning from appearing and the browser from reporting the incompatibility.

The problem can be when you want your site to appear as a referrer on a site without encryption. By default, this header is removed when switching from HTTPS to http. One solution is to use Referrer-Policy, which allows you to pass the referrer page despite switching to an unencrypted connection. The downside is that this header is supported by Chrome, Firefox and opera.

Switching to HTTPS will ruin my SEO

In the long term-quite the opposite.

Google copes well with any URL changes, and in particular it is very well adapted for migrating an HTTP page to HTTPS. There are several guides on their support pages. In principle, once you take care of HTTP 301 redirects from the unencrypted to the encrypted version, everything should be OK.

In addition, Google uses HTTPS as a light positive signal. In view of what the Chrome team is doing, it is very likely that soon unencrypted pages will be punished in some way by the algorithm of the most popular search engine.

My APIs only consume native/embedded applications, so no one will see a warning about No HTTPS

The network is not yet 100% HTTPS ready

But when will it be?

At this time in 2014, only 28% of websites were using HTTPS. Today it is almost 70% (data from Firefox telemetry). You can wait until we reach 100% organically, or you can take a bold step forward. The internet looks different than it used to, and there’s no point in looking back. How much longer are we going to hang out?

It seems to me that Chrome’s team isn’t getting ahead of themselves. Many organizations have expressed a desire to recognize HTTPS as the default protocol. W3C wrote in 2015 that we should actively prefer secure connections. The IETF wrote that pervasive monitoring is a type of attack and all new protocols should be encrypted. The American CIO Council believes that the widespread use of HTTPS reduces the attractiveness of tracking unencrypted network traffic. And that’s all right. Therefore, 2018 is just in time to slowly start to forget about HTTP and move on to solving other problems.