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."

iGoogle support?

[l2718]

For the moment Google's own gadget for for iGoogle doesn't support HTTPS access to gmail.

Sniffing? I disagree.

[FooAtWFU]

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.

Great!

[jwinster]

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 [google.com]

Re:iGoogle support?

[incripshin]

I have been complaining about this for a while. You cannot mix http and https content in a page, so the only solution is to send the whole page and all the gadgets over https. This is possible to do now, though you have to type in https://www.google.com/ig [google.com] (necessary parts: https, www, /ig). There is also no preference for this as far as I can tell.

Intercepting emails

[Adrian Lopez]

'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.

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]

Re:Wait, what?

[Anonymous Coward]

1. Encrypted data generally has a percentage overhead

2. Encrypted data, if the algorithm doesn't suck, is not easily compressed.

Re:Wait, what?

[Ant P.]

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.

Re:Wait, what?

[HeronBlademaster]

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.

Found the source

[Adrian Lopez]

I found the source. It's from PC World [pcworld.com]:

That's because they apparently were able to access a system used to help Google comply with search warrants by providing data on Google users, said a source familiar with the situation, who spoke on condition of anonymity because he was not authorized to speak with the press. "Right before Christmas, it was, 'Holy s***, this malware is accessing the internal intercept [systems],'" he said.

Re:Hang on...

[Brian Gordon]

Might as well scoop up the mod points if someone's going to get them. This, moron [wikipedia.org].

Not through sniffing

[Charles Dodgeson]

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 [blogspot.com] about this. And my source for all of that is from an article [computerworld.com] in Computer World.

HTTP sends more than just subject line...

[Omeganon]

'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.

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.

Re:Slightly off-topic...

[jpmorgan]

Because Google ignores periods in account names, and have been for many years.

Re:iGoogle support?

[linj]

This has been extant for a very long time.

The problem with this which Google hasn't fixed yet, despite lots of screaming users, is that when you try to search from that search box, it ... doesn't work. It redirects you back to the original Google homepage, which isn't very smooth.

Other than that, however, it's fine!

Re:Wait, what?

[duguk]

Not always the case anymore. Web browsers and servers have implemented persistent connections (keep-alive) for a while. It's in the RFC [ietf.org].

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.

pochta.ru / smtp.ru

[xororand]

Some free mail providers have been offering HTTPS for a long time, for example the Russian https://www.pochta.ru/ [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.

So does Wikipedia...

[cffrost]

...if you begin with the right URL. [wikimedia.org]

Re:Wait, what?

[profplump]

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.

Re:Wait, what?

[profplump]

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.

Re:No Brainer

[Anonymous Coward]

I can't imagine how you manage to live your life without SMTP.

Why would he have to? SMTP over TLS [ietf.org] 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.

I hope they keep Google Apps in the clear!

[TheSync]

If they make Google Apps HTTPS only, I'll be screwed, because my little embedded devices can't handle HTTPS stack.

Re:Hang on...

[asserted]

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.

Re:I hope they keep Google Apps in the clear!

[icebraining]

In TFA:

If you trust the security of your network and don't want default https turned on for performance reasons, you can turn it off at any time by choosing "Don't always use https" from the Settings menu.

Re:Hang on...

[petermgreen]

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.