Slashdot Mirror
The Problem With Using End-to-End Web Crypto as a Cure-All
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.
The funny thing is that the technical security of snail mail (a paper envelope) is amazingly poor, but it is generally quite secure due to law and custom. However, law and custom is absolutely no security or privacy on the Internet. There is the problem.
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.
90% UI sucess rate? Hire them -- most legit websites have 80% or lower success :)
I suspect this is a made-up/"customized" statistic.
The technical people are actually working on this problem:
1. make it super easy to encrypt all websites:
https://letsencrypt.org/
2. In the long run:
"Marking HTTP As Non-Secure"
https://www.chromium.org/Home/...
And many, many more improvements.
New things are always on the horizon
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.
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.
Strive to make your client happy, not necessarly give them what they ask for
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.
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.
Using https everywhere does have some downsides, things like Javascript that contains executable code is either cachable or secure from MITM tampering. Why don't we have a way to sign content without encrypting it?
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Fix your users... Heh heh...
-- I ignore anonymous replies to my comments and postings.
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 US government wants, such as your encryption key, or your data before encryption. In a way this is more dangerous, because you are now lured into a false sense of security by the very same companies which have been cooperating with the government before, for money no less, while their small armies of lobbyists prove that they will never really betray the government - it is bad for business.
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 support S/MIME yet?
Users cannot be fixed. The best that we have is making our software as close to user-proof as possible. It will never be foolproof.
Do not look into laser with remaining eye.
And pay to bring in a business-grade connection to a place where you have control over the environment, and operate a computer as a mail server in that environment, and work diligently to keep that mail server secure, plus work to ensure that your mail server is accepted to other mail servers somehow getting whitelisted.
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.
Do not look into laser with remaining eye.
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 to log into public Wi-Fi hotspots because a lot of the websites I use daily use HTTPS, which doesn't allow the MITM that a captive portal requires. Even if I key in http: into the address bar, HSTS or the HTTPS Everywhere extension will transparently redirect my request to HTTPS. If web browsers discourage users from visiting cleartext HTTP sites, how are they supposed to log into hotspots?
Third, and most relevantly for this article, even if you "encrypt all websites", you still have to give the website (or a third-party script operating in the website's context) a copy of your private key in order for it to encrypt and decrypt your mail.
I often quote in this context a nice 1999 article, Why Johnny can't encrypt: a usability evaluation of PGP 5.0.Yes, it's old, but still interesting: What kind of shortcomings do crypto interfaces have in order to be used by a random Johnny?
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.
The main problem with x as a cure-all is that anyone believes in a cure-alls in the first place.
This is considerably more stringent than your typical abattoir. From another source:
Penicillin, anyone?
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!
Enable 3D printed prosthetics!
Maybe the meta-problem is that all our different applications/services have different data repositories and thus need separate security solutions. What if we flipped it so that each of us had a private, individually encrypted cloud repository, with identity and communication APIs layered on top? Then simple apps could be written to conform to the new "cloudspace" certificate-based authentication and security model.
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?
My other
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?
deleting the extra space after periods so i can stay relevant, yeah.
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.
Is there anything better than clicking through Microsoft ads on Slashdot?
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 to penetrate your personal hardware, even SD cards with secure Linux distros.
The problem is that it requires users to validate the URLs.
The correct algorithms are PAKEs such as SRP. 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.
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 systems presented keys and certs as first-class objects instead of little scraps of gobbldeygook texts with an empty-page or question-mark icon.
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?
systemd is Roko's Basilisk.
Anon: 'Having an "OS" which downloads random bits of the Internet and *executes* that is the big elephant in the room.'
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 the case. Please don't bore me with reasons why it's not possible to design a secure "OS".
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 useful even absent a revocation. Properly done, expiration is handled before it happens by distribution of a new key signed by both itself and the old key. Since the attacker doesn't have the old key (it hasn't been revoked) he can't forge the old signature, and if both the old and new signatures are valid the new signature can't have been created by an attacker and the new key is clean. Both expiration and revocation become even more critical when I'm dealing with people I don't know directly, and let's face it we very rarely communicate only with a small circle of people we know personally.
And no, the CA system isn't inherently less vulnerable than self-signing alone. Self-signing without some additional authentication leaves you trusting the word of a malicious party about their identity, and they're highly unlikely to tell you the truth about that. That's why a self-signed PGP key by itself can't be trusted (unless you got it directly from it's owner by a secure channel), you need additional signatures from trusted parties to affirm it's authenticity. The problem is that the certificate system itself only permits one signature on a certificate/key. PGP had it right by permitting an arbitrary number of signatures on a key. If I require at least 3 different root CAs to vouch for a certificate, it becomes much much harder for any party to compromise things. In part that's because it takes more effort to compromise 3 root CAs, but it's also because it makes revoking a root CA certificate much less of a problem. Right now revoking a root CA certificate instantly invalidates every single certificate issued by that CA. Allowing multiple signatures would mean it would only invalidate those certificates where that CA was the last remaining trusted CA signing the certificate. OTOH if my certificate were signed by Equifax, Experian and Verisign and it was found Verisign had given their root key to the government, my certificate would still be valid after Verisign's root certificate was forcibly untrusted because I've still got 2 trusted CAs vouching for it. I'd only be in trouble if Equifax and Experian had both already had their root certificates untrusted and I'd failed to get additional signatures done by other CAs before Verisign went.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
https://www.eff.org/https-everywhere