activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <>
Subject [jira] [Commented] (AMQ-5443) SSL client does not validate server certificate common name
Date Tue, 17 Feb 2015 15:11:11 GMT


Timothy Bish commented on AMQ-5443:

Now that we require JDK v1.7 a simpler fix might be to use the HTTPS endpoint identification
algorithm when configuring the SSLParameters.  

        if (isVerifyHost()) {
            SSLParameters sslParameters = engine.getSSLParameters();

We'd be happy to review a patch along these lines, it should have unit tests along with it
to validate things work as expected with checking enabled or disabled.  

> SSL client does not validate server certificate common name
> -----------------------------------------------------------
>                 Key: AMQ-5443
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.10.0
>            Reporter: Allen Hadden
>              Labels: security
>         Attachments:
> When using SSL the server certificate's common name (or subjectAltName) must be validated
in order to prevent a man-in-the-middle attack.  The ActiveMQ client does not do this by default
and makes doing so somewhat difficult.
> The result is that most applications that use the ActiveMQ client with SSL are not getting
the security they think they are.  For a very good explanation of this hostname verification
issue, see
> It is worth nothing that ActiveMQ was specifically mentioned in a paper titled "The Most
Dangerous Code in the World:  Validating SSL Certificates in Non-Browser Software" (
> "Java-based Web-services middleware, such as Apache Axis, Axis 2, and Codehaus XFire,
is broken, too. So is the Android library for Pusher notification API and Apache ActiveMQ
implementation of Java Message Service. All programs employing this middleware are generically
> Also, ActiveMQ is specifically mentioned in CVE-2012-5784 (
as an example of a library that does not do host name checking.  I can't explain why this
hasn't been a bigger deal (am I missing something?).
> We have worked around this in our code by providing our own connection factory class
that inherits from ActiveMQSslConnectionFactory.  It overrides the createTrustManager() and
setKeyAndTrustManagers(...) methods in order to "decorate" the real TrustManagers with a check
for certificate host name.  Currently, it uses org.apache.http.conn.ssl.SSLConnectionSocketFactory.BROWSER_COMPATIBLE_HOSTNAME_VERIFIER
from the Apache HTTP Client project to verify the host name, which works for our project because
we already use the Apache HTTP Client elsewhere.
> I created this issue with a Major priority, although it could be argued that it's Critical
because it's security related and likely to affect so many people.  

This message was sent by Atlassian JIRA

View raw message