jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: SMTP Sampler and TLSv1.2/CipherSuites
Date Sun, 07 Jun 2015 17:56:07 GMT
Am 07.06.2015 um 18:59 schrieb Rainer Jung:
> Am 07.06.2015 um 17:32 schrieb Felix Schumacher:
>> Am 07.06.2015 um 15:24 schrieb Rainer Jung:
>>> Am 07.06.2015 um 15:16 schrieb sebb:
>>>> On 7 June 2015 at 13:10, Felix Schumacher
>>>> <felix.schumacher@internetallee.de> wrote:
>>>>> Am 07.06.2015 um 11:12 schrieb Rainer Jung:
>>>>>>
>>>>>> Am 06.06.2015 um 17:59 schrieb Felix Schumacher:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> to enable the SMPT Sampler to use a higher TLS version than 
>>>>>>> TLSv1 it
>>>>>>> seems to be necessary to change the SSLContext.getInstance call
in
>>>>>>> TrustAllSSLSocketFactory from "TLS" to "TLSv1.2".
>>>>>>
>>>>>>
>>>>>> Any idea why? When I test java HTTP connectivity, then "TLS" is
>>>>>> able to
>>>>>> connect TLSv1.2 if the JVM is new enough end the server supports
>>>>>> it. "TLS"
>>>>>> in getInstance() is not very wel documented, but in general seems
>>>>>> to support
>>>>>> al TLS versions trying to use the newest one supported by both 
>>>>>> sides.
>>>>>>
>>>>>> There's also the possibility to set enabledProtocols() which does

>>>>>> not
>>>>>> support the string "TLS", but only the explicit protocol versions.
>>>>>> But even
>>>>>> without setting enabled protocols and just sticking to defaults,I
>>>>>> can get a
>>>>>> TLSv1.2 (HTTP) connection with Java 8 and e.g. a TLSv1 connection
>>>>>> with Java
>>>>>> 6, both creating the SSLContext via getInstance("TLS").
>>>>>
>>>>> I have done my tests using java 7. When I repeated them with java 8
>>>>> (after I
>>>>> wrote the text below), I got the same results, as you reported. So
>>>>> it seems
>>>>> to be a problem with java 7 only.
>>>>>
>>>>>>
>>>>>> Is there a public SMTP server which can be used to observe the
>>>>>> problem you
>>>>>> see?
>>>>>
>>>>> I have used a docker image (catatnight/postfix) with self signed 
>>>>> certs.
>>>>> Instead of running it directly, I started a shell with it:
>>>>>
>>>>> $ docker run -ti -p 587:587  -e maildomain=whatever.local -e
>>>>> smtp_user=user:pwd -v "${PATH_TO_CERTS}":/etc/postfix/certs
>>>>> catatnight/postfix /bin/bash
>>>>>
>>>>> Inside the new prompt I used the install.sh script from the docker
>>>>> image, so
>>>>> that my keys get used and disabled every protocol except TLSv1.2:
>>>>>
>>>>> root@abc...:/# /opt/install.sh
>>>>> # Some message about missing dkim keys (can be ignored)
>>>>> root@abc...:/# postconf -e 'smtpd_tls_mandatory_protocols=TLSv1.2'
>>>>> root@abc...:/# service postfix start
>>>>> # Message that postfix started
>>>>>
>>>>> In another terminal I used openssl to connect to the server with
>>>>> TLSv1.2
>>>>> (success) and TLSv1.2 (no success) using:
>>>>>
>>>>> $ openssl s_client -tls1_2 -starttls smtp -connect localhost:587
>>>>> # ...
>>>>> # ---
>>>>> # 250 DSN
>>>>> quit
>>>>> $ openssl s_client -tls1_1 -starttls smtp -connect localhost:587
>>>>> # ...
>>>>> # ---
>>>>> $
>>>>>
>>>>> With this setup and the getInstance("TLS") I got no connection, while
>>>>> getInstance("TLSv1.2") gave me a connection.
>>>>>
>>>>> When I start the postfix server in its default configuration (every
>>>>> protocol
>>>>> allowed except SSLv2), JMeter is able to make a connection, but will
>>>>> use
>>>>> TLSv1 only.
>>>>>
>>>>> This test was done on ubuntu 14.04 LTS with OpenJDK 1.7.0_79. And
>>>>> after I
>>>>> wrote this text I repeated the tests with Oracles java versions
>>>>> 1.7.0_80,
>>>>> 1.8.0_45 and 1.9.0-ea-b66 where java 8 and 9 successfully created a
>>>>> connection with getInstance("TLS") and java 7 did not.
>>>>>
>>>>> So it seems to be a problem with java 7 and getInstance("TLS") only.
>>>>>
>>>>> Should we still add a system property to influence the selection of
>>>>> the used
>>>>> protocol?
>>>>
>>>> It won't do any harm, and might help some users, so I suggest we add
>>>> the property.
>>>
>>> Not that there's two knobs one can turn: the so called protocol used
>>> in getInstance() which can be a real protocol, but also the token
>>> "TLS", and the list or protocols passed to
>>> SSLSocket.enabledProtocols(). The interaction between the two is not
>>> well documented, but it might be better keeping protocol as TLS but
>>> explicitely enabling protocols via enabledProtocols. The supported
>>> protocols are available via getSupportedSSLParameters().getProtocols().
>>
>> After reading a bit more and doing some testing I think I have found an
>> easier solution, which is probably the correct way to do it.
>>
>> javamail has a property "mail.smtp.ssl.protocols" which takes a space
>> separated list of protocols, that can be used for a new connection. If I
>> set it to "SSLv3 TLSv1 TLSv1.1 TLSv1.2" then even my java 7 installation
>> will connect to a server that only supports TLSv1.2.
>>
>> I don't have to change getInstance("TLS").
>
> That makes sense to me. The Javadoc for that property says that the 
> values will be used in the call SSLSocket.setEnabledProtocols().
>
> The only problem is if we use a protocol name in the list which is 
> actually not supported by the JVM version. That would result likely in 
> a java.lang.IllegalArgumentException: TLSv1.1.
>
> Currently, since we want to demand Java 7, there's no difference 
> between the list for Java 7 and 8. The problem will show up sometime 
> in the future when TLS 1.3 becomes available. Maybe not important 
> enough for now. If you like you could instead use the list available 
> via SSLContext.getSupportedSSLParameters().getProtocols().
I have attached a patch which uses 
SSLContext.getDefault().getSupported... this version connects with java 
7 to my TLSv1.2 only postfix server.

Regards
  Felix
>
> Regards,
>
> Rainer
>
>


Mime
View raw message