[
https://issues.apache.org/jira/browse/QPID-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631600#comment-13631600
]
Robbie Gemmell commented on QPID-4636:
--------------------------------------
As per the added of the linked issue, QPID-4739 modifies the SSL configuration
to allow defining multiple trust stores and assigning them per-port. The 'peer
store' functionality is incorporated into this using the 'peersOnly' attribute
on each trust store.
> [Java Broker] add a 'peerstore' to enhance SSL Client Authentication
> functionality, provide similar 'trusted peer' support with self-signed certs
> as the C++ broker
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-4636
> URL: https://issues.apache.org/jira/browse/QPID-4636
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker, Java Common
> Reporter: Michal Zerola
> Assignee: Robbie Gemmell
> Fix For: 0.21
>
> Attachments: java_broker_peerstore.jks,
> java_client_untrusted_keystore.jks, ssl_new_trustmanager.patch,
> ssl_new_trustmanager_test_extended.patch, ssl_new_trustmanager_test.patch
>
>
> *Motivation:*
> The C++ broker implementation is based on the NSS library from Mozilla. The
> user creates a 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 logging in even to clients
> who have a certificate signed by the CA, while the peers allow logging in
> only to clients who have the certificate exactly matching the certificate
> loaded in the certificate database.
> 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. As we found out, there
> seems to be no support for the trusted peers in the JKS truststores.
> *Proposed solution:*
> 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 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.
> *Configuration and patch explanation:*
> The current configuration model for the broker (trunk) is based on JSON. We
> have added two optional attributes (peerStorePath, peerStorePassword):
> {quote}
> …
> "keyStorePath": "...",
> "keyStorePassword": "123456",
> "trustStorePath": "...",
> "trustStorePassword": "123456",
> {color:red}
> "peerStorePath": "...",
> "peerStorePassword": "123456",
> {color}
> …
> {quote}
> Internally, the broker is prepared to handle multiple truststores, since it
> can store them in the collection. If the above new attributes were specified,
> the additional truststore is added into the collection (BrokerAdapter.java).
> A new truststore will have optional flag TrustStore.PEERS_ONLY set to True.
> The SSLContextFactory was extended for collection configuration. The Broker
> creates the SSLContext using the collection of truststores (either only
> single truststore or with a new peerstore). The SSLFactory parses the
> collection and depending on the TrustStore.PEERS_ONLY flag creates either
> regular JSSE trustmanager or uses a newly introduced one
> QpidPeersOnlyTrustManager.
> The new QpidPeersOnlyTrustManager works as a wrapper around standard JSSE
> trustmanager. When client connects, the check is delegated to the underlying
> JSSE verification and if it succeeds, the additional check is done, whether
> the peer’s certificate (in the chain index 0) is present in the keystore
> file. Only then the client is authenticated, otherwise the
> CertificateException is thrown.
> Since SSLContext.init method from the array of trustmanagers uses only the
> first one which is an instance of the X509TrustManager class, we have created
> also the extension. Otherwise, it would not be possible to use simultaneously
> trustmanager (JSSE implementation) and peermanager (our new implementation)
> because both implements X509TrustManager and only the first from the array
> would be considered. Therefore, we have introduced the
> QpidMultipleTrustManager which is doing nothing else but delegating the check
> to its underlying X509TrustManagers and only if all fails, the check itself
> fails. If some underlying manager succeeds, the check itself succeeds as
> well. This QpidMultipleTrustManager is loaded with truststore and peerstore
> manager and added into the array which is further passed to the
> SSLContext.init method.
> The implementation attached in the patch seems to be working fine and adds
> the above requirements for peers only truststore. It is also backwards
> compatible- anyone without interest for peerstores will not see any change.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
