Bug hunter tricked SSL.com into issuing cert for Alibaba Cloud domain in 5 steps Certificate issuer SSL.com’s domain validation system had an unfortunate bug that was exploited by miscreants to obtain, without authorization, digital certs for legit websites. With those certificates in hand, said fraudsters could set up more-convincing malicious copies of those sites for things like credential phishing, or …
With Whois based DCV killed off at the start of this year, I think it's time the CA/Browser forum got serious with removing the other flaky forms of DCV. There's still a couple of email based DCV methods, including the one in this article. The most ridiculous IMO is emails to a 'well known' address which may not be that well known by most ppl and thus vulnerable to abuse.
CAs arent obliged to support these dodgy DCV methods, but they do, because if someone wants to pay, who are they to say no? After all it might delay a customer migrating to an automated DCV method. down that path lies Let's Encrypt and damnation (also known as zero cash).
nevertheless this particular issue appears to be just plain sloppiness on the part of SSL.com.
There's absolutely no reason that we can't operate on the same system as SSH keys where when you first connect to a website, it presents a key, asks you if you wish to accept it, and then it's expected that that website retains that key and properly signs any replacement in perpetuity (or else the browser presents another warning which tells you that it's changed and do you want to accept the changes?).
The whole concept of CA's is basically a nonsense in the modern age. I should be able to publish keys inside DNS via a secure DNS mechanism, and that's WHAT MY ENCRYPTION USES. Anything different, it gets flagged / blocked.
We already do this in part with CAA records (where we say "Hey, only GoDaddy can issue a cert for me), and DKIM ("Hey, this is my email signing key"), so I don't understand why HTTPS is any different as all it's doing is verifying that the connection we've already established to the computer which we're told hosts the domain is secure.
It's time for a revamp, and the entire CA market can go do one. And while we're there, why are code-signing certificates "special" when we could just tie them to a domain in exactly the same way?
You have to look at who was involved in designing the system and what their goals were.
That all CA's can issue a 100% valid certificate for the exact same DNS domain name does not happen by accident - That was a design requirement. Why was it done, to make the ability to man-in-the-middle simple to allow access to the pain text. It is probably a "legal intercept" requirement.
Destroyed by the presence of CAA records, certificate pinning and the registries of issued certificates and their history.
It may have been the ORIGINAL intention, many, many years ago but even that is dubious. It's certainly not now.
And anyone who wants to intercept (e.g. China) don't really bother with such things, they just forcibly replace your certificate with theirs and proxy your traffic through their systems anyway. They're in control of the DNS, they don't need to care about the TLS certificates (which are inherently reliant on DNS being authoritative).
But actually it was done so you're not tied to one CA, a competitive measure, and very useful in the early days when Internet companies would just disappear overnight leaving you no recourse.
The fact is, it's just not necessary any more whatever the reason it was present in the first place, but it's a billion dollar industry that could die overnight (I believe LetsEncrypt has really knocked it for six, at least in the experience of everyone I know who has replaced myriad expensive and wildcard etc. certificates with free ones that just auto-renew).
