Hi Jakub, You suggesting is quite interesting and it would be beneficial for Qpid project if you could raise a JIRA and attach a patch.
You might already noticed that we have changed the broker configuration model and removed xml configuration. At the moment, the only supported configuration format is json. The keystore and trustore can be configured as broker configured object attributes. It is a temporary solution. Later on, it will be possible to configure as many keystores/trsustores as needed. If you created a patch for the old xml configuration we can have a look at it and change it to fit a new configuration model. In case if you working with the existing code base than you can add special peerstore attributes to the Broker configured object to allow the configuring of peerstore. Kind Regards, Alex On 27 February 2013 14:11, Jakub Scholz <[email protected]> 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. > > 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. > > Thanks & Regards > Jakub --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
