PQ66547: WEBSPHERE APP SERVER CREATES A NEW SSL CONNECTION FOR EACH REQUEST WHEN MAKING CONNECTIONS TO ANOTHER SYSTEM USING JSSE. | |||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||
![]() 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 is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros SRLS
|
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
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.