jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: SMTP Sampler and TLSv1.2/CipherSuites
Date Sun, 07 Jun 2015 16:59:17 GMT
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
>>> <> 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
>>>>>> 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 script from the docker
>>>> image, so
>>>> that my keys get used and disabled every protocol except TLSv1.2:
>>>> root@abc...:/# /opt/
>>>> # 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 



View raw message