Re: [PATCH] Remote 3/8: Client-side

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Daniel P. Berrange wrote:
On Sat, May 05, 2007 at 12:17:44PM +0100, Richard W.M. Jones wrote:
(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.

Right, but this comment is about the client's certificate which is presented to and checked by the server.

The server knows only the IP address of the client (well, it could do a DNS PTR lookup, but it shouldn't trust the results since they are under the control of the client too!)

But what is the real solution here? Either allow the client to have multiple certificates (of course marked as IPv4 or IPv6 certificates, and perhaps other namespaces too?!), or else do some name-mangling so that IPv4 and IPv6 addresses can be compared, prepending or removing ::ffff: as appropriate?

Rich.


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]