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 <[email protected]> webtide.com <http://www.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 10:28 AM, Manpreet Singh <[email protected]> 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: [email protected] > [mailto:[email protected]] 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 > [email protected] > > > On Fri, Jun 13, 2014 at 10:28 AM, Joakim Erdfelt <[email protected]> > wrote: > > You do know that the entire Jetty 6 codebase was EOL (End of Life) > > back in 2010, right? > > > > -- > > Joakim Erdfelt <[email protected]> > > 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 > > <[email protected]> > > 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 > >> [email protected] > >> https://dev.eclipse.org/mailman/listinfo/jetty-users > >> > > > > > > _______________________________________________ > > jetty-users mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
