> This method is rarely used, instead for the domain validation most certificate authorities ask the domain owner to place a certain file in their websites. This statement strikes me as odd. Email-based validation is the most common validation method used by most CAs for DV certificates. The only exceptions that come to mind are WoSign and Let's Encrypt. The vulnerability is pretty bad, though. Good catch.
StartSSL domain validation vulnerability
61–70 of 75 posts
Re: StartSSL domain validation vulnerability
#62Earlier quoted context omitted.
Right now, StartSSL needs to do a quick search on their database to see which certs had email sent to a domain other than the one for which the cert applies. All such certs should be revoked immediately, and the owners of the domains involved notified of the breach. Also, did they check properly for TLD and subdomain issues? If I have "me.blogspot.com", can I get a cert for "blogspot.com"? (What's a TLD today? It's c…
StartSSL only allows validation for top level domains. So you can't get a cert for me.blogspot.com unless you own blogspot.com.
What about blogspot.co.uk? Do you need to own that, or co.uk to get a cert?
What counts as a "top level domain" is, as Animats said, complicated.
Re: StartSSL domain validation vulnerability
#63Earlier quoted context omitted.
StartSSL only allows validation for top level domains. So you can't get a cert for me.blogspot.com unless you own blogspot.com.
I think you entirely missed his point. What about blogspot.co.uk? Do you need to own that, or co.uk to get a cert? What counts as a "top level domain" is, as Animats said, complicated.
Re: StartSSL domain validation vulnerability
#64Could the hotmail address have been allowed because it's listed on his domain name's WHOIS?
Re: StartSSL domain validation vulnerability
#65Earlier quoted context omitted.
For a while, I ran a small non-profit gaming site. This was well before Let's Encrypt, so we looked to StartSSL for a free certificate. They denied us. Why? Because we had links to a Paypal account set up to take donations. Even though PayPal had its own security, and we were only providing a link to it, that was enough for them to deny us the cert. They refused to understand that WE would be conducting no financial…
From their policy: > Class 1 certificates are limited to client and server certificates, whereas the later is restricted in its usage for non-commercial purpose only. AFAIK simply taking donations counts as "commercial purpose". You are free to dislike their policy though.
Re: StartSSL domain validation vulnerability
#66Earlier quoted context omitted.
It has been fixed according to the article: > In 9 March, 2016 During my research I was able to replicate the attack and issue valid certificates without verifying the ownership of the website which I will explain later in my post, the vulnerability was reported and fixed within hours.
This post needs to be higher up in the thread, and not people overreacting and demanding having them removed from browser's CA-stores etc.
Re: StartSSL domain validation vulnerability
#67Re: StartSSL domain validation vulnerability
#68Re: StartSSL domain validation vulnerability
#69Arguably this vulnerability is serious enough to see StartSSL dropped from the trusted root store, or at least see browsers taking action to block DV certs from StartSSL issued before a certain date. It/they won't be, of course, since the whole system is a farce. I'd lament again how we still need to push DANE, but I was doing that 2 days ago here on HN[0] and I'm tired of it. Nevermind, maybe the next bug we see wil…
Re: StartSSL domain validation vulnerability
#70Earlier quoted context omitted.
I work for a hosting provider that acts as a reseller of certs and we use the DV file option the author speaks of. It's easy for us because we can automate the entire process for the customer. Whenever I've bought a cert for myself I've used the same process. I never thought email verification seemed like a great idea.
It's certainly easier for automation. I think the security implications are mostly the same - you're vulnerable to DNS spoofing and BGP hijacking either way. With email validation, a misconfigured or breached email server is enough to get a certificate, while with http validation, it's your web server or web app that could be vulnerable.