Slashdot Mirror
Gmail Moves To HTTPS By Default
clone53421 writes "Although Gmail has long supported HTTPS as an option, Gmail announced their decision yesterday to switch everyone to HTTPS by default: 'We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data. Over the last few months, we've been researching the security/latency tradeoff and decided that turning https on for everyone was the right thing to do.' I wonder if this has anything to do with the reports of Chinese users having their accounts hacked? 'Only two Gmail accounts appear to have been accessed, and that activity was limited to account information (such as the date the account was created) and subject line, rather than the content of emails themselves,' said David Drummond in that blog update. That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers."
For the moment Google's own gadget for for iGoogle doesn't support HTTPS access to gmail.
Google couldn't really tell if there was sniffing going on in their users' connections. They could, however, figure out exactly what sort of activities someone using POP or IMAP or the web UI (or some compromised internal Google tool) ended up doing, based on logs.
The World Wide Web is dying. Soon, we shall have only the Internet.
Great move by Google, although TFA points out that there are some problems with offline gmail and HTTPS, kudos to them for coming straight out and saying it may be a problem, while posting a link for some workarounds: http://mail.google.com/support/bin/answer.py?hl=en&answer=172697
Q.E.D.
Actually, I read somewhere that hackers gained access to a system designed to give law enforcement access to people's emails, presumably under warrant. [sarcasm]Who could have ever imagined the same loopholes intended for use by law enforcement could possibly be exploited by hackers as well?[/sarcasm]
"In prison you just have to shut your eyes and take it. Here you have to shut your eyes and give it."
1. Encrypted data generally has a percentage overhead
2. Encrypted data, if the algorithm doesn't suck, is not easily compressed.
Routers don't know whether your data is encrypted or not.
Neither does your browser, or the server. HTTP is a stateless protocol. Every encrypted request requires setting up the encryption all over again.
3. Encrypted data has two processing phases, one at each end of the connection that do not apply to unencrypted data: encryption and decryption. By "not as quickly" they were probably referring to end-users' perspective more than network transmission time.
I found the source. It's from PC World:
"In prison you just have to shut your eyes and take it. Here you have to shut your eyes and give it."
Might as well scoop up the mod points if someone's going to get them. This, moron.
Apparently the two compromised accounts were because of "access a system used to help Google comply with search warrants by providing data on Google users." I've blogged about this. And my source for all of that is from an article in Computer World.
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
No, if that were the case they would have been able to see *everything* the user received as part of the data response, including message bodies.
Omeganon
Because Google ignores periods in account names, and have been for many years.
Not always the case anymore. Web browsers and servers have implemented persistent connections (keep-alive) for a while. It's in the RFC.
You're both right, but the GP is righter. Yes, persistant connections have been around since 1999. But it still DOES starts the encrypted request all over again.
It is persistent, but it is also stateless. Makes sense when you think about it.
Some free mail providers have been offering HTTPS for a long time, for example the Russian https://www.pochta.ru/ . Their web mail interface is decent too. Unfortunately they've been bought out by or merged with "qip" and have dropped their English language option since. It's still usable though and a good option if you need a free mail account with secure authentication outside of the western countries for some reason.
...if you begin with the right URL.
Thank you, Edward Snowden.
"Arguments from authority are worthless." —Carl Sagan
The article is imprecise, but HTTPS is higher latency, even when network and CPU capacity are sufficient -- setting up an SSL connection requires several more round trips than raw HTTP, so if your latency is higher than 0 it can be noticeably slower to use encrypted connections.
Encrypted connections also typically have some per-datagram overhead, though that's typically pretty small, and not strictly necessarily on streams if you're willing to give up integrity checks. And there is a CPU load. The CPU factor was mostly relevant 15 years ago, but on low-end systems (phones, for example) it can still be a problem. And on systems with high numbers of connections (servers, for example) it's not necessarily a problem bit it does require more horsepower.
If you're using keep-alive at the HTTP layer you're most certainly not closing and re-opening the underlying SSL socket -- in typical implementations the HTTP code is only vaguely aware that SSL even exists.
Now not every server or client supports or uses keep-alive. But if you do then SSL is only negotiated once per session, not once per HTTP request.
Why would he have to? SMTP over TLS is becoming quite common now. Gmail supports it and has for some time. Many other email providers also support it, although Yahoo and Hotmail do not.
If they make Google Apps HTTPS only, I'll be screwed, because my little embedded devices can't handle HTTPS stack.
the man in the middle would have to have a valid mail.google.com certificate for the attack to be seamless.
yes, we know how effective "invalid certificate" prompts are, but this is not a failure of the encryption mechanism.
You don't need to compromise the original cert, you just need to get one of the many certification authorities that are trusted by the major browsers to create you one with the right name on it.
Afaict some of the certification authorities are very lax about checking that the person applying for the certificate is the legitimate owner of the domain and I have no doubt that if the Chinese government wanted they would have no trouble procuring such a certificate.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register