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

Costs?

[tsj5j]

Isn't it the case in enterprises where they would rather keep things status quo instead of adding additional layers of (potential) problems? I believe they won't convert unless there's sufficient financial (dis)incentive to do so.

Re:Costs?

[Lord Ender]

It's key management and distribution, not cost. The costs are very low. Training everyone to exchange S/MIME keys, for example, is just too damn hard.

When email clients can automatically look up other peoples' certificates using DNS, then encryption will hit the main-stream.

(Oh, and bass-ackward companies like Apple are also holding back encryption. The iPhone can't do Secure Email after all this time? Really, Apple? Really?)

Re:Costs?

[DarkOx]

I am not sure I agree. We have alot files XML, and flat that get exchanged between our midrange system and serveral of our WinTel and Linux servers. They are on the same lan seqment in the same locked room. The replication to the hot site for these machines is encrypted; because I can't know my DS3 is not being spied on.

I don't say an reason why these machines need to use encyption to talk amongst themselves. Anyone who has access to one is trusted to have access on them all; anyone who is premitted to be in the room where they would have pyasical access is trusted. All encryption would add is additional mantainance; more overhead; and more to go wrong.
Why would we do that?

Re:Costs?

[characterZer0]

Option 1: Allow clueless customers to send sensitive data via FTP. Keep customers. Make money.

Option 2: Require clueless customers so send sensitive data via SFTP. Lose customers. Lose money.

Self-signed is no good.

[Anonymous Coward]

Maybe when getting a server cert is free/easy people will do it defacto. but right now it's either shell out for an SSL cert or greet every traveller with the "omg this site has a self-signed cert!!!oneone" browser warning.

Re:Self-signed is no good.

[Cimexus]

Agreed.

Also I'd argue that there's no real need for the majority of HTTP traffic to be encrypted anyway. Certainly anything that's a 'two way' kind of site should use encryption (anything that allows users to post stuff, or allows/requires them to sign in) is probably wise to encrypt, but for standard 'read only' websites where anyone can just read stuff, why bother encrypting? Even Slashdot doesn't require HTTPS connections for anything other than the sign-in process - again because there's no point encrypting things that are not usernames/passwords/sensitive information.

HTTPS has a significant performance overhead too, which is worth keeping in mind.

This applies to email as well, in a way. For the average user that just wants to fire up their Thunderbird/Outlook Express/other mail client of choice, getting an cert (e.g. from Thawte) is just too difficult. It needs to be seamless and built-in before the masses will use it.

Re:Self-signed is no good.

[schnablebg]

So I guess this "feature" is one example of what is holding back encryption.

Re:Self-signed is no good.

[FrozenGeek]

There is a good reason for the majority of HTTP traffic to be encrypted: Deep Packet Inspection. If you want to stop your ISP, your government, etc, from using DPI, the most effective way to do so is to negate the value of it. HTTPS negates the value of DPI.

Personally, I hate the idea of DPI from a matter of principle. Therefore, I like HTTPS.

I have encrypted this post

[fridaynightsmoke]

I have encrypted this post as my contribution to making encryption more widespread.

Here you go:
kkjkjGHIUgibilhjGHLiubhjbiu78HVji67gfUKGHVuygjh VljhbvolygILJKbIyugIJbikhjbKJBkbvkjnfJ.a,mx jchkdjqJiufhpi9fu{ywe9f8iunsiochjaijkcs

The fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one....

Re:I have encrypted this post

[PingPongBoy]

The fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one

So tell them you were not the encrypter/encoder. You downloaded it. It's the same as people circumventing other hacks, such as the hacks at preventing file sharing - band together with a group of anonymous people. Download each others encrypted data. Obfuscate who the encrypter is, and your own encrypted data can hide.

If this isn't good enough, write a Star Trek story about Klingons. Include plenty of Klingon conversation. Key: kkjkjGHIUgibilh is Blimey! in Klingon. So is jGHLiubhjbiu78HVji67.

Signed certificates

[Spazmania]

Signed certificates are holding up encryption. Opportunistic encryption doesn't happen if it has to be carefully pre-planned.

Yes, unsigned encryption is vulnerable to MITM. So what? It protects against the far more common traffic sniffing and a plethora of other attacks.

Re:Signed certificates

[DavidTC]

And there are plenty of places that MitM would not be relevant.

For example, email and FTP and other clients where the connection is almost certainly set up manually and repeatedly used (vs. web browsing where people may never return) should be fine with unsigned encryption, as all they need to do is store the cert fingerprint and make a fuss if it changes.

But, yes, this is exactly the point I've been making for years. All TCP/IP connections should be opportunistically encrypted, period. Including web pages. There's no reason not to. No, not even CPU. (If the server load is high enough that it matters, by all means, disable it for that server, but it should still be the default.)

Even if it's not the default, make it easy enough to flip on, so that web designers can flip it on for their password and account pages without having to buy a damn cert and get a new IP and other nonsense.

I just had to set up Thunderbird on a new computer, and I noticed, instead of prompting me what sort of email connection (IMAP or POP3) I had, and making me fill out info, it just asked for the server name, and tried the connection itself, prompting me with the ones it found. But the awesome thing was, it actually suggested using an _encrypted_ connection. So, yay, maybe people will actually start using them. (I wonder how many people check their email without even meaning to, via background processes, over open wifi.)

The interesting thing about SSL is that the cert is not actually needed, at all. You can use a SSL connection without a cert on either side, just like you can use one with a cert on both sides.

Sadly, absolutely nothing seems to support this.

Because it's a PITA - Pain In the Ass!

[tomhudson]

1. It's a pain in the ass to set up - do YOU want to have to configure everyone's email, etc. to use it? I didn't think so.
2. It's not needed. If I'm sending somethig sensitive, I can just encrypt it and send it as an attachment, and give them the password over the phone.
3. You're already leaking your sh*t all over the net - and if you use google docs, you're letting an advertising company look at all your information.

Apathy

[quangdog]

I think that much more often than not most folks just use the default settings on their stuff, and at this point nearly all encryption is not something that is set up by default.

While the learning curve for using encryption in email, http, ftp, etc is not all that high, there is enough of one there for most people to just say "meh", even if they understand why they should be using encryption in the first place.

It's like personal home protection for many people - they don't want a gun in the house until after they've been robbed the first time. I'd wager that many people using encryption are doing so because they've been bitten by a lack of encryption in the past.

Inertia

[grub]

What's Holding Back Encryption?

Simple: INERTIA.

Remember back in the day when the OpenBSD guys said Enough Already and pretty much dropped telnet, rsh, rcp, rlogin, etc. for the SSH suite of tools? Yeah, a bit of growing pains at the time but no one would want to go back. It took some time but finally other open source projects followed suit.

People are lazy, if there's no push to change most won't no matter what benefit the change offers.

Re:Inertia

[Anonymous Coward]

I can second that. A few years ago I was working as a database / web programmer for a company when my boss for small intranet applications group decided that all internal applications should run over SSL/TLS. Most of the business applications didn't convey any sensitive information, but some exposed personal information as customer name, address, bank routing number, social security number, phone numbers, etc. The internal network was all switched Ethernet, of course, but just about everyone was switching over to laptops with WiFi, which does carry a certain risk of packet sniffing. We switched over to HTTPS in the test system to find out that the image server run by another group didn't support it. This meant that our users would have either had to see a lot of warning messages about "insecure" elements on the page or either turn down IE's already lax security settings so much they wouldn't ever get any meaningful warnings. Since the group that served up images didn't care at all about encryption and wouldn't budge, the initiative was scrapped.

What should have been a nearly trivial process was shot down for lack of caring.

And pushing it would give false sense of security

[sznupi]

Really, most things which should be encrypted - are. There's no reason to push encryption everywhere; especially if it would confuse people and make them think everything is safe just because it's encrypted.

Re:encryption alone

[Ephemeriis]

is not the whole solution.

This.

I'm fairly certain Blizzard uses some kind of encryption on their database. Probably doesn't send passwords in cleartext. But accounts still get compromised left and right. Not because the encryption is failing, but because people set stupid passwords and share them with friends.

The same thing is true of banking websites, and PINs, and logins to the corporate network, and whatever else. The weakest link isn't whether your data/authentication/network/connection/whatever is encrypted... The weakest link is the person sitting in front of the terminal. And as long as you've got users who'll click on random executables and use their kid's name as a password and share their credentials with someone else, encryption isn't really going to get you very far.

Sure, it'd help... It'd be another layer of protection. Another bit of security. I'm not saying that people shouldn't use encryption... But when you're looking at where to spend money, and what effort is going to get you the most impact, encryption isn't necessarily it.

Expertise

[Abalamahalamatandra]

Until a couple of years ago, I was a consultant for a large three-letter firm (not IBM) that got a project to implement an internal certificate authority that would be trusted by external partners, in support of email encryption.

Some other projects came up that I needed to do and we started searching for someone else within this 20,000+ employee technology company that could do the project and had at least some familiarity with PKI issues.

There was noone.

Couple that with the fact that we were getting the CA signed by an internal division of the company with a globally-trusted root CA, and that division had precisely two employees. To run a public root CA.

I've been in IT for over 15 years, and I think the number of people I've met in that time who see PKI as anything other than a magical black box can be counted on one hand with fingers left over.

Re:There's no reason to encrypt HTTP

[Ephemeriis]

Everything you do online provides personal information in some way.

That's true... But who are you trying to hide that personal information from? If you're sending everything with HTTPS you're protected from maybe your ISP snooping... Or your network administrator... Or someone in the middle like that...

But the website you're visiting is perfectly free to collect anything and everything it wants. You've just secured the connection between you and the site.

If the bank has a pile of tapes stolen, you're still in trouble. If Google leaks some more documents, you're still in trouble. If Facebook changes their privacy policy again, you're still in trouble. If Amazon shares your purchase history, you're still in trouble. If some advertiser drops a cookie on your system, you're still in trouble. If you get re-directed to a sophisticated phishing site and don't notice it, you're still in trouble.

People don't see the value

[Sloppy]

It costs a nonzero amount to get a certificate at all, and a self-signed certificate is barely better than raw http.

To answer the original question, the thing holding back encryption is the above mistaken attitude, that using a self-signed cert is barely better than using plaintext.

There won't be a push for improving the cert system (e.g. by moving to an OpenPGP WoT or something) until more people are encrypting, And people won't be encrypting until they get over their foolish attitude that it's pointless to force attackers to use MitM instead of passive snooping.

When more people start to realize that it's a good idea to force their opponents into doing expensive and risky things, then they will choose to do that and start to use (poorly-authenticated) key exchange. Once encryption with poorly-authenticated key exchange becomes more common, people will start to see a benefit to improving their authentication, so they'll attend more key-signing parties, or exert market forces within crippled single-signer systems to have cheaper CAs, or whatever.

Re:encryption alone

[Creepy]

screw key management trust - MANAGEMENT (as in corporate management) trust is essential. My management forced blocks on ssh and sftp because reverse sessions were deemed a threat for corporate data espionage (not that I can't, say, insert a USB fob and do the same, lol). Whereas before the block I could, say, run xterms on my home machine over an encrypted channel and work at home on my Linux box, I can now only use a Windows machine using VPN software (and incidentally, upper management wants to kill that, but they've had a hard time doing it because middle management does a lot of work from home).

Re:encryption alone

[Ephemeriis]

No measure or countermeasure is ever 100%, but in your disgruntled employee scenario, if you know what the confidential information is, you could use some mix of Rights Management Software... as well as the blocking of file types (say, .png, .jpg, .gif screenshots) from exiting the internal network... as well as preventing USB drive access, etc... and a lock on the computer case. So now the disgruntled employee would have to walk out the door with the computer

Or press CTRL+P... Or snap a picture with their cell phone... Or write the information down on a post-it note... Or call someone up and read the information off to them over the phone... Or just remember enough important information to share it with someone else...

Again, it might not be 100%, but depending on how many 9's you need to put next to your certainty that no confidential data can leave the network, and how much the business is willing to pay to implement it, you can have a fair amount of data protection. You're definitely not helpless to the whims and malice of your users.

The problem isn't in somehow constraining your data from leaving the network. The problem is in keeping the information from leaving the company.

Corporate espionage and whistleblowers and whatever else existed long before digital computers did.

Which is my whole point - no amount of technology is going to prevent a user from leaking information that they have legitimate access to in the course of their work.

You can reduce the impact of accidental leaks... You can block out viruses and keyloggers and whatnot... You can make it hard for someone who isn't supposed to have access to your data...

But the easiest vector of attack has always been the person behind the terminal.

And implementing all sorts of high-tech security isn't going to make it any harder to exploit that weakest link.

If you can bribe a user, or trick them into clicking something they shouldn't, or convince them to trust you, or whatever - you can get access to their data. Regardless of the security measures put in place.