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

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



On Tue, May 08, 2007 at 12:20:17PM +0100, Richard W.M. Jones wrote:
> 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.

Ahh.

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

So the question is, is there any meaningful security to be gained by having
the server check the commonName field of the client's certificate against
the client's incoming IP addr whether v4 or v6 ?  Perhaps the only thing the
server should be using the client cert's commonName field for is lookups in
its whitelist of allowed clients ?   Have you any idea what, say Exim or
Apache, do for validation when getting a client cert ? Do they bother to
check the commonName against the client's source addr, or do they merely
use it for access control lookups ?

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


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