When prompting for "postmaster", "hostmaster" or "webmaster", the values in that form should be just those and StartSSL should then put the two together ($MASTER_EMAIL + "@" + $DOMAIN.) They shouldn't assume that the "sendToEmail" value wasn't tampered with or overridden. If the original poster didn't include his screenshots or his steps then I wouldn't believe such a stupid mistake, especially one made by a certificate authority.<p>Back before I found Gandi.net I came across StartSSL (I was looking for basic SSL certifications.) At the time StartSSL's website was horrible, and I mean ugly, it turned me away because it felt so unprofessional. I see now, even with a new flashy website, that they still remain unprofessional (maybe not in their looks, but obviously in their practices.)
> 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.<p>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.<p>The vulnerability is pretty bad, though. Good catch.
Amongst it's repsonse, StartSSL should start logging every granted certificate to a Certificate Transparency log. From now on they need to provide the transparency so that site owners can verify there are no phony certificates being issued for their domains.
This seems to an incredibly basic error for a company trusted to issue SSL certificates.<p>How long has this vulnerability existed? Can we trust <i>any</i> StartSSL certificates? Will they charge for revocation, as they did with Heartbleed?
I do not have appropriate words for this. What a terrible nightmare. And even worse the second time they did this. I mean what kind of company is this? I am seriously shattered that they are so careless with so much responsibility. I never liked the trusted CA system on the web but always thought you would need to be at least some state actor or serious professional in order to be able to get hold of certificates from them without validation. They should all be required to get some real security audit on everything involved, and do it again whenever there is a change or some time passed. Without they should be dropped from the list of trusted CAs. I really do not get how this happened. It is like someone did this on purpose. I am sad now.
Meanwhile, when I tried to use them for a client's domain after actually paying $$$ for business validation I was refused because the names on the WHOIS records didn't match our business name.
This 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.
Now that Let's Encrypt is a thing, there's no reason to do business with these greedy losers.<p>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.<p>More to the point, in my arrogant opinion, now that a <i>good</i>, 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.
OK, 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?
Arguably 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.<p>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.<p>Nevermind, maybe the next bug we see will be in one of the other DV methods, like tricking the validator to access a http uri of your choosing rather than '/.well-known/', for instance. Or authoritative DNS poisoning.<p>[0] <a href="https://news.ycombinator.com/item?id=11321184" rel="nofollow">https://news.ycombinator.com/item?id=11321184</a>
Too bad the author didn't issue certificates for, say, google.com, microsoft.com, and/or mozilla.org. That'd be a more likely way of getting those browser makers to put some restrictions or "sanctions" on them like Google recently did with Symantec.
and this news:<a href="https://www.startssl.com/NewsDetails?date=20160323" rel="nofollow">https://www.startssl.com/NewsDetails?date=20160323</a>
StartCom log all issued SSL certificates to public CT log servers