Will it ever be possible to run all web traffic via HTTPS?

Question

I was considering what would it take (technologically) to move all the web traffic to HTTPS. I thought that computers are getting faster, and faster, so some time from now it will be possible to run all traffic via HTTPS without any noticeable cost.

But then again, I thought, encryption strength will have to evolve to counter the loss of security. If computers get 10x faster, encryption will have to be 10x stronger, or it will be 10x easier to break.

So, will we ever be able to encrypt all web traffic "for free"?

Edit: I'm asking only about the logic of performance increases in computing vs encryption. If we can use the same crypto algorhytms and keys in 20 years, they will consume a far lower percentage of the overall computing capacity of a server (or client), and in effect, that will make it "free" to encrypt and sign everything that we transmit over networks.

Answer 1

1. Encryption would not have to get 10x stronger in the sense that you would not need to use 10x more bits. The difficulty of brute force cracking increases exponentially with an increasing key length. At most key lengths would have to get slightly longer.
2. What would be the point of running all traffic through SSL, even stuff where there is obviously no advantage? This seems incredibly wasteful. For example, it seems ridiculous to download a Linux distro through SSL.

Answer 2

One of the big issues with using HTTPS is that its considered secure and so most web browsers don't do any caching, or at least do very limited caching.

Without the cache, you'll notice that HTTPS pages load significantly slower and a non-encrypted page would.

HTTPS should be used to protect sensitive information.

I have no idea about the CPU impact of running everything through SSL. I would say that on the client side, the CPU isn't an issue since most workstations are running idle most of the time anyway. The big program would be on the web server side due to the sheer number of concurrent requests that are being handled.

In order to get to the point that SSL is basically 'free', you'd have to have dedicated hardware for encryption (which already exists today).

EDIT: Based on the comments, the question's author suggests this is the answer he was looking for :

Using crypto is already pretty fast, particularly considering that we're using CPU cycles vs. data transmission. Crypto keys do not need to get longer. I don't think there's any technical reason why this is impractical. -David Thornley

UPDATE: I just read that Google's SPDY protocol (designed to replace HTTP) looks like it will use SSL on every connection. So, it looks like Google thinks that it's possible!

To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.

Answer 3

The cost isn't that great nowadays.

Also...having a computer that is 10x faster will in no way make it necessary to change encryption. AES (a common encryption for SSL) is strong enough that it would take a very very long time to break.

Answer 4

Will it be possible? YES Will it be advisable? NO

For a few reasons.

• extra cpu cycles on server and client would use more power which incurs cost and emissions
• ssl certs would be required for every server
• it's useless to encrypt data that doesn't need to be hidden

Answer 5

IMO, the answer is no. The main reason for this is that if you consider how many pages have items from multiple sources that would each have to use https and have a valid certificate that I don't think would work for some of the big companies that would have to change all their links.

It isn't a bad idea and maybe some Web x.0 would have more secure communications by default, but I don't think http will be that protocol.

Just to give a couple of examples, though I am from Canada which may affect how these sites render:

www.msn.com :

• atdmt.com
• s-msn.com
• live.com

www.cnn.com :

• revsci.net
• cnn.net
• turner.com
• dl-rms.com

Those were listed through "NoScript" which notes this page has code from "google-analytics.com" and "quantserve.com" besides the stackoverflow.com for a third example of this.

Answer 6

State department wouldn't like that idea

Answer 7

A major difference with https is that a session is kept open until you close it. Saves a lot of hassle with session cookies but puts a load on the server.

How long should google keep the https session with you alive after you send a query?

Do you want a persistent connection to every popup ad?

Answer 8

You don't need HTTPS/SSL for all client-server communication. As others here have stated, it would be a hog of resources and overkill for applications that do not need security.

Answer 9

Chris Thompson mentions browser caching, but that's easily fixable in the browser. What isn't fixable on switching everything to HTTPS is proxy caching. Because HTTPS is encrypted end-to-end, transparent HTTP proxies don't work. There are a lot of places where transparent proxying can speed things up (for instance at NAT boundaries).

Dealing with the additional bandwidth from losing transparent proxying is probably doable - allegedly HTTP traffic is trivial compared with p2p anyway, so it's not as if transparent proxies are the only thing keeping the internet online. It will hit latency irrevocably, and make a slashdotting even worse than it is currently. But then with cloud hosting, both those might be dealt with by tech. Of course "secure server" takes on a different meaning with cloud hosting, or even with other forms of de-centralisation of content across the network like akamai.

I don't think the CPU overhead is that significant. Sure, if your server is currently CPU bound at least some of the time, then switching all traffic from HTTP to HTTPS will kill it stone dead. Some servers may decide that HTTPS is not worth the monetary cost of a CPU that can handle the load, and they will prevent literally everyone adopting it. But I doubt it will be a major barrier for long. For instance, Google has crossed it already and happily serves apps (although not searches) as https without fuss. And the more work servers are doing per connection, the less proportional extra work is required to SSL-secure that connection. SSL can be and is hardware accelerated where necessary.

There's also the management/economic problem that HTTPS relies on trusted CAs, and trusted CAs cost money. There are other ways to design a PKI than the one SSL actually uses, but there are reasons SSL works how it does. For example SSH places the responsibility on the user to obtain a key fingerprint from the server by a secure side-channel, and this is the result: some users don't think that level of inconvenience is justified by its security purpose. If users don't want security, then they won't get it unless it's impossible for them to avoid it.

If users just auto-click "accept" for untrusted SSL certificates, then you pretty much might as well not have it, since these days a man-in-the-middle attack is not significantly more difficult than plain eavesdropping. So, again, there's a significant block of servers which just aren't interesting in paying for (working) HTTPS.