Why isn't all Internet traffic encrypted? [closed]

Question

Would there be a problem if all Internet traffic was encrypted with HTTPS or some other protocol?

What are the tradeoffs for using encryption all the time? Is the speed of the connection reduced or are there other complications?

Answer 1

The biggest problem is that you must be able to verify that you're encrypting to the correct key. Without it, encryption would be practically useless, as anyone could perform a man-in-the-middle attack on the connection and remain undetected.

In typical SSL/TLS, as well as other protocols using X.509, this verification is performed by "certification authorities", which are explicitly marked as "trusted" by web browsers and operating systems. Unfortunately, these CAs usually charge a decent amount of money even for the simplest, automated checks. They also get hacked often (see also: DigiNotar, Comodo). You can make a self-signed certificate, of course, but then others cannot verify it against any trust anchor.

Some browsers already support verifying self-signed certificates against information published in DNSSEC, but in some ways it is even worse than the current PKI – would you rather trust VeriSign or... GoDaddy?

The "Web-of-trust" model of PGP and TLS-PGP has other problems: getting one's key¹ signed by enough people is often tricky, [especially for those living in a small town in Europe...] Without those signatures, again, it's relatively easy for an attacker to substitute his own keys.

Another problem is that not all programs and protocols were designed with encryption in mind. While many of them have had TLS retrofitted (HTTP, SMTP, IMAP, ...), it's not always possible to update the programs themselves. Even though SMTP can enable encryption for server-server links, very few servers advertise or request it. (Out of the major email providers, Gmail is probably the only one which supports this.)

This issue can be solved somewhat by using encryption on lower layers, using protocols such as IPsec, but then you hit the verification issue again. For example, IPsec can use pre-shared keys (obviously infeasible for any larger network), Kerberos (better, but still doesn't scale to a global Internet), and X.509 certificates (which were already discussed). Hence, even if IPsec weren't so tricky to configure and use, it wouldn't work well for securing "all internet traffic".

Finally, we have political issues. Some companies insist on logging all traffic generated by employees (or at least all websites browsed), and potentially blocking "bad" websites. Since they can't see through HTTPS, often they break HTTPS. There already are commercial devices which act as filtering proxy servers for HTTPS, performing an officially-sanctioned MITM attack. (You don't even notice it, since the device issues certificates using a locally managed CA, which is pre-installed on all company's computers.)

Governments are not much different: there have been many attempts to regulate secure crypto (especially the USA export regulations), to introduce crypto algorithms or devices which the gov't could bypass (the most widely known is probably the Clipper chip), to block encrypted data (Iran), or, even, to outlaw it partially (Russia) or entirely.

---

¹ OpenPGP certificate, technically.

Answer 2

Chris's argument is not entirely true (but close). Since most "encryption methods" (technically block ciphers, etc.) are one-to-one functions, they do not need to add extra bits for every bit encrypted (and there's no need to do so by information theory). They just need to pad the original data to fill the block cipher's blocks. Normally the padding is very small (128 bits).

The real problem of encryption is performance penalty. I can think of at least three aspects:

1. The cost of negotiating the encrypted channel. Normally this involves raising a large number (thousands of bits long) to another large number (also thousands of bits long nowadays), which is a very computation-intensive operation. For a server, a considerable amount of CPU time can be consumed just to open encrypted channels.
2. Caching, which many web services rely on, will be less useful because the encryption key is different to to each transmission, so even static data has to be encrypted again and again.
3. To make things worse, the dominant CPU architectures are not designed to handle operations needed in modern cryptography and encryption libraries (OpenSSL, etc.) will sacrifice performance to prevent leaking of information.

Answer 3

To encrypt the internet traffic (using HTTPS), host providers use SSL certificates that are provided by third party authorities (such as VeriSign) and checked with these authorities. Getting one of these certificates costs money ("Authoritatively signed certificates may be free or cost between US$13 and $1,500 per year" --Wikipedia).

Another problem is that when using HTTPS is that the transmitted content must be encrypted (which is an additional load on the CPU)

Answer 4

All Internet traffic is not encrypted because:

• Computers that were the norm around the time many of these standards and technologies came to be in the 1960s, 1970s, and 1980s did not have the performance level to handle compute-intensive encryption on top of retrieving, assembling, and transferring data. This can still be true for embedded systems such as older feature phones, modems, etc. Computers of that era were also generally operated by small, trusted groups.

• Since (good) encryption involves compute-intensive operations, it always incurs a performance penalty (or requires an investment in faster hardware) as @billc.cn mentions. If the information does not need to be encrypted (for example, weather information), then it is cheaper to deliver the information unencrypted.

• In some countries (including the U.S. in the early to mid 1990s) encryption presents an issue to law enforcement because it can potentially prevent lawful interception of communication.

• If encryption is being used to provide identity services, an infrastructure must exist. Traditionally this has been PKI type services using certificates, CA's, private keys, etc. Signing up with a CA and maintaining current SSL certificates costs money if you want to depend on recognized "root" CA's automatically installed in major browsers (necessary for "Aunt Ethel").

• Regarding PKI type services, someone, somewhere, using these systems must hold a top-level "root" key. To scale this to a global level, you must remember the organizations that "run" the Internet are international in scope (at least in theory) and a lot of politics comes into play at this level. For example, who should hold the key to the root DNS zone?

• While common sense would state that having your traffic open to interception is generally a bad thing privacywise, having your traffic "open" allows proxy servers and devices to optimize that traffic easier. However this is usually an issue with LAN/WAN technologies and not traffic going to/from the Internet.

Answer 5

Encrypting all Internet traffic is overkill.

Here are some of the reasons:

1. There are no secrets in some messages/content:

   • For example, a 600 MB Linux distribution that you download. Here all you need to ensure is that the content has not been modified (accidentally or deliberately). You do this by computing and verifying the sha1sum. And if you use encryption with a peer to peer model like a torrent, you need to negotiate symmetric session keys pair-wise with all the peers with whom you send and receive. In order to do key exchange/negotiation without being subject to man-in-the-middle attack, peers need to perform mutual authentication and this requires that all peers have certificates signed by a trusted certificate authority --- this costs money, not one time but annually. I read that the vast majority of traffic on the internet these days is torrent traffic.

   • public information, like Form 10-K reports of a company. There is no need to encrypt this message. The company just needs to digitally sign the document.

2. Encryption gets more complicated for multicast data.

Note: Effectively, the bandwidth required for encrypted data is greater, though encryption takes n bits and returns n bits. This is because encryption without integrity protection is virtually useless --- and integrity protection takes extra bytes. Without integrity protection an attacker can replace the data with some other bits and as decryption never 'fails' it will return a bunch of bits. Now if this is some text that a human is reading he/she can see that it is garbage and drop it. But if is streaming audio/video data consumed by a media player you will hear/see garbage.

Note: cryptography hardware is getting cheaper and processors are getting faster. You can even browse wirelessly using smartphones which are able to handle the encryption required by access points using WPA/PSK. This was not the case a few years ago. When WPA standard was introduced a while back, because the routers of the day couldn't handle AES encryption, a simpler scheme (to be used in the interim) called TKIP was introduced. Now all routers can handle AES. So handling the crypto load should not be a problem as long as hardware advances are able to keep up with increasing data rates.

Note: Eventually everyone (including every fridge and toaster) will have an IPv6 address. IPsec is mandatory in IPv6. So there may come a time when everyone is given an IPv6 address and certificate by the government just like the way passports are issued :-)

Answer 6

Tradition. If it were done over again from the start, most traffic (other than open web pages) would be encrypted. Definitely email would be.

Answer 7

One big reason is most ad networks (I'm looking at you, AdSense) don't serve encrypted ads... meaning that ad-supported sites can't use SSL.

https://www.google.com/adsense/support/bin/answer.py?hl=en&answer=10528

Answer 8

Encrypting all the internet traffic would require an enormous amount of processing power and therefore would cost a lot of money. Daniel Bernstein has done some research in this field, for example: "High-speed high-security cryptography: encrypting and authenticating the whole Internet."

EDIT: Found a video of Bernstein's lecture.

Answer 9

This is an opinion question, and perhaps doesn't belong on this site... .

Above answers saying SSL isn't all that secure fail to acknowledge that it's still better than HTTP.

Google did an analysis of where the remaining chokepoints are in internet traffic, and concluded that in fact all traffic should be encrypted: http://www.chromium.org/spdy/spdy-whitepaper

One benefit of encrypting everything is it eliminates modern browsers' problem where they cache identical files twice: Once for HTTP and once for HTTPS. Today this means you might cache all the scripts and CSS on a site on the homepage, click around, then visit the HTTPS login page and be forced to download all the same files all over again.

The reasons most traffic still isn't encrypted:

• It costs money (cost of an SSL certificate).
• A lot of content out there was created before SSL came about or became popular.
• A lot of content out there has no relevance to security; for example, a brochure-style site describing a company has no security concerns relating to SSL.
• HTTPS has performed poorly compared to HTTP for most of internet history (and to a small degree today), largely caused by bad design.
• Many smaller sites are on shared hosting, where installing multiple SSL certificates is difficult or impossible, depending on the host.

Digging deeper into the performance problems:

• Many ISPs and other intermediaries will cache pages that pass across them frequently over HTTP to reduce the overall latency and load on the internet and more specifically their network. HTTPS pages generally are not. Sites with the money to do it make this issue irrelevant by using a CDN.
• For a long time browsers wouldn't cache HTTPS resources, which has a major negative impact on second+ page performance. Many people still use older browsers today.
• There is a CPU hit for using HTTPS; as computers become faster this becomes increasingly irrelevant, but it contributes to older sites not using it, and compounds the budget problem for sites that can't afford the SSL cert.

Answer 10

Another factor is the bandwidth required for encrypted data is greater than for plain text (as grawity points out, it's mostly key exchanges) - and a lot of the time the data being sent isn't really important enough to be encrypted, for example cats doing crazy things on Youtube.

Answer 11

The traditional internet protocols place much emphasis on easy debugging (they're not easily debuggable just by chance, it was a goal). Encryption tends to get in the way of tcpdumping packets and figuring out what's wrong.

I venture to suggest that above all, encryption didn't get done in e.g. RFC 791 because it was a difficult task, could be deferred until after stuff worked, and was in conflict with debuggability.

Answer 12

Several reasons which you may summarise in: money, technical limitations, standards, human limitations.

Let me try to explain in layman terms.

1. As noted by @grawity, once the message is encrypted, the receiver needs to decrypt it and for that needs a key. Getting the key can be done from a trusted third party (trusted by both sides), so this becomes a service and someone needs to pay. Certification Authorities (CA) as businesses are born (you can also get the key by other means, but those don't scale well in the Internet.)

2. Encryption and decryption require more CPU and time to process, which can be a limitation. Although SSL, for example, uses strong encryption techniques to exchange a new random key used in a simpler algorithm which runs faster. But this requires a handshaking step...

3. Modern encryption requires connection handshaking (see 2 above), therefore cannot be applied to a connection-less message transport, i.e. UDP. UDP is actually used in several Internet services, audio/video streaming being a notable example.

4. You mentioned HTTPS. This is HTTP over SSL, which means HTTP, the connection-oriented protocol for web pages, over SSL, the handshaking security part. The Internet traffic, as a whole, is made of zillions messages belonging to thousands of protocols. Web (HTTP) being the most of it, but there are others. You cannot simply map or tunnel every protocol to the HTTP. One reason for this, as said in (3), is that some protocols are not connection oriented and HTTP is. Other issues: FTP is connection oriented but it uses two connections. SMTP (email) is connection oriented and uses one connection, but it is state-full, not state-less as HTTP... and the list of technical hurdles goes on.

5. Sometimes it is possible to tunnel a protocol through HTTP. But you have to rewrite servers and clients to take advantage of this. Say you do this for SMTP, the protocol that allows email to travel. Then you have to rewrite a server that

   • still supports the traditional SMTP, and
   • knows how to map SMTP through HTTP.
     First option is fully controlled by a standard, no risks here. Second option will be, at least initially, ad-hoc and will only work if your new implementation becomes a standard or a de-facto standard, i.e. widely used. But "why bother?" most system administrators would say, if you already have option (a). And option (b) will be a standard only if it solves a big problem. Well, this is usually not the case.

6. Less problematic is to use SSL for an existing protocol (if connection oriented). In fact, it has been done already for many protocols, including HTTP, and it works quite well. Note that this is not 'tunnelling' and does not require changing a standard, therefore changes to existing systems are usually easy: I bet you can put most connection oriented Internet protocols followed by SSL in google and get something! Still SSL cost money, but for people concerned by security, using SSL for a connection-oriented protocol is fairly viable and actually cheap (Google gives you POP3 over SSL for example!)

7. Even in the context of HTTPS, managing SSL in corporate networks poses some other problems. Say you want to do load balancing, fail recovery or content filtering. If the handshaking links a client to an specific server, in the event of server failure it becomes harder to make the recovery transparent for the user. Also, if you want to redirect or allocate servers based on content (for example, by some HTTP headers) then the router operating as gate needs to be able to open the message and decrypt it. By construction this is not possible unless the gate deals with the SSL handshake directly. Doable, but again, those smarter routers cost more than few bucks and you need specially trained people to manage them!

And the list may get longer, so why do you need to encrypt that email from your Aunt inviting you for dinner?