Gmail now refusing to fetch using self-signed certs | Hacker News Reader

Gmail now refusing to fetch using self-signed certs

support.google.com

55 pointsmleonhard56 comments

People don't seem to understand how insecure self-signed certs are (and aren't if provisions are taken).

1) A self-signed cert provides zero protection against just about any attack that would work on clear text - any attacker can simply create their own self-signed cert and pretend to be you, and Google would have previously accepted this and happily accepted the incorrect mail. This is broken security in every way, and it is better to use no security since at least nobody can believe it is secure.

2) Self-signed certs are actually stronger than 'chain of trust' certs, provided you can trade the public cert in advance. Google should have a box on their POP fetch page where the public cert can be entered. This is more secure and the correct way to handle the problem, rather than blocking self-signed certs.

Self-signed certs are perfectly valid if the public cert is provided beforehand. Self-signed certs with the public cert used unchecked from the server is COMPLETELY BROKEN.

TLDR; Google needs to provide a box for the user to upload the mail servers public certificate.

What about having your own (self-signed) CA? You sign your own certificates and import that CA on your computer. Would this effectively prevent a man in the middle attack?

Good luck getting Google to trust your CA ;)

Sorry, my question was not actually meant to be about this Google situation but about the general approach to using your own CA instead of self-signed certificates.

As long as you don't need your services to be used by third parties then a private CA is a good option, and in some ways more secure than traditional root CAs.

So long as you can find a secure way to get your CA cert onto whatever systems need to verify your server certs, it can be a very good thing. The main advantage of this over public infrastructure is that you don't have to trust the authorities, some of whom have in the past been caught handing out dodgy certificates or been compromised.

For a set of private systems that don't need to interface with the public internet and unknown clients, I would go so far as to recommend it. You must keep your master keys safe of course!

It will prevent it as long as the client has your CA's public certificate embedded. Browsers/OS embed all of the normal CA's certs so that you know any cert signed by a regular CA is authentic. However, regular CAs are not incredibly trustworthy and are a security problem... (Regular CAs can be attacked with fairly easily with social attacks, and some CAs can even be bribed or hacked.)

Giving Google your CA or your public mail cert are effectively the same thing in theory, as long as Google only uses your CA cert to authenticate your own servers and not anybody elses.

In practice, current CA management software in most OSes is (imho) faulty, and will allow any CA in the chain to authenticate any cert. This probably needs to be fixed at some point... So until then, there is no way Google is going to accept your CA, but they SHOULD change their systems to accept a specific public cert for a mailserver for POP3 fetching.

You would hope the smart minds at google could come up with a management system for this fairly easily, though I guess it does add complexity when you're dealing with potentially millions of these servers and millions of trusted roots.

Self-signed in this context basically means "signed by something else than a trusted CA", not the strict meaning of signing a certificate by itself.

There are two elements to public key crypto: The encryption itself (which is perfectly fine on a self-signed cert) and certificate distribution (for which the best current solution are the globally trusted CAs). If you can somehow guarantee that your attacker can only listen to your data, not inject himself as a MITM, self signed is perfectly adequate to protect yourself. The catch is that providing this guarantee is very difficult.

"Google needs to provide a box for the user to upload the mail servers public certificate."

This looks like a brilliant idea. In that way the self-signed cert gets verified without the hassle of getting CA signed certificate that it's not an optimal solution if you're virtual hosting several domains (you can get a free cert from StartSSL, but with virtual hosting and IPs being scarce and all, that's far from being a good solution).

Thanks about speaking about StarSSL, I didn't knew you could get a CA signed certificate for free. I just need to sign mail and would like to get rid of the "invalid certificate" message when accesing administration side of my apps.

you get 1 for a single domain and thats it. they can stop doing it at any time, eg after they get everyone's business and services all disallow self sig.ed certs.

also by nature these certs are poorly checked and thys less trustable than some other, obviously

If one is fetching emails without SSL, does that mean the data is sent in clear text over the wire?

In that case, self-signed do provide greater than zero protection in regard to ISP surveillance and other passive attacks. (similar to smtp tls encryption, enabled by default by almost all mail servers, and uses self-signed certificates).

I use "real" certs on my START TLS enabled mail servers; it's not that hard to set up, and people should. (free certs from StartSSL, but still "real")

Only if there isn't running some sort of self-signed detecting MITM running. Which is not that hard - I made a trivial one that pretends to be a DNS server and hands out phoney addresses, then both forwards and dumps all traffic in ~250 lines of python.

But yes, it would stop purely passive attacks, unless I'm missing something.

Sure, but this is the same as having a locked door with a window next to it that anybody who knows how can reach through and unlock the door.

You can say that having the locked door is better - it will stop anybody who does not think to unlock the door through the window. It also stops any robots that come past who are programmed only to try the door-handle and move on if it fails.

Problems start to come in when you put this security on a warehouse and customers leave their secure items inside having been assured that the door is locked. Clearly, anybody can just reach through the window, unlock the door, and take the secure items and the customer is left wondering why the advertised locked door didn't help them.

Setting up a MITM mail server for an ISP that will happily proxy between the real server and the requester is as trivially easy as reaching through an open window. When asked, they could just say that it is for 'security purposes' and it helps with 'caching'. If your email provider is willing to snoop on all your email, they're probably willing to tell a few lies also.

Well actually even trusted CA's are not that trustworthy as we've seen recently by the number of revocations.

Probably a better approach thank just nuking it would be for Google to import a public certificate into their store for your self-signed cert and then only trust that one.

and thus and per your own words, self signed is just as - and in fact more - secure than regular certs, when used properly. all the uis, except ssh, are broken for this mechanism.

killing self signed just gives more business and control to big corporations.

I fail to understand how gmail accepting to fetch email from an account without any sort of encryption, but refusing to fetch email from my CS department which has a self-signed certificate can benefit me or make me more secure...

Disallowing self-signed certificates doesn't improve security of unencrypted connections, but it increases security of all connections using SSL/TLS. It doesn't make you more secure (you don't have strong authenticity in any of those cases), but it certainly makes me more secure.

When Gmail fetches email from my provider, which has a certificate signed by a trusted CA, it would have previously accepted any self-signed certificate from an active MITM.

Thanks for clarifying. I understand the decision better now.

How about an option (disabled by default) that allows self-signed certificate per fetched account, e.g., in the "edit info" dialog? I guess everybody would be happy with this one right?

This is kind of a dickish move on Google's part: you don't just suddendly do something like this, you notify in advance and give time for people to switch over.

StartSSL is on the Mozilla CA list, so it should work with gmail. They offer free certs:

https://www.startssl.com/?app=1

Not tested yet.

I kind of agree on the advance notice, but then again what excuse does anybody have anymore for not delivering IMAP over SSL?

(If you're talking about a personal server, why not either a) forward to gmail or b) update your MX records to point at gmail?)

This isn't about SSL or not SSL, this is about self-signed SSL versus non self-signed SSL.

Sure, but there's absolutely no way to differentiate between self signed SSL cert and a MITM attack.

Sure there is: just get the client to remember the cert.

How do you handle things the first time? Perhaps you're always under a MITM attack.

And what about when you change the certificate deliberately?

> How do you handle things the first time?

You compare the fingerprint.

Compare with what? Honest question, it seems to me self evident that there is nothing to compare to at first time, so maybe I'm mistaken. Would you mind to elaborate?

You have a fingerprint for your certificate on your server. Google connects to your server, and sees a fingerprint. If they are the same, you don't have a MITM.

Is it any better for all affected users to have to 1) figure out what this fingerprint is and enter it and then 2) individually update the fingerprint every time the cert changes, after they figure out that's why they're not getting any email through this particular provider any more? Isn't it easier from Google's perspective to just say "you can't do this" than deal with those complications?

You're completely missing the point, but to answer your questions:

1. If you're self generating a cert, you know how to do it.

2. It doesn't change very often.

This discussion is about Google making a change without warning that has an immediate negative impact on pre-existing users. This discussion is not about new pop3 accounts being added to Gmail.

I agree it sucks that there was no warning, but why would you be using self-signed certificates in this situation anyway? There's almost no benefit at all and in fact all it really does it give you a false sense of security that your connection is "secure" when in fact it's not.

> There's almost no benefit at all

There is, a cert under a CA could be hijacked by MITM (another CA gone rogue), while if a client stores the self-signed cert, it will always be that cert, no exceptions.

Why use self-signed certs? It depends how the client (here Gmail) handles them. If it asks you to approve the cert, and remember the approval, you get exactly the same amount of security as a non-self signed cert. iirc this is what Gmail did.

Sure there is a benefit! Unless you specifically are being targetted with a MITM, your mail will be save and encrypted anywhere between your originating server and Google's receiving server. No ISP or government router traffic harvesting.

If the government wants to harvest your traffic, MITM'ing is not really a great impediment. It might be an impediment for your ISP because of the economic constraint it imposes, but even that is not certain.

As I said, this is no precaution about targetted attacks. It works well against the default packet inspection and probably also storage routers (can) do.

Root-signed certificates tell me only that someone paid money in exchange of "trust" in a certain trust-scheme.

The fact is, the trust scheme currently implemented is broken and bad. A better system is a peer-based one, where self-signed certificates are "root" certificates.

I agree advance notice would have been good - but accepting self-signed certs seems like a recipe for MITM attacks. If I ask Gmail to check my mail.outlook.com account and it gets a self-signed cert back, I'd certainly expect it to alert, not to send my credentials to the MITM.

Gmail now refusing to fetch what from who, where, when?

Is this about people who forward their mail to gmail?

Gmail will collect pop email from other servers if you tell it to. From Wednesday, and without warning, Gmail will refuse to collect that e-mail if the remote pop server uses a certificate issued by a non-recognised CA, e.g. self-signed certs.

Please pardon my security ignorance, but I can't understand why Gmail takes this action while accepting incoming email from unsigned servers. That is, I like to toy with out-of-the-box Postfix setups in VPSes, and Gmail (still) accepts messages from my test domains. (Well, maybe the first one gets flagged as spam, but still.)

Considering that I have taken no actions whatsoever to secure/sign my server, why does Google consider this legitimate? I find it inconsistent. Also, isn't DNS unencrypted in the first place? Is there something like HSTS for mail?

Thanks in advance for any help in clarifying this.

Edit: HSTS, grammar.

The consensus in this discussion seems to be that Google should just allow each mail user to enter a cert (or hash thereof) for each self-signed mail server they're polling. And then each user would need to update each cert every time it changed, or the IP address changed, or whatever. But first the user would need to notice the change, which might not be easy if that email address was low-traffic. (I'm assuming we're not talking about user-controlled servers, because in such a case why not just forward?)

Who would want to get a notice every time the mail server had the wrong credentials? If it's a short-term thing the user can't do anything about it. If it's a long-term thing the user might be able to do something, or she might not. She'll probably just conclude "Gmail is broken", when in fact it is the upstream server that can't be arsed to buy a usable cert and take part in the (admittedly imperfect) CA PKI. Instead they'd like the user to take part in some ad hoc PKI that they'd like Google to set up for them. Are users less likely to screw up cert management than service providers? In general, making the user do work that the service provider could do is a bad smell.

This would be a giant can of worms. This scheme is not something that any other webmail provider does, and there could be security flaws that haven't occurred to us. This service would only be usable by the minority of users who can understand most of the comments on this page. Google would be blamed when things went wrong, rather than the self-signing mail servers who deserve the blame. Credit to Google for avoiding such a morass.

I've often wondered whether tls/ssl should work more like ssh, where there's an initial leap of faith and the public key is remembered afterwards (and you get warned if it changes).

Also if the certificate is published in the DNS, and available through DANE (using DNSSEC)? That would be very disappointing.

Given that startssl offers free "real" certs, I think it's probably ok to ban self-signed certs by default for a lot of things. The key thing is allowing end users to override in some cases, and giving helpful error messages (which gmail seems to be failing on).

that makes no sense, startssl isnt required to provide free ssl certs. they can stop any day. plus its a limited cert, one subdomain max.

I have mail forwarded from from me@mydomain to me@gmail so if I've understood correctly then this might potentially affect me. How would one check now, rather than waiting till wednesday to find out if there is going to be a problem?

No, this only affects users who retrieve email via POP(/IMAP?) into Gmail as separate accounts. Oddly enough this is happening on one of my accounts and not the other, yet I know both have self-signed certs.

Great, thanks for the info

Google are being dicks once more.

Between my own self-signed zero security (as someone claims) certificate and your usual Comodo.com-anyone-can-haz-a-wildcard-cert I'd definitely go for the first.

Anybody can self-sign their own certificate to copy yours in seconds.

A Comodo.com-anyone-can-haz-a-wildcard-cert is definitely safer as it takes far more effort to acquire the wildcard-cert and it leaves behind a financial paper-trail as the wildcard-cert must be paid for by someone. Definitely a long way from secure (stolen credit cards?), but still definitely safer than self-signed.

Of course, self-signed where you transmit the public key beforehand is much safer than both. Some type of 'group trust' system using quorums would be safer also.

If you are using a self-signed cert, your content is probably available over http anyway so you wouldn't want duplication of http + https or you'll get a penalty.

Just use a free startssl cert if it's important to be indexed via https

Er, this is email we're talking about here, not http

Ugh thanks for pointing that out - way too early for me and I glossed over the "gmail" part vs google.

Reply on news.ycombinator.com