Apple curl security incident 12604
daniel.haxx.se
daniel.haxx.se
That means that this "feature" by Apple either adds more computation for nothing, or breaks the verification model that is expected.
Neither of these are an expected result.
However I do agree that it’s not the expected result and thus bad behaviour.
Given how Apple generally favour backwards incompatible changes and that this feature is added into curl, this does feel like there is more to this story than Apple is letting on. Perhaps it’s used for developer diagnostic tools or AppStore validation?
Not GP but that is extra computation? It should just fail at that point, instead it's doing computation. According to the result, it's then either 'for nothing', or in order to give the incorrect result.
That's a failure scenario though. If your application is failing a CA check against an authority you've pinned then your infra and application is already broken in ways that the extra computation is meaningless. It is your certificates or application that then need correcting.
In terms of computational overhead (and only computational overhead!), where it matters is the happy path because That's where the overhead of additional computation would affect the performance for your operational infra and thus your users (and we are talking about this specific scenario and not some more generalised discussion about TLS). If you follow the happy path then Apples change, as serious as it is, doesn't affect the behaviour or your application.
I'm not defending Apple here. Whether intended as one or not, this change is a literal backdoor. And it needs to be framed as such. Arguing it as a computation overhead is, at best, missing the significance of this change in behaviour.
So the real problem isn't computational overhead, it's the question of what signing authorities are given permissions to write certificates for your pinned endpoints that wouldn't / shouldn't have had under curl's default code and expected behaviour. ie who now has a backdoor?
If I understand correctly, you're assuming that the user is in control of both running the curl command, and the host it's pointed at? And thus the behaviour in this case is, you argue, arbitrary because you shouldn't let it get there anyway?
I was just thinking of it as the former, say I want to curl -X POST a comment to secretnews.ycombinator.com (not real, as far as I know!) and verify that someone hasn't MITM'd it so that I accidentally disclose my comment on news.ycombinator.com. I don't control either domain, I'm just running a curl command.
This is a problem because it creates a backdoor.
I also disagree it creates a computation overhead because it’s only engaged outside of normal operation (ie when your application is already broken or if someone is intentionally exploiting that backdoor). but the computation argument is more of a distraction from the real problem.
So definitely not defending Apple. I’m saying it’s more serious than just a computation problem.
> That means that this "feature" by Apple either adds more computation for nothing, or breaks the verification model that is expected.
they're saying one of two things happens: you get the wrong result (more severe than amount of computation) or you (because the cert it does have is not in Apple's store either) get the correct result, but wasted cycles doing something that you didn't want it to do and risked getting the wrong result.
Whereas you’re the one barking on about computational overhead.
A company as large as Apple making this particular decision in service of a wider vision to “own user devices, is attributing to Apple a degree of organisational and coordination prowess that is well beyond unheard of in any organisation even one tenth of Apple’s size.
But it’s Apple, right!?
Similarly, some intern at Apple did not authorize this change, write the patch, and then defend the decision when upstream questioned them about it. That requires coordination, which is frankly why this whole brouhaha is offensive. Apple could be working with upstream to close a critical vulnerability, but instead they're defending the merits of a faulty and dangerous fork. That is brazen and irresponsible behavior that requires just as much effort as working together with the community to solve the issue. Even companies a tenth Apple's size can get this right.
CURLSSLOPT_NATIVE_CA
Tell libcurl to use the operating system's native CA store for certificate verification. If you set this option and *also set a CA certificate file* or directory then during verification those certificates are searched in addition to the native CA store.
I'm not too familiar with how the library works internally, but I was imagining something like the above would be possible.
There's nothing curl can do about it.
I'm not saying it's intentional, or malicious. But as a matter of fact it is indeed a backdoor.
If you start adding keys to your users authentication scheme, then you've added a backdoor.
As a multi-protocol lib, curl does not in fact implement all of them directly, instead relying on transitive dependencies which act as "backends" to outsource, in most cases, decoding the low-level bits. For some of the protocols, and for good reason, it incorporates support for multiple alternative libraries.
The downside of that approach is that it is hard, if not impossible, to ensure common behaviour across independent backends which may not cover all of the same features, provide incomplete APIs, or, such as in this case do not provide a way to patch some of its default behaviour. Libressl is not a bit-for-bit reimplementation of openssl, and are under no obligation to mimic its API fully (however convenient that would be for us all).
In such cases, and given the reluctance of upstream to fix it, curl is left with 2 possibilities: drop support for said library, or document the quirk. Given the downside of breaking user code of following the former, it should at least do the latter.
All this being said, I do agree with the main sentiment that this is a flawed approach from a security standpoint of libressl, and there's probably reason to open a CVE, but it should be on libressl.
They just don't care.
He's probably correct here, as far as I can determine in 2 minutes, but "he's correct because it's Daniel" is the worst possible argument.
This reminds me of this old exchange about the history of C (specifically, Eric S. Raymond's "contribution" to it): https://scienceblogs.com/deltoid/2011/10/14/dennis-ritchie-h...
It's about the evaluation of a finding.
Not 'Daniel' specifically, but in general when you're packaging a tool and its author/maintainer(s) contact you about it.
A fair coin can land on heads 20 times in a row, but the odds are not great.
It'd be entirely reasonable for someone to create a script that is meant to only use the internal private CA. When you run this command then you KNOW that you are ONLY talking to an internal corporate resource, because this is an internal corporate CA.
And then apple adds a backdoor the size of domain validation, to this.
Hell, it'd be entirely valid to use a dummy name, and just rely on the fact that it's signed by the corp CA, to establish that you are connecting to a corporate server. Now Apple's added a security vulnerability to that, by breaking this extremely reasonable assumption.
Not cool.
:)
https://en.wikipedia.org/wiki/Debian–Mozilla_trademark_dispu...