You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@activemq.apache.org by "Guy Allard (Created) (JIRA)" <ji...@apache.org> on 2012/03/01 04:36:04 UTC
[jira] [Created] (APLO-169) SSL Handshake Enhancements and
Modifications
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
[jira] [Commented] (APLO-169) SSL Handshake Enhancements and
Modifications
Posted by "Hiram Chirino (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/APLO-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239735#comment-13239735 ]
Hiram Chirino commented on APLO-169:
------------------------------------
Hi Guy, create question. I think it just picks the first right now. I've opened up
APLO-174 so that you can explicitly pick the one you want.
> 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.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:
> 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
[jira] [Issue Comment Edited] (APLO-169) SSL Handshake Enhancements
and Modifications
Posted by "Hiram Chirino (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/APLO-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239735#comment-13239735 ]
Hiram Chirino edited comment on APLO-169 at 3/27/12 5:59 PM:
-------------------------------------------------------------
Hi Guy, great question. I think it just picks the first right now. I've opened up
APLO-174 so that you can explicitly pick the one you want.
was (Author: chirino):
Hi Guy, create question. I think it just picks the first right now. I've opened up
APLO-174 so that you can explicitly pick the one you want.
> 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.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:
> 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
[jira] [Commented] (APLO-169) SSL Handshake Enhancements and
Modifications
Posted by "Hiram Chirino (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/APLO-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239801#comment-13239801 ]
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: 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.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:
> 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
[jira] [Commented] (APLO-169) SSL Handshake Enhancements and
Modifications
Posted by "Guy Allard (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/APLO-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236959#comment-13236959 ]
Guy Allard commented on APLO-169:
---------------------------------
If the keystore is configured with two or more certificates, how does the broker pick which to use as the broker's cert?
> 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.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:
> 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
[jira] [Resolved] (APLO-169) SSL Handshake Enhancements and
Modifications
Posted by "Hiram Chirino (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/APLO-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hiram Chirino resolved APLO-169.
--------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.1)
1.2
> 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.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:
> 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