StartSSL domain validation vulnerability
oalmanna.blogspot.com
StartSSL domain validation vulnerability
1–10 of 75 posts
Re: StartSSL domain validation vulnerability
#2This is basically a worst-case scenario. The entire public Certificate Authority trust model depends on the validation of ownership of domains that certificates are being issued for. If an attacker can get a trusted certificate for facebook.com, then they can silently man-in-the-middle connections and pretend to be Facebook.
Re: StartSSL domain validation vulnerability
#3This seems to an incredibly basic error for a company trusted to issue SSL certificates.
How long has this vulnerability existed? Can we trust any StartSSL certificates? Will they charge for revocation, as they did with Heartbleed?
Re: StartSSL domain validation vulnerability
#4> 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.
Re: StartSSL domain validation vulnerability
#5A vulnerability of this level is inexcusable. StartSSL ought to be removed from all major browsers.
Re: StartSSL domain validation vulnerability
#6A vulnerability of this level is inexcusable. StartSSL ought to be removed from all major browsers.
Agreed. The more I hear about StartSSL the more I want to run away.
Re: StartSSL domain validation vulnerability
#7This seems to an incredibly basic error for a company trusted to issue SSL certificates. How long has this vulnerability existed? Can we trust any StartSSL certificates? Will they charge for revocation, as they did with Heartbleed?
If someone has fraudulently issued a certificate for a domain you own using this (or any other) vulnerability, you're not actually a client of theirs and I don't see how they could force you to pay for revocation. Issuing such a certificate would obviously be a violation of CA/B Baseline Requirements.
Then again, I'm not exactly sure how one would go about reporting such a thing. Browser vendors have done most of the blacklisting for cases like this in the past (either by blacklisting individual certificates, or removing the root certificate completely for massive breaches). I guess I'd try my luck on one of their mailing lists or bug trackers.
If you have a regular certificate from StartSSL, there are no security implications for you because of this. (As in: for you specifically. For the CA system as a whole, this is a "Set-Your-Hair-On-Fire-And-Run-Around-Screaming-Loudly"-scenario.)
Re: StartSSL domain validation vulnerability
#8OK, so this seems like a terrible vulnerability. Does anyone know if (a) StartSSL has been notified and (b) what has been their response. This seems like such a severe vulnerability that publishing it on Blogspot seems too low key. Shouldn't there be a CVE about this?
Re: StartSSL domain validation vulnerability
#9Now that Let's Encrypt is a thing, there's no reason to do business with these greedy losers.
That's not just an off the cuff insult either - I find very few charitable words to describe a company that charges $25 to rekey a certificate for reasons outside the user's control, i.e. heartbleed.
More to the point, in my arrogant opinion, now that a good, free alternative exists, users in the know should pressure the browser makers to come down a lot harder on companies that let this kind of issue fly. There's no need to work through the CAB bureaucracy when, say, Google and Mozilla are probably a lot more amenable to dealing with bad (be that by ignorance or malice) actors by refusing to recognize their crappily-validated certificates.
Re: StartSSL domain validation vulnerability
#10OK, so this seems like a terrible vulnerability. Does anyone know if (a) StartSSL has been notified and (b) what has been their response. This seems like such a severe vulnerability that publishing it on Blogspot seems too low key. Shouldn't there be a CVE about this?
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.