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.