jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

Jaroslav Bachorik
Please, review the following test change

Issue : https://bugs.openjdk.java.net/browse/JDK-8145919
Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.02

The previous attempt to fix this problem was focused on the fact that
the test tend to fail on ARM64 platforms. This is no more true, the
failure is reproducible on various platforms if using fastdebug build.

It turns out that the test is setting up SSL in a way that only RC4
cipher suites are to be used (the test keys are generated by this algo).
These cipher suites, however, has been disabled (JDK-8076221).

By all means the test should be failing since the RC4 test suites were
excluded. For some reason it started failing intermittently instead. I
will leave the exercise of figuring out why to someone with a thorough
expertise in SSL handshake.

The fix is straightforward - create new keys (and keystore and
truststore) using a supported cipher suite. I opted for the default one
(TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties for
the test to request this cipher suite. After this change the test is
passing regularly (tried running it 200 times in a loop - without any
failure).

Thanks,

-JB-
Reply | Threaded
Open this post in threaded view
|

jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

Jaroslav Bachorik
On 11.2.2016 11:39, Jaroslav Bachorik wrote:

> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919
> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.02
>
> The previous attempt to fix this problem was focused on the fact that
> the test tend to fail on ARM64 platforms. This is no more true, the
> failure is reproducible on various platforms if using fastdebug build.
>
> It turns out that the test is setting up SSL in a way that only RC4
> cipher suites are to be used (the test keys are generated by this algo).
> These cipher suites, however, has been disabled (JDK-8076221).
>
> By all means the test should be failing since the RC4 test suites were
> excluded. For some reason it started failing intermittently instead. I
> will leave the exercise of figuring out why to someone with a thorough
> expertise in SSL handshake.
>
> The fix is straightforward - create new keys (and keystore and
> truststore) using a supported cipher suite. I opted for the default one
> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties for
> the test to request this cipher suite. After this change the test is
> passing regularly (tried running it 200 times in a loop - without any
> failure).
>
> Thanks,
>
> -JB-

Reply | Threaded
Open this post in threaded view
|

Re: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

Daniel Fuchs
Hi Jaroslav,

I have no objection to this change.

Could you add a comment somewhere to explain how you
generated the truststore and keystore - in case we need
to tweak that again in the future?

best regards,

-- daniel

On 16/02/16 10:41, Jaroslav Bachorik wrote:

> On 11.2.2016 11:39, Jaroslav Bachorik wrote:
>> Please, review the following test change
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.02
>>
>> The previous attempt to fix this problem was focused on the fact that
>> the test tend to fail on ARM64 platforms. This is no more true, the
>> failure is reproducible on various platforms if using fastdebug build.
>>
>> It turns out that the test is setting up SSL in a way that only RC4
>> cipher suites are to be used (the test keys are generated by this algo).
>> These cipher suites, however, has been disabled (JDK-8076221).
>>
>> By all means the test should be failing since the RC4 test suites were
>> excluded. For some reason it started failing intermittently instead. I
>> will leave the exercise of figuring out why to someone with a thorough
>> expertise in SSL handshake.
>>
>> The fix is straightforward - create new keys (and keystore and
>> truststore) using a supported cipher suite. I opted for the default one
>> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties for
>> the test to request this cipher suite. After this change the test is
>> passing regularly (tried running it 200 times in a loop - without any
>> failure).
>>
>> Thanks,
>>
>> -JB-
>

Reply | Threaded
Open this post in threaded view
|

Re: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

Jaroslav Bachorik
On 16.2.2016 11:56, Daniel Fuchs wrote:
> Hi Jaroslav,
>
> I have no objection to this change.
>
> Could you add a comment somewhere to explain how you
> generated the truststore and keystore - in case we need
> to tweak that again in the future?

I've added a simple readme file next to the keystores.

http://cr.openjdk.java.net/~jbachorik/8145919/webrev.03

-JB-

>
> best regards,
>
> -- daniel
>
> On 16/02/16 10:41, Jaroslav Bachorik wrote:
>> On 11.2.2016 11:39, Jaroslav Bachorik wrote:
>>> Please, review the following test change
>>>
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.02
>>>
>>> The previous attempt to fix this problem was focused on the fact that
>>> the test tend to fail on ARM64 platforms. This is no more true, the
>>> failure is reproducible on various platforms if using fastdebug build.
>>>
>>> It turns out that the test is setting up SSL in a way that only RC4
>>> cipher suites are to be used (the test keys are generated by this algo).
>>> These cipher suites, however, has been disabled (JDK-8076221).
>>>
>>> By all means the test should be failing since the RC4 test suites were
>>> excluded. For some reason it started failing intermittently instead. I
>>> will leave the exercise of figuring out why to someone with a thorough
>>> expertise in SSL handshake.
>>>
>>> The fix is straightforward - create new keys (and keystore and
>>> truststore) using a supported cipher suite. I opted for the default one
>>> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties for
>>> the test to request this cipher suite. After this change the test is
>>> passing regularly (tried running it 200 times in a loop - without any
>>> failure).
>>>
>>> Thanks,
>>>
>>> -JB-
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

Daniel Fuchs
Thanks Jaroslav, that's great!

If these certificates have an expiration date then
it's possible that we will have to regenerate them
from time to time...

cheers,

-- daniel

On 17/02/16 13:13, Jaroslav Bachorik wrote:

> On 16.2.2016 11:56, Daniel Fuchs wrote:
>> Hi Jaroslav,
>>
>> I have no objection to this change.
>>
>> Could you add a comment somewhere to explain how you
>> generated the truststore and keystore - in case we need
>> to tweak that again in the future?
>
> I've added a simple readme file next to the keystores.
>
> http://cr.openjdk.java.net/~jbachorik/8145919/webrev.03
>
> -JB-
>
>>
>> best regards,
>>
>> -- daniel
>>
>> On 16/02/16 10:41, Jaroslav Bachorik wrote:
>>> On 11.2.2016 11:39, Jaroslav Bachorik wrote:
>>>> Please, review the following test change
>>>>
>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919
>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.02
>>>>
>>>> The previous attempt to fix this problem was focused on the fact that
>>>> the test tend to fail on ARM64 platforms. This is no more true, the
>>>> failure is reproducible on various platforms if using fastdebug build.
>>>>
>>>> It turns out that the test is setting up SSL in a way that only RC4
>>>> cipher suites are to be used (the test keys are generated by this
>>>> algo).
>>>> These cipher suites, however, has been disabled (JDK-8076221).
>>>>
>>>> By all means the test should be failing since the RC4 test suites were
>>>> excluded. For some reason it started failing intermittently instead. I
>>>> will leave the exercise of figuring out why to someone with a thorough
>>>> expertise in SSL handshake.
>>>>
>>>> The fix is straightforward - create new keys (and keystore and
>>>> truststore) using a supported cipher suite. I opted for the default one
>>>> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties for
>>>> the test to request this cipher suite. After this change the test is
>>>> passing regularly (tried running it 200 times in a loop - without any
>>>> failure).
>>>>
>>>> Thanks,
>>>>
>>>> -JB-
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

Jaroslav Bachorik
Hi,

On 17.2.2016 14:41, Daniel Fuchs wrote:
> Thanks Jaroslav, that's great!
>
> If these certificates have an expiration date then
> it's possible that we will have to regenerate them
> from time to time...

Thanks for checking on this. I've update the certificates to have
expiration date 100 years from now (should be sufficient for now) and
updated the readme with the validity parameter.

Also, I've rebased the patch against jdk9/dev since this test has been
excluded there and it makes sense to include it back when it is fixed.

http://cr.openjdk.java.net/~jbachorik/8145919/webrev.04

-JB-

>
> cheers,
>
> -- daniel
>
> On 17/02/16 13:13, Jaroslav Bachorik wrote:
>> On 16.2.2016 11:56, Daniel Fuchs wrote:
>>> Hi Jaroslav,
>>>
>>> I have no objection to this change.
>>>
>>> Could you add a comment somewhere to explain how you
>>> generated the truststore and keystore - in case we need
>>> to tweak that again in the future?
>>
>> I've added a simple readme file next to the keystores.
>>
>> http://cr.openjdk.java.net/~jbachorik/8145919/webrev.03
>>
>> -JB-
>>
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 16/02/16 10:41, Jaroslav Bachorik wrote:
>>>> On 11.2.2016 11:39, Jaroslav Bachorik wrote:
>>>>> Please, review the following test change
>>>>>
>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919
>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.02
>>>>>
>>>>> The previous attempt to fix this problem was focused on the fact that
>>>>> the test tend to fail on ARM64 platforms. This is no more true, the
>>>>> failure is reproducible on various platforms if using fastdebug build.
>>>>>
>>>>> It turns out that the test is setting up SSL in a way that only RC4
>>>>> cipher suites are to be used (the test keys are generated by this
>>>>> algo).
>>>>> These cipher suites, however, has been disabled (JDK-8076221).
>>>>>
>>>>> By all means the test should be failing since the RC4 test suites were
>>>>> excluded. For some reason it started failing intermittently instead. I
>>>>> will leave the exercise of figuring out why to someone with a thorough
>>>>> expertise in SSL handshake.
>>>>>
>>>>> The fix is straightforward - create new keys (and keystore and
>>>>> truststore) using a supported cipher suite. I opted for the default
>>>>> one
>>>>> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties
>>>>> for
>>>>> the test to request this cipher suite. After this change the test is
>>>>> passing regularly (tried running it 200 times in a loop - without any
>>>>> failure).
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -JB-
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

Daniel Fuchs
Hi Jaroslav,

Looks good.

BTW - shouldn't you take
sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java
out of the problem list as well?
I see that 8147985 is fixed.

best regards,

-- daniel

On 18/02/16 09:48, Jaroslav Bachorik wrote:

> Hi,
>
> On 17.2.2016 14:41, Daniel Fuchs wrote:
>> Thanks Jaroslav, that's great!
>>
>> If these certificates have an expiration date then
>> it's possible that we will have to regenerate them
>> from time to time...
>
> Thanks for checking on this. I've update the certificates to have
> expiration date 100 years from now (should be sufficient for now) and
> updated the readme with the validity parameter.
>
> Also, I've rebased the patch against jdk9/dev since this test has been
> excluded there and it makes sense to include it back when it is fixed.
>
> http://cr.openjdk.java.net/~jbachorik/8145919/webrev.04
>
> -JB-
>
>>
>> cheers,
>>
>> -- daniel
>>
>> On 17/02/16 13:13, Jaroslav Bachorik wrote:
>>> On 16.2.2016 11:56, Daniel Fuchs wrote:
>>>> Hi Jaroslav,
>>>>
>>>> I have no objection to this change.
>>>>
>>>> Could you add a comment somewhere to explain how you
>>>> generated the truststore and keystore - in case we need
>>>> to tweak that again in the future?
>>>
>>> I've added a simple readme file next to the keystores.
>>>
>>> http://cr.openjdk.java.net/~jbachorik/8145919/webrev.03
>>>
>>> -JB-
>>>
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>> On 16/02/16 10:41, Jaroslav Bachorik wrote:
>>>>> On 11.2.2016 11:39, Jaroslav Bachorik wrote:
>>>>>> Please, review the following test change
>>>>>>
>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919
>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.02
>>>>>>
>>>>>> The previous attempt to fix this problem was focused on the fact that
>>>>>> the test tend to fail on ARM64 platforms. This is no more true, the
>>>>>> failure is reproducible on various platforms if using fastdebug
>>>>>> build.
>>>>>>
>>>>>> It turns out that the test is setting up SSL in a way that only RC4
>>>>>> cipher suites are to be used (the test keys are generated by this
>>>>>> algo).
>>>>>> These cipher suites, however, has been disabled (JDK-8076221).
>>>>>>
>>>>>> By all means the test should be failing since the RC4 test suites
>>>>>> were
>>>>>> excluded. For some reason it started failing intermittently
>>>>>> instead. I
>>>>>> will leave the exercise of figuring out why to someone with a
>>>>>> thorough
>>>>>> expertise in SSL handshake.
>>>>>>
>>>>>> The fix is straightforward - create new keys (and keystore and
>>>>>> truststore) using a supported cipher suite. I opted for the default
>>>>>> one
>>>>>> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties
>>>>>> for
>>>>>> the test to request this cipher suite. After this change the test is
>>>>>> passing regularly (tried running it 200 times in a loop - without any
>>>>>> failure).
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -JB-
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

Jaroslav Bachorik
On 18.2.2016 10:40, Daniel Fuchs wrote:
> Hi Jaroslav,
>
> Looks good.
>
> BTW - shouldn't you take
> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java
> out of the problem list as well?
> I see that 8147985 is fixed.

Sure, but that will have to be a different changeset and a different review.

Thanks for reviewing this!

-JB-

>
> best regards,
>
> -- daniel
>
> On 18/02/16 09:48, Jaroslav Bachorik wrote:
>> Hi,
>>
>> On 17.2.2016 14:41, Daniel Fuchs wrote:
>>> Thanks Jaroslav, that's great!
>>>
>>> If these certificates have an expiration date then
>>> it's possible that we will have to regenerate them
>>> from time to time...
>>
>> Thanks for checking on this. I've update the certificates to have
>> expiration date 100 years from now (should be sufficient for now) and
>> updated the readme with the validity parameter.
>>
>> Also, I've rebased the patch against jdk9/dev since this test has been
>> excluded there and it makes sense to include it back when it is fixed.
>>
>> http://cr.openjdk.java.net/~jbachorik/8145919/webrev.04
>>
>> -JB-
>>
>>>
>>> cheers,
>>>
>>> -- daniel
>>>
>>> On 17/02/16 13:13, Jaroslav Bachorik wrote:
>>>> On 16.2.2016 11:56, Daniel Fuchs wrote:
>>>>> Hi Jaroslav,
>>>>>
>>>>> I have no objection to this change.
>>>>>
>>>>> Could you add a comment somewhere to explain how you
>>>>> generated the truststore and keystore - in case we need
>>>>> to tweak that again in the future?
>>>>
>>>> I've added a simple readme file next to the keystores.
>>>>
>>>> http://cr.openjdk.java.net/~jbachorik/8145919/webrev.03
>>>>
>>>> -JB-
>>>>
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>>> On 16/02/16 10:41, Jaroslav Bachorik wrote:
>>>>>> On 11.2.2016 11:39, Jaroslav Bachorik wrote:
>>>>>>> Please, review the following test change
>>>>>>>
>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919
>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.02
>>>>>>>
>>>>>>> The previous attempt to fix this problem was focused on the fact
>>>>>>> that
>>>>>>> the test tend to fail on ARM64 platforms. This is no more true, the
>>>>>>> failure is reproducible on various platforms if using fastdebug
>>>>>>> build.
>>>>>>>
>>>>>>> It turns out that the test is setting up SSL in a way that only RC4
>>>>>>> cipher suites are to be used (the test keys are generated by this
>>>>>>> algo).
>>>>>>> These cipher suites, however, has been disabled (JDK-8076221).
>>>>>>>
>>>>>>> By all means the test should be failing since the RC4 test suites
>>>>>>> were
>>>>>>> excluded. For some reason it started failing intermittently
>>>>>>> instead. I
>>>>>>> will leave the exercise of figuring out why to someone with a
>>>>>>> thorough
>>>>>>> expertise in SSL handshake.
>>>>>>>
>>>>>>> The fix is straightforward - create new keys (and keystore and
>>>>>>> truststore) using a supported cipher suite. I opted for the default
>>>>>>> one
>>>>>>> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties
>>>>>>> for
>>>>>>> the test to request this cipher suite. After this change the test is
>>>>>>> passing regularly (tried running it 200 times in a loop - without
>>>>>>> any
>>>>>>> failure).
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -JB-
>>>>>>
>>>>>
>>>>
>>>
>>
>