activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino (Commented) (JIRA)" <>
Subject [jira] [Commented] (APLO-169) SSL Handshake Enhancements and Modifications
Date Tue, 27 Mar 2012 18:37:27 GMT


Hiram Chirino commented on APLO-169:

Hi Guy I've deployed a new snapshot with APLO-174 implemented.. Could you try it out and let
me know if that works for you? Thanks!
> SSL Handshake Enhancements and Modifications
> --------------------------------------------
>                 Key: APLO-169
>                 URL:
>             Project: ActiveMQ Apollo
>          Issue Type: Improvement
>          Components: apollo-broker
>    Affects Versions: wish-list
>         Environment: Ubuntu 11.01, 
> Java OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre11-0ubuntu1.11.10.2)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> If accepted, a fix should apply to all platforms (Unix, Linux, Windows, OS X).
>            Reporter: Guy Allard
>            Priority: Minor
>             Fix For: 1.2
> This is a request to modify Apollo's SSL behavior as described below.  My 
> apologies for the verbosity.  I want to be clear about:
> a) what I am asking for
> b) why I am asking for it
> Background:
> The endpoints of an SSL connection are typical:  a server instance and a 
> client instance.
> If peer authentication is to be performed (by either side), this is communicated
> to SSL libraries by setting verification modes in the SSL context at the
> appropriate time (before connection).
> Authentication involves the exchange of certificates and awareness of any
> Certificate Authorities (CAs) involved.  A detailed discussion of certifications,
> public keys, private keys, and CAs is not presented here.
> Also not presented is a discussion of the certificate/store formats supported by
> OpenSSL and Java.  Be aware there are incompatabilities.
> From the perspective of both client and server, there are four distinct
> scenarios possible for an SSL connection. These are:
> 1) No authentication.  The client does not authenticate the server, and the
> server does not authenticate the client.
> 2) The server authenticates the client.  The client does not authenticate the
> server.
> 3) The client authenticates the server. The server does not authenticate the
> client.
> 4) The server authenticates the client, and vice-versa.
> A very clear explanation of how both the client and server should operate
> in each of those scenarios can be found here:
> Important Note: All of the functionality described at the above link should
> be performed by SSL libraries during an initial 'connect' sequence, referred to 
> as a 'handshake'.  The timing of the 'handshake' is well before any application
> data exchange has been attempted (i.e a STOMP CONNECT frame has been sent). And
> the results are known to the client after connect, but before any attempt to
> send application data.
> Current Apollo characteristics:
> 1) Apollo implements SSL authentication via configuration, in both apollo.xml 
> and login.config files.
> 2) The login.config file indicates whether SSL authentication is 'optional' or
> 'required'.
> 3) Checks that valid client certificates are supplied are deferred until the
> initial STOMP CONNECT frame is received.
> In the case of 'optional' SSL authentication:  all four of the above scenarios
> are currently supported by Apollo when a STOMP client connects. This is currently 
> expected (AFAIK) behavior.
> In the case of 'required' SSL authentication: only scenarios 2) and 4) are
> supported by Apollo when a STOMP client connects. This is currently expected (AFAIK)
> behavior.
> Summary of Change Requested:
> This is a request for Apollo behavior to change for item 3) in "current 
> Apollo characteristics" above.
> The request is that the same behavior is exhibited, but that it be exhibited
> at 'connect', and not deferred until an initial STOMP CONNECT frame is 
> put on the wire by a client.
> In short: this request does not request a change in behavior.  It is a request 
> to change _when_ the behavior happens.
> This change will match:
> a) Behavior of SSL clients and servers in general
> b) In particular, the current behavior of ActiveMQ

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message