OK - I've made a few more changes... I've renamed the options I added
previously to and added the ability to set the enabled protocols on the
socked.  You can use the system property "qpid.ssl.enabledProtocols", or
the url option ssl-enabled-protocols (or set the property
sslEnabledProtocols on the ConnectionFactory) to provide a comma separated
list of the protocols you want enabled.  There is an analogous "disabled"
version for removing protocols you don't want enabled (which defaults to
SSLv3).

Does this provide everything you need?

-- Rob

On 30 January 2015 at 14:48, MattiasÖ <[email protected]>
wrote:

> Hi Rob!
>
> Thanks for the very quick response!
>
> My setup is JDK 7u45.
> I have bundled Qpid and Apache Camel (camel-core, camel-spring, camel-amqp,
> acticemq-camel, qpid-amqp-1-0-client-jms) and deploy this on Jboss.
> This means that I configure everything via a spring xml, so I can't really
> check enabled protocols except via trial and error against my test AMQP
> broker (activemq 5.9).
>
> Examples of setup ("Client" refers to my value of the
> TRANSPORT_LAYER_SECURITY_CODE String in SSLUtil):
>
> Client        Broker                                   Success     Used
> Protocol
> -------       --------                                   ---------
> ---------------
> "TLS"        "TLSv1","TLSv1.1", "TLSv1.2"     yes           "TLSv1"
> "TLS"        "TLSv1.1", "TLSv1.2"                 no
> handshake_failure
> "TLS"        "TLSv1.2"                                no
> handshake_failure
> "TLSv1.2"  "TLSv1","TLSv1.1", "TLSv1.2"     yes           "TLSv1.2"
> "TLSv1.2"  "TLSv1", "TLSv1.1"                   yes           "TLSv1.1"
> "TLSv1.2"  "TLSv1"                                  yes           "TLSv1"
>
> From these results and via checking source code and some documentation (see
> links below), my understanding is that the Protocol parameter you pass to
> SSLContext.getInstance( ... ), is a reference to a context that have some
> set of supported protocols and another (sub)set of (default) enabled
> protocols.
> The Context initialized with "TLS" only have "TLSv1" enabled per default,
> but it does support all the other versions of TLS _if_ they are actively
> enabled via for example SSLSockets setEnabledProtocols(String[] protocols)
> method.
> The Context initialized with "TLSv1.2" on the other hand, have the same set
> of supported protocols, but sets "TLSv1", "TLSv1.1" and "TLSv1.2" to
> enabled
> per default.
>
> In my use case, I want to set my client to only be able to connect with
> "TLSv1.2" because of security reasons. I shouldn't be able to successfully
> connect to a broker with more relaxed configuration (support of "TLSv1.1"
> or
> lower).
> As I see it, there are probably only one way to achieve this:
> * SSLContext is initialized with either "TLS" or "TLSv1" or "TLSv1.1" or
> "TLSv1.2" (they have the same set of supported protocols)
> * TCPTransportProvier creates the SSLSocket using the above SSLContext.
> * TCPTransportProvier performs sslSocket.setEnabledProtocols("TLSv1.2").
>
> This way the socket "should" only connect with "TLSv1.2" I think.
>
> If setEnabledProtocols() is not used, I believe you get the behaviour that
> I
> seem to get from my tests, where the client would accept all the protocols
> enabled per default (different sets depending on the initializating
> string).
>
> As for why you get the same set of enabled protocols from initializing with
> both "TLS" and with "TLSv1.2", I have no clue. That does seem a bit
> strange,
> since I don't seem to get the same behaviour.
> Maybe you're using another provider than SunJSSE where "TLS" is mapped
> against "TLSv1.2" instead?
>
> Of course I may also have understood everything above completely wrong. As
> you said, the documentation is really wonderfully vague :)
>
> Your changes so far seems really good though and should give the user a
> much
> more dynamic way of configuring SSL/TLS. However I don't think they would
> cover my use case completely.
> What are your thoughts on this?
>
> Finally here are some of the references that I've found:
> *
>
> http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
> *
>
> https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https
> * Some background info in the description:
> https://bugs.openjdk.java.net/browse/JDK-7093640
> * The mappings of the SSLContext initialization String towards an actual
> class:
>
> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/70e3553d9d6e/src/share/classes/sun/security/ssl/SunJSSE.java
> * The actual implementations of each SSLContext:
>
> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/70e3553d9d6e/src/share/classes/sun/security/ssl/SSLContextImpl.java
>
> Best Regards
> Mattias
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/qpid-amqp-1-0-client-jms-and-TLS-1-2-tp7619126p7619221.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to