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]
