Slashdot Mirror
Gmail Drops Support for Connecting To Pop3 Servers With Self -Signed Certs
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.
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.
If you want news from today, you have to come back tomorrow.
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.
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.
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.
It is a big deal for a CA to be compromised, I agree on that. However, to use that to then say signed certs are completely useless is not just an exaggeration, it is completely wrong and inaccurate. You sir, are an alarmist
You threw the baby out with the bathwater... oh the horror. Someone go get the baby back.
The incidents you describe did not compromise the vast majority of SSL connections. Only a tiny fraction, and only for a limited time span, since the beauty of the CA system is they are able to revoke cert's once discovered to be invalid. Although that can take some time to trickle down since many OS's cache the CA's public key, and is only changed via a system update.
Self signed certs are far more insecure. At least with CA certs you have a 99.9%+ chance of having a secure connection. With self signed certs, you have 0% guarantee unless you've been communicating public keys out of channel.
I'm not sure what "job" you are referring to is more difficult. There is a vast wealth of libraries and applications that support SSL, making any "job" involving supporting SSL easy. If that is difficult for you, maybe you should get a different job.
If you want to take the lead on implementing a new system that provides the same level of security then be my guest. Otherwise all I hear is a bunch of CA bashing non-sense that has no root in statistics.
"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."
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.
Except for Google, who provides no mechanism to associate a private CA cert, or the public side of a self signed one, with a gmail account.
"National Security is the chief cause of national insecurity." - Celine's First Law
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.