Gmail Drops Support for Connecting To Pop3 Servers With Self -Signed Certs 299
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.
Since you need FCRDNS to send mail these days (Score:5, Informative)
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.
Self-signed certs have bad cost:benefit for Google (Score:2, Informative)
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.
Re:Google should then provide signed certs (Score:5, Informative)
You're right, they're not cheap. Actually they're free [startssl.com].
Re:Google can do what they want. (Score:5, Informative)
Re:Google can do what they want. (Score:5, Informative)
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.
Re:Please Explain (Score:4, Informative)
Re:Google should then provide signed certs (Score:4, Informative)
Re:Self-signed certs have bad cost:benefit for Goo (Score:5, Informative)
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.
Re:Self-signed certs have bad cost:benefit for Goo (Score:5, Informative)
Sorry, but it isn't. MITM means the man in the middle pretends to be the server when you talk to him, then pretends to be you when the server talks to him. He then stands in the middle, encrypting to you, encrypting to the server, pretending to be both.
Check out this video for the video that finally caused me to "get" it. https://www.youtube.com/watch?v=3QnD2c4Xovk [youtube.com]