On 5/27/24 11:45, Martin Husemann wrote:
> On Mon, May 27, 2024 at 11:36:26AM +0200, Jerome Forissier wrote:
>> You're correct. The point I am making is about using a secure
>> (authenticated) connection, and I should have clarified that. While using
>> HTTPS might not be critical on a local network, things are different when
>> downloading from the internet (think man-in-the-middle attacks).
> 
> (Sorry if this sounds like nitpkicking, but I am genuinely curious)

No worries. Well-defined use cases are certainly essential to
proper implementations.

> How is it supposed to work?
> 
> You need not only https but also verify the presented certificate chain,
> and for that you need up-to-date root certificates (e.g. the bundle
> available from mozilla).

Yes. I will let Javier comment further since he's more directly
concerned with that part.

> This sounds a bit outside the scope of u-boot to me

Maybe, maybe not. I would argue it is a matter of deployment policy.
For example assume the device is an IP camera or some other IoT thing
that comes with the bare minimum to boot and fetch its OS on first
power up. No guarantee about what is on the local network -- just
plain internet access. https would be quite helpful in such a case.

> (or you should 
> avoid the man-in-the-middle argument, which leaves the still valid
> "sites stop offering plain http" argument).

As long as there is at least one valid argument then I'm fine :)

> If you really worry about man-in-the-middle you need to download via
> https in an environment that does certificate validation, and then
> even better verify the hash of the downloaded image. After that you
> can offer the image locally - via http, https or tftp - for installations.

That certainly would work but again, isn't it a decision to be made
by the device manufacturer or more generally the one who builds u-boot
for the device?

-- 
Jerome

Reply via email to