Gmail Moves To HTTPS By Default 275
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."
Re:Hang on... (Score:1, Insightful)
The beginning of HTTPS for everything by default? (Score:5, Insightful)
I've long held that the only answer to pervasive surveillance is to encrypt everything.
It won't stop them from cracking things that attract their attention, but for most things it won't be worth the hassle.
Encrypt everything.
Re:Wait, what? (Score:2, Insightful)
I suspect they were just dumbing down all the overheads of using encryption into one catchall sentence.
Re:The beginning of HTTPS for everything by defaul (Score:2, Insightful)
I've often wondered why email clients don't make it easier to set up encryption, and use it as the default if your recipient and you have exchanged keys (preferrably automatically if both have the capacity.) Sure, if you're semi-clued up it's not that hard to set this up manually, but to the average user it's way out of their comfort zone.
Re:Wait, what? (Score:3, Insightful)
The reason why encrypted data tends not to travel as quickly (other than the fact that it is incompressible) is that a lot of DPI filters in a number of links throttle anything encrypted, assuming if it is encrypted, then its P2P traffic.
Re:iGoogle support? (Score:2, Insightful)
Re:Wait, what? (Score:4, Insightful)
That is why you always apply compression before encryption. Not exactly rocket science.
Re:Slightly off-topic... (Score:3, Insightful)
-1 Wrong. Dots have been widely used in the user part of email addresses along with some other punctuation characters. From the Wikipedia article: [wikipedia.org]
The local-part of the e-mail address may use any of these ASCII characters:
* Uppercase and lowercase English letters (a-z, A-Z)
* Digits 0 to 9
* Characters ! # $ % & ' * + - / = ? ^ _ ` { | } ~
* Character . (dot, period, full stop) provided that it is not the first or last character, and provided also that it does not appear two or more times consecutively.
Re:The beginning of HTTPS for everything by defaul (Score:5, Insightful)
I don't know, I think there are some things that don't need encryption. I don't think I will ever need encryption to read google news, for example, or to watch youtube movies.
Actually yes you need to encrypt that too.
If you are selective about what you encrypt, then the best assumption to make is that the things you don't want/need to hide are plain text, and the things you want/need to hide are encrypted.
Now when I am watching your data stream and see some google news, a youtube video, and finally an encrypted block of data, it is almost certain that whatever is in that encrypted block of data is worth my while to try and crack, as it is clearly data you want hidden.
If you encrypt everything all the time, then I would always wonder what you are hiding (if anything!)
I could take some of your encrypted data and try to crack it. Say it works once or twice, and all I see are you reading your daily news, and some video of a kitten falling over on youtube. Well hell, suddenly not only did I waste a lot of time cracking that encryption for nothing, but I would assume (possibly mistakenly) that you very well might not have anything to hide, and there is no reason to specifically look into anything you are doing.
Even if I don't assume that, and either assume or just know that you DO have something to hide... Well as a hacker, where would I start? I don't have all the time and processing power in the world to brute force everything you do. I would always be very behind your 'now' traffic. By the time I eventually did get to decrypting the part you really wanted hidden, it could be years or decades later. How much use would that data be so long after the fact? More often than not, the older the data, the less useful it is.
Encrypt everything. Nothing looks suspicious and out of the norm, so if/when you do something that you do want/need hidden from hackers, a hacker wouldn't even know it happened let alone know where to start looking for it.
Not encrypting everything just paints a huge target on the exact data you are wanting to hide in the first place.
Re:Found the source (Score:4, Insightful)
And that right there, proves we're at war with China--much more than Al Qaeda. Just like George Washington's crossing of the Delaware, their attacks happen on Christmas eve.
People say it's kolluj students with time off, and to a certain extent--near uni holidays, you can see port scans and other crap go up. But the real--nasty brutish attempts, the subtle ones--happen christmas, easter, labor day--right when people aren't paying close attention. They're diabolical, they're automated--and tools like fail2ban don't catch the ssh brute force attempts, because they come from thousands of hosts one at a time--just trying to sneak in. And that's in addition to the web application attacks.
I haven't finished writing my fake SSH server yet to see what people do when they get in, but I'm betting the entire medium is just one giant funnel to beijing intelligence looking to slurp down as many usernames and passwords as they can.
They're in our network, they've been in our networks. They've compromised the DoD, and hundreds of defense contractors, and the national labs. And because they're all corporate, it hardly ever makes the news--people that reveal it are sued and/or fired under suspicious circumstances.
Make no mistake--this is war, and China is winning because we refuse to even admit it.
Was it really about that? (Score:3, Insightful)
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.
Bullshit.
Ok, maybe it's true, but it seems much more likely that this was about them conserving CPU, not about you getting your email faster. That would be why it's taken until now for them to take this step.
Of course, it's still fairly useless if I stay logged in -- then my session could still be hijacked from vanilla Google searches...
Re:Hang on... (Score:2, Insightful)
Maybe that cert has been compromised by a Chinese insider. Maybe that is why google are so upset with China at the moment. I know that in some corporate environments https is a big issue for IT security. They don't like employees punching through their filters with SSL. China may have a similar attitude and may have been trying to get their hands on the certs for some big companies.
Re:No Brainer (Score:3, Insightful)
> As usual, Google leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issues
and now you show me another free mail service of any significance that has IMAPS, POP3S, SMTPS and now HTTPS (yes, all with *S, because Gmail requires you to use SSL for SMTP, POP3 and IMAP, and has been doing so since the very beginning, HTTPS was available for use for a while, though not required or offered by default). ...right?
if google is dead last, the internet must be swarming with secure mail services, right?
Re:The beginning of HTTPS for everything by defaul (Score:1, Insightful)
A more important aspect is that everybody should use encryption. Singling out people for using encryption is a bigger threat than singling out encrypted data. As long as the encryption is good quality, "they" can't break the encryption, but "they" can break people. Encrypting everything makes mass-surveillance impractical.
encrypted data slow? WTF? (Score:2, Insightful)
https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data
Reference please? How would encrypted data travel any different than unencrypted date? Routers don't look at content and the difference in payload sizes is negligible.
Perhaps the poster is assuming the CPU required for encryption/decryption will slow the message down but we're talking about milliseconds, nothing that rises to the level of human perception.
Honestly have to wonder whether the OP is a Yahoo!, Compuserv, or AOL employee, given how out-of-date those companies' email and webmail offerings have become. Everyone else converted to HTTPS webmail and IMAP/POP over SSL/TLS long ago.
Re:What about slashdot? (Score:3, Insightful)
Because there's no reason to. What are you trying to protect, valuable mod points?
Oh, and don't say "I want to encrypt everything, so the hackers don't know what's important". HTTPS doesn't hide the IP you're accessing. If you want that kind of protecting, you should get a secure VPN or Tor.
Re:The beginning of HTTPS for everything by defaul (Score:3, Insightful)
You are exactly right. This is for the very same reason that we need to start making encryption standard for everyone; if your scenario was to take place under current circumstances, you would already be under suspicion and under greater focus since most people don't encrypt everything... when everyone encrypts everything, it will finally be the case that no pattern can be deduced from the presence of encrypted data
Re:The beginning of HTTPS for everything by defaul (Score:3, Insightful)
> Not encrypting everything just paints a huge target on the exact data you
> are wanting to hide in the first place.
Right. So just encrypt the kitten videos and send lots of tantalizing stuff in the clear. That'll fix 'em.
Re:Hang on... (Score:4, Insightful)
Have you see what root CA certs are in a browser? I'm sure that if one pulls it up and sees the list of trusted root certificates, there are offshore companies that people have not heard of, but yet not just hold charge of what is valid or not, but can delegate to people unknown who gets a green toolbar, and who doesn't. To boot, all it takes is just one of these to be compromised, and someone can start doing bogus certificates. Combine this with using Unicode text (the Cyrillic "C" is not the ASCII "C"), and one could completely spoof a legit site in an advanced phishing attack... or just threaten that legit site with the spoofing so they would pay protection fees.
What I'd like to see in Web browsers is perhaps something similar to what is done in ssh, where the Web browser keeps track of the SSL certificate that the bank uses. If it changes, the browser will pop up a notice, and perhaps show some pertinant info, showing that this is either legit, or maybe show that someone spoofed a CA and the cert is completely bogus.
Re:Ouch. (Score:4, Insightful)
Encrypted data doesn't generally compress as well as plaintext, and it's quite common for web servers to compress data before sending it to the client.
...and it's quite common for security libraries to compress data before encrypting it. For instance, it's the default in GPG, and SSLv3 and TLSv1 support configuring compression in the handshake.