What's Holding Back Encryption? 660
nine-times writes "After many years in IT, I've been surprised to notice how much of my traffic is still unencrypted. A lot of businesses that I interact with (both business and personal) are still using unencrypted FTP, and very few people use any kind of encryption for email. Most websites are still using unencrypted HTTP. DNSSEC seems to be picking up some steam, but still doesn't seem to be widely used. I would have thought there would be a concerted effort to move toward encryption for the sake of security, but it doesn't seem to be happening.
I wanted to ask the Slashdot community, what do you think the hold up is? Are the existing protocols somehow not good enough? Are the protocols fine, but not supported well enough in software? Is it too complicated to manage the various encryption protocols and keys? Is it ignorance or apathy on the part of the IT community, and that we've failed to demand it from our vendors?"
Re:Self-signed is no good. (Score:3, Informative)
what's wrong with a self-signed cert? The data is still encrypted, isn't it?
It's still encrypted, but the question is by whom? What's the point of encrypting something if you can't be sure that the person you're talking to is the same person who encrypted it?
Re:Self-signed is no good. (Score:3, Informative)
Startcom [startcom.org] offers free ssl certs and they are in all the browser roots now (although only recently added by microsoft).
that said, encryption of web traffic adds two significant bits of overhead:
Re:Self-signed is no good. (Score:3, Informative)
Actually, they do a good job and use progressive enhancement, so if you open the link without left clicking on it, it takes you to an actual page (so right click->open, open in new tab, open in new window, etc):
http://slashdot.org/my/login [slashdot.org]
You can then edit the protocol:
https://slashdot.org/my/login [slashdot.org]
You are Perceived to have Nefarious Intentions (Score:4, Informative)
Re:Self-signed is no good. (Score:3, Informative)
One of the biggest benefits of widespread encryption is just making it harder to snoop on miscellaneous passing traffic from somewhere in between, in a fishing-expedition sort of way (whether by governments, malicious private entities, or the guy sitting next to you in the coffee shop). If most data were routinely encrypted with self-signed certs, that'd successfully stymie most of that.
Stopping an attacker from hijacking sessions or masquerading as the target IP or DNS name, is also an issue, but I think much less widespread. When I use https to read my own webmail on my own server, my primary goal is to keep someone from snooping on my data off the local wireless network, which a self-signed cert does just fine for. And even a self-signed cert will catch man-in-the-middle attacks as long as the first connection, when you save the cert, is not a compromised one--- you'll still see a change in certificates if a subsequent connection is compromised, since that doesn't depend at all on signed-ness.
HTTPS (Score:4, Informative)
What's holding back HTTPS is the lack of IP addresses combined with the lack of support for modern versions of TLS...
As it stands, you need 1 IP address per HTTPS site.
What's holding back SSH and causing people to continue using telnet is a number of factors:
1, windows doesn't have an ssh client by default, only telnet
2, some networking vendors (eg cisco) charge extra for ssh support on their devices
3, lots of lower end networking devices only support telnet
What's holding back FTPS and the like is much the same, lack of client support and lack of user knowledge, FTP as a protocol pretty much needs to die anyway, it doesn't work well with NAT... Encrypted FTP is even more broken on NAT because the nat device cannot watch for the ftp commands and open up the appropriate data ports.
When you offer hosting, customers demand to use FTP and often refuse to even consider more secure alternatives.
Also, most email being sent is still completely unencrypted.
Thoughts on Email and DNSSEC (Score:4, Informative)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've been digitally signing all my email for about 15 years; I *tried* to encrypt all my mail, but I've run into two problems: inertia on the part of other people, and poor application support. Thunderbird in particular has had a bug report for "encrypt when possible" for years, complete with a detailed operation to address some of the issues, and no one who has development expertise in Thunderbird will implement it. With that, the people who have keys can start using it regularly and then there's a good reason to get other people to get keys and start using them. Without it, it's "ok, does this person have a key or not" and it's just too much bother for most. Thunderbird isn't the only one: I've looked at other mail programs, and it's always all or nothing. That should be a *choice* (it does have its place), but without a "when possible", there's no graceful transition option.
Then there's DNSSEC, which I've tried to implement. It's a voracious consumer of random numbers because of the vast number of keys you need (if you're hosting a large number of domains, as we do). I bought a usb dongle that is a hardware random number generator, and it *still* takes forever (days) to re-sign our domains, something you are supposed to do monthly.
FWIW...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAktUpfIACgkQIQ3y7i+rW6HDnQCgteApON+rI177T8Ggh8NUPFN0
NIIAoP0gOKvUy636m03supXrmDaCDtQZ
=9RCk
-----END PGP SIGNATURE-----
Re:Self-signed is no good. (Score:4, Informative)
Yup, I have a CACert certificate which is flagged by most browsers. To get it, I showed two pieces of government-issued ID to four people, who each signed a form validating that I am who I claim to be. That's a lot more evidence than most Verisign customers provide.
Really, SSL needs to die as the standard for encryption. We should be using DNSSEC and IPsec. IPsec lets you establish an encrypted connection to an IP address. DNSSEC lets you confidently associate a name with an IP address and can be used to distribute keys for IPsec. When you connect to a remote host by name, the resolver should automatically check for IPSECKEY records as well as A records. If they exist, then your networking stack should automatically use them for key exchange and then automatically encrypt everything that you send to that IP. You should then just need a getsocketopt() call to see whether a connected socket is using end-to-end encryption.
Currently, no existing network stacks work this way.
Re:encryption alone (Score:3, Informative)
Time to change job.
Re:More direct costs. (Score:3, Informative)
What is the CPU overhead for Encryption? My brother just installed Truecrypt on his 3.5ghz i7 and it says he can do ~510MB/sec of AES-256.
Assuming a 100mbit network connection, 12.5MB/sec would be about 2.5% cpu. If it was a dual socket server, it would be about 1.25% overhead. If the 100mbit connection was shared by 10 machines, it would be 0.125% overhead per machine.
My statement makes the assumptions of similar CPU performance to my brothers 3.5ghz i7, ignore decrypting incoming data which would be less than outgoing, and uses encryption on the filesystem compared to HTTPS, which would be quite different depending on how it's implemented.
AMD/Intel both will have HW accel'd AES in the next chips which both claims about 40% improvement, so typically sub 1% overhead I would guess.
Re:VOIP isn't everywhere? Good! (Score:2, Informative)
whether its large data loads being done over the network causing the voice quality to go through the floor
QoS issues with your network. Many VoIP installations seem to fail to consider LAN QoS. A busy LAN is just as deadly to VoIP as a busy WAN.
or a network outage killing the system dead
Poor High Availability design. A properly designed network should be able to tolerate the failure of a core switch or router without any noticeable impact to traffic. Sure, if you have an access switch that phones are connected to go belly up, you're going to lose some phones, but it's kind of hard to get around that one. Keep a hot spare on hand if uptime is that big of a concern.
or SIP server bugs
The beauty with SIP is that it is an open standard. The downfall of SIP is that not every vendor supports the same SIP RFCs (Compare RFC 2543 and 3264; two different "standards" for placing SIP calls on hold- although RFC 2543 is obsolete, some vendors still utilize that mechanism for call hold. There are many other examples of this within the SIP stack). Many people read that a product supports SIP and instantly think that it will work with any other product they have that supports SIP. This isn't always the case if one vendor or the other doesn't support the same SIP RFCs. When you create SIP Profiles in Cisco Unified Communications Manager, you can enable/disable some of the RFCs that other vendors may or may not support (or may support differently) which can frequently resolve these SIP headaches.
or just bugs in the IP phones themselves.
This is a pretty rare event with Cisco phones in a Cisco UCM environment- especially if you are running the current UCM release. Since Cisco deploys phone firmware as part of a UCM build, the software is typically well tested for interoperability. Not that it never happens, but in my experience, it's quite rare- especially since the old Windows-based CCM 3.x and CCM 4.x days are past.
VOIP for the office is hype - all it does is save on some cabling and wall sockets which had already been installed and paid for anyway!
Sounds like someone is resisting the change. The reduction in MAC changes alone saved us an enormous amount of time when we switched from a traditional PBX environment to a Cisco VoIP solution. Plus, ever since Cisco UCM version 5.x, they are using Linux rather than Windows, so that's certainly a benefit.
Re:Self-signed is no good. (Score:3, Informative)
That most people don't have a 15 Mbit residential connection, or a 2 GHz processor... You can't really have missed that point. A significant portion of the population (of the world, not just the USA) does still use some form of dial up and encryption would definitely be noticeable to them.
Re:Self-signed is no good. (Score:3, Informative)
> by default, most browsers won't cache anything that is ssl-encrypted.
Not quite true. They will cache it, but some only in memory, and in some cases only when you send back particularly aggressive cache directives. FireFox was particularly poor at this for a long time, but now they changed the default setting so 3.x will work a bit better.
Re:encryption alone (Score:3, Informative)
If you want to self-sign then set up your own trusted signer (not hard!) and distribute the signer public key to people before they use the service.
You mean, set up your own CA, and ask your customer to trust that?!?
Most would probably be naive enough to trust it...not realizing that they gave you the power to forge the certificate of their bank as well.
It's far preferable to ask them to just trust the web server certificate ("make an exception for"). That way, the web server operator does not get the power to seemlessly forge certificates for other domains.