[libvirt-users] Certificate checking on TLS migrations to an IP address

[Daniel P. Berrangé]

On Mon, Sep 23, 2019 at 03:04:46PM +0200, Milan Zamazal wrote:
> Milan Zamazal <mzamazal at redhat.com> writes:
> 
> > Daniel P. Berrangé <berrange at redhat.com> writes:
> >
> >> On Wed, Sep 18, 2019 at 12:18:32PM +0200, Milan Zamazal wrote:
> >>> Daniel P. Berrangé <berrange at redhat.com> writes:
> >>> 
> >>
> >>> > On Wed, Sep 04, 2019 at 03:38:25PM +0200, Milan Zamazal wrote:
> >>> >> Hi, I'm trying to add TLS migrations to oVirt, but I've hit a problem
> >>> >> with certificate checking.
> >>> >
> >>> >> 
> >>> >> oVirt uses the destination host IP address, rather than the host name,
> >>> >> in the migration URI passed to virDomainMigrateToURI3.  One reason for
> >>> >> doing that is that a separate migration network may be used for
> >>> >> migrations, while the host name resolves to the management network
> >>> >> interface.
> >>> >> 
> >>> >> But it causes a problem with certificate checking.  The destination IP
> >>> >> address is checked against the name, which is a host name, given in the
> >>> >> destination certificate.  That means there is mismatch and the migration
> >>> >> fails.  I don't think it'd be a very good idea to avoid the problem by
> >>> >> putting IP addresses into server certificates.
> >>> >
> >>> > In fact that is *exactly* what you should be doing.
> >>> >
> >>> > Traditionally certificates were created with the 'common name' field
> >>> > holding the fully qualified DNS based hostname for the server.
> >>> >
> >>> > This was long known to be a problem because it is very common for
> >>> > servers to have multiple DNS names, or for clients to use the
> >>> > unqualified hostname, or use the IP address(es).
> >>> 
> >>> The problem with putting IP addresses into certificates is that the
> >>> certificate must be updated each time an IP address changes, is added or
> >>> is removed.  Doing this in oVirt would be complicated and error-prone.
> >>> While host names are stable, host networks and the related IP addresses
> >>> may change.
> >>> 
> >>> > Thus, the "Subject alt name" extension was created. This allows
> >>> > certificates to be created containing multiple hostnames and
> >>> > multiple IP addresses. The certificate will be validated correctly
> >>> > if any one of those data items matches. When 'subject alt name' is
> >>> > present in a certificate, the 'common name' field should be completely
> >>> > ignored by compliant TLS clients, so you are free to put whatever
> >>> > you want in the common name - hostname or IP address or blah...
> >>> 
> >>> We can switch to using Subject Alt Name and we have a patch for that now
> >>> based on your advice, but it doesn't solve the problem with tracking IP
> >>> address changes and updating the corresponding certificates whenever a
> >>> change occurs.
> >>> 
> >>> > If you look at our docs, we updated them to illustrate how to
> >>> > issue certs containing hostnames + IP addresses:
> >>> >
> >>> > https://libvirt.org/remote.html#Remote_TLS_server_certificates
> >>> >
> >>> >> 
> >>> >> Is there any way to make TLS migrations working under these
> >>> >> circumstances?  For instance, SPICE remote-viewer allows the client to
> >>> >> specify the certificate subject to expect on the host when connecting to
> >>> >> it using an IP address.  Can (or could) libvirt do something similar?
> >>> 
> >>> Would it be possible?  We have host names in the certificates under our
> >>> control and we know which host name to expect in the certificate
> >>> regardless the IP address used for the given connection.  Checking the
> >>> certificate against a given host name would solve the problem easily and
> >>> robustly for us.
> >>
> >> There's two options that could make it work
> >>
> >>  - Define a new migration parameter which lets apps pass in the hostname
> >>    to use for TLS cert validation to libvirt, which would have to then
> >>    pass it into QEMU
> >
> > I think this is the best option.  We know the destination host name,
> > while we need to use an IP address to connect to it in order to use a
> > particular network.
> 
> If we can agree on this, should I file a corresponding RFE on libvirt?

Yes, please go ahead & do that


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 :|