You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Felix Schumacher <fe...@internetallee.de> on 2015/06/06 17:59:59 UTC
SMTP Sampler and TLSv1.2/CipherSuites
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".
We can't make that value the default one, since I believe it will
prevent connections to servers with older TLS versions.
So it seems, we should make it configurable. Should this parameter be
made visible in the gui, or should we make it a system property?
The same thing is probably useful for the supported CipherSuites.
What do you think?
Felix
Re: SMTP Sampler and TLSv1.2/CipherSuites
Posted by Rainer Jung <ra...@kippdata.de>.
Looks good to me!
Am 07.06.2015 um 19:56 schrieb Felix Schumacher:
> 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
>>>>> <fe...@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
Re: SMTP Sampler and TLSv1.2/CipherSuites
Posted by Felix Schumacher <fe...@internetallee.de>.
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
>>>> <fe...@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
>
>
Re: SMTP Sampler and TLSv1.2/CipherSuites
Posted by Rainer Jung <ra...@kippdata.de>.
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
>>> <fe...@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().
Regards,
Rainer
Re: SMTP Sampler and TLSv1.2/CipherSuites
Posted by Felix Schumacher <fe...@internetallee.de>.
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
>> <fe...@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
>
Re: SMTP Sampler and TLSv1.2/CipherSuites
Posted by Rainer Jung <ra...@kippdata.de>.
Am 07.06.2015 um 15:16 schrieb sebb:
> On 7 June 2015 at 13:10, Felix Schumacher
> <fe...@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().
Regards,
Rainer
Re: SMTP Sampler and TLSv1.2/CipherSuites
Posted by sebb <se...@gmail.com>.
On 7 June 2015 at 13:10, Felix Schumacher
<fe...@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.
> Regards
> Felix
>>
>>
>> Regards,
>>
>> Rainer
>
>
Re: SMTP Sampler and TLSv1.2/CipherSuites
Posted by Felix Schumacher <fe...@internetallee.de>.
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?
Regards
Felix
>
> Regards,
>
> Rainer
Re: SMTP Sampler and TLSv1.2/CipherSuites
Posted by Rainer Jung <ra...@kippdata.de>.
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").
Is there a public SMTP server which can be used to observe the problem
you see?
Regards,
Rainer
Re: SMTP Sampler and TLSv1.2/CipherSuites
Posted by Milamber <mi...@apache.org>.
On 06/06/2015 17:28, Felix Schumacher wrote:
> Am 06.06.2015 um 18:14 schrieb Milamber:
>>
>>
>> On 06/06/2015 16:59, Felix Schumacher wrote:
>>> 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".
>>>
>>> We can't make that value the default one, since I believe it will
>>> prevent connections to servers with older TLS versions.
>>>
>>> So it seems, we should make it configurable. Should this parameter
>>> be made visible in the gui, or should we make it a system property?
>>
>> Must: As a jmeter property (in jmeter.properties file)
> That one is easy, so I will start with this option.
OK
>>
>> Better: In addition of the jmeter property, a combo list in the SMTP
>> sampler.
> The values for this depend on the capability of the jvm (jre?) but are
> probably static for a while. We could just assume that the only valid
> values are those listed in
> http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SSLContext
> and change that when needed, or get them by instantiating an
> SSLContext at runtime.
>
> The first option seems to be easy, the second one seems to be the more
> robust version.
>
> The second option might be a bit confusing, if I build the test plan
> with different jvms and the options change.
Perhaps, just one 'static' list: default, SSL (not secure), SSLv2 (not
secure), SSLv3 (not secure), TLS, TLSv1, TLSv1.1 and TLSv1.2, and
catching the exceptions if the jvm doesn't support the algorithm.
Like the HTTP methods, if, in the future, a new algorithm is needed, we
can add it to the list (or use the property with the new algorithm)
>
>>
>>
>>>
>>> The same thing is probably useful for the supported CipherSuites.
>>
>> Yes probably. But the list will be long I think.
> The list will be long and probably confusing for most people.
Perhaps, offer this option only by adding a new property.
>
> I wonder if most people would just want to specify exactly one
> CipherSuite, to test their setup and let the jvm decide in all other
> cases.
>
> Which leads me to another question.
>
> Should the CipherSuite and Protocol be stored in the SampleResult, so
> that one could assert on them?
No that's not a good idea, imho.
Milamber
>
> Regards
> Felix
>>
>>
>>>
>>> What do you think?
>>> Felix
>>>
>>
>
>
Re: SMTP Sampler and TLSv1.2/CipherSuites
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 06.06.2015 um 18:14 schrieb Milamber:
>
>
> On 06/06/2015 16:59, Felix Schumacher wrote:
>> 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".
>>
>> We can't make that value the default one, since I believe it will
>> prevent connections to servers with older TLS versions.
>>
>> So it seems, we should make it configurable. Should this parameter be
>> made visible in the gui, or should we make it a system property?
>
> Must: As a jmeter property (in jmeter.properties file)
That one is easy, so I will start with this option.
>
> Better: In addition of the jmeter property, a combo list in the SMTP
> sampler.
The values for this depend on the capability of the jvm (jre?) but are
probably static for a while. We could just assume that the only valid
values are those listed in
http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SSLContext
and change that when needed, or get them by instantiating an SSLContext
at runtime.
The first option seems to be easy, the second one seems to be the more
robust version.
The second option might be a bit confusing, if I build the test plan
with different jvms and the options change.
>
>
>>
>> The same thing is probably useful for the supported CipherSuites.
>
> Yes probably. But the list will be long I think.
The list will be long and probably confusing for most people.
I wonder if most people would just want to specify exactly one
CipherSuite, to test their setup and let the jvm decide in all other cases.
Which leads me to another question.
Should the CipherSuite and Protocol be stored in the SampleResult, so
that one could assert on them?
Regards
Felix
>
>
>>
>> What do you think?
>> Felix
>>
>
Re: SMTP Sampler and TLSv1.2/CipherSuites
Posted by Milamber <mi...@apache.org>.
On 06/06/2015 16:59, Felix Schumacher wrote:
> 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".
>
> We can't make that value the default one, since I believe it will
> prevent connections to servers with older TLS versions.
>
> So it seems, we should make it configurable. Should this parameter be
> made visible in the gui, or should we make it a system property?
Must: As a jmeter property (in jmeter.properties file)
Better: In addition of the jmeter property, a combo list in the SMTP
sampler.
>
> The same thing is probably useful for the supported CipherSuites.
Yes probably. But the list will be long I think.
>
> What do you think?
> Felix
>