Problem:
- Product Name: VisiBroker 6.5
- Client Platform: VisiBroker Client on Windows XP SP2
- Gatekeeper Platform: VisiBroker Gatekeeper on Redhat Linux
- Type of NAT Firewall: Microsoft ISA 2006 Server on Microsoft Windows Server™ 2003 operating system with Service Pack 1 (SP1) or Microsoft Windows Server 2003 R2 operating system JDK1.4.2
When Microsoft ISA Server 2006 is configured to be used as a proxy with authentication required between the client and the gatekeeper (on the server site), the application requests go unanswered. The client keeps on waiting for the proxy to answer its requests.
HIOPS, ISA Authentication
Client ----------------------------> ISA 2006 ---> Gatekeeper ---> Server
Resolution:
Root Cause of Problem
The cause of the problem is that in order to make an HTTPS connection through a proxy server, an SSL tunnel is first established with an HTTP CONNECT request to the proxy. This CONNECT request generated includes an incorrect Content-Length header, which causes some proxy servers such as ISA server to block waiting for the body of the request to be sent when there is in fact no body. And the client keeps on waiting for the proxy to answer so that it can send actual data... resulting in deadlock.
If both http and ISA authentication are enabled, the HTTP POST message is sent by the Browser and the Content-Length setting in the HTTP POST message does not cause any problem with ISA. An HTTP CONNECT message is only sent by the Browser when https and ISA authentication is enabled. e.g. a following CONNECT message is sent to the proxy:
CONNECT gk3-2.oebb.at:443 HTTP/1.1
Content-Type: application/x-hiop
VisiBroker: HIOP/1.0
Content-Length: 450
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.4.2_05
Host: gk3-2.oebb.at
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
The Content-Length of this request is incorrectly set to 450, when in fact a CONNECT message never has a body, and the Content-Length should either be 0, or absent. The Content-Length header causes the ISA proxy to block waiting to receive 450 bytes that the client will never send.
On further investigations, we have found it to be a JRE (jdk 1.4.2) bug, JRE should not set the Content-Length in a HTTP CONNECT message. The incorrect Content-Length header is the length of the message body which will be sent over the SSL tunnel to the destination server. It is finding its way into the initial CONNECT request because it is set as one of the MimeHeaders of the Message, and thus included in the HTTP headers of *all* outgoing messages by the Connection class. Please refer to following Sun Java BUG report at:
http://bugs.sun.com/view_bug.do?bug_id=6226610 (HTTP tunnel connections send user headers to proxy)
The same issue is reported through another bug, though the issue is about sending SOAP Message to ISA. In essence, the problem is similar. The bug report provides a detailed description for the issue: http://bugs.sun.com/view_bug.do?bug_id=6295485
Fixed in JRE 1.4.2_13
Please refer to JRE 1.4.2 release notes at:
http://www.oracle.com/technetwork/java/javase/releasenotes-138306.html for listing of all the fixes done in different JRE 1.4.2 plugins so far. It states that JRE 1.4.2_13 includes the requisite fix for this issue - Bug Id 6226610 (HTTP tunnel connections send user headers to proxy), but it introduces a small side effect:
Applet communication to the server through the proxy fails unless we use a signed applet or a policy file. This is a regression from all other earlier versions of java. This is reported through another Bug ID 6446855 (https connections failing when connecting through a proxy) - http://bugs.sun.com/view_bug.do?bug_id=6446855. But this fix is not available in any of JRE 1.4.2 patches yet.
Fixed in 1.5.0_08
Please refer to JRE 1.5.0 release notes at:
http://www.oracle.com/technetwork/java/javase/releasenotes-142123.html for listing of all the fixes done in different JRE 1.5.0 plugins so far. It states that JRE 1.5.0_08 has the fix for 6226610 (HTTP tunnel connections send user headers to proxy), so the HTTP CONNECT message send by JRE 1.5.0_08 and above does not contain the Content-Length header. Also, there is a fix for 6446855 provided in JRE 1.5.0_12.
Another possible workaround
If for some reasons, upgrading to above JRE plugins is not possible, then a workaround for using JRE plugins prior to 1.4.2_13 could be that ISA should ignore the Content-Length in a HTTP CONNECT message, but this has to be requested from Microsoft ISA team.
#HIOPS
#https
#gatekeeper
#Security
#isa
#VisiBroker