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.
Communications Breakdown (Score:5, Insightful)
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.
Cue the self-signed-certs are insecure responses. (Score:5, Insightful)
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.
Google should then provide signed certs (Score:3, Insightful)
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?
Re:Google should then provide signed certs (Score:3, Insightful)
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.
Re:Google should then provide signed certs (Score:3, Insightful)
Re:Communications Breakdown (Score:5, Insightful)
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 ?
Free service gets changed? (Score:4, Insightful)
You get what you pay for.
Re:Cue the self-signed-certs are insecure response (Score:5, Insightful)
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.
Re:Google should then provide signed certs (Score:4, Insightful)
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.
You are wrong. (Score:5, Insightful)
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.
Self-signed vulnerabilities (Score:4, Insightful)
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.
Re:Cue the self-signed-certs are insecure response (Score:5, Insightful)
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.
Re:Google should then provide signed certs (Score:5, Insightful)
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.
Re:Google should then provide signed certs (Score:4, Insightful)
Or, you're a large organization and running your own CA means saving $30 x (large number N) per year. Or, you're aware that getting a "real" cert is no guarantee of security.
Re:Google should then provide signed certs (Score:3, Insightful)
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.
Re:Google should then provide signed certs (Score:5, Insightful)
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.
Re:Communications Breakdown (Score:4, Insightful)
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.
Re:Self-signed vulnerabilities (Score:2, Insightful)
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.
Re:Google should then provide signed certs (Score:4, Insightful)
You may argue, and more qualified than you may argue, but that doesn't mean they are qualified. A self signed cert is useless other than testing. Anyone can walk right through it.
You would argue it because you don't understand that snake oil doesn't actually accomplish anything other than fooling fools into believing they are secure when they aren't. Thats worse than making people aware of the fact that they aren't secure, in which case they can consider their behavior and curtail it appropriately.