Hi Jakub, On 27 February 2013 15:11, Jakub Scholz <ja...@scholz.cz> wrote: > Hi, > > I played a bit with the SSL Client Authentication which is supported in the > last versions of the Java Broker. It seems to work fine, but there are some > differences compared to the implementation in the C++ broker. > > The C++ broker implementation is based on the NSS library from Mozilla. The > user creates an certificate database and configures the broker to load the > database at start-up The NSS certificate database can store the private > keys used by the broker as well as the public keys related to the > connecting clients. The public keys can be divided into several groups - > the keys of trusted CAs and the keys of trusted peers. The difference > between the trusted CA and trusted peer is that the trusted CA allows to > log in even to clients who have a certificate signed by the CA, while the > peers allow to log in only to clients who have the certificate exactly > matching the certificate loaded in the certificate database. > > When the client is logged in, the CN from the certificate is used as the > authenticated username. That makes the trusted peers very important, > because if you want to use self signed certificates, you need to be able to > distinguish between the client connecting with the exact certificate or a > client connecting with a certificate which was signed by the original > certificate and has possibly a different CN. > > The SSL Client Authentication in the Java broker is based on the Java JSSE > implementation. The certificates are stored in the JKS format. The JKS > format doesn't distinguish between trusted peers and trusted CA. Therefore > all public keys behave as trusted CAs. As a result, the current > implementation cannot be used together with self signed > certificates. Additionally another minor difference is in the way the > username is constructed - the Java broker doesn't use only the CN as the > authenticated username, but it uses a complete distinguished name. But that > isn't such a big deal. > > Together with my colleague we tried to solve the problem with the trusted > peer. As far as we found out, there seems to be no support for the trusted > peers in the JKS truststores. First we investigated the possibility to > replace the JKS / JSSE implementation used in the Java broker with the NSS > library (its Java implementation called JSS). Unfortunately, the JSS > doesn't implement the Java APIs currently used in the broker - therefore > using JSS would require more significant changes (e.g. use the JSS > SSLSocket etc.). As a second approach we tried to implement our own > TrustManager, which would use the JKS truststore but handle all the > certificates inside as trusted peers. That seems to be a easier and more > feasible approach. > > As a result of our investigation, we would like to suggest following > enhancement: > > - The current configuration for the SSL Client Authentication supports only > one truststore > - We can add a second configuration entry which would allow to specify > "peerstore" > - When creating the SSL context, the existing truststore would be handled > as it is handled today > - If the "peerstore" is specified, the new TrustManager will be added to > the SSL context > - The custom TrustManager will use the peerstore to verify the peers only > as a peers > - The client will pass the authentication if it is authenticated either > with the original Trustmanager against the keystore or by the custom trust > manager against the peer store > > such solution would allow > - the change to be backwards compatible ...anyone using it will not see any > change > - provide support for signed and self-signed certificates at the same time > - it will be based on the standard Java APIs wherever possible > > Please let me know whether you think this makes sense and if yes, we can > open a JIRA for it and prepare a patch. >
At first read that all sounds sensible - looking forward to seeing the patch. > The second problem - using CN as a username versus using complete DN as > username - cannot be so easily solved in a backward compatible way. The SSL > related classes can be changed to use only CN as username, but that would > be change for everyone already using it. Another option would be to add > some mapping table between distinguished names and username which can > be optionally used. > Could we perhaps just add an option to the authentication provider to specify whether to use the CN or the DN as the username? This will leave the choice to the operator of an individual broker instance so they can choose to be compatible with the java Broker way of doing things or the C++ broker way? Cheers, Rob > Thanks & Regards > Jakub --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
