Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] jetty 6.1.26 (SSL session timeout)
SSL Session reuse was broken by Oracle in Java 6u10 (as part of a giant change for SSL in the browser plugin)

There have been numerous bugs filed against SSL Sessions against Java 6.
From memory leaks preventing SSL Session timeout, to bad SSL session putValue where the internal maps don't get updated or trigger ConcurrentModificationExceptions, to timeout configuration issues, and even cross session resume bugs.

They have fixed most of them, but _not_ for Java 6.
All of the fixes have been for Java 7, and none of them have been backported to Java 6.
There are no hacks or workarounds for the bugs, even replacing the SSL providers with things like BSAFE / BouncyCastle make no difference.
I can find no reports of custom Java 6 builds with these fixes in place.
I can also find no (success or failure) stories with using alternate Java 6 VM's (like IBM's).

If you do chose to upgrade to Java 7, be sure you start with update 25 or newer (and skip update 40 entirely).


--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts


On Fri, Jun 13, 2014 at 10:28 AM, Manpreet Singh <manpreet.singh@xxxxxxx> wrote:
Thanks for the prompt response!! We have really exhausted all our
resources. Upgrading Jetty is definitely not an option as our software is
running on a huge number of remote devices.

We are using JDK 6. And supply jre 1.6.0_22 with our deployment. When we
keep the idleTimeout as default (20 seconds), the SSL handshake takes
place after 20 seconds. If we keep the idleTimeout greater than 2 minutes,
then it does not fail on 20 seconds but also does not wait till the actual
idleTimeout.  It always sends closeOutbound() after 2 minutes and a few
seconds.


-----Original Message-----
From: jetty-users-bounces@xxxxxxxxxxx
[mailto:jetty-users-bounces@xxxxxxxxxxx] On Behalf Of Jesse McConnell
Sent: 13 June 2014 21:13
To: JETTY user mailing list
Subject: Re: [jetty-users] jetty 6.1.26 (SSL session timeout)

Commercial support is available on all previous versions of Jetty at
http://webtide.com and we typically spend our open source support time
helping folks with the newer versions of Jetty either here, on
stackoverflow or where ever we run across interesting issues :)

That being said, I would start by looking at the SSLEngine and see what
sort of options are available.. I suspect you are using a very old jdk as
well so not sure what settings were available back then.

cheers,
jesse


--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Fri, Jun 13, 2014 at 10:28 AM, Joakim Erdfelt <joakim@xxxxxxxxxxx>
wrote:
> You do know that the entire Jetty 6 codebase was EOL (End of Life)
> back in 2010, right?
>
> --
> Joakim Erdfelt <joakim@xxxxxxxxxxx>
> webtide.com - intalio.com/jetty
> Expert advice, services and support from from the Jetty & CometD
> experts eclipse.org/jetty - cometd.org
>
>
> On Fri, Jun 13, 2014 at 7:36 AM, Manpreet Singh
> <manpreet.singh@xxxxxxx>
> wrote:
>>
>> We are using jetty-6.1.26 HTTP client to post messages to an
>> Microsoft IIS Server using client certificate based authentication.
>>
>>
>>
>> The code fragment used is as below:
>>
>>
>>
>>
>> httpClient.setConnectorType(HttpClient.CONNECTOR_SELECT_CHANNEL);
>>
>>         httpClient.setMaxConnectionsPerAddress(1);
>>
>>         httpClient.setMaxRetries(0);
>>
>>         httpClient.setSoTimeout(soTimeout);
>>
>>         httpClient.setTimeout(timeout);
>>
>>             httpClient.setKeyStoreLocation(ksl);
>>
>>             httpClient.setKeyStorePassword(ksp);
>>
>>             httpClient.setKeyManagerPassword(kmp);
>>
>>
>>
>>         contentExchange = new ContentExchange(true);
>>
>>         contentExchange.setRetryStatus(false);
>>
>>
>>
>> int result = contentExchange.waitForDone();
>>
>>                         if(result ==  HttpExchange.STATUS_COMPLETED)
>>
>>                         {
>>
>>
>>
>>
>>
>> We use the httpclient to post data to the server frequently. Since
>> this software is on low bandwidth connection, we would like to resume
>> SSL session and not incur the overhead of SSL handshake every time we
send data.
>>
>>
>>
>> We have tried to increase the idleTimeout parameter to large values,
>> but it seems the SSL session expires always after 2 minutes and few
>> seconds no matter what settings we maintain. Following is what we get
>> in the javax.net.debug trace after this session expires and then
>> again the complete SSL handshake takes place that is a lot of data to
>> and fro on low BW connections.
>>
>>
>>
>> 1633060093@HttpClient-3, called closeOutbound()
>>
>> 1633060093@HttpClient-3, closeOutboundInternal()
>>
>> 1633060093@HttpClient-3, SEND TLSv1 ALERT:  warning, description =
>> close_notify
>>
>>
>>
>> Can someone help us to figure out a correct way to do this?
>>
>>
>>
>>
>>
>> Thanks a lot in advance!!
>>
>>
>>
>>
>> _______________________________________________
>> jetty-users mailing list
>> jetty-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>
>
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users

Back to the top