Take the 2-minute tour ×

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.

share|improve this question
The guys who sell ssl certs will love that. –  Hardwareguy Jun 23 '09 at 21:17
This question might be more appropriate for ServerFault. –  Achilles Jun 23 '09 at 21:18
Sure. Why would you want to? –  JP Alioto Jun 23 '09 at 21:32
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 Jun 23 '09 at 21:57
All else being equal, if you use 2x the number of bits in the key, you just SQUARED the amount of work needed to break it via brute force, while normal encryption and decryption would be just around 2-4 times slower. Brute-force being 10x faster just loses you around 3.3 bits of key strength. You should be more worried about advances in the math the crypto people use than about computers becoming faster. –  CesarB Jun 23 '09 at 22:42

7 Answers 7

up vote 10 down vote accepted

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 :


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!


share|improve this answer
This was discussed in detail on a recent Security Now podcast. See grc.com/sn/sn-198.txt and search for "couple of cons that were not discussed" –  Jeff Moser Jun 23 '09 at 21:23
If HTTPS was used for all communications, we would use other means (like Expires headers) to regulate caching. My question is only about the logic of performance increases in computing vs encryption. –  Pies Jun 23 '09 at 21:26

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.

share|improve this answer
  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.
share|improve this answer
1. But is the computing cost of encryption symmetric with the cost of brute-force? 2. I'm asking about a situation where the cost of encryption is so low, it makes sense to use it always -- Big Brother could swap in some spying code into your Debian torrent. –  Pies Jun 23 '09 at 21:25
Because if everything is encrypted there is no 'special' traffic so no sigint - I can't learn anything about your radical network of Joel fans by looking at who you send encrypted messages to. –  Martin Beckett Jun 23 '09 at 21:27
Why do you think it is ridiculous to distribute software via a secured channel? –  Dirk Vollmar - 0xA3 Jun 23 '09 at 21:30
Because there's no privacy to protect and it wastes CPU cycles. –  dsimcha Jun 23 '09 at 21:32
@Pies: No, the cost of using ciphers when you know the key is not particularly related to the cost when not knowing the key. Modern ciphers are essentially proof against brute force as they stand. –  David Thornley Jun 23 '09 at 21:49

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.

share|improve this answer
What if someone finds a weakness in AES that makes it a million times easier to break it? Wouldn't using a 16kbit keys be safer? –  Pies Jun 23 '09 at 21:28
If they find a weakness sufficient to make breaking it practical, adding more bits to the key isn't going to help much. –  David Thornley Jun 23 '09 at 21:50
Crypto doesn't work that way. –  Thomas Jun 23 '09 at 21:51

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
share|improve this answer
1) Computer cycles are getting cheaper every day. 2) Doesn't matter for my question. 3) If you just encrypt valuable data, it makes it easy to spot and focus efforts on. If everyone encrypts everything, it makes attacks far more difficult. –  Pies Jun 23 '09 at 21:33
So, why would there be a problem with every server having a certificate? They aren't expensive or onerous to generate. Right now, what's expensive is buying a cert that will be recognized by common web browsers in their default configuration; to put this another way, what you're paying for is not encryption but authentication. –  David Thornley Jun 23 '09 at 21:52
@pies 1. cheaper != free and imagine the sum cost if EVERY server and EVERY client were doing SSL for EVERY transaction 2. This is why I said possible yes advisable no 3. if you encrypt everything you might get lazy with security because "it's all https" @david not expensive != free –  Hardwareguy Jun 23 '09 at 22:01
@Hardwareguy: What if you'd get a free SSL certificate with every domain you buy? –  Pies Jun 23 '09 at 22:06
@Hardwareguy: Certificates are, essentially, free. You can generate your own, no problem. What costs is establishing some sort of connection between you and your certificate. –  David Thornley Jun 24 '09 at 18:46

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.

share|improve this answer
But if everyone used HTTPS, so would those ad servers etc. My question is whether it is possible to lower the cost of it so much, that the marginal profit of security is worth the expense. –  Pies Jun 23 '09 at 21:40
It is probable for the monetary cost to be lowered but consider what kind of transition would happen as you wouldn't imagine every server around the world switching to HTTPS simultaneously, would you? –  JB King Jun 23 '09 at 21:56
It doesn't have to happen all at once. For example Google Analytics javascript file is available both via http and https. –  Pies Jun 23 '09 at 22:07
However, if a site uses both http and https there is a dialog that will pop-up about downloading non-secure items that would be a nightmare and quite likely to happen as each webmaster has to know if all their image and javascript includes and other stuff happens in unison. Parts of it do have to happen at once is my point here. –  JB King Jun 23 '09 at 22:13
@JB: That's because right now http is the default. If https was the default, there wouldn't be a problem (i.e. there are no warnings about secure items on an insecure page.) –  Pies Jun 23 '09 at 23:30

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?

share|improve this answer
I would expect that by that time the software would be capable of handling that kind of thing, because, well, everyone would be doing it. I'm just asking if it's at all possible logically. –  Pies Jun 23 '09 at 21:43
Software can always handle it - it's the other effects, like session tracking that you need to consider. –  Martin Beckett Jun 23 '09 at 22:03
Servers can kill SSL sessions if they want to recover the associated resources. SSLv3 only has its own close message because using TCP FIN allows an attacker to insert that packet without the client realising that the server didn't intend to close (called a truncation attack). And servers can keep plain HTTP connections open with Keep-Alive if they want to. It's just that SSL handshake is considerably more expensive than TCP handshake, so keeping connections open is more valuable. –  Steve Jessop Jun 24 '09 at 18:43

Your Answer


