What's Holding Back Encryption? 660
nine-times writes "After many years in IT, I've been surprised to notice how much of my traffic is still unencrypted. A lot of businesses that I interact with (both business and personal) are still using unencrypted FTP, and very few people use any kind of encryption for email. Most websites are still using unencrypted HTTP. DNSSEC seems to be picking up some steam, but still doesn't seem to be widely used. I would have thought there would be a concerted effort to move toward encryption for the sake of security, but it doesn't seem to be happening.
I wanted to ask the Slashdot community, what do you think the hold up is? Are the existing protocols somehow not good enough? Are the protocols fine, but not supported well enough in software? Is it too complicated to manage the various encryption protocols and keys? Is it ignorance or apathy on the part of the IT community, and that we've failed to demand it from our vendors?"
Nothing (Score:1, Interesting)
Most websites are using unencrypted http for sending non-secure public pages and most people don't use email for secure transmissions and consider it almost public.
The fact that everything is not encrypted does not indicate that anything is being held back.
Encryption has transmission and management costs. It is not "free" so it will never be ubiquitous.
I'll tell you what it is... (Score:5, Interesting)
...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.
VOIP isn't everywhere? Good! (Score:4, Interesting)
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:Self-signed is no good. (Score:5, Interesting)
HTTP(S)? Marketing/profitability & IPv4 (Score:5, Interesting)
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.
Solutions Exist - But some oxes may get gored (Score:2, Interesting)
I can only answer for myself (Score:5, Interesting)
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...
Re:Costs? (Score:2, Interesting)
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? (Score:1, Interesting)
Also, enterprises are not monolothic. Let's say you are in some large organization. Let's say that you have historically received data over an insecure channel. Let's say you want to move that to using something with better security controls. You have to get the czars of the DMZ to accommodate your new request --- this raises all manner of red flag and questions about whether this "new" something is secure enough and it takes reams of paper, many many e-mail messages, multiple meetings spread over six months to get the new thing scheduled to be installed in the DMZ. After about 8 months you have a system to test in the DMZ. Figure another 4 for testing, fixing and above all DOCUMENTING. So to replace the old insecure channel with a new one requires a year of horsing around. Everybody wants the same end point: secure data transfer. Nobody wants to be the one who gave the ok to a system which might turn out to have been insecure so there are many rounds of "mother may I?" to be played.
And after that year of gyrations to get your DMZ recipient set up, guess what you now get to spend a few months convincing all the people pouring data into the "send" side of the equation that this is secure. This couples with the fact that the persons who set up the original are now employed elsewhere -- and there is no "institutional memory" about the system. So now you suggest going to the new system and it triggers a review of the old one (yuk!).
In response to the parent: I think it's less about *people* wanting to keep the status quo than it is about inertia. To overcome inertia requires organized efforts; organized efforts generate very high entropy (expensive).
Re:People don't see the value (Score:1, Interesting)
'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.'
That will never happen and it doesn't need to. What needs to happen is a non-profit browser recognized CA that issues domain wildcard certs to the technical contact e-mail address. Then people will use encryption for the web.
There is no point in establishing identity beyond this standard. This demonstrates control of the domain, and if you have control of the domain you can compromise the experience for the user anyway.
Re:Costs? (Score:3, Interesting)
That's not email encryption. That's network encryption. S/MIME, which BlackBerry and Windows Mobile support, is email encryption.
VS Electronic-Arts (Score:3, Interesting)
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:Costs? (Score:3, Interesting)
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:VS Electronic-Arts (Score:3, Interesting)
Re:encryption alone (Score:2, Interesting)
Re:encryption alone (Score:4, Interesting)
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:Self-signed is no good. (Score:3, Interesting)
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. (Score:3, Interesting)
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:encryption alone (Score:3, Interesting)
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.