libvirt users - Sep 2019 - Re: Certificate checking on TLS migrations to an IP address

Daniel P. Berrangé <berrange@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.
>> Or is there any other mechanism to handle this problem?
Thanks,
Milan

On Wed, Sep 18, 2019 at 12:18:32PM +0200, Milan Zamazal
wrote:
> Daniel P. Berrangé <berrange@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

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

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

Daniel P. Berrangé <berrange@redhat.com> writes:
> On Wed, Sep 18, 2019 at 12:18:32PM +0200, Milan Zamazal wrote:
>> Daniel P. Berrangé <berrange@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.
>  - 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.

Thanks,
Milan