The Problem With Using End-to-End Web Crypto as a Cure-All 89
fsterman writes: Since the Snowden revelations, end-to-end web encryption has become trendy. There are browser add-ons that bolt a PGP client onto webmail and both Yahoo and Google are planning to support PGP directly. They attempt to prevent UI spoofing with icons similar to the site-authentication banks use to combat phishing.
The problem is that a decade of research shows that users habituate to these icons and come to ignore them. An attacker can pull off UI spoofing with a 90%+ success rate.
The problem is that a decade of research shows that users habituate to these icons and come to ignore them. An attacker can pull off UI spoofing with a 90%+ success rate.
Technical solution to a people problem... (Score:5, Insightful)
Re:Technical solution to a people problem... (Score:5, Insightful)
Re: (Score:2)
Interesting that there is a PGP plugin for webmail. But I really wouldn't be comfortable with the idea that my private key is stored in the browser somewhere.
Re: (Score:2)
Well, I probably wouldn't use that private key for anything else, just in case the browser gets compromised by something capable of stealing it, but it's still a dramatic improvement over sending email in plaintext. Might even use a dedicated browser strictly for email - if my webmail provider gets compromised and serves me malware capable of extracting my key, I probably have bigger problems.
Re: (Score:2)
You might be able to read a letter with an xray machine. The paper and toner/ink/graphite are materials with different densities.
Re: (Score:2)
As if 'nobody' conspires with the Postal Service to do the work in the sorting center.
Re: (Score:1)
This is in correct, in many western nations the mail envelopes have been scanned and directed on their path using character recognition. This is effectively the meta data that is tracked in email, especially if people write the sender on the envelope too.
http://www.nytimes.com/2013/07... [nytimes.com]
Re: (Score:1)
I think the problem is rather ignorance. People send a letter and expect to be secure in their persons and papers, but don't understand that e-mail is (and I'm not saying it shouldn't be) neither.
End to end encryption is quite secure. But not for the ignorant. Free markets are fair, but not for the ignorant. Democracy is good, but not for the ignorant.
It's almost like ignorant people are a drain on any system. As the technocrati, we can establish security and privacy. But we can't protect the ignorant
Re:nope (Score:4, Insightful)
I used to run my own services at home in this fashion. It was a pain in the ass. Most people are not capable of doing this.
Re:nope (Score:5, Funny)
Re: (Score:2, Insightful)
Not precisely possible — Long known. (Score:2)
I often quote in this context a nice 1999 article, Why Johnny can't encrypt: a usability evaluation of PGP 5.0 [gaudior.net].Yes, it's old, but still interesting: What kind of shortcomings do crypto interfaces have in order to be used by a random Johnny?
Webmail? You're doing it wrong (Score:1, Informative)
No one sends anything confidential via webmail. That's what local applications are for. They all support SMIME, which is what DOD uses, and they do it out of the box.
Provided your MUA supports S/MIME (Score:2)
No one sends anything confidential via webmail. That's what local applications are for. They all support SMIME
And StartCom has been handing out S/MIME certificates without charge. This is fine so long as A. the mail user agent on the device supports S/MIME, or B. the device's operating system publisher allows installation of third-party mail user agents. All PC operating systems have B, but I can think of a few commonly used mobile devices that have neither. For example, does the Email app on PlayStation Vita [playstation.com] support S/MIME yet?
Re: (Score:1)
Does anyone use PlayStation Vita for sending confidential mail? Does anyone consider PlayStation Vita a "commonly used mobile device?" Maybe in the 15-20 year old demographic, but not in the office. There's no native S/MIME support for the PDP-11 either, nor for my pet rock, and they're just as meaningless as the Vita or the Zune.
Apple has great S/MIME support in its iOS devices, even the iPod Touch. Blackberry's had it for years. Android had half-assed support that's gotten better recently. Any devic
Re:Provided your MUA supports S/MIME (Score:5, Funny)
I probably wouldn't be interested in a CA that gave me my cert, I'd rather have one that signed one I generated :)
Re: (Score:2)
Especially compared to generating a gpg key that process is still a huge pain, requiring you to fiddle with obscure commands (seriously, the openssl command-line options read like someone sat down for half a year and thought "how can I make this as unusable as possible?").
Why isn't there a one-line program that does everything, ideally including submitting the request for signing? Plus a GUI of course, especially for Windows users.
Private keys for S/MIME certs ("client certs", more generally) are generated automatically in the browser, a CSR is generated and sent automatically to the CA for verification/signing. No command-line utilities are needed at all and the private key doesn't leave the browser. Quick, easy, and secure.
If you go through the process to get an S/MIME cert at StartSSL or other CAs, everything is handled seamlessly in the browser without the CA generating (or knowing) the private key.
Of course, StartSSL offers the
Re: (Score:2)
but I can think of a few commonly used mobile devices that have neither. For example, does the Email app on PlayStation Vita support S/MIME yet?
That's a serious edge case there. The vita is a gaming device first and foremost. sooner or later we have to say "look there are clients that just don't support s/mime." and not worry about them. I've got a vita, but have never used it for e-mail.
You might as well say something like:
"what about webtv, the i-opener and the MSN companion, they don't support s/mime either" or "What about someone using a Saturn netlink on an SDTV"
Don't focus so much on edge cases, they're a distraction, and in your case an
Hire those "hackers"! (Score:2)
90% UI sucess rate? Hire them -- most legit websites have 80% or lower success :)
I suspect this is a made-up/"customized" statistic.
Re: (Score:2)
I suspect this is a made-up/"customized" statistic.
It's based on a decade of research, the 90% figure comes from actual behavioral studies in which researchers asked participants to login to their bank accounts and removed the "site-authentication" image.
Re: (Score:2)
It's based on a decade of research, the 90% figure comes from actual behavioral studies
I doubt it. If you were actually familiar with these "behavioral studies", then you would have provided a citation. Studies have shown that 90% of people that claim "studies" support their opinion, without actually citing them, are just making stuff up.
Re: (Score:2)
It's based on a decade of research, the 90% figure comes from actual behavioral studies
I doubt it. If you were actually familiar with these "behavioral studies", then you would have provided a citation. Studies have shown that 90% of people that claim "studies" support their opinion, without actually citing them, are just making stuff up.
It's in TFA.
Re: (Score:2)
The are working on it (Score:3)
The technical people are actually working on this problem:
1. make it super easy to encrypt all websites:
https://letsencrypt.org/ [letsencrypt.org]
2. In the long run:
"Marking HTTP As Non-Secure"
https://www.chromium.org/Home/... [chromium.org]
And many, many more improvements.
Re: (Score:2)
This has nothing to do with HTTPS, it's aimed at PGP and OTR clients that are bolted onto web interfaces. The problem is that these interfaces can be spoofed.
Pre-SNI UAs, captive portals, and private keys (Score:2)
This raises three questions.
First, how would you "encrypt all websites" as long as Windows XP maintains a loyal following despite its end of support? Because Internet Explorer for Windows XP doesn't support Server Name Indication, it can see only the first certificate on port 443 of a given IP address. This breaks name-based virtual hosting, requiring to lease an increasingly scarce IPv4 address.
Second, your "Marking HTTP As Non-Secure" page mentions example.com. I most often use that hostname [example.com] to log into p
Re: (Score:2)
None of the GPG plugins store your private key on the server, so no.
How does the end user know this? The article states that the end user doesn't know nor care about the difference between the UI presented by a browser add-on and the UI presented by a compromised mail server.
Re: (Score:2)
How does the end user know this?
They don't "need" to know it, but they're most likely told when they install the gpg plugin.
The article states that the end user doesn't know nor care about the difference between the UI presented by a browser add-on and the UI presented by a compromised mail server.
So? Then tell people to use a proper e-mail client, which they should be doing anyway.
Re: (Score:2)
"Marking HTTP As Non-Secure" is exactly the kind of thing being argued against. TFA is saying that TLS is not a cure-all, and that the 40% or so of page loads that go over plaintext will just train users to ignore the security warning altogether, even when it's a legit MITM attack on TLS. Wonderful!
Re: (Score:2)
Have to admit I'm not a big fan of incremental improvements over an old less secure system, but they do improve things and fix things and it's stuff that actually can be deployed on the public Internet.
Examples are better revocation that actually works:
https://wiki.mozilla.org/CA:Im... [mozilla.org]
https://blog.mozilla.org/secur... [mozilla.org]
Making sure regular visitors on sites always use HTTPS and only allow for certain public keys (the last one fixed the CA system for regular visitors !):
http://en.wikipedia.org/wiki/H... [wikipedia.org]
https:// [mozilla.org]
that's not what "end to end" means. (Score:2, Informative)
End to end = I encrypt on my computer, message is sent over possibly snooping middlemen, recipient decrypts on his or her computer.
End to end is NOT: some snooping middleman in the middle has the key and does the encryption "for" me.
The only way for someone to "spoof the UI" is to have control over my computer, and if they have that, all bets are off anyway.
There's nothing wrong with end to end encryption. There's something wrong with your definition.
Any solution is better then none at all (Score:4, Insightful)
The problem with security researchers is that they declare any usable technology as "completely insecure." and in a sense they are correct. Good security is hard and inconvenient. What we have right now is even worse. There is no privacy what so ever.
What e-mail needs for most people is an envelope. Enough encryption that the casual observer cannot read the message, and the malicious observer must make a targeted attack. I don't need to stop theNSA I just want to dissuade the PHB form reading over my virtual sholder. In the process the NSA will have to pic and choose who it targets. Yes, these e-mails will remain completely insecure, but there is a much higher cost to read the data, and there is a much higher risk of being discovered doing so.
Lets not let the perfect become the enemy of the good when it comes to security.
Re: (Score:1)
I can't agree with this enough! Where is my thumbs up button! It wouldn't hurt either if PGP/GPG and Enigmail improved their UI's and didn't demand so much of the user.
Re: (Score:2)
There are usable and secure E2E email clients, but they require a separation between the messaging system and the software used to retrieve it. With traditional software distribution, we can rely on reproducible builds and security audits to increase the cost of backdooring software. On the web, each provider can deliver a custom (backdoored) version of their software to the target on demand.
Certificate pinning (Score:3)
This is what certificate pinning was made for. If the browser knows what certificates the site ought to be using, it can simply refuse to connect to anything in the site's domain that isn't using one of those expected certificates. This doesn't even require CA-issued certificates, self-signed ones would be equally secure except for the fact that browsers complain about them. Note that this is just a slightly more permissive form of the server authentication built into the SSL protocol.
Re: (Score:2)
This has nothing to do with HTTPS, it's the ability for the service provider to spoof the UI of the Javascript PGP client.
Re: (Score:2)
Well, we already have seamless transfer of public keys. That's the whole point of the PGP keyservers, after all. As far as revocation, your argument fails to take compromises into account. The ability to revoke a key is what allows me to handle a case where someone's broken into my computer and gotten hold of my private key. If I couldn't revoke my key, they could impersonate me forever using the stolen private key. Expiration serves a similar purpose, limiting the timeframe when a stolen key could be usefu
Only when you're still supporting unencrypted (Score:2, Interesting)
This is only a problem with mixed implementations of end-to-end encryption where you're still supporting unencrypted content. A system built from the ground-up to always require end-to-end encryption would not have this iconography problem, because it would not even need the icons -- it's all encrypted, all the time. I hate to see encryption itself dragged in with UI/UX problems.
Signed http? (Score:5, Insightful)
Re: (Score:2)
Another issue with signed downloads is that older versions with known security holes are still signed, someone malicious can push you the legitimately signed but known vulnerable version, then exploit the vulnerabilities to push malicious code...
Re: (Score:1)
Let's say the site you are visiting are using JQuery, hosted on a third party server and is as such subject to your proposal for signing without encrypting. Anyone intercepting the connection will see which of the JQuery versions that were requested. If the version you request is hardcoded to one of the older ones (which is often the case), and if the older version contains security vulnerabilities (less common, but happens), then the attacker will know that you are now vulnerable to those attacks. The atta
Patriot act makes everything insecure (Score:1)
This may protect against petty thieves, which is a good thing, but doesn't against mass government surveillance. It makes it less convenient and easy maybe, but due to the Patriot act, the US government has such control over companies such as Yahoo and Google that they effectually control the client software. You can encrypt all you want, but if the US government can get whatever they want in the client and the company has no option but cooperate silently, the client can be compromised the leak whatever the
Re:Patriot act makes everything insecure (Score:4, Insightful)
You know, I hate the patriot act with every fiber of my being, but that argument doesn't quite hold water.
The NSA doesn't care about your money. They don't need to blackmail you. If they want you, they can come and get you. They don't affect the vast majority of Americans. I don't care for them spying on me, but in reality the vast majority of us (myself included) will never see anything become of it.
Thieves and fraudsters, on the other hand, have a definite desire to have your money. They will get it by any means necessary. You need protection against them.
You'll never have a foolproof defense against the NSA. You can make their job harder, but that's about it. They have the resources to get to you if they want to. Ukrainian script kiddies don't. So make technical countermeasures against the thieves, and political ones against the NSA.
Re: (Score:2)
Your argument requires us to trust the NSA, which I'm afraid we can't do. They lie, they violate the constitution on an unprecedented and almost unimaginable scale, and they are proud of it.
Re:Patriot act makes everything insecure (Score:4, Insightful)
No, my argument requires you to realize the difference between the NSA and those who want to commit fraud.
Thieves will be deterred by technical means. The NSA will not be. Securing yourself against thieves is still preferable to not securing yourself at all.
I certainly don't expect you to trust the NSA, but from a practical standpoint it doesn't matter for most of us. They're not interested in us.
If you want to fight the NSA, you have to do it politically. It's their only weak point.
Re: (Score:2)
Your argument requires us to trust the NSA, which I'm afraid we can't do. They lie, they violate the constitution on an unprecedented and almost unimaginable scale, and they are proud of it.
You don't need to trust the NSA for GP's argument to be valid.
If you need to protect your house, think about regular robbers rather than Arsene Lupin. Not because you trust Lupin, but because he is both less likely to target you and harder to stop. As a result, your countermeasures are much less likely to have an effect on the outcome.
Don't make it "just an icon" (Score:4, Interesting)
Sounds like a user interface problem. Users won't get accustomed to it if unsecure sites are mauve text on navy blue background. Or something equally egregious and harder to use.
snowclone form letter (Score:2)
The main problem with x as a cure-all is that anyone believes in a cure-alls in the first place.
The article isn't about PGP, but web-based email.. (Score:2)
The article isn't actually about end-to-end email security, but about using web-based email, because you can't trust the contents of the browser window. The answer, of course, is to use a Mail app, and not web-based email. If you use a mail app, end-to-end security works great!
The real problem that needs solving isn't hacking PGP into web-mail, it's making certificate management user-friendly. And that's not even that hard to do!
Re: (Score:2)
The real problem that needs solving isn't hacking PGP into web-mail, it's making certificate management user-friendly. And that's not even that hard to do!
Lol, users don't understand certificates and I doubt that most geeks are capable of managing them.
Exactly! Icons without context are meaningless (Score:2)
Its like putting those large golden padlock images on e-commerce pages: Over time, people will absorb them as trust indications and then scammers will increase their success rate by draping their spoof pages in these symbols.
A user has to understand what a browser or email client is, and learn to look for trust indicators in the areas that frame the content.
Adding a PGP interface inside a content area is just STUPID.
The real problem that needs solving isn't hacking PGP into web-mail, it's making certificate management user-friendly. And that's not even that hard to do!
I completely agree. I think cert and key management *would* be a lot simpler if operating sy
Flip the data model and all these problems go away (Score:4, Insightful)
In this way you would no longer need separate services for email, IM, social, file sharing, etc. We'd communicate directly and privately in every mode (with public still an option if appropriate), and cut out the middleman. Starting from that approach you'd basically rewire the Internet while leaving everything else the same. You'd obviate the need for Facebook, Gmail, Twitter, Dropbox, Snapchat, Instagram, Youtube, etc., etc., etc.... Basically, any service that collects user data and orchestrates sharing between people would be an evolutionary dead end. That would be cool right?
Plus, the only way it could work is to base everything on open source software and devops, so nobody could ever seize control or extract a tariff. It would be what Bruce Schneier refers to when he laments the lack of "public commons" on today's commercially-controlled Internet. Going a step further, once everyone has his/her own private personal cloudspace, we'd each have a place to put all the data from our Fitbits and Nests and Internet of Things, and the other exploding sources of personal data. Wouldn't this be a better way altogether?
HTTPS is a pox, necessary or not (Score:3)
Forcing HTTPS on every website is the current scammage. For this, I get to go out and buy a cert, mess with the server, and all for a Joomla site that doesn't have any internal security issues fixed by HTTPS.
What is this fixing, again? Wordpress add in vulnerabilities, or certificate authorities revenue?
Re: (Score:2)
It's fixing the fact that many ISPs like to spy on people using their services, and often like to inject ads, copyright lobby propaganda and malware too. By switching to HTTPS they can't easily do that without it setting off alarm bells due to all the spoofed certificates they would need.
It also makes life harder for GCHQ and other security services who like to tap entire backbones and hoover up everything. If most of that traffic was encrypted there would be far less value in capturing all of it.
Re: (Score:2)
Using qualifiers such as 'can't easily do that' or 'makes life harder' reinforces my complaint. This doesn't prevent anything, just makes it hard for the little guys. States can still apply resources and break in if they want.
Re: (Score:2)
After all, since the big guys can read your mail or bust down your door, it doesn't make sense to take basic security precautions.
Don't understand the problem (Score:2)
If you use SSL with certificate pinning and type www.gmail.com into browser, you are safe from man in the middle attacks and root certificate compromises. The only attack vector is gmail itself or your computer being compromised. The former problem applies to any website - it obviously can serve malicious crypto code that copies plaintext elsewhere. The tradeoff is that you can use any public terminal to access your stuff, making it unlikely that someone compromised it in advance. It's comparatively easier
HTTPS / Public Key is (usually the wrong algorithm (Score:2)
The problem is that it requires users to validate the URLs.
The correct algorithms are PAKEs such as SRP [wikipedia.org]. They do magic that produces strong security from weak passwords (a bit like Diffie Hellman). If the users types the password to a phishing site then no connection can be established. Idiot proof.
The OS and random bits of the Internet .. (Score:1)
Reason being is that it is technically easier to run scripts to achieve such usability. What used to be known as 'keyboard macros' are essentially commands that execute as if you typed them at the keyboard. Can anyone in Apple/Google/Microsoft/Oracle come up with a better solution. Suns JAVA was sold as being multi-platform and secure as it came in a sandbox. Turned out later not to be
Spoofing? Huh? (Score:2)
There are browser add-ons that bolt a PGP client onto webmail and both Yahoo and Google are planning to support PGP directly. They attempt to prevent UI spoofing with icons similar to the site-authentication banks use to combat phishing.
What does PGP support have to do with avoiding spoofing?
And what does "icons similar to the site-authentication banks use" mean?
Security has a price (Score:2)
It is higher effort and the need to understand to a reasonable degree what you are doing. You either pay that price or you do not get security.
Wrong problem (Score:2)
End-to-end encryption, done properly, solves the problem of mass surveillance and, literally, provides "pretty good" privacy to end users. Not perfect privacy, but pretty good.