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 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?
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
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.
Adult Role Playing Forum
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 !!
Muchas Gracias, Señor Edward Snowden !
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.
StartCom offers free basic signed certificates at their http://www.startssl.com/ web site. You don't have to pay. Enough with the FUD already.
Not treating self-signed certs as trusted is bullying the little guy?
Self-signed certs are for internal apps or testing only. Period. Expecting anyone else to take them seriously is to not understand what a security certificate is for.
Are the big CA's foolproof? No, but they're worlds better than letting any yahoo generate a private certificate and demanding it be trusted.
You get what you pay for.
Be seeing you...
Free, trusted, certificates from https://www.startssl.com/ - no excuse at all for using self signed, at least until DANE/TLSA is deployed.
If you can't afford the $13 per year to get an official cert, you shouldn't be in business.
Also with SSL-SNI (supported by IE8+) you can use 1 IP with multiple SSL certs/ports.
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).
With respect, YOU'RE the one with the false dichotomy.
Allowing unencrypted connections is a problem and should be fixed. Allowing self-signed certificates is a problem and should be fixed.
Why does the fact that they haven't solved one problem mean they're wrong to fix the other?
Hi. How hard is it to setup your own email server at home, for receiving emails? I'm kind of tired of being dependent on others, but even though I'm on Slashdot I may lack the necessary ability to set one up right.
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.
The link only says they are validating the certificate chain... are they actually checking the identity of the remote POP3 server as well?
If not this system is no more secure than an unknown self-signed cert as anyone can legitimatly obtain a valid SSL certificate.
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.
I am setting up a few certs for various things here and there, what is the reliable cheap choice of the IT community these days?
You can store certificate fingerprints in dns, and if the dns zone is signed with dnssec you can use it as a trust authority and avoid the whole root CA crazyness. See: http://tools.ietf.org/html/rfc6698 I suspect google dosn't support it tho :(
Seeing as how I don't trust any god damn CA to get it right - remember the CA That was hacked (DigiNotar?). How about the false MS Certs that were issued by Malware recently? Do you really think any god damn chain of trust is worth a damm? I sure as hell don't. Thus I see no problem with using Self-Signed certs for email or other elements. The only purpose of a cert is to ensure you're talking to the right person. Otherwise they're as usefull as a square wheel on your charriot. It may work but makes the job more difficult then it actually needs to be.
Fast Turtle
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 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.
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.
I use Hotmail/Outlook and Verizon at random... however, for importing these into Gmail as POP3, they both support SSL. So there's not much issue on this part. With email being so easily accessible, is this really an issue? I guess the big question should be: Is there an email provider that doesn't provide SSL connection when retrieving via POP3?
A little bit harder now, if you want to use Gmail as your mail client and use SSL on the connection to Google (though its not any harder if you want the use of SSL on the connection to provide any actual security.) This change, after all, only affects what kind of certificate a server has to have to Gmail to make POP3+SSL connections to it.
The Perspectives 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.
It's up to you to determine which CA's you trust. I don't consider that part of the infrastructure to be terribly broken. Certificate revision on the other hand, is an area where we need to improve significantly. I'd like to see compromised root certificates revoked, and infrastructure for for distributing those revocation lists more widely available.
I trust self signed certificates for my own purposes. For internal websites, it makes a lot of sense to maintain my own CA, and sign my own certificates, and distribute my own public keys. This provides additional flexibility internally, and helps keep costs down. It's also handy if I want to proxy SSL encrypted sessions.
When dealing with 3rd parties, I still want a certificate signed by a major CA. It might not be perfect, but if you don't go to the efforts to complete the process, I'm going to assume you haven't bothered with a lot of other security measures as well.
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.
Agree completely, they took a step in the right direction. Otherwise China can man-in-the-middle of someone retrieving email over a connection with a self-signed cert, and then find and arrests activists retrieving their email that way. It might be misleading to use Gmail in the "Only SSL" mode, not reallizing that the connection from Gmail to third party pop3 is not secure at all.
> Self-signed certs don't provide any security advantage in the Gmail use case over no SS
That's complete nonsense. They don't provide robust protection against stolen certificates, but neither does having a valid signature authority these days: they're too easy to steal or purchase through a third party's rootkitted server, or sign with a recently stolen signature authority. All of these have happened and been publicized, right here on Slashdot.
SSL encryption does cost computational money, but signed SSL certificates also have to be signed by a signature authority that holds your billing certificate. This move is aimed squarely at making individuals traceable to all SSL traffic, and serves the desire of customer tracking and government hacking equally well. It does not service end user privacy in the slightest.
Are you sure this is true? Either you intercept the initial handshake and get access to a full MITM attack, or you miss the initial handshake, and can't decode anything.
At least, that's my understanding of how SSL attacks work.
"First they came for the slanderers and i said nothing."
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?
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.
I use OOB signalling to cross-sign certificates. They appear self-signed but the other end already knows what cert to expect. (For human consumption I send the other human the hash of the cert.)
If so then all griping here about the lack of free certificates is for naught...
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
Everything I write is lies, read between the lines.
As much as I want to like Google they really slip up sometimes. ;) 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.
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!
Just have one of them sign your cert. All they ask is evidence that you own the relevant domain name. I've had good success with StartCom. Their public cert is trusted by most OSes and browsers. If anything, Google's action may be a boon to such CAs.
What isn't being talked about here is the fact that with the recent cancellation of exchange on gmail, people have been switching services in droves. I personally switched to outlook.com. What this update did was to target the official microsoft response to WP8 not being able to support push email from gmail after exchange stops in January. Now gmail won't let you import pop3 into outlook.com anymore, and this bullshit fight is just getting out of hand. This is google being anti-user.
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
Do you Gentoo!?
Not just those people using self signed certs.
If Google allows anyone to use a self signed cert than any self signed cert can be used to MITM a connection, even if the real server uses a real certificate.
Thats the problem.
And no, it isn't Google's problem to build extra infrastructure JUST because your cheap, lazy ass thinks you should be able to upload your own thumbprint of your own cert.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Yes, that's exactly what I meant. Maybe I wasn't clear in my original post.
The only way to break the encryption is to launch a man-in-the-middle attack. You need to pretend you are the other side, to both sides.
If you are merely listening, you won't be able to get anything. However, if do you have the MITM, then you will be able to modify traffic, not just listen.
So those are your only to options, intercept the initial handshake with a MITM attack which gives you full access, or you will have no access to the transmission at all.
"First they came for the slanderers and i said nothing."
Then it is $24.95 to revoke the bad cert, which you have to do becuase an IP is only allowed one cert.
I would be more interested if CACert is supported. Free for everyone, not just the lucky and the very careful.
This allows outbound connections from Google to J-random-POP3-server to be reliably encrypted.
The other option would have been to permit you to upload, and cause Google to use, J-random-certificate for an outbound POP3 connection. However, doing this doesn't reliably achieve the "reliably encrypted" goal, since you could upload an intrinsically compromised POP3 peer certificate.
The reason for wanting the reliable encryption is that an untrustworthy ISP, government agency, or some with the capability of forging BGP could compromise the encryption with a MITM attack.
With the requirement in place, the eavesdropping agency has commit fraud, or obtain cooperation of the certificate authority, and should that become public knowledge, they would quickly find themselves untrusted by all major browsers.
The point, then, is that it is now impossible to cheaply and unobtrusively perform Great Firewall Of China or NSA-style "cast a wide net" operations on email traffic, or the type of warrantless wiretap of email that several recent US court decisions have said is "legal and not an invasion of privacy" for any email left on a server for more than 90 days.
If you start encrypting the email itself with S/MIME on top of that, you have an end-to-end guarantee that doesn't make the people using S/MIME "look suspicious, because if they didn't have anything to hide, they'd let us see it".
This type of thing is definitely a move in the right direction: drag the trusted CA's into it, and let them go out of business if/when they violate the trust place in them.
If China controls a CA (such as CNNIC), they can do that anyway.
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
"completely useless" and "completely wrong" require context to be properly evaluated. Some people look at this http://notary.icsi.berkeley.edu/trust-tree/ and say no way in hades can I depend on every single one of these actors behaving properly to ensure the security of MY system.
The incidents you describe did not compromise the vast majority of SSL connections.
If one (intermediate) CA is compromised it becomes possible for holders to perform undetected MITM against *ALL* sites globally. Every site on the network has its effective security reduced to an untrusted certificate.
To say only a small number of them would actually be compromised by compromised key holder(s) is an unknowable assumption. It does not change the severity of a single compromise of any root or intermediate.
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.
This requires a compromise to be detected and reported.
At least with CA certs you have a 99.9%+ chance of having a secure connection.
I am not impressed by numbers pulled out of thin air but lets use this and assume 99.9% is correct. This means 1 out of a 1000 connections are insecure. Not something I would find acceptable as either an operator or end-user.
Anyone using Gmail for their email interface can't be too concerned about security to begin with.
Don't they know how Google makes money off of their email service? Their system is a man-in-the-middle attack.
First, last week Google now forces permanent DOM storage cookies on it's web search pages... now this. And that's after Chrome sends all your URLs, all your downloads, and other information to Google for permanent recording and matches it across all it's services to build an even bigger profile on every person.
People should just stop using them.
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.
Looks like most everyone has missed a real point for Google doing this.
You & the data about what you do are NOW MORE VALUABLE when Google tracks & sells your details.
It & you are now Certified :-) Money Money Money
But there's not much point in posting cause there's so much hash and my posts never seem to show up.
The argument is that unencrypted connections are vulnerable to passive wiretapping - while self-signed SSL is not.
If the attacker has hijacking abilities then it's game over for both unencrypted gmail and insecure-SSL gmail accesses.
So what Google is doing here is to make it really apparent whether you are safe (within the authentication limits of SSL), or not.
It's about gmail users [some of which ARE spammers] being able to send email to NON-gmail addresses.
Care to explain how? As far as I can see its about gmail users downloading received emails from another system into gmail for viewing/archiving etc.
So next time we should need a valid certificate for our browser, to access gmail?
The interesting thing about public key encryption is that two parties (who don't know each other) can communicate in complete secrecy with each other while a third party listens in on the whole conversation including the handshake.
It is a very expensive operation so most of the times (like with SSL) a secret key for a symmetric block cypher is communicated to each other using public key encryption. After which the rest of the communication is done through a symmetric block cypher for performance reasons.
With certificate chains we add the ability of the two parties knowing each other through a trusted third (well forth in my example, maybe I should have started with Alice and Bob) party. That way someone with the ability to not only intercept the traffic but also redirect (man in the middle) it would be found out.
However certificate authorities are very fragile, especially if you trust 100 different ones (like browsers do) only one has to sign a certificate of a man in the middle and everyone will trust him.
It would be better if you could give google your own CA that it only trust for your connection to your infrastructure.
You're telling me there are email providers that allow you to connect via POP3, but don't provide an option to set up a simple mail forwarding?
With self signed certs, you have 0% guarantee [of having a secure connection]
With self-signed certs, you have a guarantee that the host you're communicating with is the same host you connected to last time. Which is worth something. Worthless? Hell no.
Server SSL certificates (that are recognized by existing browsers and operating systems without having to install a root certificate manually) are free (from startssl.com, among others), so there really is no excuse to be using self-signed certificate any more.
Yeah, apparently no security is better then some security according to google.
Got certificate from startssl, but it's a pain. Couple of hours of totally pointless work.
Another example where perfection is the enemy of good. This is my gripe with most computer security people. One of the reasons why encryption is not as widely deployed as it should be is this attitutude that "it must only be perfect".
It's up to you to determine which CA's you trust. I don't consider that part of the infrastructure to be terribly broken.
Gmail doesn't let you select which CAs you trust. Besides, the only CA I trust is the one I run, and this whole article is about blocking self-signed certificates. :)
Look at the list of CA roots in just about any device or browser you use. Have you even heard of half of those companies? What are the chances that one of them ISN'T doing something nefarious, or at least incompetent?
The only reason they're on the list is that at one time in the past they paid a bunch of money to an auditing company to say that at that point in time everything looked fine. That point of time could have been a decade ago, and they can delegate all the intermediates they care to.
Can we please kill pop3 and move on?
They also announced they're actually moving it back to beta so they have an excuse to do stupid stuff like this without warning, lol.
That's the thing about clouds, they're always changing. If you want consistent, reliable webmail, run roundcube on your own server and stop gifting Google your data.
You could always use Microsoft's outlook.com free service.
In the abstract SSL case that's true. But the issue here is not the abstract SSL case.
In the concrete case of Gmail's POP+SSL implementation -- where Google's practices and the requirements for using it are well-known and public -- the attacker knows that there is no facility for a self-signed cert used on a POP server that is being contacted by Gmail to be pre-shared with Google, and therefore knows that it is safe to MITM such traffic, both capturing the real data from the POP server and injecting false data to the Gmail client, with a forged self-signed certificate if it intercepts the request. Which is why, in the specific case at issue, self-signed certs provide only illusory security. (This is more generally true of their use in any public system with known policies and no presharing facility; obviously there are uses to which this is not applicable.)
Note particularly that, if an attacker can intercept requests to the POP server, Gmail's support of self-signed certs allows it to impersonate (and MITM a connection with) a server that would legitimately be identified by a cert with a valid CA chain anchored with a trusted CA using a self-signed cert, since Google's server in this case is the POP client and authentication of the client uses username/password rather than a client certificate. So supporting self-signed certificates the way Gmail did compromises the security of users whose POP server has a certificate signed by a trusted CA, it doesn't just merely affect those who are willing to accept the issues around self-signed certs to avoid the effort of getting a CA-signed cert for their POP server.
One can perhaps legitimately argue over whether it would be bettter for Google to require self-signed certs to be pre-shared over a connection authenticated by some other mechanism than to discontinue all support of self-signed certs for its POP+SSL implementation, but I don't see any legitimate argument that the use of POP+SSL with self-signed certs that Gmail had prior to discontinuing support for self-signed certs provided anything but a dangerous gaping hole in the security of all POP+SSL users.
Yes, but supporting unauthenticated encryption in a manner which creates a new attack vector that works to bypass authentication of servers which otherwise would have authenticated encryption in order to support unauthenticated encryption for a minority of servers is making security for most users vastly worse.
Sure, but this is offset against the fact that supporting self-signed certs without presharing means that all SSL connections in Gmail's POP+SSL implementaiton were subject to MITM by way of self-signed cert, not just those made to servers where the real target server used a self-signed cert (since an attacker that can intercept traffic destined for the server with a CA-signed cert can impersonate that server with a self-signed cert, capture the logon credentials, and then use them to establish its own connection to the real target server.) Net, this is a huge loss for security for all users, to support a small gain in security for those users whose POP server operators didn't want to bother with a cert with a trust chain back to a valid CA.
POP3 does not have the server authenticate to the client with a username and password; in the case at issue, Gmail is the client, the POP3 server (whatever kind of certificate it has) is the server. So, while its abstractly possible to provide some authentication method along with a self-signed certificate in an SSL application, there is none available in a POP3+SSL environment (except presharing the public key through a separate authenticated connection), and certainly there was none being used by Gmail prior to discontinuing support for SSL to POP3 servers with self-signed certs.
There might be room for some debate about whether this was the best way to fix the problem (and, particularly, whether a facility for advance key sharing for servers with self-signed certs might have been a better idea), but there doesn't seem to be much legitimate room to argue that the pre-existing setup was a massive security hole that created MITM opportunities against any POP3+SSL server that Gmail tried to connect to and which needed to be changed, and that disallowing self-signed certs is a net gain even if it isn't the best possible solution.
Lots of people are making arguments about the abstract utility of self-signed SSL certificates but not really understanding the implications in this particular use case.
First of all, this is old news. Secondly, has it occurred to anyone that if Microsoft had pulled this stunt, the resident "Slashdoter's" would have been up in arms crying over the inhuman policy of a tyrannical corporate entity. However, since it is Google, who personally I believe is far more evil than Microsoft, the posts are mostly low keyed and benign in nature.
Pigskin-Referee
Linux: Yesterday's technology, tomorrow
DigiCert just wrote an article about this with an explanation and troubleshooting tips. Check it out:
http://www.digicert.com/ssl-support/gmail-pop3-troubleshooting.htm