HTTPS notes

4th January, 2014

Benefits of HTTPS-only

Security

Anything less than HTTPS-only is not secure, due to session highjacking and Man-in-the-middle attacks (e.g. an attacker creating a fake login screen).

HTTPS also prevents more prosaic threats, such as preventing Wifi providers or ISP's injecting ads or malicious javascript into your web page, along with preventing users' traffic being eavesdropped on public hotspots. And HTTPS gives users the padlock-icon assurance that the page has not been tampered with or snooped-on.

SPDY

Using HTTPS-everywhere allows the use of SPDY to speed up your site (by prioritizing and multiplexing page resources over one connection).

Simplicity

Moving a partially HTTPS site to HTTPS-only can drastically simplify code and server configuration. Along with the obvious benefits of less code and blanket HTTPS-redirection, another benefit is the ability to use simple abstractions to ensure included resources begin with https:// to avoid mixed-content issues.

Drawbacks of HTTPS

Mixed-content issues

Need to be careful not to include non-HTTPS resources, to prevent mixed-content warnings (or worse, some browsers may also not load insecurely included static resources).

This may prevent use of some 3rd party scripts which do not support HTTPS (though fairly rare).

Also causes problems with allowing users to embed 3rd party resources (e.g. for images, would need to make your own cache).

Handshake slowdown

The HTTPS handshake causes an initial slowdown - be sure to use a keep-alive connection to ensure the HTTPS connection is reused, and the handshake is not repeated (Apache reference, Nginx reference).

There are also ways to reduce handshake time.

Note the handshake may cause severe slowdowns or failed requests with very poor internet connections.

CDN concerns

If using a CDN, you must use one which supports HTTPS. If you want your own domain with a CDN, SSL certificates can be very expensive (e.g. $7200/year for Amazon's Cloudfront).

Other issues

Load balancing can become more complicated.
If you have social buttons on your site before switching to HTTPS-only, these will refer to HTTP resources, you will need to ensure the buttons have the correct href to retain the correct count.

HTTPS Myths

HTTPS does not use lots of CPU.
HTTPS does not slow down pageloads significantly, as long as you use a keep-alive connection (see above).
HTTPS is not expensive, you can get free or cheap certificates, and can use SNI to run multiple sites.
HTTPS is not difficult to set up, a simple Nginx SSL setup would take just a handful of lines.
HTTPS is not bad for SEO, so long as you have appropriate redirects.

HTTPS Pitfalls

Including non-HTTPS resources

This is an easy mistake to make without suitable abstractions. This can result in as little as a broken padlock, a pop-up warning, or as much as insecurely included images/css not being displayed to the user.

Not using HTTPS everywhere

Risks include interception of session token, MITM attacks, accidentally not using HTTPS when required, accidentally causing mixed-content warnings due to code complexity.

Not using HSTS and secure cookies

See futher reading, below.

Redirecting HTTP to HTTPS

Allowing redirection from HTTP to HTTPS leave a security gap during the initial request, allowing the possibility of a MITM attack.

This is a little controversial, most site maintainters prefer redirecting HTTP to HTTPS, rather than disabling HTTP altogther.

Not using keep-alive connections

This will slow down pageloads by requiring an HTTPS handshake for every request(see above).

Not enabling caching

Cachable resources will not be cached by the client unless you enable caching with the header Cache-control: public (reference). Note this should only apply to non-sensative pages/resources.