Slashdot Mirror
What Gmail's New TLS Icon Really Means: Email Encryption Is Still Broken
An anonymous reader writes: On Safer Internet Day Google announced that Gmail will display warning signs for missing encryption and authentication, a great initiative indeed! Now that it's live we've taken it for a spin, only to find that the warning when composing email is quite slow (for new domains), and that they fail to mention that the non-authenticated TLS encryption that the currently sad state of SMTP encryption leaves us with is really poor, and vulnerable to almost anything (except passive wiretapping). I rather wish they took a stance on how we could move on to proper email encryption.
The problem here is that crypto infrastructure in general is too fucking hard for anyone but dedicated security professionals to work with. Hell, even they have a shitload of trouble with it, as we've seen from the many OpenSSL bug debacles lately! This technology is way beyond what average, or even above-average, computer users are capable of dealing with. Some people will probably reply saying, "But it's not that hard! I can understand it!", yet those are the kind of people who understand this technology the least. At least average computer users know crypto technology is way beyond their capabilities. These self-proclaimed "experts", on the other hand, don't realize how much they don't know! Until crypto becomes far more simpler for average folks to use then we just won't see it used.
Use S/MIME, PGP, etc...
All the transport level stuff isn't going to protect your email or ensure it's not modified in transit (or at the destination or origin).
Gmail's help on their new icon:
If you see the red padlock while composing a message
Don’t send confidential material, like tax forms or contracts, to that email address.
Fuck that... if you're sending confidential email without encrypting the content, you're already screwed.
For semi-important information, one should at least digitally sign the content to prove it wasn't modified in transit (ex. this should be used for any contracts, and if it's very sensitive, it should also be encrypted, and not just on the transport layer).
Bill Gates said they would solve the spam problem a few years back. Yet my inbox under office365 that my employer uses is a chum bucket of spam, while good cron and batch job emails end up in "junk" half the time. wtf, Gates. billions and you couldn't at least have pushed domain a authentication/verification system?
Please, this has been available since 1991. 25 years and now there's concern?
PGP https://en.wikipedia.org/wiki/...
09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
I consider gmail to by my biggest threat to the privacy of my email.
If I want end to end security, well there is a standard for that. I use it. It works.
But gmail is close to having a monopoly on email. It isn't quite yet, but almost everyone I know uses exclusively gmail now. That means if I want to email them, Google IS the man in the middle. I can't easily email my friends without giving Google the contents of my email, which they will use to build a profile of me - and I've never signed up for any of their services or estasblished any kind of business relationship with them.
Furthermore, most small to medium businesses are using gmail.
Think about this: we used to have a decentralized, non-censorable, email standard that no one entity could control or pervert for their own ends. But the whole world said, "Fuck that, we want one advertising company to see everybody's email!.
Google is the main threat to the privacy of email today. Like Bruce Schneier observed, they want you to have email privacy from everyone except them.
Some of you will have a hard time with this, but... why is the problem here with SMTP? Is it really that hard to understand that MAIL TRANSPORT is not compatible with HIDE MY STUFF? Good grief people, you can't truly be that ignorant.
Do you trust that anything you mail through the Post office, FedEX, UPS, or any other mail service is "Secure"? Do you believe it's impossible for people to know what's in your boxes because you use those services? I can provide you a list of drug dealers who thought so too, but they are jailed for that thought.
Want secure, use secure. Lotus Notes was friggin awesome for securing content. Nobody wanted to pay for it though, and all the cool kids were using Outlook because you could drag-n-drop audio files right into your email (also read fart noises). Many Writing applications have encrypt/decrypt features. Zip has it too, but generic standard email? Come on now.. it's a MAIL TRANSPORT and works very well as a mail transport.
If you somehow believe "Generic Transport" can also be "Secure", I got some ocean side property you may be interested in buying.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Great, so this gets you end-to-spam filter encryption. Anyone who has their email delivered to a 3rd-party for spam filtering could appear secure but would only be secure for the first hop. False sense of security.
Using GPG seems pretty painless, at least on OS X.
The real problem with GPG is the same one you'll run into with S/MIME... almost nobody else is using it, which means all you can really do is sign your own messages.
#DeleteChrome
At least until they use they use that email notification to lure you to your toaster and detonate a small C4 charge!
I had someone contact me about my server -> gmail as I host a number of mailing lists and other technical resources. After much research it seems the only way to fix it is to hard code that gmail and other locations are to be encrypted vs the default opportunistic encryption of "if they offer it, try it".
There are a lot of things that should be addressed here to ensure data is properly encrypted, this is easy and a solvable problem but at least for postfix I had to enter some custom maps which the software should have solved for itself with the 'may' setting. I'm past the UUCP days, I don't want to maintain a map of who can do things and who can't. We need to solve this software not doing the right thing problem first.
Ive run my own mailserver for quite some time as both a mark of hacker pride and a means of circumventing what has historically (until google started giving a shit because snowden made them) been a very lax SMTP ecosystem. I use the DJB curve primes, i use 256 bit tls 1.2, i use multifactor, but as for other mailservers? crypto doesnt seem to be even a slight consideration. ive had to leave it enabled opportunistically on my mailserver, however most of the time I fallback and dont use it.
Good people go to bed earlier.
How are you going to implement that for web mail exactly? Will you let the sever do it? That means Google gets to assert your identity, and if they ever get compromised we have a whole mess of people sending signed mail with signatures that may or may not be valid and we are back to a more or less unauthenticated situation.
You could have the client do with JavaScript but that still leaves the door open, if the server is compromised and sends an altered script how can you know?
You go the traditional install plugin route, but then web mail is no more portable than a fat client.
There just isn't actually a good answer for this. You can have secure E-mail or portable E-mail but not both.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Google is trying to force servers to use STARTTLS encryption for port 25 MX traffic, this is all commendable, but they are giving their users a false sense of security. When gmail does not display the broken padlock it simply means that the first hop to the recipient's MX server supports STARTTLS, but mail is routinely stored in plain text queues on multiple servers, transmitted on in additional hops that are not necessarily encrypted, and even the first hop encryption often times uses self-signed certs or certs signed by non-authoritative CAs, so the message being sent, while being encrypted is still vulnerable to man in the middle attacks.
But Google is giving the impression that if that first hop offers STARTTLS, then the message will be sent securely and encrypted. This will result in people putting all sorts of credit card details and other information in their emails thinking (because Google said so) that the message is secure, when nothing could be farther from the truth.
Google needs to stop this right away, it's going to do way more damage than good. There is only one way to hide the content of an email from prying eyes and that is with properly implemented PGP encryption. There is no way to hide the meta (envelope) data from prying eyes. It is really important that people not be misled on this account.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
Second, Google is unwilling to provide such a plugin because it would interfere with the company's ability to scan e-mail and build advertising profiles.
Actually they were working on a PGP plugin for Chrome, though it's moving very slowly, possibly dead.
Use S/MIME, PGP, etc...
All the transport level stuff isn't going to protect your email or ensure it's not modified in transit (or at the destination or origin).
Gmail's help on their new icon:
If you see the red padlock while composing a message
Don’t send confidential material, like tax forms or contracts, to that email address.
Fuck that... if you're sending confidential email without encrypting the content, you're already screwed.
S/MIME & PGP do not hide the sender, receiver or the subject of the email (nor where you sent it from). That information is in the header, and only TLS or STARTTLS will hide it.
By the way, the TLS-SMTP problems are related to STARTTLS and stupid client software, but not TLS (but cert verification requires DNSSEC for either).
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Has anyone any idea what's happening with Google End-to-End ?
nobody should be using web based email.
At first I thought you were being sarcastic, but then realized that sarcasm makes no sense here. So you must be serious.
It's quite simple - use email for the 99.9% of your communications that does not need to be secure. Send your tax forms through a secure web site. Problem solved. Web email is still useful.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
How are you going to implement that for web mail exactly?
End to End with something like Mailvelope?
You go the traditional install plugin route, but then web mail is no more portable than a fat client. There just isn't actually a good answer for this. You can have secure E-mail or portable E-mail but not both.
People SHOULD be using "webmail" via IMAP with proper e-mail clients Then it's portable because there are mobile mail clients that can support PGP. So yes you can have portable secure e-mail, even on a phone or tablet.
You are calling for link-encryption. That is obvious nonsense for email. Proper email encryption is end-to-end and does not trust the transport at all.
Incidentally, this problem has been solved since 1991 with PGP.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Great questions, and they all have answers already.
Webmail s/mime, pgp, gpg encryption: See https://www.mailvelope.com/, or https://www.penango.com/produc..., or similar products.
Alternatively (or in addition to that), Google could provide a javascript based solution. The private key storage would be an issue, but it could be held server side via zero knowledge encryption (ie. enter password on client side, get blob from gmail, decrypt client side). JS validation is also a solved problem, though it's ugly - basically, you just sign the javascript and then validate the signatures, but there is, of course, a bit more to it than that.
For almost all users on smart phones, they use a local client, and not webmail. Google could CERTAINLY implement S/MIME and pgp support there!
As of this moment, you can already do that with products such as R2Mail2 (https://play.google.com/store/apps/details?id=at.rundquadrat.android.r2mail2&hl=en).
You go the traditional install plugin route, but then web mail is no more portable than a fat client.
For this to be even partially true, you would have to assume that all received email is encrypted (rather than just signed).
Personally, I find the need to encrypt email to be rare, but the need to verify the contents (sign) to be useful almost all the time.
If the email is only signed, then you can still read all your email via webmail without a plugin. You can even verify the signatures without a plugin (with just javascript) because signatures do not rely on the recipients private key.
You could also still send unsigned/unencrypted email, so a dumb webmail client is still useful.
All that said, the goal would be to make the feature ubiquitous. Google ships chrome, and could ship the "plugin" as part of chrome. Firefox could add a similar feature. Both could use the existing password/key storage that is already built into the browsers. For users that are taking their security VERY seriously, they'll be using a dedicated client, and probably won't be using gmail anyway.
You can have secure E-mail or portable E-mail but not both.
Sorry, but you are wrong.
All that said, it's obvious that gmail isn't the party we should look to for these features. They need to read the contents of your email in order to pay for the service (targeted ads support the service). Part of the business model is being able to read your email, so you can forget about keeping your email private from them based on any solution they provide.
I am surprised that they haven't attempted to implement s/mime or pgp with server-side private key storage. While that would significantly reduce the security of those technologies, it would also significantly increase the security and privacy for all those that currently use clear text email (and especially their webmail service), and it would provide interoperability with existing real email clients implementing the same standards (outlook, thunderbird, alpine/pine, mutt, mail.app).
There's nothing wrong with them improving the state of server-to-server and client-to-server transport layer encryption but, on its own, it does not provide sufficient protection for the examples they provided.
This company lives off of mining your data and violating your privacy. You expect them to allow you to fully protect your communications to the point where they can't figure out how to advertise to you?
Give me a fucking break.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
The two products you pointed out are essentially plugins, they won't be installed on your friends computer and they wont be on the computer in the Hotel business center. Try again. People like web mail because they don't have to carry their own laptop everywhere they go.
For this to be even partially true, you would have to assume that all received email is encrypted (rather than just signed).
No, if you are not in a position to verify the signatures, and sign your replies we are back to essentially have no identity or integrity assurance at all. Only now the non technical person has to remember different rules are in effect when using the web interface than when using their client at home. That isn't a win, its a recipe for tears.
As to mobile devices you have a point, but who wants to compose a long form message on their cell phone, table maybe but not phone.
I still see it as either portable or secure, not both.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
While usage of gpg is low, signing does show people that you use it and can help them find your pubkey if it's on a keyserver.
The story is from an author of utterly unknown email server software ranting about something he thinks he understands but doesn't, and the proceeds to tell us that the method he supports is the right one and all others suck ... If he weren't biased I might have ... Oh who am I kidding, dude doesn't know what he's talking about and utterly fails to understand how and why email is in the star it's in: hint ... Your shiny new feature breaks compatibility with far too many PAYING CUSTOMERS, so some random no name vendor like yourself doesn't mean jack shit.
No one who matters is going to go hard TLS until everyone of their CUSTOMERS supports it. Your new shiny tech that you think will solve the problem will do the opposite, and just make it take longer.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
You're telling me that PGP is a serious contender for non-technical people to secure their communications? Seriously?
Given they can't even maintain a steady pop.gmail cert I'm not expecting too much.
The reason people don't use PGP is because of the name Pretty Good Privacy makes it sound amateurish (that and the initialism PGP is too similar to PHP). Maybe they could get more users if they called it Good Privacy or Very Good Privacy, but I know there's a local-maximum trust in there somewhere because I think trust would go down if they called it Excellent Privacy or Perfect Privacy.
IMO, more people would consider using it if it used an animal name or some name from mythology.
You dont need a plugin, just implement encryption via JavaScript where the private key pairs are stored on the server but encrypted with a secret key derived from a password the server never sees. Server sends an encrypted blob to the client, client inputs a special password which then decrypts their keys.
All of the communication happens over HTTPS so man-in-the-middle replacement of the JavaScript cant easily be done.
Is it as secure as having a dedicated setup with keys stored in the client and a plugin on the local system? (or using a dedicated client with proper encryption support) No. But its much more secure than doing nothing.
Of course this leads to 2 problems for Google. First is that Google looses the ability to scan everyone's email and use that to feed people targeted advertising. And the second and more serious is that Google is now unable to provide emails when sent a warrant or a secret letter or whatever and then has to compromise the system for everyone so it can obtain the private keys of the user(s) the government is interested in (or do what Lavabit did and shut it down but I dont think Google can do that)
I still see it as either portable or secure, not both.
There are a million shades of grey between the absolutes.
Phones are portable, and can be secure, as you noted (and in so far as a phone can be secure).
Moving yourself between random 3rd party computers with who knows what running on them and checking your webmail from them... yeah, that's never going to be very secure.
Moving between multiple devices you own... you can certainly use a local mail client, or a plugin, or a javascript implementation with zero knowledge encryption holding the private bits.
Moving between devices you do not own, but aren't entirely untrustworthy (ex. a friends computer), it'll depend on the situation (maybe he has the plugin installed already and you're carrying your usb key with your private bits? maybe he creates a guest account on his computer for you? maybe you use the 100% javascript solution and the zero knowledge encryption to pull your key from an encrypted blob stored online somewhere?). There are option.
And, maybe you consider the server-side s/mime implementation as another possibility. While partially compromising the security of your private key, it's still adding a significant amount of security and verification.
Your duality statement could easily be exaggerated to, "something is either online or secure, not both". You've gotta draw your lines somewhere, but there are multiple end-to-end email encryption solutions that will greatly improve the privacy and verification of email through webmail far more than the TLS work that the article mentions.
Imagine if you could actually write good clean documented code!
Good example of how not to code.
- no useful comments
- the only two comments conflict with each other
- no line breaks before "if" constructs or after "else" constructs
- assumes existence of files for which it doesn't check existence
- doesn't check status for execution of openssl commands
Not bad for a six-year old.
M
They could at the very least provide signing, and verification of externally signed messages... If people started getting used to all messages being signed then phishing scams would become a lot less effective, and the presence of a signature doesn't have any negative side effects on anything else.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
The point is not to encrypt email during transit. The point is to encrypt e-mail at all points between the correspondents. The mail should be encrypted clientside and remain encrypted while at rest on the servers as well as during transit. S/MIME and PGP/GPG do that. Encrypting only during transit means that plaintext is sitting around waiting to be hoovered up by Google (for ad profile building) and whatever other parties (NSA, hackers, etc) have access to Google's servers.
In an ideal world yes, but for now having mail thats encrypted whenever it traverses the internet and is cryptographically signed so you can verify the recipient is an improvement. Yes this requires trusting google (which users already have to do anyway), or not - you're free to use a different email provider and/or do all the crypto client side if you want.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Not if the passphrase is manipulated using something like argon2 or scrypt that are specifically designed to make brute-forcing the password/key difficult and computationally expensive.
I doubt even the NSA has the computational horsepower to crack the best of these schemes in a reasonable space of time (if you have the parameters set really high that is)
So you're saying that...
1, users would need to trust google (but clearly they already do or they wouldn't be using their mail service)
2, the worst case (google getting hacked) would be no worse than the current status quo.
So basically email signed/encrypted by google would be better than what we currently have, but not ideal. And users are free to pick a different provider and/or do proper client side crypto but most simply don't bother. If gmail started implementing pgp or s/mime even server side and started prominently showing when mails are signed or encrypted then it would massively increase usage and awareness which could only be a good thing.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Well by portable i guess they mean that it can be accessed from any device without needing to install a client (ie from your work desktop)... From a mobile device that you control is entirely different as you can install whatever encryption tools you want on there.
While webmail can be convenient, it's also dangerous not only because of the lack of end to end encryption but also because its primary utility (ie logging in from a random place) is its biggest danger - how do you know who's monitoring any given random box you might use?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
When it comes to mobile, apple already implement s/mime on ios although configuring it is not as simple as it could be (ie even if you have mail accounts synced from a mac it can't automatically transfer your keys).
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
You can as a minimum implement verification of signatures into a webmail client, as that can all be done server side...
Users already have to (or should) remember that there's different rules when accessing webmail, in fact you shouldn't be accessing the webui from random machines if you value security at all. You should always carry your own portable device, and access your mail from there.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
If you're concerned about google reading your mail then such a system wouldn't work, while in theory the javascript performs all its work client side there is nothing stopping them changing the javascript to submit your passphrase to the server. Unless you're going to thoroughly inspect the javascript every time?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Because the key is a private key with a public key counterpart, while the passphrase is a symmetric key for decrypting (in this case the main private key)... If you have the public key its easier to attack the private key, so the private key generally needs a much larger keyspace to provide an equivalent level of assurance to a symmetric key.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
In an ideal world yes, but for now having mail thats encrypted whenever it traverses the internet and is cryptographically signed so you can verify the recipient is an improvement.
Not really. With SMTP you have no control over which MTAs the email gets queued on before it gets to the recipient. If the content is not encrypted, it will be on those untrusted servers in plain text for some (hopefully very short) period of time before it gets routed to the next server.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
PGP is great. It has one slight issue: you do not see it anywhere. The reason? It is not pre-installed.
It would be trivial to add it to Outlook, Gmail, Hormail and any other mail service or program by default. Now it needs action on the users side.
I would like Email to have PGP by default. Not to hide any content from others (because two people is one to many to keep a secret) but sender verification. Is it my bank that send me the email, or SpammerJohnny who found out you can make your own From in Outlook?
If it would be included by default in email programs, it would be uses. Not by 100% and some would turn it off, but by enough to get others to use it.
It could solve a LOT of the spam email issues, especially phishing mails. No, it will not solve everything; it will be better then what we have now: nothing.
I am not going to hold my breath. It will never happen. At most, each will try to push their own system that willl not work, leaving us worse with what we have now: nothing and no way to improve it.
Don't fight for your country, if your country does not fight for you.
As someone who just inherited a huge repo full of uncommented code with nondescript variable names (A, B, C...) and no error handling, I have to say that the parent comment isn't scored high enough. Posting crap like that on the internet does nobody any good. Even if it is short enough to understand, poorly written code is especially intolerable if the subject is cryptography.
(Anyone who says that their code documents itself hasn't tried waiting a year and then trying to figure out why their undocumented code doesn't handle some edge case.)
If you want a vision of the future, imagine a youtube comments section scrolling - forever.
FUCKING PIECE OF SHIT SLASHDOT LOGGED ME OUT. THIS IS MY COMMENT. FUCK YOU SLASHDOT. I'M SICK OF YOUR SHIT.
And fuck you for saying I'm yelling! And fuck you for saying I'm yelling! And fuck you for saying I'm yelling! And fuck you for saying I'm yelling!
Yeah, start teaching the users, that something is secure, if a lock appears INSIDE the website (or insecure, if its a broken lock). Because err nobody would ever use this to tell the user the fake banking website is as secure as the email on gmail.
People use computers, which are named like fruit. And operation systems from companies, which are named like some detergent. Their text processor's name implies you may only write one word and so on.
Nope, names aren't important. Ask the novice users, if they even know, what PGP means.