130

If I was setting up a server, and had the SSL certificate(s), why wouldn't I use HTTPS for the entire site instead of just for purchases/logins? I would think it would make more sense just to encrypt the entire site, and protect the user entirely. It would prevent problems such as deciding what has to be secured because everything would be, and it's not really an inconvenience to the user.

If I was already using an HTTPS for part of the site, why wouldn't I want to use it for the entire site?

This is a related question: Why is https only used for login?, but the answers are not satisfactory. The answers assume you've not been able to apply https to the entire site.

Community
  • 1
  • 1
Malfist
  • 31,179
  • 61
  • 182
  • 269
  • 2
    It amazes me that financial services companies still use http. – Tom Hawtin - tackline Apr 30 '10 at 16:35
  • 15
    @Tom I wish some of the sites that send me phishing messages would use https for their forged sites, so I know I am giving my data to the right phisher. – WhirlWind Apr 30 '10 at 16:37
  • Thanks for asking this question. I was assuming performance was *the* reason and it would be much worse than http. Seeing the answers, it seems the performance is not terribly bad, which makes me too wonder. – Sundar R Apr 30 '10 at 16:54
  • @WhirlWind Yeah, it's like phishers never use https even for login! – Tom Hawtin - tackline Apr 30 '10 at 17:10
  • One reason: performance. Also, sometimes encrypted communication blindly gets throttled by ISPS. – Wadih M. Apr 30 '10 at 19:40
  • See also [this question on ITsec](http://security.stackexchange.com/q/258/33). – AviD May 04 '11 at 21:56
  • https traffic cannot be cached, so you will see more requests and more data being downloaded.. this also affects user experience (depending on how your site is contructed) as browser cache will not cache script, images etc so every site navigation may end up pulling all assets for every click. – Soren Nov 03 '13 at 02:07
  • 5
    I think you picked the worst answer on the page, with currenlty 11 down votes. The answer you chose has a total disregard for security and best practices. – rook Mar 26 '15 at 21:22
  • 6
    This question really deserves an educated modern answer. – Old Badman Grey Aug 02 '16 at 02:00
  • 1
    It's interesting how the general mood of things can change in only 7 years. This is truly an amazing industry. – gd1 Mar 27 '17 at 18:49

15 Answers15

24

In addition to the other reasons (especially performance related) you can only host a single domain per IP address* when using HTTPS.

A single server can support multiple domains in HTTP because the Server HTTP header lets the server know which domain to respond with.

With HTTPS, the server must offer its certificate to the client during the initial TLS handshake (which is before HTTP starts). This means that the Server header hasn't been sent yet so there is no way for the server to know which domain is being requested and which certificate (www.foo.com, or www.bar.com) to respond with.

*Footnote: Technically, you can host multiple domains if you host them on different ports, but that is generally not an option. You can also host multiple domains if your SSL certificate is has a wild-card. For example, you could host both foo.example.com and bar.example.com with the certificate * .example.com

Eadwacer
  • 1,138
  • 7
  • 10
  • 5
    Wouldn't having a wildcard SSL certificate solve this problem? – Rob May 03 '10 at 18:06
  • The footnote contradicts the answer :/ you can use wildcard certs and host any domains.http://en.wikipedia.org/wiki/Wildcard_certificate – lucascaro Dec 16 '14 at 15:20
  • 25
    This issue has long been solved by Server Name Indication, which is supported by all major browsers nowadays. http://en.wikipedia.org/wiki/Server_Name_Indication – tia Feb 28 '15 at 03:08
  • @tia except not all web servers support it – Northstrider Apr 02 '15 at 19:52
  • 2
    @meffect ...But plenty do, including apache2, nginx, lighttpd, and nodejs. Besides which, the developer gets to choose what reverse proxy they use for HTTPS tunneling. Saying "no clients support it" would be a valid point if it were true because it's something the developer has no control over and must account for. However, saying "some servers don't support it" is largely irrelevant, precisely because it doesn't need to be accounted for. Especially when all the mainstream servers **do** actually have support. – Parthian Shot Jul 20 '15 at 17:20
  • It is correct, that with SNI you could host multiple sites on HTTPS on the same server / IP address. But there might be a larger annual fee for such multisite certificates than for a single site or wildcard certificate – Vering Nov 02 '15 at 19:30
  • Huh... I do this with nginx and I experience no such issues. – anna328p May 09 '17 at 19:27
17

I can think of a couple reasons.

  • Some browsers may not support SSL.
  • SSL may decrease performance somewhat. If users are downloading large, public files, there may be a system burden to encrypt these each time.
rook
  • 66,304
  • 38
  • 162
  • 239
WhirlWind
  • 13,974
  • 3
  • 42
  • 42
  • 139
    What browsers do not support SSL? – Malfist Apr 30 '10 at 16:27
  • 6
    Some compiles of lynx will not support it. If you are only supporting newer browsers, you should be fine. – WhirlWind Apr 30 '10 at 16:28
  • I believe SSL main performance problem comes from establishing the connection. / https can redirect to http. – Tom Hawtin - tackline Apr 30 '10 at 16:34
  • The SSL performance burden is highly dependent on the characteristics of the site. AES can be fairly CPU-intensive to perform, for example. – WhirlWind Apr 30 '10 at 16:35
  • 5
    I was looking through this: http://iweb.tntech.edu/hexb/publications/https-STAR-03122003.pdf "Once the server is saturated, the system performance of HTTPS achieves around 67% of HTTP in terms of throughput." – WhirlWind Apr 30 '10 at 17:09
  • @The Rook That's why I used the adjective "some." Saying "all browsers support SSL" would be incorrect. – WhirlWind Apr 30 '10 at 20:47
  • 2
    @WhirlWind yeah I respectfully disagree with almost everything you have said. My main concern is that the cookie value will be leaked when you are not using https for some pages. Make sure to read A3: "Broken authentication and session management" in the owasp top 10: http://www.owasp.org/index.php/Category%3aOWASP_Top_Ten_Project – rook Apr 30 '10 at 20:52
  • 2
    Is the third point re. hoe page legitimate? I type gmail.com and it automagically goes to https. What browsers can't do this? – djechlin Mar 04 '13 at 16:05
  • 18
    I don`t buy this explanation. 1) Don`t use a browser that doesn`t support SSL in 2013. 2) even google uses SSL right now 3) properly setup, you can redirect http traffic to the right https link. – jfyelle Mar 12 '13 at 14:46
  • 4
    Bad answer, why so manu upvotes? What browser on earth doesnt support ssl and users don't have to remember typing https, can be handled with redirects – Sanne Jul 20 '13 at 12:45
  • 3
    Interesting article about stackoverflow itself not using https http://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/ – Sanne Jul 20 '13 at 12:50
  • 1
    Its quite easy though to redirect a http:// to https://, easy being mod_url_rewrite. Otherwise a simple header redirect. For example, ( bare in mind this is quick and untested ) $current_url = $_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"]; if (!strpos($current_url,'https://')) { $url = str_replace('http','https',$current_url); header("Location: {$url}"); } – Christopher Shaw Feb 05 '15 at 12:42
  • 4
    It is answers like this that make me which i had two down votes. This is terrible! – rook Mar 26 '15 at 21:21
  • 1
    –1. Comments above already explain the problems of this answer. – texnic Jun 14 '16 at 22:03
  • @Malfist Older versions of Chrome have pretty poor SSL support. They simply will not load HTTPS sites, meaning you can't use Chrome on Windows XP for secured sites. Other browsers like IE or Firefox, etc. will work, though. – InterLinked Nov 04 '19 at 02:18
13

SSL/TLS isn't used nearly often enough. HTTPS must be used for the entire session, at no point can a Session ID be sent over HTTP. If you are only useing https for logging in then you are in clear violation of The OWASP top 10 for 2010 "A3: Broken Authentication and Session Management".

rook
  • 66,304
  • 38
  • 162
  • 239
  • This may be too broad of an assumption. There is no reason session state can't be managed separatly for http and https via single https login operation. Its likely to be more work than its worth and invite security related bugs but would not seem to automatically constitute a clear violation. – Einstein Apr 30 '10 at 18:19
  • @Einstein please read the OWASP A3, it is very clearly worded. Keep in mind that the attacker doesn't need the username/password if he has the cookie from an authenticated session. – rook Apr 30 '10 at 18:44
  • Site provides mixed https/http. https login provides separate low and high security session tokens. Low security tokens assigned only to http session would not work for operations requiring high security. From my read OWASP A3 is mearly illuminating the basic problem of possibility of high security access via low security transport. – Einstein Apr 30 '10 at 20:34
  • @Einstein So then you disagree that Session id's are used to authenticate web browsers? Take into consideration this attack pattern, in xss attacks you are trying to obtain the value of `document.cookie` so that the attacker can use this to authenticate. This value can also be obtained by sniffing traffic, which https stops. I'm not exactly sure what your point is. – rook Apr 30 '10 at 20:50
  • In your scenario the session id for http would be worthless for https protected resources if a system were to create two separate sessions for a single authentication action to allow both protocols to be used without https session and associated resources exposed by the http session cookie. For example http session might be used for identification of access to public resources for reporting purposes or access to public message boards but they would not be valid for secure resources. – Einstein May 01 '10 at 21:48
  • @Einstein See the [HSTS flag](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security). It's part of why there's no excuse for using insecure channels. Because if you set that flag when the user's browsing your site from home, they can safely browse your site at the airport with the knowledge that exploit-laden HTTP resources can't be injected into their browser, since when they navigate to the domain the browser will start the session HTTPS, rather than getting a redirect to HTTPS after trying HTTP. `sslstrip` is harder to use when someone accesses HSTS sites. – Parthian Shot Jan 29 '16 at 20:13
12

Why not send every snail-mail post in a tamper-proof opaque envelope by Registered Mail? Someone from the Post Office would always have personal custody of it, so you could be pretty sure that no one is snooping on your mail. Obviously, the answer is that while some mail is worth the expense, most mail isn't. I don't care if anyone reads my "Glad you got out of jail!" postcard to Uncle Joe.

Encryption isn't free, and it doesn't always help.

If a session (such as shopping, banking, etc.) is going to wind up using HTTPS, there's no good reason not to make the whole session HTTPS as early as possible.

My opinion is that HTTPS should be used only when unavoidably necessary, either because the request or the response needs to be safeguarded from intermediate snooping. As an example, go look at the Yahoo! homepage. Even though you're logged in, most of your interaction will be over HTTP. You authenticate over HTTPS and get cookies that prove your identity, so you don't need HTTPS to read news stories.

David M
  • 4,325
  • 2
  • 28
  • 40
  • LOL!!! Great! I bet the rogue postman opening the envelope with "Glad you got out of jail" will freak his pants a bit and reseal it perfectly.. – Andrei Rînea Nov 08 '10 at 00:15
  • 21
    If registered mail cost 1% more instead of 300% more, I _would_ use it for everything. – solublefish Jul 19 '12 at 10:48
  • 4
    `You authenticate over HTTPS and get cookies that prove your identity, so you don't need HTTPS to read news stories.` That's not the proper way to handle session auth. Cookies should be set with the SECURE flag. But disregarding that horrible security advice for a second... Your mail analogy isn't really accurate for a few reasons. One being that you can't usually inject exploits into return mail, or impersonate someone to someone else with impunity, or pop a "Your Session Expired" message into return mail so they re-enter the credentials they use for both Yahoo! and their bank. – Parthian Shot Jan 29 '16 at 20:09
  • Password reuse and session fixation, among other things, aren't problems in snail mail. – Parthian Shot Jan 29 '16 at 20:10
  • 1
    Those are good points, but you're applying 2016 analysis to a discussion in 2010. – David M Jun 17 '16 at 23:59
12

The biggest reason, beyond system load, is that it breaks name-based virtual hosting. With SSL, it's one site - one IP address. This is pretty expensive, as well as harder to administer.

Michael Currie
  • 13,721
  • 9
  • 42
  • 58
Adam Wright
  • 48,938
  • 12
  • 131
  • 152
5

For high latency links the initial TLS handshake requires additional round trips to validate the certificate chain (including sending any intermediate certificates), agree on cipher suites and establish a session. Once a session is established subsequent requests may utilize session caching to reduce the number of round trips but even in this best case there is still more round trips than a normal HTTP connection requires. Even if encryption operations were free round trips are not and can be quite noticable over slower network links especially if the site does not leverage http pipelining. For broadband users within a well connected segment of the network this is not an issue. If you do business internationally requring https can easily cause noticable delays.

There are additional considerations such as server maintenance of session state requiring potentially significantly more memory and of course data encryption operations. Any small sites practically need not worry about either given server capability vs cost of todays hardware. Any large site would easily be able to afford CPU /w AES offload or add-on cards to provide similar functionality.

All of these issues are becoming more and more of a non-issue as time marches on and the capabilities of hardware and the network improve. In most cases I doubt there is any tangable difference today.

There may be operational considerations such as administrative restrictions on https traffic (think intermediate content filters..et al) possibly some corporate or governmental regulations. Some corporate environment require data decryption at the perimeter to prevent information leakage ... interference with hotspot and similiar web based access systems not capable of injecting messages in https transactions. At the end of the day in my view reasons for not going https by default are likely to be quite small.

Einstein
  • 4,450
  • 1
  • 23
  • 20
4

https is more resource-hungry than the normal http.

It demands more from both the servers and the clients.

Michael Petrotta
  • 59,888
  • 27
  • 145
  • 179
Johan
  • 20,067
  • 28
  • 92
  • 110
3

You should use HTTPS everywhere, but you will lose the following:

  1. You should definitely not use SSL Compression or HTTP Compression over SSL, due to BREACH and CRIME attacks. So no compression if your response contains session or csrf identifiers. You can mitigate this by putting your static resources (images, js, css) on a cookie-less domain, and use compression there. You can also use HTML minification.

  2. One SSL cert, one IP address, unless using SNI, which doesn't work on all browsers (old android, blackberry 6, etc).

  3. You shouldn't host any external content on your pages that don't come over SSL.

  4. You lose the outbound HTTP Referer header when browser goes to an HTTP page, which may or may not be a problem for you.

Neil McGuigan
  • 46,580
  • 12
  • 123
  • 152
3

If whole session is encrypted then you won't be able to use caching for static resources like images and js on proxy level eg ISP.

Alexei Tenitski
  • 9,030
  • 6
  • 41
  • 50
0

windows Server 2012 with IIS 8.0 now offers SNI which is Server Name Indication which allows multiple SSL Web Applications in IIS to be hosted on one IP Address.

Webmaister
  • 9
0

In addition to WhirlWind's response, you should consider the cost and applicability of SSL certificates, access issues (it's possible, though unlikely, that a client may not be able to communicate via the SSL port), etc.

Using SSL isn't a guaranteed blanket of security. This type of protection needs to be built into the architecture of the application, rather than trying to rely on some magic bullet.

Michael Petrotta
  • 59,888
  • 27
  • 145
  • 179
3Dave
  • 28,657
  • 18
  • 88
  • 151
  • 3
    Since the user's already protecting part of the site, the cost of the cert is more or less moot. – futureelite7 Apr 30 '10 at 16:30
  • 2
    @futureelite7 good point, but probably relevant to others that may be researching this topic in the future. – 3Dave Apr 30 '10 at 16:32
  • Featurism is the enemy of security. The majority of the weaknesses in my own stuff, have roots in some ill-advised feature that myself or a predecessor accepted into the product plan. I find that getting a feature kicked off because it causes a security vulnerability doesn't make you any more popular than declining it in the first place. Popularity SHOULDN'T matter, but sadly it can and does. In your shoes, I would ask myself how much I really want to deal with unsecured users, or whether the app is even suitable for users who can't use encryption (think: banking, politics, activism). – Jason Apr 30 '10 at 19:58
0

Well, the obvious reason is performance: all of the data will have to be encrypted by the server before transmission and then decrypted by the client upon receipt, which is a waste of time if there's no sensitive data. It may also affect how much of your site is cached.

It's also potentially confusing for end users if all the addresses use https:// rather than the familiar http://. Also, see this answer:

Why not always use https when including a js file?

Community
  • 1
  • 1
Will Vousden
  • 32,488
  • 9
  • 84
  • 95
0

https requires the server to encrypt and decrypt client requests and responses. The performance impact will add up if the server is serving lots of clients. That's why most current implementations of https is limited to password authentication only. But with increasing computing power this may change, after all Gmail is using SSL for the entire site.

futureelite7
  • 11,462
  • 10
  • 53
  • 87
0

I was told that on one project at our company, they found that the bandwidth taken up by SSL messages was significantly more than for plain messages. I believe someone told me it was an astounding 12 times as much data. I have not verified this myself and it sounds very high, but if there is some sort of header added to each page and most pages have a small amount of content, that may not be so far out.

That said, the hassle of going back and forth between http and https and keeping track of which pages are which seems like too much effort to me. I only once tried to build a site that mixed them and we ended up abandoning the plan when we got tripped up by complex things like pop-up windows created by Javascript getting the wrong protocol attached to them and that sort of thing. We ended up just making the whole site https as less trouble. I guess in simple cases where you just have a login screen and a payment screen that need to be protected and they're simple pages, it wouldn't be a big deal to mix-and-match.

I wouldn't worry much about the burden on the client to decrypt. Normally the client is going to be spending a lot more time waiting for data to come over the wire than it takes to process it. Until users routinely have gigabit/sec internet connections, client processing power is probably pretty irrelevant. The CPU power requried by the server to encrypt pages is a different issue. There might well be issues of it not being able to keep up with hundreds or thousands of users.

Jay
  • 26,876
  • 10
  • 61
  • 112
0

One other small point (maybe someone can verify), If a user types data into a form item such as a text box and then for some reason refreshes the page or the server crashes out for a second, the data the user entered is lost using HTTPS but is preserved using HTTP.

Note: I'm not sure if this is browser specific but it certainly happens with my Firefox browser.

toc777
  • 2,607
  • 2
  • 26
  • 37