Domain validated SSL certs for google.com.mg and google.com.im (not Google) | Hacker News Reader

Domain validated SSL certs for google.com.mg and google.com.im (not Google)

certsimple.com

19 pointsnailer24 comments

Head of Let's Encrypt here.

We were aware of the "google.com.mg" cert soon after it was issued. We didn't revoke the cert for the same reason we don't revoke most certs: as far as we can tell, the cert was issued to the entity properly controlling "google.com.mg". Whether or not that is Google (the company) is not really within our purview.

That said, in this case, as a courtesy, we did notify Google employees and made the decision to report the site to Google Safe Browsing. GSB and SmartScreen are the right places to deal with things like this.

IIRC GSB did block the site for a while, but that block seems to be gone now.

> Whether or not that is Google (the company) is not really within our purview.

Hi Josh. This is mentioned in the third paragraph of the article, but it looks like HN didn't read that far, so probably worth mentioning it again.

I didn't mention LE specifically out of respect for the work you guys are doing, but since you've posted here: why wasn't this flagged as a High Risk Certificate Request before issuing per Baseline Requirements 4.2.1?

Also where is the High Risk Certificate Request check available in the LE source?

Thanks!

66 days later google.com.mg is still owned by not-Google, not revoked, and not on any 'safe browsing' warning lists.

So? Why would a website be in safe browsing warning lists if it doesn't do anything malicious? Does Google own a trademark in Madagascar? If so, they probably can take down this domain by asking NIC-MG. If not, then, unless this website is used for phishing, I don't see any problems with issuing a certificate.

(It's interesting how companies selling certificates switched to scare tactics after Let's Encrypt made DV certs free.)

> Why would a website be in safe browsing warning lists if it doesn't do anything malicious?

Some of the previous arguments in favour of DV have said that safe browsing lists will catch misissuance.

Whether DV certs are $10 or $0 doesn't make a huge difference: they don't check identity.

Some of the previous arguments in favour of DV have said that safe browsing lists will catch misissuance.

Yes, so what is this website doing that warrants this measure? There was no misissuance.

I don't get the tone of the article. Why is this a bad thing?

It's not the job of SSL to ensure a domain name is not owned by someone it shouldn't be. That falls to the domain registrar, if you have a problem with someone owning google.com.mg go take it up with the registrar or better yet leave it up to Google as it's THEIR trademark.

I actually find this to be a good thing that someone was able to get a domain, create an SSL certificate for it painlessly and start securing traffic between clients and their web property without having to spend a) tons of money and b) tons of time dealing with antiquated CAs that should be entirely automated.

The tone of the article is such because the company writing it only sells EV certs and therefore is on a relentless quest to discredit DV certs as inferior.

Author here: DV certificates are inferior. Knowing whose key you're encrypting with is a good thing. DNS providers do not do identity checks.

Edit: 100% agreed with laumars' point below regarding blogs and low trust sites. DV certificates have their place, it's just that high trust websites aren't it. I've added an author tag as requested.

If I'm connecting to my bank or preferred e-commerce store, then yes. If I'm connecting to Joe's wordpress blog or some random wiki then I barely care if the site is even under TLS to begin with, let alone whether the site had passed a human authorisation process prior to receiving their certificate.

And frankly, the vast majority of internet go-ers are non-technical and wouldn't even notice the different between DV and EV certificates (let alone care), so I question just how well EV even solves the problem you're claiming to address.

It's also generally good etiquette to disclose when you're the author and employee of the company in question (a company that specifically sells EV certificates) when replying on HN; since that highlights biases regarding your arguments

Person who just registered certsimple.org and certsimple.net here. Will you issue me a EV cert?

That's pretty hilarious. I'm sure even if CertSimple won't issue you an EV cert that one of the many providers others will.

I just noticed he's in the UK, so surely he's registered certsimple.co.uk, right? Nope. Yay, now I have another domain!

I will begin issuing EV certs via my new company 'Certs Imple Limited' very soon. You can trust us, we have more domains than that other fly by night organization does.

And furthermore, you shouldn't need to get your identity verified and send in pictures of your ID just to make a website, blog, or custom email domain.

> it's not the job of SSL to ensure a domain name is not owned by someone it shouldn't be.

That's correct. CAs checked identity back in the 90s, but stopped and moved to domain validation for most certificates. The article mentions explicitly: the certificates aren't fake, they're just DV, and that's what DV is. Obviously most consumers have no idea about that, and have been conditioned to trust any kind of SSL.

The main issue asides from most consumers having no idea what DV is, is that Section 4.2 of the baseline requirements - which applies to all CAs - asks CAs to check for 'high risk' domains. That's clearly broken here.

Certificate transparency records for the domains in question:

https://crt.sh/?q=google.com.%25

> Obviously most consumers have no idea about that, and have been conditioned to trust any kind of SSL.

Is that actually the case? If I see a "check for HTTPS!" reminder, most of them clearly show and talk about the name from a DV cert.

What do you mean by 'the name from a DV cert?'

typo. meant EV, where the cert owner shows up in the URL bar.

I'd love that to be the case, but I'm not sure it is.

So, in a nutshell, these guys are saying that (a) it's too easy to get a misleading cert and (b) they make it easier to get a certain kind of cert. That's going to be a hard sell. They need to make a case that non-EV certs are worthless not only in terms of security but to consumers - i.e. that you, the certificate buyer, will lose business. Then they need to explain why EV certs are better, and lastly how that superiority can be preserved even on a shorter acquisition timeline. They do none of that. The article is not only too pitch-y for HN, but it's also a poor pitch.

So everything is working as intended? Great!

That's the third paragraph of the article. Keep reading.

This feels a little like link bait. You don't realize till the end that it's a pitch.

Author here. As the article mentions, this is how DV SSL works. The issue is that most people outside tech are conditioned to trust DV identifiers.

As a side note, newer versions of Chrome have stopped using 'identity' for domain validated certificates.

A domain validated cert in Chrome in 47.0.2526.106 http://i.imgur.com/RiISSrU.png

A domain validated cert in Chrome 49.0.2618.0 no longer refers to 'identity' http://i.imgur.com/XkaPDwx.png

The term 'identity' remains in use with extended validation certs - http://imgur.com/j7fKGt1

In other words: DV CA does exactly what it's supposed to do.

Reply on news.ycombinator.com