What's Holding Back Encryption?

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?"

Comments

Re:Self-signed is no good.

[danpritts]

Startcom 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:

• encryption takes CPU time. on busy web sites this really adds up.
• by default, most browsers won't cache anything that is ssl-encrypted. This really adds up too. Browsers warn you if some elements on an encrypted page aren't encrypted, so you can't mix elements easily.

Re:Self-signed is no good.

[maxume]

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

You can then edit the protocol:

https://slashdot.org/my/login

You are Perceived to have Nefarious Intentions

[Nethemas the Great]

Among the myriad reasons... Those that bother with encryption on anything other than a shopping cart are generally perceived to have nefarious intentions. As the old saying goes... "what do you have to hide if you're not doing anything wrong?" Beyond that:

• Government arms can compel you to produce the key or face obstruction charges...so what the point. Espionage business or personal isn't really on peoples minds. Survey people around you and see how many know anything about the Google-China deal.
• Encryption technology was/is banned from export. Distribution of software with out of the gate support while satisfying relevant laws is a pain/expensive.
• [En/de]cryption is processor intensive. Servers have to have significantly more power to handle the same number of people.
• People are oblivious to the information they're making available and the ramifications there of. Take Facebook/MySpace for example, both are a dataminer's/identity thief's candy store.
• Authority signed security certificates are expensive. Self-signed certificates produce wonderfully scary messages in web browsers and are vulnerable to MIM attack. No certificate (unencrypted) sites are displayed in the browser as if everything was perfectly alright, safe, and secure.

HTTPS

[Bert64]

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

[vanyel]

-----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.

[TheRaven64]

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.