Hacker News (curated)new | past | comments | ask | show | jobs| show hidden

To be honest, git deferring to the OS is the right thing to do. It's macOS that's the problem, not git.

"Ten days later, macOS and all applications that rely on it still trust the compromised eMudhra certificates" would have been a better title.



Yeah, definitely: having lots of separately distributed and likely rarely and unreliably updated trust roots would not inspire a lot of confidence.

In turn the centralized OS authority needs proper maintenance otherwise it's just as bad if not worse, because of the larger blast radius

I don't know about worse. Imagine a world where there is no OS authority, each app does their own. Do you think all important apps would be updated in 10 days, including auto-updates?

Apple fucked this up, but I really don't think the situation is "as bad if not worse" than if MacOS just didn't do this.


It makes no sense to imagine this hypothetical scenario and compare it to reality, you have to imagine a similar world with a OS authority, but it only gets updated every 6 months. Which is worse in the worse case? I'd say the one with the lower blast radius.

But this abstract exercise is only to highlight the importance of Apple getting its shit together, because such a scenario exists with Windows and the culture of downloading exes and msis and it's honestly way worse than having a central but responsible authority.


Isn't that the world that Docker gives us, basically?

Yes - difficulty in shipping security updates to a hundred different container images, each of which is vulnerable in their own slightly-different way because they all decided to ship an OS alongside their app - is one of the top criticisms of the docker way of doing things

What kind of psychopath ships 100 distinct container images? I mean, maybe if you’re talking about all of Netflix or something, but… I suspect even they have base images that they use as a starting point.

There’s very little actually running in a docker container. ca-certs may actually be an exceptional case though, since it’s not code that’s running but a kind of data.

It’s not like if you use an Ubuntu image for a node.js app that you get PHP too and have the PHP vulnerability present in your web app.


You still have to rebuild each Application Container with new CACert and deploy them. Depending on teams are working, that can be disruptive.

I would say that if rebuilding your docker containers is a disruptive process, that is a process issue.

I would agree but it doesn't change the fact that many companies do not have CD and have processes that must be followed for rollouts.

It's same problem we have when libraries get massive security vulnerabilities. Updating them is not always as easy as many would like.


Just run it in kubernetes and mount the certificates with trust-manager

> Imagine a world where there is no OS authority, each app does their own.

That's the world we live in now thanks to Google and Mozilla.


Remember this is the same company that demands they're the only ones who can possibly decide what software their users get to install.

So many Java trust stores never seeing this update.

Yes, but the irony here is that Apple used to (or perhaps still has) forbidden using other HTTP(S) clients in iOS apps (or perhaps Appstore in general) than the built-in out of security concerns like this would address by using 1 central storage instead of multiple ones were one won't get timely updates.

I could swear I saw that title here earlier today almost verbatim maybe even referencing the same link.

Can confirm I saw the same thing

Wouldn’t be true either. Stuff that uses the OS certificate store (that you can view in the keychain) won’t trust the compromised certs.

Correct. I Googled to ask about location of certs on disk: /etc/ssl/cert.pem

Is it possible for users to remove the eMudhra certificates themselves? I have no experience with MacOS, so I don't know if certain actions are prohibited. To be clear: I am not suggesting that normies do this! Rather, I am asking if it is possible for highly skilled users.




It's pretty trivial to do this. Before the official patches were out on other platforms I did it on a few machines.

You can have it "both ways" if you want, but it quickly becomes very muddy - defer to the OS, but override the deferral in some cases.

Certificate management is fifty kinds of all messed up - and in THEORY everything is designed perfectly and properly, in practice it's all bandaids on bandaids that nobody cares about as long as "things mostly work".


This doesn't have the vibes of something that's designed perfectly even in theory. This more has the vibes of "this was the least worst option"

If you look at the FULL design, it's actually pretty good - things like https://en.wikipedia.org/wiki/Certificate_revocation_list CLRs have actual thought behind it - but I know of no system that actually IMPLEMENTS everything, for various practical reasons.

So from a spherical cow perspective, it's well-designed; from a "this has to work in the real world with real things and people" it's ... workable by violation of the design all the time.


I would argue for anything security - if there is a difference between how it works in theory vs in practice - then the theory is flawed. Physics gets to have theory/practice distinctions, but engineering doesn't because the bridge can't fall down.

Exactly, and it's a very real problem with the IETF-way of building things, and why "this is what Chrome does, copy it" becomes the real standard.

Trust relationships are fundamental even in the most abstract view of the Web PKI and without the band-aids of Certificate Transparency etc. that trust relationship is: Some random commercial entities that are completely independent of the DNS, make fully trusted statements about the validity of DNS record ownership. It's bonkers to the core. If someone would design it from scratch, of course the domain registrars would be the ones issuing the certificates via their established relationship to the customers, and they would only be able to issue them for the domains they are responsible for. And no: DNSSec does not solve the same problem and is a tragedy all of its own.

I guess we are going to learn how important secure communication is based on the stories (or lack of stories) about how it is being exploited in the wild.

Exceeds character limit, but admins can modify if there’s a better shorter title.

> To be honest, git deferring to the OS is the right thing to do.

Tangentially related: I fucking hate so much that browsers now all have their own DNS resolvers and caches, it's just Another Fucking Thing to debug when you're working especially on locally hosted stuff. This is not a browser's job, it's a task that should fall to the OS.


It is super annoying especially since it's not even "browser has its own DNS and cache but uses your name servers" - more and more "browser bypasses all your shit both on the OS and the network and uses DNS over HTTPS to do God knows what".

Wait, did I miss this? Can you share details on what browsers started doing this?

"In May 2020, Chrome switched to DNS over HTTPS by default."

Welcome to hell. https://en.wikipedia.org/wiki/DNS_over_HTTPS

(My current chrome reports no at https://one.one.one.one/help/ so maybe I changed it or maybe the default's different now)


Can confirm, Firefox did this forever ago. Become my ritual during a rebuild to turn DNS over HTTPS off because it fucks everything up.

Edit: Found it, February 2020: https://blog.mozilla.org/en/firefox/firefox-continues-push-t...


> Become my ritual during a rebuild to turn DNS over HTTPS off because it fucks everything up.

Out of curiosity, what are some of those things it messed up for you? And what kinds of builds is it affecting?


Like I said, internal DNS. I have my own DNS server with a small set of records for my own internal sites, mostly automation tools alongside the websites I've built and maintain for small businesses near me. The latter are the easiest to explain, for example, if I built joescoffee.com I wouldn't work in production obviously, I'd work on a copy hosted on my local server at joescoffee.myhouse.com, make my changes and then push that code live. Because Firefox and Chrome (and likely others) roll their own DNS server though, I have to configure that separately, because while my machines all get their DNS from the DHCP leases I've already configured which point all DNS queries to my internal DNS server, DNS over HTTPS bypasses that and contacts public DNS servers directly.

And like, I don't need that. My DNS server is properly maintained and queries those exact same servers itself when you request something like google.com or apple.com. Putting a separate friggin DNS query AND cache in a browser is just more trying to protect people from themselves IMO, and introduces this weird issue where you can't hit an internal site in Firefox, even though you're running `nslookup` on your freaking computer, and it's giving you the proper IP address. And paradoxically putting the IP address in makes the browser find it when the domain you can see correctly resolving in terminal isn't resolving in the browser is fucking obnoxious.

It also would render a pihole useless because Firefox despite the PC's DNS not resolving ad provider's names, WILL resolve them, ensuring an attack vector for malware remains wide open even if you've tried to close it.

And while I'm bitching about this: STOP DEFAULTING EVERY CONNECTION TO HTTPS. Any properly configured website is going to do this anyway, the browser also doing it, again, just annoys the piss out of anyone trying to host stuff locally because why the fuck would I get certificates for servers that aren't even exposed to the damn Internet!?


Fair enough, carry on.

Indeed, it makes it harder to block addictive sites like this one in HOSTS :)

That too lol



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact | github