Most active commenters
  • tsimionescu(8)
  • amluto(3)
  • echoangle(3)

←back to thread

482 points sanqui | 54 comments | | HN request time: 2.865s | source | bottom
Show context
danpalmer ◴[] No.42285229[source]
This is a bad look. I expected the result would be Chrome and Firefox dropping trust for this CA, but they already don't trust this CA. Arguably, Microsoft/Windows trusting a CA that the other big players choose not to trust is an even worse look for Microsoft.
replies(8): >>42285389 #>>42285408 #>>42285431 #>>42285622 #>>42286061 #>>42286142 #>>42286897 #>>42287654 #
1. jsheard ◴[] No.42285389[source]
What is even the point of a web CA that isn't trusted by all of the major players? Is there one?
replies(3): >>42285424 #>>42285444 #>>42285550 #
2. beeflet ◴[] No.42285424[source]
I suppose it allows you to enable third party control and censorship. If you look at microsoft's censorship of bing in china for example, they are more than willing to bend the knee if it means they can get ahead.
replies(1): >>42285660 #
3. tialaramex ◴[] No.42285444[source]
These are generally government CAs, so, typically the situation is Microsoft sold the government Windows, and as part of that deal (at least tacitly) agreed to the CA being trusted, and so every system that's trusting these certificates is a Windows PC anyway, running Edge because the whole point was the government will only use Windows and pays Microsoft $$$.

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.

replies(4): >>42285464 #>>42285561 #>>42285818 #>>42285942 #
4. sneak ◴[] No.42285464[source]
Windows is less popular every year.
replies(3): >>42285533 #>>42285732 #>>42285907 #
5. notimetorelax ◴[] No.42285533{3}[source]
I looked at the graphs at Statista. I don’t think it’s so clear cut. Mobile OSs have pushed it down, but it seem to dominate PC market. Do you have a graph that shows its decline on computers, not mobile phones? Or in absolute unit counts?
replies(2): >>42287363 #>>42287388 #
6. ◴[] No.42285550[source]
7. awinter-py ◴[] No.42285561[source]
what's the state's interest in having their CA built into windows?
replies(7): >>42285580 #>>42285679 #>>42285705 #>>42285808 #>>42285814 #>>42285837 #>>42286935 #
8. tptacek ◴[] No.42285580{3}[source]
States are themselves extraordinarily large IT enterprises, they generally want control of traffic and its transparency or protection, and they are large enough to get arrangements for that, though usually not this particular arrangement.

Large enterprises in the US generally have the same capability, but not loaded into operating systems by default (that is: Walmart's ability to do this on its own network in no way impacts you, who have never worked on that network).

replies(1): >>42285936 #
9. alganet ◴[] No.42285660[source]
As a brazillian, I find this very unlikely.

In 2013, when the same party was in power, SERPRO was tasked with replacing Microsoft in key aspects, such as government email (which was handled by Outlook Server at that time) and operating systems.

The main reason was fear of espionage. So, in reality, we are more afraid of the US spying on us than random internet dissidents.

replies(1): >>42286217 #
10. lazide ◴[] No.42285679{3}[source]
Legitimate, or illegitimate?
11. mnau ◴[] No.42285705{3}[source]
E.g. identity verification. My state has a "qualified" certificate that can be used to sign contracts and basically everything else you can do in-person. When you can transfer you home with that, there are higher requirements on checking the identity of a person who gets the certificate.

That CA is not used for much else and is basically confined to our state. But it has to be in Windows, otherwise no other software could verify the signatures.

See eIDAS and other similar schemes.

replies(3): >>42286944 #>>42288746 #>>42292455 #
12. saghm ◴[] No.42285732{3}[source]
I feel confident in guessing that any net changes in Windows popularity have close to no relation to Microsoft's policies around trusted CA. The number of users who are worried about sketchy certificates being trusted by default are dwarfed by the number of users who don't have any idea what a "trusted CA" is but care about more "visible" things like UI changes, performance, and how hard Windows is pushing Edge and other things they don't want.
replies(1): >>42286103 #
13. Onavo ◴[] No.42285808{3}[source]
So they can mitm their own employees without annoying TLS warnings.
replies(2): >>42286301 #>>42286950 #
14. csomar ◴[] No.42285814{3}[source]
So when they issue their certificates, you don't get that huge red banner? I belong to a small developing country and even with its tech illiteracy it has a CA. Now, of course, because that CA is not trusted by anyone, all government websites are red.
15. efitz ◴[] No.42285818[source]
Windows CA program is governed by requirements like any other CA. Microsoft has ways to provision machines with enterprise CA roots so there is no advantage, and highly visible disadvantage, to adding a noncompliant CA to your trust store. I think that the theory that Microsoft will included it to sweeten a sale has no merit, unless you have evidence.

Most certificate trust stores have some certs in them that are sketchy, eg a bunch of university certs from all over Europe. These are slowly dropping off, presumably because it costs quite a bit to operate a CA in a compliant fashion and get it professionally audited.

Issuing a fake cert is grounds for removal from every certificate trust program I’m aware of, if it can’t be demonstrated that they found what went wrong and have fixed it so it can never happen again.

replies(1): >>42286068 #
16. efitz ◴[] No.42285837{3}[source]
Getting your CA into a trust store means that every machine using that trust store will accept your certs. It’s not really necessary for a government or corporation to have a public CA in anyone’s trust store unless they want to issue certificates that everyone trusts. If they just need their own machines to trust their certificates, they can use the management utilities that come with Windows and with AD to distribute an “enterprise root”, which only their machines will trust. This is how most large companies and governments do it.
17. n144q ◴[] No.42285907{3}[source]
You need to show statistics to prove that, not just throw the statement out there, possibly only based on the vibes on HN.
18. adra ◴[] No.42285936{4}[source]
If you're a large enterprise, then it's trivial to add yourself your own custom CA and save the cost/hassle of needing to deal with outside companies. The tradeoff being you need to manage it yourself vs basically paying this third party company to survive?
replies(2): >>42286218 #>>42287574 #
19. amluto ◴[] No.42285942[source]
The solution seems straightforward: limit the trust in the CA to .BR domains.

[domain name typo fixed]

replies(2): >>42285957 #>>42286002 #
20. bitwize ◴[] No.42285957{3}[source]
.bz is the TLD for Belize. Brazil is .br.
21. kelnos ◴[] No.42286002{3}[source]
IIRC name constraints is very poorly supported by client software, so there are likely lots of clients out there that wouldn't even parse that restriction out of the cert, and happy accept anything singed by the CA.
replies(3): >>42286042 #>>42286555 #>>42290933 #
22. amluto ◴[] No.42286042{4}[source]
I’m not talking about a name constraint — that would need to be part of the root certificate. I’m suggesting that MS add a feature to its root store to constrain the usage of the certificates in the store. IIRC Google’s root store has features like this.
replies(1): >>42286979 #
23. lokar ◴[] No.42286068{3}[source]
IMO, issuing a fake CA for one of the top (and highest risk) domains even once should be the end of that CA (and any other CAs managed by that org)
24. l33t7332273 ◴[] No.42286103{4}[source]
It’s not becoming the users that are the decision makers. A few CTOs could make decisions based on this
replies(1): >>42286249 #
25. serial_dev ◴[] No.42286217{3}[source]
As a non Brazilian, sometimes when a government says a company is spying on its citizens, they mean that they want access, too, to the spying and censoring apparatus.
replies(1): >>42286312 #
26. tptacek ◴[] No.42286218{5}[source]
That's true, but in the bad-old-days of the antidiluvian WebPKI it was somewhat routine to sell big companies CA=YES certs simply to allow them to do this universally without pushing out updates to all their endpoints. It was a terrible, bad practice, and so far as I know it's completely dead now --- except for Microsoft, I guess.
27. saghm ◴[] No.42286249{5}[source]
If the rationale in the parent comment for this behavior is correct, it sounds like a lot of people making the decision to use Windows are doing it _because_ of behavior like this, not in spite of it.
28. throwaway2037 ◴[] No.42286301{4}[source]
To be clear, this is bog standard in all mega-corps now. They have a vendor product that provides HTTP Internet proxy, then they perform MitM to decrypt HTTPS traffic and re-sign/encrypt with in-house issued cert. Then, this cert is auto-trusted as part of all base OS installations. To be honest, how else can mega-corps spy on HTTPS traffic without this MitM tactic? I don't know any other way.
replies(1): >>42287372 #
29. alganet ◴[] No.42286312{4}[source]
I see your point.

Maybe if I was in government I would think the same. Catch criminals before they act, stuff like that (I'm just being the devil's advocate here).

This is a dillema, and the worst kind. The kind citizens know nothing about, so the only possible way to talk about it is to speculate. I am, however, too old to speculate about these things anymore.

30. 8organicbits ◴[] No.42286555{4}[source]
I think support for name constraints is much better now, but I think someone needs to correctly audit it. We need near universal adoption for it to be considered a usable tool.

I researched the issue a little here: https://alexsci.com/blog/name-non-constraint/

31. tsimionescu ◴[] No.42286935{3}[source]
So that they don't depend on anyone else to have proper TLS for their state sites and for companies operating in their state.

Imagine if you don't have a state CA, and your relationship with the USA goes sour, and the USA prohibits all of their major CAs from doing business with your country, including Let's Encrypt. People in your country still use the internet and you still want to protect them from scammers pretending to be local businesses online. So it's important that you as the state can provide CA services and sign those certificates yourself.

Of course, in this scenario you wouldn't want to be relying on Microsoft to help. But the general principle is that any state who can afford it has a strategic interest in having fully self-sufficient Internet infrastructure, including DNS, CAs, IP allocation etc.

replies(1): >>42287706 #
32. tsimionescu ◴[] No.42286944{4}[source]
Why would you want to mix identity verification with the WebPKI? This makes no sense at all. Just because a CA is trusted for web verification doesn't mean it's trusted for identity verification, machine enrollment, or any other purpose. And vice-versa: a CA for identity verification is not in any way trusted for web verification.
replies(1): >>42288754 #
33. tsimionescu ◴[] No.42286950{4}[source]
You don't need a publicly trusted CA for that. You just run an internal CA and install its root certificate on your employees' machines, just like you install VPN software or whatever else.
34. tsimionescu ◴[] No.42286979{5}[source]
The Windows trust store doesn't offer a verification API, I believe it simply lists the trusted certificates so that they can be looked up by verification software. That is, OpenSSL doesn't ask windows "hey, is this certificate with this chain trusted for google.com?" it asks Windows "hey, do you have a cert in the trusted root CAs with this ID? If so give it to me", and then OpenSSL will use that root cert to check if this is the real google.com.

Chrome, which is both the cert store and the client on certain OSs, might implement this limited trust. But Windows can't, except maybe for its own internal services.

Either way, this makes little sense overall. If a CA is trustable, it can be trusted to sign a certificate for any domain. And if it's not trustable, then you can't trust it for any domain. Brazilian companies wishing to use a local CA can own .com domain names, so you'd be preventing a completely legitimate use case. Google almost certainly has a google.br domain, so if the Brazil CA is untrustworthy, they can still be used to attack Google even if you only trust them for .br domain.

replies(1): >>42288755 #
35. flir ◴[] No.42287363{4}[source]
I think that might be a bit of an unfair caveat. People do real work on mobile OSes. They shop and communicate on mobile OSes, and occasionally organise revolutions.

(Although I'm not sure why "Netraft confirms, Windows is dying" is a useful comment here anyway. Windows is a behemoth.)

36. echoangle ◴[] No.42287372{5}[source]
Yes, but normally this is done by making your own CA and installing it into your client devices, not by getting it into every device globally by working with Microsoft.
replies(1): >>42287586 #
37. lysace ◴[] No.42287388{4}[source]
https://gs.statcounter.com/os-market-share/desktop/worldwide...

There's a clear but slow trend on desktop.

Jan 2009: 95.4% Windows

Jan 2016: 85.2% Windows

Jan 2024: 73.0% Windows

In e.g. US it's going down faster, desktop market share now at 62%:

https://gs.statcounter.com/os-market-share/desktop/united-st...

38. hulitu ◴[] No.42287574{5}[source]
> If you're a large enterprise, then it's trivial to add yourself your own custom CA

The big CA have their own "Boy club". See Ahmed used cars and certificates.

39. hulitu ◴[] No.42287586{6}[source]
> Yes, but normally this is done by making your own CA and installing it into your client devices, not by getting it into every device globally by working with Microsoft.

Google, Facebook, Microsoft, Apple, Cloudfare, Godaddy, Lets encrypt. They all "work with Microsoft".

replies(1): >>42287643 #
40. echoangle ◴[] No.42287643{7}[source]
Does any employer get a certificate from any of the CAs you listed to MITM their internal networks?
replies(1): >>42288144 #
41. withinboredom ◴[] No.42287706{4}[source]
This seems like a matter of signing a certificate signed by an actual CA with your own CA as well. If the relationship sours, you still have your own CA to vouch for it.
replies(1): >>42294433 #
42. 3np ◴[] No.42288144{8}[source]
The listed companies are employers. I think they all have self-managed CAs.
replies(1): >>42288757 #
43. Muromec ◴[] No.42288746{4}[source]
You don't really need your CA doing eIDAS in the system root. This scheme works as a closed system where you need eIDAS app to produce the artifact and another eIDAS app to verify it, when both have their own non-system root.

Ukraine for example successfully operates their own eIDAS-like scheme where everything is based on DSTU+GOST algos not supported by any operating systems a major libraries, the certs are signed by the government root and it doesn't leak into web pki.

44. Muromec ◴[] No.42288754{5}[source]
I think the idea was to use client certs for strong authentication on the government web services, which didn't rally took off, except maybe in Estonia.
45. nordsieck ◴[] No.42288755{6}[source]
> Either way, this makes little sense overall. If a CA is trustable, it can be trusted to sign a certificate for any domain. And if it's not trustable, then you can't trust it for any domain.

That's a silly position to take.

When I lived with roommates, I trusted them. But I also locked my bedroom when I went out. Because there's no good reason to rely on trust when you don't have to.

replies(1): >>42288962 #
46. echoangle ◴[] No.42288757{9}[source]
Yes, but surely the listed companies don't use their public and globally trusted CAs to MITM their internal networks. I hope they have another internal CA to allow them to MITM their internal Network.
47. tsimionescu ◴[] No.42288962{7}[source]
It is given the design of the PKI and DNS. There's no relation between CA and the TLDs on the certificate being signed.
replies(1): >>42290581 #
48. amluto ◴[] No.42290581{8}[source]
This is true, but it’s an old design that has been (in my opinion at least) obviously wrong since the very beginning of HTTPS. Microsoft could easily fix it, at least for clients that can manage to use an updated API.
replies(1): >>42293809 #
49. cvalka ◴[] No.42290933{4}[source]
As of 2024, they are well supported.
50. estebarb ◴[] No.42292455{4}[source]
It doesn't have to be. In Costa Rica the Central Bank has their own CA for the same purpose. We need to download the certificates ourselves. It is inconvenient, but an error by that CA won't propagate to the rest of the world.
51. tsimionescu ◴[] No.42293809{9}[source]
Microsoft has nowhere near the power to change the PKI and/or DNS. And it's not an API problem, it's a problem of where companies go to get their legitimate certs. If there are a lot of companies getting their certs for international TLDs from country CAs, or country TLDs from international CAs, then you have to wait for huge systemic changes before enforcing any kind of TLD-CA relationship.
replies(1): >>42297769 #
52. tsimionescu ◴[] No.42294433{5}[source]
That doesn't achieve anything at a country level if trust stores don't include your CA directly. A country can't just push an update to all its citizens' computers to switch CA, it has to plan ahead for such eventualitites.
53. account42 ◴[] No.42297769{10}[source]
Microsoft has absolute power about the restrictions they support in their root store.
replies(1): >>42300019 #
54. tsimionescu ◴[] No.42300019{11}[source]
That's irrelevant. My whole point is that such restrictions go against the whole design of the PKI, at a systemic level. It's actively harmful to try to restrict trust in a CA to certificates for a certain TLD, because the two don't have any relationship whatsoever, by design.

It would be like restricting trust in a CA to certificates for sites whose name starts with a certain letter. It's exactly as meaningful from a Web PKI perspective.

Could Microsoft make it so that Windows only trusts this CA for certificates on domains whose name starts with a "b"? Sure. Would it help with anything? No. Would it be actively harmful to companies whose name starts with A that are using this CA? Yes. The same thing is true for domains whose name ends in .br.