Having http as an alternative to tftp is a nice win. The range of things that can run an http server is much bigger than tftp
>Additionally, adding the TLS layer brings back the missing integrity and confidentiality guarantees and thus paves the way to move critical boot components out of the trusted network, possibly even to a remote location/Cloud.
Doesn't secure boot already provide this or am I misunderstanding something? I suppose secure boot only provides integrity but not confidentiality although I'm not sure how much confidentiality matters given we're just talking about the kernel here
> > adding the TLS layer brings back the missing integrity
A foolish interpretation of what TLS does. Integrity of the bits and bytes in transit is unimportant. Validation of the signed software after you have received it is everything. TLS integrity is at best redundant and at worst — the interpretation made here — leaves you vulnerable and with a false sense of security.
Secure boot is designed to verify software signatures. The UEFI bios might support loading software over https, but it isn't part of secure boot. Secure boot would verify any kernels/etc loaded from https.
> Secure boot is designed to verify software signatures
aka integrity.
HTTPS is a useless gesture here, adding complexity to critical software that needs to be as simple and auditable as possible. Confidentiality is essentially unimportant to anyone but the most autistic of by-the-book nerds. It buys you nothing in a practical sense. Most netbooting happens over closed networks anyway.
That was the point as I read it. Payload signature verification is a good and sometimes desirable alternative to transport encryption when the payload itself isn't secret.
Highly-cacheable resources like game and OS updates are often intentionally delivered over http as signed payloads to facilitate middlebox caching.
There's still the tftp->ipxe->http->??? path. TFTP only needs to serve a 300kb file which can then switch to more robust transport like http for the kernel/OS
You could bypass that by shipping iPXE on USB tho
On metal you also commonly have a BMC so generally that lets you attach an ISO or other storage you can boot from to bypass UEFI primitive PXE. This is probably the biggest one--use BMC functionality instead of UEFI PXE
At home, I use JetKVM or GL.iNet Comet network KVM to bootstrap commodity hardware without BMC (by attaching an ISO). Probably could make a cheap commodity device with Raspberry Pi Zero that does that same thing at lower cost although at that point you're back to "just use USB storage"
BTW Apple has been doing HTTP boot for like two decades at this point. How do you think Internet Recovery works?
Having http as an alternative to tftp is a nice win. The range of things that can run an http server is much bigger than tftp
>Additionally, adding the TLS layer brings back the missing integrity and confidentiality guarantees and thus paves the way to move critical boot components out of the trusted network, possibly even to a remote location/Cloud.
Doesn't secure boot already provide this or am I misunderstanding something? I suppose secure boot only provides integrity but not confidentiality although I'm not sure how much confidentiality matters given we're just talking about the kernel here
> > adding the TLS layer brings back the missing integrity
A foolish interpretation of what TLS does. Integrity of the bits and bytes in transit is unimportant. Validation of the signed software after you have received it is everything. TLS integrity is at best redundant and at worst — the interpretation made here — leaves you vulnerable and with a false sense of security.
Secure boot is designed to verify software signatures. The UEFI bios might support loading software over https, but it isn't part of secure boot. Secure boot would verify any kernels/etc loaded from https.
> Secure boot is designed to verify software signatures
aka integrity.
HTTPS is a useless gesture here, adding complexity to critical software that needs to be as simple and auditable as possible. Confidentiality is essentially unimportant to anyone but the most autistic of by-the-book nerds. It buys you nothing in a practical sense. Most netbooting happens over closed networks anyway.
That was the point as I read it. Payload signature verification is a good and sometimes desirable alternative to transport encryption when the payload itself isn't secret.
Highly-cacheable resources like game and OS updates are often intentionally delivered over http as signed payloads to facilitate middlebox caching.
To what extent is this possible for actual metal hardware? I'm sure lots of us are running PXE/TFTP systems and HTTP would be a heck of a lot simpler.
There's still the tftp->ipxe->http->??? path. TFTP only needs to serve a 300kb file which can then switch to more robust transport like http for the kernel/OS
You could bypass that by shipping iPXE on USB tho
On metal you also commonly have a BMC so generally that lets you attach an ISO or other storage you can boot from to bypass UEFI primitive PXE. This is probably the biggest one--use BMC functionality instead of UEFI PXE
At home, I use JetKVM or GL.iNet Comet network KVM to bootstrap commodity hardware without BMC (by attaching an ISO). Probably could make a cheap commodity device with Raspberry Pi Zero that does that same thing at lower cost although at that point you're back to "just use USB storage"
All recent servers support HTTP boot.
You can use iPXE https://ipxe.org/
Hey, I'd say "hire this guy", but we already did. This is an excellent write up of excellent work by an excellent colleague. Thanks yadutaf!