What are the pros and cons of site wide SSL (https)?

Question

What are the pros and cons of encrypting all HTTP traffic for the whole site through SSL, as opposed to SSL on just the login page?

Answer 1

Since most of the other answers here deal with the downsides of site-wide SSL (mainly performance issues - btw these can easily be mitigated by offloading the SSL termination, either to an SSL proxy box, or an SSL card), I will point out some issues with having only the login page over SSL, then switching to non-SSL:

• The rest of the site is not secured (though this is obvious, sometimes the focus is too much on just the user's password).
• The user's session id must be transmitted in the clear, allowing it to be intercepted and used, and thus enabling the bad guys to impersonate your users. (This is mostly what the Firesheep hubbub was about).
• Because of the previous point, your session cookies cannot be marked with the secure attribute, which means that they can be retrieved in additional ways.
• I have seen sites with login-only-SSL, and of course neglect to include in that the Forgot-password page, the Change-password page, and even the Registration page...
• The switch from SSL to non-SSL is often complicated, can require complex configuration on your webserver, and in many cases will pop up a scary message for your users.
• If it's ONLY the login page, and f.e. there is a link to the login page from your sites home page - what is to guarantee that someone won't spoof/modify/intercept your homepage, and have it point to a different login page?
• Then there is the case where the login page itself is not SSL, but only the SUBMIT is - since that's the only time the password is sent, so that should be safe, right? But in truth that removes from the user the ability to ensure ahead of time that the password is being sent to the correct site, until its too late. (E.g. Bank of America, and many others).

Answer 2

The "server overhead" increasing as a significant "con" is a common myth. Google engineers noted that when switching gmail to 100% SSL they deployed no additional hardware, and that SSL accounted for less than 1% increase in CPU load and 2% in network traffic. Stackoverflow also has a few questions dealing with this.

Answer 3

From the zscaler blog entry Why the web has not switched to SSL-only yet?

"With the session-sidejacking issue highlighted once more by Firesheep, a many people have asked me why more websites, or at least the major players (Google, Facebook, Amazon, etc.) have not enabled SSL by default for all communication. Indeed, encryption is the only way to ensure that user sessions cannot be easily sniffed on a open wireless network.

This sounds easy - just add an s after http in the URL! It's not actually that easy. Here are some of the challenges."

Summary of challenges (cons):

• "server overhead"
• "increased latency"
• "challenge for CDNs"
• "wildcard certificates are not enough"
• "mixed HTTP/HTTPS: the chicken & the egg problem"
• "warnings are scary!"

Answer 4

Ars Technica has an excellent article explaining some of the challenges in deploying SSL sitewide.

One big one: most ad networks do not provide any way to serve ads over SSL. Moreover, if you embed ads (delivered over HTTP) in a main page that's delivered over HTTPS, browsers will issue scary mixed-content warnings, which you do not want to subject your users to. So, ad-supported sites will likely find it very difficult to transition to SSL sitewide.

The article also outlines some other challenges, such as third-party widgets, analytics, embedded videos, etc.

Answer 5

A downside which is missed in the other answers above is the massive reliance these days on content distribution networks (eg Akamai) - many web pages in current usage grab content from a variety of domains so the browser would need to have certs for each of these or warnings would pop up. And then of course, if the attacker used a CDN platform which the browser already had certs for, they may not get a warning when they should.

Tricky problem with the way applications and content are currently delivered.

Answer 6

OK, this is an ancient question, so my answer will probably languish down here at the bottom. However, I have something to add to the 'cons' side.

HTTPS Latency:

Having a low client-to-server HTTP latency is critical for making fast-loading, responsive websites. And fast page load times increase end user happiness.

TCP/IP alone has the famous TCP 3-way handshake, i.e. the initial connection setup for plain HTTP over TCP requires 3 packets. When SSL/TLS is used, the connection setup is more involved, meaning the latency for new HTTPS connections is unavoidably higher than plaintext HTTP.

Note that the impact of this can be reduced (but not eliminated) by re-using the HTTPS connection many times, i.e. using persistent connections, and other performance optimizations such as SSL False Start.

Modelling exactly how much HTTPS slows down page loads is complicated, because all modern browsers download HTTP objects in parallel whenever possible. Even so, the higher initial connection setup time is both significant and unavoidable with current technology; so the increased new connection latency is an important consideration.

Answer 7

Pros is definitely increased security. Cons could be relatively slower connections, more intensive CPU usage, required accurate certificates management, some costs for certificate (if you do not use self-signed certs). But in recent times there is a spreading practice to use https and those cons comes to background due to benefit for end-users and increased trust to a company that is providing service.

Answer 8

Other downsides (touched upon by others) is a lack of caching which will obviously affect speed. Also, some server variables are not available - like HTTP_FORWARDED_FOR I think.

Answer 9

All good point mentioned here, however, I mis the con cost! And by cost I dont mean only buying the certficate, but having the proper infrastructure to manage certificates, revocations, dedicated crypto modules to decrease CPU load of the webserver, etc.

Answer 10

Benefits of keeping the entire site encrypted:

• you won't piss off your privacy-concerned visitors by sending them plaintext after login.
• less risk for mistakes when redirecting/linking between http and https parts of the site.

The con: ?

Read the testimonials from google and others. It doesn't have to be costly to go 100% https.

Answer 11

Other answers have asserted a "chicken/egg problem" due to mixed-content warnings that makes the HTTP->HTTPS migration difficult. It is an issue, but I don't think it is as difficult as they make it out to be.

Mixed content can be addressed using protocol-relative URLs and the same scanners that you should be using to find XSS problems.

RFC 3986 section 4.2 uses the term network-path reference:

A relative reference that begins with two slash characters is termed a network-path reference

First scan your pages until you find all uses of http://example.com/ in same-origin links, images and other site assets and replace them with protocol-relative URLs (//example.com/...). This lets you have the same HTML served regardless of whether you are serving a page via HTTP or HTTPS and puts you in a much better position to rollback if something goes wrong later in your migration.

Then set up permanent HTTP->HTTPS redirects so that existing URLs on sites outside your control continue to work and start serving via HTTPS. Using a permanent redirect with aggressive cache headers will help search engines transfer page-rank and speed up the site for return visitors.

You should of course keep your scanners looking for mixed content so you catch regressions.

Answer 12

I know this is an old question/thread, but I just wanted to point out a huge PRO for doing side-side SSL.

SPDY

Using mod_spdy on Apache requires SSL.

I you haven't deployed SPDY yet, get it done! Both Chrome and Firefox support the protocol, as well as Opera.

That is about half of your users that will be able to take advantage of SPDY.

Answer 13

There is one benefit of using site-wide SSL that nobody has mentioned here: it prevents people from changing your site's content while the content is en route from your server to your clients.

This may be important in some places where ISPs cannot be trusted. It is possible for an ISP to modify unencrypted data before it reaches a client, which is undesirable at times.