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

Question

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:
   • Perfect Forward Secrecy
   • Hardened Cipher List
   • Don't use obsolete and insecure protocols like SSLv2 and SSLv3 (if possible; not using SSLv3 means that IE 6 can't access your site).

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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"

Answer 5

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.

Answer 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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.