Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Gmail Moves To HTTPS By Default

timothy posted more than 4 years ago | from the you-mean-I-gotta-log-in-again? dept.

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

cancel ×

275 comments

Sorry! There are no comments related to the filter you selected.

Hang on... (2, Funny)

Anonymous Coward | more than 4 years ago | (#30757408)

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.

Re:Hang on... (1, Insightful)

Anonymous Coward | more than 4 years ago | (#30757510)

You, sir, are an idiot!

Re:Hang on... (4, Informative)

Brian Gordon (987471) | more than 4 years ago | (#30757698)

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

Re:Hang on... (0)

MichaelSmith (789609) | more than 4 years ago | (#30758636)

We have been through this before. Many times. Reading the wiki article:

In the original description, the Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack. A person in the middle may establish two distinct Diffie–Hellman key exchanges, one with Alice and the other with Bob, effectively masquerading as Alice to Bob, and vice versa, allowing the attacker to decrypt (and read or store) then re-encrypt the messages passed between them. A method to authenticate the communicating parties to each other is generally needed to prevent this type of attack

Encrypted data doesn't travel across web as quick (3, Funny)

Anonymous Coward | more than 4 years ago | (#30757412)

We need network neutrality for encrypted packets!

iGoogle support? (5, Informative)

l2718 (514756) | more than 4 years ago | (#30757432)

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

Re:iGoogle support? (5, Informative)

incripshin (580256) | more than 4 years ago | (#30757522)

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.

Re:iGoogle support? (2, Insightful)

incripshin (580256) | more than 4 years ago | (#30757792)

Offtopic? You cannot be serious.

Rubber ball mods (-1, Flamebait)

hrimhari (1241292) | more than 4 years ago | (#30758600)

It bounced back. While the correction for the original post is most welcome, I can hardly see why the second one deserves such a positive rating.

Re:iGoogle support? (0, Offtopic)

Hurricane78 (562437) | more than 4 years ago | (#30758848)

I also noticed that normal comment trolling now went down, while moderation trolling rose strongly. But I still wonder if someone could trick the system, or if the mod points will soon be burned away...

Re:iGoogle support? (3, Informative)

linj (891019) | more than 4 years ago | (#30758114)

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:iGoogle support? (1)

incripshin (580256) | more than 4 years ago | (#30758624)

Ha! Ironically I never tested to search with https iGoogle.

Re:iGoogle support? (1)

kindbud (90044) | more than 4 years ago | (#30758752)

u cannot mix http and https content in a page,

<Kyle's Mom>Wha-wha-wha?</Kyle's Mom>

Sure 'u' can.

Re:iGoogle support? (1)

incripshin (580256) | more than 4 years ago | (#30758894)

I guess I should be more specific. Two documents that were sent over differing protocols cannot interact. A frame or iframe has its own document.

Or are you referring to my use of 'you' as a genderless third person?

Re:iGoogle support? (1)

FlyingBishop (1293238) | more than 4 years ago | (#30757566)

Google has a lot of rough edges on their peripheral apps. The Android plugin for Eclipse is unsigned. (And this is the plugin that most developers will be signing their apps with.)

Re:iGoogle support? (1)

Elwood P Dowd (16933) | more than 4 years ago | (#30757804)

I believe it does. I'm not sniffing, so I could be wrong here. Do you have any explanation for this statement?

Re:iGoogle support? (1)

Nukenbar (215420) | more than 4 years ago | (#30758122)

Every two weeks or so Google asks you to reconfirm your password. If the app hits this, it will give you the https error. All you have to do is manually log in and the app will work again.

Re:iGoogle support? (1)

amRadioHed (463061) | more than 4 years ago | (#30757944)

It didn't used to, but it's working for me now. I just checked and my gmail is still set to always use HTTPS.

Re:iGoogle support? (1)

espamo (1061728) | more than 4 years ago | (#30758678)

Yes, it didn't used to, but It's been working for me for awhile also, maybe a month. The gadget's iframe address uses https.

Sniffing? I disagree. (4, Informative)

FooAtWFU (699187) | more than 4 years ago | (#30757440)

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.

Re:Sniffing? I disagree. (1)

Antique Geekmeister (740220) | more than 4 years ago | (#30758392)

Given that connecting a new POP3 client, or new IMAP client, and syncing up your data is likely to grab everything in your relevent folders, including "All Mail" if you're not careful, I doubt that such transactions would normally be noticed. And given the incredible amount of logging involved, I doubt that Google hangs onto those logs for very long. Can anyone attest to how long individual transaction is preserved for at Google?

Great! (4, Informative)

jwinster (1620555) | more than 4 years ago | (#30757456)

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:Great! (2, Interesting)

Anonymous Coward | more than 4 years ago | (#30757820)

Great move by Google,

Especially considering yahoo & hotmail don't have any option for https.

Google just doesn want... (0, Troll)

Megaweapon (25185) | more than 4 years ago | (#30757488)

others sniffing the traffic they want to store for you on their end as to keep it all to themselves.

Re:Google just doesn want... (0)

Anonymous Coward | more than 4 years ago | (#30757858)

In other news: That's why they at the same time blocked all incoming and outgoing e-mail traffic, as they couldn't stand the idea that their customers would share information via Google's service.

Wait, what? (1)

Hatta (162192) | more than 4 years ago | (#30757534)

encrypted data doesn't travel across the web as quickly as unencrypted data.

Why on earth would that be? Routers don't know whether your data is encrypted or not. The one difference I can think of is that encrypted data can't be compressed. But that wouldn't have any effect on latency, just throughput. And that can be taken care of by compressing the data before you encrypt it anyway.

Re:Wait, what? (3, Informative)

Anonymous Coward | more than 4 years ago | (#30757554)

1. Encrypted data generally has a percentage overhead

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

Re:Wait, what? (3, Informative)

HeronBlademaster (1079477) | more than 4 years ago | (#30757624)

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.

Re:Wait, what? (2, Funny)

Anonymous Coward | more than 4 years ago | (#30758502)

4. Profit!

Re:Wait, what? (0)

Anonymous Coward | more than 4 years ago | (#30757656)

3. Encryption/Decryption takes compute cycles.

Re:Wait, what? (1)

Drumpig (13514) | more than 4 years ago | (#30758146)

5. Some ISP's throttle encrypted data.

Not really informative (3, Interesting)

billstewart (78916) | more than 4 years ago | (#30758354)

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.

Re:Wait, what? (3, Insightful)

Sir_Lewk (967686) | more than 4 years ago | (#30758476)

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

That is why you always apply compression before encryption. Not exactly rocket science.

Re:Wait, what? (2, Insightful)

The End Of Days (1243248) | more than 4 years ago | (#30757610)

I suspect they were just dumbing down all the overheads of using encryption into one catchall sentence.

Re:Wait, what? (3, Informative)

Ant P. (974313) | more than 4 years ago | (#30757618)

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? (1)

TSHTF (953742) | more than 4 years ago | (#30757832)

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

Re:Wait, what? (2, Informative)

duguk (589689) | more than 4 years ago | (#30758168)

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.

Re:Wait, what? (1)

Hurricane78 (562437) | more than 4 years ago | (#30758642)

Hmm, I wonder if I should try to finish my old project:
An AES encrypted packet-based bytestream connection between the client and the server, implemented in pure JavaScript (client) and Java (server).
With JSON inside the packets. And most importantly: One standing connection. (A single HTTP request that does not time out.)
I already did the basic framework. Back then I had already a “network card” and a “network file system” protocol and object. Also compression is built-in into HTTP (with all major servers).

Of course, back then it ate way too much CPU. But nowadays...

Re:Wait, what? (1)

TheRaven64 (641858) | more than 4 years ago | (#30758724)

HTML 5 includes a WebSocket object that allows you to keep persistent connections to the server and send data in both directions over it.

Re:Wait, what? (4, Informative)

profplump (309017) | more than 4 years ago | (#30758796)

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:Wait, what? (1)

phizi0n (1237812) | more than 4 years ago | (#30757666)

1) Encryption/decryption take time. While time for packets to travel across is unchanged, the overhead of (en|de)cryption does add to the overall latency from layer 7 http server to layer 7 client app and vice versa.
2) It's possible that some ISP's may have lower QoS priorities for specific encrypted traffic, traffic they can't identify, or port 443.

Re:Wait, what? (0)

Anonymous Coward | more than 4 years ago | (#30757716)

I also wondered what they meant by that. Many people don't understand that encrypted data is the SAME SIZE as unencrypted data. That said, there is additional work on each end of the communications to negotiate the session and actually encrypt and decrypt the data. Also, existing proxies and caches may provide fewer performance benefits under HTTPS.

Re:Wait, what? (1)

EvanED (569694) | more than 4 years ago | (#30757976)

Many people don't understand that encrypted data is the SAME SIZE as unencrypted data.

That depends on your encryption algorithm. For instance, some are block-based, which means at the least you have to round up to the nearest block size. I don't know whether SSL fits into this or not.

There's also overhead of setting up the encryption: SSL has a few messages that pass back and forth (to establish the signature is correct) before you even begin the transfer.

Re:Wait, what? (3, Insightful)

Anonymous Coward | more than 4 years ago | (#30757734)

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:Wait, what? (1)

Hairy1 (180056) | more than 4 years ago | (#30757760)

Apart from the CPU of encrypting there is the issue of compression. Perhaps some physical network links use compression, and encrypted traffic can't be compressed?

Re:Wait, what? (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30757818)

I think is a common misconception to think that encrypted data cannot be compressed.

On Compression of Data Encrypted with Block Ciphers (from DCC2009, http://dx.doi.org/10.1109/DCC.2009.71).

From the article conclusions: "Simulation results indicate that, while still far from theoretical limits, considerable compression gains are attainable and improved performance can be expected as block sizes increase in the future."

Re:Wait, what? (2, Informative)

profplump (309017) | more than 4 years ago | (#30758716)

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.

Intercepting emails (5, Informative)

Adrian Lopez (2615) | more than 4 years ago | (#30757542)

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

Found the source (5, Informative)

Adrian Lopez (2615) | more than 4 years ago | (#30757694)

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:Intercepting emails (1)

AHuxley (892839) | more than 4 years ago | (#30757714)

Its all in plain text until sent, thats how LOE gets to read, google is a good company.
The end users feels safe as they are using the "s" and no more plain text in the wild.
Google would have never offered "s" unless they have a backdoor.

Re:Intercepting emails (1)

Monkeedude1212 (1560403) | more than 4 years ago | (#30757936)

While true that it wasn't interception - I am sure the recent involvement with the Chinese security issues has simply brought into focus how much Google is being attacked, also knowing that they are dealing with some relatively skilled hackers. Whether the attacks were designed to sniff out people not using HTTPS or not - better to just remove that option altogether.

The beginning of HTTPS for everything by default? (5, Insightful)

maillemaker (924053) | more than 4 years ago | (#30757552)

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:The beginning of HTTPS for everything by defaul (2, Interesting)

rastilin (752802) | more than 4 years ago | (#30757616)

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.

Re:The beginning of HTTPS for everything by defaul (0)

Anonymous Coward | more than 4 years ago | (#30757964)

sadly freenet is empty if you dont count the pedophile....

Re:The beginning of HTTPS for everything by defaul (2, Insightful)

Anonymous Coward | more than 4 years ago | (#30757628)

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:The beginning of HTTPS for everything by defaul (1)

larry bagina (561269) | more than 4 years ago | (#30757764)

if you want encryption, encrypt your email. Encrypting the connection between you and your smtp/pop server doesn't change the fact that the message is not encrypted when stored on the server or sent between hosts.

That said, I have been using gmail over https because I often check it using free wifi and damned if I know what kind of logging, packet inspection, or html modification might be going on.

Re:The beginning of HTTPS for everything by defaul (1)

mrmeval (662166) | more than 4 years ago | (#30757894)

I deal with the vast unwashed neo-luddites who are happy with their on button and cup holder. They can with some effort open and read emails. Asking them to manage a secure public key system is beyond their fragile minds. At least their mail is harder to hack.

Having terrified them that they would lose everything including pension if they did anything with banking or 401k or bought anything at least my parents are safe.

Though to my dismay they used a debit card for the first time last year. When they told it to me you'd think they'd survived the Donner party.

Re:The beginning of HTTPS for everything by defaul (0)

Anonymous Coward | more than 4 years ago | (#30757766)

Not much point with gmail though. If the power that be wanted access to your account they would simply look up Google's "lawful interception" pricelist and pay them the $40.

Re:The beginning of HTTPS for everything by defaul (1)

Sloppy (14984) | more than 4 years ago | (#30758416)

If the power that be wanted access to your account they would simply look up Google's "lawful interception" pricelist and pay them the $40.

Google probably only (at least intentionally) offers that service to governments. So while it might not protect you from the biggest threats out there, there sure as hell would be a point to it.

Re:The beginning of HTTPS for everything by defaul (0)

Anonymous Coward | more than 4 years ago | (#30757844)

The spooks in government and private industry (hi IT dept, snoop anything juicy recently?) don't want encrypted traffic to become the norm. They have the ear of their respective leaders, so I wouldn't expect the status quo to be changing anytime soon. The plebs don't even realize what they've given up.

(Posted using my work computer via unencrypted HTTP piped through an SSH tunnel)

Re:The beginning of HTTPS for everything by defaul (1)

phantomfive (622387) | more than 4 years ago | (#30758052)

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.

Re:The beginning of HTTPS for everything by defaul (1)

trentblase (717954) | more than 4 years ago | (#30758584)

Maybe you don't want that cute barista (who is also a geek and watches coffee-shop router traffic for fun) to know you are watching a Taylor Swift video?

Re:The beginning of HTTPS for everything by defaul (5, Insightful)

dissy (172727) | more than 4 years ago | (#30758822)

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:The beginning of HTTPS for everything by defaul (2, Interesting)

Anonymous Coward | more than 4 years ago | (#30758504)

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.

Re:The beginning of HTTPS for everything by defaul (1)

Hurricane78 (562437) | more than 4 years ago | (#30758676)

Since when is HTTP(S) “everything”? Maybe for those who have never seen something else than HTML and webapps.

Just set up VPN-like connections. Or think it to the end, and use a Darknet by default. ;)

Really? (1)

rastilin (752802) | more than 4 years ago | (#30757558)

I wonder if this has anything to do with the reports of Chinese users having their accounts hacked?

Really? No, I'm sure it's just a coincidence.

Keyloggers (0)

Anonymous Coward | more than 4 years ago | (#30757560)

Unless you're entering your details via a virtual keyboard, using http or https won't make a damn bit of difference if you've got a keylogger running. (via trojan? I believe that's how the Chinese accounts were hacked)

Re:Keyloggers (0, Troll)

AHuxley (892839) | more than 4 years ago | (#30757778)

They trusted microsoft and google.
Today China, soon you.
What do you think the NSA is doing in your fly over states?
Do the Soviets have a few extra trade missions?
Wipe MS from your computer, learn all you can about linux and then meet in person to swap one time pads.

Re:Keyloggers (0)

Anonymous Coward | more than 4 years ago | (#30757824)

Keyloggers will be modified to take a screenshot as you click (if they haven't already).

Next step: encryption at rest (3, Interesting)

giladpn (1657217) | more than 4 years ago | (#30757670)

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.

Re:Next step: encryption at rest (1)

mlts (1038732) | more than 4 years ago | (#30757884)

Hushmail does exactly this. If you use the Java (as opposed to the Javascript/SSL) client, the only place E-mail gets decrypted is on your personal computer. I use Hushmail for both secure E-mail (PGP encrypted), as well as aliases that I can dispose of, such as when I'm posting to Craigslist and only want the address to last the duration of the buy/sell/work transaction.

(Yes, Hushmail did have to give information to LEOs a couple years ago, but that doesn't mean that anyone and everyone has access to one's stored data.)

Re:Next step: encryption at rest (0)

Anonymous Coward | more than 4 years ago | (#30758736)

If Google can't serve you ads, what incentive do they have to even provide you this magical secure email service?

Not through sniffing (4, Informative)

Charles Dodgeson (248492) | more than 4 years ago | (#30757712)

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.

Re:Not through sniffing (4, Interesting)

Blakey Rat (99501) | more than 4 years ago | (#30758430)

That access is actually provided in a ton of places you wouldn't expect.

Did you know that Xbox Live encrypts everything by default?

Did you know the one and only exception is... voice communication? Hmm...

Worth it (0)

Anonymous Coward | more than 4 years ago | (#30757730)

The initial slow down because of the encryption overhead will eventually be compensated for with faster networking hardware and technology so it isn't such a burden.

In the long run it will be better.

Will Yahoo! follow suit? (2, Interesting)

vinn01 (178295) | more than 4 years ago | (#30757740)

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.

No Brainer (2, Interesting)

fm6 (162816) | more than 4 years ago | (#30757742)

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.

Re:No Brainer (0)

Lord Ender (156273) | more than 4 years ago | (#30757796)

Anybody who cares about security has stopped using open protocols to send sensitive data.

I can't imagine how you manage to live your life without SMTP. Or have you convinced everyone you correspond with to use S/MIME?

Re:No Brainer (1)

fm6 (162816) | more than 4 years ago | (#30758204)

I didn't say that you shouldn't use SMTP. I said you shouldn't send a password over an open SMTP connection. There are ways to encrypt the login transaction, and even the contents of your messages. Alas, too many SMTP providers don't support this.

Re:No Brainer (1)

TheRaven64 (641858) | more than 4 years ago | (#30758770)

I think you are confusing open with unencrypted. Open protocols are ones that are documented and can be implemented by anyone. Most of these can be run with or without encryption at the lower layer.

Re:No Brainer (1)

alannon (54117) | more than 4 years ago | (#30758206)

Keep in mind that SSL-enabled versions of both POP and SMTP (with authentication) are very widely supported.

Re:No Brainer (0)

Anonymous Coward | more than 4 years ago | (#30758026)

Encryption has some overhead, but so what? It's not like modern hardware isn't up to it.

Multiply that overhead by millions of email accounts, and you're looking at a significant cost. I'm sure google has already calculated the additional server load & power usage this change will require.

(POP? You're still using POP?)

POP over SSL has been around for a very, very long time.

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

Hahaha. Can you show me the option to read yahoo mail using SSL? You can't, because IT DOESN'T EXIST. Google always gave you the option to use https, it just wasn't enabled by default.

Wait, what? (1, Redundant)

ScriptedReplay (908196) | more than 4 years ago | (#30757862)

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

Huh? Encrypted bits are asthmatic and can't run as fast as unencrypted ones? Coming from someone at Google this statement is quite the WTF. Is it too technical now to say that encrypting data requires extra calculations which introduce delays so gmail will respond somewhat slower?

Re:Wait, what? (1)

Fishbulb (32296) | more than 4 years ago | (#30758674)

Yeah, I thought the same thing. Being that several years ago my coworkers determined that using sftp (or ftp through stunnel? - I forget) added slight compression as well as encryption over regular ftp. So, even though a secure transfer was unnecessary (public weather data) and despite the cpu hit, we'd actually be saving quite a lot in bandwidth since the data was on the order of terabytes.

The best reference to this I could find was this wikipedia article [wikipedia.org] .

any experiments already done ? (0)

Anonymous Coward | more than 4 years ago | (#30757950)

I'd think someone would have done this analysis for all types of data. Can someone on Slashdot point us to those studies ? Mapping the delay times to user experience may be the missing link but surely some study indicating how decryption/encryption processing will delay response times.

Slightly off-topic... (0, Offtopic)

mustafap (452510) | more than 4 years ago | (#30757960)

why is it that if I have an account like

bob.alice@gmail.com

That mail addressed to

bobalice@gmail.com

gets delivered to bob.alice@gmail.com

Re:Slightly off-topic... (2, Informative)

jpmorgan (517966) | more than 4 years ago | (#30758080)

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

Re:Slightly off-topic... (-1)

Anonymous Coward | more than 4 years ago | (#30758092)

Becuase you arn't meant to use "." in the user part of an email address.

Re:Slightly off-topic... (1)

mustafap (452510) | more than 4 years ago | (#30758342)

Strange, because they didn't complain when I signed up.

Where's that from then? What says I shouldn't use periods? I couldn't find a reference in the SMTP rfcs

Re:Slightly off-topic... (3, Insightful)

hrimhari (1241292) | more than 4 years ago | (#30758746)

-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:Slightly off-topic... (1)

maxume (22995) | more than 4 years ago | (#30758382)

Because the system disregards the periods. The upshot is that no one can use the bobalice account to try to impersonate bob.alice.

HTTP sends more than just subject line... (3, Informative)

Omeganon (104525) | more than 4 years ago | (#30757966)

'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:HTTP sends more than just subject line... (1)

Temporal (96070) | more than 4 years ago | (#30758912)

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.

Unless the user only looked at their inbox without opening any particular message.

pochta.ru / smtp.ru (2, Informative)

xororand (860319) | more than 4 years ago | (#30758212)

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... (3, Informative)

cffrost (885375) | more than 4 years ago | (#30758510)

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

Gmail gadget for iGoogle (3, Interesting)

kindbud (90044) | more than 4 years ago | (#30758522)

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.

Huh? HTTPs? (1)

Hurricane78 (562437) | more than 4 years ago | (#30758546)

Dont’ you mean IMAPS and SSMTP?

Correction to summary (4, Interesting)

metrometro (1092237) | more than 4 years ago | (#30758666)

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

So go change your passwords.

Use HTTPS on the authentication only? (2, Interesting)

hrimhari (1241292) | more than 4 years ago | (#30758688)

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?

Ouch. (3, Funny)

machine321 (458769) | more than 4 years ago | (#30758778)

encrypted data doesn't travel across the web as quickly as unencrypted data

That just hurts my brain.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>