back to article Google wants to add 'not encrypted' warnings to Gmail

Google is getting ready to alert Gmail users when messages are received in the clear instead of via encrypted transport, in response both to slow adoption of encryption by some hosts, and apparent hostility to encryption in some countries. Seven countries – Tunisia, Iraq, Papua New Guinea, Nepal, Kenya, Uganda and Lesotho – …

  1. Eugene Crosser
    Facepalm

    Yeah, right.

    Rather than fussing about largely useless TLS SMTP, Google ought to make better effort to support PGP in its webmail client.

    1. A Non e-mouse Silver badge

      Re: Yeah, right.

      In Bruce Schneier's blog, he references a study which basically says that PGP tools are still not suitable for general use for email encryption & authentication.

      PGP for email will only become mainstream when (if?) it becomes almost as easy as HTTPS is to use.

      1. Pascal Monett Silver badge

        I don't see that that can happen. HTTPS depends on the server and client supporting it - which is basically baked in by server admins and browser makers without user input. PGP depends on every user exchanging excryption keys with everyone they contact.

        Until we get an Internet-wide public key database for every mailbox available, it will never be as easy as HTTP.

        1. DropBear Silver badge

          "Until we get an Internet-wide public key database for every mailbox available, it will never be as easy as HTTP."

          ...which will always be problematic in terms of trusting that server. So, what next? Blockchain...?

          1. dogged

            > ...which will always be problematic in terms of trusting that server. So, what next? Blockchain...?

            You'll rapidly run into size problems with a blockchain, of exactly the type that's causing issues in the BitCoin community right now.

        2. Anonymous Coward
          Anonymous Coward

          > Until we get an Internet-wide public key database for every mailbox available

          https://pgp.mit.edu/

          (Do note the serious security risk of relying on keyservers without having checked fingerprints first)

        3. Anonymous Coward
          Anonymous Coward

          > Until we get an Internet-wide public key database for every mailbox available, it will never be as easy as HTTP.

          Reason it'll never be as easy as HTTPS is that it is somewhat akin to asking to see an ID (and showing yours) every time you communicate with someone in real life. It is only done when "necessary" (i.e., seldom) because it's cumbersome.

          That is for PGP. The X.509 approach perhaps does have a bit more chance of succeeding, but it is subject to the same weaknesses as X.509 on HTTPS--basically, central authority trust or lack thereof.

      2. dogged

        Re: Yeah, right.

        > In Bruce Schneier's blog, he references a study which basically says that PGP tools are still not suitable for general use for email encryption & authentication.

        And I think that's where the OP is recommending that Google concentrate their efforts. The whole process is clunky at the moment. Surely somebody can come up with a user-friendly way?

        1. John Brown (no body) Silver badge
          Coat

          Re: Yeah, right.

          "Surely somebody can come up with a user-friendly way?"

          Google Wave?

      3. Anonymous Coward
        Anonymous Coward

        Re: Yeah, right.

        PGP for email will only become mainstream when (if?) it becomes almost as easy as HTTPS is to use.

        Even if that happens you only end up with partial protection: the weak point of PGP and friends is that it only encrypts the body of an email message. One of the reason mass surveillance is of interest is because it reduces the need for seeing what is in a message - inferences are made on context (who it was sent to, the associated network, synchronicity of timing etc etc). That this results in a less precise analysis is something that few people understand, which is partly what causes the problem with no-fly lists and so on - we're talking about derived probabilities rather than raw facts. Sorry, going offtopic a bit

        In short, PGP protects only one factor of comms, but there is much more to consider. Even making it easy to use will still give you only a fragment of what you need.

        1. dogged

          Re: Yeah, right.

          > In short, PGP protects only one factor of comms, but there is much more to consider. Even making it easy to use will still give you only a fragment of what you need.

          Moscow rules, old boy. You need a blind cut-out. In the cold war this was a person or a dead letter drop along with an entirely unrelated notification. Smiley's People uses a discarded cigarette packet containing a photo negative - carry no documents you cannot discard instantly without attracting notice - and yellow chalk elsewhere. Two unrelated elements.

          The modern equivalent would be something along the lines of an anonymous single-use account with a provider both initial parties have agreed upon along with an entirely unrelated notification of significance only to the recipient. Something that indicates no connection between the two parties. Perhaps a comment or post on an open forum.

          1. dotdavid

            Re: Yeah, right.

            "The modern equivalent would be something along the lines of an anonymous single-use account with a provider both initial parties have agreed upon along with an entirely unrelated notification of significance only to the recipient. Something that indicates no connection between the two parties. Perhaps a comment or post on an open forum."

            And suddenly the purpose of amanfrommars' posts becomes clear.

        2. LDS Silver badge

          Re: Yeah, right.

          Just, delivery/routing information which are fully encrypted are a bit hard to use for their intended use... but it's true other headers could be encrypted.

    2. Doctor Syntax Silver badge

      Re: Yeah, right.

      I don't think it's a matter for Google alone. It needs to be baked into the mail protocols so that encryption is the default. It would need to be phased in in a backwards compatible manner but at some point the existing SMTP would be deprecated and any lagging clients & servers would find themselves shut out.

      What Google needs to do is start pushing RFCs for this. Except I'm not sure Google would be the best party for this. They're likely to want something that would end up with plain text on their servers so they can scan it.

      1. Vic

        Re: Yeah, right.

        It needs to be baked into the mail protocols so that encryption is the default. It would need to be phased in in a backwards compatible manner

        You've already got that. SMTP aleady supports the STARTTLS verb, and you can configure your mailserver to require TLS for some or all of your connections. This isn't today's technology - it's been there a long time.

        The problem you have is that many people simply do not use the capabilities there. Until and unless they do, you either need to fallback to no enxryption, or you need to balkanise email. So far, we've had the former, although I suspect the latter isn't all that far away.

        What Google needs to do is start pushing RFCs for this

        That's sorta what they're doing here - naming and shaming those that do not use the TLS capabilities that have existed for many years...

        Vic.

        1. Doctor Syntax Silver badge

          Re: Yeah, right.

          " It needs to be baked into the mail protocols so that encryption is the default. It would need to be phased in in a backwards compatible manner

          You've already got that. SMTP aleady supports the STARTTLS verb"

          But that's only encryption in transit. AIUI what Eugene was looking for was PGP to encrypt the message end-to-end so it would only be readable by its intended recipient. And, of course, there would also be the possibility of signing it to verify the sender.

          The impediments to this are (a) if your correspondents aren't set up to use it there's no point setting it up for yourself so almost nobody uses it and (b) as Pascal says, it needs an infrastructure for the public keys.

          As I see it the solution for that would be to revise the protocol to build in message encryption rather than making it an add-on. It would need to be rolled out in stages so that in the interim stage new versions of clients would prompt users to set up their key-pair and make use of keys where both ends had them set up but after a given date email to a user who didn't have a key would require specific user approval followed by an end stage where unencrypted email wouldn't be supported.

  2. LDS Silver badge
    Devil

    We're the only one...

    .... who should be able to read and index your emails.

    Truly yours,

    Google.

    PS: otherwise how could we make money selling your data if everyone has them??

    1. Richard Jones 1
      WTF?

      Re: We're the only one...

      Except of course, the account points out that the far end are demanding clear messaging and Google want to advise senders that their message to such far ends will be sent clear because of this far end situation.

      So however much you might like to troll Google do have a fail for this one.

      Mind you while I do not use Google mail, I have never knowingly sent an encrypted message to anyone, I just hope the tooth fairy reads birthday lists and that Santa does the same for Christmas wishes. My rule has been never send anything in an e-mail that would matter if world plus dog, even down to the flees on world and dog read the contents. So no bank details or credit card codes.

      I wonder if said dog likes the pictures of my bathroom refurbishment?

      1. Ken Moorhouse Silver badge

        Re: Bathroom Refurbishment

        Expect lots of adverts for colour coordinated fluffy towels and toiletries in your Inbox.

        There's two sides to this (no, not the bathroom refurb):

        Receiving of emails - gmail would alert you to an unsecured incoming email. Not a lot of choice you have in the matter of receiving it anyway.

        What about the sending of emails? Would gmail alert you to the recipient insisting on downgrading the security of your outgoing communications? If so, it would need to do a preparatory handshake test of the recipient email server to see what is supported, and then give the chance for the sender to think twice about sending the message.

        1. Richard Jones 1
          Go

          Re: Bathroom Refurbishment

          I thought that were two ways this would be exposed to senders and receivers.

          Based on the address the sending client could warn that the country was liable only to accept decrypted mails. The receiver would of course only receive decrypted mails.

          On receipt of a return mail I guess the message would be flagged as have an insecure, non encrypted link protocol.

          I Assume that the address header part 'your_isp.some_country' would be enough for any origin to know if that destination would, or would not accept encrypted communications.

          Alternatively, there were only a small number of countries listed, I guess a blanket warning could easily be generated that XYZ country only accept plain text mails

        2. Vic

          Re: Bathroom Refurbishment

          Would gmail alert you to the recipient insisting on downgrading the security of your outgoing communications? If so, it would need to do a preparatory handshake test of the recipient email server to see what is supported, and then give the chance for the sender to think twice about sending the message

          It would be easier to have a header to say that the mail requires TLS, and then return it as undeliverable if TLS is not available.

          This, of course, only works for the first hop. There is no way to counter a well-behaved first hop forwarding onto a malicious second.

          Vic.

      2. Anonymous Coward
        Anonymous Coward

        SMTP "security" is crap anyway

        * You want to send mail to foo@foo.com

        * You look up the recipient domain in the DNS, and you see foo.com has MX records mail1.bar.com and mail2.bar.com

        * You connect to mail1.bar.com on port 25, cleartext.

        * *IF* mail1.bar.com advertises the STARTTLS option, then you upgrade the connection to TLS. (Of course, if some man-in-the-middle has stripped it out, you fallback to sending in the clear, since you have no other way of knowing whether mail1.bar.com supports TLS or not)

        * You check the server presents a valid certificate for mail1.bar.com

        However there is no certificate binding for foo.com to mail{1,2}.bar.com. So anyone who can spoof the DNS can redirect the mail to anywhere they like.

        1. Ken Moorhouse Silver badge

          Re: SMTP "security" is crap anyway

          Yes, I appreciate my post was over-simplistic and that there was more to it than what I wrote.

      3. LDS Silver badge

        Re: We're the only one...

        SMTP encryption (as designed and implemented till now) it's useless. Most MTAs don't check the certificate, nor check the addresses domains against the certificate of the receiving end. Encryption without authentication is close to useless, it will hinder casual snoopers, won't stop anybody wishing to read your data - as along as it can easily MITM you. Nobody has ever thought SMTP STARTTLS was a sound protection method.

        The only way you have to really protect your email is end-to-end encryption, using keys only your destnation knows - S/MIME, PGP, whatever - just it would also block Google from reading your emails - but I'm sure Google will soon offer to store your S/MIME and PGP keys in your Google profile, to improve your user experience and allow you to easily send and receive encrypted mail from any Google service - and allow Google to keep on putting its nose in your stuff.

        Google and C. should ask for a revised RFC for SMTP, nor act like a gorilla just because they're big and ugly.

        1. Vic

          Re: We're the only one...

          SMTP encryption (as designed and implemented till now) it's useless

          It is not. It might be far from perfect, but OE is still better than cleartext.

          Most MTAs don't check the certificate, nor check the addresses domains against the certificate of the receiving end

          I can't vouch for all MTAs, but it is usual for that to be a configurable option. It is rarely used because few MTAs are set up for such checks to succeed. Iff we get to the point where the majority do, then such checks will be turned on. Until then, certificate enforcement[1] is really only going to leave you with an inability to send email.

          Vic.

          [1] Certificate checking is commonplace - my server does it on every STARTTLS. But most verifications fail.

          1. LDS Silver badge

            Re: We're the only one...

            It's not enough to check if a certificate is valid. You should ensure the certificate is the right one for the domain of the recipients. The problem is, as another commented pointed out, many MX records redirect to a different servers which hosts the mailboxes - often in its own different domain.

            For example if I look for the MX records of a colleagues of mine domain, it redirects to Google servers. Which certificates should they present me when my server calls STARTTLS? It doesn't know yet which recipients I'm about to send to, and thereby which domain(s).

            The way SMTP is designed today it could only work if an MX record points to servers for the same domain - an MTA could check if recipient somebody@foo.com will be really delivered to a server using a foo.com certificate, after it obtained the server certificate.

            But if I'm sending to foo.com, ask the MX record and get aspmx.1.google.com, EHLO/STARTTLS it and the server answer with a valid certificate for aspmx.1.google.com, what the the MTA should do? And what if the DNS is poisoned (or the channel MITM) and it answers with eve.com, with a valid certificate?

            Yes, you get some encryption which may be often better than nothing, but it's not so difficult to nake useless with a simple MITM attack. And your email will still be in cleartext on the server, with no protection.

            1. Vic

              Re: We're the only one...

              It's not enough to check if a certificate is valid. You should ensure the certificate is the right one for the domain of the recipients

              Yes. That's what's meant by "verifying" the certificate. MTAs are trivially configurable to do such verification - but as yet, there aren't enough with appropriate certificates in place for that to be worth doing.

              That still doesn't mean that OE is useless, it just means that there is room for improvement - and the code to do it is already in place.

              The problem is, as another commented pointed out, many MX records redirect to a different servers which hosts the mailboxes - often in its own different domain.

              That is the domain owner's decision. That's what "ownership" means. It's also relatively easy to secure that link to the extent of the trust system in SSL by securing the MX record with DNSSEC.

              The way SMTP is designed today it could only work if an MX record points to servers for the same domain - an MTA could check if recipient somebody@foo.com will be really delivered to a server using a foo.com certificate, after it obtained the server certificate.

              And if it's important to you to secure the domain, you do that. If you choose not to do so, there's no grounds for complaint later.

              But if I'm sending to foo.com, ask the MX record and get aspmx.1.google.com, EHLO/STARTTLS it and the server answer with a valid certificate for aspmx.1.google.com, what the the MTA should do?

              Take it. If the domain owner has said he trusts that server, all you need is a verified certificate. If that's not enough security for you - don't trust someone else's server.

              And what if the DNS is poisoned

              If you can poison DNSSEC, you can poison anything, so all talk of security is moot. If you require security - use DNSSEC to obviate the DNS poisoning attacks.

              Yes, you get some encryption which may be often better than nothing

              It is better than nothing. Cleartext is a mistake far bigger than being vulnerable to a few privileged attackers.

              And your email will still be in cleartext on the server, with no protection.

              If your mail is important enough to you that that is a problem, make sure the server is encrypted. If you're using someone else's server, you probably don't care that mush.

              TL;DR: security isn't an all-or-nothing affair; just because you're not protected against every single possible attack, that doesn't mean you shouldn't be proteecting yourself against what you can.

              Vic.

              1. LDS Silver badge

                Re: We're the only one...

                "Take it. If the domain owner has said he trusts that server, all you need is a verified certificate. "

                So you mean in HTTPS if foo.com is a CNAME for bar.com a bar.com certificate is valid for foo.com?

                Moreover, you can't be sure the domain owner trusted that server, how could you know from the MX result alone? Face it, SMTP security is broken, it needs a new RFC.

                1. Vic

                  Re: We're the only one...

                  So you mean in HTTPS if foo.com is a CNAME for bar.com a bar.com certificate is valid for foo.com?

                  No. We're not talking about HTTPS. We're talking about SMTP.

                  Moreover, you can't be sure the domain owner trusted that server, how could you know from the MX result alone?

                  If the MX record for one domain says to use the MTA for another, then you have an explicit, stated trust relationship. If, as a domain owner, you don't trust the domain's MTA, don't use it.

                  Face it, SMTP security is broken

                  It isn't. It just needs more widespread adoption of the security measures in place. At present, hardly any are actually used, yet we still get encryption.

                  it needs a new RFC

                  So go and write one. And get others to adopt it.

                  In the meantime, leave the rest of us to get on with improving things to make the most of what we've got.

                  Vic.

                  1. LDS Silver badge

                    Re: We're the only one...

                    "No. We're not talking about HTTPS. We're talking about SMTP."

                    Exactly. SMTP, unlike HTTPS, has no way to present you the right certificate when you connect. SMTP was designed for a much simpler Internet, and it really needs to be updated.

                    "If the MX record for one domain says to use the MTA for another, then you have an explicit, stated trust relationship"

                    No, you didn't, exactly like a CNAME doesn't imply any trust relationship. It's merely a pointer that a resource is in a given place. The *only* trust comes from the *certificate* itself. A web server can be smart enough to present the correct certificate for a request even if it comes from a CNAME resolution, an SMTP server can't, because STARTTLS happens before the sender can tell what domain is going to send to.

                    But feel free to believe broken security is good just because you get some encryption which is close to useless. Companies like Google are happy with that, they have to ensure proper security doesn't get in their way.

                    1. Vic

                      Re: We're the only one...

                      SMTP, unlike HTTPS, has no way to present you the right certificate when you connect.

                      Yes it does.

                      When you connect to an MTA and go through the TLS procedure, you get the certificate for that MTA. If you get a certificate for a different MTA, something is bogus.

                      No, you didn't, exactly like a CNAME doesn't imply any trust relationship.

                      When you publish a record that claims a given machine will handle your email traffic, that is a trust relationship. You forge the realationship. and you take the rewards and penalties that that implies.

                      A web server can be smart enough to present the correct certificate for a request even if it comes from a CNAME resolution, an SMTP server can't, because STARTTLS happens before the sender can tell what domain is going to send to.

                      An MTA produces its own certificate. The trust relationship is forged in declaring that MX for the domain. And you secure that with DNSSEC...

                      But feel free to believe broken security is good just because you get some encryption which is close to useless.

                      Look, you clearly don't understand some part of this whole technology. My bet at the moment, based on what you've posted so far, is that you think the MX record gives you an IP address. Would that be your opinion? Because it most assuredly isn't so.

                      Vic.

      4. Anonymous Coward
        Anonymous Coward

        Re: We're the only one...

        Except of course, the account points out that the far end are demanding clear messaging and Google want to advise senders that their message to such far ends will be sent clear because of this far end situation.

        So however much you might like to troll Google do have a fail for this one.

        I disagree, the OP was merely (and correctly) pointing out that Google talking about email security is more smoke and mirrors than reality. Let me clarify.

        Why do we want email security? Because we want EVERYONE (not just any evil government agency, but EVERYONE) to keep their fingers out of our private life.

        What is the very first thing that happens when email lands at Google, via encrypted means or not?

        It gets read by Google. There are two problems with that:

        1 - despite all the frantic flag waving post Safe Harbor, the fact remains that Google is a US company which can give you at best a vague idea where your data resides. It is thus subject to US "please come and get it if you can make a profit of it" laws which have more or less abandoned the rights as once envisaged by their own Fourth Amendment, let alone our still more or less functioning EU derivatives of the Universal Declaration of Human Rights no 13.

        2 - YOU may have agreed to Google's terms, but *I* have not, and neither have any of the other people that send you email. Google scans your inbox, which will include people not using Gmail - it does so without a SHRED of permission of the senders, but Google uses you to scrape data off your correspondents. You may find it interesting in this context to know that only Google gives itself the right to hang on to that data forever, even Facebook does not do that. Google have taken great care to remove the word "perpetuity" from later versions of their Terms of Service, but the net effect of what you agree to still amounts to the same: you have agreed to have a spotty nerd from Silicon Valley peek over your shoulder and keep whatever he finds, forever.

        So, back to the original topic: Google talking about email security is cute, but it does not make them safer. As a matter of fact, if you're an EU company using Gmail or one of the various groups in UK government that have unwisely switched to Google (Cabinet Office and, unbelievably, part of HMRC) you may actually be breaking Data Protection laws now that US protections as prescribed by Safe Harbor are no longer considered "adequate".

      5. Vic

        Re: We're the only one...

        I have never knowingly sent an encrypted message to anyone

        Knowingly or not, it's almost certain that you will have sent one.

        I discovered email encryption when looking through the logs on my mail server. It was using encryption because that was the default. I saw all the "verify=FAIL" messages, and had a quick panic; a bit of reading reassured me as to why this is (currently) quite normal.

        Vic.

  3. AnoniMouse

    A whiff of hypocrisy?

    And presumbly Google also wants to warn users about the impact on their privacy of accessing Web Sites which, even though acceessed via HTTPS, are riddled with DoubleClick GoogleAnalytics and other Google SpyWare?

    1. Doctor_Wibble

      Re: A whiff of hypocrisy?

      Have an upvote for that, I started blocking those after the first time that I saw them (as 'waiting for...', when else?) on an actual 'credit card number' page when buying something (having already spotted them on the order summary) and that was when I decided they could fck the fck off.

    2. allthecoolshortnamesweretaken Silver badge

      Re: A whiff of hypocrisy?

      Or a whiff of Eau de Rat, possibly. There might bee something good in this or coming from this, far too many people still have no clue whatsoever about anything related to encryption or online security (or should that be safety?) and so on. If this makes at least a few people think it will be a good thing.

      However, I can't help it, this feels a bit like McDonalds partnering with Weight Watchers - oh, wait...

      1. LDS Silver badge

        Re: A whiff of hypocrisy?

        I'm afraid it could shift the perception from true forward secrecy to just "encrypt the comm channel". While encrypting (properly - authenticating also!) the channel is part of the solution, it's not the solution.

        But companies like Google may fear that people asking for perfect forward secrecy may impact their business, so in these times when everybody asks for "encyption", they need to shift that need to something that doesn't impact them. So make them believe some "encryption" makes them secure, but avoid to give them what they really need.

        After all, do you feel safe to send your credit card number to a site just because it uses "HTTPS"? Or you should be also worried about where and how that number is stored, and for how long? Just encypting the channel may be good for very transient and short-lived data which aren't stored and/or have no value after a short time. For the other data, channel encryption is just a little part of a true solution.

  4. auburnman

    How to make users care about encryption

    Google should leverage their strengths to make people want encryption; all they'd have to do is insert ads in -BUY A RADIATION KING BRAND TV TODAY!- cleartext emails and some clever apple BUY THE NEW APPLE IMAC TODAY! would come up with a solution.

  5. Marclonus

    3e3a24a4a799dcb3c9f0b30f1fc7d8cd !!

    b9b0f94abfa23421f7f473c67cff62b5571c689f0d949e4c61468fa9ba1aaa8aecd43304b7941620b81dee4768dd40be762f6d93402140aa170669343773384f :-)))

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019