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).

Authenticity

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 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.

Android is picky about intermediate CA's

And will refuse to display the site without careful configuration, see 1, 2.

Further reading

When switching to HTTPS-only be sure to also use HSTS & secure cookies. These measures combined provide good security for all requests, except for an initial HTTP -> HTTPS redirect (reference).

HSTS

HTTP Strict Transport Security (a.k.a. HSTS) - a header instructing client to use only HTTPS, this prevents MITM attacks by enforcing the client will not make requests to the domain through HTTP - apart from the initial request (more info).

Secure cookies

Secure cookies - a cookie attribute instructing the client to only send the cookie over HTTPS.

Resources

SSL server test
Easy tips to accelerate SSL
MozillaWiki Security/Server Side TLS
Why No Padlock?
Best practices

References

http://erik.io/blog/2013/06/08/a-basic-guide-to-when-and-how-to-deploy-https/
https://news.ycombinator.com/item?id=6946962
http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose
http://stackoverflow.com/questions/149274/http-vs-https-performance
http://blog.httpwatch.com/2009/01/15/https-performance-tuning/