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

[Milan Zamazal]

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?

Thanks,
Milan

>>  - The source host libvirtd has a connection to the dest host libvirtd.
>>    It can thus ask dest host what its primary hostname is, and then
>>    automatically tell QEMu to use that for TLS cert validation. This
>>    could cause problems though for people already using TLS certs
>>    with IP addresses in.
>
> This doesn't look very good from the security point of view, since then
> the source doesn't check it really connects to the host it expects, just
> that the destination host has a valid certificate signed by the right CA
> (I suppose).  It may be good enough or even useful for some scenarios,
> but not for others.