activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guy Allard (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (APLO-169) SSL Handshake Enhancements and Modifications
Date Thu, 01 Mar 2012 03:36:04 GMT
SSL Handshake Enhancements and Modifications
--------------------------------------------

                 Key: APLO-169
                 URL: https://issues.apache.org/jira/browse/APLO-169
             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.1


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:

http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html

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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message