Is gmail-to-gmail still insecure? Why?
Email is historically considered insecure for two reasons:
- The SMTP network protocol is unencrypted unless STARTTLS is negotiated, which is effectively optional
- The mail messages sit unencrypted on the disk of the source, destination, and any intermediate mail servers
Google mail servers all speak STARTTLS if possible, so for gmail-to-gmail the transmission step shouldn't be a concern. However, the sending server stores an unencrypted copy of the email in your Sent folder. The receiving server stores an unencrypted copy in the recipient's Inbox. This leaves them open to various threats:
- Rogue Google employees reading that email
- Google choosing to read that email despite their assurances to the contrary
- Governments forcing Google to hand over that email
- Hackers breaking into Google and accessing that email
If you can trust everything to go right, then gmail-to-gmail is perfectly secure. But you can't always expect everything to go right.
For these reasons, the security and privacy community long ago reached the stance that only end-to-end email encryption is secure. That means the email remains encrypted on server disks and is decrypted when you're reading it, and never stored decrypted.
There have been an enormous number of comments, so let me expand/clarify a few things.
End-to-end encryption - in the context of email, when I say end-to-end encryption I mean something like PGP, where the message is encrypted until it reaches the recipient's email client, and only decrypted to be read. Yes, this means it can't be searched on the server, and often also means it doesn't remain "backed up" on the server either. This is a case where security and functionality are at odds; pick one.
Security and privacy community - unlike many Information Security topics, email security is one that extends out to other communities. The question of what stateful inspection in a firewall means is not something often extended out to interest others, for example. But email security is of direct, significant interest to
- Human rights workers
- Whistleblowers
- Insurgents
Forget about credit card data, there are people trying to communicate with email whose lives, and the lives of their families, depend upon the security of the email. So as there are phrases in the comments below like "depends upon what your standards are for 'secure'", "sufficiently motivated adversary", "there is an illusion of security at the email-level" - am I being too strong to say the server can't be trusted? Not for people whose lives are at stake. That's why the phrase "email is insecure" has been the mantra of the privacy movement for 20 years.
Trusting the server - In the US, "your cap for liability for unauthorized charges on a credit card is $50" so you may well be happy trusting the server with your credit card. If you're cheating, on the other hand, you might lose a lot more as the result of leaving unencrypted email on the server. And will your service provider shut their doors to protect your privacy? Probably not.
STARTTLS - STARTTLS is SSL for email; it uses the same SSL/TLS cryptographic protocol to encrypt email in transit. However, it is decidedly less secure than HTTPS for several reasons:
- STARTTLS is almost always "opportunistic", meaning that if the client asks and the server supports it, they'll encrypt; if either of those things are not true, the email will quietly go through unencrypted.
- Self-signed, expired, and otherwise bogus certificates are generally accepted by email senders, so STARTTLS provides confidentiality but almost none of the authentication. It's relatively trivial to Man-In-The-Middle email if you can get in between servers on the network.
A lot of this hinges on what you mean by "insecure".
Traditionally e-mail was considered an insecure transport as it was transferred over an unencrypted protocol (SMTP) and typically you had limited control over how the e-mail actually reached it's destination, so you wouldn't necessarily know about the security of the systems that it traversed.
These days most modern large e-mail providers use encrypted transfer protocols (generally SMTP + SSL) which removes the concern about the e-mail being sent over the Internet in the clear, however for generally Internet e-mail the concern about not knowing what systems will process the mail on the way to it's destination remains.
In your case you would seem to know that as it'll be google sending and receiving, so it's not likely to leave their control.
A couple of potential concerns remain.
- do you trust Google? Presumably you do as you're using their mail service, but it goes without saying that they could theoretically get access to your mail.
- Security of the mail once it reaches it's destination. You may not have control over how the recipient stores/processes the mail and that could result in it being held insecurely (e.g. being downloaded to an unencrypted mobile client, stored on an unencrypted PC etc). Also e-mails tend to get forwarded on, so there's always the risk that someone sends it to another party who's not hosted on google.
If you're satisfied in both those regards then generally yep I'd say there's nothing wrong with using e-mail for general data transfer. The one other point I'd mention is that specifically for things like Credit card data, if you're a business you'll have compliance concerns (e.g. PCI) and they may well preclude the use of e-mail.
In the Snowden revelations it showed that the NSA had tapped into the fibre cables connecting Google's datacenters together. You can refer to the image below and make your own deductions about whether anything on Google's network is actually secure.
They may have improved the situation since then, but it would be hard to prove to customers exactly what they've done to improve security on their network and that the government no longer have full access. You would have to take their word for it. If you want real security you should use open source end-to-end encryption where only the sender and receiver have the private keys and all encryption/decryption is done client side. There are a number of new webmail services around for this or you can always use the classic GnuPG.