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.schumac...@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").
Regards
Felix
Regards,
Rainer