Which, without some form of certificate pinning, could still be MITM'd. At least if there's a catalogue of hashes for everything it downloads (hard-coded or configurable by the user, latter preferred) then at least it can verify the right files are being downloaded regardless of source.
Apple Internet recoveryOS images are served over plain http, on purpose. The macrecovery.py script used by Quickemu uses http¹, though the server supports https.
> When the internet recovery and diagnostic modes were added to Mac computers in 2011, it was decided that it would be better to use the simpler HTTP transport, and handle content authentication using the chunklist mechanism, rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmwareʼs attack surface.
Well that's a matter of trust as well, isn't it? I would assume that even if it's user configurable, the app itself should still ship with an up to date catalogue whenever a new release is made. After all you're already trusting the app itself at that point.
If you are having your SSL connection to Apple MITMed, then you have much bigger problems. Ones like "why do you have a malicious root cert in your keychain?!"
> without some form of certificate pinning, could still be MITM'd
Now, apparently this uses plain http - but if tls/https is an option - any client (like curl/wget) should by definition come with a ssl trust root (os or bundled). If this is mitm'ed, you've got big problems. Certificate pinning doesn't really help that much in this case.
