81

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?

AviD
  • 72,138
  • 22
  • 136
  • 218
Olivier Lalonde
  • 5,039
  • 8
  • 31
  • 35

13 Answers13

62

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).
AviD
  • 72,138
  • 22
  • 136
  • 218
  • For more info about firesheep see [Ep. 272 of Security Now!](http://media.GRC.com/sn/SN-272.mp3) 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
47

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. Stack Overflow also has a few questions dealing with this: How much overhead does SSL impose? and HTTP vs. HTTPS performance.

Community
  • 1
user502
  • 3,261
  • 1
  • 22
  • 18
  • 17
    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 left the building 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 '14 at 19:01
  • 2
    You are [not Google](http://security.stackexchange.com/a/4376/2379). **Still** an overhead: https://www.httpvshttps.com/ – Pacerier Mar 28 '15 at 23:53
  • 2
    @Pacerier, according to that test (with a single data point, mind), http is ~1% faster than https. Seems to be in line with the answer, no? – Celos Apr 19 '16 at 08:20
  • @Pacerier And now the site says that http is 2655% _slower_ than HTTPS (mostly likely due to the benefits of HTTP/2, which is only supported over HTTPS). – Ajedi32 Nov 30 '17 at 17:03
25

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!"
Tate Hansen
  • 13,714
  • 3
  • 40
  • 83
  • 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 02 '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 04 '10 at 15:03
  • 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
  • 4
    @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 08 '14 at 20:54
19

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.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 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
15

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.

  • The [TLS 1.3 draft](https://tools.ietf.org/html/draft-ietf-tls-tls13) gets the handshake down to 1-RTT, and 0-RTT with session resumption. [Resumption has downsides](https://www.imperialviolet.org/2013/06/27/botchingpfs.html): if tickets are kept for more than a few hours you lose PFS. – Tobu Jan 20 '15 at 17:45
12

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.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • 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 05: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
  • 1
    Only if you try to create your own cert and it's not from a validated source... I know this is old but this is just wrong info. – iLLin May 15 '15 at 18:21
  • I really don't understand why this is an issue. What serious CDN would not have an SSL certificate that is trusted by all major browsers? – Mike Feb 20 '16 at 00:07
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.

5

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.

Community
  • 1
Mike Samuel
  • 3,873
  • 17
  • 25
4

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.

Spock
  • 149
  • 1
  • 2
  • 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 00: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 '14 at 13:44
  • 1
    @Jared: Even in 2014 SPDY had no way to negotiate up from HTTP/1.1 other than the SSL Next-Protocol-Notification, and there was no implementation which offerred and alternate solution. In 2016, SPDY is deprecated in favour of HTTP/2. A description of the benefits would have been helpful here: SSL/TLS adds a minimum of 1 extra RTT per connection (more typically 2) which has a HUGE impact on a site far away from its users. Comparisons with HTTP over vanilla TCP and SSL/TLS are somewhat meaningless in relation to the question asked as most of these benefits come from multiplexing. – symcbean Aug 29 '16 at 12:00
  • I know this is an old question/thread, but I just wanted to point out that SPDY is deprecated, unsupported and not used for quite a long time already. – ximaera Sep 09 '18 at 16:53
3

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.

Henri
  • 1,525
  • 10
  • 11
  • "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 06:29
3

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.

MattBianco
  • 231
  • 3
  • 9
3

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.

Nev Stokes
  • 458
  • 3
  • 10
  • 3
    It is possible to cache over HTTPS. Some versions of Firefox just require the "Cache control: public" response header. – realworldcoder Dec 04 '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. –  Jul 16 '11 at 21:36
  • Most CDNs will cache HTTPS content if configured with a server certiifcate (which is maybe a consideration in terms of how exposed the certificate is). Optional HTTP headers are somewhat irrelevant. – symcbean Aug 29 '16 at 12:03
2

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.

TRiG
  • 609
  • 5
  • 14