Slashdot Mirror
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?"
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.
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.
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....
This is a substitute for a clever sig that fits within the maximum number of characters.
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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.
...encrypted communications are too bloody hard to debug!
With unencrypted protocols, I can whip out the packet sniffer and find out *exactly* what's going on. With encrypted protocols, I have to write reports like "we have verified our software configuration and believe it to be correct; perhaps the problem is at your end?"
Maybe we need to come up with a standard way of encrypting things, that our packet sniffers somehow know how to decode. Maybe even with a "relax the crypto" configuration flag we can throw during debug.
Do daemons dream of electric sleep()?
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.
Trolling is a art,
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.
One that hath name thou can not otter
For most of the Web surfing that I do, full https encryption simply isn't needed. Why do I need encryption (which adds another quite significant protocol layer) to surf Slashdot or CNN or xkcd?
OK, granted, I probably should use encryption or TOR for that last one or the 'raptors will catch on. But other than that... why?
Paleotechnologist and connoisseur of pretty shiny things.
Ever since our company fell for all the marketdroid hype from Cisco for VOIP and dumped our old but reliable PBX system we've had one problem after another. The new system has been as unreliable as its possible to be whether its large data loads being done over the network causing the voice quality to go through the floor or a network outage killing the system dead or SIP server bugs or just bugs in the IP phones themselves.
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! Well whoop de fucking do. Talk about Emporers new clothes.
First, keep in mind that name-based virtual hosting with HTTPS is very limited. With few exceptions, you're quite restricted in your ability to host multiple SSL-encrypted sites on a single IP address. Most often, one must instead assign each SSL-encrypted virtualhost to a dedicated IP address. If every website was, today, to switch to HTTPS-only operation, and if the RIRs were to allow it, we would immediately run out of IPv4 addresses. You can argue that we should instead be using IPv6, and I might agree, but we're simply not there yet.
Secondly, performance is a major consideration for many companies. This is especially true for internet marketing & advertising efforts, for whom every millisecond matters in their ability to serve their content. Advertisers are unlikely to prefer SSL over unencrypted content. Worse, marketers are those most likely to desire poor security practices in order to gather information and track users, while also being those that provide means of financial sustainability for many sites. That is, if the marketing companies won't go for it, the companies being paid by the marketing companies won't go for it.
Thirdly, cookies and other domain-specific security measures may not be functional via HTTPS, depending on the browser's security configuration. Some browsers provide warnings or block unencrypted content sourced by encrypted pages, or originating from another domain. These security profile of the browser may be much different for SSL-protected sites than for unencrypted pages. Ultimately, this would prevent, discourage, and limit advertising efforts which (again) drive the sustainability of many sites.
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.
"Work is the curse of the drinking classes." -Oscar Wilde
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.
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.
"Work is the curse of the drinking classes." -Oscar Wilde
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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).
But I'm not really using encryption because
1- I don't have much of value to encrypt. Clearly, that's not the case for everyone, but encrypting my to-do list, address book, birthday list, and pathetic attempts at programming seem very much overkill.
2- I don't feel confident I would do encryption right. I COULD encrypt my password list, but right now it's on a piece of paper hidden somewhere. If it were on my PC or cellphone, even encrypted, I'm not confident that i would be using a secure encryption method, nor that it wouldn't be short-circuited by a trojan/keylogger
3- I'm afraid I'll get encrypted out of my data. A few times a year, I have to clean up my HD and recover broken files. What happens when the files are encrypted on top of it ? Any way to recover them ?
4- Is encryption reliable ? what if I can't recover my data after I encrypted it ?
5- I'm not sure what programs I should use. Windows has some basic stuff, then there's PGP, Truecrypt...
The Cloud - because you don't care if your apps and data are up in the air.
Two of my imaginary friends reproduced once
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.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I wish *EA* would use hashes or something of the sort on their databases. Last time I tried to reset my password the damn thing mailed me that actual PW in plaintext, which indicates to me that they're too stupid to realize that:
a) Storing non-hashed passwords in a DB is a good way to get hacked and expose all your customers accounts. It's really quite dumb
b) Email is an insecure medium for sending somebody's password down the wire
-----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-----
In a sense, though, the weakest link is actually the sysadmin, who isn't enforcing appropriate password complexity, length, age, etc... As well as, in a corporate context, not locking-down the network and machine and user profile, so that keylogging executables aren't so much of a problem. Even if the business and/or customers complain about "impact", there's always a way to win the argument for establishing and enforcing IT policies that make sense. You have to be willing to save users from themselves.
Negative.
Say I'm the absolute best sysadmin in the universe. I've got everyone required to use long, complex passwords that they have to change frequently. I've got smartcards and retinal scanners and crazy sci-fi encryption going on. Absolute top-of-the-line security.
And some disgruntled employee decides to share some confidential information with someone he shouldn't.
How am I going to prevent that?
That employee has whatever credentials are necessary to access that information. They have to, because their job requires it. So no amount of passwords and encryption are going to prevent that employee from accessing the information.
The weakest link is always going to be the person sitting in front of the terminal. It doesn't matter how secure your network is... If someone decides to share information that they shouldn't, that information is going to get out.
"Work is the curse of the drinking classes." -Oscar Wilde
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.
"Work is the curse of the drinking classes." -Oscar Wilde