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."
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."
If someone can intercept your traffic how will this help? They can intercept all your secret handshake bits too.
We need network neutrality for encrypted packets!
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."
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.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
1. Encrypted data generally has a percentage overhead
2. Encrypted data, if the algorithm doesn't suck, is not easily compressed.
I suspect they were just dumbing down all the overheads of using encryption into one catchall sentence.
Encrypt everything.
I agree, and let me add I always thought Freenet's model was onto something. It's very failure proof and it caches static content. Which unfortunately is everything. But there's probably a way to get something wiki-like using the current message board implementation, providing one had an application that could interpret the data from a dedicated board.
How do you kill that which has no life?
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'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.
OK, better late then never. Good that Google has finally introduced HTTPS as a default.
Now the next feature we all need is encryption of the content of our data when it is at rest on disks in Google's data center. That way even Google employees cannot read our mail. Not for serving up ads. Not for any reason whatsoever.
And after that, Facebook and Twitter...
Nah, I'm dreaming.
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."
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
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.
Anyone care to guess if Yahoo! will so the same thing?
I really hope so. I use a Yahoo account and I know how easy it is to sniff Ethernet. I hate to read mail at cafes and other places where I'm not certain of the LAN security.
Encryption has some overhead, but so what? It's not like modern hardware isn't up to it.
Anybody who cares about security has stopped using open protocols to send sensitive data. FTP is out, SFTP is in. Goodbye Telnet, hello SSH. And anybody who sends passwords over an open HTTP, SMTP, or IMAP connection is begging to be hacked. (POP? You're still using POP?) The issue is not security versus performance, it's the usual case of people not going to the trouble of upgrading their technology until they can't ignore the problem any more.
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, or making sure you the resources to properly support your latest product. They need to hire fewer geniuses and start hiring more ordinary drudges with the patience to make things work in the real world.
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.
1a - If your email is encrypted with IPSEC, then there's a per-packet overhead from the extra packet header; it's not really a percentage, though you could think of it that way for average packet sizes. It's not significant for most applications except VOIP, which typically has very small data wrapped in lots of RTP/UDP/IPSEC/IP headers.
1b - If your email is encrypted at or above the transport layer, there's typically minimal overhead. The data encryption doesn't take extra space, except sometimes for the last packet of a session which might not contain a full block of plaintext so it gets padded by a few bytes.
1c - There's typically some setup overhead for key exchange. It doesn't take much transmission time unless you're on some funky very-low-bit-rate transmission medium, but there can be a couple of RTTs and some public-key math calculation time. So maybe it takes an extra second for you to start Gmail - big deal.
2 - That's why you compress the data *before* encrypting. Not many people use compressed transmission systems these days (e.g. fancy WAN optimizer tricks), and if anybody's still using SLIP or PPP with header compression, it doesn't care about HTTPS vs HTTP because that's not a Layer 1/2/3 problem.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
That is why you always apply compression before encryption. Not exactly rocket science.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
4. Profit!
The day someone implements DNSSEC based server key delivery in a popular browser, there will be a grass-roots effort to make your dream come true.
...if you begin with the right URL.
Thank you, Edward Snowden.
"Arguments from authority are worthless." —Carl Sagan
I removed the Gmail gadget for iGoogle from my iGoogle homepage, because despite the iGoogle being loaded via HTTPS, the Gmail gadget would use plain HTTP.
Have they changed the Gmail Gadget to also use HTTPS? I couldn't find anything about it.
Edith Keeler Must Die
"Only two Gmail accounts appear to have been accessed"... by attacking Google systems directly. Using other methods, the attackers were highly successful.
Google disclosed that upon investigating users suspected of being attacked, they found "dozens" of Chinese human rights activists who had been compromised through phishing, malware or other systems that allowed security forces (presumably) to read their mail via a valid authentication. So, while Google itself may be mostly reliable on the backend, the security ecosystem as a whole is deeply flawed.
Google: "as part of this investigation but independent of the attack on Google, we have discovered that the accounts of dozens of U.S.-, China- and Europe-based Gmail users who are advocates of human rights in China appear to have been routinely accessed by third parties. These accounts have not been accessed through any security breach at Google, but most likely via phishing scams or malware placed on the users' computers."
http://googleblog.blogspot.com/2010/01/new-approach-to-china.html
So go change your passwords.
Is it obvious to everybody that encrypting everything is good only for privacy but doesn't seem to add much to security when compared to encrypting just the authentication data then using a session ID? Or rather, could the gurus please clarify where's the security increase in putting everything over https?
http://dilbert.com/2010-12-13
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.
-1 Wrong. Dots have been widely used in the user part of email addresses along with some other punctuation characters. From the Wikipedia article:
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.
http://dilbert.com/2010-12-13
encrypted data doesn't travel across the web as quickly as unencrypted data
That just hurts my brain.
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.
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.
How big an effort is that to do in, say, WebKit? Firefox? Why isn't anyone working on it? Or are people? What are the benefits?
Forgive my ignorance, I truly didn't know. Is it something that a few thousand dollars of programming time would buy?
How do you effectively search your email history if it's all encrypted? Are there algorithms for indexing encrypted data without giving too much away?
If they make Google Apps HTTPS only, I'll be screwed, because my little embedded devices can't handle HTTPS stack.
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...
Don't thank God, thank a doctor!
I really want EVERY site I visit to use https. Why doesn't slashdot?
Just another "Cubible(sic) Joe" 2 17 3061
The standard e-mail addressing scheme for nearly all institutions is firstname.lastname@blahblah... It is most certainly valid.
Google just - being a service where anyone can register - wanted to ignore dots so that johnsmit@gmail couldn't impersonate john.smith@gmail and the other way around. In addition, google only allows a-z, . and 0-9, so you can't register john-smith@gmail, john_smith@gmail... etc... You actually need to have different letters and number combination than anyone else.
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
> 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.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I will be really scared when encryption systems do comprehension.
There is a free certificate authority: http://www.cacert.org/ . Unfortunately, it's not "official", but the root certificate is installed by default on a lot of free systems. (see ca-certificates package in Debian) I'm sure slashdot users are techy enough to understand it.