Using HTTPS-everywhere allows the use of SPDY to speed up your site (by prioritizing and multiplexing page resources over one connection).
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.
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).
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.
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).
- 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 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.
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.
Risks include interception of session token, MITM attacks, accidentally not using HTTPS when required, accidentally causing mixed-content warnings due to code complexity.
See futher reading, below.
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.
This will slow down pageloads by requiring an HTTPS handshake for every request(see above).
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.
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).
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 - a cookie attribute instructing the client to only send the cookie over HTTPS.