Hi Alex, Right now we have only something I would call prototype. We yet have to prepare some real patch with the whole configuration stuff - I wanted first cross-check whether the idea sounds feasible before spending the time on the configuration :-). We will try to prepare the patch already with the new configuration model in mind and see how it works.
Thanks & Regards Jakub On Wed, Feb 27, 2013 at 4:12 PM, Oleksandr Rudyy <[email protected]> wrote: > 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] > >
