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.
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).
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.
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.
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.
If you're thinking STARTTLS then you're encrypted transport system is already broken. Use the proper SMTPS ports. A number of ISPs (including TPGi in Australia) use Cisco PIX appliances (and other) to intercept SMTP tcp/25 traffic from their users. And they force unencrypted connections by not reporting STARTTLS in its EHLO response. Your privacy and security, broken in the name of "SPAM control."
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