All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: ipxe-devel@lists.ipxe.org, "László Érsek" <lersek@redhat.com>,
	qemu-devel@nongnu.org, crobinso@redhat.com
Subject: Re: https booting
Date: Wed, 22 Jul 2020 13:23:47 +0100	[thread overview]
Message-ID: <20200722122347.GF2324845@redhat.com> (raw)
In-Reply-To: <20200722120827.dq72uabrk26nllra@sirius.home.kraxel.org>

On Wed, Jul 22, 2020 at 02:08:27PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> With the world moving to use https by default people start to ask for
> https being enabled by default for the qemu boot roms.
> 
> We could simply flip the DOWNLOAD_PROTO_HTTPS switch in
> src/config/qemu/general.h (ipxe git repo).  Note that this would only
> affect booting in bios mode, for uefi qemu uses the efidrv builds which
> implies https support is in the hands of the uefi firmware (edk2/ovmf).
> 
> After looking at https://ipxe.org/cfg/crosscert I'm not convinced this
> is a good idea though.  This would likely put quite some load to
> ca.ipxe.org.  Also that machine becomes a single point of failure for
> worldwide ipxe https boot, and looking through the mailing list I've
> seen we already had (at least) two outages this year.
> 
> What happens if you sent crosscert to the empty string?
> Will ipxe fail or will it boot without cert verification?
> 
> What does it take to mirror http://ca.ipxe.org/auto/?
> Just "wget -r" everything and serve it?
> 
> How does edk2 handle the root ca problem?

There are two fw_cfg paths

  - etc/edk2/https/ciphers
  - etc/edk2/https/cacerts

The first sets the cipher algorithms that are permitted and their
priority, the second sets the CA certificate bundle.

There's some recently merged code in QEMU to simplify the setup
of the ciphers data via the "tls-cipher-suites" object, but
ultimately libvirt is responsible for passing suitable -fw_cfg
args to QEMU to populate both.

I'd suggest that iPXE needs to support the equivalent kind of
concept, both CA certs, and the cipher priority.

The rationale is that the OS vendor defines CA certs and cipher
priority for the host OS, with optional local administrator
override. Any firmware QEMU runs needs to honour the host OS
settings in this area, so we should have a mechanism for pass
in the relevant data from the host for iPXE IMHO.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2020-07-22 12:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22 12:08 https booting Gerd Hoffmann
2020-07-22 12:23 ` Daniel P. Berrangé [this message]
2020-07-22 13:55   ` Gerd Hoffmann
2020-07-22 14:13     ` Daniel P. Berrangé
2020-07-22 18:47       ` Laszlo Ersek
2020-07-24 16:19       ` [ipxe-devel] " Michael Brown
2020-08-03  7:37         ` Gerd Hoffmann
2020-07-22 13:21 ` Michael Brown
2020-07-22 13:45   ` Michael Brown
2020-08-03  8:04   ` Gerd Hoffmann
2020-07-22 18:34 ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200722122347.GF2324845@redhat.com \
    --to=berrange@redhat.com \
    --cc=crobinso@redhat.com \
    --cc=ipxe-devel@lists.ipxe.org \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.