This is pretty bad. Someone circunvented the ban on emitting public certificates but also disrespected Google's CAA rules. Hope this CA gets banned on Microsoft OSes for good.
If a CA can be convinced to issue a server certificate for google.com, would you feel very comfortable trusting their contract/deed/... signing certificates?
Microsoft have a terrible reputation for security, which they've earned through doing stuff like this.
It's not likely to get any better any time soon either, as their trajectory is still pointed downwards.
Why bake it into everybody else's Windows? If you make say a Brazil Government-only Windows which trusts this CA instead, I guarantee somebody crucial in Brazil will buy a 3rd party Windows laptop independently and it doesn't work with this CA's certificates and that ends up as Microsoft's problem to fix, so, easier to just have every Windows device trust the CA.
They'll have an assurance from the CA that it won't do this sort of crap, and that's enough, plausible deniability. Microsoft will say they take this "very seriously" and do nothing and it'll blow over. After all this stuff happened before and it'll happen again, and Windows will remain very popular.
Would it be fair during that time if I asked you to hold your PRs, bug tickets and work in general because we're on paid leave?
On-call rotation exists for those reasons. Otherwise, all countries would need to respect all other countries holidays.
In fact, we're not even aware of most US holidays. It is likely to be a coincidence.
A MitM attack can be easily carried out by someone in control of an ISP, or someone in control of a WiFi network. So, if you trust your ISP and your WiFi network, realistically you have nothing to worry about.
The reason that this issued certificate could allow an attack like this to happen is because all websites nowadays use HTTPS connections, and certificate authorities are the entities that tell your web browser that certain certificates are legit. They confirm that a website is actually that website.
If you visit some website and someone tries to do a MitM attack between your web browser and that website, the web page should fail to load because if they try to change the certificate, your web browser should reject it because it is invalid.
The bad certificate was caught, and caught quickly. The system works.
It is a bit like if airport security catches someone who wanted to bomb a plane. Yes the immediate gut reaction is that is terrible, but if you think about it for a bit its actually reassuring, since its proof the safe guards worked.
I'm not a Windows user, but I have to wonder if there's a way to use the Chrome trust store on Windows/Edge. I can't imagine trusting Microsoft's list.
> Microsoft seems to be casual about trusting CAs
Are you aware of the big hack on Netherlands govt-approved CA? Read about: DigiNotar. My point: That was a widely trusted CA that was hacked after the root CA cert was added to most browsers / OSes trust stores. So would you say that MSFT was "casual" about trusting DigiNotar root CA? How about Mozilla Firefox? I doubt it.
A challenge for Microsoft is that they aren't transparent in their inclusion decisions, so we can only speculate why they chose to trust this CA. What gives you confidence that Microsoft is doing careful vetting?
In stark contrast, Mozilla publicly and extensively documented why they didn't trust this CA [2].
I don't see any reproducible builds for Microsoft Edge. Therefore, your statement is an assumption and nothing more. We can not trust Microsoft more because they are more proprietary.
I don't think those two things have anything to do with each other. Living in Redmond for my entire life has mostly shown me that MS owns one of the best and most lucrative sales orgs and sales channels in the world. That sales channel means they can sell to governments better than nearly anyone one the planet, no matter what their security practices are like.
I'm sure that Microsoft carefully ensure they're paid for all CA additions.
Given their monopoly there is no incentive for vetting.
Are you? Why? For Mozilla the vetting process takes place in public, that's one purpose of m.d.s.policy so we can see what is or is not done and draw our own conclusions.
Each of the proprietary trust stores has an opaque process which unless you're a CA applicant you don't even know what they're asking for, much less what (if anything) they do with it.
These are for-profit companies, and this is a cost centre. The cheapest possible thing they could do is piggy back entirely on the public Mozilla process (which of course for this CA would mean rejecting)
The next cheapest option would be to allow senior management to override Mozilla's decisions for, you know, commercial reasons.
And yes, it would certainly be possible for them to have their own teams every bit as effective as the public process but entirely made up of employees and contractors. Weirdly though, although it's easy to run into people who worked for say, the Windows OS team, or XBox team, or Azure team, you don't run into ex-Microsoft opaque CA process people. One reason might be that they're all career professionals, never leave, never get downsized, maybe there are dozens of them. But the more likely reason is they do not exist.
Right now, a CA can issue a certificate for any public key and domain they like. A rogue trusted CA can intercept all traffic.
If a certificate also included a signature by the owner of the public key signed by the CA (using their private key, signed over the CA signature), then a CA would no longer have this ability.
What am I missing?
The chain of trust for all the certificates in your example is established by trusting the rogue CA root certificate. The CA (or a bad actor who misled the CA through real-world fraud) could be the “owner” of the key pair you’re trusting for the second signature.
Infrastructure and processes for key distribution and revocation. Reusing the existing PKI infrastructure used for CA trust roots won't handle it. Perhaps public keys/certs could be distributed over DNS, like for DANE (or maybe even using DANE)?
Not saying it can't be done, just to point out how it's not trivial and requires buy-in from incumbents across the ecosystem.
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
I like your general idea of improving the status quo by adding decentralized/self-managed trust on top of/alongside the existing centralized PKI. Could be a stepping stone towards something more systematically resilient.
I'm not sure it would make much difference to most of the existing PKI infrastructure though. CAs wouldn't see any difference. For example, currently this is what happens:
1. Owner: generate CSR and send to CA 2. CA: validates owner identity, signs cert and returns cert to owner.
All we would then add is:
3. Owner: signs cert with own private key and uses it.
As far as I can see, the only other changes required would be to clients (so they could reject non owner signed certs), and maybe some revocation stuff.
1. https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...
I think the parent is suggesting that users should be able to tune their trust stores. I'd imagine that trusting only the CAs that are in all the major trust stores (Google, Microsoft, Mozilla, and Apple) would be a reasonable policy. Few websites would choose a CA that falls outside that group.
Admittedly DNSSEC has issues to put it mildly, but it does serve as a counterexample to your claim.
The problem is between the keyboard and the chair. Users struggle to understand SSL already. Browsers decided that the distinctions between EV, DV, and OV were too complex and hid them. What will your grandmother think when she opens up her bank and your browser plugin shows a greenish yellow trust indicator because the cert is trusted by Google, Apple, and Microsoft, but not Mozilla?
Unfortunately, trust is binary. Your grandmother click on the bank bookmark and either sees her banking websites or sees a scary warning.
So an employee can type in google.com and check any boxes about did you verify this is the correct name and it's OK to issue, and then they hit issue and the certificate is minted, just like that.
Why google.com? Well, if you're testing something, say a web browser, what web site comes to mind? Maybe google.com? Doesn't work. Oh - the cable is unplugged. Doesn't work. Wait, this checkbox isn't checked, try again. Aha, now it works... Oops we issued a certificate for google.com
This is a "Never" event, there should be countless things in place to ensure it doesn't happen. In practice, just like safety guards on dangerous machinery, too many people just can't be bothered with safety, it's a cultural issue.
† Let's Encrypt famously does not. As part of the Mozilla application process they need to show their certificates expire properly, usually people either manually issue a back-dated certificate which has expired already, or they manually issue one with a deliberately short lifetime to expire. Since they can't issue manually Let's Encrypt obtained an ordinary certificate from their own service and then waited ninety days for it to expire like a fucking boss.
ie: Brazilian government demands Microsoft to grant them MITM access from Windows machines, in order for the right to do business in the country.
Governments are usually sneaky with their evil plans. It is simply too hard to get away with something like that to make it a viable. Case in point, the fact you are reading about it on hn.
[1] https://alexsci.com/blog/ca-trust/#government-control-of-cas
And without DNS pointing google.com to that IP address, it's pretty useless.
The brower (possibly only edge) and system would show the connection as being secure.
The "blast radius" is limited to Microsoft since they are the only ones that trust this particular certificate authority. Your non-Microsoft browser won't trust these certs. Your non-Microsoft OS, Java program, etc. etc. won't trust these certs.
The system is deeply flawed, which is something I realized fifteen years ago when I was put into a situation where I had to use online banking. (Had to being the nearest branch of any bank was an hour long flight away, though there was an ice road you could use in the winter.) One of my first questions of the bank was: who issued their certificate. They didn't have a clue what I was talking about. I suppose I could have pushed the question until I found someone who did know, but I also realized that a random person asking about security would be flagged as suspicious. The whole process was based upon blind trust. Not just trust in the browser vendors to limit themselves to reputable CA, but of the CAs themselves and their procedures/policies, and who knows what else.
…what did the certificate say?
> whole process was based upon blind trust
If I offer someone a ride and they start quizzing me on what differential I’m driving, I’m going to ignore them. That isn’t requiring blind trust, it’s just the wrong place and way to get the information you’re asking for.
When I was in schooling getting filled in on Web of Trust, I about ground that particular day's class to a halt because I couldn't imagine the world was that cavalier on such a thing.
Lo and behold, I realized shortly afterward it absolutely was the case, and there was nada I could do to change it except figure out how to get normal people universally fluent and invested in basic cryptography so they could manage their own trust networks. You can imagine how well that's gone.
(Assuming certificate pinning doesn’t exist, which was the case 10 years ago and is true now, too)
If the bank is unable to tell me which CA they use through a trusted channel, the only way I could tell if there is a problem is if the CA changes.
Yeah, this is after the certificate was issued, and my guess, used.
Also, has anyone tried to look up CT logs lately? I tried. Can get maybe a single FQDN if you look, but trying to do wildcards or name-alikes, nothing worked. Most of the CT searching websites were straight up broken. Clearly nobody is actually looking at CT logs.
CAs are a joke. There's a dozen different ways to exploit them, they are exploited, and we only find out after the fact, if it's a famous enough domain.
We could fix it but nobody gives a shit. Just apathy and BAU.
crt.sh allows you to subscribe to an RSS feed for wildcard searches. We map those into a slack channel for infrastructure advisory alerts. You can also setup more aggressive alerts if something shows up unexpectedly.
It's an incredibly handy service.
We really can't fix it. You try and coordinate updates across all major (and most minor, and outdated) OSs, and websites around the world, amateur & professional, from the mom-and-pop store who don't understand any of this, to the big bank that'll take 3 years of procedure.
I have friends who work in the CA field (on the OS side). The level of alcoholism and turnover in the field is... higher than average.
Is anybody else surprised at this point?
Multiple RCEs and critical CVEs cannot be fixed because Microsoft "lost" the source code. So they disclosed those RCEs but without any solution or fix.
(Not kidding, sadly, look it up, there also have been occasional binary patches because of the same reason)