I find this entire situation kind of baffling: Apple successfully revoked trust in the compromised intermediates and also in the root CA that issued them via Security.framework (or wherever their root program actually gets stored), but they’ve failed to do the same for the CA bundle that much of their non-graphical userspace uses. Instead users are just left to run shell commands to patch it manually, which I assume the majority won’t (if they even become aware of this support page).
I think Homebrew’s curl actually uses Homebrew’s own CA bundle by default. It can use the SecTrust APIs but those aren’t the default because they’re deprecated by macOS and don’t support TLS 1.3. I think the same is true with the built-in curl, so it boils down to Apple just not shipping their own CA bundle update for whatever reason.
Yes, I was just thinking how bizarre it is to have an article that acknowledges the issue and then encourages manually editing the cert file instead of shipping an update to users!
Can you link to where it says that they're deprecated? (I don't think they should need to support TLS 1.3... they're just for validating the certificates you get from the handshake, right?)
I think you could use the SecTrust APIs for path building only but that isn’t how curl uses them currently, I believe it uses them for the entire TLS stack. The curl maintainers probably have more context on that decision and why it makes sense for them.
I think SecTrust is not deprecated and can be used without SecureTransport. I should dig in and see if I can offer curl a patch that does that for other TLS APIs. I think that'd be useful and would avoid this specific problem.
Depends on the APIs. But yeah, the more precise thing for me to say would be that curl uses Secure Transport along with the SecTrust APIs, and the former is 100% deprecated (and is where the TLS 1.2 restriction comes from).
That was what I thought too, but macOS has had “rapid security release” functionality for the last few years. In principle they should be able to ship this via an RSR, which doesn’t even necessarily require a reboot.
Apple doesn’t provide guidelines for their their RSR process, but something this severe still doesn’t qualify. What that process is for is to push changes where users devices are actively being exploited in a destructive way.
The RSR process is a highly risky action, where the potential cure make be worse than the sickness.
Aside from some early RSR tests (which almost certainly received extensive testing), there haven’t been any in years.
Think of it this way: in the wild zero day RCE kernel mode exploit that affects all iOS devices.
I mean, this is a complete break in the Web PKI. It’s tantamount to RCE for development flows, of which a significant percentage of Apple customers perform daily/constantly. And the roots in question have been safely removed by Apple everywhere else, just not in this specific bundle.
I don’t have an opinion about whether Apple should do it as an RSR or not, but it absolutely qualifies as something that needs to have been fixed yesterday.
I don’t think so, I think it’s limited in size and complexity. For example I don’t think it can be used to deploy most kernel changes, although I might be wrong about that. Modifying the CA bundle is the kind of thing that should be within its capability, though.
I think the fact that that bundle is in a spot protected by System Integrity Protection means it would require a system reboot. And I thought that was the line for the rapid release patches, but I'm not certain of that.
Wait Apple STILL hasn't blocked the certs other than in some GUI apps??
Xcode Command Line Tools — like curl and git — check certificates against /etc/ssl/cert.pem and can still accept these certificates until a future software update.
Why the hell hasn't that "future software update" already shipped?
I had macOS on my work laptop for a few years, and I gotta say, as a developer, the experience left me feeling like a second-class citizen. Compared to pre-WSL Windows, though, at least I was a citizen!
WRT the cert bundle stuff: Makes me think deprecating Secure Transport might have been a mistake if their LibreSSL build won't support the system certificate store and modifying non-Apple world things to support Networking.framework is highly invasive (as curl figured out).
WRT the cert bundle stuff: Makes me think deprecating Secure Transport might have been a mistake if their LibreSSL build won't support the system certificate store and modifying non-Apple world things to support Networking.framework is highly invasive (as curl figured out).
Go has its own TLS stack but it uses the “platform verifier” on macOS. I wonder how they do it.
yossarian | 21 hours ago
I find this entire situation kind of baffling: Apple successfully revoked trust in the compromised intermediates and also in the root CA that issued them via Security.framework (or wherever their root program actually gets stored), but they’ve failed to do the same for the CA bundle that much of their non-graphical userspace uses. Instead users are just left to run shell commands to patch it manually, which I assume the majority won’t (if they even become aware of this support page).
craigstuntz | 20 hours ago
What is doubly baffling is that homebrew curl does verify through SecTrust. It’s the version that Apple itself distributes which doesn’t.
yossarian | 19 hours ago
(I’m one of Homebrew’s maintainers.)
I think Homebrew’s curl actually uses Homebrew’s own CA bundle by default. It can use the SecTrust APIs but those aren’t the default because they’re deprecated by macOS and don’t support TLS 1.3. I think the same is true with the built-in curl, so it boils down to Apple just not shipping their own CA bundle update for whatever reason.
misty | 10 hours ago
Yes, I was just thinking how bizarre it is to have an article that acknowledges the issue and then encourages manually editing the cert file instead of shipping an update to users!
craigstuntz | 17 hours ago
Hm, I saw this on Daniel Stenberg's mastodon and presumed the claim was correct. I don't have any insight here beyond that.
hoistbypetard | 17 hours ago
Can you link to where it says that they're deprecated? (I don't think they should need to support TLS 1.3... they're just for validating the certificates you get from the handshake, right?)
This is where I'm looking.
yossarian | 13 hours ago
I think you could use the SecTrust APIs for path building only but that isn’t how curl uses them currently, I believe it uses them for the entire TLS stack. The curl maintainers probably have more context on that decision and why it makes sense for them.
hoistbypetard | 10 hours ago
I think SecTrust is not deprecated and can be used without SecureTransport. I should dig in and see if I can offer curl a patch that does that for other TLS APIs. I think that'd be useful and would avoid this specific problem.
mxey | 17 hours ago
How would SecTrust support TLS 1.3? Isn't it solely about certificate verification?
yossarian | 13 hours ago
I was using it as a shorthand for Secure Transport, which is the deprecated TLS stack on macOS (including X.509 path building).
mxey | 12 hours ago
But it doesn’t seem like SecTrust on its own is deprecated.
yossarian | 11 hours ago
Depends on the APIs. But yeah, the more precise thing for me to say would be that curl uses Secure Transport along with the SecTrust APIs, and the former is 100% deprecated (and is where the TLS 1.2 restriction comes from).
mxey | 20 hours ago
My best guess is that they cannot change that CA bundle without releasing a whole OS update.
yossarian | 19 hours ago
That was what I thought too, but macOS has had “rapid security release” functionality for the last few years. In principle they should be able to ship this via an RSR, which doesn’t even necessarily require a reboot.
Hellion | 10 hours ago
Apple doesn’t provide guidelines for their their RSR process, but something this severe still doesn’t qualify. What that process is for is to push changes where users devices are actively being exploited in a destructive way.
The RSR process is a highly risky action, where the potential cure make be worse than the sickness.
Aside from some early RSR tests (which almost certainly received extensive testing), there haven’t been any in years.
Think of it this way: in the wild zero day RCE kernel mode exploit that affects all iOS devices.
yossarian | 8 hours ago
I mean, this is a complete break in the Web PKI. It’s tantamount to RCE for development flows, of which a significant percentage of Apple customers perform daily/constantly. And the roots in question have been safely removed by Apple everywhere else, just not in this specific bundle.
I don’t have an opinion about whether Apple should do it as an RSR or not, but it absolutely qualifies as something that needs to have been fixed yesterday.
mxey | 17 hours ago
Can that be used to push any arbitrary change?
yossarian | 13 hours ago
I don’t think so, I think it’s limited in size and complexity. For example I don’t think it can be used to deploy most kernel changes, although I might be wrong about that. Modifying the CA bundle is the kind of thing that should be within its capability, though.
hoistbypetard | 10 hours ago
I think the fact that that bundle is in a spot protected by System Integrity Protection means it would require a system reboot. And I thought that was the line for the rapid release patches, but I'm not certain of that.
yossarian | 8 hours ago
I just checked and this CA bundle actually isn’t protected by SIP. You can modify it with a normal elevated shell and it takes effect immediately.
(I agree that it would be another story if it was SIP’d!)
hoistbypetard | 6 hours ago
Thanks for checking that. I'm kind of shocked that it's not SIP'd. Absent that, I'm surprised they didn't use their RSR feature!
msangi | 20 hours ago
Likely. What's odd is that they could have sent out an OS update and they choose not to.
mort | 18 hours ago
Wait Apple STILL hasn't blocked the certs other than in some GUI apps??
Why the hell hasn't that "future software update" already shipped?
mxey | 17 hours ago
Some? It's blocked in everything that uses the native Mac APIs.
mort | 17 hours ago
Which apparently none of their command line stuff does
mpolden | 18 hours ago
What? This is written as if there aren't millions of developers (and their agents) out there using command line tools on a Mac every single day.
zmitchell | 14 hours ago
It's written as if developers aren't the only people who may find themselves reading this article that doesn't have "for developers" in the title.
cos | 16 hours ago
I had macOS on my work laptop for a few years, and I gotta say, as a developer, the experience left me feeling like a second-class citizen. Compared to pre-WSL Windows, though, at least I was a citizen!
nelson | 14 hours ago
Perhaps there are fewer developers using their Mac for command line work now.
agwa | 17 hours ago
Really weird that removing the AAA root is labeled "optional" since if you don't remove it, then doing the other steps is pretty much pointless
calvin | 18 hours ago
WRT the cert bundle stuff: Makes me think deprecating Secure Transport might have been a mistake if their LibreSSL build won't support the system certificate store and modifying non-Apple world things to support Networking.framework is highly invasive (as curl figured out).
mxey | 17 hours ago
Go has its own TLS stack but it uses the “platform verifier” on macOS. I wonder how they do it.
edit: https://github.com/golang/go/blob/master/src/crypto/x509/internal/macos/security.go