qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith W <keith.w...@gmail.com>
Subject QPID-7867 [Java Broker] Authentication using self-signed expired certificates
Date Wed, 02 Aug 2017 10:50:26 GMT
Hello

Martin Krasa raised JIRA QPID-7867 [1] on 21st July.   As the JIRA
possibly eluded to a potential security issue, the initial discussion
was held in private on the Qpid private / Apache security lists.   We
have now reached a point where there is a agreement that there is no
security issue as such.   We might however added a feature to the Java
Broker to benefit this use-case.

I don't wish to cross-post the private conversation verbatim.  Instead
I will try and summerise the issue and the background as I understand
it.

use-case/issue:

The use-case is a development one, It involves a mutually
authenticated TLS connection for messaging from the Qpid JMS Client to
the Java Broker.  Both client and server were using self signed
certificates and those certificates had expired   The complaint was
that connection succeeded even though the certificates had expired.
The user was comparing behaviour with the CPP Broker which disallowed
such connections.

background:

Both the Java Broker and Qpid JMS Client rely on the inbuilt features
of Java JCA for the purpose of establishing trust during a TLS
handshake.   Java treats certificates in the truststore store as
trust anchors.  During an TLS handshake, the Java builds a certificate
chain from the certificate(s) provided by the peer over the wire to a
trust anchor in the store.   If the chain can be formed, the
certificates that comprise the chain are subject to checks (such as an
expiration), but these checks are *not* applied to the trust anchor
itself.   This behaviour seems to me to consistent with  RFC5280 [4].

In use-cases involving self-signed certificates, the certificate is
installed in the peer's truststore. and as such the self signed
certificate is itself the trust anchor.   When the remote side
connects and presents the self signed cert, this matches the trust
anchor stored and connection forms without expiration exception.

I hope this is reasonable summary.  Please feel free to correct or clarify.
I plan to post again later today with my ideas for changes we could
make to the Java Broker to help this use-case.

Keith,.

[1] https://issues.apache.org/jira/browse/QPID-7867
[2] https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html
[3] https://docs.oracle.com/javase/8/docs/api/java/security/cert/package-summary.html
[4] http://www.ietf.org/rfc/rfc5280.txt

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message