Forgot your password?
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 PlusFiveTroll (754249) on Monday December 17, 2012 @08:44PM (#42320327) Homepage

    Will it work with STARTSSL free personal certs? []

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

  • by msauve (701917) on Monday December 17, 2012 @09: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 js33 (1077193) on Monday December 17, 2012 @09:29PM (#42320815)

    A cert from BigNameInternetCompany costs next to nothing

    In fact it costs nothing from StartSSL [], 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 [].

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

  • No, it's perfectly reasonable to run your own CA, as an individual or an organization, distribute your CA cert to those using the service, and go merrily on your encrypted and authenticated way.

    For $30 per year to get a real cert (or even less, a little googling will quickly product things like 80% off at GoDaddy etc), your time has to be of quite a low value if it's easier/cheaper to run your own CA and distribute certificates (unless, of course, you're doing it all for the fun of it)

    Where self-signed certs are no good is when you need to access your SSL protected service from someone else's machine, or a machine you've not used to access the service from before, and you have to take it on blind faith (or remember a long and complicated fingerprint) that the cert you're getting is the correct one.

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

    by dch24 (904899) on Monday December 17, 2012 @11: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 @11: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, [], version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
    Dec 17 21:33:38 mailserver sm-mta[13455]: AUTH=server, [], 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,, proto=ESMTP, daemon=MTA, []

% APL is a natural extension of assembler language programming; ...and is best for educational purposes. -- A. Perlis