Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
To clarify, are you asking "pros and cons... of using SSL?" or "... using SSL for the WHOLE site as opposed to just login page" or something like that? –  AviD Nov 14 '10 at 2:37
    
@AviD: SSL for the whole site vs just login page –  Olivier Lalonde Nov 18 '10 at 14:48

13 Answers 13

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).
share|improve this answer
    
For more info about firesheep see Ep. 272 of Security Now! for the episode where they go in depth about firesheep (They begin talking about it at 44:05). –  Scott Chamberlain Jul 18 '11 at 14:22

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.

share|improve this answer
10  
Not as much a myth as outdated info: in the olden days, when dinosaurs roamed the Earth (i.e. in the late 1990s), computers were way slower than today, and so a much larger % of the CPU time would be given to SSL, even making the server CPU-bound. Modern servers are usually database-bound or disk-bound, that's not to mention more powerful CPUs - so that SSL is no longer a significant CPU hog. –  Piskvor May 22 '11 at 22:09
2  
@Piskvor also, the algorithms we have now are much faster, 3DES is 5 times slower than AES-128, even before using AES-NI (hardware acceleration) and nearly 25 times slower than AES-128 with AES-NI! –  Hubert Kario Feb 25 at 19:01

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!"
share|improve this answer
3  
Plus it gives the users a false sense of security: "well the whole site is using SSL so it's gotta be secure!" –  Steve Dec 2 '10 at 23:14
    
@Steve +1, SSL guarantee Encryption. Typically encryption is negotiated, but technically it's not required; an SSL session can be negotiated with authentication only. –  Chris S Dec 4 '10 at 15:03
    
+ "needs a unique ip-address per domain" –  Hendrik Brummermann Mar 27 '11 at 20:53
    
Not strictly true. Needs a unique IP address per certificate. But you can have a multi-domain certificate. Not necessarily sensible or practical, but feasible! –  Tom Chantler Mar 28 '11 at 22:08
1  
@SteveS: What, like locking your front-door gives you a false sense of security? Surely that's not a good reason not to, it's a reason to educate users better. –  nicodemus13 Jan 8 at 20:54

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.

share|improve this answer
    
Useful article to point people at. +1 –  Rory Alsop Mar 27 '11 at 8:28
    
Sorry, I can't edit your post for less than 6 chars, you made a typo here: "delivered over HTTP" where you meant "delivered over HTTPS" –  Shadok Oct 24 '11 at 10:44
    
Thanks, @Shadok! Fixed. –  D.W. Oct 24 '11 at 16:59

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.

share|improve this answer
    
I don't understand the statement that users need to have certs. The way SSL works is that the server needs to have a cert; the client doesn't need to have a cert (the server sends its cert to the client for validation). Web browsers already have everything they need (in particular, they contain a list of trusted root certs). It might help to explain/elaborate what you had in mind. –  D.W. Jan 17 '11 at 5:41
1  
@D.W. The user has to accept certs from the server. This acceptance process is the problem here. Most users are non-technical so don't understand what they are accepting. Have updated wording to clarify. –  Rory Alsop Jan 17 '11 at 12:46

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
3  
It is possible to cache over HTTPS. Some versions of Firefox just require the "Cache control: public" response header. –  realworldcoder Dec 4 '10 at 22:11
    
@realworldcoder: The latest browsers will generally cache HTTPS content when the proper Cache-Control headers are given. But all older browsers, and many or most public caches as deployed today will not cache SSL content. –  Jesper Mortensen Jul 16 '11 at 21:36

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.

share|improve this answer
    
"Buying the certificate": $25/year/cert from GoDaddy. "Proper infrastructure": GoDaddy's CRL. Dedicated crypto modules to decrease CPU load of the webserver": just get a second webserver and actually serve you customers well - with transport-layer privacy. –  yfeldblum Jan 17 '11 at 6:29

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
Can you spell out more explicitly what are the end-user-visible benefits of using SPDY, or the most compelling reasons for site operators to support SPDY? Also, why does support for SPDY require you to turn on SSL for the whole site, as opposed to just part of the site? –  D.W. Jun 17 '13 at 0:04
    
@D.W. It doesn't require you to turn on SSL (not sure why Spock said it does.) But the benefits to the end user is a faster loading website. Tests show that there are significant performance gains. The chromium project page claims 27%-60% faster than plain tcp and 39%-55% faster than SSL/TLS when tested against 25 of the top 100 sites on the internet. –  JaredMcAteer May 21 at 13:44

If a website is managed by a CMS which a non-technical user can use to edit pages, they might edit the HTML to include references to off-site resources, such as images, over HTTP. I've built a shopping site which uses SSL only where necessary, and redirects other pages back to HTTP, because otherwise you'd get mixed content warnings due to all the off-site images the owner has stuck into the site.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.