3 Feb 2015

Web security: HTTPS

After your users' web browser retrieved your site address through a DNS request, it will connect to your site. In order to keep your users' privacy (eavesdropping, man-in-the-middle attacks) and prevent data flowing between your site and your user to be tampered with, the connection must be encrypted. For the web that's using HTTPS instead of HTTP, which is tunneling HTTP requests in an encrypted channel.

There are several points to take into account when deploying HTTPS:

cryptographic protocols,
keys and ciphers,
certificates,
compatibility,
overhead (CPU, bandwidth, latency)

Cryptographic protocols

HTTPS supports several encryption protocols, currently:

SSLv2
SSLv3
TLSv1.0
TLSv1.1
TLSv1.2

Some known vulnerabilities in SSLv2 and SSLv3 make them unsuitable for the task anymore and must be disabled. TLSv1.0 also has some vulnerabilities but they can be mitigated.

Keys and ciphers

The cryptographic protocol defines how to establish the connection, the session key and the cipher defines how the data are encrypted. When configuring your server you should ensure that the strongest session key/ciphers are used in priority.

Certificates

During the connection establishment your server will provide a certificate to prove its identity. This certificate is signed by a Certification Authority (CA) who has checked that you are who you pretend you are. The are several levels of certification, with different prices. Some companies like StartCom provide free Class 1 certificates.

Your users' web browser will check if there is a path between your certificate and a trusted CA (your server may need to provide some intermediate certificates to complete the chain, so be sure the CA authority you buy your certificate to is linked to a CA trusted by web browsers).

The certificates are signed, some signature algorithms are known to be weak like (MD5 or SHA1) so be sure to use a strong enough one (at least SHA256).

The certificate is related to your server private key, the key element to identify your server. Be sure to create a big enough one, as of today you should not create a key smaller than 2048 bits (4096 bits being a better choice).

Compatibility

Unfortunately lots of web clients do not support the latest cryptographic protocols. For instance even if TLSv1.0 has some vulnerabilities, it's still very common has its vulnerabilities can be mitigated and lots of installed web clients does not support newer TLS versions.

Overhead

This is a kind of non-issue. As reported by some Google engineers, the overhead of switching from HTTP to HTTPS for GMail was about 1 % more CPU load, 2 % more bandwidth and 10 kB more memory by connection.

The main drawback is when opening the connection the TLS handshake adds several TCP roundtrip which increases the latency.

Misc

You can check online that your HTTPS is properly configured and get plenty of advices: https://www.ssllabs.com/ssltest/index.html

I was thinking that since HTTP is not secure by default, maybe we should force everybody to do HTTPS all the time. It looks like the Chromium developers (the open source part of Google Chrome) are thinking the same way and are planning to gradually show HTTP connections as insecure.

So, you are developping a web application? Make it accessible over HTTPS only!