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

encryption alone

[bugs2squash]

is not the whole solution.

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.

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

[jarocho]

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.

Re:encryption alone

[Ephemeriis]

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.

Re:encryption alone

[Z00L00K]

Time to change job.

Re:encryption alone

[Nursie]

Depends what you're encrypting for...

I don't, for instance, care about having slashdot encrypted at all. if someone steals the password or the cookie then so be it. But where I want encryption at all - online banking, shopping - I want to be sure. And it's not really a case of "extra sure", it's any surety at all.

If you're angling at changing the signal-to-noise ratio then I sympathise, but unauthenticated SSL is pretty much useless in my book. That's not to say self-signed is useless, if you get the self-signed cert ahead of time, or the public key of a private CA, then it's great. In fact I'd go so far as to say where you have explicitly accepted a CA in a situation where you know there has been no compromise, it's more trustworthy than any of the preloaded CA certs in a browser.

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.

Re:encryption alone

[turbidostato]

"the weakest link is actually the sysadmin, who isn't enforcing appropriate password complexity, length, age, etc..."

Who the hell do you think a sysadmin is? Stablishing policies is way beyond his duties. He can *counsel* about how technical means can help to acomplish a policy but he is not the one to build the policy in first place, much less to enforce anyone on his own.

Re:encryption alone

[Stradivarius]

the weakest link is actually the sysadmin, who isn't enforcing appropriate password complexity, length, age, etc...

There is value in those things. There is also a point after which you get diminishing returns, and in fact may make your security worse. For example:

1. If you make the age requirement too short, then nobody can remember their passwords. So they start working around it by picking less secure passwords, writing them on stickies, or flooding your helpdesk with password-reset requests.

2. Complexity requirements are good up to a point, but when you start requiring too many different types of characters you just get people resorting to the equivalent of P4ssword! so they can actually remember the stupid thing. That may meet your complexity metric but a dictionary attack program will probably crack it quickly.

IMO we need to move away from such a heavy reliance on passwords, and towards some sort of two-factor system. When an individual has to create dozens of different passwords for their work systems, banks, retailers, email providers, and who knows what else, it becomes way too much to manage, and people take shortcuts as a result. They share passwords among different entities, or create weak passwords, etc.

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.

This is the sort of statement that drives even security-conscious users nuts. Concern about "impact" is not "complaining". It is acknowledging that security policies can have a big impact on people's abilities to do their job effectively. A policy that makes IT sleep easier at night may also be the policy that grinds a worker's progress to a halt. Good security is a collaborative process between IT and their users to find the right balance for the circumstances.

Re:encryption alone

[TerranFury]

blocks on ssh and sftp because reverse sessions were deemed a threat for corporate data espionage

Part of this is the fault of the OpenSSH distribution of sftp. It is too tightly coupled to ssh for many uses. If we want sftp to replace ftp (and there are many good reasons why we'd want this, NAT being high on the list), we need to make it easy for people to configure sftp servers that do nothing but serve "chrooted" sftp. The fact that serving files and getting a login are just the tiniest misconfiguration apart is a big problem.

As it is, there are three options that I am aware of:

1. Modify sftp-server to behave as though chrooted (without ever actually running chroot), and disable the client from executing anything but sftp-server in sshd.conf
2. Build a chroot jail, and do similar sshd configuration to #1
3. Use a different SFTP server, e.g. CoreFTP on Windows.

Of these, #2 especially is a very crappy solution; #3 is the easiest, but AFAIK Windows-only. Option 1 is my personal favorite on Linux, but has the disadvantages that (1) you need to maintain your own sftp-server, and (2) if sftp-server is exploitable, then you have a problem since IIRC it runs suid root. There should be a simpler, secure way to set this up out-of-the-box. If such a thing existed, and were standard and Open Source, we'd see SFTP used a lot more.

(A lack of clients is also a problem, particularly on Windows, but ExpanDrive ($$$) is pretty good. The Open-Source "Dokan" is ok too, but transfers are slow. The best thing would be for ExpanDrive to get all the kinks worked out and to then be bought out by Microsoft and incorporated into Windows by default.)

I could make a similar argument about WebDAV, actually. It would be deployed more if it weren't such a pain to set up. In principle there's nothing stopping someone from making a nice self-contained WebDAV fileserver. But AFAIK such a thing doesn't exist.

Re:encryption alone

[h4rm0ny]

That's fine, but certificates cost an obnoxious amount considering the time and resource it takes to generate and serve one. The government could provide a central certificate authority for less than it costs for a couple of MPs to have lunch, but they don't.

And as I'm posting, I might as well list my #1 reason why emails aren't routinely encrypted with GPG / PGP: it doesn't encrypt HTML emails properly (or it tells me that it doesn't). Maybe the people who write these tools are still insisting that they like plain text and HTML emails are a plague upon the land. But the rest of us want it and use it.

Re:encryption alone

[Ephemeriis]

You went from the above in your original post, to whistleblower employees playing Spy vs. Spy in your latest. I humored your first reply by pointing out ways that you can actually layer your security to prevent most data protection breaches, instead of resigning yourself to the fact that users prefer to make their passwords "password", and it's not like there's anything you can do about that... But come on, you're kind of changing the subject here... I specifically said that nothing is 100% effective. I realize that cognitive marvels can memorize things. Or write them down on a notepad. I wasn't talking about that, but then neither were you initially.

Yes, actually, I was.
The original subject of this entire thread was, in regards to encryption:

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?

To which bugs2squash replied:

encryption alone is not the whole solution

Which eventually resulted in my posting my assent.

I never suggested that encryption was useless. Nor did I suggest that your layered approach has no merit. I stated, instead:

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.

The weakest link is the people behind the terminals, which I've said over and over again.

You're pointing out one specific person behind a terminal - the sysadmin. And, yes, a lazy sysadmin is going to be a problem. And the solution to a lazy sysadmin isn't going to be throwing hardware and technology at that sysadmin - it's going to be training that sysadmin how to do their job correctly. And if the training succeeds, then that sysadmin will ask you for the appropriate tools to implement whatever security they feel is necessary.

I've just been throwing out one random example after another where technology isn't going to solve the problem for you.

I used the example of convincing a user to click something they shouldn't... I did not mean to suggest that this could only be a trojan on their computer. It could also be as simple as buzzing somebody through a door because they claimed to have left their key/badge/whatever in the car.

I never suggested any kind of spy vs. spy stuff... I pointed out that whistleblowers and corporate espionage have existed since before digital computers... Not to suggest that your layered approach would be useless in the face of such elite hax0rs... But to point out that information has been leaking out of companies since before digital encryption existed.

My whole assertion, from my very first post, is that technology (specifically in the form of encryption, but also in the form of just about any other security product) is not the whole solution. And that in many cases your time and effort is better spent in educating the users of that technology - both the end users reading their mail and the sysadmin running the mail server.

Re:encryption alone

[ArsenneLupin]

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.

Re:encryption alone

[turbidostato]

"If Joe User cannot create a password that has less than 12 characters"

He then will moan to management which in turn will ask the sysadmin who the hell does he think he is to enforce such an unasked for policy. Management stablishes policies not technical staff.

Re:encryption alone

[Mista2]

I have worked at an office, I cant say where, but they had demagnetizers at the dor for nuking magnetic media, Cellphones and USB keys are banned. There is no white paper anywhere, only yellow coloured paper which the copiers scan as black. The desktop PCs are terminals with no USB posts accessable to the users, and the terminal software wont pass through a prtscreen key to windows.
Some apps are even escured against having the clipboard work between it and any other app running in the session to prevent copy and pasting between apps.
The only printers and copiers are in public locations, and require swipecards to login to copy or retrieve print jobs, images of the first pages are archived for every print and copy job.

Then there was the secure office where I wasnt even allowed to service PCs' If one broke or they had a problem, the PC would be left outside the door with the HDD removed, they imaged and ran their own desktop, and their network is isolated from the general LAN, no internet access from that office.

Man, what a bi*&ch of a place to work. Glad I only did occasional support there.

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?

[wvmarle]

http (web): my e-banking is encrypted, I couldn't care less to get my slashdot feed unencrypted. Well save for sending my password when logging in maybe. https is nice there. But reading a newspaper online, no. Most of http traffic is not sensitive, it is public information that is sent to anyone who asks for it. Still if a site is going https it gets encrypted and I as user don't have to do anything. If I remotely log in to my server, I use ssh, again encrypted and fully transparent for me as user.

Now e-mail: encryption could be very nice but how am I going to get keys from my correspondents? Do I have to manually ask them to send me or so? It seems so. I am not aware of any automated method to get their public key. ssh is transparent in key exchange, https too. E-mail not (yet). Besides, is there any (formal) standard to encrypt mail? And if I cc: to several recipients that means the e-mail has to be split before encrypting already. Makes it quite expensive when you're on a slow uplink.

And IM well not using that much any more but 8-10 years ago ICQ did have an option to encrypt traffic if a direct connection was in place, but that may be a feature of my licq client alone. But it shouldn't be too hard to implement automatic key exchange and user-transparent encryption there.

All in all I think there is a lot more information that is public on the Internet than what is private. Only private information should be encrypted, the rest is a waste of resources, so https has an important place but only for specific info. Encrypting stuff like BitTorrent is merely to hide activity, not because the transmitted information is sensitive. And encrypting e-mail is at the moment just plain impractical.

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.

Re:Costs?

[Em Ellel]

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.

Erm, time IS a cost, a HUGE cost, often much bigger cost than anything else.

-Em

Re:Costs?

[NuclearRampage]

Parent here has a great point. When we implemented SFTP it was a huge nightmare of support calls. Customer lemmings were incapable of following the very detailed picture tutorial sent to them. Obviously the most asked question was why we changed.

Re:Costs?

[Lord Ender]

That's not email encryption. That's network encryption. S/MIME, which BlackBerry and Windows Mobile support, is email encryption.

Re:Costs?

[TheRaven64]

My publisher wants me to send things to them using FTP. I refused. Their IT staff refuses to run an SFTP server (or HTTPS WebDAV, or anything else that is marginally secure) for them. They also block outgoing SSH from the corporate network. I run an SFTP server for drafts of my latest book and my editor has to download them from home and take them in to the network.

Sometimes clueless customers are the problem. Sometimes clueless admins are. If it's clueless customers, then a clueful admin can run SFTP and WebDAV as options for the clueful customers and just warn the clueless customers that using FTP is insecure and that you accept no liability for data theft that results from it. If it's clueless admins, there's not much you can do about it.

Fortunately, clueless admins tend to leave other holes in their security, so you can usually use one of those to sneak a secure channel through...

Re:Costs?

[bitslinger_42]

I couldn't care less to get my slashdot feed unencrypted.

Coming from a reasonably-free Western country, I can understand that attitude, but there are still problems. What if, for some reason, a government with jurisdiction over you decides to start monitoring Internet activity, looking for signs of insurrection? You're fine, because you're doing nothing wrong, so there's nothing for you to hide. But wait, you were in a chat room one night at the same time as a guy on their watchlist, so now you're connected to terrorists, and they'll be watching you more closely. And then, one day, you click a link to a news story from Slashdot, and the story's on Al Jazeera's website. It doesn't matter that the story's about the earthquake in Haiti, it could contain coded instructions, blah, blah, blah. And then, all the sudden, you go to this website that's encrypted. The encrypted traffic itself is a red flag, since it is unusual for your normal behavior, even if they can't see the data itself.

This is a real problem for people who truly need security. There are lots of places in the world where activists (freedom fighters, terrorists, whatever) need to be able to communicate securely, but the governments they're protesting explicitly watch for encrypted sessions as evidence of wrongdoing (think China, North Korea, Myanmar, etc.)

Even if you take governments out of the picture, there are still places where I might want even slashdot encrypted. Say, for example, I were to read slashdot from work (completely hypothetically, mind you :-), and I read a story that contained a comment with graphic sexual content. I didn't go there for that content, I might not have even read that far down the thread to see the text, but the network monitors at the office saw it, and now I'm getting looked at by security or HR. Sure, I'll probably be cleared for the one-off event, but the investigation will get logged, and they'll look more closely next time, etc.

It used to be the norm that there were places with an expectation of privacy, where governments and employers couldn't look without a court order. Ubiquitous Internet encryption moves us back towards that, which should be a good thing.

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.

[R2.0]

"With a 15 Mbit residential connection and a 2Ghz processor, I find it hard to believe that the performance drop will matter...to me.

To the server, maybe.

Oh, and what's wrong with a self-signed cert? The data is still encrypted, isn't it? "

You flew in a private jet to Congressional hearings, didn't you?

Re:Self-signed is no good.

[schnablebg]

Actually /. does not make it even possible to login via HTTPS, at least with Javascript turned on. The Totally Sweet Javascript popup they use for login is sent over plain HTTP, because it is not possible to POST to HTTPS via Javascript due to the same origin policy in browsers. If it is possible to get an HTTPS login page on /., I can't figure out how to do it.

Re:Self-signed is no good.

[schon]

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.

[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

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.

[Trepidity]

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.

Re:Self-signed is no good.

[Ritchie70]

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

Why?

There are millions of sites out there that allow user posted content. Millions more that require a user login to access free content. On most of those, especially the later category, there's really no point. It's just some web guy jerking off to his ability to do so.

Most of those, I shrug and use my standard, dictionary-attack-vulnerable, stupid password and user name. Because I don't care if someone imitates me on vwspeedclub.com (made that one up) or even on Slashdot. Oh no. Some loser might pretend to be me? On my precious Slashdot? Mod points aren't that important to me.

Likewise, I don't need the email to my mom or my sister about Christmas encrypted. Go ahead, find out what we're having and who's going to be there. See if I care.

Even the email to my lawyer about the house we're buying or my accountant about the taxes - once again, really not much sensitive in there.

At my job, if I want an email sent safely to an outside party, all i have to do is put "[SEND SECURE]" in the subject. I don't think I ever, ever have done that - except once to see what the result looked like - nothing I do is that interesting.

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.

Re:Self-signed is no good.

[Aram Fingal]

What about the argument that a policy of only encrypting sensitive information draws attention to encrypted information because it must be sensitive? If you encrypt everything, an attacker doesn't know which particular piece of information is worth trying to crack (or otherwise attack with key logging, social engineering attempts, etc.)

Re:Self-signed is no good.

[bkr1_2k]

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.

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

Re:Self-signed is no good.

[gmack]

Not just that.. IE, Chrome and Safari don't have the SNI support needed to allow ssl-encrypted based websites to share IPs because Microsoft only included SNI support in it's libraries for Vista and newer OS.
It also doesn't help that the most common web server on the internet has only recently begun to add support for it because they got suck waiting for openssl to get around to adding SNI support.

Unless we want to use a crapload of extra ips while ISPs are getting stingy with them we need to wait a few years before we can go to an all encrypted based web.

Re:Self-signed is no good.

[zuperduperman]

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

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.

Re:I have encrypted this post

[DriedClexler]

So tell them you were not the encrypter/encoder. You downloaded it.

And when they make it illegal to download and view encrypted files, or files from an unverifiable source, your brilliant countermeasure will be _____ ?

Re:I have encrypted this post

[badzilla]

I got in A LOT OF TROUBLE when I decrypted that! Next time at least have the decency to flag it NSFW.

Re:I have encrypted this post

[93 Escort Wagon]

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

Like many others, you made the mistake of choosing a weak key. Here ya go:

"Be sure to drink your Ovaltine"

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.

I'll tell you what it is...

[multipartmixed]

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

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.

Re:There's no reason to encrypt HTTP

[Cthefuture]

Everything you do online provides personal information in some way.

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.

It's simple.

[Low Ranked Craig]

It won't happen until the pain of not doing it exceeds the cost of implementing it.

Re:It's simple.

[louzerr]

Or, the cost of NOT doing exceeds the cost of doing it ...

What's the problem?

[spaceyhackerlady]

What problem do we need to solve here? If it ain't broke...

Just for the hell of it I've toyed with hooking my geiger counter up to my computer, generating a couple of DVDs full of random numbers (really random) and using them for one-time pad encryption to send email to my Mom. Which cannot be cracked, by anybody.

There is also the issue that if you lock things down too tight you risk locking yourself out and can't get back in.

...laura

Re:What's the problem?

[maxume]

I've thought about distributing such DVDs (I might not go so far as to get a Geiger counter) to people that I would want to communicate with after a shit-meets-fan scenario, but they would look at me like I was a loon if I brought it up, so I haven't done anything about it.

One Word:

[louzerr]

Verisign. Because of the ridiculous cost of THEIR certificates, and that browsers don't seem to properly recognize any certs but ones from Verisign. People either use fake certs (encrypted traffic, but no verification of trust), or simply don't bother.

Also, because so many sites pull in images and other content from non-origin servers, webmasters do not know how to build a proper SSL site in most cases. It's tricky to do right (not impossible - just tricky), and most web designers / site administrators simply give up on SSL, rather than try to learn how to implement it properly.

Why?

[FlyByPC]

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?

More direct costs.

[SanityInAnarchy]

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

It also costs a nonzero amount in server CPU usage and/or dedicated hardware to do the crypto itself, especially the https sessions. For example, Google App Engine will handle the SSL for you for free, using a wildcard cert for *.appspot.com, but the crypto does count towards your CPU quotas.

These two factors suggest that it makes sense for crypto to be used only where needed, rather than using it everywhere we can. Combine that with corporate sluggishness to approve any spending, and you can imagine why even where it is needed, it can be an uphill battle to get it actually adopted.

Re:More direct costs.

[Bengie]

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.

VOIP isn't everywhere? Good!

[Viol8]

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.

Re:VOIP isn't everywhere? Good!

[joshio]

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.

HTTP(S)? Marketing/profitability & IPv4

[GiMP]

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.

Business email

[freedumb2000]

In the case of email I am not using encryption because none of my business contacts are. It is kind of like with MS Word. I would love to use something different and I never mail out doc files, only PDF, but if everyone else is doing it's hard to stand your ground.

Talking out loud ...

[daveywest]

How often do you speak out loud in a public place?

None of that is encrypted. Someone might overhear you. Break out the tin foil hats!!!!

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.

Because encryption is a bigger problem

[samjam]

Encryption is a big problem to handle.

You are more likely to lose your keys than your privacy; there's just so many ways to get it wrong, even on the lowly USB memory stick, and end up losing your own data.

Solutions Exist - But some oxes may get gored

[wevets]

Having worked in a company that makes Ethernet adapters that implements IPsec offload, I can tell you EXACTLY what's holding up encryption across the network: Cisco and possibly a few other network hardware vendors. The problem is that they can't see into encrypted traffic, and they want to "own the network". If they can't see into the traffic for deep packet inspection, route optimization, traffic steering, etc. all their fancy hardware becomes pretty neigh useless. And encrypted traffic cannot be viewed by "lumps in the network". And these "lump makers" are, unfortunately, influential enough to make commercial implementation difficult by others. In fact, the best, most effective encryption is done as high up the stack as possible so as to protect the traffic from as many lower layers as possible. And, if you study the problem carefully, you'll see that you actually need encryption at several layers to properly protect the entire attack surface. But you either have to do this cleverly with existing protocols - possibly getting into vendor-specific solutions that would need to be standardized, - or create new protocols. Just applying SSL/TLS to everything is not the answer. As I said, solutions exist even at some large companies that could bring them to market inspite of Cisco. But to bring them to market, there needs to be some market pull from the user community for effective cross-network encryption, which, so far, does not exist.

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.

Headache for diagnostic tests

[neapolitan]

I'm surprised nobody brought up -- needless encryption makes a *huge* headache for running diagnostics on any sort of server. If any sort of script is not working, there is difficulty in evaluating what is happening, and even network diagnostics is much more complicated.

Additionally, encryption wastes a lot of CPU cycles if not needed. Although a small argument, this slows down networks and costs $$$ by burning fuel.

Finally, you have to make sure encryption is done right to be secure. If you encrypt everything, it is more difficult to see where there might be a vulnerability because there is more to audit. Think of the analoy to personal encryption -- unless you work for the NSA or something it is much better / easier to encrypt a directory on your disk with personal stuff than trying to encrypt your whole logical volume.

Which would be easier to recover from if you had a hardware fault / disaster?

I can only answer for myself

[obarthelemy]

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

Encryption is too hard

[DrXym]

Email has traditionally been ignored because obtaining a S/MIME key cost money, the keys expired too quickly, encryption was slow and bloated the message, and the crypto experience in most email clients was positively user hostile. PGP / GPG solves some of the issues (hooray we don't have to pay $$$ to a CA for worthless trust and an expiring cert) but integration in email apps relies on plugins (e.g. Enigmail).

Put simply encrypting content is just too much effort for most people. I've only ever had dealings with one company that preferred to use crypto. No one else cares.

The only way crypto is going to see wider adoption is if its turned on by default and virtually a no-brainer to use. It has to be virtually transparent. I think it's well past the point of ever happening, although it might gain some traction if a major mail provider such as Google issued all users with a keypair, made it the default to sign outgoing messages.

The question is why Google or any other provider would bother to do that.

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.

FTP would be dead

[randallman]

FTP would be dead if Microsoft would adopt the SSH suite, since SSH has the exact same capabilities as FTP. SSH is the swiss army knife of encrypted networking. Port tunneling is very useful. Less known, but also very nice is the ability to use pipes like this:

echo "hello" | ssh remote_host "cat > hello.txt"

You could use it to make a large backup without consuming disk space on the local machine.

tar -zc directory_to_backup | ssh remote_host "cat > backup.tar.gz"

It also works very well with rsync. Combine with hard links for a great backup strategy.

I like to see the surprise from Microsoft centric developers when they discover what SSH can do. They seem to all have this false assumption that it's just for getting a shell on a remote UNIX system.

Though I haven't kept up with SSH development on Windows, two applications I've used on Windows are: WinSCP and PUTTY sshwindows also looks interesting as I use cygwin + SSH

VS Electronic-Arts

[phorm]

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

Re:VS Electronic-Arts

[Golddess]

Reminds me of some experiences with TigerDirect. I'd thought I'd forgotten my password, so I'd gone through the password reset process or whatever they had (it's been a few years). They sent me my password via email in plain text, and it was the exact same password I'd been trying. I tried it again anyway, and it still didn't work. I then tried explaining to them that that password did not work, but they refused to believe me and just continually sent me the same password, in plain text, over email, over and over again until I just gave up.

managers

[Tom]

You asked a simple question, you deserve a simple answer: Managers.

Over my years in IT, I have seen too many decisions being made by people who haven't updated their IT knowledge for 10 years or so. People who think that "FTP" doesn't stand for "Fuck This Protocol" and to whom SSH is "this new encrypted remote login tool". In addition, crypto is inherently difficult to understand, and a lot (I can't emphasize that enough) managers simply don't support anything they don't understand.

Cisco had the right idea of VPNs and making the whole encryption "thingy" become invisible. Unfortunately, that too required some managers to make decisions.

The only places I've ever seen where encryption is used a) consistently and b) well is where someone very high up understood at least enough about the issue to roll out a general policy or put a security officer in place and gave him authority over such decisions. And then proceeded to fire at least one high-ranking middle-management idiot for violating the policy.

ssh tunnels / port forwarding / sshfs

[cenc]

I keep hearing everyone bitch about how hard it is to do wide scale encryption with so many user computers to configure, but I have found things like ssh port forwarding between offices to be an incredibly easy and secure solution to much of my encryption needs. Yea, it does not solve all the problems, but it is sure makes life as a systems admin much easier than trying to keep track of all the various possible protocols and their potential faults. It is possible to just about encrypt anything with a high level of transparency to the end user.

Encryption Ensmyption

[wtbname]

I'd settle for my damn financial sites not forcing me to arbitrary length limited passwords with only alpha numeric characters.

SPECIAL CHARACTERS and spaces ARE VALID PASSWORD CHARACTERS. STOP LIMITING MY CHOICE IN PASSWORDS.

If I want to set my password to

"*?@> $}}% v ^{@:># >>@@* &&^% £ÜÄ-AbN-

Your site needs to accept that.

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:Thoughts on Email and DNSSEC

[vanyel]

Actually, when I came here, I convinced everyone that we *should* be signing our mail and got everyone thawte certs. thawte's process for that was so painful that no one wanted to go through renewal a year later. Despite being a target of phishing scams, the practicalities of role based email mean that inertia is *still*, many years later, impeding routine use.

SSL/TLS is solving the wrong problem for most uses

[Lazy Jones]

SSL and predecessory try to prevent forged messages in addition to providing encrypted communication, adding the unacceptable overhead of handling a key infrastructure, purchasing certificates etc. where for most uses encrypted communication alone would be sufficient and could be achieved in a much simpler, cheaper way (especially when authentication is achieved with passwords anyway). So we're not encrypting traffic and not preventing eavesdropping because preventing forged messages is too hard/costly - congratulations! On the other hand, one should consider the implications of the false sense of security for the layman with only encrypted traffic - which is similar to what we have now with SSL being broken (MD5 etc.)

Re:wetware

[HarryatRock]

The problem is not data leaving the network, it's data leaving the company. Bar eliminating the user or chaining him to the desk, if anyone who knows, or can get to know (i.e. internal access) something valuable, then it can be stolen, even if he/she has to memorize it.

False sense of security

[Sloppy]

using a self-signed cert is barely better than using plaintext.

I'm going to argue that it's potentially worse, because it gives a false sense of security.

If someone is sufficiently ignorant (I just mean non-geeky; I'm not trying to insult anyone) that they get a false sense of security, don't you think they're also going to be ignorant enough to send sensitive info in plaintext?

Think about anti-virus. We say, "Pay attention to your security!" They say, "Ok, I'll buy some anti-virus!" And then they go right back to watching porn on IE and downloading BonziBuddy.

Take away the AV software which gives them a false sense of security, and I think they'll still watch porn and download BonziBuddy.

Server Name Indication

[Kaseijin]

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.

This is effectively true, but it gives the impression that the problem is inherent to the protocol. The main obstacle to secure name-based virtual hosting is that Microsoft won't implement Server Name Indication for Windows XP.

Re:What's the purpose of encryption if it's defeat

[jonaskoelker]

Do you lock your house? Does it have windows?

Will the police catch people who read my mail as it's travelling around some foreign mail servers?

Is it possible to secure as well against breaking and entering as it is to secure against eavesdropping? Is it feasible?

Bad analogy. The trade-off equations are vastly different for securing houses vs. securing information.

Say you wanted to practice your breaking and entering skills. Would you practice picking one of your own locks, or would you demand your neighbours not lock their doors?

I assume you're a nice person who respects their neighbours' wishes. I assume you can extend that nice respect and not insist on picking your neighbours' electronic locks, or on them being unlocked.

If not, why not?