Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Google Security Technology

Gmail Drops Support for Connecting To Pop3 Servers With Self -Signed Certs 299

Posted by Unknown Lamer
from the security-through-redefinition dept.
DECula writes "In a move not communicated to its users beforehand, Google's Gmail servers were reconfigured to not connect to remote pop3 servers that have self-signed certificates, leaving folks with unencrypted connections, or no service when getting email from other services. Not good for the small folks. One suggestion was to allow placing the public keys on Google's side in the user configuration. That would be a heck of a lot better than just dropping users into never never land." Apparently, "valid" now means "paid someone Google approves to sign the certificate." It's not like commercial CAs have the best security track record either.
This discussion has been archived. No new comments can be posted.

Gmail Drops Support for Connecting To Pop3 Servers With Self -Signed Certs

Comments Filter:
  • by Frosty Piss (770223) * on Monday December 17, 2012 @07:30PM (#42320181)

    In a move not communicated to its users before hand

    In a move not communicated to you. I have a Google Apps account and received an email about this a few weeks ago.

    Not good for the small folks.

    A cert from BigNameInternetCompany costs next to nothing (although it might just be worth that much as well).

    My guess is that this is mostly driven by the desire to minimize SPAM email servers using the Google network to abuse their victims.

    One suggestion was to allow placing the public keys on Google's side in the user configuration. That would be a heck of a lot better than just dropping users into never never land.

    Again, a cert that is acceptable to Google is so dirt cheap as to be inconsequential to anyone running a server that needs one. So, the only reason can be that those that object are the crusty RMS types â" everything must be free. Google is more concerned with the health of their network, not random non-paying non-customerâ(TM)s not really needy needs.

    I know that sounds harsh, but Google is not a social services agency.

    • by IBitOBear (410965) on Monday December 17, 2012 @07:38PM (#42320253) Homepage Journal

      This cut at free flow of information, and this alligation that the cost is trivial in the parent poster's post, suggests that if it were such a nothing then google should offer a means to comply wihtout forcing people to go out and pay a third party.

      If it's so cheap and such a nothing, then what's the problem wiht them providing what is needed to interract with their own service?

      • by Threni (635302) on Monday December 17, 2012 @07:41PM (#42320287)

        Google can do what they want. This move improves security. Sometimes you have to force people to wake up so that they move their feet out of the fire.

        • by Taco Cowboy (5327) on Monday December 17, 2012 @07:54PM (#42320453) Journal

          Google can do what they want.

          Sure, Google can always do what they want, but please tell us, the noname folks, whether or not we can download our email from our Gmail account, to our own computer, using POP3 protocol?
           
          Thank you and to anyone who can provide us, the noname folks, the critically needed information !!
           

          • by ThatFunkyMunki (908716) <thatfunkymunkiNO@SPAMgmail.com> on Monday December 17, 2012 @08:17PM (#42320707)
            Yes, you can. The only issue is that when you are using the gmail interface to download mail from an external POP3 server, if you want the connection to be encrypted, your SSL certificate cannot be self-signed. This does not affect anything to do with using regular gmail with a regular POP3 client.
            • by hierofalcon (1233282) on Monday December 17, 2012 @11:48PM (#42322043)

              Yes, actually it does. Our company was getting along nicely with a self-signed cert which we added to all the company devices as a trusted source. One enterprising engineer was using gmail. When they dropped the change on us, he could no longer use gmail and in the spirit of letting VIPs get away with anything they want mostly, we were forced to buy real certs. I'm not against real certs - especially for a company - but you can't just use plain socket access because our server broadcasts STARTTLS as an option for security in credentials - as it should, which google immediately tries to use and rejects due to the self signed cert. I'm sure we could force off the STARTTLS option, but that is actually used as a feature by some of our locations, so it isn't that simple.

          • by PhunkySchtuff (208108) <kaiNO@SPAMautomatica.com.au> on Monday December 17, 2012 @08:18PM (#42320709) Homepage

            From my reading of the linked article, this has nothing whatsoever to do with fetching your email from Google over POP3 (or POP3S)

            What this affects is if you are running a mailserver that uses a self-signed certificate, or if you're using another email account on a mailserver that uses a self-signed certificate, then you can no longer tell your gmail account to pull the email in from your second account over POP3S, as it can't verify the certificate.

            You can still have gmail pull in your POP email via the non-secure protocol, or have the mail server administrator pay the $30 or so a year it costs to get a valid certificate signed by a recognissed CA.

            You can still fetch your gmail via POP, using SSL or not, although why anyone would want to use POP if they're given any other option (such as IMAP) is beyond me.

        • So why can't they move their feet out of the fire by verifying the public key themselves and uploading it into their own Gmail account?

          No registrar can beat the verification of me pasting the public key from my own server and verifying the fingerprint out-of-band.

        • by icebike (68054) on Monday December 17, 2012 @08:18PM (#42320711)

          This move improves security.

          How does it do that?

          This change only affects those people who configure Gmail to pop mail off of small company (or personal) Linux box which has a self signed certs so that the traffic is encrypted. It then puts this mail in your Gmail inbox. I fail to see any big security hole here. Who is going to run super secret mail on a self signed certificate?

          The work around is to have the Linux box forward a copy to Gmail. At least they would then be using Googl's cert. I'm not seeing this as that much better for over all security.

          • by Albanach (527650) on Monday December 17, 2012 @10:22PM (#42321639) Homepage

            How does it do that?

            Presumably if you trust self-signed certificates, anyone can launch a MITM attack against your server with a self-signed certificate. Google would trust the self-signed certificate as being your own and then relinquish your login credentials when it attempts to retrieve the mail.

            Now the MITM has to at least get a certificate from a trusted source that will have to, at a minimum, perform some sort of domain validation.

            The increase in security may not be huge, but there's certainly some gain in security from this, and well worth the few dollars that a domain authenticated certificate costs.

            • by Shagg (99693) on Tuesday December 18, 2012 @01:29PM (#42328005)

              Presumably if you trust self-signed certificates, anyone can launch a MITM attack against your server with a self-signed certificate. Google would trust the self-signed certificate as being your own and then relinquish your login credentials when it attempts to retrieve the mail.

              But why does Google care? If someone wants to run their own server that could be open to a MITM attack, that's their decision. It's not a good idea, but it's got nothing to do with Google and doesn't effect the security of Google's service at all.

        • by msauve (701917) on Monday December 17, 2012 @08:25PM (#42320775)
          "This move improves security."

          No, it doesn't. According to Google:

          you can disable using SSL in Gmail by unchecking 'Always use a secure connection (SSL) when retrieving mail on the Accounts and Import tab in your Mail settings. However, this means that your password and email will not be protected while sent over the Internet, so we don't recommend disabling this.

          so, instead of using SSL for it's encryption capabilities (Google is now forcing authentication as a bundle), some users will have to leave the connection wide open. Now, I realize that self-signed certs still leave an opportunity for MITM attacks, but something is better than nothing. Google could have cached self signed certs, and notified the user if they changed, which would have at least made MITM interception apparent. They could have made this level of SSL authentication configurable. They could allow users to upload a private CA cert, or the public side of an SS cert. But they didn't. They just changed to "all or nothing," which will push many users to "nothing."

          That in no way improves security.

          • by blueg3 (192743) on Monday December 17, 2012 @09:59PM (#42321493)

            instead of using SSL for it's encryption capabilities (Google is now forcing authentication as a bundle)

            Because an encrypted communication using only an IP address for authentication is no encryption at all. Any attacker reasonably capable of intercepting your communications to read them is also capable of undetectably executing a man-in-the-middle attack on the SSL connection.

            This increases security because it encourages people who actually want encrypted POP connections to use an approach that actually provides that rather than using an approach that appears to provide it but doesn't.

            It would be nice to have the ability to upload the signer's cert and use that for verification, though. That enables secure use of self-signed certificates.

        • by X.25 (255792) on Monday December 17, 2012 @10:34PM (#42321721)

          Google can do what they want. This move improves security. Sometimes you have to force people to wake up so that they move their feet out of the fire.

          Haha.

          Ok, how does this improve security, pretty please?

      • by spcebar (2786203) on Monday December 17, 2012 @07:42PM (#42320303) Homepage
        Agreed. The problem is not the levity of the price, but the existence of the price itself.
        • Agreed. The problem is not the levity of the price, but the existence of the price itself.

          Right, because everything should be free as in beer right? Even if it costs someone else something to provide it to you, it shouldn't cost you a thing, right?

          A lot of geeks here need to start to realize that all that stuff Out There(tm) isn't produced for free, and won't be free as in beer to you forever. Don't like what Google did? Use another solution or roll your own. *That* is freedom.

          • by spcebar (2786203) on Monday December 17, 2012 @10:57PM (#42321833) Homepage
            I don't think anyone's arguing that you should have to pay for a service that costs money to provide- I think we're just miffed that a service that worked and was free has been altered so that it can be no longer. I think anyone would be willing to pay for a service that costs money to provide (and a lot of us geeks do, i.e, linux is free but support costs money), but when it comes down to it, A. Google isn't exactly strapped for cash, and B. As IBitOBear suggested, the cost is trivial, and Google really ought to offer an alternative means to comply without paying a third party. But that's just my two cents, take it or leave it.
      • by PlusFiveTroll (754249) on Monday December 17, 2012 @07:44PM (#42320327) Homepage

        Will it work with STARTSSL free personal certs?

        http://www.startssl.com/?app=1 [startssl.com]

        • by morcego (260031) on Monday December 17, 2012 @07:55PM (#42320463)

          Will it work with STARTSSL free personal certs?

          http://www.startssl.com/?app=1 [startssl.com]

          If they offer a valid certificate chain, it should.

          • by ls671 (1122017) on Monday December 17, 2012 @10:23PM (#42321647) Homepage

            I use STARTTLS so Google servers can use my SMTP server with authentication to relay mail I send from gmail. The idea is that I can post from gmail using my real email address and not my gmail address. Trying to relay mail with my real address directly from gmail servers would cause problems with SPF (Sender Policy Framework). It that case, gmail puts your real address in the Reply-To field and puts your gmail address in the From field so it is obvious for people receiving my emails that I posted from gmail.

            I do not have gmail servers popping mail from any of my servers so I haven't tested it.

            After testing a few minutes ago, I can tell you although that gmail still works with my self-signed certificate when it connects to my SMTP server to relay mail. So, having gmail relay mail through your SMTP server still works with a self-signed cert. In order to enable this functionality, you have to provide gmail with a user name and password to connect to your SMTP server.

            Dec 17 21:33:38 mailserver sm-mta[13455]: STARTTLS=server, relay=mail-qc0-f171.google.com [209.85.216.171], version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
            Dec 17 21:33:38 mailserver sm-mta[13455]: AUTH=server, relay=mail-qc0-f171.google.com [209.85.216.171], authid=XXX@XXXX, mech=PLAIN, bits=0
            Dec 17 21:33:39 mailserver sm-mta[13455]: qBI2XaZT013455: from=XXXX@XXXX, size=2286, class=0, nrcpts=1, msgid=CAHEH8eWJ121WWK9o87V8SSttDhRHTHZa2NgiygugupZ0ROd3gQ@mail.gmail.com, proto=ESMTP, daemon=MTA, relay=mail-qc0-f171.google.com [209.85.216.171]

        • by IVI4573R (614125) on Monday December 17, 2012 @08:30PM (#42320821)
          Yes. My dovecot server is configured with a Class 1 from STARTSSL and Gmail is happy with it. You just have to remember to use the "Server Certificate Bundle with CRLs" provided by STARTSSL in the ssl_ca option so that the chain to CA is complete.
      • by hobarrera (2008506) on Monday December 17, 2012 @08:05PM (#42320595) Homepage

        You're right, they're not cheap. Actually they're free [startssl.com].

      • The paying to get a SSL certificate only affects people running a mail server, not people using a mail server.
        If you're running a mail server, you should really get a recognised SSL certificate if you want to offer SSL protected services, otherwise you're only getting half the benefit of SSL connections - you get encryption but not authentication.

        From my reading of the linked article, this has nothing whatsoever to do with fetching your email from Google over POP3 (or POP3S)

        What this affects is if you are running a mailserver that uses a self-signed certificate, or if you're using another email account on a mailserver that uses a self-signed certificate, then you can no longer tell your gmail account to pull the email in from your second account over POP3S, as it can't verify the certificate.

        You can still have gmail pull in your POP email via the non-secure protocol, or have the mail server administrator pay the $30 or so a year it costs to get a valid certificate signed by a recognissed CA.

        You can still fetch your gmail via POP, using SSL or not, although why anyone would want to use POP if they're given any other option (such as IMAP) is beyond me.

      • alligation

        Is that like an allegation that hides beneath the surface of the river, biding its time?

      • by syntax (2932) on Monday December 17, 2012 @11:30PM (#42321961) Homepage

        First they have the gaul to ask us to purchase a domain name, and now this?

    • by morcego (260031) on Monday December 17, 2012 @07:50PM (#42320407)

      My guess is that this is mostly driven by the desire to minimize SPAM email servers using the Google network to abuse their victims.

      Ok, hold on a moment. What does POP3 access over SSL has to do with spam ?

    • by js33 (1077193) on Monday December 17, 2012 @08:29PM (#42320815)

      A cert from BigNameInternetCompany costs next to nothing

      In fact it costs nothing from StartSSL [startssl.com], like several commenters have pointed out, but people forget that the commercial x.509 PKI is for convenience, not security.

      A self-signed cert is highly secure as long as you can verify through independent means that it is in fact the same cert installed on your server, and as long as the private key has not been compromised. In fact this is really the only way you can really get this level of security from even a commercial cert --- to verify independently that it is in fact the cert you think it is, and you have not been subject to a man-in-the-middle-attack [pcworld.com].

      It's not as though Google previously made any effort to verify the authenticity of those self-signed certs, or if accepting those self-signed certs as they did before would give their users anything but a false sense of security. Surely it is not a money issue for the "small guy". Commercial certs can be had, if not free from the one provider I already mentioned, for a very minimal price from many different providers, on the order of what the "small guy" is already paying for his domain registration. Why is it that the "small guy" always seems to choose the most expensive, heavily advertised vendors of some service or product and then proceed to complain about the price?

      I have to agree (mostly) with Frosty here. No, the mainstream commercial PKI is not the most highly secure thing in the world, but you're trying to authenticate your server to a big commercial company---you need a commercial cert. And if you're trusting such a big commercial company as Google, then you may as well trust the whole commercial PKI, because you're extending your trust far and wide in either case, which there is nothing wrong with, as long as you be mindful of what you are entrusting to the "big boys."

    • by Shavano (2541114) on Monday December 17, 2012 @08:50PM (#42321001)

      Again, a cert that is acceptable to Google is so dirt cheap as to be inconsequential to anyone running a server that needs one. ... Google is more concerned with the health of their network, not random non-paying non-customers not really needy needs.

      I know that sounds harsh, but Google is not a social services agency.

      No, they aren't , but if they want people to us their services they will need to make their services suit their users' needs and wants.

      And nothing is more secure than a self-signed cert distributed out-of-channel.

      • by BitZtream (692029) on Monday December 17, 2012 @11:30PM (#42321963)

        Very true ... so all 8 people that use the gmail interface to check OTHER pop3 servers are possibly going to notice it. The 4 people who run their own mail servers and are too cheap to get a CA cert are just SOL.

        Obviously I exaggerate, but really, the number of people this effects is statistically irrelevant to Google.

    • by X.25 (255792) on Monday December 17, 2012 @10:32PM (#42321705)

      Again, a cert that is acceptable to Google is so dirt cheap as to be inconsequential to anyone running a server that needs one. So, the only reason can be that those that object are the crusty RMS types Ã" everything must be free. Google is more concerned with the health of their network, not random non-paying non-customerÃ(TM)s not really needy needs.

      Please, explain us how self-signed certs impact the health of their network.

      All ears.

  • by Rich0 (548339) on Monday December 17, 2012 @07:36PM (#42320227) Homepage

    I know this will get 400 replies about how self-signed certificates don't provide complete security.

    I'd buy that argument if Google configured their servers to only accept connections over SSL with trusted certificates, and then refused to connect at all otherwise.

    However, they're still allowing unencrypted connections as well. There isn't a single attack you can mount on an SSL connection with a self-signed certificate that you can't also mount on an unencrypted connection.

    Trusted vs untrusted SSL is a false dichotomy - it neglects the most commonly used option of not using SSL at all, which is completely insecure.

    • by DragonWriter (970822) on Monday December 17, 2012 @07:59PM (#42320501)

      I know this will get 400 replies about how self-signed certificates don't provide complete security. I'd buy that argument if Google configured their servers to only accept connections over SSL with trusted certificates, and then refused to connect at all otherwise. However, they're still allowing unencrypted connections as well.

      Self-signed certs don't provide any security advantage in the Gmail use case over no SSL, and SSL takes processing power on both ends (self-signed certs can be useful in security if both endpoints of prior shared knowledge of each other); so it is literally costing Google money to provide you with nothing at all (except perhaps a false sense of security), so it makes sense that Google would discontinue spending money to deceive you with security theater.

      Admittedly, there are ways that the POP-over-SSL support in Gmail could be changed to actually be useful in the case of self-signed certs (allowing self-signed certs only if the user has provided the corresponding public key through an authenticated connection to the Web UI, for instance), and one might argue that that would be better. OTOH, its quite likely that the cost of making changes to support that wouldn't be justified by the number of people that would benefit.

      But its better -- for Google and users -- for Google not support self-signed certs than to support them in a way which provides illusory security, which is what Google was doing before it discontinued support for them.

      • You are wrong. (Score:5, Insightful)

        by Kludge (13653) on Monday December 17, 2012 @08:30PM (#42320833)

        But its better -- for Google and users -- for Google not support self-signed certs than to support them in a way which provides illusory security, which is what Google was doing before it discontinued support for them.

        That is wrong. Here is the hierarchy.
        1. No security (OK)
        2. Encryption (Better)
        3. Encryption and Authentication (Best)
        Saying that 1 is better than 2 is wrong. After Google connects to a server just once and stores the key, all subsequent connections can be encrypted and verified that they are made to the same server. This fear of encryption without authentication is very ignorant.

        • by jamesh (87723) on Monday December 17, 2012 @08:59PM (#42321077)

          But its better -- for Google and users -- for Google not support self-signed certs than to support them in a way which provides illusory security, which is what Google was doing before it discontinued support for them.

          That is wrong. Here is the hierarchy.
          1. No security (OK)
          2. Encryption (Better)
          3. Encryption and Authentication (Best)
          Saying that 1 is better than 2 is wrong. After Google connects to a server just once and stores the key, all subsequent connections can be encrypted and verified that they are made to the same server. This fear of encryption without authentication is very ignorant.

          Disagree. Encryption doesn't matter if the encryption is to the enemy. Anyone in a position to snoop on the traffic is in a position to redirect the traffic to themselves and provide their own self-signed cert in place of yours (give me an example of where this isn't true - there might be some but there won't be many!). From a security point of view, 1 and 2 are equal, but then SSL is extra overhead and a false sense of security, so 1 is better.

          • Re:You are wrong. (Score:5, Interesting)

            by dch24 (904899) on Monday December 17, 2012 @10:17PM (#42321601) Journal
            Examples of snooping that lack the ability to do a MITM attack:

            1. Listening to an encrypted wifi session, then breaking the encryption offline

            2. Tapping into undersea fiber (the listening party is going to have a hard enough time exfiltrating the snooped bytes; setting up a "take over" command and associated equipment is prohibitive due to both the technical and political risks)

            3. Listening device inside a government facility. China famously does this for example by using a small office-supply firm to get equipment into a US facility somewhere is Asia; the copy machine has a hard drive like any copy machine and there's nothing suspicious about that, right? And then you find the second, and the third, and the fourth hard drive hidden in places you would never look. The data is exfiltrated only when the machine is replaced as part of a regular service contract.
            Need I go on?
          • by ls671 (1122017) on Monday December 17, 2012 @10:57PM (#42321835) Homepage

            Well, no. Self signed certs protect you from somebody simply sniffing the wire. Hijacking the traffic to redirect it to another host requires more effort...

            http://slashdot.org/comments.pl?sid=3322605&cid=42321807 [slashdot.org]

      • by WaffleMonster (969671) on Monday December 17, 2012 @08:33PM (#42320859)

        Self-signed certs don't provide any security advantage in the Gmail use case over no SSL

        There is an important difference in the use of SSL provides protection against passive easedropping where an attacker may only be able to listen to but not alter the contents of transmitted data.

      • by ls671 (1122017) on Monday December 17, 2012 @10:52PM (#42321807) Homepage

        Untrue, you can still authenticate when using a self signed cert with username and password. The benefit of using a self signed cert is that someone sniffing the wire won't be able to read the data or steal your authentication credentials.

        http://slashdot.org/comments.pl?sid=3322605&cid=42321777 [slashdot.org]

    • by Burning1 (204959) on Monday December 17, 2012 @08:04PM (#42320577) Homepage

      This misses the point that trusting self signed certificates significantly reduces the security of CA signed certificates.

      In order to protect against Man in the Middle and other identity based attacks, Google needs a way of certifying that the remote machine is who they say they are. If the service trusts an self-signed certificate, there's nothing preventing a 3rd party from performing a MITM attack by intercepting your traffic and re-signing it with their own key. The only workaround would be to use a known_hosts based system, similar to SSH. This however increases the costs of administration, and still provides avenues of attack.

      I generally agree with Google's move. I think it's a bad thing to compromise the security of CA certs in order to support self-signed certs.

    • by X.25 (255792) on Monday December 17, 2012 @10:37PM (#42321747)

      I know this will get 400 replies about how self-signed certificates don't provide complete security.

      Self-signed certs are much more secure than 'commercial' certs.

      Anyone telling you anything different is simply lying and/or doesn't know what he's talking about.

  • by Vekseid (1528215) on Monday December 17, 2012 @07:40PM (#42320275) Homepage

    That means you have to control at least one IP address.

    It's also really hard to send e-mail without at least one domain of your own.

    Reseller pricing of low-end certificates is about the same cost as a domain. From Namecheap and elsewhere.

    That said, I didn't know about this, and forgot to set up SSL at one of my domains. I didn't much care, but my reaction to this is pretty much "Oh, so that's what Google is bitching about. Okay."

    This is much ado about rather little.

  • by Nyder (754090) on Monday December 17, 2012 @08:01PM (#42320521) Journal

    You get what you pay for.

  • by vanyel (28049) * on Monday December 17, 2012 @08:01PM (#42320529) Journal

    Free, trusted, certificates from https://www.startssl.com/ [startssl.com] - no excuse at all for using self signed, at least until DANE/TLSA [ietf.org] is deployed.

  • by hobarrera (2008506) on Monday December 17, 2012 @08:02PM (#42320549) Homepage

    Why would I have to pay?
    I could just get a free cert from StartSSL, which is trusted by most mayor OS, browsers, and mobile devices.
    It's also trusted by chrome on *nix (in windows it uses the OS certificates - which include StartSSL).

  • by rudy_wayne (414635) on Monday December 17, 2012 @08:14PM (#42320685)

    Gmail servers were reconfigured to not connect to remote pop3 servers that have self-signed certificates, leaving folks with unencrypted connections, or no service when getting email from other services.

    Sorry for the ignorance, but I don't understand this. Why would I be getting email from a "remote POP3 server" or "other service"? Why wouldn't I just have my email client connect directly to Gmail's POP3 server?

    pop.gmail.com port 995 using SSL. I'm using Thunderbird and it works fine.

  • by AaronLS (1804210) on Monday December 17, 2012 @08:34PM (#42320865)

    I like self-signed certs because they are away to leverage SSL support for encrypted connections, but they are vulnerable to man-in-the-middle attacks. Hence the suggested workaround of providing the public key in the Google account so that Google can prevent man-in-the-middle attacks. IMO that is a reasonable suggestion, but many tools for creating self signed certs don't give you an easy way to separate the public key without opening the file and being knowledgeable of it's format. It would be a feature used by probably a tiny percentage of users, and be a point of what-the-heck-is-that-option for the rest. The lack of user understanding would also be a vulnerability, where people might be duped into providing a different public key with malicious origins.

    This has nothing to do with the inflammatory "valid" vs. "paid" statement. There are CAs that provide free certificates, and thus are not vulnerable to man-in-middle-attacks because of the verifiable chain. So they are indeed valid in a sense that there is the trust chain, yet not paid, making the summary's inflammatory statement INVALID. No one is trying to claim self signed certs are invalid, they just leave users vulnerable.

    The last statement about CA's being compromised is somewhat irrelevant to the subject at hand. They seem to be trying to make the point of Google unfairly favoring CA signed certs over self signed certs. So they either feel that Google should also do away with CA signed cert support, or not do away with self signed certs on the basis that CA signed certs are no more secure(as a result of CA's being compromised). I will address both of these possibilities.

    1) Doing away with self signed certs prevents vulnerabilities that most users are probably unaware exist. Thus avoiding more shenanigans like Chinese activists getting arrested when the government snoops their communications using man-in-the-middle attacks. So this is definitely a step in the right direction(although perhaps alternatively could have supported providing public keys out of channel as summary suggests).

    2) Doing away with support for CA signed certs to close the potential vulnerability of relatively rare forged certs? That's like throwing the baby out with the bath water. The system in place significantly improves security for the vast majority of connections. It allows certs to be revoked when found to be forged, and provides a secure connection that cannot be snooped(with the exception of the tiny fraction of invalid certs, which that get revoked anyhow). Self signed certs cannot offer either of these features transparently(without requiring users to setup public keys).

    Self-signed certs can be "forged" in the sense that a man-in-the-middle can present a completely different cert. as the original, and there is no third party verification that would allow that cert to be revoked. Even if it were revoked("hey bob, just calling to tell you to look at the cert on that connection when you get your email and if the key read f0a135... then disconnect" I kid, I kid), the malicious snooper would just create a new self-signed cert for another man-in-the-middle the next time a connection is initiated. For those same reasons, connections made with self-signed certs have very little guarantee of security.

    Usually I'm not concerned about man-in-the-middle attacks, since if someone has gained that level of access to the network I'm connecting over, then things are looking bad already. In places like China though, where the people who control the network are the people who want to snoop on you, it is a ever present danger.

    If there were more user friendly systems in place for managing/retrieving public keys, then self signed certs would be great. Even when I know a cert. is valid, some make it very hard to permanently add the public key as trusted, and thus prompt me with an extra step every time I restart my browser and try to access a page using one.

    • by Skapare (16644) on Monday December 17, 2012 @09:41PM (#42321371) Homepage

      There are two ways to verify a client that is connecting with some private key. The more commonly known method involves the client providing its signed public key, and verifying the signature (a use of the signer's private key) against its known and trusted public key. Then it is assumed if the trusted signer signed this user public key, then the signer trusted the user, and so the server can trust the user as well. The less commonly known method involves the server having a copy of the user public key, and keeping that copy in the context of users it trusts. Signatures are not involved. The server simply checks if the two keys it has are corresponding pairs.

      There are two examples of the latter method being used. The lesser well known is "mode 3" verification in the "stunnel" program. The more well known is the "authorized_keys" list per user in "ssh".

      The first method is more appropriate for web access where it is not practical for each user to keep a list of trusted web sites given the vast numbers user may access. But it is possible to do that. You do that by accepting the site key the first time you visit. Future visits verify keys using the stored public key that was previously trusted.

      The second method is actually more appropriate for services where all users must be trusted enough to connect, such as ssh. The server needs to trust the client (but trust the other way is good, too). However, the second method should already have been in use for services like POP3 and IMAP.

      The second method is done simply by providing you own public key through a channel which the server can verify the user by another means (login by password over HTTPS for example), and keep that public key as part of the user credentials. It, like a password, can also be changed at any time. Signed certificates are not needed. Signatures are not involved.

      • by AaronLS (1804210) on Monday December 17, 2012 @10:07PM (#42321549)

        SSH comes to mind quite often when thinking about these kinds of things. In most places, users see prompts about accepting a public key so often that it becomes second nature. No one goes to the IT admin and is like "Hey, did something change on the server that would cause me to see this message today, or is someone intercepting my connection and providing their own public key?". Maybe not in that wording, but the point being, even savvy users in a computer science department generally ignore these messages and happily accept the key even when they've connected to the server before.

    • by Anonymous Coward on Monday December 17, 2012 @11:10PM (#42321873)

      Usually I'm not concerned about man-in-the-middle attacks, since if someone has gained that level of access to the network I'm connecting over, then things are looking bad already.

      No, things aren't looking bad, things are looking normal.

      I trust my local network, and I trust the destination network, but a simple traceroute will show that my packets have to traverse 6 to 8 other networks that belong to other people to get to their destination. Do I trust the owners of those networks not to be malicious? Do I trust that the owners of those networks have properly secured themselves from attackers?

      With working, signed SSL, it doesn't matter if the bad guys are sniffing, because they'll only get the encrypted traffic. Good luck decrypting it.

      With working, signed SSL, it doesn't matter if the bad guys are redirecting or spoofing traffic, because the connection WILL FAIL validation.

      The whole point of SSL is that you don't need to trust the intermediate networks to have a secure, encrypted, authenticated connection, EVEN IF THE BAD GUYS HAVE COMPLETE CONTROL OF EVERY NETWORK between you and your destination.

      The SSL connection is secure, or will fail with a validation error (unless there is a flaw with SSL, or the CA is compromised, but that is another story).

      And frankly, if your security isn't worth $15/year for a cheap-o SSL certificate (or even less sometimes), then why do you bother?

      Do you have a lock on your front door? I hope it cost more than $15.

  • by Onymous Coward (97719) on Monday December 17, 2012 @08:47PM (#42320973) Homepage

    The Perspectives [perspectives-project.org] notary system could be updated to include mail servers. Then everyone, including organizations like Google, could check notaries to make sure they weren't getting MITM'd.

  • by manu0601 (2221348) on Monday December 17, 2012 @10:32PM (#42321707)

    For the administrator of an enterprise mail server, which offers users the ability to check mail from the outside using POP/SSL or IMAP/SSL, The whole POP/IMAP feature of Gmail is scaring. You insist that your users should not disclose their password to anyone, and some of them see no problem in giving their credentials to Google, a patriot-act constrained third party.

    What can be done here? Block GMail IP range for POP and IMAP? Request a client certificate to be presented?

  • by funkboy (71672) on Monday December 17, 2012 @10:39PM (#42321757) Homepage

    If so then all griping here about the lack of free certificates is for naught...

  • As much as I want to like Google they really slip up sometimes.
    Regardless of whether there is a good reason for the latest change, Google has absolutely no qualms about the way it draws large numbers of people to use what is perceived as public infrastructure (it isn't, but Google search being the ubiquitous, number one engine there is a gray area in perceptions of trustworthiness), then drops it (infrastructure services) like a hot potato if the numbers don't meet their definition of "huge".
    You can't just do something like this and imagine that instantly throwing large numbers of people into confusion, not just about this service but about all Google services, is a morally responsible thing to do. At the very least an email to nonpaying customers as well would have been the right thing to do.
    And regarding the "costs so little it isn't an issue" argument is specious at best. For someone who has no budget available at all, or who uses self-signed certs for minimal security, suddenly being forced to do anything at all is a use of resources, time=money, which they did not have available.
    I am not affected by this move and while I have used gmail I do not depend on it, and I have been burned in the past by changes in Google services.
    So what I'm saying is basically, Google resembles Microsoft. Microsoft does an embrace/extend/extinguish thing where you get drawn in and then can't get out. Google draws you in with sexy services (the bastards! ;) well that is okay) but god forbid you actually use the stuff, you have to live in fear and that fear is what Google now thinks is a good reason to pay for services. My impression is that mainly nonprofits, students and people without money lying around use free services so they are being harmed. Also, whatever a cert costs, it may not be much in U.S. terms but Google is global.

  • Not that many people are talking about it, but Exchange support for GMail is also going away for free customers on Jan 13. That is a huge deal.

    That means no push notification of GMails on the iPhone without using the GMail app.

    Google's strategy is becoming clearer vis-a-vis iOS: replace Apple's native apps with its own. People will be forced to use the GMail app instead of native iOS mail if they want push notifications. Same thing with Maps---people are going to use Google's maps app whenever possible. At least Apple managed to grab a foothold with iMessage. That one won't be replaced by Google soon.

"Well hello there Charlie Brown, you blockhead." -- Lucy Van Pelt

Working...