Hi (again) Mattias,
Out of interest, which JDK version and platform are you seeing this on.
Testing with 7u75 on my Mac I see both getInstance("TLS") and
getInstance("TLSv1.2") return the same set of enabled protocols:
["SSLv3", "TLSv1",
"TLSv1.1", "TLSv1.2"]
The Oracle documentation is wonderfully vague on what you can expect:
(from
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext
)
TLS : Supports some version of TLS; may support other versions
TLSv1.2 : Supports RFC 5246: TLS version 1.2
<http://www.ietf.org/rfc/rfc5246.txt> ; may support other versions
My inclination is to leave the default as "TLS" but the user to set both
the protocol and the provider as system properties, e.g. in your case you
could do
System.setProperty("qpid.ssl.protocol", "TLSv1.2");
(or obviously set via -D on the command line).
Would that work for you as a solution?
-- Rob
On 29 January 2015 at 20:26, Rob Godfrey <[email protected]> wrote:
> Hi Mattias,
>
> apologies for this, I'll make a fix along the lines you suggested and
> apply it to trunk this evening. Thank you for spending the time to
> investigate the issue and suggest the solution - much appreciated!
>
> -- Rob
>
> On 29 January 2015 at 16:52, MattiasÖ <[email protected]>
> wrote:
>
>> Hi!
>>
>> I have searched the archives for information on the following issue but
>> have
>> not found any. Please point me in the right direction if there is any :)
>>
>> I'm trying to achieve a connection towards a broker that only accepts AMQP
>> 1.0 over a TLS 1.2 connection.
>> In order to do this, I'm using the qpid-amqp-1-0-client-jms lib. However
>> as
>> far as I can see, this does not seem doable.
>>
>> I would like to know if this:
>> a) Is doable by some configuration of the lib that I haven't found?
>> b) Is a feature that is in the pipe to do, or can it be requested?
>> c) Is something that I could/should code a patch for and send in for a
>> review?
>>
>> Here are my technical findings on the issue:
>>
>> 1) I'm creating a Connection via
>> org.apache.qpid.amqp_1_0.jms.impl.ConnectionFactoryImpl
>> 2) ConnectionFactoryImpl uses org.apache.qpid.amqp_1_0.client.SSLUtil to
>> create a SSLContext using provided truststore, keystore etc..
>> 3) SSLUtil initiates a SSLContext with a hardcoded String:
>> TRANSPORT_LAYER_SECURITY_CODE = "TLS"
>> 4) In Oracle JDK 7, the file "<jdk installation
>> path>\jre\lib\security\java.security" register
>> com.sun.net.ssl.internal.ssl.Provider, an extension of
>> sun.security.ssl.SunJSSE, as the default JSSE provider. This class is, in
>> turn, configures that sun.security.ssl.SSLContextImpl$TLS10Context should
>> be
>> used as SSLContext for the alias "TLS".
>> 5) TLS10Context is only registering TLSv1 and SSLv3 as the default
>> protocols
>> to use.
>> 6) This means that when
>> org.apache.qpid.amqp_1_0.client.TCPTransportProvier
>> (which btw lacks a "d" in the name) is creating the underlying connection
>> between the qpid client and the broker, the SSLSocket only gets enabled
>> with
>> "TLSv1" and "SSLv3".
>>
>> I've tried to change TRANSPORT_LAYER_SECURITY_CODE to "TLSv1.2" and
>> recompile the qpid-amqp-1-0-client-jms lib and use this recompiled version
>> instead. This was working successfully and gave me a connection that can
>> connect to a broker configured with any of the following protocols
>> ["SSLv3",
>> "TLSv1", "TLSv1.1", "TLSv1.2"].
>> My next test is to once again use "TLS" in SSLUtil, but instead provide
>> ConnectionFactoryImpl with a list of protocols that I want to be enabled.
>> These will then be sent downwards through the stack to the
>> TCPTransportProvier that can apply these directly to the SSLSocket per
>> connection.
>>
>> All in all, can anyone involved tell me which of a, b or c above, is
>> correct
>> or should be done?
>>
>> Best regards,
>> Mattias
>>
>>
>>
>> --
>> View this message in context:
>> http://qpid.2158936.n2.nabble.com/qpid-amqp-1-0-client-jms-and-TLS-1-2-tp7619126.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]
>>
>>
>
