On Sat, May 05, 2007 at 12:17:44PM +0100, Richard W.M. Jones wrote:
> Richard W.M. Jones wrote:
> >3 Client-side
> >-------------
> >
> >A src/remote_internal.c
> >A src/remote_internal.h
> >M src/driver.h
> >M src/libvirt.c
>
> This is the code which serialises requests on the client side. First up
> is a small patch against driver.h and libvirt.c which just declares and
> registers the new driver.
>
> Secondly, the driver itself (remote_internal.h / remote_internal.c)
> which I will describe in more detail.
>
> The header file is small and I think non-controversial. It just
> declares the remoteRegister function and a handful of constants like
> paths and port numbers.
>
> The driver itself (remote_internal.c) consists of the following parts,
> arranged here in the same order that they appear in the file:
>
> (1) remoteOpen and associated, GnuTLS initialisation
I've got a question about this comment
/* XXX This loop contains a subtle problem. In the case
* where a host is accessible over IPv4 and IPv6, it will
* try the IPv4 and IPv6 addresses in turn. However it
* should be able to present different client certificates
* (because the commonName field in a client cert contains
* the client IP address, which is different for IPv4 and
* IPv6). At the moment we only have a single client
* certificate, and no way to specify what address family
* that certificate belongs to.
*/
It is my understanding that the 'commonName' should be the public user
facing name of the server. eg, if the user is accessing
https://foo.example.com/
Then commonName in the certificate would be 'foo.example.com'. The commonName
should be verified against the user supplied address, which in this case
would also be foo.example.com.
So if foo.example.com in turn resolved to both IPv4 & IPv6, eg
$ host foo.example.com
foo.example.com has address 60.64.20.142
foo.example.com has IPv6 address 2001:71c2:1:ee34::2
Then it really shouldn't matter whether we ended up connecting over IPv4
or IPv6, because we're still comparing foo.example.com against foo.example.com
AFAICT.
Now, if the certificate was configured with an IP adress in it commonName,
and the user connected to 'foo.example.com' then certificate validation
should fail because 60.64.20.142 != foo.example.com and neither is the IPv6
address 2001:71c2:1:ee34::2. It should only succeeed if the user ewas
explicitly connecting with https://60.64.20.142/
Basically DNS lookups should not be involved in any part of the certificate
validation process - user provided hostname should be validated unchanged
against the certificate's embedded commonName.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|