62

While writing an answer to this question on Server Fault, a thought that has been bouncing around my head for quite some time resurfaced again as a question:

Is there ever a good reason to not use TLS/SSL?

To further elucidate the question, I'm asking about the specific case in which things have been configured properly:

  1. Performance:
    • Time to First Byte has been optimized.
    • The cipher list is small enough to avoid multiple roundtrips from server to client.
    • For mobile web applications, 2048 bit RSA server keys have been used as opposed to 4096 bit keys to lessen the computational load on clients.
    • SSL sessions have a reasonable lifetime to avoid regeneration of session keys.
  2. Security:

If done properly, is there ever a good reason to not use TLS/SSL for TCP communications?

Naftuli Kay
  • 6,715
  • 9
  • 47
  • 75
  • 1
    We have some related questions you might want to review for interesting tidbits: [Why do websites use HTTPS when they don't need to?](http://security.stackexchange.com/questions/52856/why-do-websites-use-https-when-they-dont-need-to) and [Should a site have SSL if it doesn't have a login form?](http://security.stackexchange.com/questions/38832/should-a-site-have-ssl-if-it-doesnt-have-a-login-form) – Xander Aug 07 '14 at 14:05
  • 1
    It also makes your business look professional with the green lock (at least to me it does). – Anonymous Penguin Aug 07 '14 at 15:04
  • 1
    Example: [Why aren't application downloads routinely done over HTTPS?](https://security.stackexchange.com/questions/18853/why-arent-application-downloads-routinely-done-over-https) – Gilles 'SO- stop being evil' Aug 08 '14 at 07:59
  • Added complexity? (For many sites, authenticity might be so unimportant that its benefits are far outweighed small chance of a Heartbleed-like bug). Consider icanhazcheezburger.com as an example of something where HTTPS is barely useful (except when logged in). – user253751 Aug 08 '14 at 09:59
  • 2
    Also, no matter how good the performance of TLS gets, it can only asymptotically approach the performance of non-TLS. – user253751 Aug 08 '14 at 10:01

12 Answers12

74

The main issue with HTTPS everywhere is that it basically makes caching web proxies useless (unless you have trust the proxy and have it impersonate sites for you, but that doesn't work with certificate stapling and is possibly illegal in some jurisdiction). For some use cases, like for example the distribution of signed software update, HTTP makes perfect sense. If you have e.g. a hundred workstations behind a corporate proxy, them downloading update with HTTP will mean for all but one it will be delivered off the proxy cache. That will be a lot more efficient that each of them doing it over HTTPS...

In short, HTTP makes sense as a transport layer if another mechanic is there to verify the authenticity and integrity of the content, and if confidentiality is of little importance...

For web browsing by actual human beings, I find it very hard to justify not using HTTPS in this day and age.

Bruno Rohée
  • 5,221
  • 28
  • 39
  • 5
    This actually makes a lot of sense. I hadn't considered the problems with caching that HTTPS would cause. While I agree that signed software packages over HTTP works and makes sense, privacy-conscious users still might want HTTPS for anonymity: "I don't want (third-party) seeing that I've changed from Chrome to Firefox." An adversary can see that you're downloading packages, but not necessarily what they are. (Unless the correlate the exact package size...) – Naftuli Kay Aug 07 '14 at 17:33
  • Does SSL/TLS not have something like SSH's MSG_IGNORE message type to help with traffic analysis? – RoraΖ Aug 07 '14 at 18:52
  • 3
    So TL;DR "Use TLS on every web site." – Naftuli Kay Aug 07 '14 at 21:12
  • @raz TLS officially allows 0-length data records (which after possible pad, HMAC and possible IV are larger) but when OpenSSL tried to use this years ago to defend against the then-theoretical Vaudenay attack it didn't interop well. When Rizzo&Duong matured the attack into BEAST, the consensus solution for < TLSv1.1 was splitting 1/n-1; now that's available you might get away with variants like 1/1/1/n-3. Also for CBC modes (not RC4 and not GCM and CCM) the spec allows "extra" padding up to 256 not just cipher blocksize, but I don't know if any implementation does so. ... – dave_thompson_085 Aug 10 '14 at 12:39
  • @raz ... *HTTPS* however allows arbitrary "x-ignoreme:" headers to be added or not, and 1.1 allows chunked coding to be inserted more often, less or not at all, with variable ignoreable extensions and trailers. Also, it can use or not use compression, and the compression algorithm could take or skip various opportunities; but all implementations I've seen are controlled only crudely by history limit, they take all opportunities within that limit. Plus many folks disabled compression due to BREACH. – dave_thompson_085 Aug 10 '14 at 12:51
  • Interestingly, Debian choice of HTTP transport for package retrieval in place of HTTPS just exposed them to a MitM attack escalating to RCE as root. Another case where using HTTPS even where there wasn't an obvious confidentiality need would have saved the day. See https://justi.cz/security/2019/01/22/apt-rce.html for more info. – Bruno Rohée Jan 22 '19 at 18:52
16

I don't agree with the response of @valentinas. There is a performance loss with TLS. If it is relevant for you depends on your site:

  • To establish the connection you first have the TCP handshake between client and server for both HTTP and HTTPS, which needs one full round trip between client and server.
  • For HTTPS you additionally have the TLS handshake which needs two round trips on the initial session establishment (only one if TLS false start is supported) and one round trip if you can resume a session.
  • While the symmetric cryptography used inside the TLS session is cheap, the initial key exchange is not. If you do it right you want to use forward secrecy, which means either DHE or ECDHE. Simple DHE is very expensive to set up, ECDHE is much cheaper but not all clients support it. See http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html for benchmarks.

These things combined make TLS connections more expensive to set up and thus introduces a noticeable performance hit with short connections. More hardware will not help much, because the major problem are the additional exchanges between the peers, where they have to wait for each other to continue.

With long connections this overhead does not matter that much anymore, so if you use keep-alive (most clients and server do) and have only few connections you probably will be fine. But, few connections means that you should not include any ad-networks, because they often redirect between multiple hosts until they reach the one which finally serves the advertisement. Sites which heavily depend on advertisements are already slowed down by this (initial round trip for TCP) but they will be more slow if they switch to HTTPS, because of two more round trips needed to establish the TLS session to each of the servers in the advertisement chain.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • A TLS handshake can be good for more than a single connection. – Paul Draper Aug 10 '14 at 01:30
  • 1
    I don't know what you mean with "connection", but a SSL handshake is required for each TCP connection, although you can do a shortened handshake if client and server can resume an established SSL session. Each TCP connection itself can contain multiple HTTP requests (keep-alive), but only to the same server. So if you have multiple server (e.g. ad-networks) you will need multiple connections and you also need to setup multiple SSL sessions. – Steffen Ullrich Aug 10 '14 at 07:33
  • 4
    I don't see penalizing ad-networks as a disadvantage really :) – Hagen von Eitzen Aug 10 '14 at 10:38
  • 1
    About your third point, I think DHE can be used as a DOS measure but I don't think CPU performance is really important on desktop and mobile devices although I'm assuming we can afford the cost on server. About using TLS for internal communication of services... I think people will start using ACL and VPNs as soon as they see TLS impact so there is no reason to worry about it as long as we can configure system to disable TLS. – Pooyan Khosravi Aug 10 '14 at 19:39
11

A reason I haven't seen mentioned yet is that, as archaic as it may sound, some clients may not support TLS/SSL. This is a specialized case, for sure, and usually involves either embedded or legacy systems, but unfortunately some still do exist.

The first example that springs to mind is a custom microcontroller we were using, where we'd underestimated the amount of space we'd need, and weren't going to be able to include the size of an SSL library. We ended up needing to cut it out and communicate over standard HTTP instead, and were quite thankful that the server this had to pull data from offered both methods.

Also ran into a legacy system a few years back that prevented the use of TLS/SSL. A project a friend of mine was hired for involved setting up a remote web server and a automated client at a university. The client script was running in an antiquated and heavily sandboxed environment at the university - every part of compilation was handled by an automated system, and the set of libraries that could be accessed was a hardcoded list.

Are these common enough to warrant avoiding TLS/SSL in normal cases? I'd say no, but there are times when they can be important. If you're writing software primarily meant to communicate with embedded systems, I'd think twice before offering only TLS/SSL.

Mike Precup
  • 211
  • 2
  • 5
  • You can setup an ssl stripping proxy between the microcontroller and the embedded device. Although you should consider the security impact, as services that offers ssl only connection usually does so out of actual concerns that they have. If you want to offer a bit of protection still, then you can rewrap the connection between the device and your proxy server with custom encryption scheme that has smaller overhead. – Lie Ryan Aug 07 '14 at 23:59
  • @LieRyan microcontroller = embedded device, so an ssl stripping proxy between the device and itself? – user253751 Aug 08 '14 at 10:00
  • I meant between the embedded device and the server – Lie Ryan Aug 08 '14 at 10:14
  • @LieRyan: "...usually does so out of actual concerns that they have" and the modern mentality of "TLS/SSL everywhere" kinda clash. Either there *are* actual/specific concerns (which means *not* doing it is justifiable in other cases), or using TLS/SSL is just "what you should do" these days (and actual concerns easily get drowned out by all the chanting about best practices). – cHao Aug 08 '14 at 16:01
9

One other note on this, as I do not see it specified in your question, is that everyone appears to have made the jump to suggest that when you asked about TLS/SSL you were meaning just HTTPS. Since you mention TCP communications you may also be considering the use of TLS/SSL for other applications that run over it besides HTTPS.

What comes to mind is TLS/SSL as used by SMTP. When it comes to using TLS/SSL for SMTP communications I personally would not ever rely on it as a maintainable method for security (note, I do mean SMTP communications, not the use of TLS/SSL to provide security between a mail client and mail server). The reason I say this is the inherent nature of TLS/SSL. You are looking at a point to point secure socket connection being adapted for a multiple hop communication mechanism.

So even if you force the use of TLS/SSL for your SMTP connections, you can only verify the connection was secure one hop out from your server. As most mail streams have multiple hops such as this:

mail server -> AV solution -> Internet -> AV Solution -> Mail Server

And the use of 3rd party AV solutions in the cloud are becoming more prominent, it is difficult to ensure TLS is used for every hop between two organizations.

For the sake of argument (as I have done this) let's say you take the time to secure that SMTP traffic between two sites by verifying each and every hop between the sites forces TLS. That is all well and good for today, but what happens when infrastructure changes 5 years from now? If not careful for example, when the AV solution is changed/replaced, you could easily leave one hop not forcing TLS.

Just wanted to throw this out there as another TLS implementation for brainstorming (and BTW if requiring secure email, I would go the S/Mime route to actually encrypt the message on the sender side and decrypt on the recipient side). As with any tool, you have to use the right tool for the right job

"If the only tool you have is a hammer, every problem becomes a nail"

Insecure
  • 289
  • 1
  • 2
  • 4
7

No.

The usual excuses are performance and price, but both are bad reasons. The performance hit is minimal (I stand corrected. Other posters here point out some interesting metrics. I still think that "TLS is a must" is a good general guideline) and the price is low too - most people will spend orders of magnitude more than that on coffee).

Thinking in retrospect it should have been built in to HTTP protocol, but back in the day no one thought that HTTP will evolve to be something it is today. Back in the day it was used to transferred hypertext documents with no guarantee for integrity, security or anything else.

valentinas
  • 1,038
  • 8
  • 10
  • 2
    [When the number one suggested solution to a problem is "hardware acceleration", it is not minimal](http://www.cs.rice.edu/~dwallach/pub/tls-tocs.pdf) – Alice Aug 10 '14 at 12:13
6

During development, SSL makes it so much harder to debug HTTP connections. Surely you can register the server certificates in Wireshark, but that's much hassle.

So for development I nearly always have it turned off.

cweiske
  • 191
  • 1
  • 8
  • *Surely you can register the server certificates in Wireshark* If you're using protocols other than HTTP, then Wireshark is probably a good tool for that job. But specialised tools like Fiddler [can automatically MITM your HTTPS connections for you](http://docs.telerik.com/fiddler/configure-fiddler/tasks/decrypthttps). – ta.speot.is Aug 10 '14 at 02:27
  • I prefer mitmproxy, since Fiddler only works on windows. But it is still harder to setup the proxy in your application than simply start wireshark and peek at the packages. – cweiske Aug 10 '14 at 06:19
  • Burp proxy also has no problems intercepting SSL. – valentinas Aug 10 '14 at 22:23
3

I wrote a response to this on Quora already:

https://www.quora.com/If-HTTPS-is-more-secure-than-HTTP-why-dont-all-websites-use-HTTPS?s=1

10 years ago I would have agreed with the other answers that HTTPS is unnecessary for most web sites. Today, I'm no longer convinced it's optional.

  • Encrypted connections reduce the opportunity for ISP and government tracking, both a problem in most countries, including the US.
  • Encrypted connections reduce the opportunity for on-the-wire malware and spoofing.
  • Encrypted connections make up for the inadequacy of the insecure DNS infrastructure to some extent.
  • The browser enforces a slightly higher security policy for HTTPS connections, reducing hack opportunities on the client regardless of the communication channel.
  • If HTTPS is not present, even once, for one web site, a user is vulnerable to all of the above attacks or tracking.
  • A computer which is hacked even once is owned by the hacker, forever or until it's reformatted and restored to a safe state.

The cost of HTTPS are also minimal for each web connection.

  • The CPU cost of 256-bit encryption is very low, comparable or lower than compression algorithms.
  • The extra ~500ms latency of the 7-way SSL handshake only occurs once per web connection.

The benefits far outweigh the costs in the modern computing environment on the Internet. Written 3 Jul.

2

One reason that springs to mind is IPsec.

These days, encryption on internal networks is recognised as a high-security practice. Probably not standard practice just now, but going that way.

IPsec has some advantages over TLS for internal network encryption. Primarily because if you're going to encrypt everything, then it's a protocol that is designed to encrypt everything, which TLS is not.

There is normally no point is doing double encryption, so if you're using IPsec internally, it is generally a bad idea to use TLS as well.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • That's only possibly true if you use IPsec everywhere and DNSSEC for everything, making sure every name resolver actually checks DNS response correctly. I never saw that. In practice, TLS over IPsec is a good idea. – Bruno Rohée Aug 07 '14 at 13:05
  • @BrunoRohée - question was "is there **ever** a good reason..." – paj28 Aug 07 '14 at 13:14
2

Encryption blinds network monitoring devices (IDS/IPS/etc). Depending on the network one may elect not to encrypt traffic. Instead leverage IPsec to ensure the integrity of the traffic is maintained while allowing it to pass in the clear. Thus providing network monitoring devices full access without the overhead of encryption.

anon
  • 21
  • 1
1

Plain and simple: when security is not required. In other words, when an anonymous visitor is browsing your public web site, HTTP is sufficient, and adding security protocols is unnecessary and wasteful. (As others have noted, it's also wasteful of other people's resources as it interferes with caching.)

Most web sites serve general purpose information without special security requirements. Obviously, if your site has information that people may use in some context where the reliability of the content is essential, then of course, you don't fall into this category, and you should consider measures such as an HTTPS-only site.

  • 2
    You never know beforehand what kind of information might be critical. – Christian Aug 09 '14 at 18:39
  • 1
    Christian - I don't know in what sense you are using "you never know". Are you saying that more security is always better? The essence of this question is about whether https is always better. I'm saying that a web site owner /can/ assess their security needs, and that for many/most web sites it doesn't help. My house has a lock on the front door, but not on the garden gate. – Dominic Cronin Aug 09 '14 at 19:52
  • The can assess their security needs, but not the needs of the visitors especially if the owner of the website doesn't have much information about the visitors. – Christian Aug 09 '14 at 20:14
  • Most websites know exactly what their target audience is. – Dominic Cronin Aug 09 '14 at 22:02
  • Not everyone who uses the website is a member of the target audience. It's also not trivial to understand what someone can do with knowledge of browsing habits.An attacker can build personality profiles through complex correlations that you simply don't see when you think about your website. – Christian Aug 09 '14 at 23:48
  • 1
    Christian - that's like saying I should put a lock on my garden gate because someone might follow the postman and decide to mug him because he visited on a Tuesday. There are more appropriate defences than blanket transport security. A certain amount of paranoia is justified, but there really are plenty of situations where plain-old http (or whatever other protocol) is fine. Even with TLS/ssl, your browsing patterns are still visible, unless you are using something like tor, in which case, you've only moved the problem. – Dominic Cronin Aug 10 '14 at 01:19
  • You have overlooked something critical which TLS provides to clients: privacy. An adversary can see that you've accessed a certain IP, but cannot see the contents or modify them. As a user, I want this for EVERY site I visit. It's terribly simple to run a MITM and rewrite web pages as you see fit. TLS protects users from wire-tapping and tampering. – Naftuli Kay Aug 10 '14 at 04:22
  • 1
    Naftuli - I haven't overlooked it. I just don't place as high a value on it as you. Most sites offer content which is not critical. If I turn up half an hour late to the village cricket match because some prankster has interfered with my connection to the cricket club's site, the world won't come to an end. Your question was whether there's ever a good reason not to secure the traffic. My answer is: yes, sometimes the benefits are less than the costs. – Dominic Cronin Aug 10 '14 at 05:30
  • 1
    It's a reasonable answer to the question you asked, especially considering your stipulation of "doing it right". Perhaps your question should reflect your view that everything should be secured. – Dominic Cronin Aug 10 '14 at 05:40
  • 1
    The fact that you don't value your privacy doesn't mean that you can be confident that you don't have users who value their privacy. – Christian Aug 10 '14 at 09:56
  • 1
    Christian - if you have to justify the budget, you will make these judgments. For a normal website, your visitor's desire for privacy is their own concern. You may care enough about how they perceive you to invest in extra security, or you may not. – Dominic Cronin Aug 10 '14 at 10:28
  • 1
    @Christian Just because users value their privacy doesn't mean it matters. – Alice Aug 10 '14 at 12:16
  • I agree it can be a burden when you get a certificate warning for a site you wouldn't trust too much and it's only used as opportunistic encryption. However, that's a client-side problem. I find a bigger issue when you **do** want a secure layer and the site doesn't provide it, not even by manually changing the protocol to _https_ (and sometimes it is configured, just not enabled for the page/subdomain). Even if you don't think many people will need TLS for your service/web page, you should provide https as optional if that isn't a big problem for you. – Ángel Sep 13 '14 at 22:43
1

Probably the biggest excuse people give for not using TLS involves entry-level web hosting in the era of IPv4 address exhaustion. Cheap web hosts use name-based virtual hosting to pack web sites of dozens of subscribers onto one machine behind one IP address. When I used to host my personal site on Go Daddy, I found that my domain was one of over a thousand on a single IP. Using HTTPS with name-based virtual hosting requires a relatively recent addition to TLS called Server Name Indication (SNI). Pretty much every major web browser still in use, except for Android Browser on Android 2.x and Internet Explorer on Windows XP, supports SNI. A few low-end hosting providers offer SNI service, but not many do because of the support issues that IE/XP and Android 2 would cause. You may have to pay more to upgrade to a VPS.

A second is the recurring cost of a certificate from a well-known commercial certificate authority. Even if you use a CA that offers a service tier without charge, such as StartSSL, it's still manual work every 12 months to reissue and reinstall the certificate.

Finally, a lot of advertising networks don't work in HTTPS pages because of web browsers' mixed content blocking. AdSense is the only one I can think of that does, and it didn't offer HTTPS until September 2013.

Damian Yerrick
  • 540
  • 3
  • 15
0

I cannot answer your question as for the security of commmunications and performance, but I see one good reason why an HTTPS-only world wide web could be dangerous.

When the time of a client machine is not correctly set, this causes certificate issues for browsing the web. One can observe this when the CMOS battery no longer holds the charge. Of course, in such case one can set the correct time again in the operating system.

However, if a virus was capable to make permanent changes to the operating system time on a large number of computers, it would cause an Internet blackout for https:// sites.

OuzoPower
  • 149
  • 2
  • 1
    A brief note about _how_ an incorrect system clock on the client could lead to certificate issues would be helpful. – Philip Rowlands Jul 27 '18 at 07:44
  • 1
    @PhilipRowlands Some of it is [discussed here](https://security.stackexchange.com/q/71364/5405), but there it is also observed that TLS does not rely on it. – S.L. Barth Jul 27 '18 at 07:51
  • 1
    Making a bunch of websites inaccessible is better than the alternative of setting the clock back so they can MitM with weak or exposed certificates. – AndrolGenhald Jul 27 '18 at 13:04