[foaf-protocols] TLS 1.0-1.1 issue with regard to client certificates

Henry Story Henry.Story at Sun.COM
Wed Feb 25 09:22:07 CET 2009


I recently came across a couple of well versed security folks who were  
surprised [1] that the server could ask the client for arbitrary self  
signed certificates.

The question asked is the following:
> when a server sends a certificate_request msg to a browser, how  
> could the certificate_authorities field within the request be such  
> that it causes the selection of a self-signed certificate by the  
> brower (assuming that the server cannot identify all the possible  
> self-signing certificate authorities in its certificate_request msg)?


Bruno Harbulot (and others) helped identify the source of the problem:  
an ambiguity between the specification of TLS 1.0 and TLS 1.1.

RFC 2246 (TLS 1.0) Section 7.4.6 states [2]:

       If no suitable certificate is available, the client should send  
a certificate message
       containing no certificates.

This would be very problematic for foaf+ssl because a server has no  
way to know all possible self signed certificates that may be sent,  
and so even if it knew them - which it won't - it could not list them  
all. So people well versed in RFC 2246 may indeed find this surprising.

On the other hand in RFC 4346 (TLS 1.1), section 7.4.4 [3] on  
Certificate Requests was changed to say:

         If the certificate_authorities list is empty then the client  
MAY send any certificate of the
         appropriate ClientCertificateType, unless there is some  
external arrangement to the contrary.

So this is much more favorable to the simple current implementation of  
foaf+ssl.

The problem now is: since TLS 1.1 is much newer than TLS 1.0 - the RFC  
states the date of April 2006 - how many browsers implement this piece  
of its behavior. Until now I had assumed we were working in the space  
of well accepted best practices and so that we had authority on our  
side. Now I think verification is needed: we need a list of browsers  
and we need to find out which ones implement this aspect of TLS 1.1  
(It could well be that the language of TLS1.1 was added because all  
well known clients just behaved that way)

There may be another solution to this I just thought of and this would  
be to create a  foaf+ssl root certificate and publish its private key  
so that anyone could sign their certificates with this public root  
certificate. It would just be a matter then of filtering on this then.  
Does this make sense?

	Henry


[1] https://glassfish.dev.java.net/issues/show_bug.cgi?id=6935
[2] http://tools.ietf.org/html/rfc2246#section-7.4.6
[3] http://tools.ietf.org/html/rfc4346#section-7.4.4

Blog: http://blogs.sun.com/bblfish



More information about the foaf-protocols mailing list