[
https://issues.apache.org/jira/browse/QPID-8499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268498#comment-17268498
]
Robert Godfrey edited comment on QPID-8499 at 1/20/21, 10:39 AM:
-----------------------------------------------------------------
My understanding of this trust store type was that its intended use was for
checking certificates passed by connecting clients as part of a client
certificate exchange. It is _not_ intended to be used in the case where the
broker is making an outbound TLS connection. As such the certificate is really
just acting as a "secret" rather than necessarily being tied to a valid DNS
name, moreover when receiving a client certificate I'm not sure it really makes
sense to worry about MITM attacks.
It would make sense for the implementation to, in some way, indicate that it is
not suitable for use as a truststore in the case where it is being used to
check the certificate presented by a server on an outbound (from the
perspective of the broker) connection, and prevent its use in this way. It
should also (if it does not already) validate the current date lies within the
start/end dates on the presented certificate .
was (Author: rgodfrey):
My understanding of this trust store type was that its intended use was for
checking certificates passed by connecting clients as part of a client
certificate exchange. It is _not_ intended to be used in the case where the
broker is making an outbound TLS connection. As such the certificate is really
just acting as a "secret" rather than necessarily being tied to a valid DNS
name, moreover when receiving a client certificate I'm not sure it really makes
sense to worry about MITM attacks.
It would make sense for the implementation to, in some way, indicate that it is
not suitable for use as a truststore in the case where it is being used to
check the certificate presented by a server on an outbound (from the
perspective of the broker) connection, and prevent its sed int his way. It
should also (if it does not already) validate the current date lies within the
start/end dates on the presented certificate .
> [Broker-J] Customized TrustManager bypasses certificate verification
> --------------------------------------------------------------------
>
> Key: QPID-8499
> URL: https://issues.apache.org/jira/browse/QPID-8499
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Ya Xiao
> Priority: Major
>
> We found a security vulnerability in file
> [qpid-broker-j/broker-core/src/main/java/org/apache/qpid/server/security/SiteSpecificTrustStoreImpl.java|https://github.com/apache/qpid-broker-j/blob/a70ed6f5edbcf0e8690447d48a1fe64e599cb703/broker-core/src/main/java/org/apache/qpid/server/security/SiteSpecificTrustStoreImpl.java].
> The customized TrustManger (at Line 339) allows all certificates to pass the
> verification.
> *Security Impact*:
> The checkClientTrusted and checkServerTrusted methods are expected to
> implement the certificate validation logic. Bypassing it could allow
> man-in-the-middle attacks.
> *Useful Resources*:
> [https://cwe.mitre.org/data/definitions/295.html]
> [https://developer.android.com/training/articles/security-ssl|https://developer.android.com/training/articles/security-ssl#SelfSigned]
> *Solution we suggest:*
> Do not customize the TrustManger or specify the certificate validation logic
> instead of allowing all certificates. See
> [here|https://developer.android.com/training/articles/security-ssl] to
> securely allow self-signed certificates and other common cases.
> *Please share with us your opinions/comments if there is any:*
> Is the bug report helpful?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
