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.
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.
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?
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.
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 :(
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?
There are distributions of Linux and Windows Server that make it pretty easy to setup. The hardest part will be configuring DNS, and the possibility that your ISP won't allow it. If they did allow it, they'd have trouble with their IPs getting blacklisted on account of people spamming from their home email servers.
That's like saying the Nexus One doesn't support making phone calls, it's all the antennas and chips inside.
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.
(Nods head in approval)
They are still very usable in server-to-server communications, or some client-server scenarios. You can provide the respective public key's manually out-of-channel so each server can identify the other securely, and benefit from the security of SSL without the need of a CA signed cert. A devil's advocate would say someone with access to the server could swap the public key maliciously, but the same is true of the CA's public key. (If someone with malicious intents has that level of access to your server, you are screwed in 100 other ways anyhow.)
There would be a bigger place for self signed certs if there were more user friendly means to manage public keys out-of-channel, but the majority of the public would not endure that minor annoyance without understanding the value. Additionally, they would be more vulnerable to social engineering attacks of the form "Share this public key with your friends, copy and paste to 10 friends and you could win $1000!" if the system wasn't designed thoughtfully.
If you can't afford the $13 per year to get an official cert, you shouldn't be in business.
Agree. There is more money in the time it takes to go through the certificate generation process (self signed or csr) and installing it than in the cost of the cert.
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.
Except that the person specifically mentioned 1 IP hosting several SSL-enabled domains (which is SNI), which IE cannot do on Windows XP because IE doesn't provide its own cryptographic engine. The fact remains that IE doesn't do crypto, it uses the Windows crypto library, which is more limited (including lack of SNI before Vista).
It's like saying my tablet can't do LTE because the phone that's tethered to it doesn't support LTE. It's but weirdly stated, but true. If I upgraded my phone, my tablet would get LTE, but that's hardly the point because I still don't have LTE either way.
Which is exactly the situation in which a self-signed certificate is appropriate. But it doesn't really matter in this case, since your reason for setting up your own mail is to take control of your own data, not hand it over to Google.
I didn't make the leap from "IE doesn't support SSL at all" to "IE doesn't support SSL at all with 1 IP hosting several SSL-enabled domains" since the "at all" part implied that he was throwing out the previous context and making a blanket statement about IE lacking SSL support.
It's quite challenging these days, mainly due to the various anti-spam measures that are deployed around the internet which you need to understand and configure your server appropriately to avoid being blocked. Also, you need to keep up with security updates (this goes for any server open to the internet) as script kiddies will be hitting you dozens of times per day.
An alternative is just to aggregate your mail from other servers using fetchmail + dovecot, and take control of storage and backup yourself.
There wasn't that leap to make. AC said "IE doesn't support SSL at all, it's all windows internal" which is a (possibly poorly phrased) way of saying that IE doesn't support SSL independently, it uses the SSL implementation built into Windows. Obviously IE works with SSL, it's just not actually a part of IE.
> 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.
Exactly. To say "Obviously IE works with SSL" is the opposite of "IE doesn't support SSL at all", which was the point I was trying to make with the phone analogy.
I just tire of people taking the most extreme position they can on something, when they could have conveyed the same without the inflammatory fluff. Instead of contributing to the conversation by clarifying that SNI support is tied to the OS instead of IE version, he couldn't help but quote the OP and then state exactly the opposite regardless of how twisted the wording was:
"(supported by IE8+)/IE doesn't support SSL at all"
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."
Who exactly is stating the opposite? I agreed that the wording is weird, mainly because they didn't put in something like "built-in" with their statement "IE doesn't support SSL at all", but I'd hardly call it inflammatory...
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.
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.
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!?
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.
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.
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.
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.
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.
An easy solution to this is to use your ISPs outgoing mail server as a "smarthost".
Incoming mail comes directly to your server. Your mail client connects to your server to send outgoing mail and your server connects to your ISPs server to relay that outgoing mail.
It's just one extra hop (though it does put your outgoing mail at the mercy of your ISP, who can sometimes suck) but it solves a lot of the problems relating to running a mail server at home.
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.
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