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

[leuk_he]

Yes it is, but key management and trust is part of the solution and not very simple. You need some kind of authority to centrally manage the keys. improper key management will only give a false sense of security.

PS "Yes but" is the same as "no unless"

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

[jwinster]

I agree with this. There are many more attack vectors that have far higher rates of success, primarily social engineering on people who have ALL the unencrypted information sitting right in front of them, than trying to map out a network topology, find the unencrypted point, and get the information you want. Also, it's cheaper to train people

Re:encryption alone

[Anonymous Coward]

is not the whole solution.

Sure, it'd help... It'd be another layer of protection. Another bit of security theater.

FTFY. As long as the user remains the weakest link, most additional security measures are nothing but theater. I dont care if your security is a safe, buried 50 feet down in a random desert. If you write down the location, tell someone the code, etc... it is only security based on the apathy of the attacker.

Re:encryption alone

[OldSoldier]

One thing and an observation.
Thing) a good SSL Cert (and accompanying support code) that allows for encryption w/o necessarily ensuring authenticity. We use self-signed certs for https: connections to a web-available database in our office and it's disconcerting to most first-time users to see all the warnings against "confirming that exception".

Observation) I'm still STUNNED that password encryption policies are not part of "privacy statements" on the web. I tend to use "secure" and "insecure" passwords. I was stunned recently when I went into a Sprint office to update my cell phone account and ... long story short... the clerk asked me if I knew my account password (I didn't). He then asked for my name and looked it up and... get this... told me what my password was!!! un-fucking-believable. Turns out I did set it (I recognized the pw as being one if mine).

Re:encryption alone

[Nursie]

SSL without authentication is inadequate.

They *should* get all sorts of warnings in the browser because anyone could be MITM attacking the session in a variety of ways. 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.

People use the net for all sorts these days, banking included. The last thing we want is to get the less tech-savvy individuals used to accepting untrusted certificates.

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

[interploy]

Too bad you can't fix stupid.

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

[Korin43]

I think the main problem with encryption is the need for certificates. Why not make all traffic encrypted and then use certificates when you want to be "extra sure"? I know, I know, "OMG WITHOUT CERTIFICATES WHAT'S THE POINT?!!?", but 90% of websites don't use SSL at all, so you obviously trust them well enough now..

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]

Too bad you can't fix stupid.

Well... You can't fix stupid with technology. At least not yet.

No amount of software or hardware will protect you from stupidity. But good training can fix stupidity.

Re:encryption alone

[Korin43]

I agree that in most cases it's not a big deal whether a website is encrypted or not, but the question is why there is so much encrypted traffic still, and the reason is that it's not trivial. If encrypted "might be nice", it's probably not worth it. Buying a certificate is only worth it if you have to. Because of that, banks and shopping websites are pretty much the only ones who use SSL.

Re:encryption alone

[jarocho]

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 in order to realistically take the confidential info with him/her. 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.

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

[bitslinger_42]

Since I work in corporate computer security, I was going to post from that perspective, but then I decided to do the other side. Where I work, all employees have to sign one of those "everything I create at work belongs to the company" agreements. Combine that agreement with doing work on my personal computer at home. What happens if I come up with something cool, salable, and completely not related to my day job, but all that work was done on a machine that I also use in conjunction with my day job? What's to prevent my employer's lawyers from laying claim to my new product? After all, if I came up with any part of that product during a timeframe where I was also logged into work, they could reasonably claim that the private-time innovations were influenced by the simultaneous company-time activities. It would also be very difficult for me to prove the inverse (i.e. that there was no absolutely relationship between the two activities that were occurring at the same time on the same computer).

Beyond that, I don't trust my company to not do stupid things that would break my home computer (i.e. try to force out a patch or force-install the corporate antivirus software), search my home computer looking for content or software that's not approved for the work environment, use my private activities done on my own time with my own resources against me when it comes time for promotions, raises, insurance, etc.

In the end, I look at it this way: either me working from home is important to the company, in which case, it's the company's responsibility to provide the equipment/connectivity to do the job, or it isn't, in which case they can go fsck themselves when they ask me to work from home on my personal computer.

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

[ShieldW0lf]

Isn't encryption the antithesis of openness? How can you have security without openness?

Perhaps it's that encryption is a tool used to maintain control and keep us in the uninformed and insecure state that we are currently in, only the people attempting to maintain control by rolling out these mechanisms are unable to keep up. As efforts to maintain secrets fail with greater frequency, we become more secure.

Wikileaks is a tool for increasing security. Encryption is a tool to prevent that from happening. It has no place in a secure society, only in a broken society that is engaged in ongoing destructive internal conflict.

Re:encryption alone

[NotBorg]

But accounts still get compromised left and right.

More accurately, the Windows machines of users with Blizzard accounts are compromised left and right as a means to compromise a Blizzard account. The system gets compromised and then phones home with account credentials as users log in. Blizzard combats this with a key chain authenticator. Doesn't stop the machine from being infected but insures that when the user name/password makes it to the wrong hands it is not useful because the attackers don't have the 3rd login credential (which is time sensitive and cryptographically generated by a separate physical device).

Re:encryption alone

[BlueParrot]

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.

It can get you pretty damn far if you do what Swedish banks do and use one of these:

http://www.swedbanksjuharad.se/bildarkivet/motiv/7131/Webb_Liten.jpg

You get one of those from your bank ( you have to pick it up in person ), use it to encrypt your PIN before even typing it into your computer, then you use it to sign any account and transaction details you send them, including the receiving account number as well as the amount of money to send. The little device itself has no means of exchanging information with the rest of teh world except the LCD window and the number keys. You literally perform the encryption "manually" as far as the computer is concerned. Ok, it's not perfect in the sense that if your computer gets owned they can eavesdrop on your sessions and get information about your transactions, but at least they won't be able to withdraw any cash.

My main point about this is that security is not a black or white thing, and encrypting transactions can dramatically reduce the number of possible attacks available. That it may be possible to get personal information about me if they own my computer is not quite the same as being able to withdraw all my savings if the bank used a software implementation.

Re:encryption alone

[Ephemeriis]

But accounts still get compromised left and right.

More accurately, the Windows machines of users with Blizzard accounts are compromised left and right as a means to compromise a Blizzard account. The system gets compromised and then phones home with account credentials as users log in.

Sometimes.

There are also frequent cases of an account being shared and one of the "trusted" individuals not being so trustworthy. I've seen it happen more than once myself.

Blizzard combats this with a key chain authenticator. Doesn't stop the machine from being infected but insures that when the user name/password makes it to the wrong hands it is not useful because the attackers don't have the 3rd login credential (which is time sensitive and cryptographically generated by a separate physical device).

The authenticator only adds security if the account belongs to a single user. If multiple people are using the account, intentionally, then they'll be sharing the authenticator as well. Yes, I realize this would mean they'd need physical access to the authenticator. But if one of them decides to sell all the lewtz for money, the authenticator isn't going to stop that.

Nor is an authenticator going to prevent somebody with appropriate access from emptying out a guild's vaults.

Re:encryption alone

[lgw]

Finally, some sense.

To put his simply: in a corporate environment, security is the ratio of difficulty of authorized to unauthorized access. Anything that makes it harder for an authorized user to use the system reduces the effective security, because peopl eneed to do their joba and will invent work-arounds as necessary.

This isn't merely true of electronic security either. Many's the "secure" building with a door propped open somewhere so that the smokers can go outside or a bit without the hassle.

Re:encryption alone

[jarocho]

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.

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.

Whether you want to acknowledge it or not, in many, many cases and environments, the weakest link is absolutely the sysadmin, who throws up his hands in the midst of his end-users, and does nothing. Rather than the end-users themselves, the vast majority of whom are more likely to click on a random executable than to want to sell the secret formula of New Coke to the highest bidder.

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

I couldn't disagree with you more. Most of the point of IT security is to make it harder for anyone to exploit the user, that user included... so hard that it isn't worth the effort.

If the sysadmin fails to implement counter-measures, it's he who is the weakest link. Because whatever its true effectiveness is, there's ALWAYS a counter-measure. I can think of an industry-standard counter to every single scenario you and others have alluded to here; you had to downshift into a pretty specific hypothetical about someone who willfully chooses to leak data, in order to support your original assertion. It doesn't make it any less misguided to let the sysadmin asleep in the corner off the hook.

Feel free to give yourself the last word here.

Re:encryption alone

[Anonymous Coward]

Well, if you can't trust the people you live with you should quit WoW and fix that first. Seriously you're risking much more than just a game if you can't trust the people around to not act maliciously.

The acts you describe are not accidental they are malicious. and they are people you live with? No software will fix that. Get your kids in line, get new roommates, and/or find another wife/husband/gf/bf. Has nothing to do with WoW other than it being a tool to abuse you.

I realize it's a game and thus not really that significant, but remove WoW and see what the abuse shifts to.

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

[hawkinspeter]

Have a look at http://sublimation.org/scponly/wiki/index.php/Main_Page for providing sftp sessions in a restricted shell.

Re:encryption alone

[Afell001]

To be honest, anyone working at home doing anything other than an RDP session to their local box at work needs to negotiate on good terms with their employer for compensation. Figure out what percentage of internet traffic is work related vs. personal, and how much overall use of the equipment will be dedicated to work vs. personal and divide that by the total value of that machine, depreciate that over the length of time you reasonably expect to own that computer (i.e., 3 years) and present that figure to your management. As long as you don't pad it too much, I'm sure that management will most likely be willing to compensate you for use of your personal equipment if they expect to have work-for-hire rights to anything you create with that equipment. If they argue with you regarding the need to do this, you can always bring up the fact that many companies will reimburse employees who use their personally owned vehicles to perform company tasks, such as delivery people or on-the-road salespeople. This is, in essence, no different. If they still continue to argue, then you have every right to refuse to work from home until such time as you are either provided with the equipment and internet connect with which to work or they are willing to provide you with compensation for the use of your personal equipment and connections. All said and done, it should come out to be about $45 to $50 a month. Not much, but you can use that to defray the cost of your internet.

Re:encryption alone

[Hognoxious]

Nope. Training fixes ignorance.

Re:encryption alone

[shmlco]

"If you make the age requirement too short, then nobody can remember their passwords. So they start working around it...."

One company I know of had an employee send around a "helpful" email saying pick a password, then just add the month/year to it. As in "password 01/10". Solves the special character and number requirements too. Next month when it expires use the same password and just bump the month.

Got back a ton of "great idea" responses. So now everyone is using xxxx mm/yy formatted passwords... and everyone there knows it.

Re:encryption alone

[Hognoxious]

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

There is also a point after which you get diminishing returns, and in fact may make your security worse.
[...]
Complexity requirements are good up to a point

Some part of "appropriate" giving you trouble?

Re:encryption alone

[TerranFury]

Thank you. I have seen scponly though. What I dislike about it is summarized by this quote from its installation page:

installing scponly with chroot could incur some pretty hairy troubleshooting. The binaries and libraries must be set up properly in the chroot subdirectories properly.

-- from here

It seems to me (though I wouldn't mind if I were wrong) that this is essentially just a way to do #2 in my list (prev. post) for versions of sshd that do not support restricting the commands that users can execute, or built-in chrooting. So, haven't new versions of sshd made scponly unnecessary?

FYI, #1 in my list was referring to this approach (found URL since last post). This does not actually use a chroot; it just makes sshd-server behave as though it were in one by modifying the way it handles file paths. I don't know how it plays with symlinks.

Re:encryption alone

[hclewk]

If Joe User cannot create a password that has less than 12 characters, then the Sysadmin *established* (with an 'e' on the front) a policy that is being *enforced*. He doesn't just go around to each employee and teach them what kind of passwords they should make, he tells the system what kind of passwords will be accepted and how often they expire.

Re:encryption alone

[hawkinspeter]

I wasn't aware that new versions of sshd allowed you to restrict what commands are allowed; that sounds like it would make scponly obsolete.

I've used chroot'ed scponly to only allow sftp (and scp) to servers - it's not that tricky, but you end up copying the binaries into each home directory. Works a treat.

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

[Dinatius]

Encryption is separate from authentication. As it stands right now quite a few people assume they are the same thing. Encryption ensures that once you and whatever it is are talking to each other that session is private and only the two of you can understand what is being passed back and forth. Ensuring that your talking to the right person before starting the session is not the job of the encryption.

I understand that this view is wide open for man in the middle attacks but tying encryption and authentication together has been a big mistake. It is a convenient way to authenticate a server or a client and that is why it was implemented this way and continues to be implemented this way. A authentication handshake could easily be performed over and already encrypted session and verify the server for who it is.

Re:encryption alone

[DigiShaman]

Your company is doing it wrong.

If they want to isolate sensitive data, it needs to be on its own internet network. The only access to it is from stand-alone workstations or via terminal sessions. E-mail, web access, IM, etc are done through another network and separate computers connected to it. This way, all sensitive data access can be logged. If you must take a copy of the data outside the building, printing a hard copy is the only way. Oh, and it must be signed by management prior to walking out the door with it.

This can be done without question. It's all a matter of how much time and money they want to throw against it. There is no reason to be quivering over the little shit and spinning in circles over it.

Re:encryption alone

[Nursie]

I don't disagree, but secure auth is what the (usually) RSA exchange at the beginning of an SSL session is for. I'm not sure I see the difference between that and your proposal.

Re:encryption alone

[Nursie]

Woops, didn't think of that!

I only deal with SSL/TLS on the web as a consumer. As a coder I deal with in-house non web setups where you trust your CA completely and don't use any others, or any other services.

You're right, that would be a bad plan.

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

[hclewk]

You apparently don't pull as much weight with your company as I do with mine. A fact that is likely due, in part, to not following (e)stablished spelling practices.

Re:encryption alone

[bigstrat2003]

If you really think that all companies are populated with rational managers who will be convinced by their IT staff's reasons, rather than just listen to "I don't want my damn password to be 12 characters long", you are blissfully ignorant, my friend. I hope for your sake your luck holds out, but don't kid yourself that management listening to IT's advice depends wholly on the quality of the IT department.

Re:encryption alone

[Anonymous Coward]

How can you have security without openness?

The same way I can have a barbecue without pancakes.

Re:encryption alone

[phtpht]

is not the whole solution.

How true. In transport crypto is almost futile nowadays (original SSH was deployed on coax ethernet networks where anybody could see your pw, today it's another story).

Authentication crypto has the burden of certificate management (do you verify fingerprints of each https site you visit?)

In the light of botnet compromises, crypto achieves precisely nothing (bot controlled agent can do/see exactly the same stuff as local user).

Consumer crypto has mixed success stories (see GSM and satellite TV smartcards).

Static data crypto (on-disk) brings key management hassle (crypt the daily backup, but backup the keys to a different place) and opens a field for legislative battles (i give my disk key to my lawyer).

Finally, crypto of any kind itself is hard to get done right and bad crypto is worse than no crypto (Debian openssl epic fail). It requires powerful hardware. And of course, some enlightenment of the staff, tighter procedures, etc.

So crypto deployment is always to be weighed against these (and other) downsides.

Re:encryption alone

[svirre]

Usually management will listen to ITs concerns considering them the experts on the matter.
More often than not though IT's security policies are actually reducing security:
Complex rules on the password complexity actually reduces the number of effective bits in the password and can also make a password very difficult to remember, which prompts the user to write it down.
Very short expirations on passwords particularly combined with complex compositioning rules leaves the user unable to learn the password for a long time, increasing the passwords exposure through written notes.
Whenever there is a security scare IT generally tightens one or both of these screws, which might actually decrease security. Management as i said usually takes ITs advice in security matters. However security would be better left to people who are experts in human behavior rather than technologists.

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.

Re:encryption alone

[muckracer]

> The last thing we want is to get the less tech-savvy individuals
> used to accepting untrusted certificates.

They are already used to it. NEXT?

Re:encryption alone

[muckracer]

> I don't, for instance, care about having slashdot encrypted at all.
> if someone steals the password or the cookie then so be it.

That's like....Bad Karma! :-)

Re:encryption alone

[muckracer]

> I don't, for instance, care about having slashdot encrypted at all.
> if someone steals the password or the cookie then so be it.

On a more serious note:

What if somebody uses your account to, say, post "I wanna blow up the
POTUS!!!"? Do you still not care, if the Secret Service rings your
doorbell and starts asking you very detailed questions?

Agent Smith: "The threatening message was posted yesterday at 22.34.
What were you doing at that time?"

Korin43: "Oh...well, I was on the computer. Reading stuff. Like
Slashdot. Uhh...yeah *gulp*"

Right. Even if you can clear yourself chances are you'll be watched
afterwards and you are definitely indefinitely in the USSS database
if nothing else.

Re:encryption alone

[bakker Bart]

Proper chrooting and SFTP with OpenSSH should be done like this in sshd_config:

Subsystem sftp internal-sftp

Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no

Then it's just a matter of adding accounts to the 'sftponly' group. Works like a charm in OpenSSH 5.3, may work in some earlier versions but it's a fairly recent feature.

Re:encryption alone

[higuita]

*COOF* NSA *COOF*? ;)

Re:encryption alone

[rainsford]

And yet I can still think of several ways to get information out of that office, including obvious things like memorizing information, copying it (by hand) onto paper you brought into the office yourself, and printing secret things with normal looking first pages.

Technology is never the solution to the problem of insiders. It might make it HARDER to steal information, but honestly, you can't run a business with non-trusted insiders. Technology has a place keeping people inside the company from information they shouldn't have (like keep engineers out of HR records), but preventing people from stealing information they need access to in order to do their jobs? Forget about it...

Re:encryption alone

[Anonymous Coward]

FTP is a very efficient file transfer mechanism. It has a few common scenarios, such as distribution via anonymous FTP. This results in performance benefits over HTTP for low numbers of bulk file transfers. If you are using a username and password, the information is probably non-sensitive and the username is mainly for some kind of tracking metrics on the server. Another possibility is that the device is an embedded device and is never meant to be on the Internet at large (e.g. on a protected control network). Only recent technology advances have provided embedded devices a viable include encryption capability, and it is slowly rolling out.
As to HTTP, the bulk of that information is non-sensitive. Most of the business Internet HTTP access can be described as marketing and sales. You do not want to exclude people from that information. When something needs to be more secure, then HTTPS is used. Note that HTTPS does not inherently solve the security problem. It merely makes eavesdropping harder. Security at the end points themselves is still important. If it is not self-signed, then a third party needs to be compromised to go undetected. On the other hand, it assumes an attentive and security-aware user to know what is going on there.
For DNSSEC, it is really a horrible idea. To work, you need to get everyone who runs DNS to communicate to trade keys with the upper level server. This assumes that you are doing zone signing. This is work on two different organizations. This must be repeated pair-wise across the globe up to the root servers. Every update means a new signing and there should be a periodic change to the key, also. If you want to have individual records signed and verified, then you need every client on the Internet to cooperate. The amount of logistics required to do this quickly becomes fairly heavy considering that the information itself (the host name or IP address) is still not encrypted.
For encrypted Email to work, you will need to exchange keys with the recipient of your Email. The key exchange should not occur via Email. In a corporate environment, it is possible to assign all the required keys from a server. However, leaving that corporate network means that the keys must be exchanged. As to doing this with ease, WinZIP (for example) allows you to right click on any file or directory and select "Zip and Email Plus..." which allows a user to encrypt the ZIP file. There are dozens of similar tools. Today, such tools are more commonly used maliciously to bypass virus scanners. As such, many corporate Email servers strip such attachments. Signing Email would offer less security while being far easier to handle in most cases, but that requires the sender to register with a "well-known" certificate authority (for fee) or for the recipient to explicitly trust the certificate authority used. Both of these options require additional effort and cost and offer no significant security enhancement for non-sensitive Emails. The digital signing could be made obsolete by placing a phone call and asking talking about the Email contents. There is, however, significant movement on VoIP. Beyond the idea of simply creating an encrypted tunnel for the data, there is work being done to encrypt the calls being made.
The reality is that encryption is as complicated as it needs to be to get the job done. With the new two-factor authentication requirements from the payment card industry (PCI) starting to appear, things may improve. Perhaps we will see PKI certificates tied to your ATM or credit card for those transactions. We are already seeing laptops with card readers and/or fingerprint scanners built-in. We are also seeing whole hard drive encryption in software and also offered on hard drives themselves. Ultimately, however, security must strike a balance. If I laden technology with too much encryption, it is hard to configure and use and will cost more. Your microwave (I presume non-networked) really does not need to encrypt its database of power settings for the button presets with a user provided key.

Re:encryption alone

[Mista2]

Similar, but for a free country, not the USA 8)

Re:encryption alone

[Mista2]

Most of this I actually thought of as "Security Theater" Make people think they are being monitored and it stops the casual or accidental leak of information. Nothing to stop a "Trusted" employee signing out a document and walking away with it though.

Re:encryption alone

[turbidostato]

"If you really think that all companies are populated with rational managers who will be convinced by their IT staff's reasons, rather than just listen to "I don't want my damn password to be 12 characters long", you are blissfully ignorant, my friend."

That's not the point. The point is that even if your manager listens to your explanations and even if he's convinced by them it still will be the manager the one that will establish the policy, not the technician, even if the policy ends up being "do as you suggest".

Re:encryption alone

[Ungrounded Lightning]

Where I work, all employees have to sign one of those "everything I create at work belongs to the company" agreements. Combine that agreement with doing work on my personal computer at home. What happens if I come up with something cool, salable, and completely not related to my day job, but all that work was done on a machine that I also use in conjunction with my day job? What's to prevent my employer's lawyers from laying claim to my new product?

If it's your computer, the work was not done on company time, and your employment is under Californina law, what will prevent them from laying claim is California IP law. B-)

Consult a lawyer if you're working in other states. (Heck: Consult one even if you're working in CA for a CA company. After all, IANAL and even if I were I'm not YOUR lawyer.)

Re:encryption alone

[jwhitener]

Most businesses that store sensitive information are well aware that it is impossible to absolutely guarantee that the data is safe. That is why the smart ones implement massive auditing.

A hospital I used to work for was like that. If a celebrity was admitted to the hospital, everyone knew that you'd get caught in seconds if you looked at their medical record.

Each keystroke, date time, screens accessed. Sure, the information might get out, but the blame isn't going to be on the system admin, or the hospital, which is 99% of what the institution cares about.

For an industry that absolutely must not let information get out, there are ways of doing it, but those methods are so extreme and expensive that they are not usually implemented anywhere except military/military contractors.

Re:encryption alone

[codematic]

I agree, contracts that state "everything i create belongs to them" or some such general terms, are not binding. The courts will notice immediately that your company cannot claim your child, which you also could create while in their employ. This also includes self built additions to your house, birdhouses, shelves, etc. The contract is invalid because its applicability is in question.

Re:encryption alone

[Creepy]

Corporate does all the things you say. We were purchased and they want us to migrate to their policies and security, which includes per-machine keycard login, which really doesn't work well for teams like QA since it also forbids remote desktop and breaks all of our VMs (which are headless in a lab). I heard several million and 12 man-years of labor would be needed to get us to get the level of security they want, which isn't happening soon.

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?

[McNihil]

Reading confidential corporate emails in plain text where it is not supposed to be is not incentive enough?

and

IMHO Anyone still using FTP for material that isn't completely open nor "in-"sensitive should get a corporate slap on their foreheads and rightfully be labeled idiots.

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?

[Anonymous Coward]

Don't forget that encryption can be done on the conents of a transmission.

So this means the contents of an email could be encypted.

So a special protocol is not really required. As long as you can SEND DATA. It can SENT be in any format - encypted or plain text - up to you!

Also the only true security is using the quantum method, where you can transmit a key and if this transmission is being snooped you can tell and change they key (or use another comms channel).

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?

[Anonymous Coward]

So long as Van Eck stuff isn't part of your threat model, you're probably alright - and if it is, there are probably other unaddressed vulnerabilities.

My only concern would be that your "defense in depth" is not as deep as it might be.

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?

[emilper]

I think leaving TPS reports and most of the memos in plain text is the best strategy to befuddle the competition.

The biggest threat is the inside man, not the "man in the middle".

Re:Costs?

[rainmayun]

just FYI, from the wikipedia article:

"S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of e-mail encapsulated in MIME."

http://en.wikipedia.org/wiki/S/MIME

Re:Costs?

[Bert64]

I don't think many other phones can do encrypted email out of the box either, tho third party apps are available for some.

Nobody cares, large companies, even companies working in the security market don't use encrypted email and often don't even understand how to use it... Then you have mail setups which stamp disclaimers or signatures on mail (thus breaking signatures), not to mention exchange that likes to create an html counterpart to your (encrypted) plaintext mail, thus breaking PGP completely...

Re:Costs?

[zn0k]

(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?)

It does IMAP over SSL, POP3 over SSL, SMTP over SSL and ActiveSync over SSL. What else do you need it to do?

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?

[pixelpusher220]

my aged Treo 700p with default browser Palm Blazer v4.5 seems to handle my https webmail 'out of the box'.

Granted the rendering of the page sucks donkey balls, but I can definitely connect and read email.

Re:Costs?

[Anonymous Coward]

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

[Anonymous Coward]

You don't know what you are talking about.

Re:Costs?

[XanC]

That's a Web page, not email.

Re:Costs?

[Anonymous Coward]

Don't forget ass-backward company Microsoft - Outlook doesn't support OpenPGP, you need a plugin to be able to read and send PGP encrypted email. Combine this with the fact that although everybody has to follow a mandatory IT course in secondary school, people aren't educated at all about how the internet works and they won't see the benefit and won't install any plugin. The only way this will change, especially in the corporate world, is when Microsoft makes applying encryption the default in Outlook. But realistically that won't happen, because you'd have to ask the user to create a key, distribute the public key, and so on. Users will simply click "Cancel", probably even if the dialog pops up every single time you click "Send".

Re:Costs?

[TheRaven64]

What do you mean by 'same LAN segment'? Are you using a managed switch? If not, then I can flood your switch with MAC packets from outside that segment and fill up its CAM table. It will then broadcast all packets aimed for internal MAC addresses to all ports. I can then get copies of all of the data.

Alternatively, I can bribe one of your minimum-wage cleaning staff to plug a dongle into a network cable in the room (or outside, if the network cable goes out). With about $100 of off the shelf hardware (about the size of a matchbox), I can then record all of the network traffic until the dongle is removed or its memory is full (which may take a while, given the current price and physical size of 32GB of flash). Installing and removing the dongle would take around 10 seconds of access to the network socket.

Of course there are still ways of attacking your network if you do use encryption, but they're harder.

Re:Costs?

[Isao]

Windows Mobile, Blackberry.

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?

[Anonymous Coward]

Ha ha, WinTel. Cause most Linux boxes are not Intel, and Windows doesn't run on anything other than x86.

Oh wait.

Re:Costs?

[TheRaven64]

Depends on what you mean by encrypted mail. If you're talking S/MIME, then you're probably right. Most, however, can do IMAP and SMTP over TLS. For a corporate network, you can do the signing on the server for outgoing mail (after authenticating the SMTP connection) and verify S/MIME signatures for incoming mail before it hits the user's inbox.

Re:Costs?

[TheRaven64]

It's particularly strange, since Mail.app on OS X has supported S/MIME for ages (since 2003), so it's not like Apple doesn't have code sitting around for doing S/MIME that they can reuse.

Re:Costs?

[glebovitz]

All of my phones handle ssl or tls security for imap. Otherwise I couldn't use Google imap or my companies email.

Re:Costs?

[pixelpusher220]

doh!...fortunately for me the donkey balls that is the Treo 700p also does SSL for its native email client too ;-)

Re:Costs?

[Anonymous Coward]

I agree. Security is always a loss from the perspective of a company.

Re:Costs?

[tendrousbeastie]

I agree with this. About 25% of our customers have trouble using normal FTP, plus an awful lot of corporate firewalls have trouble with passive FTP (the random data connection port gets blocked).

There is no sensible payoff to me implementing SSL for our FTP transfers.

Re:Costs?

[XanC]

Well, okay, but that's not really what we're talking about either. That's encryption when the user goes to get his mail from his mailbox, which is all well and good, but the emails themselves are completely unencrypted as they go from server to server on the way to their final destination. It's that issue which is meant by "email encryption".

Re:Costs?

[jaavaaguru]

The iPhone can use SSL for email too. That's not mail encryption. S/MIME is. I doubt many people really care though. SSL is good enough for me.

Re:Costs?

[Lord Ender]

SSL is not email encryption. S/MIME and PGP are email encryption. All business-class smartphones can do S/MIME.

Re:Costs?

[uncqual]

Why would someone ever let a minimum wage cleaning staff member into their server room without a trusted escort monitoring them? I've worked at commercial companies where rooms far less important were only unlocked and cleaned under the watchful eye of a trusted security staff member -- isn't that standard practice at big companies?

(Of course, I've also worked at small startups where nothing but the exterior doors had locks and every so often those just didn't get locked at night -- perhaps the attitude was that the code was really the only valuable asset and it was so bad that it would take longer to figure it out and use it than to just implement it from scratch.)

Re:Costs?

[slim]

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.

This is the purpose of X.509 and LDAP. It requires trusting a central authority (or several), but if you're willing to do this, it works.

PGP's "Web of Trust" is another solution to this problem, in which your client can make decisions such as "Five of my friends trust this public key, so I will too".

Re:Costs?

[durdur]

There is some truth to this, but most B2B traffic is already secured - the technologies for this have existed for many years. The odds that someone lets external unauthenticated entities post invoices to their accounting system are pretty low. When they converted off paper/fax they likely put in EDI or some other established system. SOX has also made execs extra paranoid about traceability and non-repudiation. But if the traffic isn't business critical then it is harder to justify turning up the security level (as many other posters have noted) and harder to make it happen.

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.

Re:Costs?

[stewbacca]

The iPhone doesn't do secure email because not enough people want that feature, not because Apple can't do it, or because Apple thinks they know better than you or I (which is the expected response to this post).

Re:Costs?

[swillden]

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

Though you have to wonder if there's any point in sneaking your secure channel through, given that the endpoint you're connecting it to is so obviously insecure...

Re:Costs?

[Anonymous Coward]

hahahahahahahahaha

yeah, because as a pirate, i'm going to seal your unfinished books

tool.

Re:Costs?

[Lord Ender]

Every desktop email client from mutt to Outlook supports S/MIME. BlackBerry and Windows Mobile support S/MIME. The iPhone is the odd one out. This is just one of many reasons it's considered a toy by large enterprises.

Re:Costs?

[Bert64]

The iphone can do https webmail too, and the rendering probably works a lot better.
But that's not the point, its about what the dedicated email client can do.

Re:Costs?

[Bert64]

iphone does imap/smtp with tls too, my mail server requires tls and it works fine with iphones.

Re:Costs?

[Bert64]

You can encrypt from server to server too, i have postfix configured to negotiate TLS if possible, but 99% of mailservers that communicate with it don't try to negotiate TLS.

Re:Costs?

[Anonymous Coward]

(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?)

iPhone mail client supports secure email at least imap and pop with ssl/tls is working never checked smtp

Re:Costs?

[stewbacca]

This is also why it is marketed as a consumer device and not an enterprise one.

Re:Costs?

[blitzkrieg3]

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.

The problem with key exchange is that there is no central authority. Thinking about it in a TLS kind of way, every cert is a self signed cert.

Re:Costs?

[arminw]

....My publisher wants me to send things to them using FTP. I refused...

Mail (snail) the editor or whoever processes your file a CD with one or more passwords for the encrypted files you would be sending them over plain unencrypted FTP. You might also want to include the decryption software. Even relatively dumb users configure stuff like that out. Alternatively, you could probably give them the password over the telephone with reasonable safety. It's low tech, but it should work pretty well.

Re:Costs?

[shmlco]

"This is just one of many reasons it's considered a toy by large enterprises."

Yeah. And those new-fangled personal computers were once considered to be "just toys" by the IT department mainframe jocks.

Re:Costs?

[mrtwice99]

Well, at least for HTTP certs, the price is coming down considerably. The Planet has $15 certs: https://ssl.theplanet.com/ With 99% browser acceptance rate. I used to avoid SSL for my customers b/c of the cost. Now, I don't have any aversion to using them. The low cost certs are just as secure, but they lack some of the "frills" like badges for your site. For most of my customers and their user base, all that matters is the lock icon in the browser and no security warnings when the page loads.

Re:Costs?

[ArsenneLupin]

The Nokia E61i that I bought 2 years ago does SSL Imap out of the box. Probably nowadays all non-Microsoft and non-Apple smartphones can do it too.

Re:Costs?

[macintard]

Could not agree more. And often times, our "customers" are in house users who refuse to modify their own behaviors.

Re:Costs?

[Anonymous Coward]

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.

The lazy user or admin, like me, does not care enough to implement security because of the points you make about impractical stuff. On the one hand, Wireless networks have exploded since the creation of Etherpeg around the year 2000.

Yes, most of the networks are encrypted, in comparison to back then. No, you could still be sued for having an open access spot where you intentionally let people log in just to peek at their downloads so you could find some compromising sex photo that your neighbor downloaded from e-harmony or whatever. The funny part is that your neighbor wasn't counting on anyone so easily peeking at their pr0n and sifting through megs and megs of pr0n just to zoom into their one private slip-up. If they could somehow encrypt everything endpoint to endpoint while tunneling through your unencrypted open AP, they would --but that's mostly a hindsight decision for affected people.

You can assume that 'national security,' monetary risk to financial institutions and great moral scandals are behind all the laws that eventually force standards to be pushed. Eventually we lose freedoms --remember when windows accounts had Guest accounts enabled by default, and college networks gave their students naked IP addresses and no download quotas? Protection didn't matter back then, and scammers weren't as many as they are today. That was just 10 years ago.

Microsoft, with all their security failures, has a say on what's industry standard. They force you away from things they consider a problem. If you had a workaround for easing administrative tasks and they broke it via an update, you need to implement a fix for yourself --or potentially hundreds of clients that you used that productivity fix on.

Even if I agree that the current state of things in security is simpler, it doesn't mean that we are safe from SELECTIVE changes. MS, large banks and local governments force changes when they have enough internal accountants and local politicians demanding them. Security only comes second, but it does eventually come, selectively.

Re:Costs?

[TheRaven64]

Do you think that's a joke? PDFs were available on pirate sites for download before the paper copy hit the shelves, although (slightly) after the (DRM-free PDF) eBook version was released. Personally, I'd rather not give the pirates a better experience than my paying customers.

Re:Costs?

[Anonymous Coward]

Key management, while an important issue to consider, (as is creating a PKI for your organization) is not whats holding use of encryption back.

Email clients can already do that. Using Outlook combined with PGP desktop, one can automatically sync keys with the PGP keyserver, or an internal source. S/MIME keys are automatically exchanged when I send you an email. Contained inside the certificate w/ signature I just emailed you is the public key.

Re:Costs?

[wvmarle]

Besides that I have never heard of it, and have no idea whether it's widely implemented, there are plenty of pitfalls mentioned in that very wp article.

Oh and it doesn't solve my core issue: key exchange.

Re:Costs?

[wvmarle]

When the government really monitors you, they can afaik still see the links you are going to. Or does https also encrypt the url? No matter what they can still see which SERVER you connect to. So they can still see you are connecting to al-jazeera or whatever.

What you are talking about is far more than just encryption of traffic between you and the server you visit: this requires something like tor where you can hide which site you are actually trying to connect to. Which in itself would be a serious red flag for investigators: why using such a system, at high cost (slow connections, maintenance, etc) when you have nothing to hide?

And if your boss is mandating such high level monitoring of your internet use, then there are probably far more serious problems than accidentally running into something sexually explicit or so while trying to read /. at work.

Re:Costs?

[Anonymous Coward]

even companies working in the security market don't use encrypted email and often don't even understand how to use it...

Comodo is one of them. They want you to send various ID documents via unencrypted email and don't offer alternatives. I asked for a more secure method but they literally had no idea what I was talking about despite selling the product I was inquiring to use as a secure means of sending the documents. Fucking morons.

Re:Costs?

[Anonymous Coward]

That's the Network Layer you fucking idiot

Re:Costs?

[Dan541]

Fortunately, clueless admins tend to leave other holes in their security,.

Are you sure that's always to your benefit?

Re:Costs?

[Dan541]

Training everyone to exchange S/MIME keys, for example, is just too damn hard.

Many of us are still training people not to download the latest screen savers. Or install the latest cool app that someone was kind enough to email to them.

Re:Costs?

[Dan541]

Only terrorists and pedo's encrypt email, or do you not listen the government propaganda? Traitor!

But seriously iPhone lacking a common feature? Who would have thought.

Re:Costs?

[Anonymous Coward]

That's funny, my ipod touch does imaps and smtps connections.

Re:Costs?

[coofercat]

Keys-by-DNS (or similar) is pretty much where I think things need to go.

I've always wondered why we needed SSL-for-http, SSL-for-smtp and SSL-for-other_protocol. Why don't we just have a generic "ssh to someone" protocol which can forward the packets to the right service on the remote server (perhaps a sort of TCP-S protocol or something?). Of course, key management is really the problem.

Back to costs: Who's gonna spend the time (and money) trying to convince the world it needs keys-by-DNS when no one uses keys-by-DNS yet? It's probably worse than you might think because SSL's already been done, and the vast majority of normal people in the world don't need much more than that.

Re:Costs?

[jwhitener]

You might consider it if a new network guy screws up and you find out that your lan has been accessible to the world for 2 months without your knowledge......happened to me once, early in my career.

I now add as many different layers of protection as possible. More work, more things can go wrong, but much much safer.

Re:Costs?

[citrustech]

Agreed. Here in the UK the Information Commissioner has just received powers to fine up to £500,000 for data breaches: http://bit.ly/69Ufrz. I think that may help address financial incentive balance.

Re:Costs?

[Anonymous Coward]

Anyone who has access to one is trusted to have access on them all;

You're assuming that none of these accounts that are trusted have been compromised. In the security industry we call this the "Hard Candy Shell With a Soft Chewy Center". By assuming that anyone on your LAN is already trusted, and wouldn't possibly want to do something nefarious, you make it much easier for an attacker who does manage to get past your defenses. Once I'm in, I have unfettered access to EVERYTHING.

Why would we do that?

Ultimately security is a time/money tradeoff. If it will cost more to secure it than it would cost to lose it, there is no need to secure it. If It would cost more to lose it than to secure it, you secure it. For purposes of this conversation "cost" should include effort to do the securing... If you can add an additional hoop for a potential attacker to jump through, or make his job a little bit harder, you make the soft target down the road look much more appealing. There is a fallacy that important systems are well-protected, so they are attacked more often. This is not true. Most attackers these days (discounting targeted attacks with a specific purpose) are interested in compromising as many systems as possible so they can sell them as spambots/ddos zombies/etc. Much like a bully, if you put up a bit of a fight they will move on and find easier prey.

Re:Costs?

[JSlope]

ResoMail has automated key exchange, it's lot better than currently existing products and is completely transparent to end user.

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.

[OrangeCatholic]

I mostly agree with that, but I wouldn't mind read-only sites being encrypted as well. The way I see it, we're at a point now where all digital communications should be encrypted. Just how steep is the performance drop from HTTPS? 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?

The web was built largely because people made websites for others out of the kindness of their hearts. From that, it's not a big step to turn on https.

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.

[Anonymous Coward]

StartSSL is now providing free SSL certificates that actually work.

Re:Self-signed is no good.

[-noefordeg-]

That is so true.
Interesting thing with signed certificates, was that BBS (Norwegian: Bankenes Betalings Sentral) which is more or less the central point of all money transfers by credit/debit cards in Norway, is the one signing SSL certs for a lot of banks web pages in Norway. I would trust BBS far more than some signed cert from some unknown web certification authority, but... BBS signed certs would still show up in most browsers with "WARNING WARNING!!!"

What added security for any one person, does Tawte/Verizon provide?

For companies in Norway, I think a huge step would be to have Brønnøysund Register Centre issue certificates to every company or for EU, European Business Register.

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.

[Mr. Underbridge]

The way I see it, we're at a point now where all digital communications should be encrypted.

Whenever I hear somebody say "All X should be Y", I ask 'why'? The problem you have is inertia - if switching requires any kind of thought or effort, it's not going to get accepted by the general public. I don't want to dig up the old slashdot checkbox meme, but your idea won't work because it requires buy-in from people who don't care.

To the server, maybe.

You got it. Also, the first page somebody sees goes from a normal looking http web page to a "ZOMG this certificate can't be validated!" which will require additional clicks to accept the cert, and scare people who don't know what they're doing. Either way, there's absolutely no reason to add that to a simple web page.

The web was built largely because people made websites for others out of the kindness of their hearts. From that, it's not a big step to turn on https.

That internet hasn't existed for at least 15-20 years. It's pretty commercial now, and companies don't add costs and drive away users due to subjective notions like 'all traffic should be encrypted.'

You also presume that every other geek cares that much about encrypting all traffic. That's the problem with 'should', it's inherently subjective. I don't think the bulk of internet users agree with you.

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.

[tsj5j]

https://www.startssl.com/ StartSSL is offering free SSL certificates. From the fact that the link above displays the EV green bar on my browser, I believe these free SSL certificates won't display any untrusted warnings.

Re:Self-signed is no good.

[Anonymous Coward]

There is also an IP-address overhead if everything is SSL.

Right now you could have several hundred domains going to one server's IP address, then based on the hostname the client requests, use a different "virtual" server. Anyone who hosts web stuff is probably familiar with this.

Problem is the hostname is sent -AFTER- SSL negotiation. This means that the SSL certificate used has to come BEFORE we know what site they're looking for. This means that we can't select the proper certificate based on name. So you have 100 sites on same IP, but when an SSL request comes in for negotiation, it doesn't say which hostname it want, so you have to guess what certificate to give it! If you get it wrong, it says "Wait, this is cert for something.whatever.com, I wanted somethingelse.coolstuff.com!" and will reject the session. The only case you can actually succeed is if you have one domain and all your SSL domains are below it (something.com and subdomains of a.something.com, b.something.com) in which case you can use a wildcard cert (*.something.com) and negotiate with this.

Most shared hosting environments use shared servers and thousands of sites to one IP address.

We already have an IPv4 space problem, imagine what happens when -EVERY- domain requires its own SSL cert?

Yikes.

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.

[maxume]

I think the Slashdot admins don't think it is particularly important (and last I checked, only subscribers were blessed with access to the https version of the site anyway). If they wanted to, they could put a secure login link on the javascript popup.

Re:Self-signed is no good.

[OrangeCatholic]

Huh?

Do you dial in to Slashdot on a 486? I don't even get what you're saying.

Re:Self-signed is no good.

[OrangeCatholic]

>I don't think the bulk of internet users agree with you.

Agreed. But if you read my other posts, you'll see that a) the bulk of internet users is 14-year-old girls and Latina housewives, and b) the Postal Service has been encrypting the majority of its traffic for over 100 years.

Welcome back Mr. Brucke. Try to be more contrarian.

Re:Self-signed is no good.

[Yvanhoe]

Even without that, I am shocked that emails are not encrypted by default. In theory it is bad practice to trust the keyserver, but the occasional physical meeting and keysigning will allow to detect if a tampering happened.

What is holding back mail cryptography ? Outlook. It doesn't respect the RFC that would allow every email to be at least signed in a a transparent way. There has been urge to change it for more than 8 years.

Meybe it is time to mandate GPG key generation transparently at thunderbird's install ? Forget about having the regular paranoid crypto-phreak security, a locally stored password would still allow a lot of phishing attacks to be detected and would offer a good layer of privacy against eavesdropping.

Re:Self-signed is no good.

[Anonymous Coward]

...getting an cert (e.g. from Thawte) is just too difficult.

You don't need a certificate from Thawte - I use a mozilla Keygen add-on to get a self signed certificate for my email. While I agree that personal email is a different issue from a website (I might be suspicious if I saw a website with a self-signed certificate), there is absolutely no technical problems with self signed certificates.

Re:Self-signed is no good.

[zxaos]

Unfortunately, although you do point out the benefits of having even a self-signed cert, the average user is going to go the page see something that looks like either an error or a "you are being hacked!" message, depending on how much they read and how much they know (particularly if they're using firefox). That's the point when the average person is going to hit back or go to a different site completely.

In short, until browsers change their behaviour when confronted by a self-signed cert they will never gain widespread acceptance and use with a non-technical crowd.

Re:Self-signed is no good.

[Anonymous Coward]

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

What about the cookie?

Far too many sites require HTTPS for login and then go back down to unencrypted HTTP where your auth cookie (typically set to expire long into the future) is sent over the wire.

Re:Self-signed is no good.

[Tim C]

I find it hard to believe that the performance drop will matter...to me.

To the server, maybe.

The server being slow because it's overloaded doesn't matter to you?

Re:Self-signed is no good.

[Mr. Underbridge]

Agreed. But if you read my other posts, you'll see that a) the bulk of internet users is 14-year-old girls and Latina housewives,

And yet they still count as much as high-minded (and racist and misogynistic) folks like yourself. And that's ultimately the problem you face - geeks who advocate unnecessary technical changes for their own aesthetic sake are a tiny minority of internet users now.

You are a prime example of someone who lives in 'the land of should'. By that I mean you hold as an ideal that all traffic 'should' be encrypted without any discussion as to why. But from a practical standpoint, the vast majority of people either A) don't care if their non-transactional traffic is encrypted, or B) consider themselves uninteresting enough to not be a target.

More to the point, encryption of one-way traffic (http sessions) is controlled by providers, and as mentioned, there's approximately 0 reason to encrypt a web site that anyone can go read for themselves, aside from your idealistic and subjective notion that 'all traffic should be encrypted'. Given that, you're increasing their operational costs...for nothing. And driving away users...for nothing. So the only way they'll change is when so many users DEMAND encryption that they'd lose traffic for not having it, and that's not ever happening.

The above also ignores the blatantly obvious fact (as mentioned) that encryption with self-signed certs is actually worse that nothing, since it causes people to trust a cert that could easily be generated by a man-in-the-middle type of attack. So it's either buy a real cert, or use nothing. As above, using real certs costs money, so there's absolutely no motivation to use it for standard web traffic. If I'm a guy writing a blog, why would I go to that expense?

People keep telling you why traffic won't go full-encryption anytime soon, and you keep arguing with the blatantly obvious reasons why not. I'd suggest finding a windmill and start tilting.

Re:Self-signed is no good.

[schon]

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.

Only if you verify the certificate yourself before you connect - otherwise anyone could be snooping and you'd never know.

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

No, this is absolutely wrong. Without some OOB way to verify the certificate, it is impossible to know if the first connection is being intercepted or not.

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.

[jellomizer]

Also modern infrastructure doesn't make secured connection less necessary... Ok before you go ranting here me out...

Back when we needed encryption is back in the days of hubs where the cost of switches were way to expensive. Now that we have switches port sniffing has become more and more useless as the equipment directly forwards the traffic vs. a wide broadcast that was even popular 5 years ago. So today the method of getting personal information isn't really useful for the problem encryption solved.

That said, We still don't have a trusted path on the internet. There are still hubs floating around and someone in the middle can setup something in the middle, to get your data... However Encryped vs. UnEncrypted data is being relegated to the people are doing more direct attacks on information vs. the old day just get as much data as possible. So if you are going to risk getting caught and being on the "inside" of the traffic you really need to make sure your reward is greater then the risk. And a lot of the information passed really isn't that useful. And not worth the risk.

Re:Self-signed is no good.

[MobyDisk]

because it is not possible to POST to HTTPS via Javascript due to the same origin policy in browsers

This is the first I've heard of this. I wrote code for an AJAX site that required https for everything. The only http page was the front page, which redirected to the https site.

Re:Self-signed is no good.

[jhol13]

Getting a cert, or creating PGP key, is not the problem.

I do not know a single person who has PGP key or cert. Or more accurately and to the point, everyone I know I do not even know *IF* they have a PGP key and where that might be or how I might retrieve it.

Re:Self-signed is no good.

[peragrin]

Two issues.

One i have hundreds of phonenmbers and emailaddresses for people I will never meet physically. It is tough to meet them when they are thousands of miles away.
Second how do you pass the keys around? In a clear text email? Where the man snooping on you gets a copy of the key anyways?
So you have non secure key passing, quadrupling the workload on the person. Yes it is you have to manually verify recipt and proper decryption but check ca isupdated. Something that I see failing daily in IT with just SSL certs. Sending one encrypted email isn't as easy as typing a Letter and clicking send. Until it is encryption for emails will remain insecure.

Re:Self-signed is no good.

[schnablebg]

Your AJAX code cannot POST to a an HTTPS address if the page it is posted from is HTTP. Redirecting to HTTPS is the correct solution; /. does not allow this (if you go to https://slashdot.org/ you are redirected back to HTTP).

Re:Self-signed is no good.

[icebraining]

They allow OpenID - it's as secure as your choice of provider.

Re:Self-signed is no good.

[icebraining]

Verizon certificate comes with the browser! So, if a certificate is checked by Verizon, your browser can verify it against the certificate it has from Verizon, which it knows is good.

Even if some guy is doing a MITM attack and replaces the website cert, it can't be signed and pass the validation against the Verizon cert in your browser.

Did your browser came with a BBS cert? Mine didn't.

Re:Self-signed is no good.

[icebraining]

People still chain mail by putting all their contacts in the To: instead of Bcc: , and you want them to encrypt everything?

Then you would have people using webmails that don't support it, or using Outlook '97, or deleting their key file, etc.

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.

[Lazy Jones]

Startcom offers free ssl certs and they are in all the browser roots now (although only recently added by microsoft).

They also offer to generate a private/public key pair for you, which is something you should really give some thought before you recommend using it.

Re:Self-signed is no good.

[Anonymous Coward]

Require the Registrar to give one wild card cert with every domain sold.
This would make me use them every time just because I have them.

Re:Self-signed is no good.

[Anonymous Coward]

Trouble is, self-signed IS good. It establishes encryption, which is the point.

What a self-signed cert is missing is the I've-paid-Verisign-to-vouch-for-me identifier. That's nice and comforting for stuff like banks, but if my-bank-of-choice.com gets compromised, the bad guys have the Verisign-vouched cert too. The "I am who I say I am" problem can be slightly helped, but not solved, by the current pay-Verisign-or-whoever system. The problem of encrypting data so that nasty folks in between can't read it, that problem's easy: encrypt it. We don't need the concept of vouched (note: not _proven_) identity in order to encrypt data.

Encryption on its own is worth plenty, but browsers (Firefox 3+ in particular) disagree, and complain spectacularly at the idea.

Re:Self-signed is no good.

[ei4anb]

well, you could use OpenID and have HTTPS for your own login on your own site.

Re:Self-signed is no good.

[Trepidity]

How is it "wrong", when you restated exactly what I said? I pointed out that if the first connection was not an intercepted one, the self-signed cert guarantees that subsequent ones are not either. It does not guarantee that the first one was not intercepted, clearly. But it still greatly decreases the odds of a man-in-the-middle attack, since such an attack could only be made on the first ever connection.

(I do, incidentally, have an OOB way to verify my own self-signed certificate on my own server.)

Re:Self-signed is no good.

[jthill]

Only if you verify the certificate yourself before you connect - otherwise anyone could be snooping and you'd never know.

I'm sorry, but that's just wrong. Self-certs stop all the garden-variety wiretap tools cold, and that's where snooping starts.

Self-certs stop everything from there on up until the attacker has completely usurped the target's subnet to the point of controlling things like ARP and DNS and DHCP, and at that point we no longer call it "snooping".

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

No, this is absolutely wrong. Without some OOB way to verify the certificate, it is impossible to know if the first connection is being intercepted or not.

I'm sorry, but you got that wrong too. The OP posited untampered transmission of the certificate. It's invalid, non sequitur, just plainly and completely wrong to rebut that by rejecting his premise.

It's a completely different response to question his faith in the security of the transaction that delivered the cert, but that in itself raises questions that the entire CA architecture does not completely answer.

Let's start with obvious fact: there are close to eighty (80) authorities on my brower's authority list.

It's valid to reject the obvious implication I'm raising here as requiring far more resource and dedication than just casual snooping, but see above: that's my point too.

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.

[slim]

A Man in the Middle attack:

Snooper uses DNS poisoning to misdirect you to the wrong server. Snooper presents you with a self-signed certificate, which you accept. Snooper decrypts your requests, records/rewrites/generally-mucks-around, then forwards it to the real server on a separate SSL session.

With a self-signed certificate, you'll at least be warned that the certificate has changed, if you've previously used the kosher certificate. But you're training users to just accept self-signed certificates.

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.

[schon]

How is it "wrong", when you restated exactly what I said? I pointed out that if the first connection was not an intercepted one, the self-signed cert guarantees that subsequent ones are not either.

I apologize, I misread your statement.

However, your statement is a tautism. How do you know that the initial connection isn't intercepted?

To use the OB /. car analogy, it's the equivalent of saying "Summer tires are as good on icy roads as winter tires, as long as you don't lose traction."

it still greatly decreases the odds of a man-in-the-middle attack, since such an attack could only be made on the first ever connection.

Citation needed. MITM attacks on the initial connection were around years before the recent SSL-renegotiation bug was discovered. If someone can do SSL renegotiation MITM, then they can do initial-connection MITM, and you've gained nothing.

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.

[julesh]

Maybe when getting a server cert is free/easy people will do it defacto

Only if we've switched to IPv6 as well. Fact of the matter is, the average hosting provider has about 20 domains per IP address. If all of those sites switched to HTTPS, each would need a separate IP address, resulting in instant demand for around 150 million extra IP addresses. AIUI, this is approximately the size of the current unallocated pool, so we'd be out of addresses instantaneously.

Re:Self-signed is no good.

[julesh]

it is not possible to POST [login details] to HTTPS via Javascript due to the same origin policy in browsers

Huh? I haven't tried this, but I'm pretty sure it's possible: put a form in an iframe (either hidden or visible, at your choice) with the submission URL set to your secure site. Submit the form via javascript. Have the secure page update a server-side session with your new credentials (if login was successful) and then redirect back to a non-secure page which calls a function in 'parent' to notify it of the result of the submission. What's so hard about that?

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.

Re:Self-signed is no good.

[julesh]

Just how steep is the performance drop from HTTPS? With a 15 Mbit residential connection and a 2Ghz processor, I find it hard to believe that the performance drop will matter...to me.

More relevant is your ping times to the server. Opening an SSL connection requires (IIRC) 6 extra round trips as the protocol handshake and key exchange take place. On my reasonably fast connection (admittedly not a 15Mbit one) I see ping times of around 100ms for most web sites (50-60 for really high performance ones, like google and high profile sites using content distribution networks). This means using SSL would add over half a second to my page load times, which is why I usually do notice when a site is using it.

Re:Self-signed is no good.

[Anonymous Coward]

Oh, you're sure that the person you're talking to is the one who encrypted it. You're just not sure that the website is the one you intended to visit.

In other words, you're not sure that you're actually talking to tinywebmerchant.com instead of some hacker.

Re:Self-signed is no good.

[PCM2]

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.

Except that if the only data you ever encrypt is sensitive data, you make the jobs of the people trying to snoop on you that much easier. It may still take some CPU power to crack your encryption, but they know they can discard 99 percent of your packets and focus exclusively on the encrypted ones.

Re:Self-signed is no good.

[mstahl]

I am intrigued by your ideas, TheRaven64, and would like to subscribe to your newsletter.

Re:Self-signed is no good.

[danpritts]

Interesting - I hadn't actually looked at it beyond a quick glance. They will accept a standard certificate request, but as Lazy Jones describes above they'll just generate it all for you.

It's a tough call for me whether this is a good thing or a bad thing.

Obviously, as you say, when they generate the key for you, you're giving them your ssl session. OTOH, maybe if it gets more people using ssl in more cases, it's worth it.

Re:Self-signed is no good.

[jthill]

GGP wanted to protect against snooping, against which SSL is bulletproof.

As I said early and late, getting into an SSL session means getting control over ARP or DNS or DHCP traffic, and that goes beyond just "snooping".

Fire up wireshark surreptitiously, you're snooping. Set yourself up to impersonate a particular site and then usurp the local gateway or poison its DNS to enable a man-in-the-middle attack, you're not snooping any more.

In short, Trepidity's post was spot on, and schon hammered him for not defending against attacks he explicitly mentioned as potential weak spots and said he didn't care about. As you say, widespread use of self-signed certs might lead the ignorant into unthinkingly accepting self-signed certs at the wrong time, but schon didn't say that.

What the self-signed-cert warning screens should say is something along the lines of

This session is vulnerable to a targeted attack. No major or commercial site will ever use the sort of security credentials this site is presenting. If anything you truly value is at risk, get out now. If you intend to continue with this session you must acknowledge either that you have independent verification that these are the correct credentials for [site name here] or that you are willing to take the very real chance that an attacker is impersonating this site.

with "get out now" above being an escape link, a big button and the only button on the panel that reads "Get out now", the full hashcode beneath that with no explanation at all, and links, not buttons, below that reading

I've verified every digit personally, and that's the correct credential for [site name here].

and

This might be an impostor's key, but if so I simply don't care enough to check. Anybody willing to spend a few hours' effort to steal my identity here is welcome to it.

That way people could actually make an informed choice. As it is now, the simple fact is that the major browsers are telling lies about security issues.

Re:Self-signed is no good.

[BZ]

If you're actually trying to prevent your password being compromised, putting it into an http page is the wrong way to do it. Even if the page normally sent it to an https:/// server, nothing is preventing someone who cares from running mitm on the login page itself and just changing the form action or XHR url to an https:/// server of their choice (theirs, say)....

Re:Self-signed is no good.

[BZ]

The particular change was that if the server sends "Cache-control: public" the SSL content will be cached on disk (after decrypting it, of course). Otherwise it's memory-cached only.

Re:Self-signed is no good.

[muckracer]

> If all of those sites switched to HTTPS, each would need a separate IP address

AFAIK, SSL via shared IP and virtual host(names) is possible. Haven't had the need to actually use it but it is available.

Re:Self-signed is no good.

[muckracer]

> to protect against snooping, against which SSL is bulletproof.

Is it really? Am not so sure. After all, you "trust" all those companies you've never heard of to vouch for the certificate. So what's someone with extended capabilities and resources to get a nice MITM certificate signed by said companies and putting themselves, well, in the middle of your session to your intended target server (let's say SSL'd web mail). Your browser trusts the white-van cert and they in turn forward your traffic to the real site. Seems pretty classic. In fact, a self-signed cert which you've been able to verify or at least save once would offer more security.

Everybody and their mother asks: Do you know who you are communicating with? Perhaps the real question is: Do you know who you trust?

Re:Self-signed is no good.

[jthill]

I'll say it a third time, then: setting up a mitm goes far beyond snooping.

Against snooping, SSL is bulletproof.

Against a targeted attack, SSL with a known-good certificate is bulletproof.

What lengths you have to go to to be sure of the certificate increases as attackers throw more resources at it, and yes, if they're going to go to the trouble to corrupt a CA, you and I and everyone else are screwed so hard we can't even feel it any more. That was the implication I left earlier.

And that's the other part of the reason I so strongly dislike the misleading and excessive warnings against self-sign: not only are the tactics being used deceptive, the trust they're offering in its place is blind.

Re:Self-signed is no good.

[bingoUV]

But how is self-signed cert less secure than plain old HTTP? Browser does not give any warnings when encountering unencrypted HTTP "OMG, you could be hacked, unencrypted page!!!". Plain old HTTP is also susceptible to MITM attack, only you don't even need MITM attack to snoop.

Re:Self-signed is no good.

[bingoUV]

While I agree with most of your points, the browser message you suggest is too scary. A HTTPS connection based on a self-signed cert is at least as secure as plain old HTTP. A browser which does not warn against plain old HTTP does not have the moral authority to warn so severely against self-signed certs. The only thing it can say is that such a connection should not be considered "secure" simply by its being HTTPS.

Re:Self-signed is no good.

[Bengie]

You only need a hand-shake at the beginning of a connection. Maybe they need to let a connection stay open a configurable amount of time set by the web admin. I could see a connection staying open for 1 minute and that would cover a lot of rapid clickers. If I spent more than 1 minute on a web page, waiting 1 second for the next link to respond won't matter much to me.

Or ma'b we need a new system. Here's an example of something that would help, but not very transparent since browser and web service would have to work together.

After a secure connection is established and right before it drops the current connection because it's done transferring, create an symmetric key, send the key to the client along with a GUID/Token. Next time(make these tokens expire after 15min or something) the client attempts to connect to the same web server, the client sends this GUID/Token in clear text and all data after this token is encrypted with the previous agreed key. If the key+GUID pair is rejected, start over from scratch and just do a new hand-shake, otherwise keep on truck'n. Obviously the server would remember which GUID is attached to which key, and the GUID+Key would expire the instant it's used.

The above example would eliminate a hand-shake on every new secure connection by the same client and wouldn't add to much extra load to the server because looking up an indexed table of GUIDs to find the key attached would be easy.

Because nothing bad...

[Chysn]

...could possibly happen to me. That's it. Perceived risk versus perceived effort.

Re:Because nothing bad...

[timeOday]

Well, what are the supposed consequences? There is a rather glaring lack of horror stories about people with big problems that would have been prevented by using encryption. Partly because the stuff that most needs to be, already is (ssl/https). And with gmail now using https by default a huge swath of email is now encrypted on the wire.

Re:Because nothing bad...

[XanC]

It's encrypted when the user goes and reads it from his mailbox. It certainly ISN'T as the mail bounces around between servers on its way to gmail. That's the encryption we're talking about here.

Re:Because nothing bad...

[timeOday]

It just depends on when you suspect the alleged snooping is most likely to occur. Protecting clients (google webmail clients in this case) does protect the end-user credentials. In cases where the sender and receiver happen to both be on gmail, all you have left to worry about is whether google itself is snooping - which they are, openly and on a massive scale. But they have an awful lot of users who don't seem to mind, and so far it's hard to identify any sort of damages from it, whereas the benefit in spam filtering is easy to appreciate.

Re:Because nothing bad...

[Anonymous Coward]

... And with gmail now using https by default a huge swath of email is now encrypted on the wire.

I might believe you if gmail was using TLS for their SMTP trasnsport... but sadly not.

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

[Concerned Onlooker]

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

Yes, encryption won't stop government oppression, but it will slow it down. It's not just the fact that they can still harass one person, it's the fact that with everybody encrypting their communications the government's ability to data mine email and do covert spying on its own citizens becomes much harder.

Re:I have encrypted this post

[140Mandak262Jamuna]

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

But what if that post contains the secret formula that would set the pants on fire successfully? You know what kind of danger that would pose to general aviation? So get ready to greet a couple of tall gentlemen in dark suit, dark glasses who speak into the lapels of their coat.

Re:I have encrypted this post

[fridaynightsmoke]

But what if that post contains the secret formula that would set the pants on fire successfully?

But I thought that a certain T. Blair had the formula for "pants on fire"!

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

[Anonymous Coward]

email is still transfered between servers unencrypted

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

[__aastpl2241]

That's what steganography is for (check truecrypt). Encryption ensures that nobody else can read the message, if you want to hide, then you need steganography, which hides the message. or as true crypt does: the data can be decrypted with 2 passwords. one for the cop, one for you and they can't know if there is something else

Re:I have encrypted this post

[Anonymous Coward]

>band together with a group of anonymous people.

And then the fuzz busts you for racketeering.

How about not breaking the law instead?

Re:I have encrypted this post

[Anonymous Coward]

He can provide a one-time-pad which turns the "encrypted" data into a message of his choice. For every encrypted message, there is an infinite number of decryption keys and algorithms which turn it into a plausible clear text, and some (like OTP) are extremely easy to calculate for any given cypher/clear text pair.

Re:I have encrypted this post

[fridaynightsmoke]

How about not breaking the law instead?

I'm soooo glad that you would never ever break ANY law whatsoever.

(Assuming you're in the UK) you've never:
* Driven at 70.0001mph or more on any public road
* Played any copyrighted music in public
* Made any kind of written or verbal statement about anyone that you couldn't absolutely prove to be true on demand
* Been in posession of a single molecule of any banned drug (CLUE: There are detectable traces on all money, and most other objects that have been handled by the public)
* At any point downloaded or stored any image or depiction of S&M or potentially arousing images of any person younger than 18 (even accidentally)
* Dropped any object in a public place as litter (I wonder if skin cells technically count)

Re:I have encrypted this post

[MobyDisk]

I don't think there is a countermeasure in the UK. In the US, they call it the second amendment.

Re:I have encrypted this post

[Explodicle]

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

Can't download/view encrypted files? Goodbye DRM!
Can't download from an unverifiable source? Goodbye scammers!

Call me the day this fantasy world arrives and I'll find plenty of holes for you.

Re:I have encrypted this post

[Myopic]

I feel the pain of people living in the UK. It's not a free country, even though it masquerades as one. It doesn't have freedom zero (self defense) and it doesn't have freedom one (self expression). It isn't a real democracy, either, although thankfully it is a sort-of-half-way democracy. It surprises me, actually, that democracy gained a toe-hold there, but never fully blossomed; and that democracy was insufficient to provide all the basic freedoms.

The United States certainly has its problems, but at least here I can kill people who are trying to kill me; and I can say deeply offensive and contrarian things with impunity.

Re:I have encrypted this post

[StikyPad]

To say that you couldn't verify the source without trying to decrypt the files?!?

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"

Re:I have encrypted this post

[Concerned Onlooker]

The idea is that you encrypt it before you even send it.

Re:I have encrypted this post

[Rainer]

Simple solution:

Use one time pad encryption.
Hand out the key that produces the desired plaintext.

Re:I have encrypted this post

[Anonymous Coward]

You're right...damn those pesky brits.

On a related note--I tried decoding your message, but I get two different plaintexts depending upon which one time pad I use to decode it. Can you please clarify whether or not the message decodes to:

"please pick up some milk and eggs at the supermarket on the way back home, and your half of the rent check is due in a week. TTYL."

OR

"comrade, we have placed the incendiary device at dropsite 2. Execute plan blue native next tuesday. Praise be to Allah. -- jackel."

Re:I have encrypted this post

[cerberusss]

Include plenty of Klingon conversation. Key: kkjkjGHIUgibilh is Blimey! in Klingon. So is jGHLiubhjbiu78HVji67.

I hate that kind of sexual activity! It is disgusting!

Re:I have encrypted this post

[Anonymous Coward]

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.

you're obviously not familiar with RIPA. Any data on your computer that you can't convert to english prose, gets 2 years porridge. God help us when the computer-illiterate [I've met some] idiots at Paddington nick antiterrorism branch discover tar.gz

Re:I have encrypted this post

[Anonymous Coward]

If you're in China, the government's response to your hiding behind the rest of your "anonymous" group would be to lock everyone up. Now, allow real-life torture on to a group of, say, 40 other anons, and wait till one says 'Please stop punishing me! _______ was the original encrypter.'

The classic Prisoner's Dilemma is worse for you as an individual prisoner when they can coerce more prisoners. There will always be someone in an anonymous group willing to rat our at least your screenname or even falsely blame you. No honor amongst 'bandits' who don't know you personally in an anonymous collective, you know?

Re:I have encrypted this post

[Anonymous Coward]

"You can take my gun from my cold dead...*BAM*"
-MobyDisk seconds before being taken out by a tank

Lot of good that second amendment does you against the government.

Re:I have encrypted this post

[alphastar]

Incidentally, that's EXACTLY whom the Second Amendment was designed to protect us against.

Lack of time.

[Smoky D. Bear]

A lack of time to implement it/management changing priorities... again. I would love to and I had thought that I had convinced management why we needed to (Nothing fancy, just ssl on parts of our web page). Then something blew up. Then something else blew up... and it just wasn't that important to management any more.

Nutshell

[Anonymous Coward]

Businesses don't give a shit about encryption because there isn't any accountability on their part.

Your information is stolen? Too fucking bad. That's your problem.

Show me one company that got sued or whatever and had to pay for their stupidity with regards to information being stolen or lost.

Re:Nutshell

[Lunix Nutcase]

Okay. What do I win?

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

[SanityInAnarchy]

Yes, unsigned encryption is vulnerable to MITM. So what? It protects against the far more common traffic sniffing...

I wonder if traffic sniffing is far more common because it's easy to do, because we aren't really doing opportunistic encryption?

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.

Re:Signed certificates

[sjwest]

I'd be pro if

1. i had control over who got my key data rather than assuming its gets passed on by default to echelon by versign etc
2. i could create keys without firefox complaining like two year old about them
3. I can do external and internal networks via two cheap network cards - put the price up and maybe we talk
4. Im still going to need a firewall, a virus thingy, and a copy of spam assassin
5. There's security in obscurity
6. I'd rather not have a password like 'Rabbit09876cluckTHE-cHicken' and have to type it in for disk encryption each time, or have truecrypt keyfile of amazing length that probably constitutes a security risk all on its own

Until the ssl 'industry' comes to its senses or gets replaced I'm happy to do without

Re:Signed certificates

[Anonymous Coward]

More generally speaking, key management and authentication are holding up encryption. Certificates are just one form of managing and authenticating public keys.

Re:Signed certificates

[blueg3]

Sadly, absolutely nothing seems to support this.

Except for your example two paragraphs up, where you note that Thunderbird both supports and recommends SSL-encrypted connections.

Re:Signed certificates

[icebraining]

Does Versign need your _private_ key to encrypt the public certificate? Why?

And I don't think Firefox should complain, as long as it displayed those connections exactly as an unencrypted connection, because they don't provide the same security as a signed connection; just the fact that it can be MITM'ed kills the whole security.

Re:Signed certificates

[TerranFury]

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.

Indeed. What's more, I'd argue that the content of these sites is usually sufficient proof that they are who they purport to be. Say I SSH into my home media server. I believe that I'm talking to the machine I think I am if-and-only-if it has the 2 TB of media I expect it to have. That -- especially if public keys are stored by clients, a la SSH -- is all the authentication most users need.

Re:Signed certificates

[Anonymous Coward]

You do not seem to understand what a man-in-the-middle attack is. The attacker acts as a proxy. They connect to the real server and provide the real content, they just get to see it. Including the user's password and personal data.

Re:Signed certificates

[Anonymous Coward]

On the other hand, encrypting everything has got it's own disadvantages, such as throwing away the entire caching infrastructure for the web.

Re:Signed certificates

[TerranFury]

You do not seem to understand what a man-in-the-middle attack is.

It's weird; I've known forever what MITM attacks were but hadn't gotten how you'd pull one off here; I'd somehow come to the conclusion that the proxy wouldn't be able to authenticate to the remote server (though that's nonsense). The discussions prompted by this article have been helpful to me in clarifying things.

Re:Signed certificates

[DavidTC]

Erm, I said nothing supports cert-less connections.

While I have no idea if Thunderbird in specific can be configured to accept SSL without a cert, I do know most email servers can't beconfigured to operate without one (I certainly couldn't set up dovecot that way.), because most mail clients barf when you do that.

Most clients are entirely happy with self-signed or expired or non-matching certs, but don't want anything to do with you if you try to set up a connection without a cert at all. It's really stupid.

Re:Signed certificates

[DavidTC]

Erm, not the 'entire' one....there's nothing stopping clients from caching, which is about 80% of the caching done.

Everything else is just ISPs with slow connections trying to make them faster. At some point, we have to stop coddling slow connections.

Of course, there'd be nothing stopping such devices from simply not switching to SSL mode anyway.

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.

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

[SanityInAnarchy]

It's a pain in the ass to set up - do YOU want to have to configure everyone's email, etc. to use it?

Yes, actually, if I'm their admin. If I can't do something as simple as reconfigure everyone's email by throwing a switch, I'm probably a lousy admin.

Also only has to be set up once.

You're already leaking your sh*t all over the net

Only if you're careless, which is actually the point of the original question, I think -- why are people so careless about this?

if you use google docs, you're letting an advertising company look at all your information.

Better one advertising company under a contract that doesn't let them do evil stuff with it, than anyone who happens to sniff it, anywhere.

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

[OrangeCatholic]

>It's not needed.

You're clearly not anti-facist. Everybody says "oh, the criminals only go after what's important. Just protect that."

Actually, facists go after the mundane. In Germany it was your name that got you killed. Try encrypting that.

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

[mr crypto]

Agreed. People switch between computers at home, work, and public workstations and don't have a universal login to make it 'just work' anywhere. It also definitely suffers from the "if everyone would just use OUR system it would be easy" problem. Try coming up with your own solution and run through setup scenarios for different users (including your mother) and you'll find that there are too many steps. Even just doing authentication is tough to make simple (relies on contacting some central authority).

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

[Stepnsteph]

^ This. Perhaps some people here are lucky enough to know people who are willing to use encryption tools. They don't live in the same world as the rest of us. "It ain't happening" isn't a strong enough way of expressing the situation. I was just barely able to convince someone to install an OTR plugin, and even then they grumble about it. That's just a plugin ffs. Imagine trying to convince people to use shared key encryption for their email. I've tried (I maintain a PGP key for some absurd reason) and the responses were "No" and "Hell no" and derivatives there of.

The closest I was able to get with email encryption was Ciphire Mail. That was a beautiful tool, and it was the easiest thing to ever happen to email encryption. It's a darn shame that they folded.

That is, of course, in regards to every day users. I can't speak for the enterprise level.

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

[tomhudson]

if you use google docs, you're letting an advertising company look at all your information.

Better one advertising company under a contract that doesn't let them do evil stuff with it

You argue for encryption and yet you trust an advertising company those CEO says If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place." Their job is not protecting your privacy. Their job is making money for their shareholders. And do you really think you'll win if you sue google? After all, they'd even have your correspondence with your lawyers, so they'll know your legal strategy.

Encrypt sensitive info as a separate attachment. It's the ONLY way to be sure. Anything else is not secure.

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

[tomhudson]

Do you really think anyone cares about Aunt Martha's next post on facebook? It's going to be there for the world to see anyway.

Same with the comments posted here. No need for encryption.

Same thing with a lot of email traffic - why should I waste cpu cycles decrypting spam or lists of jokes and funny gifs?

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

[tomhudson]

It's a pain in the ass to set up - do YOU want to have to configure everyone's email, etc. to use it?

Yes, actually, if I'm their admin.

Several problems in your "solution":

1. Who the h*** are YOU that I should trust you, a stranger, to mess around with MY computer? All you've done is add one more link in the chain that needs to be validated. Two people can keep a secret - but only if one of them is dead.
2. Who's going to do all the home computers?
3. How are you going to monitor email and web traffic to make sure it conforms to AUP (Acceptable Use Policies) where you work and that someone's not sending your customer list to a competitor?

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

[maxume]

If something like OpenID were pervasive, an authentication provider could setup a certificate-on-a-stick system, and then only authenticate against sites that they had verified (so the system might decide to trust yahoo.com and google.com, but it would not authenticate requests from say, malwarexpress.com).

'Advanced' users might not like it, but it would be easy for mom and provide a pretty high degree of protection.

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

[SanityInAnarchy]

you trust an advertising company

I trust them with a few very specific things, yes.

those CEO says If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place."

Troubling, sure, but also good advice -- and no matter what the CEO says, they are, in fact, under contract.

Their job is not protecting your privacy.

Maybe not, but they are legally bound to.

do you really think you'll win if you sue google?

Actually, yeah. It'd take a class-action, but sure. But have you actually seen a case where someone has occasion to sue Google for not protecting their privacy?

After all, they'd even have your correspondence with your lawyers,

Actually, no, they wouldn't. I currently use Gmail for my school email address, because it beats what the institution has for webmail. However, I run my own mailserver for personal correspondence.

Encrypt sensitive info as a separate attachment. It's the ONLY way to be sure.

No, you could also just PGP-encrypt all your mail. I don't currently have any mail that's sensitive enough to warrant getting off my ass and doing something about it yet, though. I just don't send sensitive information over email, I deliver it by hand, or over the phone, or via more secure protocols like SSH.

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

[SanityInAnarchy]

Who the h*** are YOU that I should trust you, a stranger, to mess around with MY computer?

If it's a corporate environment, I'm your IT guy, and I already have Admin access to your computer. In fact, you don't.

Who's going to do all the home computers?

For the home computers, create simple, easy-to-follow instructions on the website. The real cost is going to be support calls, I suppose.

But if we're talking about a corporate environment, I'd say, what home computers? Anyone needs to work from home, give them a corporate laptop.

How are you going to monitor email and web traffic to make sure it conforms to AUP (Acceptable Use Policies) where you work and that someone's not sending your customer list to a competitor?

Well, first, there's no real way to prevent that. If the user is really determined, they'll just drop it on a flash drive, something like that.

But given that the email is going through the corporate server, I can monitor it there. If it's something end-to-end, like PGP, I either keep all the users' keys somewhere safe, or have the PGP done on the server.

Web is similar -- funnel everything through the corporate proxy.

But this is an issue that you want to address at a much more fundamental level. You want to have employees who actually care about your company, who won't want to do things like that. That means addressing this at the level of hiring, HR, management, and office space, not at the level of IT.

Because if you can't trust your employees, you really can't trust them. It's like ISPs trying to block BitTorrent -- users will find a way around it, and the more intrusive it becomes, the more likely they are to leave for greener pastures.

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

[zaffir]

I'd like to add that key management is a huge pain in the ass, as well.

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

[Anonymous Coward]

I didn't think so.

When will you pompous sons of bitches quit assuming you know the answer to be given by anyone who reads your sanctimonious bullshit? That whole trope has gotten to be trite enough to make sensible people puke when they see it.

Fucking arrogant assholes.

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

[tomhudson]

their job is not protecting your privacy.

Maybe not, but they are legally bound to.

Haven't read your agreement, have you? I have, and that's one reason I removed ALL of google's stuff from all my computers.

1. We may combine the
2. information you submit under your account with information from other Google services or third parties
3. When you send email or other communications to Google, we may retain those communications
4. Google processes personal information on our servers in the United States of America and in other countries. In some cases, we process personal information on a server outside your own country. We may process personal information to provide our own services. In some cases, we may process personal information on behalf of and according to the instructions of a third party,
5. We have a good faith belief that access, use, preservation or disclosure of such information is reasonably necessary to (a) satisfy any applicable law, regulation, legal process or enforceable governmental request

Read that last one twice - it means that they only have to believe that the request for information COULD be enforced, that the requester could get a warrant, not that they actually have one.

Also, you've agreed to them being able to process your data outside the US, where different laws apply. Forget about suing - you've already said they can do it.

I wouldn't trust them with anything business-related, not with such a one-sided agreement.

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

[Graymalkin]

People put a lot of information into Facebook and other social network sites. If the login cookies are all sent in the clear it's trivial to sit and sniff the network. From there it's pretty easy to grab all the information you want out of someone's account. While the threat of identity theft is a bit overblown by the media it is an actual problem that costs people a lot of money. With a little bit of information out of Facebook or Ancestry.com it wouldn't be terribly difficult to sign up for some credit cards in Aunt Martha's name and go on a little spending spree.

Keep in mind it is ridiculously easy to sniff your local cable modem segment. Connect your system directly to a cable modem sometime. An hour running ettercap or tcpdump can get you tons of e-mail and website logins. While you might not see a lot of value on Aunt Martha's Facebook postings scammers, spammers, and identity thieves are extremely interested.

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

[R2.0]

Thanks for the explanation of PITA - for a minute there I was thinking it was a gyro recipe.

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

[tomhudson]

Who the h*** are YOU that I should trust you, a stranger, to mess around with MY computer?

If it's a corporate environment, I'm your IT guy, and I already have Admin access to your computer. In fact, you don't.

Come off it. Many of us have to know how to get root on any box we can get our grubby paws on. Comes in handy when passwords get lost or the "admin" quits in a huff.

Besides, good developers administer their own machines, and their own networks. If you can't admin your own linux and bsd boxes, you're simply not qualified to be develop on them. You're an admin? YOU do not touch the developer boxes, YOU do not touch the svn server. YOU do not touch the test servers. Heck, YOU probably don't have root on the external servers, to keep you from screwing things up.

You're an admin for things like setting up email? Fine - go bug the Windows users. Or do you want to find a picture of yourself having gay sex in a cheap motel circulating on the net (historical note: the last time, it took the boss 3 weeks to find out they weren't real pics, but that I had GIMPed them).

If you want something safe from prying eyes, email encryption doesn't do it - people forward stuff all the time. Encrypt the attachment instead, and use another channel to communicate the password to ONLY the intended reader. This way, it doesn't matter how many people it gets forwarded to who can read the email itself.

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

[SanityInAnarchy]

Come off it. Many of us have to know how to get root on any box we can get our grubby paws on.

Good for you.

Besides, good developers administer their own machines, and their own networks. If you can't admin your own linux and bsd boxes, you're simply not qualified to be develop on them.

Great! If you're qualified to develop on them, you damned-well better be qualified to set up a little crypto on your email.

You're an admin? YOU do not touch the developer boxes, YOU do not touch the svn server.

Actually, I'm a developer. But no, I don't touch the svn server, because svn sucks. Use Git, use Mercurial, use Bazaar, use just about anything you want, but don't use SVN, or CVS, or worse, Visual SourceSafe.

Heck, YOU probably don't have root on the external servers, to keep you from screwing things up.

If I was an admin? Yeah, I would have root, and the developers wouldn't, for exactly that reason. Being a developer doesn't make you a good admin, and vice versa -- though the best admins are at least decent developers, so they can automate their job away.

You're an admin for things like setting up email? Fine - go bug the Windows users.

Exactly my point. I assumed we were talking about Windows users -- the kind of people who would have trouble checking the box that says "Use SSL" in their email settings.

If you want something safe from prying eyes, email encryption doesn't do it - people forward stuff all the time. Encrypt the attachment instead...

The kind of idiot who would forward something like that is probably the same kind of idiot who would forward the password, too.

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

[SanityInAnarchy]

#1 and #2 -- basically, this says that they can use information from my Gmail account to send invitations from my calendar, or to manage my chat contact list, etc. It says nothing about sharing with third parties.

#3 -- so what? Really?

#4 is probably the most worrying, but it seems to me that this is referring to the datamining they do -- it doesn't seem to suggest that personal information may be used in any other way than as aggregated statistics.

Read that last one twice - it means that they only have to believe that the request for information COULD be enforced, that the requester could get a warrant, not that they actually have one.

I don't see it. I've read it three times, now, trying to see how you could interpret it that way.

It essentially says that they'll preserve enough information so that they can deal with appropriate subpoenas, if they come up. But if you look at Google's actual behavior, when law enforcement has come knocking, they often fight giving up that information.

I wouldn't trust them with anything business-related, not with such a one-sided agreement.

I'm also not clear on what "business-related" has to do with it.

But let's see...

Google only shares personal information with other companies or individuals outside of Google in the following limited circumstances:

• We have your consent. We require opt-in consent for the sharing of any sensitive personal information.
• We provide such information to our subsidiaries, affiliated companies or other trusted businesses or persons for the purpose of processing personal information on our behalf. We require that these parties agree to process such information based on our instructions and in compliance with this Privacy Policy and any other appropriate confidentiality and security measures.
• We have a good faith belief that access, use, preservation or disclosure of such information is reasonably necessary...

The way I interpret this is that they won't share information unless you consent, unless they're legally forced to, or to the extent that they offload their processing to a third party.

Also, you've agreed to them being able to process your data outside the US, where different laws apply.

Though it seems unlikely that they'd take their business anywhere where contracts like this don't apply -- they have their own contracts they want to support.

Forget about suing - you've already said they can do it.

Could you please bring up a specific example of something they'd do that I don't want them to?

For example, I don't want them to dig through my personal emails and send them to everyone on my contact list. And according to this policy, they won't.

Also, if I may ask, who do you do business with? Who's got a better policy? Not that I doubt one exists, I'm just curious.

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

[tomhudson]

If you want something safe from prying eyes, email encryption doesn't do it - people forward stuff all the time. Encrypt the attachment instead...

The kind of idiot who would forward something like that is probably the same kind of idiot who would forward the password, too.

Which is why I said to use the telephone to give them the password. Always use a different channel of communications for the password. Phone. Fax. SMS. If you have to put it in an email, reference something that is specific but not to them only - "Second letter of each word in the first paragraph. You already know which book to use." The recipient knows it's not even a book, it's the obituaries in today's paper - a real one-time pad.

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

[tomhudson]

Google has already interpreted the "sharing with the fuzz" the way I stated. They hand over the info without a warrant, because, under the TOS you agreed to, it only requires the expectation that the requester could obtain a warrant.

You just posted something nasty about Eric Schmidt? He "could" try get a warrant, so google has the legal right to let him see your info w/o a warrant.

Like I said, they've already done this.

Also, if I may ask, who do you do business with? Who's got a better policy? Not that I doubt one exists, I'm just curious.

My sites, and my email are hosted in Canada, and so is my ISP. Both PIPEDA (Personal Information Protection and Electronic Documents Act - federal) and provincial legislation guarantees that they may NOT ship personal information outside the borders of the country without my express consent, and that any release even inside Canada requires a warrant except in immediate emergency, which they have to explain afterwards.

Remember - faced with being banned in both Canada and Australia, facebook backed down. It's sad how Americans continue to tolerate intercepts without a warrant.

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

[SanityInAnarchy]

The kind of idiot who would forward something like that is probably the same kind of idiot who would forward the password, too.

Which is why I said to use the telephone to give them the password.

The point is that if they're going to deliberately forward something confidential, they'll find a way to do it anyway. They'll listen to you on the phone as they write it on a sticky note. Then, if they have to forward the file, they'll type it into the email.

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

[Dan541]

Yes, actually, if I'm their admin. If I can't do something as simple as reconfigure everyone's email by throwing a switch, I'm probably a lousy admin.

Yes that's all fine and well for internal mail, but when they want to exchange their bank details with that prince in Nigeria they are back to unencrypted email again.

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

[Dan541]

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.

Over the phone? When the key is something like "HjnH6AooMyKzE9HOki6Au2d51wb" screw that, I just include the key in the body of the email. Such an email would actually be compliant with many corporate security policies.

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.

Re:Apathy

[tsalmark]

Telnet and Rsh are effectively dead. FTP is used primarily on cheap hosting and drop boxes. HTTP is encrypted where it is taken to count - Banking and such. POP IMAP are being encrypted by more and more Large ISP's. Some issues that are solable by encryption are solved otherways (routing and firewalls) Everything can be encrypted but most does not need to be.

Re:Apathy

[Anonymous Coward]

Canadians don't want guns in their houses. We learned from our previous primer minister that the only weapon* we need is a plastic spork from KFC.

* In case of missing spork, simply try to strangle the assailant.

Re:Apathy

[snspdaarf]

Agreed. Less than three percent of our customers want encrypted data exchange. They not only seem fine with standard FTP, they are hostile to SFTP. Some will ask for an IP address to add to their access control lists, but for most the attitude is, "Have a go, joe!"

Re:Apathy

[OrangeCatholic]

>Probably not the best attitude

It would be fine if your FTP server wasn't connected to every user in China and Russia. It's kind of like hanging your underwear to dry on a clothesline in the backyard thinking, "I only have one neighbor, what's the chance he's going to see my underwear?"

Meanwhile, there's 6 BILLION people living at your neighbor's house. I mean, it's not a sure thing that you'll get robbed, it just goes to show that your FTP server is in a ghetto.

That's what people don't get about the internet. It's the ultimate shitty party. Everyone's invited. There's no way to keep anyone out.

Oh wait, there is!

Re:Apathy

[camperdave]

Here's another meh for you. If I send someone an encrypted email, can the recipient read it, or do they have to have their email set up too. My guess is they have to set up as well, but I can't be bothered to check.

Re:Apathy

[theCoder]

It's not just apathy -- most people don't see a need for encrypting stuff. Either it's "I'm not important enough" or a belief that it's not really possible to eavesdrop on Internet communications.

I had this conversation with my father over Christmas. I was trying to encourage him to digitally sign (PGP) his emails and how that would enable other people to send him encrypted emails. He wanted to know why, if eavesdropping on the Internet was so common, can't you go Google for people willing to sell you sniffed data. I couldn't come up with a good answer, because I don't think I've ever even heard of a rogue admin at a Tier 1/2 ISP doing that sort of thing. The closest I've heard of is the government slurping all data and doing who knows what with it, but probably not selling it.

So, if I was a nefarious businessperson who wanted to find out the confidential dealings of my competitors just by listening to their Internet traffic, is that even realistic? Are there people/groups out there that do that? Is it necessarily even illegal for an ISP to packet dump and then sell the data? If not, why don't they do that -- or maybe they do?

I know it's a theoretical possibility, but for many people it's way too theoretical to bother worrying about it. Some hard information would be helpful.

Re:Apathy

[cstdenis]

Even in IT the learning curve can be an issue for some items.

Ever read the man page for openSSL? If you don't already know the parameters to get what you want, good luck figuring them out.
openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout example.com.key -out example.com.crt
and
openssl req -new -nodes -keyout example.com.key -out example.com.csr
Isn't exactly obvious from the documentation.

And ever try to implement DNSSEC? That is a pretty complicated system too so it's no surprise few are bothering to go to the considerable effort to set it up.

Encryption needs to be simple to implement if we expect people to bother doing it.

Re:Apathy

[Anonymous Coward]

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'd imagine encryption to be locks and safe window joints; a gun would be something like a ping flooding daemon.

Re:Apathy

[westlake]

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

Understanding the problem correctly is the first step to a solution.

You don't want a gun in the house.

You want to ward off an intruder without a confrontation.

The armed encounter is damned unpredictable. You don't know when it will happen or who will have to face it.

Maybe your ten year old kid can pull it off.

But you might come home to find her dead.

Re:Apathy

[omb]

Yes, you have a point, that CLI looks hard but it would only take a competent student a day to write a gui wrapper for A/L/W with Qt.

There's no reason to encrypt HTTP

[Anonymous Coward]

There's no reason to encrypt HTTP requests that don't contain personal information.

Re:There's no reason to encrypt HTTP

[Cthefuture]

Everything you do online provides personal information in some way.

Re:There's no reason to encrypt HTTP

[grub]

There's no reason to encrypt HTTP requests that don't contain personal information.


No? Think about someone in China searching for Falun Gong information then having their door kicked in by the state police.

Re:There's no reason to encrypt HTTP

[Pojut]

True, but some things truly don't matter if they get out in the open. My own website linked in my sig is a perfect example of that...while I log activities on my site through statcounter.com and can view any visitor's IP and system specs, their information isn't "public" unless they leave a comment (and then the only information public is what they write.)

A lot of information out there doesn't need to be protected, and other than my own traffic logs, there is nothing on my site that would warrent the cost and time associated with using encryption. If I were running a bank or a store, then absolutely everything if you were logged in would be encrypted...but for people like me, encryption is a waste of resources.

Re:There's no reason to encrypt HTTP

[MathFox]

But there is no reason why I should make it easy for my ISP, upstream providers and the NSA to eavesdrop on communication with a webserver. Encrypting my communication plugs a big privacy hole: so, why not use it?

Re:There's no reason to encrypt HTTP

[OrangeCatholic]

Thank you. Perfect example. Especially since it would happen.

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.

Re:There's no reason to encrypt HTTP

[eightball]

That search seems to me to contain personal information: an interest in Falun Gong.

Re:There's no reason to encrypt HTTP

[Anonymous Coward]

I don't consider personal information like "I visit Slashdot" or "I like kittens" relevant in this case.

Re:There's no reason to encrypt HTTP

[Grizzled Old Scout]

Excellent point and it underscores the truth that for some people and some sites, merely the act of visiting the site is confidential information.

Re:There's no reason to encrypt HTTP

[TheRaven64]

By that token, any HTTP request contains personal information: an interest in whatever is in the HTTP response. Which makes the original statement essentially semantically null.

Re:There's no reason to encrypt HTTP

[eightball]

Yes and no. The Chinese government knowing who like the Jonas brothers probably isn't going to be an issue. Whereas with the given example it probably would be, and the people there know the difference.

Re:There's no reason to encrypt HTTP

[Anonymous Coward]

Several search engines will take https encrypted requests. Welcome to 2008.

Re:There's no reason to encrypt HTTP

[eightball]

I suppose I should make clear that I take "personal" in this context to mean stuff that could be used to impersonate or incriminate you: addresses, bank information, pronography collection indexes,etc..

Re:There's no reason to encrypt HTTP

[Anonymous Coward]

The point of security like this is to protect you against 3rd parties, not the party you are communicating with.

Obviously the person you are talking to knows what you're doing, duh.

Re:There's no reason to encrypt HTTP

[TheRaven64]

I take it that you've never studied the history of the USA. Here's a relevant example for you:

During the end of the Second World War, the USA was part of an alliance with several other countries against the Axis powers. A number of American citizens contributed money to charities to help people in their allied countries who had been left without homes or food by the war.

A few years later, one of these former allies was now the enemy, the Red Menace, and anyone who was suspected of being a member of the communist party faced losing their job, many of their friends, and so on. Having contributed to a charity to help the Russians was seen as evidence of having communist sympathies.

So, it may not be important who knows that you like the Jonas Brothers now, but that doesn't mean that it won't potentially be damaging in the future. Social mores change, and things that are completely acceptable now may be proscribed in a decade's time.

Re:There's no reason to encrypt HTTP

[eightball]

The "Red Scare" that preceded that alliance of convenience suggests it was more than a mere change of social mores.

Nothing's "broken"

[prescor]

Because the people who pay for everything don't "see" a problem. From the uneducated user's perspective, everything works "the same" whether or not it's encrypted. They don't see how anything is "broken" so why should they pay $$$ in the form of certs and staff time to upgrade (i.e., "fix") things?

(That's a possible explanation, not an excuse.)

Not needed

[DerPflanz]

I think it is simply not needed. Why would you put effort in encrypting a public website, or your e-mails to your grandmother to feed your cat while you're away.

Risk = damage x probability. Probability (sniffing email/web traffic) is extremely low on most data, as is damage. I think logins should be encrypted, but not (public) data.

Re:Not needed

[sqlrob]

your e-mails to your grandmother to feed your cat while you're away.

Party at DerPflanz, he's going to be away, easy to tell since the e-mail at the wireless point wasn't encrypted.

Nothing

[Anonymous Coward]

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.

maybe not apathy, nor ignorace

[AverageJoe8686]

Maybe it's more of an issue of ready availability and accessibility. Plus (I think) some businesses may think that it's an unwarranted cost which should only be used for money transactions or whatever. But then again I'm talking outta my arse here with no previous knowledge.

Same old Same old

[killmenow]

It's the same thing holding back lots of things: greed. Microsoft would standardized on e-mail encryption support in Exchange/Outlook if it were THEIR "standard" that either locked users in or locked other providers out. So would Apple and damn near every other company out there.

Lots of encryption is in place where companies stand to lose money (eg., DRM, banking, etc.) But where they stand to lose money DUE to encryption, it's not widespread...imagine that. If the security of your data isn't going to lose (or make) a company money, the people running that company don't care a whole lot about the security of your data.

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.

Re:I'll tell you what it is...

[amorsen]

Modern packet sniffers support IPSEC. Getting the keys out can be fun, but not all that difficult on e.g. Linux. Keeping up with the key changes adds a bit of fun too.

Re:I'll tell you what it is...

[Anonymous Coward]

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

. . . wireshark

Re:I'll tell you what it is...

[GWBasic]

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

It's called SSL, and you can bolt it on to any TCP-based application by setting up STunnel. The problem is that the "man in the middle attack" means that you need to jump through a bunch of hoops in order to prevent your ISP from decrypting and then re-crypting your traffic.

Re:I'll tell you what it is...

[Anonymous Coward]

if you can't prove that you're delivering packets reliably without knowing what's in them, then i recommend you look up the word "packet" again

Apathy

[maino82]

I know at my company a lot of it is apathy. We have an unencrypted FTP site where clients can upload/download stuff at their leisure. It's not sensitive material, so no one really cares if something happens to it or if someone gets hold of what's up there. Probably not the best attitude, but if the higher ups don't concern themselves with it, I don't concern myself with it too much either. That being said, for internal stuff and for access to project files from offsite, I did set up an SSH account on a segregated virtual machine that we can gain access to via SFTP. I also gave out separate keys for each individual in our organization. If a key becomes compromised I can simply issue a new one to the key holder without having to inconvenience everyone else. Still probably not ideal (I'm not a security expert by any stretch of the imagination), but better than nothing.

Key Management is hard

[Anonymous Coward]

Both technically and administratively. I've lost count of the number of 'Public Key Certificate Expired' warnings I've had over the years. Also doing crypto slows down servers - the cpu hit on web servers by using https is significant so many only use https for the bits of transactions that really need it. I just wonder what hit Google took by encrypting by default all Gmail sessions.

Encryption isn't free

[raju1kabir]

Most websites are still using unencrypted HTTP

Without dedicated hardware, https is an incredible performance drain on web servers. And even the dedicated hardware at the data centre won't help the client side. Not to mention the caching rules which mean much more data traffic.

For most web sites, I see no reason to use encryption.

Re:Encryption isn't free

[louzerr]

While I agree most sites probably don't need encryption, I don't see why you'd need dedicated hardware, or why it would be an incredible performance drain. Even client-side, it shouldn't be too difficult of a task (unless you're decrypting War and Peace in a single download).

That encryption is a performance drain is a myth created by hardware vendors wanting to sell you more hardware.

Re:Encryption isn't free

[Nerdfest]

To encrypt all traffic when running your web servers on an IBM mainframe costs _many_ millions of dollars a year. In cases like this, and when you're already near capacity on your hardware, encryption applicances are a great idea (they make debugging easier as well).

Re:Encryption isn't free

[raju1kabir]

That encryption is a performance drain is a myth created by hardware vendors wanting to sell you more hardware.

Do you run any web servers? You should be able to see this for yourself.

On relatively decent hardware I push out about 60% as many pages per second with SSL. Much of this is due to the huge overhead on session setup. With separate front-ends for SSL I can keep this from tying up slots on my content generation servers.

Re:Encryption isn't free

[acidblood]

Eh, go run an `openssl speed rsa' benchmark and see what kinds of results you get.

In my MacBook with a Core 2 Duo 2.4 GHz CPU, I get 30 RSA-2048 private-key operations per second, and 1042 public-key operations per second. One of these operations is used on every SSL handshake, not sure which of the two, so I can't really say whether performance is only `really bad' or `eye-poppingly awful'. Sure the performance drain would be a myth if we only used symmetric encryption, but key exchanges can only take place on an insecure channel if public-key encryption is used.

Performance on the client is irrelevant, it doesn't have to perform hundreds if not thousands of encryptions per second like the server does.

Re:Encryption isn't free

[OrangeCatholic]

Then don't use envelopes. Just send all your mail as postcards.

After all, it takes easily twice as long to open an envelope as it does to flip over a postcard and read it. And it costs more.

Funny that 99% of personal mail is in an envelope. I feel like we've tackled this problem before. Does an envelope serve a purpose other than security?

Meanwhile, we've lowered the cost of sending a letter from 42 cents to 0.01 cents by using email, and you're saying that cpu cycles cost too much? Dude, how did you ever afford stamps?

Re:Encryption isn't free

[yabos]

The session setup of SSL is the huge bottleneck. Symmetric encryption, while more expensive than not encrypting, is still pretty fast and is what is used for all of the data transfer over SSL.

Re:Encryption isn't free

[Anonymous Coward]

web encryption doesn't really slow down anything that is actually deployed on the client side these days. Unless you count proxies but the true client side would be better off without proxies anyway.

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

[Pascal Sartoretti]

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.

I am looking forward for OpenBSD to drop IPv4 use only IPv6...

Re:Inertia

[Anonymous Coward]

So why didn't you setup a proxy for the imaging server and serve them up yourself via HTTPS?

Re:Inertia

[gbutler69]

So why didn't you setup a proxy for the imaging server and serve them up yourself via HTTPS?

Already answered...

Since the group that served up images didn't care at all about encryption and wouldn't budge, the initiative was scrapped.

Comment removed

[account_deleted]

Comment removed based on user account deletion

first question: does it *need* encrypting

[Anonymous Coward]

"Most websites are still using unencrypted HTTP"

that's cause most websites aren't serving up any content that needs encrypting. If you were only looking at banks etc, then maybe I'd worry.
Encrypting lolcats is just a waste of cpu cycles.

As for email, I only use my own mailserver or gmail these days, both of which are using ssl encrypted imap... If your emails contain sensitive information etc, you probably shouldn't be using hotmail etc :p

Invisible threat

[famebait]

Suppliers give priority to what their customers nag about, and they nag about the problems they see and feel every day. Only those who get attacked and discover it see the threat of unencrypted traffic.

Potential problems

[Xamusk]

Because if anything goes wrong, like forgetting the password or corruption on a single byte, can make your whole data unusable

it's all about perception

[cybernga]

since most people consider their daily transactions ( FTP , mail , what-have-you ) safe, there is no need to go for anything more even if the IT staff understands the risks, any attempt to actually implement something will cause a stone-throwing for "breaking something that was working just fine" even if the downtime is minimal.

The same reason router passwords are Admin.

[GiveBenADollar]

People are lazy. I know I am! If It doesn't need encryption, why encrypt it? Then again I have the root password on my linux box set to a single character, so maybe I'm too lazy.

Re:The same reason router passwords are Admin.

[Ltap]

Thanks for the info, it's 20 chars now. I, uh, "improved" it for you.

Re:The same reason router passwords are Admin.

[GiveBenADollar]

Thanks for the info, I was wondering why my media PC recorded Brokeback Mountain and then started on a Queer Eye marathon.

Re:The same reason router passwords are Admin.

[Ltap]

No, I think that was you.

There are a number of problems

[cdrguru]

First big problem is you simply cannot send encrypted email to someone without a prior relationship. They aren't going to "get it" and they aren't going to be bothered to figure out why they can't read your email - just delete it.

The second problem is that if you want to be seen doing something "real", you need to spend some money on a "real" certificate. At a corporate level it might seem to make sense to have a corporate level certificate that then signs individual certificates. But this doesn't seem to be "real" enough.

Finally, most people understand that email is insecure and unreliable. They get a few Viagra ads every day and this reinforces the idea that it is insecure. They call people to make sure their email went through - because email is unreliable. Encryption would be another layer of trouble on top of all that insecurity and unreliability for no apparent benefit.

Re:There are a number of problems

[Grizzled Old Scout]

Finally, most people understand that email is insecure and unreliable

I disagree on that latter point. People aren't surprised when their messages aren't sent or received, but they do expect/think/believe that the messages they do have can be seen by them and them alone. Next time you talk e-mail with a less-knowledgeable type, tell them that their e-mail can be read by anyone, anywhere, anytime. Guarantee their reaction will be more of shock than of understanding.

This is even true of Gmail.

Re:There are a number of problems

[muckracer]

> tell them that their e-mail can be read by anyone, anywhere, anytime.
> Guarantee their reaction will be more of shock than of understanding.

Actually it'll be denial: "I don't care if anyone reads what I write". Which, of course, is bullshit.

Re:There are a number of problems

[Abcd1234]

First big problem is you simply cannot send encrypted email to someone without a prior relationship.

What? Every email client I've come across will happily use the standard keyservers (like MIT's) for retrieving public keys. No prior relationship required. The person just needs to publish their key on one of those servers, an operation which is incredibly easy (and automated by some key management software, such as Seahorse on Ubuntu).

The second problem is that if you want to be seen doing something "real", you need to spend some money on a "real" certificate.

BS. Are you saying PGP isn't "real"?

Encryption would be another layer of trouble on top of all that insecurity and unreliability for no apparent benefit.

No, encryption would be a layer which would *remove* the insecurity and unreliability. If everyone signed their emails, it would be trivial to have the server filter out emails that don't have valid signatures.

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

Re:It's simple.

[Low Ranked Craig]

In this context pain generally equals cost, but pain consists of disgruntled customers, bad PR and legal issues as opposed to the straight cost of implementing the solution.

Anyway, I thought that's what I said?

Re:It's simple.

[Anonymous Coward]

If it's a win/lose competitive race, then any way to lose is is bad as any other. If encryption slows you down a little, then even if getting hacked slows you down severely, people will chance getting hacked even the expected value in speed of encryption + not getting hacked is higher than the expected value in speed of not encrypting with a small chance of gettnig hacked. If it is only possible to win by not encrypting and being lucky enough not to get hacked, then that strategy will be chosen by all, even if it leads to the downfall of most who partake of it.

What good is encryption?

[Anonymous Coward]

If Chloe can break it at CTU in a couple of keystrokes? DAMN IT!!

Seriously?

[EXMSFT]

Weeks after Google, a technology leader gets hacked by having ancient versions of IE 6 on their desktops, and you're asking why encryption isn't everywhere? Same reason IPv6 isn't everywhere, VOIP isn't everywhere, the current spam-friendly email protocols we've been living with for decades haven't been replaced with authenticated sender-based protocols, and why blacklist-based antivirus hasn't been replaced by a less "lossy" model of security. Why? Because doing nothing costs nothing. Doing something costs something - and if you can't explicitly explain why doing something more than the current "bare minimum" MUST be done, quantify the costs of doing vs. not doing it (and have the latter exceed the former) and/or end-of-life the current methodologies, then things just don't happen in the low-cost/low-budget world of IT.

Re:Seriously?

[SanityInAnarchy]

I was with you up till here:

the current spam-friendly email protocols we've been living with for decades haven't been replaced with authenticated sender-based protocols,

Are you telling me there's a spam-hostile email protocol possible? How does it do with The Form?

blacklist-based antivirus hasn't been replaced by a less "lossy" model of security.

Actually, the simple replacement for all antivirus is a savvy user. I don't think that's inertia, though, I think that's a weird social block we have -- we want to make this an IT problem instead of an end-user problem, because if it was an end-user problem, we'd have to educate all the end-users, and quite possibly lose a lot of otherwise-productive people who refuse to learn tech.

Re:Seriously?

[OrangeCatholic]

Actually I think people do nothing because keeping the internet the same, gets more people online. It's over 15 years since I got online and it's only in the past year that people know what "Tivo" is. Hell, if I drove in to Kansas I bet they still don't. And they sure as hell don't have Tivo in Juarez, Mexico.

So at what point will there be a critical mass of people online where the internet can evolve again? Well, we've already seen one evolution - web forums and facebook. And both of them are stunningly stupid. The second evolution is YouTube and Hulu. Err. I'll take Hulu over Facebook, but these are more likely to kill television than create something superior.

I don't think IT is low-cost/low-budget. More like low standards. And it will only get worse with each new 14-year-old girl or Latina housewife who gets online. They offer nothing from an IT perspective except end-user testing. Which is valuable but, they can't build squat themselves.

Re:Seriously?

[EXMSFT]

You're exactly right. Unfortunately.

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.

Re:What's the problem?

[cpghost]

What's the point of buying one-time pads generated from an untrusted third party (even if it were trusted, is it TEMPEST-proof?), esp. when those pads are being shipped via an untrusted carrier, and possibly crossing international boundaries where they could be copied by customs, TSA and other agents?

Re:What's the problem?

[maxume]

What are you talking about?

Re:What's the problem?

[cpghost]

About your idea of distributing one-time pads on DVDs?

Re:What's the problem?

[maxume]

The ones I would make myself and hand deliver to the people I spoke of?

(I'm not just making that up...)

Re:What's the problem?

[HeckRuler]

So, presuming you handed one of the DVDs to you mother in person (otherwise I'd ask who you handed said DVD to in order for it to arrive at your mother's), then there is now a DVD located in the house of little old lady which is vital to proving a comment on slashdot wrong. Gentlemen, my mission is clear, I must be off...

Re:What's the problem?

[Anonymous Coward]

Yes, but you still have to worry about a MitM attack where somebody at the post office copies your DVDs.

If we could just track down and eliminate Mallory, now that would make a difference!

The costs overweight the benefits.

[kikito]

The same happens with telephone conversations, or radio emissions. Except in some specific cases, it is just not worth the hassle.

Re:The costs overweight the benefits.

[Rockoon]

ding!

You win. We just don't care enough, and this fact is not something that can be changed, because we REALLY don't care in almost every case. My conversations on the phone are generally private, but not worthy of "secret" status, and thats all there is to it.

The same is true for what I do on the Internet. In almost every case privacy is preferred but its not "secret worthy."

Ease of use and implementation...

[foxtyke]

That's where the hold up is in my opinion.

Secure e-mail via HTTPS/SSL is all but completely standard service throughout most providers, it's passive and in most cases proffered as the default information from a service provider.

Secure FTP via any means is a little touch and go, most hosting providers offer it in differing flavors but it is not well standardized in terms of FTP client support and each have their own name for the same methods.

Secure HTTP by default on sites, not really available for the market en masse due to cost of certificates and limitations of some of those cheap certificates which is why many do not offer it and with shared-services, your certificate is pretty worthless unless you opt for a dedicated IP in most plans/services.

PGP/GPG, now here's a real stick in the mud, this needs to be supported by all clients and implemented equally wherein there is nary a thought to clicking send (eg. what passphrase did I use for this one?)

DNSSEC, much like PGP/GPG, without wide adoption through large registrars and more information from those registrars on its uses, benefits and general reason for existence, it won't be used by many.

Performance overhead vs. value of the information

[Cimexus]

For me, it's mostly a tradeoff between the value of the information and the extra work/performance overheads involved in using encryption.

I usually don't bother encrypting my email because it's mostly mundane stuff, and frankly there's more of a threat from the owner of the email server reading my stuff than there is from a MITM attack. Also, getting and using a cert is a bit of extra work.

But if I do need to send sensitive information via email, I will use encryption. Generally by putting that sensitive information in an attachment, and encrypting the attachment using AxCrypt or something similar (128 bit AES which is pretty decent for anything I'd be communicating).

I upload and download files from a web server regularly, that permits standard FTP connections as well as SFTP and SCP. But I generally just use FTP because a) the stuff is usually mundane; and b) FTP maxes out my connection, whereas SCP/SFTP to the same server seems to bottleneck at 60 kB/s upstream for some reason - seems like quite a large performance overhead!

too much effort

[mrphoton]

I wish Thunderbird of evolution had some type of automated system for encryption, where you tagged your public key to the bottom of every e-mail. When an in coming e-mail was detected with a key at the bottom all replys were automatically encrypted. I think the problem with encryption at the moment is that people have to think about it so it does not happen.

Re:too much effort

[SanityInAnarchy]

I wish Thunderbird of evolution had some type of automated system for encryption, where you tagged your public key to the bottom of every e-mail.

What? Thunderbird has had this for awhile, and so has KMail, and really any decent PGP-supporting mail client. It's not at the bottom anymore, though -- the preferred way is as an attachment.

When an in coming e-mail was detected with a key at the bottom all replys were automatically encrypted.

I suspect you can configure it this way, but it's fairly pointless -- it buys you very little unless you can verify that the key in question actually belongs to that user.

Re:too much effort

[Cormacus]

I've actually had trouble with Thunderbird doing automatic (encryption-like) things with email. And the trouble didn't stem from Thunderbird, but rather from my recipients. They noticed that emails coming from me suddenly had an extra icon by them (Thunderbird was signing all my outgoing messages) and they flipped out. "Why is that icon there?" "OMGWTFBBQ?!" So unfortunately even doing automated stuff like that will still run into the under-informed user problem.

Re:too much effort

[Anonymous Coward]

Got the OpenPGP (Enigmail) add-on for Thunderbird.

For the replies in encrypted:
Menu Bar -> OpenPGP -> Preferences -> Advanced -> Encrypt Replies to Encrypted Message

Option to auto-attach your key however when doing PGP.
Account Settings -> OpenPGP Security, Advanced Button, Attach my public key to messages.
For me it wasn't working with the Auto-select email for key to use method, but that could be because I don't have any keys set up.

Now for S/MIME method, I see less options, and as far as I can tell the only way to set them are in the Account Settings Dialog for the account. Those options appear to be which cert to use to sign and encrypt the messages.
Hmm, looking at some old random messages I sent to myself signed with S/MIME(random tests), it seems as it auto-attaches the public key. View Source shows an attachment of 'Content-Type: application/x-pkcs7-signature; name="smime.p7s"'
But I don't remember if it asked me to reply encrypted when the message itself was encrypted.

Encryption is demanding

[Alif]

Encryption is pretty demanding on hardware. A normal webserver without a cryptographic accelerator can serve say 100x more webpages unencrypted then with a full HTTPS encryption.

Re:Encryption is demanding

[Anonymous Coward]

A normal webserver without a cryptographic accelerator can serve say 100x more webpages unencrypted then with a full HTTPS encryption.

I suspect there's some hyperbole somewhere here. A previous poster said that his web server could handle "only" 60% of the load, with encryption. So, to give the benefit of the doubt, that would be "2x more webpages unencrypted". That's 1/50 the hit that you're claiming.

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.

Re:One Word:

[XXeR]

Verisign. Because of the ridiculous cost of THEIR certificates, and that browsers don't seem to properly recognize any certs but ones from Verisign.

Take a look at Entrust. I've switched all my certs to them as they seem to be supported by just as many browsers as Verisign -- and are much cheaper.

Ethan Hunt

[holophrastic]

Outside of our industry of computers and internets, security is handled wiht a simple motto -- secure what needs securing. With the knowledge that Ethan Hunt will always be able to break in, the question is not "what is insecure" but "what is being stolen". You don't need to secure something that no one wants.

Your home is easy to break into. Maybe you have a lock. Maybe you have a dead-bolt. Your locks can be carded, your dead-bolt can be picked.

You wouldn't want real security at your front door, because you'd be trapped outside more often than an actual burgler.

The same is true of computer security. If no one is breaking in, why would you want to slow everything down. My FTP traffic isn't that important. It's just code, and very few people think they want it.

Re:Ethan Hunt

[SanityInAnarchy]

I think the primary difference is that outside of computers and internets, security is much harder to do. For example:

Your home is easy to break into. Maybe you have a lock. Maybe you have a dead-bolt. Your locks can be carded, your dead-bolt can be picked.

Replacing those with Real Security -- even replacing a lock with a deadbolt -- requires physically dismantling part of the door, at a minimum. And you have to do that for every door you want secured that way.

Contrast with, say, replacing unencrypted wireless with WPA-encrypted wireless. Takes about two minutes with a web browser.

You wouldn't want real security at your front door, because you'd be trapped outside more often than an actual burgler.

Quite possible, but again, the implications are different. For example, take said WPA-encrypted wireless -- worst case, you have to plug a cable in physically so you can get to the admin panel and recover/reset the password. If that fails, you push the big reset button. If that still fails, you buy a new router, at a cost of maybe $30 -- and in the meantime, you can plug in physically.

Yet it still provides plenty of security, given you're probably not going to leave unattended guests around the wireless router long enough to do any damage -- this is intended more to keep your neighbors from leeching your internet.

I think the problem with your analogy is that unencrypted traffic isn't like a front door with a lock. It's like a front door without a lock. Maybe your lock can be carded, maybe your deadbolt can be picked, but would you want to actually leave your house unlocked all day?

If no one is breaking in, why would you want to slow everything down.

Blowfish still hasn't been broken, and it's fast on a Pentium -- 18 clock cycles per byte -- so on a 1 ghz CPU, that's 55 megabytes per second -- that's bytes, so more like 400-500 megabits. And that's with a hypothetical 1 ghz Pentium -- modern CPUs are both faster and more efficient, and some machines have dedicated crypto hardware.

I don't care what you're using now, but AES 256 will run just fine on it -- you will not be slowing anything down. Especially if you're talking about this:

My FTP traffic isn't that important. It's just code, and very few people think they want it.

Yeah, the amount of data you're transferring, and the speeds you're transferring it at, aren't going to be slowing anything down. But that aside...

This is probably the most common mistake people make with security -- assuming that they're safe because they're not a target, and because even if they have something semi-valuable, no human would waste their time with it.

Let me guess -- you're FTP-ing some PHP files, something like that? Maybe to a webserver? Let's start by assuming it's static HTML.

Suppose I'm a malware author. I want to spread my malware to as many target PCs as I can. That means I need it hosted in as many places as I can. That means there is an incentive (albeit a small one) to pwn your website.

It's not terribly difficult for a script to intercept your FTP traffic, grab your password (which very likely is sent in the clear) or simply hijack your session, then go looking for something like index.html to infect. It doesn't have to completely replace it, just hide an exploit somewhere on that page. Suddenly, everyone visiting your homepage is getting infected with my malware.

And let's suppose it is PHP. Even better -- now I can have every hit to your website send an email. Your webserver just became a zombie for my spamming botnet.

Finally, let's suppose my script can't figure out what to do with it -- still, if you've got a few gigabytes worth of storage, I could use it to store pirated movies, warez, etc.

And all of this can be automated, so it doesn't matter how small a target you think you are. You might not be worth my time, but you sure a

Re:Ethan Hunt

[holophrastic]

It's never that easy. It's that easy to turn on and to turn off, but in the real business case, encryption causes logistics nightmares.

Certainly, in my home, with my router, and my laptop, and me, all it does is slow down the wireless traffic ever so slightly, and increase my cpu usage ever so slightly.

But when my friend comes over, he can't just use my network. If it's my grandmother, it's a problem. And when it's my business, and my client comes by, I'd like it to just work -- without him having to configure his device at all.

And when my supplier comes by, and is in my drive-way, and left something at his office, and he wants to quickly grab it before meeting with me, I want him to find my connection just available, how conveniently.

And in the real business world, where the router is hidden and secured, and it can't just be reset, and it's under load, and everything else, then it winds up being a $500 piece of equipment, with a person amnaging it, and it's just all more complicated.

You asked if I'd leave my home unlocked all day. My home is rather involved, and is everything I and my businesses own. Not everything inside is mine, so I secure it more than I otherwise would.

But I drive a convertible sportscar -- a mazda mx-5. And yeah, on a nice day, I'll park it at a mall, and I'll leave the roof open. Nothing stops anyone from jumping into the car, damaging it, throwing coffee, accidentally or maliciously, or hot-wiring it and driving it away.

But really, it's just my car. I can buy a new one. At most it's $41'244.24 to replace. And I don't often leave it in really dangerous areas. So I'd rather the pleasure and fun of leaving it open than the paranoia of closing it.

I do, however, worry about the birds!

Re:Ethan Hunt

[SanityInAnarchy]

But when my friend comes over, he can't just use my network.

So you tell him the password. He's a friend, after all.

If it's my grandmother, it's a problem.

She's that much more likely to let you actually type it into her computer.

And when it's my business, and my client comes by, I'd like it to just work -- without him having to configure his device at all.

So it'll take an extra few seconds. I realize you want to baby your client all you can, but I think he can handle typing "h0mest4r2k" or whatever your password is.

The other solution is somewhat more complex -- set up two networks, one encrypted, one not. Then you can do things like throttle the unencrypted network, block outbound port 25, etc...

And in the real business world, where the router is hidden and secured, and it can't just be reset, and it's under load, and everything else, then it winds up being a $500 piece of equipment, with a person amnaging it, and it's just all more complicated.

Actually, that makes it simpler. There's a person managing it. It's that person's job to make it do what you say. You say, "Encrypt it, please." They say, "Ok." What goes on after that is something you're not really even involved in, and however complicated, it's also something this person should be very good at.

But I drive a convertible sportscar -- a mazda mx-5. And yeah, on a nice day, I'll park it at a mall, and I'll leave the roof open. Nothing stops anyone from jumping into the car, damaging it, throwing coffee, accidentally or maliciously, or hot-wiring it and driving it away.

Key word there. Would you leave the key in the car at the mall?

Re:Ethan Hunt

[Sloppy]

If no one is breaking in, why would you want to slow everything down.

The problem with unencrypted communications, is that you never know if someone is breaking in. You can't wait until there's a detected incident, because in the unlikely event that you ever discover someone has been listening, that was the 1000th time that someone listened. By the time someone exploits their intel on you, many parties may already have a shitload of intel on you.

The other problem is that the question of what needs securing vs what doesn't need securing, does not usually cleanly break down along application lines. Your ftp server might always be not-sensitive stuff, but what about web and email?

An email to your friend that says "Iron Maiden rulez! Up the irons!" isn't sensitive, but "We're going to the Iron Maiden show on Saturday so I hope nobody reads this and takes advantage of knowing when we won't be home, because that would be the perfect time to burgle us" is. But if you're going to encrypt the second message, then your email client needs to be encrypting things. And you probably want it to be trying to do that whenever it can, without the user having to think about which which messages are sensitive and which aren't. If they have to think, they will get it wrong, because it turns out the first message is sensitive too, since it lets an attacker profile who might have undefended homes on the night that Iron Maiden is in town.

You wouldn't want real security at your front door, because you'd be trapped outside more often than an actual burgler.

I think that's a bad analogy, though. If you remember your passphrase, stuff just works. When the day comes that someone tries to decrypt and turns out to not have the key, that person (unlike a person trying to enter a house without a key) probably really isn't you.

Re:Ethan Hunt

[holophrastic]

they probably aren't me, but they likely are someone of whom I'd approve. And for 99% of my communications, I don't care if someone listens. There really isn't anything of any importance -- which is why no one's listening. It simply has no value to them at that capacity.

There certainly are many things that I would, and do, encrypt. But there are indeed sacrifices made for that encryption. And those sacrifices are often not worth the benefits.

Re:Ethan Hunt

[muckracer]

> And for 99% of my communications, I don't care if someone listens.
> There really isn't anything of any importance -- which is why no
> one's listening. It simply has no value to them at that capacity.

Nice attempt at rationalization. Fact is, that you DO NOT decide
what's valuable to someone else nor whether somebody will be
listening.

Re:Ethan Hunt

[holophrastic]

I decide what's valuable to me, that it might need to be protected. Someone else can find value in anything. That's got nothing to do with me -- I'm not interested in hording my garbage.

But all that said, still no one's listening to most of my stuff. Furthermore, most of my stuff is incomprehensible to them.

Since when is no-encryption a problem?

[AbbeyRoad]

Simply put, the bulk of security problems are not solved by encryption.

In fact encryption and authentication often create more problems than they solve. Corporations are asking for many passwords where they aren't needed, certificates create admin overhead, and encryption is more difficult to set up and get working in-time-to-market than if there were no encryption.

One doesn't invest in something "because it sounds like -- real cool, man". Rather, one must begin with a problem and think creatively to solve that problem. ...and encryption is just one of the available tools.

Also, you can't take the protocols SSL, DNSSEC, SFTP, IPSEC and pool them into one bucket and call it "encryption". Each are separate solutions to separate problems, and indeed will usually be only one component within the solution.

-paul

Re:And pushing it would give false sense of securi

[aGuyNamedJoe]

I know -- why don't we all go to travelocity and check on flights to Pakistan, and then start encrypting all our email?

Or maybe someone could develop a web page that will set us up for encrypted email, and check for flights to Pakistan behind the scenes the first time, first...

Then we might have an interesting test of the security of encryption...

Isn't it obvious? Money

[Etylowy]

Certificates, bandwidth, cpu power - it all ain't free.
Encryption costs: the obvious - signed certificates aren't free, but also https has higher bandwidth cost than http, encrypting data is CPU intensive - it all sums up.

IMHO encryption will be always limited to the bare minimum - where money and/or sensitive data is involved - and that's fine: why the hell would I want to encrypt anything else?

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?

Re:Why?

[gregarican]

I wouldn't either. Although for my company's e-commerce website, our Citrix ICA web client, Outlook Web Access, etc. I can throw down $30 a year for a cheaper GoDaddy SSL cert for each host.

There are always cheaper alternatives that take cost out of the equation. Like a few years ago I looked at why we were spending $800 a year for a commerical PGP license for transmitting SFTP banking batch transmissions. Get GNU PGP for free and have basically the same security!

Re:Why?

[Anonymous Coward]

You use GOTO?!

Re:Why?

[Mr. Freeman]

No one is saying you should.

The question specifically mentions businesses and things that need to be secure (like email, banking, etc.). Clearly, your website does not need to be secure and is thus not at all related to the topic at hand.

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.

[sqlrob]

In the enterprise, it's a near zero cost because they can set up an internal CA and churn out certs. Policy can push the root cert into the clients.

Re:More direct costs.

[Anonymous Coward]

Not to mention a self signed certificate brings out some pretty frightening prompts (I'm looking at you Firefox)

Re:More direct costs.

[slim]

You think setting up a CA is cheap?

Software is cheap. Hardware is cheap. Process is expensive.

Any cheap CA would only provide the dangerous illusion of security.

Re:More direct costs.

[Anonymous Coward]

You think setting up a CA is cheap?

Software is cheap. Hardware is cheap. Process is expensive.

Any cheap CA would only provide the dangerous illusion of security.

Settin up a CA is cheap and secure, especially when it is for internal only use.

Re:More direct costs.

[SanityInAnarchy]

That's a Good Thing.

That said, sqlrob makes a good point. If you're going to do a self-signed cert in a corporate environment, you probably can push it out to clients easily enough.

Re:More direct costs.

[TemporalBeing]

Unless you need someone else to recognize it as valid. Then you have a high cost to getting your CA setup.

Yes, it's trivial to setup an unauthenticated CA. But most will want an authenticated CA.

Also, I wouldn't sign my life away for a PPK - been at one company that wanted that; too much liability for me. (They company absolves all responsibility for the PPK, all of which would have been assigned to me.)

Re:More direct costs.

[tinkerghost]

It's fairly trivial to get your corporate CA recognized. It runs just a couple of hundred to get a root cert from someone who is in most CA lists. As long as your cert has the leading certs that trace back, it'll be recognized.

Re:More direct costs.

[slim]

How are you protecting your CA root private key?

One recommended practice is to keep the CA off the network under lock and key and use sneakernet to get the certificate requests in and the signed certificates out.

So now that's somebody's job - being that sneakernet. Someone trustworthy. Maybe you should require two keyholders present in order to issue a certificate. And they should keep records, for auditability. Then you'll need some sort of process for if a keyholder falls ill.

Think all this expensive process is overkill? Then you don't actually want a secure CA. You just want the warm and fuzzy of seeing the padlock icon in Firefox. I agree that's cheap and easy to achieve.

Re:More direct costs.

[Intron]

That's a Good Thing.

No it isn't. In what way is a self-signed cert on https less secure than an http connection?

Re:More direct costs.

[TheRaven64]

A self-signed certificate is fine if the certificate is distributed out of band. For corporate use, you generate a certificate, sign another certificate with it, and then put the original on a USB key in a safe. Then you put the public key for the first certificate in the trusted CAs list for the image that you use when you install your OS of choice on new machines. Then you use the second certificate to sign the certificates that you use for your Intranet and your corporate mail servers. It still costs CPU time (although not a huge amount), but it doesn't cost very much.

Re:More direct costs.

[TerranFury]

a self-signed certificate is barely better than raw http.

I wouldn't go that far. It guarantees that nobody can eavesdrop on the conversation you're having. You just might not be talking to the person you think you're talking to. That said, once you've stored the cert, it does guarantee that you're talking to the same person you talked to last time.

For file servers, I think this is fine most of the time.

I mean, compare this to SSH. How do you know you're talking to the server you think you're talking to? ~/.ssh/known_hosts . Which behaves exactly as the above.

Re:More direct costs.

[Abalamahalamatandra]

Trivial? You've obviously never done it.

I did a project like this - it required an offline root CA that stored its keys in a HSM (Hardware Security Module) infrastructure that ran into the $60,000+ range and required multiple-party control via "M of N" smartcards issued to multiple staff members. Same for the online issuing CA, it couldn't even be started without multiple people with multiple smartcards.

It also required development, acceptance and auditing of a Certificate Practice Statement (CPS) for both the offline root CA and the online issuing CA. Yearly auditing by an outside party.

And then, for all that trouble, you still pay a per-cert fee to the signing authority for the certs you issue.

Hardly "trivial" - try months of consulting time and a budget of $150k plus per-cert and auditing fees ongoing.

Re:More direct costs.

[N!k0N]

That's a Good Thing.

No it isn't. In what way is a self-signed cert on https less secure than an http connection?

It's not a bad thing in its own right; but if you train your non-tech-savvy corporate users (ie everyone) that the alert in $BROWSER is ignorable they use that ideology every time $BROWSER screams about a bad cert. Leaves you open for all kinds of other trouble if an internal site somehow gets re-directed to the outside world, and the user just clicks through because they know that the site is "safe" because the alert always pops up.

The idea that a user would implicitly trust a site (even with a bad cert) because the admins told them it's a non-issue is what makes it so.

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.

Re:More direct costs.

[SanityInAnarchy]

In what way is a self-signed cert on https less secure than an http connection?

In the sense that it gives a false sense of security -- you see 'https', you see the padlock, you think, "Oh, I'm safe."

Also in the sense that most reputable websites use real certificates, not self-signed certificates. So, for example, if my first visit to www.paypal.com shows a self-signed certificate, my browser absolutely should be slamming on the brakes.

Now, there probably could be some better UI, a way to show that this is a self-signed certificate (and thus dangerous), but that it's still more secure than plaintext.

Re:More direct costs.

[SanityInAnarchy]

It guarantees that nobody can eavesdrop on the conversation you're having. You just might not be talking to the person you think you're talking to.

On a wireless connection, this is pretty worthless, because everyone within range who wants to could likely MITM you, or each other. You could be "talking to" anyone in the room -- thus, anyone within range can eavesdrop on you.

This is more or less the same problem you have with passive sniffing, and there isn't really a practical difference, other than that it's safe once the cert is stored. On the other hand, if you store the wrong cert in the first place...

I mean, compare this to SSH. How do you know you're talking to the server you think you're talking to? ~/.ssh/known_hosts . Which behaves exactly as the above.

True, but in most cases, my first SSH connection to a machine is over a trusted medium, like a crossover cable or at least a local network. I then have it in known_hosts.

Note also that if the key ever changes, SSH gives you HUGE GIANT WARNINGS and refuses to connect, much like Firefox.

Re:More direct costs.

[TerranFury]

True, but in most cases, my first SSH connection to a machine is over a trusted medium, like a crossover cable or at least a local network. I then have it in known_hosts.

That's more-or-less the assumption that I'm making about TLS certs. Or at the very least, if it keeps changing you know retrospectively that you need to change your password.

Re:More direct costs.

[swillden]

a self-signed certificate is barely better than raw http

I disagree. A self-signed certificate isn't as good as a certificate that verifies the identity of the server, but it's significantly better than raw http, especially if your browser keeps track of which self-signed certs come from which sites, and alerts you when the cert changes.

I think in this respect the behavior of current browsers with self-signed certificates is unfortunate. What I'd like to see is for the browser to silently accept self-signed certificates but not to show the "secure" lock icon. That should be reserved for sites with proper certificates, so that users don't think that they have a secure connection when they might be subject to a MITM attack. I'd also like to see browsers complain LOUDLY when a site that used to have one self-signed certificate (or proper certificate) suddenly starts providing another one. Particularly if the previous certificate isn't revoked or expired.

The security model of self-signed certificates would then be very similar to that of SSH server keys. The first time you SSH to a machine, you're asked if you want to connect, since this is an unknown key. Thereafter connections succeed silently, as long as the server continues providing the stored key. But if the server key changes, connections are ABORTED and you have to take specific corrective action before SSH will allow you to connect again. With that model, MITM attacks are possible, but only if the attacker gets in on the very first connection.

I think if our browsers handled it similarly, we could easily move to a model where HTTPS is the default. Eventually, we could "deprecate" raw HTTP, by having the browser provide a visual indication that this site is "unsecure" (meaning less secure than the norm).

Re:More direct costs.

[SanityInAnarchy]

encryption on the filesystem compared to HTTPS, which would be quite different depending on how it's implemented.

It is quite different. It's apparently initializing the session that's the bottleneck.

Now, I agree that it's a minimal cost, one which should be possible to make lower (even with HTTPS as implemented), but it's still not zero.

Re:More direct costs.

[shmlco]

"It also costs a nonzero amount in server CPU usage and/or dedicated hardware to do the crypto itself...."

I think the rule of thumb was that a server could handle ten HTTP requests for every HTTPS request. Therefore a popular web site (like Slashdot) might find its infrastructure costs increased significantly, with little added benefit. Could add dedicated SSL-enabled network cards, but those are fairly expensive too.

Re:More direct costs.

[arminw]

...see the padlock, you think, "Oh, I'm safe."...

I guess that could be rephrased: see the padlock, you think, "Oh, I'm safer." Having the padlock their is definitely better than not, don't you think? Nothing, including your life, is absolutely safe in this world.

PS I looked up the link in your sig. That is a rather impressive list of people. At least one of them I know was a Christian.

I am almost positively sure that nobody will know of any of these people 3000 or more years from now. Yet there are millions of people, right now, all over the earth, that are reading the words of this shepherd boy who later became king of Israel, written about 3000 years ago. Even today, you would probably find one or two orders of magnitude more people in this world, in all lands, on all continents, who know about that shepherd boy David, than about most of the people in that video.

If you want to, you can read God's opinion of that otherwise well-done video. The apostle Paul wrote it down for us about 20 centuries ago.
1Corinthians 1:19 - 1Corinthians 1:29

Re:More direct costs.

[EllisDees]

>In the sense that it gives a false sense of security -- you see 'https', you see the padlock, you think, "Oh, I'm safe."

Umm, no. If the cert is different from the last time you connected, you get a nasty error message - just like you would from any other site who's cert has changed.

Re:More direct costs.

[SanityInAnarchy]

I guess that could be rephrased: see the padlock, you think, "Oh, I'm safer." Having the padlock their is definitely better than not, don't you think?

Nope. If you were to not show them the padlock, they'd assume their data was vulnerable, which is correct. Give them a real cert and a proper padlock, and their data is much less vulnerable.

Nothing, including your life, is absolutely safe in this world.

I never said "absolutely". However, it reduces the number of things you have to trust by an enormous amount. Going from plaintext to self-signed just means someone has a narrower window to MITM you, but for that window, you still have to trust everyone on your local wifi, everyone on any non-switched network, any routers and wires between you and the server in question, your DNS server (and anyone in a position to spoof DNS packets), etc, etc.

Going from self-signed to properly signed means you now only have to trust the certificate authority, the website in question, and the fact that there aren't yet viable quantum computers.

At least one of them I know was a Christian.

Which one, if I may ask?

I am almost positively sure that nobody will know of any of these people 3000 or more years from now.

*sigh*

And a little less than two thousand years later, we know about Nero. Indeed, some Biblical scholars suspect that Nero is what is referred to as "The Beast", which makes sense in light of Jesus' statements about returning quickly, bringing the apocalypse within the lifetime of those present.

If you really want to have this discussion, bring evidence or a good argument. You've made this exact argument before, and I've countered it before, so frankly, it's boring.

If you want to, you can read God's opinion of that otherwise well-done video. The apostle Paul wrote it down for us about 20 centuries ago.

How do you know Paul got it from God? In particular, how do you know Paul's experience on the road to Damascus was anything other than dementia?

Of course, there's the demonstrably false proposition, also from scripture, that they are all fools, and I doubt you would seriously claim that they are all evil.

Re:More direct costs.

[Eil]

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

Well, the question was about encryption rather than trust. Trust is a whole different topic. Nobody has yet come up with a good trust model for the public Internet. The one that exists right now is next to worthless for two reasons: 1) Criminals who exploit novice Internet users never bother with using SSL on their phishing sites 2) greater than 99% of all Internet users who encounter an SSL certificate problem simply click "Okay, proceed" without bothering to understand what the warning is trying to tell them. In terms of trust alone, SSL on the public Internet is as bad or worse as any security theatre you'll find in an airport.

A self-signed certificate, however, gets you encryption without trust. That in itself is valuable to someone like me. It's incredibly unlikely that anyone would want to target me specifically to pose as my email/web server. I'm mainly concerned about preventing eavesdroppers from picking up the contents of my traffic by sniffing the wifi or compromising a router along the way. And if they did, the chances are pretty high that I would be trying to access my server using a client that already has the certificate saved, so I would likely be warned if the certificate changed in any way.

Finally, a lot of people fail to realize that there are plenty of situations where you can have both encryption and relative trust without needing the services of a public certificate authority. Anyone can set up their own CA and distribute the root certificate to all computers and devices that need them. This works fine for a corporate intranet or VPN, for example.

Re:More direct costs.

[SanityInAnarchy]

1) Criminals who exploit novice Internet users never bother with using SSL on their phishing sites

Novice users will screw up anyway. What's important is whether the system is usable by an experienced user.

2) greater than 99% of all Internet users who encounter an SSL certificate problem simply click "Okay, proceed" without bothering to understand what the warning is trying to tell them.

Which is why modern browsers make it so difficult and scary -- especially Firefox.

In terms of trust alone, SSL on the public Internet is as bad or worse as any security theatre you'll find in an airport.

Does this also apply if used properly? And if so, how?

A self-signed certificate, however, gets you encryption without trust. That in itself is valuable to someone like me. It's incredibly unlikely that anyone would want to target me specifically to pose as my email/web server. I'm mainly concerned about preventing eavesdroppers from picking up the contents of my traffic by sniffing the wifi or compromising a router along the way.

So tell me, why would someone target you specifically as an eavesdropper, but not as a MITM? It's trivial to do over wifi, even easier if they've compromised a router.

And if they did, the chances are pretty high that I would be trying to access my server using a client that already has the certificate saved, so I would likely be warned if the certificate changed in any way.

Several people have claimed this. I'm tempted to test it, to see if browsers are actually doing the right thing here...

Finally, a lot of people fail to realize that there are plenty of situations where you can have both encryption and relative trust without needing the services of a public certificate authority. Anyone can set up their own CA and distribute the root certificate to all computers and devices that need them.

Oh, I realize that, and that's fine -- if you've actually distributed them through secure channels. That also gets you around the big giant Firefox warning.

But if you're just connecting to some random forum... no. That goes double if it's something you actually care about in any way. Think of it this way -- properly signed certificates cost on the order of $20-30 per year, and require less than an hour of your time. So you're dealing either with a complete incompetent, or someone who can't afford to spend $30/year (and an hour of some admin's time) setting up a certificate.

So yes, self-signed certificates should send up giant red flags unless there's a very good reason to trust them -- like distributing and installing the CA yourself.

Re:More direct costs.

[arminw]

...Which one, if I may ask?...
Charles Schulz the creator of "Peanuts"

(....How do you know Paul got it from God?...)

How do you know he did not? Both the courts and historians generally ascribe truthfulness to witnesses and documents.

It is always up to the opposition to prove witnesses and documents to be false. You know the innocent until proven guilty thing. I don't have to prove that the statements in the Bible are true. Historians and the courts are on my side in that they assume truth. You, as the opposition has to prove falsehood. Saying that it doesn't make sense is not good enough. It is true, that generally people don't rise from the dead, but you have to prove that Jesus in particular did not.

(....we know about Nero....)
People may name their dogs Nero, but their sons have biblical names such as David, Peter, James, Joseph had many many more. You, and some other well-educated people like you know about Nero, but millions of others all around the world have never heard of him. They have however heard of David and how he killed Goliath. They also have heard about Jesus and Paul.

(...Paul's experience on the road to Damascus was anything other than dementia?....)
If it was, then Paul was not the only one hallucinating.

Act 9:7 And the men who journeyed with him stood speechless, indeed hearing a voice but seeing no one.

(....I doubt you would seriously claim that they are all evil....)
Of course they are not evil, but lost, like sheep in the wilderness. It is instructive that the Bible, both in the Old and New Testament compares people to sheep needing a shepherd. Your namesake in the Bible was a shepherd who knew what sheep are like. Jesus calls himself the good Shepherd.

This comparison of humans to the dumbest domestic animal we know of is not much to my liking either, but if you look at the sweep of human history, there is definitely something to that.

The stubborn persistence of religion, including atheism, speaks of the deep human need for significance and purpose. What would you call the curiously enduring belief of almost all of humanity in a dimension of existence beyond the here and now? Why do so many people WANT to believe in something or someone outside of themselves?

In line with the subject of this thread, people being sheep, also means there will never be complete computer security. Ease of use and security, are like so many things in life, a trade-off. The phenomenal success of social sites like Facebook testify to the fact that many people are more than willing to share some of their most intimate secrets with the world. Most people don't have very many deep dark secrets. That to me is the biggest reason why encryption has not become more common.

Re:More direct costs.

[SanityInAnarchy]

Charles Schulz the creator of "Peanuts"

"Was" being the operative term, then. A quote:

I do not go to church anymore... I guess you might say I've come around to secular humanism, an obligation I believe all humans have to others and the world we live in.

I suppose it's contestable -- after all, secular humanism doesn't strictly require atheism.

How do you know he did not?

I don't. The burden is on you to show that he did.

Both the courts and historians generally ascribe truthfulness to witnesses and documents.

We've discussed this, and I think I've provided very good reasons why this is a bad idea. If you wish, I can direct you to some point-by-point rebuttals of Lee Strobel.

But let's suppose Paul existed, and that he really did say everything he was supposed to have said. How do you know he wasn't on drugs? How do you know his experience on the road to Damascus was genuine?

People may name their dogs Nero, but their sons have biblical names such as David, Peter, James, Joseph had many many more.

And also Rama, Krishna, and Mohammed. So what?

millions of others all around the world have never heard of him.

They have, however, heard of the Beatles.

Act 9:7 And the men who journeyed with him stood speechless, indeed hearing a voice but seeing no one.

How do you know they weren't all under the influence of something similar?

Of course they are not evil, but lost, like sheep in the wilderness.

Yet the Bible calls them evil, and says, specifically, that they do no good. You would agree with me that this is simply wrong, as in not correct.

The stubborn persistence of religion, including atheism, speaks of the deep human need for significance and purpose.... Why do so many people WANT to believe in something or someone outside of themselves?

I am not a psychologist, but there are a few factors:

• Dying sucks. We don't like the idea that we won't be here anymore.
• Some people need a strong parent figure, especially when we've outgrown our real parents -- when our real father has been shown to be merely human, or even dead, who plays the role of a father in our lives? Note that it doesn't always end up being God -- sometimes, it's an abusive boyfriend, for example.
• The church employs powerful psychological mechanisms, and it does so deliberately. Here's an analysis of why you believe -- in particular, I am thinking of Part 2 here.
• The church provides a strong sense of community, along with several other good things (like charity), which work just as well in a secular environment -- but because the church is doing it, they get associated with the church.
• When we were growing up in the Savannah, survival depended very much on pattern recognition -- we are pattern-seeking creatures. If you saw a tiger that wasn't there, you might be paranoid, but you were alive. If you didn't see a tiger that was there, you were lunch. This explains why, when you look out into the beauty of the Universe, you see God all around you -- you were evolved to see patterns and intelligences, even when they aren't there.

I could go on, but like I said, I'm not really the right person to ask. Suffice to say that there are real psychological, even physiological (brain chemistry) reasons why we, as a species, are drawn to religion.

Ease of use and security, are like so many things in life, a trade-off.

Somewhat, but they also aren't mutually exclusive.

The phenomenal success of social sites like Facebook testify to the fact that many people are more than willing to share some of their most

Re:More direct costs.

[ArsenneLupin]

Then you put the public key for the first certificate in the trusted CAs list for the image that you use when you install your OS of choice on new machines.

... with the added advantage that you can then spy on any bank operations (or any other SSL-"protected" webactivity) that your employees might perform during company time.

Re:More direct costs.

[arminw]

....The burden is on you to show that he did....

No, if this were tried in a court of law, the burden of proof would be on you. This is also true of historians when they find ancient documents. The presumption is truth of the document, not falsehood. It is contingent upon the one who has reasons to believe that the document is false, to come forth with good reasons for such an assertion.

(....How do you know he wasn't on drugs?....)
What evidence can you bring forth that this is so? Were those that were with him on drugs also? Did the drugs make him blind? If you think that the apostle Paul's experience on the Damascus road did not happen as related in Scripture, you would have to bring forth evidence against it.

(....They have, however, heard of the Beatles....)
Only in cultures where this kind of music is appreciated. Also, they are contemporary to our times, not someone who was on earth 2000 years ago. Name someone from that time who is as well known to as many people as Jesus Christ or the apostle Paul.

(...How do you know they weren't all under the influence of something similar?...)
Again, under the universal assumption of truth by both courts and historians, you as the opposition would have to provide evidence of this. What evidence other than your conjecture can you give for this assertion?

(....Yet the Bible calls them evil....)
I think the biblical definition of evil and yours are different. What, in your estimation is the essence of evil?

(...Dying sucks. We don't like the idea that we won't be here anymore...)
Yes, it does in a big way, especially for those who have no hope of eternal life.

John 11:25 Jesus said to her, I am the Resurrection and the Life! He who believes in Me, though he die, yet he shall live.

My body, just like yours will die, but my real self, my spirit lives forever. According to the promises in the Bible, I will get a new body that transcends space and time, no longer subject to some of the laws of physics that the one I live in now is constrained by. God, through the apostle Paul gives us a little insight.

1Corinthians 15:35 But someone will ask, "How are the dead raised? With what kind of body do they come?"

You can read the answer to this question in the rest of this chapter.

(....who plays the role of a father in our lives?...)
That is true, but what is your explanation? Why do people, especially little girls cling to a loving father? Christians are people who call their God "Father". The Jewish religious leader were extremely upset when Jesus called God his father.

(... Here's an analysis of why you believe....)
I looked at it, but it does not explain missionary experience. Muslims for example, severely persecute anyone who turns from their faith to Christ. This is true where the vast majority is against very few Christians. People of every ethnic group have responded to the Christian message even though the majority of their culture group were against them.

(...This explains why, when you look out into the beauty of the Universe, you see God all around you ....)
So when you look out into the beauty of the universe what do you see? Where did the laws that control the beauty comes from? Is there a person behind the universe or is it all impersonal, such as time and chance? Is there a purpose and meaning to it all? Only a person can appreciate beauty. Who or what appreciated beauty in the universe before people existed? Was there no beauty in the universe before people could appreciate it? The very word "Universe" means "one word" as spoken by God, recorded in the first sentence of the Bible. David my friend, you can't get away from God. He is with you and around you and loves you very much.

(...reasons why we, as a species, are drawn to religion...)
The essence of religion is worship. Why is it that humans are the ONLY species on this whole planet that is drawn to worship something external to ourselves? If the chemical explanations were correct, then

Re:More direct costs.

[SanityInAnarchy]

No, if this were tried in a court of law, the burden of proof would be on you.

Why are you so enamored with the rules in a court of law? This is not a course of law, and I am not interested in getting into all of the legal reasons this is wrong. As I've said, Lee Strobel has been answered. Here you go:

Here is an example of Strobel missing a basic concept in evidence law: He never addresses the issue of hearsay. Hearsay is an out of court statement offered to prove the truth of the matter asserted. Subject to many exceptions, hearsay is generally inadmissible as evidence. If the gospels are used to prove the truth of its statements, then they are technically hearsay. If they do not fall under a recognized exception, then the statements would be inadmissible. On the whole (I am not going to go line-by-line here), the gospel statements do not qualify under any of the recognized exceptions.

Chapter 2 is entitled "Testing the Eyewitness Evidence," yet he never once mentions the hearsay problem or that the eyewitness accounts are that of unavailable witnesses whose statements would be inadmissible in court because the declarants could not be cross-examined.

The same would apply to Paul and Damascus:

What evidence can you bring forth that this is so? Were those that were with him on drugs also?

Looks like you are shifting the burden of proof again -- so, what is your evidence that he wasn't, or that he wasn't surrounded by men on drugs? All of this, again, assuming the veracity of the document itself, which I don't accept either.

Why would I start out by doubting this? Because it is an extraordinary claim -- I don't know about you, but I don't often hear disembodied voices, and people who do are generally locked up. When a group of people tells me they saw something (like a UFO), I have to wonder where they all got the idea, but it doesn't mean I immediately believe in aliens.

Name someone from that time who is as well known to as many people as Jesus Christ or the apostle Paul.

Nope, I'm out of patience for this strange ad-populum. Know what even more people believe in? Violence! Surely, there must be something to it...

I think the biblical definition of evil and yours are different. What, in your estimation is the essence of evil?

I don't think I have to provide one, since you indeed agreed with me. You said:

Of course they are not evil, but lost, like sheep in the wilderness.

Either retract that statement, or admit the Bible has a flaw. You really don't have a third option there.

Yes, it does in a big way, especially for those who have no hope of eternal life.

The point is that humans invented the idea of eternal life because they don't like the thought of dying.

Of course, most people haven't thought it through -- do you really want to live forever? How long would it be before you'd watched every movie, read every book, and thought every thought you could possibly think? And then what?

And would it still be you? Think about yourself when you were five years old. Was that really you? Chances are, not a single atom of your body is the same, and your personality is very likely quite different, you don't play with the same toys, you read very different books (assuming you were reading at five)... On what basis do you call yourself the same person now that you were then? Wouldn't it be fair to say you're a changed person?

But that wasn't that long ago, relative to eternity. A thousand years from now, ten thousand, eighty billion, will you still in any way be the same person?

If you aren't, what's the point, really, of wanting eternal life, since it won't be you living it? If you are the same person, don't you think that'd get really boring a

Re:More direct costs.

[arminw]

...Why are you so enamored with the rules in a court of law?....
Because courts of law is where evidence, including written depositions are methodically considered. The procedures there are developed by society to determine truth. Since you dispute the truth of the Bible, you should be able to do it by the same esablished methods as used by our legal system. You should be able to defend your version of the truth.

(...If the gospels are used to prove the truth of its statements, then they are technically hearsay...)
In legal terms, the Gospels are written depositions and not hearsay. They are recorded testimonies of eyewitnesses who heard and saw what they wrote about. Hearsay by definition is nothing more than unsubstantiated rumor.

(...that of unavailable witnesses ..)
If you do not have any witnesses or other admissible evidence, such as depositions, that is writings of other eyewitnesses, you have no case.

(...Looks like you are shifting the burden of proof again...)
Yes I am. A court as well as historians will assume the statements in the written documents are true. Since you are saying they are not, it is indeed YOU who has to come up with credible evidence refuting the eyewitnesses. The Dead Sea Scrolls for example are considered authentic, although initially there were some doubts. It of course your right to reject truth. There is nothing that can be done or said against that.

(...I don't often hear disembodied voices...)
I don't either, but that does not make by itself the written depositions of the eyewitnesses untrue. If you are really trying to determine truth, such as you hopefully would if you were on a jury, you would not be allowed to go by your experience, but what is presented to you.

(...I have to wonder where they all got the idea,...)
I am in your company there. I haven't seen anybody rise from the dead either. My lack of experience of someone rising from the dead, doesn't mean it could not have happened to Jesus. Many skeptics and scholars have examined the evidence, as written, trying to refute it. The more I study the Bible, the more I come to the conclusion of its truth and divine authorship.

(...Either retract that statement, or admit the Bible has a flaw...)
A sheep that has wandered willingly and purposefully away from the shepherd is by definition evil. Anyone who will purposefully not humble himself under the rightful rulership of Almighty God is evil. This leaves you out, because presumably you are still willing to submit to truth WHEN you find it.

(...do you really want to live forever?...)
Definitely not under the present conditions of life here on earth. Think about it, death is really a blessing. What if all the evil dictators and other evildoers could not be killed? What if Caligula and Nero and Hitler and such would be alive here forever? I would call that hell on earth.

God promises that eventually there will be a new heaven and a new earth, essentially a new universe. The Bible tells us that this universe will be rolled up like a scroll. (Big Crunch?) If you would read your Bible, you would learn that God is always having humans participate in what he's doing. Personally, since I am an engineer, God may allow me to participate in the design and creation of some aspect of the new universe.

(...And would it still be you?...)
The short answer is yes. But there are a number of answers to that found in the Bible. One of them is in Matthew 17:1-17:9.

(....will you still in any way be the same person?...)
We humans think of eternity or the eternal mostly in terms of time. Your questions echo this. When we transfer from time to eternity, we go into a new dimension, an existence where time is not measured. There are no clocks nor calendars in heaven or hell.

Those who believe God now, will be eternally with him, but those who don't will not be forced to be in the presence of God forever. In eternity, there will be no yesterday and no tomorrow, only a forever present.

(...

Re:More direct costs.

[SanityInAnarchy]

Because courts of law is where evidence, including written depositions are methodically considered.

They are far from the only place.

In legal terms, the Gospels are written depositions and not hearsay. They are recorded testimonies of eyewitnesses who heard and saw what they wrote about. Hearsay by definition is nothing more than unsubstantiated rumor.

Well, you've used some fancy legal terminology there -- "written deposition" -- but you've also shown a clear lack of understanding of what hearsay is:

Hearsay is information gathered by one person from another concerning some event, condition, or thing of which the first person had no direct experience.

So, for example, even supposing the Gospels were penned directly by people who actually saw and heard Christ, they have only his word that he's the Son of God, and not, say, a demon. Thus, that part alone is by definition hearsay.

As for the Gospels themselves, I would hope a "written deposition" would have, at the very least, a signature. We don't have that -- nowhere within any of the Gospels does the Gospel author name himself.

I would apply more rigorous standards here, however. Consider the eyewitness testimony of this woman. Granted, even if it were accurate, it would not be sufficient; our legal system does not allow murder simply because God said so.

But the more important question is, do you believe her?

If you do not have any witnesses or other admissible evidence, such as depositions, that is writings of other eyewitnesses, you have no case.

You are correct -- I have no case.

That is because I am not trying to establish something -- you are. The burden is, and always has been, on you.

Suppose I said you were right about the rules of evidence. Would that make you happy? Is your goal really to convince me that you are right about the legal system, or is it to convince me that you're right about the existence of God?

If it's the latter, you have a lot of work to do, work you've been avoiding.

A court as well as historians will assume the statements in the written documents are true.

Do you assume the Illiad is true?

I don't either, but that does not make by itself the written depositions of the eyewitnesses untrue.

Then why is it that when people claim to hear voices, we lock them up, instead of pondering whether or not they might actually be hearing something? Why is it that if someone today said "I am the son of God," or "I saw a UFO the other day," we tend to assume that there is a chemical imbalance in their brain, rather than that what they said is true?

Or are you saying that we should open the gates of the asylums and assume that everything everyone ever said is true, no matter how insane they are?

The more I study the Bible, the more I come to the conclusion of its truth and divine authorship.

What is divine about condoning slavery, rape, forced marriage, stoning, genocide, mutilation of the dead (including genital mutilation), genital mutilation of infants, religious intolerance (including stoning any relatives who worship another god), vengeance, and wholesale, wanton destruction?

A sheep that has wandered willingly and purposefully away from the shepherd is by definition evil. Anyone who will purposefully not humble himself under the rightful rulership of Almighty God is evil. This leaves you out, because presumably you are still willing to submit to truth WHEN you find it.

Then why does it not also apply to the same people mentioned in that bible verse? In fact, why am I not included? If I do find "truth", certainly, I will have to accept it,

Re:More direct costs.

[arminw]

....they have only his word that he's the Son of God....

This clearly shows that you have never read the four Gospels. There were at least two occasions, where God personally testified from heaven to three or more witnesses, that Jesus is the son of God. You can read it here: Matthew 3:17; Matthew 17:5

(...nowhere within any of the Gospels does the Gospel author name himself...)
People did not make a big deal of themselves back then. The Gospel of Luke for example was written to a guy named Theophilus. Some scholars believe, with good reason, that this Gospel was used in the defense of the apostle Paul before the Caesar.

(...But the more important question is, do you believe her?...)
No, of course not, because God never contradicts himself. He said in his Word, the 10 Commandments, "thou shalt not commit murder".

(...That is because I am not trying to establish something....)
Yes you are, you're trying to establish that the Gospels are false, just made-up stories instead of factual events that happened in history. I and millions of Christians assert that these stories are true history. Historians and courts of law assume truth. You dispute this truth, so you have to come up with good evidence why.

(... Is your goal really to convince me that you are right about the legal system, or is it to convince me that you're right about the existence of God?...)
Neither. My goal is to persuade you to diligently pursue the truth of this matter, because your eternal destiny hangs in the balance. I would like very much to see you with me in eternity, both of us rejoicing before God, even though we would likely never meet here on earth, although I would welcome that also. My basic assumption is, which I believe is correct, is that you are interested in truth.

You could try something like this in your quest for truth: "Dear God I am not even sure at this point whether you exist. However I am willing to read the four Gospels to find out once and for all, whether the message is true. If I am persuaded by you, I give myself to you unconditionally."

(...you have a lot of work to do...)
Neither I or any other human being can convince you of the truth of God in the Bible. No other human being can get you to want to obey the will of God. However, God by the agency of the Holy Spirit, He can and will do this, if you ask them in all honesty and humility.

(...Do you assume the Illiad is true?...)
There may be elements of truth, but the question I would ask is this: is homer or whoever wrote this poem an eyewitness to all this? Was he actually there? Did he even talk to eyewitnesses?

(...Why is it that if someone today said "I am the son of God"....)
If such a person could control the weather, multiply bread, control wild animals, demons, heal terrible diseases, raise the dead and live a perfect sin free life, I would believe. If provided that finally, if a person made such a claim, here he would have to die at a public execution and then come to life again after a few days.

Anyone who could NOT do all of that could be safely ignored, but the world has not been able to ignore Jesus Christ.

(...What is divine about condoning...)
God is a realist who realizes that this world is thoroughly messed up by sin. All of that horrible long list you mentioned is the result of the cancer of sin on earth. In God's time, in God's way, it will be dealt with.

(...So am I corrupt, are my deeds vile?...)
No more than I am, but I have received forgiveness, which you so far have rejected. It is not the corruption and vileness of people or their evil, that keeps people away from God, but their refusal to believe God, admit their sins and receive total forgiveness.

(....So am I to take that as a "No", or as a "Yes, in Heaven"? I did not qualify "live forever" with any sort of requirement that it be "here on earth."....)

It is God's desire, that humans should be comfortable and happy in his presence. After man sinned, he has been running away from God. All m

Re:More direct costs.

[SanityInAnarchy]

There were at least two occasions, where God personally testified from heaven to three or more witnesses, that Jesus is the son of God.

So we've also got a disembodied voice, which puts them back, roughly, on the same level as Paul.

The Gospel of Luke for example was written to a guy named Theophilus.

Where's your citation for this?

No, of course not, because God never contradicts himself. He said in his Word, the 10 Commandments, "thou shalt not commit murder".

Yet he commanded the wholesale slaughter of the Canaanites. He also commanded Abraham to kill his son. Even within the pages of the Bible, he frequently contradicts himself.

Yes you are, you're trying to establish that the Gospels are false

No, I'm not. You have attempted to establish that they are true, and I have expressed skepticism.

Do you not understand the difference between a lack of belief and a positive belief to the contrary? Must I explain this to you in every conversation we have?

Are you really that damned slow?

I and millions of Christians assert that these stories are true history.

Millions of Muslims assert that they are false.

Historians and courts of law assume truth.

You've clearly gotten the rules of law mixed up. I suggest you ask a few other sources, rather than only a clearly biased one like Lee Strobel.

Historians, as a rule, are capable of distinguishing what is meant as a story of fact versus a myth. This is why other "histories" are not often assumed to be true either, such as the Hopi story of humans climbing out of the Earth, or the Hindu story of Lord Rama defeating Ravana...

Is your goal really to convince me that you are right about the legal system, or is it to convince me that you're right about the existence of God?

Neither. My goal is to persuade you to diligently pursue the truth of this matter...

...then why continue to hammer on this point of a court of law, and your argument ad-populum, when you know I see both as fallacious? Why not search for an argument which is actually sound?

You could try something like this in your quest for truth: "Dear God I am not even sure at this point whether you exist....

Aside from the absurdity of asking an imaginary being whether or not he exists -- can you say you've done the same for Zeus or Mithra? -- you assume that I haven't tried something like this.

I have occasionally asked God for some sort of a sign. I've never been given one, so I've stopped asking.

Neither I or any other human being can convince you of the truth of God in the Bible.

Why do you think that is so? Human beings can convince me of many unbelievable things, and I suspect it was first a human who convinced you of your faith.

There may be elements of truth,

Stop dancing around my questions. Every story has "elements of truth" -- the question wasn't whether it's truthy, but whether it's true. Do you believe it to be true or not?

but the question I would ask is this: is homer or whoever wrote this poem an eyewitness to all this? Was he actually there? Did he even talk to eyewitnesses?

Given the Gospel authors do not name themselves, it seems Homer could be as much an eyewitness -- it's not explicit either, but doesn't it seem just as plausible that Homer could've spoken with Odysseus? And Odysseus was a king, certainly well-respected, one whose word would be trusted.

However, you try to claim two things -- that documents are implicitly assumed to be true, and that eyewitnesses are implicitly trusted. However, we aren't dealing with eyewitnesses (unless you can introduce me to John or Peter while I'm alive), we

Re:More direct costs.

[arminw]

....So we've also got a disembodied voice, which puts them back, roughly, on the same level as Paul....

The question you never answered is whether these witnesses wrote down the truth. Did they all actually hear a voice from heaven? I believe they did and you believe they didn't. I believe the gospel witnesses are truthful and you don't. If you have ever read at least the New Testament, you would know that Luke also wrote the book of Acts as well as his gospel. He writes this at the beginning of the book of Acts.

(....Yet he commanded the wholesale slaughter of the Canaanites....
God looks at sinners who refuse mercy in a similar way as surgeon looks at gangrene. If you would study history, you would learn that the Canaanites had terrible idolatrous practices, such as sacrificing their babies on the red-hot iron statue of Baal. When sin gets bad enough, God deals with it.

(....Even within the pages of the Bible, he frequently contradicts himself....)
Maybe you can come up with one or two instances.

(....You have attempted to establish that they are true....)
No, I assume, I believe they are true, just as I would believe a witness sworn to tell the truth and nothing but the truth, in a court of law. You have to come up with good reasons for your skepticism. You have to refute the witnesses. Just because you have never experienced someone rising from the dead, does not mean it could not have happened to Jesus, just as it is witnessed. Why do you not want to accept the procedure for establishing truth, that has worked reasonably well in courts of law for centuries?

(....Millions of Muslims assert that they are false....)
Study life of Jesus and the life of Muhammad. For one thing, Muhammad is dead, so is Buddha and the rest. Jesus is alive. Christianity hangs on the truth of the resurrection. Many have tried to refute the fact that Jesus rose from the dead. He conquered death for all of us. Many have tried unsuccessfully, to prove that the resurrection of Jesus Christ never took place. You give it a try.

(....You've clearly gotten the rules of law mixed up....)
You can ask almost any trial lawyer about this. Witnesses are sworn in court to tell the truth and nothing but the truth. Witnesses are assumed to be truthful for this reason. Since you are skeptical or opposed to the witness of the Gospels, you have to come up with good reasons for your skepticism. So far you have not.

(.....Why not search for an argument which is actually sound?....)
I don't have to come up with any arguments, because I simply assume, believe, that the witnesses are telling the truth. Jesus DID rise from the dead. You have to tell me why you do not want to believe this.

(....I have occasionally asked God for some sort of a sign....)
What sort of a sign? Ask God for a sign indeed, but also tell him that you will dedicate the rest of your life to him and mean it, when he does. Meanwhile, before he does, why don't you read the four Gospels through for yourself, instead of relying on secondhand knowledge? Study the life of Jesus to see for yourself what he was like. Assume for the moment that everything he said and did is absolutely true. Forgo a few movies or television shows or even --gasp-- slashdot.

(....I suspect it was first a human who convinced you of your faith....)
Yes it was. However he was given information from God about me that only I and God knew. This is how I came to believe that this person was speaking truth to me.

(....Do you believe it to be true or not?....)
In the Gospels we are talking about eyewitnesses to the events. They actually walked with, talked with Jesus and the events around him. Was this also recorded of Homer? I have not studied this, so I don't know.

(.....Given the Gospel authors do not name themselves...)
However many scholars studying church history their whole life, are mostly agreed on the given authorship of the Gospels.

(...However, we aren't dealing with eyewitnesses....)
Witnesses don't have to be ali

Re:More direct costs.

[SanityInAnarchy]

The question you never answered is whether these witnesses wrote down the truth. Did they all actually hear a voice from heaven? I believe they did and you believe they didn't.

You presuppose far more than I actually believe. Supposing they existed, and the record of them was accurate, and that record has been unaltered for thousands of years, then we still have to talk about whether they were sane -- we still have to investigate natural explanations.

I humor you by doing so, but we're not even at that point yet.

God looks at sinners who refuse mercy in a similar way as surgeon looks at gangrene.

Yet the God you claim is not a surgeon, but an omnipotent being. A surgeon has to cut off the leg because there's no way he can remove all of the disease in time. A deity has no such restriction.

Why not simply kill those directly responsible for that "sin", and allow the children a chance? Remember, God commanded genocide, including the killing of babies -- though in at least one instance, the order was, "Kill all the men, children, pregnant women, and women who have known a man, but take the virgin girls as wives."

Maybe you can come up with one or two instances.

I can point you at whole lists of contradictions. Here's a few.

You have attempted to establish that they are true

No, I assume, I believe they are true,

That much is certain. But you are clearly trying to establish it, otherwise, what is the point of this discussion? You have your faith, and I don't.

just as I would believe a witness sworn to tell the truth and nothing but the truth, in a court of law.

Yet you have not produced such a witness. Show me where the gospels swear to tell the truth and nothing but the truth. Note that this is necessary, but far from sufficient for your argument.

I don't want to appear as though I am moving the goalposts -- again, you've got a long way to go.

Just because you have never experienced someone rising from the dead, does not mean it could not have happened...

However, what do we say when we encounter real life witnesses offering such extraordinary claims? What do you say when people tell you about their alien abductions? Or how about something closer to home -- that an angel personally told them that the Garden of Eden was in America, and that godliness is correlated with skin tone? What do you say to such people?

By your logic, you have to take them at their word unless you can refute them. You must believe every claim anyone puts forth unless you can find a reason to doubt it.

It's amazing that you still cannot see the folly of this. Look, I've got an invisible dragon in my garage...

Study life of Jesus and the life of Muhammad. For one thing, Muhammad is dead, so is Buddha and the rest.

And so is Jesus, according to everything we know about how the natural world works.

Jesus is alive.

So is Muhammed, then -- he's in Heaven with Allah. And the Buddha -- he's likely reincarnated as a higher being, though it's also possible he's escaped the cycle entirely.

But you've missed the point again, and I wonder why I waste my time with you.

Nowhere did I claim that I place any more faith in Muhammed or Buddha. My only claim here is to show you that you don't really believe that numbers have anything to do with it. Can I count on you to stop making ad-populum fallacies yet, or are we still back in a 10th grade popularity contest?

You can ask almost any trial lawyer about this. Witnesses are sworn in court to tell the truth and nothing but the truth. Witnesses are assumed to be truthful for this reason.

Thanks

Re:More direct costs.

[arminw]

....then we still have to talk about whether they were sane.....

That depends upon your definition of sane. You have elevated logic, the ability of your mind as the final arbiter of all truth. Is it possible that there are some things in this world that are bigger than your mind? Is it possible that there's some things you have to simply believe, rather than try and figure out?

(....A deity has no such restriction....)
That is true, that is why God promises that there will be a fair judgment for every single person that has ever lived. The reason that you think that killing of what you term innocent women and children is so terrible, is because your logical view of death is limited to the here and now. God is still going to judge the people that drowned in the flood, were incinerated in Sodom and Gomorrah and killed at his command. You look at death as the end, the ultimate punishment. God looks at death differently.

Everybody that has not accepted the forgiveness God offers in Jesus Christ, will be fairly judged on that last day. If you have told even a single lie, it will be brought up and you will have to explain yourself. For those who have accepted what Jesus Christ has done for them, the judgment has already taken place. Jesus Christ took the punishment I deserve. For this reason, my wicked deeds will not be mentioned at all.

(....You have your faith, and I don't....)
In that sense, I suppose that is what it boils down to. However it is not that you don't have faith, but your faith is in the ability of your mind to reason. Faith begins where reason stops. God tells us in his word:

Hebrews 11:6 But without faith it is impossible to please Him, for he who comes to God must believe that He is and that He is a rewarder of those who diligently seek Him.

(....the Garden of Eden was in America, and that godliness is correlated with skin tone? What do you say to such people?...)
As in science and engineering, there has to be a standard. For me, the standard is the Bible, as it has been transmitted to us over the ages. The Bible stands high above other books. How do you explain that the Bible has endured it for centuries, as the most widely distributed book, if it is not the word of God, supernaturally protected? None of the books presently on New York Times' bestseller list, will still have a readership of multiplied millions even only 50 years from now. No one will be avidly studying and discussing any of these, but millions studying the Bible every day. Why?

There are no human writings even remotely close to the Bible. Some of science and technology books are outdated before their ink is dry. Therefore, any philosophy or so-called revelation, that is not consistent with the Bible and a biblical worldview, is by definition wrong.

(...So is Muhammed, then....)
Jesus is the only one who was physically resurrected. All the other religious gurus and Prophets are dead and buried. You can't, and neither can anybody else refute the resurrection. Many have tried with all sorts of weird theories. Jesus is also the only person that never sinned. He is unique. There has never been anyone like him. He is the same yesterday today and forever.

(.... I just happen to disagree.....)
It is too bad that you disagree with the rules of evidence that have been established over centuries, but that is of course you're right. I just hope that nobody ever accused of a serious crime gets you on their jury. You could have your logic overrule the evidence presented in court.

(....you very likely haven't seriously considered any other explanation...)
I only have to look at one thing that all non-Christian religions have in common. All their founders or leaders are dead. Why should I listen to someone who does not have the solution to the most vexing problem of humanity? Jesus alone solve the problem of death. Even if you deny the truth of the resurrection, it still is true that none of the others even make that claim.

(...You are thus not on a quest to discover tr

Re:More direct costs.

[SanityInAnarchy]

You have elevated logic, the ability of your mind as the final arbiter of all truth.

That's not what logic is. Please look it up. Logic is also external to the mind, unless you wish to claim that the universe is basically illogical, which would have dangerous implications for the sort of deity who would create such a universe.

Please don't confuse "logic" with "opinion". An "opinion" might be that 2+2=5 -- opinions can be true or false. Logic is what tells you with absolute certainty and no possibility of being wrong that 2+2=4.

The reason that you think that killing of what you term innocent women and children is so terrible, is because your logical view of death is limited to the here and now.

Death is still likely to be incredibly painful and scary, and that says nothing of rape. Keep in mind that there are places in the world today where young children are sold as sex slaves.

However it is not that you don't have faith, but your faith is in the ability of your mind to reason.

A dictionary would do you some good.

I have confidence and trust on my ability to reason, based on past experience -- I have generally been good at reasoning, and it has generally led me to truth.

Faith is to believe without sufficient evidence or reason.

As in science and engineering, there has to be a standard. For me, the standard is the Bible, as it has been transmitted to us over the ages.

Why the Bible and not the Qur'an, the Book of Mormon, or the Tao Te Ching?

How do you explain that the Bible has endured it for centuries, as the most widely distributed book, if it is not the word of God, supernaturally protected?

I've explained this to you over and over, to the extent that I have ideas about the subject, even when the burden is not on me to explain why, but rather on you to explain why a supernatural explanation is the only one that fits.

Regardless, I will not explain it again.

Jesus is the only one who was physically resurrected. All the other religious gurus and Prophets are dead and buried.

Except Elijah, according to the book. And Rama, for that matter -- if I recall, he also ascended bodily to heaven, without his body having to physically die. Even L. Ron Hubbard was not dying, but leaving his body to return to another planet.

I just hope that nobody ever accused of a serious crime gets you on their jury.

If that happens, I am sure I will be properly briefed about the rules of evidence by someone who knows, not by a Slashdot apologist.

I only have to look at one thing that all non-Christian religions have in common. All their founders or leaders are dead.

That is an incredibly narrow-minded view, and I hope you never have to represent your religion to an interfaith council or anything of the sort.

There is no greater truth that any human can ever obtain in all of eternity, than to know Jesus Christ is God.

You do not know this, you believe it, you have faith. In fact, you choose to believe it as a conscious act of will, something many skeptics find curious.

But because you believe it, you are uninterested in finding out whether or not your belief is true, or whether there might be other related, important truths, or truths unrelated to it. If you ever change your view and decide truth is actually important to you, you're going to have to start by learning some critical thinking, something you seem to entirely lack right now.

I have not given up learning lesser truths, otherwise I would not be interested in technology.

No, it's only the big, important, life-altering truths that you've given up learning. Remember: If you think you know everything important, you cannot learn, and this holds for any su

Re:More direct costs.

[arminw]

.... Logic is also external to the mind....

I always thought the mind expresses itself through the brain. How do you mean that?

(....Death is still likely to be incredibly painful and scary....)
You're certainly right about that. Besides Jesus, what other religious founder promises you life and proved it by coming to life himself?

(....I have confidence and trust on my ability to reason....)
I do also reason every day, but I also know, that reason has limits. There are things in this universe that are beyond science and reason.

(....Faith is to believe without sufficient evidence or reason...)
The existence of the universe and life is sufficient reason for me to have faith, as well as millions of others. The distribution and reach of the Bible, as well as its life-changing power, as the word of God, is another good reason. What would be sufficient reason for you to believe what Jesus said and did?

(...Why the Bible and not the Qur'an, the Book of Mormon, or the Tao Te Ching?...)
There are many reasons, some of which I already gave you. The other books, like most human documents, were written by one person. The Bible, though penned by many, has one author. The burden of proof, as to why the Bible has endured is not on me, because I have told you of a supernatural origin. You reject that, so you have to come up with a natural explanation.

(...And Rama, for that matter...)
Except Jesus lived again, physically, in a new supernatural body, yet visible, able to interact with people here on earth. The apostle Paul, in one of his letters writes this:

1Corinthians 15:6 Afterward He was seen by over five hundred brothers at once, of whom the greater part remain until this present day, but also some fell asleep.

There is no way around it, either he is right, or you are. To believe in his enduring message is more logical and reasonable than to believe you.

(....I will be properly briefed about the rules of evidence...)
Indeed you would be and one of the things they would tell you first off, is to consider only evidence admitted to the court. To enforce that, they sometimes sequester juries.

(....That is an incredibly narrow-minded view...)
You are indeed right about that. But there is a fact you cannot get around. Jesus' grave is empty. The people heard and saw him, walked 7 miles with him, ate with him and watched him eat with them. His enemies, those who had him crucified as well as the Roman government would have paraded his dead body around Jerusalem to show everybody that this resurrection rumor was false. The women could not have moved the 2 ton stone blocking the entrance to the grave, even if there had been no Roman guard. You have to deny the resurrection by faith, not by the reasoning you're so proud of.

(....No, it's only the big, important, life-altering truths that you've given up learning.....)
What other life altering truth is greater and more important than the overcoming of death? What other truth is comparable to that? Why should I give up the most important life altering truth that was ever visited upon humanity? What truth is more important than life itself, eternal life? All other truths, are like a small hill compared to the Everest of this truth of life eternal. Is your life not important to you? Why can't I learn lesser truths, just because I hold the resurrection of Jesus Christ higher than any other?

(....A quick Google turns up this critique ....)
[...We have a 300+ year gap between the first entire Gospel manuscript and the time at which it was supposed to have been written....]

That is manifestly false. At least three of Gospels were written before the destruction of Jerusalem in 70 A.D. The Gospel of John is the only one that may have been written after that, although there are some scholars who think that it was also written before the temple in Jerusalem was destroyed. If these gospels were truly written as claimed here, then the historical authors would have surely mentioned

Re:More direct costs.

[JSlope]

I think that for static pages it's possible to implement something like page signing, so that it will be possible to download those pages without encryption and still be sure that pages are authentic. For example if you're downloading a page from site A, but it's signed with signature of site B then it's a problem.

Re:More direct costs.

[SanityInAnarchy]

I think that for static pages it's possible to implement something like page signing, so that it will be possible to download those pages without encryption and still be sure that pages are authentic.

Well, and dynamic pages could be done in a much more efficient manner, also. But with the realities of what servers and browsers support at the moment, HTTPS is either CPU-intensive or hardware-aided, probably both.

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!

[Anonymous Coward]

"large data loads being done over the network causing the voice quality to go through the floor"

You (or Cisco) are doing it wrong.

We have a fairly simple, Asterisk-based, VoIP system in-house, serving about 20 extensions. Our 3Com 100Mbit managed switches (ex-elsewhere via ebay, and not even close to current tech) prioritise VoIP traffic, so even though the Asterisk server is on the same gigabit switch in the system rack as some pretty beefy servers, I can transfer 40+ GB virtual disk images from server to server (or my desktop PC) and the VoIP users will not notice a thing. Our infrastructure setup is not sophisticated - we could have created a separate VoIP VLAN on the IT room switches, but found no need.

Something's not good with your network design and whoever put it in should be taking a look.

Re:VOIP isn't everywhere? Good!

[Viol8]

"we could have created a separate VoIP VLAN on the IT room switches"

Doesn't that rather defeat the whole point of voip which is to use the same network cabling as everything else?

Re:VOIP isn't everywhere? Good!

[Anonymous Coward]

VoIP for the office is a tremendous time- and resource-saver, especially when you're doing Moves-Adds-Changes (MAC) or rolling out exotic voicemail and call routing features that cost many $$$ with legacy PBX systems.

It *is* network-dependent, though. You must consider that in any legacy-to-VoIP migration plan.

Your network isn't up to handling VoIP traffic. That's not VoIP's problem, that's your network's problem. And dropping VoIP packets isn't the only thing your network's mis-handling, is it?

VoIP isn't a drop-in solution, and anyone who doesn't do a thorough network examinination before moving a mission-critical application like voice to IP . . . gets what they deserve.

Re:VOIP isn't everywhere? Good!

[Low Ranked Craig]

I have a small business and we've been using VOIP exclusively for 6 years with only minor, occasional problems, and those were right in the beginning. The problem isn't VOIP, the problem is Cisco's somewhat proprietary and really fucking expensive implementation. Asterisk + Astera is reliable and cheap as hell...

Re:VOIP isn't everywhere? Good!

[Low Ranked Craig]

No. VLANs use same network cabling as everything else. Personally all we do is give top priority to VOIP traffic via QoS in our router. No garbled calls...

Re:VOIP isn't everywhere? Good!

[Anonymous Coward]

Then you don't know what your doing....

Re:VOIP isn't everywhere? Good!

[fwr]

You are either nuts, trolling, or woefully uninformed. For proper VoIP, or any protocol that requires minimal delay, jitter, and packet loss, QoS is necessary. With a proper QoS setup you should not have any issues. Without QoS, reliability is not guaranteed.

Re:VOIP isn't everywhere? Good!

[Anonymous Coward]

My place of employment had a VOIP phone system installed a couple of years ago. Someone soon discovered an exploit which causes the PA to play the 'off hook' sound. Apparently this knowledge has spread, and it can be done from any phone in the building. It's now a daily occurance.

Re:VOIP isn't everywhere? Good!

[Anonymous Coward]

This sounds like your voice network isn't properly separated from your data network, and/or you don't have decent QoS. That would explain the first and possibly the second. The last two I don't know about. If I were your network guy, I'd look into putting the entire VOIP system on its own VLAN and then look into QoS settings. It might be necessary to replace the switches, but even relatively cheap managed switches can handle this stuff these days.

My experience has been generally positive, but I will say that packet switched networks make me a little more nervous than circuit switched. Not particularly happy to be on VOIP at home (not that the quality or service is poor).

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.

Re:VOIP isn't everywhere? Good!

[Anonymous Coward]

VOIP in the office -just working for us. With zero maintenance in the last few years. Calls are always connecting and we never had any quality issue.
And I have to say, that we are not using Cisco. We had very bad experience with it. (we are using a voip server from a small hungarian company called mizutech)

> all it does is save on some cabling and wall sockets which had already been installed and paid for anyway
I don't know from where are you writing. We have much lover price using voip service providers than pstn.

Re:VOIP isn't everywhere? Good!

[w0rd]

"we could have created a separate VoIP VLAN on the IT room switches"

Doesn't that rather defeat the whole point of voip which is to use the same network cabling as everything else?

No, not at all, 802.1q trunking allows you to create multiple vlans, and run them over one cable. One cable can carry two vlans, the phone peels off the voice vlan, and the inline pc get's just the data vlan

Re:VOIP isn't everywhere? Good!

[zero0ne]

VLAN = Virtual LAN

Amazingly, switches allow you to setup a port on them for more than one VLAN... crazy I know.

Re:VOIP isn't everywhere? Good!

[rantingkitten]

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.

A lot of people don't do this; they have some Cisco phones lying around from their previous vendor, and simply point them at the new SIP server's IP along with the SIP auth information. It depends on who their previous provider was to determine if they had UCM or have any meaningful access to it.

Frankly, Cisco's SIP stack is completely half-assed. They were dragged kicking and screaming to support SIP at all, which was (is?) a competitor with their own SCCP crap, and when you look at the release notes of the SIP firmware for their phones, their open caveats are often complete show-stoppers, yet they release them anyway. What the hell?

That said, it sounds like the original poster's problem is mostly a lack of proper network design, like they just threw all the phones and computers on the same network without any VLANs or QoS and assumed it'd work. Sadly, this is an extremely common problem with VoIP, because customers don't have any understanding of how it works and just want a plug-and-play solution, not one that's going to require them to expend time or effort into network planning.

Re:VOIP isn't everywhere? Good!

[joshio]

Good point about Cisco's SIP stack. The SIP release notes are laughable compared to the SCCP ones. Anyone using Cisco phones connecting to CCM or CUCM via SIP must be completely bonkers. It really is a poor implementation. I'm interested to see if it improves now that they have started releasing SIP-only phones (89xx and 99xx).

Re:VOIP isn't everywhere? Good!

[rantingkitten]

Honestly, I think they should just give up pretending like they can make consumer-level gear. They have their Linksys division for that, and in fact, Linksys makes a number of very simple-to-setup-and-use IP phones. The Cisco-branded ones, e.g., the 7960s et al, are a horrendous mess that no normal end user can possibly use.

As a comparision, to set up a Linksys phone you can have it download an xml file using a variety of protocols, or use its web-based UI to enter the SIP information it needs, which is only a few fields. Troubleshooting is easy and there are many options to handle various NAT implementations and network environments. Flashing firmware is as easy as downloading and running an executable and telling it the phone's IP address.

The Cisco 79xx series, contrawise, have no web-based UI. You have to enter all information on the keypad like you're text messaging, or you can have it download a poorly-documented xml file using TFTP, and TFTP *only*. Changing even trivial settings requires a password. Troubleshooting involves attempting to decipher totally useless messages on the screen or connecting to the phone via telnet and issuing non-intuitive Cisco commands, but even then your options for actually doing anything about the problem are limited. Putting new firmware on it requires something like four different files, using naming conventions that Cisco changes CONSTANTLY, and they keep those files guarded like they're the eleven herbs and spices. The files can only be sent via TFTP, and as far as I can tell, the TFTP server must be on the LAN.

They're completely asinine for anyone to use without spending serious time getting acquainted with The Cisco Way of doing things, and they don't even work that well. Why is Cisco even bothering with this crap instead of letting their consumer Linksys division handle it?

Re:VOIP isn't everywhere? Good!

[Viol8]

"As a comparision, to set up a Linksys phone you can have it download an xml file using a variety of protocols, or use its web-based UI to enter the SIP information it needs,"

Alternatively you could just use a POTS phone at home. You plug it into the wall and , oh look , it just works!

VOIP is technology for its own sake.

Re:VOIP isn't everywhere? Good!

[rantingkitten]

At home, sure. For small to medium businesses, analogue phone lines are expensive and not nearly as versatile. You want additional lines because you hired some new employees? Now you have to wait for some doofus to come out and install them. With voip, you just configure the pbx or have your vendor do it, in a few minutes. It's all software; there's no messing around with physical wires.

It'd be nice to see...

[Anonymous Coward]

...the crypto responsibility moved to the network where it belongs. It can and should be completely transparent to the end-user, and non-optional.

Want to send something via FTP/telnet/http? Fine, go ahead. We'll encrypt/decrypt it silently on your behalf anyway. No need to give it a second thought. Want to encrypt it yourself? Fine, go ahead. We'll encrypt/decrypt it all again, our way.

well, duh

[zogger]

The answer got leaked a long time ago

Re:And pushing it would give false sense of securi

[Sycraft-fu]

No kidding. I mean using HTTPS for most websites? Why in the hell would you do that? If the site is public, well then that means anyone can look at the information anyhow. What would encrypting it gain?

Also encryption isn't free. It takes CPU time (or dedicated crypto units). This isn't a big deal on client PCs, you tend to have plenty of power, but on servers it can be a problem. You can end up needing to get more power if you are going to do a lot encrypted.

Encryption should be used sensibly, not indiscriminately. If there's a password involved, yes that password needs to be encrypted. If the data is sensitive or private in some way, yes that needs to be encrypted too. However there's no reason to encrypt something that is public anyhow. It's just a waste of resources.

encryption is no panacea

[Anonymous Coward]

because encryption breaks things and makes them run slower. Caching proxies fail with encryption. Error rates increase with every level of complexity, and fixing them gets less likely. Making computer work together is still hard, so making it artificially harder is retarded. I hate DNS-SEC, and I hate the push for encryption for no reason.

As another poster said, the bulk of security problems are not solved by encryption. Many problems are caused by poor attempts at encryption.

  - deadshift

Most Data Isn't Worth Encrypting

[InitZero]

Most data traveling in the clear has little value. What value it has may be momentary. A week from now, it is worthless.

Heck, most encrypted data has little value. The fact of the matter is most data is worthless junk.

I was the backup administrator for a Fortune 500 company's branch office of 1,500 users. I have a pretty good idea of what data existed because I was responsible for keeping it safe. Of the terabytes upon terabytes of data sitting in the archive, I could have put the worth-encrypting sensitive company information on a USB thumb-drive. There was really that little of it floating around.

So, the reason most data isn't encrypted is that there really is no reason for its encryption.

Cheers,
Matt

Crying wolf in the past

[starglider29a]

In 1994, I wrote a rant to my friends telling to "get encrypted or get pwned*". Paranoia of that day (new prez, newer congress, Blue laws, Waco, Ruby Ridge, OK city yet to happen) We went through a bit of wrangling to get PGP keys and such. We were not n00bs, but it still seemed more difficult than it should have been. We encrypted our emails, and even our chats... for a while. When we realized that nothing we were saying mattered to anyone interesting (pick a 3 letter acronym), we stopped bothering.

But now, it seems like delusional paranoia to think we need to encrypt our every day stuff. I still have that rant on file, and it seems pretty kooky in retrospect. Having to explain the wisdom of encryption to someone who can't open a .DOT file comes off as wacko.


*no, I didn't use that word.

Re:Crying wolf in the past

[muckracer]

> When we realized that nothing we were saying mattered to anyone
> interesting (pick a 3 letter acronym), we stopped bothering.

Out of interest...how did you 'realize'?

Encrypting What?

[Anonymous Coward]

The techniques discussed here address only the data in transit. While IO haven't seen anything other than anecdotes, my sense is that the successful attacks have been at the server/database/file level; i.e., static data.

There, I've seen the network guys and the application people pointing fingers at each other saying "encryption is HIS job, not mine.", when it's BOTH their jobs, IMO, since different techniques apply.

Certificates.

[Eskarel]

The basic reality is that most information really isn't all that private, and that managing certificates is rather tedious and expensive.

People don't generally whisper when they're talking to their friends in public, or talk in code, or anything much else. They don't care too much who overhears. If something is supposed to be secret they take the appropriate steps.

The same is true for web traffic. Most of it just doesn't need to be all that secure. Sure bank details need to be private, and a few other things, but my google search doesn't really need to be. Google is already storing it, and why would anyone bother to spy on it, or care if they did?

The exception to this of course is e-mail which is more of a systematic failure than https or ftps. Most people would indeed like their e-mails to be private, but while webmail providers are starting to provide https interfaces, real, honest to goodness, e-mail encryption is just too damned hard. Key management becomes impossible past more than a couple of keys and the whole process is just incredibly tedious. The person who comes up with a way to get e-mail encryption in a way that isn't too much hassle and doesn't involve storing all your keys with some "trusted" third party will have a license to print money.

Re:Certificates.

[acohen1]

More likely they will die alone and forgotten, because only that "trusted" 3rd party method will allow for monetization.

Re:Certificates.

[muckracer]

> Key management becomes impossible past more than a couple of keys
> and the whole process is just incredibly tedious.

What part of it do you find difficult? (honest question...trying to understand)

Re:Certificates.

[Eskarel]

Well, the problem is that if you're talking about trying to encrypt the majority of your communications, you've got to get everyone who e-mails you to use your public key, and everyone you e-mail to have a key pair of their own. Otherwise the whole thing falls apart.

Since you can't really encrypt the majority of your communications in any meaningful way, that leaves encrypting specific traffic, usually business. Encrypting business traffic generally involves quite a number of key pairs, and some sort of way to distribute and store them. That becomes very difficult for everyone involved.

I can tell you that Health Care for one is crying out for a secure e-mail platform which actually works, and I'm sure that there are a number of other industries in the same boat. The easy solution is to have the government or some other body issue and manage the key infrastructure, but no one trusts the government with their medical records, let alone anything else. That's why I said it was a license to print money.

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.

Re:HTTP(S)? Marketing/profitability & IPv4

[Anonymous Coward]

.. in short, IPV6, no marketing, cookies or scraping sites??
Sign me up Scottie!

Re:HTTP(S)? Marketing/profitability & IPv4

[Macrat]

You can argue that we should instead be using IPv6, and I might agree, but we're simply not there yet.

Are we there yet?

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

Re:Talking out loud ...

[Anonymous Coward]

ever use slang in conversation? congratulations, you are using a form of verbal encryption. albeit a weak one.

Re:And pushing it would give false sense of securi

[apoc.famine]

The other issue is that there is some inherent risk in data encryption. It's another thing that can break. If my data gets a bit corrupted, I can probably recover most of it. If my encrypted data gets a bit corrupted, I don't have such confidence. It depends on the way it was encrypted, and the decryption tool.
 
I'd agree - most of what really, really needs to be encrypted already is. And there is definitely a diminishing return as we encrypt more things.

underappreciation of importance

[dpilot]

The flip side of a "false sense of security" is an "under-appreciation of importance."

In spite of the dismal state of security on the internet, most attacks are still based on human engineering. In other words, the people are still a weaker link than the horrible software security we currently have. Beef up our software, improve certificate and key generation and distribution, and the human engineering attacks would step up. This time they'd have new targets - certificates, private keys, etc. Given the current state of things, such attacks would get exactly what they're after, in too many cases. The real problem is that because "now things are secure" more trust would be placed in internet communications and more money/reputation/etc would be placed at risk. Bad things would happen until we properly recalibrated our habits - or our expectations.

Dan Kaminsky got it right

[Anonymous Coward]

I think the reason is the utter failure that current PKI infrastructure is. Dan Kaminsky's talk at 26C3 opened my eyes:
http://www.youtube.com/watch?v=RE_Z-HKzRW0

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

[Anonymous Coward]

There was noone.

I doubt that's truly the case. Odds are it was more of "There was no one that was willing to do the work at the salary we wanted to pay them."

Re:Expertise

[Anonymous Coward]

What is ironic is that a properly administered infrastructure would mean a great boon to privacy.

Setting the ID debate aside, Picture an ID card with a smart card on it. The private key on the smart card is signed by the state with a certificate saying that the person who the key belongs to is above 21 and is of legal drinking age. Now when the cardholder hits a bar and the card gets scanned, the establishment gets the one key point of information they need by law, and no more. They don't need someone's birthdate, just proof they are over 21.

Similar with degrees awarded by colleges. A college can make a certificate saying that so and so got a M. S. in chainsaw fencing on May of 2009, and an accrediation agency can sign the college's key. This allows sufficiant proof of a college degree, but without requiring invasive searches.

Re:Expertise

[Anonymous Coward]

Must be real fun typing that username in, eh?

ignorance and stupidity

[theyulman]

In many cases, the very reason that encryption was not part of a corporate security policy is...well ignorance and/or stupidity on the management part.

They would rather rely on security by obscurity.

What about cost?

[opus_magnum]

I don't have figures handy, but I assume encryption would "waste" a sizable amount of computing power, for no apparent benefit.

Re:What about cost?

[funwithBSD]

And speed. A good scp connection using arcfour maxes out at about 22MB per second on most systems I have used.

An unencrypted transfer will hit the theoretical max of ~140mb per second over a 1G connection.

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.

Re:Because encryption is a bigger problem

[Anonymous Coward]

Are you sure that's more likely? Obviously you'll always remember the one time you lost your crypto key and got locked out of your data. OTOH, if someone happens to snoop around your data, you probably wouldn't even notice. Of course, this is assuming that the reward/effort is worth it for someone to bother.

Re:Because encryption is a bigger problem

[Abcd1234]

You are more likely to lose your keys than your privacy

Yes, because it's so very tough to throw your .gnupg directory onto a CD and squirrel it away in your closet.

Please.

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.

Re:People don't see the value

[Anonymous Coward]

Replying to remove wrong mod!

Re:People don't see the value

[SanityInAnarchy]

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.

get over their foolish attitude that it's pointless to force attackers to use MitM instead of passive snooping.

It has a point right now, which is more or less security through being a harder target. If you get everyone doing it, I doubt it will help very much -- MitM is painfully easy to do over wireless, and there's at least one freely available tool which does it.

Once encryption with poorly-authenticated key exchange becomes more common, people will start to see a benefit to improving their authentication,

More likely, people will say, "I'm safe, aren't I? I'm encrypted!" And then they'll go right back to ignoring us.

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.

exert market forces within crippled single-signer systems to have cheaper CAs,

It costs something on the order of $20/year for a cert. Sure, EV certs cost more, as do wildcard certs, etc, but the base cost isn't bad.

And yeah, I would much rather see a web-of-trust scheme, or at least some more decentralization of CAs, but that really doesn't seem like the problem here. Remember, we're still talking about pretty much every organization Doing It Wrong -- I'd suggest it has much more to do with getting authorization to pay for anything, and with the hardware costs.

Re:People don't see the value

[Anonymous Coward]

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.

Yeah. Tell that to browsers.

BFU encounters HTTPS site with self-signed certificate and what happens? Red site (or even better, site with same design as "timeout/exception") with something like "this could be another site blablabla something like malware blablabla".

Simple solution for that, just don't use this irritating "s" in http://.

Re:People don't see the value

[Tim C]

As an AC? How exactly is that supposed to work?

Re:People don't see the value

[Anonymous Coward]

'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:People don't see the value

[TheRaven64]

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.

It's not a mistaken attitude, and it's becoming an increasingly less-mistaken one. Think of all of those free WiFi access points. Your employee sits down in a cafe and connects with its access point. Well, he thinks it's their access point. Actually it's run by the guy renting the flat above the cafe. He redirects all HTTP through his proxy and will do a MITM attack on anything that uses a self-signed certificate.

Your employee connect to your corporate Intranet with it and, unless you distributed the certificate out of band and your employees know not to allow connecting when the certificate verification fails, he's just handed his login details to a stranger. This guy harvests as much as he can from the Intranet before you notice, then sells it to one of your less scrupulous competitors.

When a potential threat needs about $50 of off-the-shelf kit and a tiny bit of patience, it's not the sort of thing that you should be discounting.

Re:People don't see the value

[93 Escort Wagon]

As an AC? How exactly is that supposed to work?

Did you not notice the "Post Anonymously" check box when you were typing your reply? Okay, right now I don't either - the checkbox is there, but "Post Anonymously" is white text on a white background (Taco is still getting the hang of HTML, apparently). But anyway... the system can still know who an AC is, assuming that AC is actually logged in.

Re:People don't see the value

[Anonymous Coward]

Yes, but posting anonymously does not eliminate any moderation that has been done. You can moderate and post anonymously in the same article.

Re:People don't see the value

[sgrover]

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

You must live in an ideal world. Very few people I know even think at this level. The only way "people" will change is if the tool they use changes. This IT thing is not so simple that just anybody can understand all aspects of it, and frankly I prefer it that way. I'd rather a nurse know how to fix ME, than how to fix a computer. But if you want that nurse to use encryption to make the world more "secure", then you need to make sure the tools do it for them without them needing to know the details. Now tie in that idea with the concept of lazy programmers. Until the programming eco system changes so that encryption is the ONLY way to communicate, then the lazy programmers will hold back everyone else. (I'm not talking about Lazy as in worthless, I'm talking about the concept of achieving a required task with the minimum of effort or costs). Have you tried to program an encrypted system lately? It isn't "simple" yet, and probably never will be. Same as achieving "security" is a nebulous but desirable goal.

Re:People don't see the value

[TerranFury]

He redirects all HTTP through his proxy and will do a MITM attack on anything that uses a self-signed certificate.

How would that work? The bad guy's server wouldn't be able to log into the remote server (since plaintext passwords never get sent across the network with SSL), and the user would immediately notice something is amiss, no? Isn't "oh, I can see all the corporate documents" proof enough that he's talking to the server he thinks he's talking to?

(Ok, I understand that I'm possibly overstating the intelligence and/or necessary-paranoia of typical users here; in a corporate setting where you're responsible for other people's behavior, you'd need to to run a CA and distribute certs in OS images, etc.... But in principle, with observant users, this attack shouldn't work, right?)

Re:People don't see the value

[Sloppy]

Think of all of those free WiFi access points. Your employee sits down in a cafe and connects with its access point. Well, he thinks it's their access point. Actually it's run by the guy renting the flat above the cafe. He redirects all HTTP through his proxy and will do a MITM attack on anything that uses a self-signed certificate.

That's bad. But you've got the same risk with plaintext. Unauthenticated crypto is no worse. And it has an advantage over plaintext, even when MitM attacks are attempted:

Your employee connect to your corporate Intranet with it and, unless you distributed the certificate out of band..

(attackers have no way of knowing whether or not that has happened, so every MitM carries risk of detection)

.. and your employees know not to allow connecting when the certificate verification fails, he's just handed his login details to a stranger.

And if just one employee does know what the verification failure means, then the word is now out: MitM happens; it's not merely a theoretical risk that cypherpunks need to worry about, it's every day reality that Joe Average needs to worry about. A memo goes out: "someone tried to MitM attack Jones at Cafe Greaso!"

Self-signed certs give you a fighting chance that plaintext doesn't give you. I'm not saying it's as good as authenticated crypto -- it's not. But it's far better than not encrypting at all. If certification is too much of a pain in the ass, then worry about it later if you must delay, but that shouldn't be stopping people from encrypting.

Re:People don't see the value

[bitslinger_42]

Two thoughts. First, there are times where it is better to be using a system that you know without a doubt is insecure than to use a system that appears secure, but isn't. At least with the known unsecure system, there's a chance that the user will stop and think "hmm, this is pretty sensitive, maybe I shouldn't be doing this over the unprotected link". If the user has that magic gold lock icon, they'll think they're secure even when they're not, which not only increases the chance of compromise, it also increases the chance that high-value data is compromised.

Second, key-signing parties are not a panacea. When it comes to trust and identity, how well do you really know people? There are exactly two people in the world that I can say with confidence that I'm 100% sure that I know who they are. I am the first (self-evident). My son is the other. I know that because I was in the room when he was born, he was handed to me, I carried him to another room, and he never left that room unless he was accompanied by either my wife or myself. Since then, he's been in our possession and we've maintained documentation of him (i.e. pictures, medical records, hand prints in clay, etc.)

For everyone else I know, there is no way for me to establish their identity with that level of certainty. I know that the people I call my parents today are the same people that I've called my parents for as long as I've had the concept of parent, but when it comes down to it, there's no way I can be sure that my father really is Bob Bitslinger and not, for example, D. B. Cooper, or Alice Cooper, or James Fennimore Cooper, and that's with someone that I've supposedly known my whole life.

Read Cory Doctorow's book Little Brother. It isn't particularly well written, and the story's a bit overblown, but it does a great job of explaining why key-signing parties don't solve the trust and identity problems in security.

Re:People don't see the value

[Dan Ost]

Wow, that's stunningly simple and elegant.

Who would be a good, trusted non-profit to suggest that to? EFF? Apache? Mozilla?

Re:People don't see the value

[compro01]

Actually, if you are logged in and check the post anonymously box, it will silently remove any moderation on that story.

The only way to post and moderate in a story is to completely log out to post.

Re:People don't see the value

[zippthorne]

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.

Indeed. It would be more accurate to say that a self-signed cert is no better than using plaintext, unless you distribute the cert via a separate channel.

Re:People don't see the value

[TheRaven64]

No one said it self-signed certificates were worse than plaintext. You said that saying that they were 'barely better' was 'mistaken'. It's not. A self signed certificate is barely better than no crypto.

Re:People don't see the value

[TheRaven64]

I'm not sure what you think happens. With a MITM attack, the client will establish an SSL connection to the attacker, the attacker will establish one to the server. Anything that the client sends to the server will be recorded by the attacker. Lots of protocols, and lots of web apps, send plaintext passwords from the client to the server when using SSL (why bother hashing it when the connection is 'secure'?) and so it's entirely possible that the attacker will record the user's login name and password.

The user will not see anything unusual. They will get a warning saying the certificate is not properly signed, but they'll get that anyway with a self-signed cert. They'll see everything that they usually see. Later, the attacker will log into the system with the same credentials and be able to access anything that user could access.

With a signed certificate, this attack is impossible, as long as the client trusts the issuing authority and has the public key for their root certificate. Whether that root certificate is Verisign or your own IT department is irrelevant. If you handle key distribution properly, out of band, then it's not a problem. If you just slap up a self-signed certificate, enable SSL, and think you've got security, then you've got a problem. You're immune to casual eavesdropping, but nothing more.

Re:People don't see the value

[TerranFury]

Oh! Yes! The passwords are either going to be just POSTed or submitted with HTTP BASIC authentication -- plaintext to the proxy either way; the password is not involved in setting up the SSL/TLS connection to begin with. Gotcha. Thanks for the clarification.

Re:People don't see the value

[bill_mcgonigle]

No one said it self-signed certificates were worse than plaintext. You said that saying that they were 'barely better' was 'mistaken'. It's not. A self signed certificate is barely better than no crypto.

That's only true for the initial request. All browsers will warn on subsequent changes if you store the cert.

So, for example, an internal webmail that gets one initial request and then thousands of subsequent ones, has a real benefit from a self-signed cert over plain text. And if the cert is installed in the company's standard build, even better.

The real problem is that some browser vendors charge for root cert inclusion and so they put up inappropriately worded warning dialogs to scare users, and force the issue.

Re:People don't see the value

[Sloppy]

When it comes to trust and identity, how well do you really know people?

Usually: about as well as I know Verisign.

Read Cory Doctorow's book Little Brother. It isn't particularly well written, and the story's a bit overblown, but it does a great job of explaining why key-signing parties don't solve the trust and identity problems in security.

Doctorow got it wrong. The characters make a big deal about only having people they trust at the key-signing meeting. And likewise, it's some sort of big deal when the narrator finds out that one of the people he signed was an infiltrator. This shows he (or to be generous, the narrator) doesn't understand the value of the WoT.

OpenPGP lets you get many certifications for an identity, thereby making it so that an attacker needs a conspiracy. Instead of putting all your trust into a possibly hostile CA, you put your trust into a bunch of possibly hostile certifiers not conspiring (and even then, the ideal UI would just tell you that the key-to-identity mapping is probably correct). For each CA/certifier, there's a nonzero probability that he's working to subvert the system. But if you multiply the probabilities of all the paths, the product starts to get to be a really small number. At some point the trustworthiness gets to be higher than what any one CA can possibly offer.

Security isn't an all-or-nothing nothing thing. There are degrees. Any system which doesn't acknowledge that there are degrees of risk, is broken and will eventually mislead someone. That's why OpenPGP makes the X.509 system obsolete.

I'm a little unhappy with Doctorow for misrepresenting the point of keysigning parties (as well as for coopting the term "Little Brother," which I used to use as a term for the myriad potential adversaries other than government). OTOH, it's just a story and does contain some things which people ought to be reminded of.

When will Hotmail finally implement full-SSL?

[Anonymous Coward]

When will Hotmail finally implement full-SSL? Gmail has had this for a long time now.

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?

Re:Headache for diagnostic tests

[Anonymous Coward]

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.

You're clearly not a coder. Debugging in the presence of an extra layer of indirection is not "complicated" to this side of IT.

Re:Headache for diagnostic tests

[JSlope]

Actually encryption is not only about encryption, but also about authentication and if all files in OS would have been signed, there would have been a lot less corrupted files.

WAY too baroque and fragile

[david.emery]

PKI might be theoretically secure, but it is to damn complex to set up and maintain in the face of issuing and then managing certs including expiration of same, email addresses that change causing a cascading exchange of certs, case mismatch between the sender's email address, e.g. "joe.blow@example.com" might not match a cert issued to "Joe.Blow@Example.com", etc.

Same thing's true for trying to set up https on websites. But I'm disappointed at how many corporate high-confidence (e.g. bank) websites don't start off with https these days. They can make the purely server-side investment. Unlike email and point-to-point connections, at least web server security is encapsulated on the server.

Another problem is that most of the time you just want a simple "did this message come from who you thought it did", but the cert authorities add to this confirmed identity. That means you have to pay a company like Verisign a lot of money for an identity cert where they require you to show up with your passport, etc,. Again, -overkill- for what most people need, mostly they want to make sure there's no interference with subsequent messages from the same sender.

The error messages in general are not helpful, in part due to bad human factors engineering and in part due to policies that want to prevent covert channels (akin to the lack of distinction between 'file doesn't exist' and 'file exists, but you don't have access')

It took me several years to get reliable PKI certs working for encrypted email on Thunderbird, but all that broke when I moved my mail over to Apple Mail.app. I'll probably have to move back to Thunderbird (even though there are things about T-bird that I actively despise.) Part of that complexity is exchanging individual certificates with others, and part of that is trying to connect to external corporate LDAP servers to get certificates for new correspondents. (Seems that most mailers assume a single internal LDAP server, and don't provide support for connecting to ldap.xyz.com for XYZ employee certs, ldap.abc.com for ABC employee certs, etc.)

And then there's Smart Cards/Common Access Cards, which work OK if someone who knows what they're doing configures a Windows machine, installing third party software, etc, etc. A security measure that only works on Windows is questionable (and that's before the well-documented problems with Windows vulnerabilities, allowing people to get 'inside the firewall'. Just ask Google, Adobe, etc...)

As someone who's been using personal computers for over 30 years, if -I- don't have patience with this, it's certainly not ready for mom-and-pop.

Why not slap encryption everywhere?

[Anonymous Coward]

It's the keys, stupid.

Re:Lack of Open, Accessible Standards

[t'mbert]

I second this! This is exactly what's keeping most businesses I talk to from using it. Because of the lack of standards, your implementation either isn't compatible with everyone, or if it is you provide a bunch of really complex options that only PhD's understand.

This also produces fear...IT management doesn't understand all those options and the implications of one over the other, and don't want to be held accountable for encryption that doesn't work.

Until there is a simple, uniform and free way to implement certificate authentication, it's just going to wallow.

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

Re:I can only answer for myself

[srinathhs]

using encription for everything is a pain... also in my point,, keeping those certificates / passphrases is even more troublesome, u loose them n u are left with nothing... in order to keep ur passphrase safe - u tend to keep it in another encryption -- it goes onn n on.. some where there ll be a weak link from which ppl can hack out if they really need ur precious data :)

Re:I can only answer for myself

[diitante]

1. Your right to privace needd to be exercised or it will atrophe. Use it our loose it regardless of your need to hide something. 2. That piece of paper WILL be found with the proper effort exerted. Strongly encrypted files will NOT be read, no matter the effort. Learn yourself how to use some encryption tools. 3. It could happen if your not careful. Be careful and keep a copy of your keys in an alternate safe place. 4. Very. Backup, you should be doing it anyway. 5. You mentioned 2 of the most respected tools. Start there. Start anywhere, just start. Its important. Cheers and good luck. M

Re:I can only answer for myself

[Anonymous Coward]

i use encryption because
1. i do have things of value to encrypt (passwords to e commerce sites,
for starters).
2. i use plan 9's factotum. it does encryption right. my password list is
encrypted and managed by the system.
3. there's one password to remember. no fear of losing it.
4. ? really. tin foil hat thinking.
5. ah, there's your problem.

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.

Re:Encryption is too hard

[OFnow]

Yes, too hard to set up in email. Even on Linux, where support is built into thunderbird,
it is more trouble to set up than most would endure. And the certificate providers
are so focused on big-customers it's hard to understand how to even buy a cheap
non-expiring certificate! I use a free one from Comodo, but it expires in a year.
I'd pay for one but they explain nothing on the comodo web site on how to do that
(cost being a secret?)!

On Mac-mail and Windows mail I had little luck finding decent explanations of how to go about it
(maybe it's just me).

Re:Encryption is too hard

[Anonymous Coward]

As for Google they just made https the default for browsing Gmail, so yay for that.

As for having some kind of private key system, Google will never do that without having a backdoor or copy of the key that allows them to scan the email and add their relevant ads.

Re:Encryption is too hard

[cpghost]

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

Why would Google do that? They need to be able to peek inside the mails to display their context-sensitive ads, so end-to-end encryption is undesirable for them. And if they have your private key so that everything is transparent -- and usable as ad platform for Google --, what's the point of encrypting mails at all? Even though we can use FireGPG with Gmail today (or GnuPG or whatnot) as end-to-end encryption, as soon as more people start to do it, you bet that Google will react and block it.

Re:Encryption is too hard

[Anonymous Coward]

Re Email..

It'd be great if a large email provider used TLS for their email

Re:Encryption is too hard

[DrXym]

I think Google could enable crypto and still deliver ads. After all, you cannot encrypt messages to someone unless you have their key and most email is 1-way - mailing lists, purchase confirmations, ebay bid notifications, newsletters etc. Sites sending you stuff would still do so in the clear which is plenty to determine someone's interests. It is only when you have exchanged keys with somebody else that you can encrypt mail to them. Google could implement message signing and key exchange by default without materially affecting the quality of their ads.

The question still remains as to why they would bother. I suspect they would run a mile from the jurisdictional and legal mess entailed from implementing crypto.

No single reason

[Anonymous Coward]

An interesting take is the paper titled "why johnny can't encrypt" (no link, only a google away). That clearly shows lack of user education. And that in turn shows a plethora of problems. Such as there are:

People have no idea why it is needed. And then it gets worse. We haven't figured out how to make it as easy as sticking a key in the outside kitchen door. We haven't figured out how to show that something is trustable. For that matter, we haven't properly defined "trust". Currently it comes in two basic flavours. One requires you to specifically assign two values unclear and mutually confusing values to each and every key (how's that for transparency?) and any GUIs around it simply echo the already confusing messages from the underlying layers. That is, they don't FIX anything (nor should they), they just put a pretty face on the confusion (but that doesn't help). Two requires either declaring you trust yourself and getting everybody else to trust you declaring that, which causes most applications to ungracefully barf unless and until you kick them into submission again, or, and that is really a triumph of capitalism, you can pay someone else to declare trust and charge you through the nose for it. That gets even better when *cough* certain vendors *cough* effectively disallow you to not-trust some of those parties by adding them right back to the store of trusted parties after you've expliticly removed them, without telling you. Lovely icing, this cake has. The bottom line here is that these commercial parties only protect you from evildoers they aren't willing to take money from.

So, moving forward, go read the GNU privacy handbook, and if you are terminally bored, go read up on PKI, x509, the OpenPGP specs, but minimally do include Peter Gutmann's "Everything you never wanted to know about PKI but were forced to find out" on your reading list. Try and understand what both systems are really about.

Then it gets fun: Play a little game of what if? and ask yourself what you would do if you would get a signed email from your mom and it doesn't check out. Now ask yourself, how do you explain to your mom, supposing you got her to use crypto in email, what she should do if she gets a signed email from you and it doesn't check out. Do you have a clear and concise answer to this?

Compare with what you would do if you go to a website and your browser starts to complain about the certificates used. What do you do? How do you get the information you need regardless, and in such a way that you can trust that information? Could you trust it in the first place, given that it came in over an encrypted link? What does the certificate chain do to the trust you assign to the information received?

And so on, and so forth. Does the very act of casual encryption as currently done still make sense to you? Does paying a party you have never met for a certificate make sense for anything but shutting up the browser?

I for me think that we need a single system that can do both hierarchical and web-of-trust type key/cert trusting, and we need to re-think what this trust thing means, and what to do when trust fails. We certainly have not figured out the SOP of what to do with many of the innumerable ways crypto can go wrong. And until we do, using crypto remains specialist work.

VoIP and encryption

[JSBiff]

One of the most disturbing trends to me has been the rise of a lot of SIP based VoIP services (and client software) that offers no encryption. The thing is, there's been a couple IETF RFCs which specify how to secure SIP traffic for a few years, I believe (I'm not exactly sure how it all fits together, but I've read about SIPS, ZRTP, and SRTP).

Skype, of course, does use Encryption, so the most popular VoIP service is using encryption, *but* I'd like to see more VoIP providers offering it as part of their service.

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.

The Stone Cutters at work again

[ZuluZero]

Who reads your plain text mail? We do, we do!

Practicality

[Kjella]

I work with a vendor that implemented a nice secure upload facility for their support services. I'm sure it's secure, but I haven't been able to use it at a single customer yet because of firewalls and plugin blockers and who knows what else. So instead of using the plain HTTP which they so kindly removed, I now email everything to them instead. Luckily they got an intelligent script that'll parse mail and file it to my case.

Re:And pushing it would give false sense of securi

[Anonymous Coward]

Exactly!!! if malwareshitstorm.net is encrypted and the files are signed then why not get the new "codec" needed to get free Pr0n. After all it is all encrypted ans safe. After all who would encrypt something that is not safe and trustworthy.

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.

Re:HTTPS

[diitante]

Not true, you can have many https hosts on a single IP. 1. 2. & 3. solved with open source software. Unfortunately, PCs are now like cars, you really should show some basic ability before operating one. Sad, it seems that the attitude of most is that they have nothing to hide. It is a hollow argument perpetuated by ignorance.

Re:HTTPS

[Bert64]

How would you operate multiple HTTPS hosts on a single ip?

As i understand it, you either need to run it on multiple ports (and thus most proxies will block connections to your site) or by using SNI (http://www.ietf.org/rfc/rfc3546.txt) for which there is a lack of client support, nothing that uses the microsoft ssl libs (ie, chrome, safari) on xp, will support it for example.

two words....Key Management

[Anonymous Coward]

The problem with Encryption is not the protocols it is the management. Until Windows automagically installs and sets it up for you it is not likely to get heavily used outside of places where the expertise already exists.

From a storage point of view....

[HockeyPuck]

There's a large, but slow, movement in the storage area and that is encrypting data at rest. Either in the disk array or on the tape. Both require dedicated hardware either in the array or on the tape drive to be practical and not impact performance. While you can buy current generation tape drives that encrypt data on the fly the pain becomes managing the keys. Now there's plenty of solutions to do Key Management, however many customers I've worked with on this are always afraid of losing the key. We tell them to create a hard copy of the encryption key (or put it on a USB thumb drive) and put it in a safe. You have to be a lot smarter when it comes to dealing with encrypted tapes as it's nolonger in the event of a disaster, "ship the tape from NY to LA" and restore the data. It's also about making sure the correct key is present in the LA datacenter when that tape arrives.

Dealing with encrypted disk based data can be even tougher, especially when you're dealing with replication (SRDF/timefinder/PPRC/Snapshots etc..) Because now you're encrypting a volume/lun and replicating that between datacenters. So either the lun is de-encrypted when it leaves the array or you've got the problem of making sure that the lun/volume stays with it's associated encryption key.

What's wrong with data at rest from a security standpoint? It's not walking away with a tape/HD full of encrypted data, it's a compromised hosts that mounts the filesystem or restores the tape. Hosts always have access to unencrypted data. I don't see encryption being used within the application itself until everyone is willing to purchase encryption offload engines for all their servers as it's too taxing on the primary CPU to encrypt everything.

Critical threshold

[macemoneta]

It's like what's holding back Google Wave; there's no one to talk to. I've had encryption setup for about a decade. I've tried convincing people to set it up. In the end, I'm talking to myself.

If encryption is going to go mainstream, then setting it up and using it has to be the default configuration. Pretend it's a new version of Microsoft Word, defaulting to a new file format. There you go, everyone has upgraded (kicking and screaming).

Apple, Microsoft and Linux distributions need to establish (and export) new keys (or import existing keys) as part of the first boot processes, and use encryption if the destination user has a key by default. It's the only way it will happen.

It's the users...mostly

[Mr. Freeman]

Most businesses don't offer encryption because their customers don't demand it. Most users don't demand it because there is no penalty for not using it.

Sure, not using encryption can result in identity theft, someone sniffing your password, someone getting into your financial info, etc. But how often does this really happen? Most users perceive the benefit to be non-existent. "I haven't had a problem before, why should I change now?". Having your financial information ruined is something that always happens to "other people".

Companies have a financial incentive to discourage encryption because it costs them money (regardless of how little) to implement it. They also have financial incentives to poorly protect and secure their customers' data and to lie to customers when their data is leaked.

Oh, all of our customer's credit card numbers, names, addresses, and other personal information is now available on the internet because someone lost a laptop that should never have been taken outside of the building? Let's just cover it up.
Someone leaked to the press that we had a security breach? Let's lie and say that there's no risk to customers.
People are now having their identity stolen because of the leak? let's sue to keep people quiet and offer tiny settlements with NDAs.

We're not going to see encryption become widespread until:
1. Customers demand it. (Which won't happen anytime soon, see above)
2. A bunch of congressmen have their personal info leaked because of a fuckup and they pass some laws about securing personal info.

Re:It's the users...mostly

[mlts]

You hit the nail on the head here. Encryption, and security in general has no ROI. Therefore, a number of businesses will do the absolute minimum to keep up appearances. They will happily take the risk of a breach, because they can always put out an apology, push out a GPO blocking changes of the average company user's wallpaper and say they increased security. Other places believe they can just call a contracting team to clean up the mess, believing it will not happen.

You won't see serious security and encryption demands coming from the private sector. This will have to come from governments who are tired of intrusions and passing strict data privacy laws with data retention limits. Only this will get the private sector to pay more than just tired old lip service to security.

Re:It's the users...mostly

[muckracer]

> Encryption, and security in general has no ROI

Unless you're Airbus who lost a $6 billion contract due to snooping of their communications or any number of companies, known and unknown, who had their product data leeched off the ether in some fashion.

Re:It's the users...mostly

[mlts]

That is true. However, we are the people who beg the PHBs for a budget so we can have a decently working IDS, SecurID cards so VPN users who get compromised by malware on their laptops don't allow remote intruders, or allow for a sane security policy that actually works.

The PHBs don't see that. They see that they are paying money for something that does not bring them anything. Instead, they spend the $100,000 to get the highest sales guy a new BMW so he can impress clients. The PHBs don't learn by example. They think Airbus or other incidents like that are just bad luck. Even if disaster strikes, there is always some IT guy that can be thrown under the bus.

It's not worth it.

[tjstork]

People don't think it is actually worth it. Besides, HTTPS alone doesn't halt man in the middle attacks, when user's browsers can accept bogus certificates.

Free exists STARTSSL.com

[Anonymous Coward]

Free server certs exist STARTSSL.com

For awhile, the CA wasn't included in the Microsoft list, but that has changed for over a year.

What's wrong with FTP?

[Anonymous Coward]

If what you are distributing is Open Source or Public Domain, then FTP is just fine. I don't see a problem with half of your communication being unencrypted, provided that same half is not confidential in nature. Encryption should only be used for messages that you would object to seeing on the front page of the newspaper the next day -- but if that is the case, perhaps you shouldn't be sending those messages over the 'net at all!

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

Re:FTP would be dead

[gregarican]

Though I haven't kept up with SSH development on Windows

Actually this Swiss Army knife helps me a great deal in the Windows-centic world I support for admin tasks where I work. Been using Putty for over 5 years now for everything from SFTP to SSH remote commands. Works fine for me. That and some Ruby scripting help automate a great deal of my work :-)

Re:FTP would be dead

[swillden]

Now imagine how much better it would be if every Windows box had SSH client and server installed by default (though the server should be disabled until enabled by the user).

Re:FTP would be dead

[gregarican]

True. Just testing out my Windows 7 pro machine a second ago I found they removed telnet.exe from the system. So instead of adopting a standard set such as SSH (which is unlikely seeing their conflict with FOSS) they have dropped other long standing, less secure components.

THis is topical

[Anonymous Coward]

FUD

I've been looking into putting TLS on my mail server. The instructions are not very clear. It seems certain that I will require a 3rd party certificate. But I don't find anyone offering a TLS certicate; only SSL. I'm assuming that an SSL certicate is what I need but NOBODY says that; you know what happens when you assume.

Then there is the cost. They do cost and it is not a one time cost. The certificate system does appear to be structured to maximize cost. Right now, you have either a self-signed certificate or a 3rd party certificate. How about a self-signed certificate that is authenticated against my 3rd party certificate?

It occurs to me that TLS could be used to reduce SPAM. AFAIK, most spam is sent by spambots. If all legit mail servers used TLS and spambots didn't have access to a verifiable certificate then they would not be able to operate.

You missed the point of encryption

[tacokill]

Isn't one of the goals of encryption to make your message indecipherable from random noise?
How would one know whether you downloaded an encrypted file or just downloaded some random noise?

Re:You missed the point of encryption

[Fareq]

because it is much more likely that you waited for the 300GB to download because you wanted the data, rather than just to exercise your internet connection downloading the next 300GB from /dev/urandom.

Unless you can get a significant majority of internet traffic to actually *be* random noise with the appropriate statistical foibles to match your encryption scheme, this just isn't going to work.

Re:You missed the point of encryption

[Onymous Coward]

Also, you could get a significant percentage of your own downloads to be noise. That would also work.

So, as much as you can be compelled to decrypt your data is proportional to how much noise may be compelled to be transferred.

Re:You missed the point of encryption

[Onymous Coward]

Rubber hose?

But, yeah, there has to be some plausibility to your downloading noise. I mean, noise that's as substantial in volume as your encrypted traffic. (So downloads from random.org might not afford you plausible deniability.)

Why?

[jaygridley]

Why should I go drop $1000+ for a SSL cert from Verisign for my website when its not passing any sensitive/confidential information "just because"?

(A)pathetic Users

[Tony Stark]

The biggest problem with encryption and security in general is the user. The user wants everything out of the box and as easy as possible. I run across way too many home users who don't even have a login password on Windows. I've been trying to use PGP for email for years but I can't get anyone else I communicate with to use it. Most likely even if they did, their passphrases would still be things like "password" or any other password no no's. It's not even a matter of educating the user anymore. A lot of educated users still just don't care. If it's not something they're interested in, they won't do it. Striking the balance between convenience and security has become and impossible task because in the end convenience (read: laziness) will trump all.

"Free" and "Easy"

[ExileOnHoth]

Maybe when getting a server cert is free/easy people will do it...

I hate buying/installing SSL certs for clients. But:

How exactly are we supposed to create an "identity verification" process that's "free?"

The whole point of an SSL cert is supposed to be that someone, before issuing it, did some good old-fashioned sanity checking against the application and said, "yes, this person really IS the owner of the domain BankofSeattle.com"

How are you supposed to make that process "free?"

I wish it were easier. I do it all the time and hate it. So this is a sincere question.

But let's not assume it's ever going to be "free." Free, by necessity, means no human is putting any labor into it. Unless we are going to create an open source non-profit SSL issuing authority.

Ooh, sounds so very fun and stimulating. Any volunteers?

Re:"Free" and "Easy"

[compro01]

The whole point of an SSL cert is supposed to be that someone, before issuing it, did some good old-fashioned sanity checking against the application and said, "yes, this person really IS the owner of the domain BankofSeattle.com"

How are you supposed to make that process "free?"

A simplest method I can think of would be to authenticate ownership of the domain via the contact information (easiest would be email address) on the domain registration.

Re:"Free" and "Easy"

[omb]

A very good question, BUT you are starting from the wrong point, you know the old Irish saying " ... I wouldn't start from here". The first point is that the CA Authority Cert idea was designed by the naive or greedy or both and was endorsed by the stupid. It is that way so Verisign et al., the greedy, can extort money from everyone.

The checks are stupid and are easily worked round.

There are three cases (a) purely personal, need to be initially issued AT BIRTH, or on later demand by the BIRTH or PASSPORT agency of your country, with the same process as usual and signed by a Country key which the UN runs a registry for; (b) Corporations signed on incorporation by the registry, whose signing keys are signed by the Country government; (c) special keys needed for Miscellaneous reasons signed by third parties with government signed keys, for a fee.

Essentially we now only have (c). We also need a rule that says any key signed by two valid personal (a) keys is valid for (a) & (c) but not (b).

Finally, even if it is the real "Bank of Seattle" dosn't mean you are safe, of course.

Each G20 government will have to have a small office to run signing for their own government Departments and a backup of the UN country key list, and hold a list of revoked keys; any key can be revoked by their owner or by Court Order.

I have left out a lot of detail, of course, but the job is about as complicated as the dog licencing in my Switzerland.

Re:"Free" and "Easy"

[Onymous Coward]

Well, Perspectives performs basically the same function and it's roughly free.

http://www.cs.cmu.edu/~perspectives/index.html

I'd like to encourage more folks to look critically at this system. You can think of it as an analog to public key servers, which are a free solution for associating public keys with persons.

Re:"Free" and "Easy"

[GenSolo]

When I get an SSL certificate from my registrar, the fact that I am logged into the account that owns the domain should be enough proof. Since the computer can do this, it could be free. Frankly, any registrar should be able to issue a free normal SSL certificate, and if any of the big ones started this, they would all be pressured to follow suit. They make the big bucks on the EV certificates now anyway.

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.

Re:VS Electronic-Arts

[julesh]

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

You can guarantee there's a dev team and a DBA who sat over there in EA's offices, tearing their hear out en masse over this decision. Fact is, it happens all the time, and the cause is very simple: management writing functional specifications of software. Somebody, somewhere, put on the functional spec that there must be a password recovery function that sends your original password back to you. That person didn't understand encryption, and was too sure of himself and his ideas about how the system's supposed to work to listen to lowly developers about whether or not it's a good idea. Of course it's a good idea. He's the boss for a reason, you know?

Re:VS Electronic-Arts

[siloko]

Ha ha! I was subscribing to a well known literary magazine here in the UK via email and the subscriptions lass at HQ asked me to send my credit card details in a return email. I pointed out this was ridiculous and phoned them instead. About a month later I got a phone call from the magazine thanking me for raising my concerns and assuring me that processes were in place to ensure a more secure procedure was followed in future!

Re:VS Electronic-Arts

[IBBoard]

I can understand EA doing it - after all, they're 'just' a games company - but the one that really makes me laugh/cry is the British Computing Society. They're the professional organisation for IT-related careers in the UK and they send you your actual password! Of all the places that I'd expect decent security from, the nationally (possibly internationally) recognised organisation for IT pros would be it, but apparently not.

Re:VS Electronic-Arts

[Ginger Unicorn]

Two women showed up unsolicited at my place of business with a cheap glossy business card in a plastic holder claiming to be from barclaycard asking if i wanted to sign up for a barclaycard PDQ machine. Before filling in almost every single confidential detail about my business and bank accounts and signing a piece of paper I wanted to verify who they were.

They were really taken aback and said that no one had ever asked to verify who they were before. They told me to phone the number on their "ID card" but that i had to say they were from some other company who were presumably subcontracted on a commission basis by barclaycard. I got an answer on the phone and gave their names and the guy on the other end confirmed their names, so I asked him how I was supposed to know that this number was legit. He tried to cover the receiver but I could hear him asking some other guy in the room, then the pair of them sounding stumped like they were just shrugging at each other and had never heard the question before. Then they told me to phone barclaycard's main switchboard and get put through to the security department.

I got barclaycard's main number from their website, but when i rang it, i spoke to about 4 different people none of whom knew of this department and when i tried to explain what i wanted to know, they just kept asking me what my credit card number was even though the request was regarding a pdq machine not a credit card.

The two women also needed my business partner's details and signature and he wasn't around and they were going back to london the next morning so they wanted to go to his house to get him to sign something. He couldn't do it so they wanted me to post a copy of the papers to the woman's home address. This was incredibly fishy, so I took down the woman's driving licence details that matched the address. Long story short, it turned out in the end that they were from barclaycard. Abso-fucking-lutely astonishing.

Re:VS Electronic-Arts

[GravityStar]

Proving that you are who you say you are, is hard. Your id card? That could be a fake. The phone number on the website? The website could be a fake. The phonecall to that business? Kevin Mitnick could have entered that building an hour ago and is just waiting to confirm to you that 'yes sir, those are our salespeople'.

Re:VS Electronic-Arts

[Ginger Unicorn]

There a difference between "proved" and demonstrated beyond reasonable doubt. It depends what you decide is a reasonable doubt. What I experienced was, in my opinion, laughably inadequate and practically useless. I would not find it reasonable to suspect barclaycard's URL to be the subject of a DNS poisoning attack on OpenDNS's servers. Although possible, it's so unlikely that if it did happen I would just consider myself extremely unlucky and deal with the consequences.

"Most websites" don't require HTTPS.

[mrspecialhead]

"Most websites are still using unencrypted HTTP." ...and should be unless security is specifically required as a priority. Pick the right tool.

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.

Encryption is brittle

[Anonymous Coward]

When systems fail they often fail gracefully and often provide you a hint of what's failing. Your image server is broken? Ok, no images but you still get the text and it's plainly obvious there is a problem with the image server.
When encryption fails, you are usually dead in the water with no inkling of what went wrong or how to fix it. Letting you know what is wrong and how to fix it is often considered a security flaw (for example, the classic approach of being vague about which part of your username/password combo is wrong).

Encryption is either all working or all not working by its nature. It is brittle by design and a pain to use as a result.

DNSSEC has nothing to do with encryption

[Anonymous Coward]

DNSSEC has absolutely nothing to do with encryption. Nothing is hidden and the resource records are still in clear text. DNSSEC is about integrity of the resource records.

But DNSSEC can be a catalyst for encryption technologies. DNSSEC allow you to put certificates, ssh-keys, etc in the DNS in a secure way.

JB

Encryption export rules

[Antique Geekmeister]

In the USA, there are nasty regulations on the export of encryption, which been included under the Arms Export Control Act (http://en.wikipedia.org/wiki/Arms_Export_Control_Act). This law has been extended and manipulated in unconstitutional ways: this used to be done as regulations under the Customs department, but were found to be unconstitutional there, and were transferred to the Commerce department, where they've been made somewhat more sane in the last decade but remain burdensome to software authors.

These regulations are not directly controlled by Congress, they're authorized by the Arms Export Control Act, so what is actually in them is confusing and serves the goals of the current administration, not Congress. It seems clear that whether the regulations are designed only to preserve the ability to eavesdrop on foreign communications, their direct effect is to protect the ability to eavesdrop on almost all civilian communications.

The case of Phil. Zimmerman, the author of PGP, being convicted of exporting weapons under this act simply illustrates the point. PGP could have been released for general use 10 years earlier, and incorporated in every email client in the world as a matter of course, if it were not for this regulation. DES suffered similar regulatory problems in the 1980's, and SSL suffered them in the 1990's and still suffers them.

What about..

[Anonymous Coward]

ease of use?

For example e-mail: it is hard for the majority of people to generate a key, select the appropriate strenght/algorithm, know the difference between public and private keys, notify their friends about their keys (and key changes). It is just too much of a hassle, so even if you want to use it yourself, the majority of the people you communicate won't.

Take skype for example (though closed source), they claim to encrypt your calls and video chats using 1024bit public/private RSA keys. The end user doesn't even realize it happens. The same goes for SSL, from the perspective of the end-user it 'just works'.

Unless there is a real necessity, people won't make an effort and just go for the easy way. Therefore it should be easy.

It's not just the Police...

[MrSteveSD]

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

In the UK, local councils can view your phone and email records, unbelievable as that is. It is a power granted to them under the RIPA Act and it's not just a theoretical power either. They have used it to spy on people for all manner of reasons. Due to these intrusive powers, public usage of encryption etc should be much more common than it is.

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.

Re:Encryption Ensmyption

[chandoni]

Financial sites? I'd settle for them letting me use the hyphen in my name.

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

[jonaskoelker]

it *still* takes forever (days) to re-sign our domains, something you are supposed to do monthly.

So what? As long as it takes itself days and doesn't take your days to do the job, and it's allowed to start that number of days before it has to be done, what's the big deal here? Don't you just delegate the work to it and consider yourself done with that task?

Re:Thoughts on Email and DNSSEC

[vanyel]

The corollary is the time it takes to make a change to a domain, something, as an ISP, we do a lot of. There's also having to integrate support into the tools we use to manage domains. I'm actually planning on doing it, but the more barriers there are, the more subtractions from priority...

Re:Thoughts on Email and DNSSEC

[ThrowAwaySociety]

vanyel,

Please remove the extraneous text from the bottom of your message. It is unprofessional and may distract outside clients.

Also, please use our company's standard disclaimer signature, per our policy on email security.

Thanks,

Your Boss.

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.

Re:Thoughts on Email and DNSSEC

[Anonymous Coward]

Oh yes. Most people are using webmail now anyway. I don't understand why they find it easier to learn several web interfaces than one email client and why they trust some server over their harddisk, but that's how it is. I don't know of any webmail interface with PGP support. GMail does verify sigs now, but for encryption you still need a browser plugin such as FirePG.

And the frontends suck. To use OTR in instant messaging, you don't have to do anything. It will switch encryption on automatically when both parties support it. To use PGP in Thunderbird with Enigmail, you have to read through long manuals, generate keys, find a safe place for your private key, and do all the en/decrypting/signing/verifying by hand. Why can't it just look up every new recipient's email address in the background and encrypt by default without me having to click on anything?

It's almost as if developers didn't want normal people to use encryption. Which makes it more dangerous for the geeks that do use it, because it singles out their traffic.

IDS/IPS is ineffective with everything encrypted

[haus]

Corporate / Government security operations centers do not want everything to be encrypted, because it makes it much harder to determine when someone/something is doing something that you do not want them to do.

The Government can't read it

[0p7imu5_P2im3]

The fact of the matter is that the CIA and NSA have their hands so deep in all the tech companies pockets that none of them want to make it easy for fear of losing the government funding or monopoly protection that those government agencies provide.

It's not necessary

[Evilclicker]

First of all HTTPS is totally unnecessary for 99.9% of the internet. The VAST MAJORITY of content is static, or dynamic but doesn't change per user, so it's not generally unneeded. HTTPS adds cost and complexity to the site that is probably not even necessary. Second, encrypted email is nice, but also typically unnecessary. Think about the majority of emails you send? Are you sending credit card numbers and social security numbers in your email? No, chances are you saying "Bill slept with Jan last night" or some other stupid BS that nobody really cares about. Even in company email it's generally something like Did you do this? No, ok. However, in company email it's a little different because the mail server is behind a FW anyway so again, encryption becomes unnecessary unless you're trying to hide something from the employees. As for FTP, seriously? Are we transferring bank account numbers via FTP now? Last time I checked FTP was just used for transferring random files, and assuming you don't have some CIA top secret documents you're transferring via FTP for some strange reason, it's perfectly fine. It's not like it's that hard to setup SFTP if you really need it, but chances are, you don't. In summary, you must not be in the IT field or you would know that the general consensus is make it easy and usable. Security is only a concern when private data is really an issue (CC/SS/etc), and all of those type of sites are properly secured. And just in case you haven't noticed, every encryption technology that has ever been created, has already been cracked anyway, so it doesn't even matter if these technologies are used, they can still be cracked, and the data read. I'm betting the sheer volume of traffic over the internet is security enough.. nobody has enough time to go through all that.

Complexity

[pr0f3550r]

People don't understand encryption and so they don't use/insist on it. Moreover, it is usually that thing that gets in the way when they want to be productive. I once saw the security manager at our company spend months specially crafting a security policy for the company and then sought board approval so that he could reign in the CEO and COO anytime they balked at the policies and procedures put in place. This is the 'iron fist' rule which does more to educate than any other tool. When forced to go through the hoop many times, the process becomes simpler. The lesson to be learned here is to design systems that security is understood and mandated. That education and knowledge transfer become mandatory and not optional. This also helps to illustrate and point out the stumbling blocks for poorly designed or cumbersome systems. For instance, ClearOS provides only 2 factor OpenVPN configurations for client VPN access to the network. Because key/password authentication is mandatory, efforts are made so that user key self-service is provided. If another method were provided that caused less friction, then the users would not sufficiently test/validate the process, training, or education of the secure method.

This surprises you?

[sirgoran]

Please. I use to work for a mid-sized company that dealt with Fortune 500 companies. Companies that required us to use specific programs for FTP and accessing their systems. Despite several warnings, several long talks, we still had one account manager in our company that refused to follow the guidelines set out by our clients and used IE for all of his FTP traffic. We were dealing with companies paying us millions and we couldn't get one jackass to follow the rules. Even under the pressure of the IT department and the possible loss of a client couldn't get him to change his ways. Rather then fire the idiot, they moved him to a different client. Just goes to show that even when you beat someone over the head with rules, guidelines, and facts, they're still going to do what they want to do.

- Goran

Re:This surprises you?

[Mr. Freeman]

In a business that sounds like a personnel issue rather than a security one. I mean, what if they guy "simply refused" to arm the alarm after he left the building, (obviously just an example) or "simply refused" to lock his office door, or "simply refused" to take any physical security measures. Would the company just let him to continue to keep working there? If so, they probably deserve the consequences when they loose a client and get sued for releasing all sorts of confidential data.

Anyone who "simply refuses" to follow security policies after a warning or two should be promptly sacked with a black mark on their record. Not just "asked to resign", but sacked and escorted out of the building immediately.

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

needs industry to introduce as standard

[DaveGod]

People aren't going to implement encryption, but their software might implement and do it all for them.

The consumer mindset is that if it was important the software would take care of it for them. If that sounds like criticism, well it is, but not of consumers. They should be right, partly because they think they are paying (in $ or advert eyeballs) for the software to take care of whatever is important, and partly because it simply wont work any other way. It would be pointless if I installed encryption software on my email client, because I'd need to get everyone I email to have compatible encryption and for them to use it.

It shouldn't even take much industry co-operation to get the ball rolling, according to this more than half of email is conducted through MS clients. Add Yahoo, Google and Apple and you have 90% (admittedly, some of those clients are quite old).

Spaces?

[Mathinker]

You might have already thought of this, but do you ever use passwords which start or end in whitespace? Or perhaps include non-printing Unicode characters?

OTOH, I recommend using vendors who are less clueless, rather than more. Thanks for sharing your experience.

Re:And pushing it would give false sense of securi

[Bragador]

If you only encrypt what is sensitive, you are flagging your communications as being important. If everything is encrypted, this protects even more your sensitive data. This is a good reason to push encryption everywhere.

I don't see the value either

[Anonymous Coward]

What real attacks does HTTPS with a self-signed cert protect against?

The first time I visit your website, it provides no protection at all against a MITM (Man In The Middle) attack.
If the browser caches the cert, then it provides protection the second time I visit your site. However, if you then change your cert for any reason I'll get a bogus security warning. And that's the exact same security warning I'd get if there was a MITM attack, so how do I tell the difference?

Now I suspect you're thinking of passive evesdropping... that's such an old-fashioned attack. Modern networks are switched. So almost any scenario where I can evesdrop, I can also MITM. Even if you're using an unencrypted WiFi access, I can just set up my own base station and arrange for you to connect to it.

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.

Encryption is not always a good thing

[junglebeast]

Sure, everything could be encrypted but encryption data requires more bandwidth to transmit the same amount of data. This would make your internet connection appear slower. It also requires more processing power to encrypt and decrypt, which again, would make the internet appear slower for the end-user. It's not just about speed. Because of the increased computational effort, it would require more power to do equivalent tasks. This means laptop batteries would not last as long, and it would increase greenhouse gas emissions because ultimately that means power plants would have to produce more power. For sending important private data, sure, encrypt that stuff...but let's not all get paranoid and ask that EVERYTHING be encrypted.

Because the help to get there is lacking

[Anonymous Coward]

As I see it, the problem is less with the technology, and more with providers' lack of steering users there:

1. While this is definitely better these days, in the past, it was common for POP3 tutorials from e-mail services, or FTP tutorials from hosting providers, to describe the unencrypted way of getting in - no doubt because it was the easiest way to get the customer what he wants, and least prone to errors. Many people who learned how to do what they're doing are probably not even aware their connection is unencrypted, or that they could, in fact encrypt it. And even if - they'd probably argue "What for? Why would anyone want to steal the password to my e-mail account?".
2. Redirects. It's a very simple thing: Automatically redirect users to the HTTPS version of websites. No user thinking involved - just set it up and let them enjoy the shiny padlock. Yes, the very large players do this automatically for logins, but the vast majority of small websites, e.g. mom and pop running an osCommerce installation, do not. The user enters through unencrypted HTTP, and proceeds to do what he wants unencryptedly. Had the server just redirected him to the secure site as he entered, he would do the exact same stuff, not having to waste a thought about security, and would still be secure.
3. Lastly, setup. I have a small VPS, and I, in fact, recently tried to set up SSL security for the sites I host. I can't. At least not within a reasonable threshold of effort. Why? Because SSL sucks to set up for virtual hosts. The only thing I could easily do is set up one certificate per IP, and I only have one shared IP for all accounts. Add to that Mozilla's oh-so-brilliant decision to auto-block self-signed certificates, and you end up in a situation where many smaller and non-corporate admins would like to employ secure connections, but they can't, because the setup is needlessly complicated, the easy ways to do it are being blocked, and basically the only way to actually get there is shell out more money.

The Mozilla team justified its decision to auto-block self-signed certificates with the fact that one can get "real" certificates for free from StartSSL. Well, I went there. I tried. I utterly failed. Because having a free certificate for every domain doesn't mean jack shit if you can only deploy a single one - or would have to dig deep into the config for hours to get it working for all of them.
I mean, we're talking about a situation where it's easier to tell all users to whitelist an "invalid" (self-signed) certificate than to get real certificates working properly. ...and that's all not taking into account that certificates expire, and once you committed to going "real", getting new certificates for all sites becomes a periodic task.

Summary: On principle, the technology works fine, but The Powers That Be are not using their powers to quietly encourage its adoption (e.g. by just not offering unencrypted FTP anymore, period), and those responsible for the technical side have created a system where it just sucks to offer encryption.

If the users are not encouraged to use encryption, and the admins are discouraged from offering it - how prevalent can it get, really?

The reason is caching issues vs. browser rules...

[jamesivie]

Most browsers still have a warning that cannot be bypassed whenever unencrypted content is linked on an encrypted page. The existence of this warning assumes that the end-users understand the basic HTML security model (laughable in the vast majority of cases) and that the server code is buggy and might allow secure data to be sent insecurely. This prevents caching of items on encrypted pages that really should be cacheable (most css, most images, most flash, most javascript). Using SSL despite the lack of caching reduces website performance and increases hosting costs (so that's not likely to happen except when the added security is worth the added cost and wait). IMHO there should be some kind of explicit unsecure-data-within-a-secure-page protocol (httpu://? httpp://) that prevents the browser warning but allows unsecured css/images/javascript/flash/etc. within secure HTML. This way, all those items could be cached at any point along the way (proxy servers, browser, etc.), and we could still provide warnings for buggy websites that unintentionally included content with http://./ A one-time warning similar to the "switching to secure!" warnings could be included for security-paranoid users, and a different icon for pages with this type of content could be used. Ideally, for those same paranoid users, there'd also be a way to quickly asses WHICH items on the page were insecure, like a button that turns on/off the display of either the secure or the insecure parts of the page.

Webmail killed email encryption

[dokebi]

Back in the late 90's I was hopeful that easy to use encryption plug-ins for mail clients would finally bring encryption to the masses. But when gmail came along, with a Gig of space and full text search through your past, end-to-end encryption was finished.

Currently I'm hoping for crypto id tokens to catch on to stop all the id theft issues, but I'm not exactly holding my breath.

I think the only feasible thing for that is for the Government to hand out crypto tokens with a central auth server, and severe penalties for abuse (much like mail fraud), so that at least there is one *good* way to be identified as who you say you are.

Say what you will about Big Brother, but at least voters can do something about government abuse of personal information. Corporate abuse is absolutely unregulated.

Re:And pushing it would give false sense of securi

[nine-times]

Really, most things which should be encrypted - are.

First, I'll tell you that I don't think that's true. Even in the past few years, I've seen a ridiculous amount of confidential/sensitive/secure information pass over the Internet via unencrypted channels. A lot of people still use FTP and send sensitive information via email without any additional protection. Perhaps you're encrypting everything you should be, but many people aren't.

But even if it were the case, the idea that we should only encrypt the things "which should be encrypted" is problematic too. I'm posting my response here, but I mean to respond to all the people who are saying encryption is generally unnecessary. I'm not saying it's wrong; you may be 100% right that "There's no reason to push encryption everywhere," but it's not so simple; there are also drawbacks to this approach.

The first drawback is perhaps a little paranoid, but it's a little simpler to wrap your head around: by only encrypting sensitive information, you're giving potential attackers a clear target. Metaphorically, if you're trying to protect a bunch of solid gold needles, it may be better to hide them in a haystack rather than in a locked box with the words "SOLID GOLD NEEDLES" printed on the side. Relying on "security through obscurity" alone is a bad idea, but that doesn't mean that you want to share more information with your attackers than you need to.

The second (potential) problem with your line of thinking becomes clear if you translate it into real-world terms: "I have all my valuables locked in a safe in my bedroom, so there's no point in locking my house. After all, there's no point in pushing locks everywhere, especially if it's going to make people think that everything is safe just because it's locked." See some problems here? No, the lock on my house doesn't do much to stop a determined and skilled thief, and most people don't want steal my non-valuable stuff. On the other hand, we don't think it's too silly to want to employ a basic level of security for our physical property. (It may be worth noting, however, that there are people who believe it's a shame that we all lock our houses. I've known people in small towns who don't lock their houses.)

The third possible problem is much more vague and perhaps paranoid, but I believe it's still worth considering: we don't really know what the value is of the information being passed around unencrypted. I'm not talking about people accidentally posting something sensitive through unencrypted channels (though obviously that's a potential problem); I'm talking about people posting seemingly harmless information that may still be useful for nefarious purposes.

Again, I'd like to take this back to real-world terms. Imagine a thief wants to steal something very valuable from me, and there's only one place that I go where there's any security. It's a very secure room with an unpickable lock, and because this is the only secured location, I've already given him a pretty good idea where my valuables are hidden. How can he get in?

Well he doesn't have to pick the lock if he can pick my coat pocket and get the key. He doesn't need to pick my pocket if he can get me to take off my coat. He doesn't need to get me to take off my coat if he has access to the closet where I store my coat. Basically, he doesn't need to confront my security measures head-on, he just needs to find the weakest point and exploit it.

So let's go back to computer security. Let's say I want access to your bank account. I don't need your password if I know the answers to your secret questions. What's your mother's maiden name? Well, I can read your email, and I see there's an email to a guy named "John Smith" where you call him "Grandpa". Since your last name isn't Smith, it's a pretty good guess that your mom's maiden is Smith.

I know, in real-world cases hacking a bank account isn't quite that simple, but I only mean to illustrate how seemingly inn

There's an obvious answer - most people don't need

[Johan Welin]

Seriously, what data do you absolutely require to be encrypted? I would speculate that most data that one transfer across the net will impose no harm to yourself or your peers. Sure some data will eventually be picked up by some services and may, or may not, be used for commercial uses (ad's maybe). If you don't want that you can often opt for other services or use encrypted protocols.

A closely related issue

[Aram Fingal]

The use of digital signatures in email is closely related to encryption because it requires the same PKI. That may end up being the driving force because of the increasing sophistication of phishing. The institution I work for is now frequently attacked with phishing emails. Our help desk is constantly answering questions about whether a particular email is phishing or not. What's even worse is the people who don't call (and don't know how to smell a phish). We are dealing with hundreds of compromised accounts per year because of phishing. I think this is not only a compelling reason to start authenticating email with digital signatures but also to integrate the recognition of digital signatures into our spam filtering.

Use Cost and Benifit Analysis for an answer!

[zarthon]

Just like anything encryption has a cost. This cost is actually pretty low. Keeping the government loop and comply with regulations so that terrorist plots are detected early is simply part of this cost. There is an optimal use of encryption where it's marginal costs are equal to it's marginal benefits. We may fall short of this optimum if among other things there is imperfect Information about the costs and benefits. #1 The the benefits are hard to measure and unknown. #2 There are social concerns because of a lack of consensus about what constitutes The Greater Good and this undermines trust. People want their communications encrypted but not the communications of others. The costs of encryption are very low and the technical knowledge is common and equipment is ubiquitous. The problem is not primarily technical. The largest technical problem is related to benefit estimates. Other security holes may allow breaches. Encrypted channels must be decrypted at the end points. If the end points are spyware invested sieves then encryption is irrelevant. Encryption use is not promoted. It's better to have most channels open and encrypt only the necessary information. A start would be to create a collection of ROI and Cost/ Benefit analysis for enterprises over type, industry and size, and for various individuals and households over education level, income, and wealth. Create public policy briefs about encryption. There is a lot of communication people can't exploit and so people don't care about it. For example who cares if someone finds out I am reading web pages to try to prevent razor burn and read a web page on gentle ex-foliation. At least the office would know I am trying ! Who pays to disseminate the marginal cost and benefit information? You don't know when encrypted conversations would have been breached or the costs that would have been incurred from the breach. The costs of breaches are a large part of the benefits of security and must be estimated.

On "let's just HTTPS the login process"

[jonaskoelker]

there's no point encrypting things that are not usernames/passwords/sensitive information.

Except in the most rare cases, there's no point in encrypting user names (unless you want to argue by semantic shift).

However, whenever you do anything that requires you to be logged in (i.e. post a comment), you should have to prove that you're the rightful owner of the username you post under.

In other words, in every transaction you send some kind of secret to slashdot that proves you're you.

I want that to be guarded with HTTPS. I don't want anyone else to prove they're me. That means everything I do while I'm logged in has to be HTTPS-guarded.

The sooner web code monkeys get this, the better.

What's the purpose of encryption if it's defeated?

[jonaskoelker]

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.

And then only let the government and government-approved network administrators have packet sniffers, to avoid the black hats having them? Except that the Nigerian government could hand them out to any Nigerian if it felt like it, so we need trade embargoes, and...

Exactly what's the point of encrypting something if information will still leak out of the encrypted packets?

Or---when in debugging mode you could send some insensitive unencrypted traffic. That way, people can have their encryption and network debuggers can have their not-encryption.

Cost and Lack or Windows sFTP support

[HannethCom]

As odd as it may sound, there are many companies willing to pay tens of thousands of dollars a year on maintaining and making changes to their web site, but some of these don't want to pay $300 a year for a security certificate, even if they pay for an expensive security system to be written.

As for secure FTP, some people don't want to download a separate FTP client, they just want to use what is built into Windows, and I don't think that supports sFTP. You also have to pay for a cert.

Bad analogy

[jonaskoelker]

How often do you speak out loud in a public place? None of that is encrypted. Someone might overhear you.

When in a public place, you can see who's there. How often do you speak out your VISA card number, expiry date and three-digit security code in public? Okay, that is encrypted. How often do you speak out your Gmail password in public? Or the ssh password to your computer? How often do you leave your wallet and car keys lying around in public?

Not needed

[Anonymous Coward]

The reason that most traffic is not encrypted is simply that encryption is unnecessary for most traffic. Does slashdot need to be encrypted? Arguably, there are some things out there that should be encrypted and aren't, but the basic answer to your question is that most traffic isn't very sensitive.

One major problem is spam.

[Anonymous Coward]

How is a mailbox provider going to analyze all those potential spam mails when everything is encrypted?

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.

Re:False sense of security

[SanityInAnarchy]

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?

Nope, because right now, I can educate people who are with a very simple message: "Make sure there's an https in the URL bar. If you get a green bar, even better."

In fact, I often trained people (before it became the default) to always go to https://mail.google.com instead of gmail, in order to keep the entire session secure.

With the giant Firefox warning, they'd at least have a clue something was amiss.

Suppose it was less threatening. How much good does it do to train someone to go to https://mail.google.com/ if they could be MITM'd by any idiot in a Starbucks? How much attention are they going to pay to the warning message they'll get?

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

True enough, but at least they're not wasting money.

But at least without the false sense of security, they'll listen when I try to teach them. Too many people have an attitude of, "Oh, I have antivirus, so I'm safe." Basically, they delegate security to some piece of software that comes in a box, so they don't have to think about it, which is exactly the wrong way to go about it.

Put another way: If someone has a general sense of malaise and they take a homeopathic remedy, they're wasting their money. If they've been shot, broken a leg, or had a heart attack, I hope they're getting some real medical attention, and not waving the EMTs away with, "It's OK, I've got St. John's Wort!"

What's holding back encryption?

[Sir_Real]

This is easy. It's not worth it. The losses attributable to "not encrypting" something are less than the cost of "encrypting everything" and managing it. It doesn't hurt enough yet. Wait till we get a large scale breach of a service like alt.com or adultfriendfinder. You will then see some action. Capitalism is not pro-active unless it's clearly profitable and has little risk.

You FAIL with "encryption is good enough"

[jonaskoelker]

where for most uses encrypted communication alone would be sufficient

Okay, here's a thought experiment:

Suppose you have a two-way key exchange protocol. That is, Alice sends something to Bob, then Bob sends something back, then they can talk encryptedly.

Suppose when Alice sends "Hi Bob, I'm Alice" to Bob, that Alice's ISP, Eve, grabs that bit, then sends her own message to Bob saying "Hi Bob, I'm Alice". Bob returns something ("Oh, hi Alice, Bob here.").

Now Eve is talking to Bob (and vice versa) encryptedly, and Bob thinks Eve is really Alice.

Oh, but we left Alice waiting. Now Eve returns "Oh, hi Alice, Bob here." to Alice.

Then Alice is talking to Eve and vice versa, encryptedly, and Alice thinks Eve is really Bob.

So when Alice sends "I love you, Bob" (the secret message), Eve---who hates Alice---looks at that and cackles. Then she sends "I hate you, Bob. I'm breaking up." to Bob, who now thinks Alice hates him.

Not only did Eve learn what secret and ostensibly encrypted message Alice wanted to send to Bob, she could also forge a completely different one. She could also have just relayed the message, and listen in on the session between Alice and Bob.

Exactly what did we gain?

There's a reason I'm doing my phd in cryptography: if you fail at implementing an efficient algorithm for sorting, or shortest path, or travelling salesman, you know your algorithm is inefficient. If you fail at designing a secure protocol, there's a very real danger you think it's secure. The failure modes of cryptography are worse and more hidden than in almost any other subfield of computer science that I knew I needed to spend more time on it.

Plus, I like the geeky math (finite fields ftw.) and the spy-vs.-spy stories ;)

Re:You FAIL with "encryption is good enough"

[multipartmixed]

It's PhDs in computer science that are the REAL problem, if you want my opinion.

There are some things that are worth casually encrypting -- like locking the door to your house.

There are some things that are REALLY worth encrypting -- like locking your safe.

The problem with the crypto community is that you seem to think that black-and-white, good-and-bad, all-or-nothing approach is reasonable. It's not. It's crap.

So, when people don't want to deal with *real* security, but wouldn't mind some opportunistic encryption, to make things more annoying to break but not impossible, they have no choice. So they simply pick "no encryption" in the opportunistic requirement scenario.

Kinda like Nothing vs. WEP vs. WPA. I'd rather use WEP than no crypto for casual communications.. but I'd rather use no crypto than type in a 20-digit number just to get online to check my (https) email.

The only reason we have a middle ground in the WiFi land (WEP) is because the crypto guys screwed up. It's handy. Let us keep and decide how secure we need to keep our information... either that, or give us a no-cost secure channel.

Re:You FAIL with "encryption is good enough"

[jonaskoelker]

The only reason we have a middle ground in the WiFi land (WEP) is because the crypto guys screwed up.

No, it's because the guys who screwed up weren't crypto guys. Or rather, they were made crypto-responsible without being crypto-capable.

Let us keep and decide how secure we need to keep our information

Sure. But why do you want to pay more for the server to spend boatloads of extra CPU cycles (because they have many clients) in order to... still not be secure against the non-lazy man in the middle?

Correct me if I'm wrong, but I think you said that because we don't use encryption only, we're insecure against eavesdropping. I showed you how we're still not secure against eavesdropping if we use encryption only.

Exactly what goal is served by using the crappy tools?

Re:You FAIL with "encryption is good enough"

[lennier]

"The only reason we have a middle ground in the WiFi land (WEP) is because the crypto guys screwed up. It's handy. "

Um, I thought it was because when WiFi first launched, you couldn't *get* anything more secure than WEP.

Now that WPA2 is out, I can't see any reason to not use at least WPA2/PSK. Type in a password, set your Wifi manager to remember it forever, and you're good to go. How is that hard?

Re:You FAIL with "encryption is good enough"

[Froggels]

This is unlikely to happen unless Eve has access to Bob's private key. She won't be able to read what Alice sends her, and anything that she sends to Alice will not be properly signed. Alice will notice immediately "Bob" is an impostor.

Re:You FAIL with "encryption is good enough"

[jonaskoelker]

This is unlikely to happen unless Eve has access to Bob's private key.

Bob doesn't have a private key. What I described is supposed to happen during e.g. a diffie-helman key exchange protocol.

Re:You FAIL with "encryption is good enough"

[multipartmixed]

> Now that WPA2 is out, I can't see any reason to not use at least WPA2/PSK.
> Type in a password, set your Wifi manager to remember it forever, and you're
> good to go. How is that hard?

Typing it in on my iPod often takes longer than the actual information I want to check.

Never mind that *getting* the WPA2 key is often difficult, as well. When my father died, it took me nearly an hour to get net access at his house, so that I could check my email (via https!). If he hadn't been as well organized as he was, I /never/ would have found the post-it.

That day, I would have been far happier being able to chose either no encryption, or something secure against casual eavesdropping.

Re:You FAIL with "encryption is good enough"

[multipartmixed]

> Exactly what goal is served by using the crappy tools?

Allowing me, the owner of the information, to select the ratio of ease-of-use vs. difficulty of eavesdropping.

Just like locking your house. I'm sure you only one, maybe two deadbolts. Why not 16? Do you still have windows? Why? Did you know they are really easy to break?

I think it is unreasonable for the crypto specialists to dictate my needs -- present me with information, let me make my choice. The market has shied away from opportunistic encryption because the crypto people have taken this choice away, instead preferring to still not-encrypt most communications.

For example, I consider https over WEP to be secure enough for almost all my surfing needs, including web banking. If somebody *really* wants to know what servers I'm exchanging packets with, what DNS entries I'm looking up, etc -- go ahead, break my WEP and eavesdrop, you really need a life.

So, I'm happy with that. Why should I have to enter a 20-digit WPA key? It's lucky that I have the choice, if the crypto people had their way, WEP would be erased from every router on the planet.

And don't even get me started with https. Why do we need signed certificates for everything? Jim-joe-bob's page of Mullet Haircuts doesn't need them; again, the crypto+browser people have taken away the casual encryption option and replaced it with an all-or-nothing dichotomy.

Which answers the main question of this /. topic: why is there no opportunistic encryption? Because the crypto people subscribe to this all-or-nothing crap.

Short answer

[Anonymous Coward]

TME.

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.

Complexity Interferes with Work

[stewbacca]

The reason this stuff isn't taking off is because the complexity of a certificate gets in the way of work for most non-technical people. My VeriSign digital signature, for example, took a lot of futzing around with to get working (not to mention costing $100+ to my company) with little to no perceivable value to the end-user.

Self-important people (like my boss) don't have time to be goofing around with their computers to make their security certificates and digital signatures work correctly.

When a boss can't access a certain site or submit a particular proposal because The Computer won't let him, then the boss insists that all these security features just go away.

Someone must be making money off identity theft

[rwa2]

Maybe the insurance companies?

I want to know why I still have to guard my SSN and my mother's maiden name like it's some sort of dirty secret. No one should be able to open up a credit card in my name unless they somehow got the request signed with my private key.

Cost and complexity are the problems

[Anonymous Coward]

Cost of recognized certificates, ones which come from the client software's preloaded default certificate authorities is a major problem. Server to server can be self signed, but ones that are customer/user facing have to be ones most browsers and applications will recognize without prompting with a security warning.

And managing those certificates which expire every year or every couple years can be a hassle, or worse they will cause people problems when they expire.

Of the two problems though, if cost was less then you would see wider adoption. For server to server communications, self signed certs make a lot of sense.

Its not needed as badly as people thing

[gravis777]

What is the point of implementing something that is really not needed? When you are running secure stuff, SSH, SCP, VPN are used. Encrypting harddrives is overkill for the average person. What e-mails are we sending back and forth that is so sensitive it needs to be encrypted? If it is sensitive, most organizations have the approproate framework in place. I mean, why do I need to encrypt an e-mail to my fellow co-workers of the redneck joke of the day, or encrypt my browsing of Slashdot?

Do you know anything about Public Key Crypto?

[gbutler69]

You DON'T need to send your public key to someone securely. That's why it's called PUBLIC KEY!

Allow me to explain. Public Key Cryptogrpahy uses 2 VERY LARGE prime numbers as keys. One is your Public Key, which ANYONE CAN KNOW. Give it out freely. Publish anywhere. Paint it on your forehead. Doesn't matter. The other is your Private Key. This you keep PRIVATE! NO ONE, not even your most trusted friends and allies, should or needs to know your private key.

Now, you can use your key-set in two ways: 1) You encrypt a message to someone in particular by using THEIR PUBLIC KEY and YOUR PRIVATE KEY. You send them the encrypted message (and you can even send them a copy of YOUR PUBLIC KEY at the same time if they don't already have it). They decrypt the message you sent them using YOUR PUBLIC KEY and THEIR PRIVATE KEY. At know time does either party let any other party know their PRIVATE KEY. Anyone else who has your Public Key will be unable to decrypt the message (in a reasonable amount of compute time) without access to the PRIVATE KEY of the recipient (who you sent the message to). 2) You generate a second Public/Private Key-Pair (in addition to your normal key-pair). You encrypte a message (or digest thereof) using your REAL PRIVATE KEY and the generated extra PUBLIC KEY from the generated pair. You send the message and encrypted digest along with the generated PRIVATE/PUBLIC KEY PAIR (NOT YOUR REAL PRIVATE KEY THOUGH). The recipient should already have a copy of your public key gotten through offline channels. The recipient uses your REAL PUBLIC KEY plus the generated PRIVATE KEY included with the message plus the encrypted digest to verify that you are indeed the sender. This method is used to verify that the sender is the correct person that matches up with the Public Key I KNOW for a fact I received from that sender previously.

So, method 1 allows encryptiion/decryption of the message and verification that no one has intercepted the message and decrypted it (and, if you have the receiver has a copy of the senders public key already, it verifies the sender as well). Method 2 simply verifies that the sender is, in fact, the sender whose public key the receiver already has a copy of without encrypting the message.

The important point is that nowhere does any party ever give out their real PRIVATE KEY to anyone else.

Another important point: Most of the time Public Key Cryptography is only used in order to encrypt and transmit a Private Key (like an AES key) for a Non-Public Key Cryptography cryptographic method because PKC is computationally intensive whereas private key schemes are require much less computational overhead. So, in effect, we exchange Public Keys, then one party sends the other party an encrypted message containing only the key for a non-public-key crypto method. Then, the two parties begin comunicating using the non-PKC algorithm using the key exchanged via PKC.

Re:Do you know anything about Public Key Crypto?

[Anonymous Coward]

And do you know anything about email? Or the purpose of encryption?

He sends email to lots of people he doesn't know well. In order for an encrypted email to be read it has to be unencrypted. Once unencrypted it can be sent to anyone anywhere or even PRINTED OUT!

Encryption prevents people from reading your email while in transit or in storage. It cannot guarantee secrecy of the email.

LACK OF UNDERSTANDING ASTOUNDING!

[gbutler69]

I'd be pro if

1. i had control over who got my key data rather than assuming its gets passed on by default to echelon by versign etc

There is nothing for Verisign to pass on. They only have your public key. You keep your private key private. Look into how Public Key Cryptography works before you worry about non-existent problems

2. i could create keys without firefox complaining like two year old about them

Again, your lack of understanding is astounding. Firefox complains because it has no way of verifying that your generated Public Key is actuall from who is says it is (You). Firefox must be able to get a copy of your public key from a "Trusted" source in order to verify your key. There are 3 possibilities: 1) Register your Public Key with a "Trusted" Key Service (i.e. Verisign), 2) Register your own key signing authority with a "Trusted" service (i.e. Verisign) and then register your public key (Cert) with your own key registrar, 3) Install a copy of your public key (cert) into the pre-trusted keys in Firefox (provide an installer for your end users).

Re:LACK OF UNDERSTANDING ASTOUNDING!

[Spazmania]

Firefox offers no complaint if you send your information in the clear.
It also offers no complaint if you encrypt your information with a signed certificate.

In what bizarro world does it then make sense to complain when your encryption is unsigned?

Maybe it would help to have a different protocol designator, httpe, for unsigned encrypted traffic.

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

[multipartmixed]

> Exactly what's the point of encrypting something if
> information will still leak out of the encrypted packets?

Do you lock your house? Does it have windows?

cryptography laws

[astar]

openbsd is rather secure, at least until you put applications on it. part of this is cryptography as a os service. so in the us, the os is a export restricted munition and so the openbsd people do not allow us citizens to work on the os. I speculate that this has a negative effect on development of the os. since associated projects like openssl are widely used, one might think there are negative impacts on the use of cryptography in the us.

HTTPS can't be cached by proxy

[Baloo Uriza]

HTTP proxy caching is a best practice for ISPs and businesses, and going to HTTPS thus adds overhead since this traffic can't be cached.

There is no escape

[UBfusion]

+1 Insightful - I wonder why this was not the topic of the first comment.

I don't want to sound pessimistic or paranoid, but from the signs so far I firmly believe that soon the use of encryption will be reason enough for any obscure organisation to raid my house/office/computer.

This is the main reason I do not practice or even consider any kind of encryption. After 20+ years of being online, I think that any sudden change of online behaviour from my static IP will raise a flag on this or another continent. Therefore, I prefer obscurity through transparency: I take special care everyday to visit xxx sites, check new conspiracy theories, visit celeb and gov sites etc like any normal curious person. However I avoid the googleplex, facebook and all permanent records of any personal details on social networks.

Yes, I know about proxies, anonymizers, Tor etc, but I consider these as the orange flags because using them also can be interpreted as changes of online behaviour. There is no escape.

It costs more

[Anonymous Coward]

The CPU requirements for handling encrypted traffic are a lot higher than for http.

It costs MONEY - and it's not a linear scaling - doing 1/10th of the transactions/CPU needs more than 10x the number of CPU's since you have to spread load - which imposes more load on the system.

Trusted > Self-signed > Worthless

[jhantin]

[U]ntil browsers change their behaviour when confronted by a self-signed cert they will never gain widespread acceptance and use with a non-technical crowd.

Agreed. I'd rather see more relaxed behavior: if the browser is presented a cert that does not connect to a known trust root but is otherwise valid, and either has never done https with the site before or has accepted the same cert in the past, accept it, retain it for future reference and continue with no warning -- but also don't show the "secure site" chrome such as padlock, colored address bar, etc. If the key changes, then go ahead and pop up a warning -- the key change is better evidence of a possible MitM attack than mere absence of a shared trust root.

Also, since there's already a precedent for variable chrome established by EV certificates, it might also make sense to have distinguishing chrome for the apparently-valid-but-no-trust-root case. Conveying the sense of "secured against passive snooping, but doesn't prove identity" with the chrome is left as an exercise to the usability specialists -- failing such a case, using the unsecured chrome is acceptable.

It's the money grubbing root authorities...

[n0tWorthy]

that have led us to this. Certificates should cost no more than $10 yet Verisign wants $1000 for a 1 year enhanced web site certificate. Thawte wants $995 for 2 years. Out and out piracy is my opinion. I'm pretty sure that there would be a lot more security in the small businesses I support if I could buy them certificates for $25.

It looks like app UIs may be biggest barrier

[Sloppy]

After various arguments where I propose that unauthenticated encryption is superior to plaintext, I'm left with the sense that some users (whether it's a lot of them or just a few, I don't know) conflate encryption with the nebulous word "secure." There are applications still in use today, which confuse users into thinking that if the communications are encrypted, then no one can listen in. (Either that, or there are people out there mis-training users into thinking that's what the apps are telling them.)

And if that indeed is the case, then some well-meaning people don't want to deploy encryption without authentication, because they feel that it could trick the user. So those defective apps are making your question become "what is holding back authentication?" And that's a whole other problem.

If we don't want to accept that encryption must come after authentication on everyone's todo list, then we need to repair those user interfaces (e.g. get rid of the padlock icon that is displayed when encryption is used).

Enough to make it not always worth the effort.

[Red Reaper]

As mentioned in a previous post, encryption tends to break many of the other types of security measures we have come to rely upon. Intrusion prevention and detection systems do not always work with encrypted traffic very well; the same goes for mail and web filters. You cannot always trust that which is encrypted and can be as much of a security risk as it is added security. Those types of systems capable of scanning encrypted content can present privacy concerns depending on how they are implemented. Additionally, these systems are not always capable of scanning all types of encrypted traffic, particularly when dealing with proprietary implementations or specs that deviate from a standard. I am not saying that encryption is worthless, however its pros and cons need to be weighed against other aspects of security carefully to ensure that your network gets the best combination of protection and usability that it can have.

Re:And pushing it would give false sense of securi

[Anonymous Coward]

I disagree completely. Doctors, Lawyers and accountants are routinely emailing very sensitive information in clear text. I see it happening every day. Many offsite backup solutions don't guarantee encryption for at-rest data (just SSL while on the "wire").

The single biggest problem with encryption is key management. People are just so accustomed to forgetting their passwords that they don't understand that not managing your encryption keys is going to result in lost data. They just "assume" there is some backdoor (I know this because I maintain a secure storage site and have lawyers contacting me weekly that have lost their credentials).

Inadequate for what? That's a key question.

[Motard]

IMHO, one of the problems with the propagation and improvement of encryption is that too many people, knowing that better encryption is possible, reject all forms of encryption that aren't ideal.

I worked at a company and we had a one time need to send data outside the company in a way that would relate individuals without disclosing their identity. It wasn't a problem that we wanted to spend a lot of time and money on. At some point I coldly offered the possibility of simply multiplying the ID's by X. It would obscure the ID's, but not secure them. I expressed my doubts, but the legal representative of the company ruled that we only needed to take reasonable steps - not outwit Sherlock Holmes. I raised a mild objection, but with all of this documented, and with a legal opinion in hand, that's exactly what I did.

But I started thinking about this later and began to realize how woefully inadequate other forms of human communications have been for most of human history. My parents would never trust anything not on paper, but their mailbox was hardly secured. Signatures on contracts are never examined - except perhaps, in a court of law. Today, normal fax machines are legal instruments capable of transmitting prescriptions for controlled substances.

The gap between the now and the ideal is very wide. Symmetric key encryption is adequate for many situations. Asymmetric encryption is a solution that doesn't always need the establishment of trust. That can often be established on a peer-to-peer human level.

Often, when I've developed a program/system that had been generalized to solve anticipated problems in addition to the specific problem to be addressed, I've found that much confusion would follow. I learned to design and code to the general, but expose only that which addressed a specific need. Later I could expose more if needed. That worked much better and, when people later asked if we could add something else, I could say that I'd anticipated it and yes, we could.

So here's the thing. When I did have to implement more general forms of encryption, I felt like an idiot. I'm don't think I'm an idiot. I've written routines to compute surface normals to geometric planes to effect hidden surface removal.

But just figuring out how to get/buy PGP while not get ripped off was hard enough. I knew about GPG but couldn't find any definitive statements that they would work together (PGP being ubiquitous in my industry). Then I was given choices between various ciphers and hashes. Uh, which one is best? No guidance.

Then there was the company that had been recently compromised who's newly formed Information Security department refused to let us send them PGP encrypted data over their FTP site without a security review of *our* company.

Crypto folks, get your heads out of theory and into the real world.

Training, Where to get trained on using PKI?

[Anonymous Coward]

Where can an IT professional get training for using encryption tools? We need to have more training for the realities we face on the Internet. I've been writing interface scripts for banking interactions for a long time, and have only recently seen banks offer some level of encryption. Ideally, we should leverage IP restrictions as well. There should be both in place for any secure transaction. IP restrictions and some level of object encryption and/or session encryption. How can data be safe otherwise? -JW

Smart Card

[K-tWizel]

Most large (and some mid) companies employ a SmartCard of some kind for access to the building. Adding a smart card with a chip then help authenticate getting into the building and (with certs on the chip/card) auth the user onto the network and provide for digital signatures and encryption. Most companies also have a policy governing levels of protected information and how it is shared. There is a bit of 'heavy lifting' as far as implementation and it would come down to how much risk is acceptable. I have worked in both environments and hybrids in-between. SmartCard logon as building ID is the smoothest and easiest for the user as well since a single PIN is needed with the SmartCard. With most people familiar with Bank ATMs, this should be a no brain-er

Government Endorsement?

[tif]

I believe that the US Post Office should take the lead here. Even 10 years ago, I thought that the USPO was the perfect "official" entity to manage keys. The post office currently serves a sort of official role in guaranteeing safe deliverly of your mail (more or less). If the USPO had official processes for proving you are who you say you are and keeping your public key, then the US Government could safely allow digitally signed emails to represent contracts, etc. Once you reach that point, it seems like signed emails would become the norm for business transactions. Furthermore, once you have all the keys and government endorsement, it seems like encryption would follow very quickly.

Even better, it would become trivial to filter out any non-signed emails as spam, and for any signed spam to be prosecuted.

--Paul

Options

[benjic]

It may not be feasible to employ encryption in everything we do. But we should focus on making it an option to all users to elect to use. A right to privacy shouldn't be nulled because it's to hard to protect. Additionally employing encryption farther from the application level makes it easier to implement it more transparently.

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?

Re:Trusted Self-signed Worthless

[Onymous Coward]

Maybe Perspectives can help show that certs come from the right source.

http://www.cs.cmu.edu/~perspectives/index.html

WOW! Did you even read?

[gbutler69]

3 Modes:
1. Non-encrypted - no need to warn, not claiming to be secure (No Lock Shown/No Yellow URL Bar)
2. Signed-Certificate - claiming to be secure, lock-shown, yellow-url bar shown - verification exists that the traffice is in fact encrypted by domain owner (exluding difficult and unlikely MITM)
3. Un-Signed Certificate - claiming to be secure, but, no verification exists that traffice is in-fact encrypted by domain owner.

If you can't understand the difference, then you need to REALLY think about the problem for a moment instead of just shooting off your mouth.

Re:WOW! Did you even read?

[Spazmania]

That's a badly broken mental model of how security works.

Encryption with an unsigned or self-signed certificate isn't claiming to be secure. It's claiming to be encrypted. Nothing more, nothing less.

If encrypting with a signed certificate is claiming to be secure, it's a false claim. The signature authorities have made errors as with microsoft. Certificate algorithms have been usefully hacked as happened last year creating collisions with the hash algorithm. And relatively few users will notice that the site and certificate are actually bankofameriKa.com. Or bank.ofamerica.com. Or even bankofamerica.xyz.com.

Encrypting with a signed certificate is more secure than encrypting without, but it is not -secure- in any absolute respect. What's more, the difference in security between plaintext and encryption is far greater than the difference in security between signed and unsigned encryption.

Claiming otherwise is not good science. It's really something of an ideological error.

Too hard to use ...

[gordguide]

I had a secure certificate for eMail encryption. Took about a day to figure out how to use it, get it implemented in my mail program, how to inform other eMail users the procedure to decrypt my messages, get the certificate signed by Thawte, etc. As it turned out, only one other person I corresponded with had implemented eMail encryption.

Then one day, the certificate expired. Do you think I could wade my way through the obscure techno-babble of the Thawte website to renew my certificate? If you answered "yes", you'd be wrong. I couldn't even figure out what kind of certificate I had when wading through the obtuse language at Thawte.

Someone has to make this easier than getting 24 bit video at something bigger than 640x480 to work on obscure hardware with a new Linux distro. That was a piece of cake in comparison.

To this day I have no idea what Thawte wanted me to do to renew the certificate.

The Feds are holding back encryption :(

[Anonymous Coward]

Link to relevant information....

http://www.bis.doc.gov/encryption/default.htm

It's a shame that a mathematical transformation of information is considered a weapon (of mass destruction). :(

Slashdot CAPTCHA: skulls

(how apt) :P

Many people don't know about encryption...

[Froggels]

and many more could care less. Attempting to explain the benefits of encryption to the most people is at best a waste of time and at worst makes you come across as a babbling paranoid geek with something to hide. For years I have had GPG setup so that I can send and receive encrypted email; however I can count on no more than one finger the number of times that I have ever sent a "real" encrypted email and that was to verify an oder with thinkgeek.com. I have yet to receive "real" encrypted email from anyone whether it by my bank, or any of the several companies I deal with even though my public key is readily available. I find that most people are simply confused the whole topic. What I would like to see is for the windows Thunderbird installation routine to include a security setup option that automatically downloads, installs and configures GPG for the user. More people might then start using "secure email/signing" if the option were available by default in their email interface. Self signed certificates are good enough for most people's purposes and could be dealt with by dumbed down security warnings, eg. "Do you really trust this sender...?. Once trust is properly established the only "flags" of real concern would be when a self signed certificate doesn't match the one that has been previously trusted.

What's your point?

[gbutler69]

I send something to someone to read. They can read it. It can't be read by someone else until the intended recipient gets it and decrypts it. What the recipient does after that has NOTHING to do with encryption (nor can it). If you think otherwise, you really are misinformed. What your are advocating in DRM (Digital Restrictions Management) which is "Defective By Design" and doesn't actually achieve the purpose you are seeking (keeping intended recipient from doing with something you sent them what you don't want done). I'm sorry, but, no sane person is going to every grant you such control.

Re:What's your point?

[gbutler69]

Oh, and by the way:

And do you know anything about email? Or the purpose of encryption?

Yes. Yes.

But, apparently, you are quite confused! You should probably re-think your statements before you speak. You show yourself to be misinformed and ignorant.

MITM

[Lazy Jones]

Exactly what did we gain?

We gained an encrypted transport, meaning that eavesdropping is not possible without forging packets. What's so hard to understand about it? Yes, MITM is still possible, as it is with weak SSL, but it is a different problem and it does not need to be adressed for many uses. If my ISP can intercept and modify packets, he can forge all my responses in a (unidirectionally authenticated) SSL communication, he can do all sorts of evil stuff pretending to be me and I'm generally out of luck with most current protocols/implementations. The number of people who can eavesdrop is generally higher than that of the evil ISPs who can forge packets and when I have the choice between unencrypted transport and encrypted transport vulnerable to MITM, I will choose the latter, simply because the evil people with only the capability to record conversations will be unsuccessful.

US Government

[Anonymous Coward]

One word: ITAR.
http://en.wikipedia.org/wiki/ITAR

not necessary most of the time

[Eil]

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.

Not encrypting FTP or email is pretty inexcusable if you're going over the public Internet.

However, most websites use plaintext HTTP most of the time because there's nothing to hide. It's expected that a site will switch into SSL mode when entering a password or displaying personal or financial information, but other than that, there's really not an incentive to encrypt normal web traffic. If someone snooped on my connection and saw spurts of HTTPS traffic coming from IPs assigned to Slashdot and CNN, all they have to do visit those sites themselves to see what I'm reading.

(Although I really do wish Slashdot would at least allow logins and comment submissions over SSL.)

Macs

[Anonymous Coward]

A not so computer-literate user just pleaded me to allow unencrypted FTP because in order to use SFTP on a Mac:

For Mac OS X, you'll need to take an extra step and install the "putty" package. Honestly, it's a huge install (1 GB+) which will take about half an hour to do (or more if you need to download Xcode). Unfortunately, there isn't an easier way to do this on a Mac. Anyway, here are the steps to follow:

  1. Install the Xcode 3.0 Developer Tools found on your Apple's Install Disc in the "Optional Installs" folder (Optional Installs->Xcode Tools->XcodeTools.mpkg) or at https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=19897 (beware: it's a 1 GB download)
  2. Then you need to install MacPorts: http://www.macports.org/install.php
  3. Open up a Terminal (Applications->Utilities->Terminal)
  4. At the prompt type: sudo port install putty
  5. (you may be asked for a password)
  6. Voila!

I can't fucking believe it. How can an FTP program come without SFTP support? How can PuTTY be 1 gig? The PuTTY that came with my WinSCP is 1.4 megs big.

Encryption makes it hard to read

[uninformedLuddite]

At least that's what the NSA, CIA, TFI, FBI, DEA, ONI, ATF, CIA, NGA, DHS, DIA, DOD, DOE, INR, NRO, ISR, RIAA, BSAA, and the Children's Television Workshop have all said at some stage.
The DOJ insisted back in 1999 that its agents need the ability to secretly enter private property and disable security on personal computers. Apparently SELinux has a back door built in using NSAKEY as the password.

Easy answer

[abulafia]

It is orthogonal.

FTP is unencrypted because what people want to do is get files from point A to point B. Something as simple as scp causes them to see a warning message that the can't quite make sense of, that looks scary, that is not on the critical path between getting files from point A to point B. So, they do what all humans do, which is go back to the lowest common denominator that is not directly related to their chosen career.

Email? Encryption? Are you fucking kidding me? I knew that was a failure when X509 was pushed. People do now want is-a-person identity verification for themselves, just for everyone else. And it turns out that PGP web of trust sort of key management only works for geeks that like concerning themselves with security. The single best thing that happened to email over the last 12 or so years is admins accepting that opportunistic transport encryption is, yes, basically free and self-signed certs work just as well as that one from Verisign. But, still, this is transport, not storage, so (in the U.S., at least) the legal system intersects, and transport encryption is necessary, but not sufficient, for personal control over one's email. And this is putting aside that a rather large part of the population has migrated to web mail, where they don't even control the storage in the first place, and the service providers have obligations to state actors that are substantially less robust than storing your own damn email on your own damn disk.

I don't think I've seen an ecommerce shop running on port 80 in 5 or 6 years, but I'm sure there are some out there still. But this ignores that we're really not that worried about people compromising routers and whatnot (I'm not saying it hasn't happened, but that is by no stretch the most common security breach mode for Joe User). Transport encryption doesn't help you when the Chinese government targets you with a zeroday, or even when you're not paying attention on a more generic phishing attack.

I was on the Cypherpunks list back in the early 90s, and there is a reason why most of the predictions of the use of crypto did not pan out to create a cyber-anarcho-capitalist-utpoia (dystopia?). And that reason is that a lack of crypto is not the weak link, and, as always, the problem exists between chair and keyboard, if you're prone to considering that the problem.

My view is that people want to get things done, not worry about getting things done securely. And so any time "securely" means even slightly more work, fuck it, it won't happen. And that means even really minor points of friction, because people don't even understand why they're doing these things in the first place. ("Why did my login have to time out? I still want to put things there.")

Ultimately, the right posture for someone who wishes to promote security is to make it transparent. That's not possible, of course. But we, as a culture, are used to accounting safeguards, CPAs imposing annoying multiparty checks and balances and whatnot, so it isn't impossible that this sort of thing could be pushed to consumers. I'm personally skeptical, because the non-geek consumer has an interest in not caring and the people selling stuff have an interest in catering to that.

Top 2 reasons

[quarkscat]

(1) The USA government, or more specifically the USA's intelligence agencies, have for decades opposed any meaningful strong encryption that they might have some difficulty breaking, let alone exporting or re-exporting such encryption. President Clinton's Clipper Chip initiative included the requirement that the keys be sequestered by the government, which destroyed any credibility with businesses or individuals. These requirements, although relaxed somewhat, still exist to this day. (2) USA and foreign computer manufacturers (hardware and software) are compelled to provide either degraded encryption, or else key sequestration to the USA government if they wish to do business with the USA government -- money talks, and big money talks loudly. Without the ability to easily integrate strong encryption into either the Operating System or the Hardware, the use of encryption is problematic for the generally lazy end-user. The entire USA IT industry has been subverted and corrupted by the USA intelligence agencies. Until such time as strong encryption can be shared across national boundaries without fear of any government's intrusion, this situation will persist.

The Actual Problem

[Dan541]

Only Terrorists use encryption, if your not a terrorist you've got nothing to hide.

Re:The Actual Problem

[muckracer]

> Only Terrorists use encryption, if your not a terrorist you've got nothing to hide.

Oh, the irony of this! I love it! :-)

You forgot: "Signed, Your friendly NSA and associates" :-D

Encryption is either pointless or forbidden

[BugHappy]

There are two kinds of encryption:

- The one that stops your little sister (SSL used to admin firewalls, to fuel VPNs, or RC4 used in Remote-Desktop, etc.)
- The one that puts your company into big trouble because governments will crunch your company if it does not "comply".

This may help to understand why encryption is not widely used: it is either pointless or forbidden.

Re:Trusted Self-signed Worthless

[muckracer]

> Maybe Perspectives can help show that certs come from the right
> source.

> http://www.cs.cmu.edu/~perspectives/index.html

Perhaps something like what Perspectives does for SSL certs would be
feasible for GPG keys pulled off a key server.
As in: "This public key for email@domain has been seen consistently
for X amount of days", i.e. it has not changed thereby preventing
imposters. Would be a nice secondary path of semi-trust in addition
to the Web-of-Trust.

Why use encryption?

[dublinclontarf]

Why use encryption? The Government, and not necessarily your own. Why would a government care about the content you view from websites? I moved to China 6 months ago and am sick of half the internet being blocked, I can't talk to my friends or family on facebook, my porn is cut off and plenty more. And China is only at the forefront, Australia is close behind followed by the UK(in the "free" world), and every other despot country with internet.

DNSSEC does *not* do encryption.

[hardaker]

DNSSEC does data authentication and has never strived to do encryption. Ok, NSEC3 added hashes of names to the negative answers so you couldn't walk the domains, but that still isn't encryption. The only thing DNSSEC adds to the DNS data is signatures and hashes on existing data.

Now, having said that, DNSSEC does let you securely look up SSH fingerprints, X509 keys, etc from DNS data so that you can do key bootstapping. There is even a patch to openssh to automatically accept a key if it matches a fingerprint that was securely retrieved using DNSSEC.

Kmail on Debian just works

[marcosdumay]

My experience is that on Debian if you install GpG, Kmail instantyl activates all the buttons and interface changes needed for suporting it. The only thing that is hard to do (or, I guess I just didn't try to learn) is adding other people's keys to your database.

GpG by the way is required by aptitude nowadays, thus almost always present on Debian installs.

Re:Kmail on Debian just works

[OFnow]

The only thing that is hard to do (or, I guess I just didn't try to learn) is adding other people's keys to your database.

Just get the other person to send you a gpg-signed email. That's all it takes.

It's not your fault this was not obvious to you. That is precisely my point earlier: even the simplest steps are not documented in an easy to understand way.

Re:Performance overhead vs. value of the informati

[Abcd1234]

I usually don't bother encrypting my email because it's mostly mundane stuff, and frankly there's more of a threat from the owner of the email server reading my stuff than there is from a MITM attack. Also, getting and using a cert is a bit of extra work.

Bah, that's crap. Fire up Seahorse on Ubuntu (Accessories -> Passwords and Encryption Keys), generate a new key, then publish the key. Then fire up Evolution or Thunderbird + Enigmail and tell it to use the key. There, you're now using signed/encrypted email.

Honestly, this is *dead simple*. The argument that it's too hard is pure BS, IMHO.

Re:And pushing it would give false sense of securi

[Abcd1234]

Really, most things which should be encrypted - are. There's no reason to push encryption everywhere

Actually, there's a *very* good reason to push encryption everywhere: It adds noise to the signal. Right now, if a government agency wanted to focus their efforts on surveillance, it would make sense to focus it on those who are making use of encryption. After all, as you say, encryption is used where it "matters".

But if everyone used encryption, then it becomes impossible to identify "important" data from "unimportant" data. That's a very good thing.

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

[bingoUV]

Or---when in debugging mode you could send some insensitive unencrypted traffic. That way, people can have their encryption and network debuggers can have their not-encryption.

But the "bug" appears only when the encryption is turned on. Only for data for which encryption is turned on. Now what?

Encryption doesn't have to be complicated...

[Anonymous Coward]

Encryption made easy for the average user. Try https://www.threadthat.com. Effective and simple.