PQ66547: WEBSPHERE APP SERVER CREATES A NEW SSL CONNECTION FOR EACH REQUEST WHEN MAKING CONNECTIONS TO ANOTHER SYSTEM USING JSSE.

 A fix is available

4.0.5: WebSphere Application Server Version 4.0 Fix Pack 5 (Version 4.0.5)



APAR status
Closed as program error.

Error description
Environment:
WebSphere Application Server 4.0.4 AE
IHS 1.3.19.3 (Part of WebSphere Application Server 4.0.4
installation) Solaris 8
We use the default java environment, that shippes with
  WebSphere Application Server 4.0.
Description:
When the Application Server or an Application deployed into
the Application Server make SSL connections
to another system using JSSE, then there is following behavior:
.
The program creates a new SSL connection for each request,
including
performing a new SSL handshake.
.
The correct behavior (in our opinion) is, that multiple
requests reuse
existing established SSL connections.
.
We have a test application testing these variants, and the
result for
the test application is,
that a request takes average 20 milliseconds with reusing, and
200 milliseconds without reusing SSL
connections.
.
To test the case with reusing of SSL connections, we got a patch
from
IBM for the JSSE
.
with following version informations:
-------------------------------------------------------
IBM Security Software Development Kit, Java (tm) Technology
Edition
JSSE Components
(C) Copyright IBM Corp. 1999, 2002 All Rights Reserved.
Build:  20020701
.
-------------------------------------------------------
.
This patch does work, but customer needs to have a version
of this that is supported for WebSphere Application Server 4.04.
.
Developer response:
.
"In the past after pulling in a new version of JSSE, our team
saw 4
severe problems with
respect to IKeyMan and opening of SSL sockets. After sniff
testing I
will be in a better
position to recommend pulling in JSSE v 1.0.3 into ASV4 ptf5
build."
.
 The change requested is one that has a high risk factor in
affecting
the functionality of other parts of the component and causing
instability. The developers must undergo rigorous testing to
minimize
the possibility that the new addition will cause further
defects. Being
involved in software development, you probably understand why
this is
the way it is.
.
Customer was asked for a specific deadline. They responded:
.
currently we can run the one problematic application on another
application server.
on december 13., we scheduled another application deployment,
which can
not run on our "emergency"-environment.
.
based on your last information, we think as follows:
.
an individual efix will have a higher risk than e.g. fixpack 5,
because
an individual efix has reduced testing.
so, if fixpack 5 will contain a fix for the given problem, and
will
really arrive around end of november,
then we maybe would prefer waiting.
What we prefer, and how many days in advance of december 13 we
require a
solution, will be clarified this week.
This decision will be made in a decision board that is talking
this friday.
.
As was spoken in our previous phone call, if we require an
efix, it will be
ok to have it tested against the jdk only.
.
if we request an efix, it depends on a decision board from us
tomorrow.
.
if we request the efix tomorrow, I will ask the following
question:
if we use the efix in our application, would the risk be
minimized by
choosing specific classpath visibility modes ?
(IMHO this could reduce interfering between WebSphere and the
applciation
by giving each one a distinct jsse)
if answer is yes, which classpath mode should we use ?
.
Your question could be misunderstood by us, so I will try to
describe
it, as we understand it.
tested with JDK means, that JSSE will be tested against "normal
Java
applications (J2SE).
It will not be completely tested or guaranteed that the JSSE in
the eFix
can be used for WebSphere itnernal use of JSSE (e.g. for
handling of
iiops and ldaps) safely.
To use the JSSE eFix safely wihtin an application it would be
necessary,
that the application uses specific classloader visibility modes
and use
the JSSE contained in the eFix, while the WebSphere Application
Server
will still use the already existing JSSE version.
Did we understood correct ?
.
We would like you to provide an eFix that will be tested with
J2SE asap.
We would like you to provide a release date for this eFix asap.
.
Because we will use iiops, ldaps, and https with the Applicatio
Server,
even with the fix described above we are still concerned about
performance.
So we want to ask, if there is a way, that after some time we
could get
a more general JSSE eFix, that can be used f r Webphere
Application
Server and Applications, without restrictions to classpath
visibility.
If this is possible, how long would it take, roundabaout
(4,8,12,12+
weeks) ?
.
Also I want to ask about Fixpack release dates.
At what time, even if you can only provide roundabouts, will
Fixpack5 be
general available ?
At what time, roundabout, could Fixpack6 be available ? (our
current
assumptions are march 2003, is this optimistic or pessimistic ?
.
If an acceptable complete solution date will be not in sight
until next
friday, customer's decision board will make further decision on
how to
deal with the situation.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: All the users of ASV40X will be affected     *
*                 due to performance degradation while opening *
*                 SSL sockets using ibmjsse.zip. The SSL       *
*                 connections are not being reused as they     *
*                 should be.                                   *
****************************************************************
* PROBLEM DESCRIPTION: When WebSphere or an Application        *
*                      deployed in WebSphere makes SSL         *
*                      connections to another system using     *
*                      JSSE, then following behaviour is       *
*                      observed:                               *
*                      The program creates a new SSL           *
*                      connection for each request,            *
*                      including performing a new SSL          *
*                      handshake. The correct behaviour is     *
*                      that multiple requests reuse            *
*                      existing established SSL connections.   *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
WAS CREATES A NEW SSL CONNECTION FOR EACH REQUEST WHEN MAKING
CONNECTIONS TO ANOTHER SYSTEM USING JSSE.The correct behaviour
is to reuse the SSL connections. Using a test application
to test the two variations, the results were that a request
takes average 20 milliseconds with reusing, and 200
milliseconds without reusing SSL.
Problem conclusion
A new JSSE (v1.0.3_20021009) resolves the issue.
Inernal defects 150199, 150199.1 and 150199.2 were used to
include the new JSSE within WebSphere.

Defect 150406 handles coexistenace issues between IKeyMan
for JSSE and IHS.

Defect 150406.1 handles packaging issues.
Temporary fix Comments
APAR information
APAR number PQ66547
Reported component name WEBSPHERE AE SO
Reported component ID 5630A2202
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2002-09-24
Closed date 2002-10-30
Last modified date 2003-04-30

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros

SRLS

Fix information
Fixed component name WEBSPHERE AE SO
Fixed component ID 5630A2202

Applicable component levels
R400 PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ66547
IBM Group: Software Group
Modified date: Apr 30, 2003