4 ms·
How far are we from just encrypting everything on the web because it has a negligible cost? Is this purely CPU-limited or is there another reason (does it take
by MikeCapone 16y ago
How far are we from just encrypting everything on the web because it has a negligible cost? Is this purely CPU-limited or is there another reason (does it take much more bandwidth? screw with caching?)? Is Moore's Law taking care of this quickly, or is it still far off?
- amalcon 16y ago"Screw with caching" is probably the biggest issue. In order to negotiate the SSL connection, any proxy (on either end) needs to have your certificate. There's also the issue that some browsers (Firefox, I'm looking at you) do their best to scare users about self-signed certificates, which means that you need to pay for a cert. It also breaks the shared-hosting model: your entire HTTP stream is encrypted, which means that key negotiation occurs before the server has your HOST header. This, in turn, means that the TCP/IP data (IPs and ports) are the only pieces of information that the server can use to determine which certificate to use. In practice, this means that a server can only host multiple distinct sites if it has multiple distinct IPs.
- MikeCapone 16y agoWould it be possible to devise a caching system that works with encrypted data without weakening security too much?
- mcav 16y agoAnything's possible. But if it isn't compatible with existing proxies, it isn't gonna happen any time soon.
- jmillikin 16y agoThere's also the issue that some browsers (Firefox, I'm looking at you) do their best to scare users about self-signed certificates, which means that you need to pay for a cert. Firefox is absolutely in the right, here. Self-signed certificates are worthless; if you'd like a free certificate, use StartCom or CACert. It also breaks the shared-hosting model: your entire HTTP stream is encrypted, which means that key negotiation occurs before the server has your HOST header. This is only true for older servers; modern TLS implementations support name-based certificate negotiation.
- jcnnghm 16y agoUnfortunately there is more to this than server support. IE6 and every browser on XP, including firefox and chrome, don't support the tls extension. Even apache doesn't ship with it. For all practical purposes, name based virtual hosting still doesn't work for ssl. You'll need a seperate ip address for each name, unless you can use a wildcard.
- buster 16y agoWhat's the benefit of using CACert when browsers don't include those? https://cacert.org https://cacert.org gives a big fat warning in chrome.
- jmillikin 16y agoMy browsers include CACert's root certificate -- therefore, I use it for securing any of my private websites. It's just like using a self-signed certificate, except not stupid. If you need to support the general public, pay the $20 or whatever for a certificate with a widespread root.
- amalcon 16y agoThey're worthless except insofar as they let you get the encryption benefit out of SSL without paying the cost necessary to get the authentication benefit.
- jmillikin 16y agoWhat's the point of encryption if you don't know what server you're connected to? Somebody could be intercepting your traffic, and you wouldn't realize it.
- amalcon 16y agoThe point is to stop one particular class of attacker: the one that's passively sniffing and archiving network traffic while trying to remain invisible (and thus isn't actually altering the traffic profile). This is a benefit (over in-the-clear HTTP), but Firefox and others effectively tell users that it's more dangerous than regular HTTP.
- est 16y agoHow about Server Name Indication?
- tlrobinson 16y agoSNI is supposed to fix the SSL + virtual hosts problem, but XP doesn't support it, unfortunately. http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Transport_Layer_Security#Support_for_name-based_virtual_servers http://en.wikipedia.org/wiki/Transport_Layer_Security#Suppor...