United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6446855 https connections failing when connecting through a proxy
6446855 : https connections failing when connecting through a proxy

Details
Type:
Bug
Submit Date:
2006-07-07
Status:
Closed
Updated Date:
2011-05-18
Project Name:
JDK
Resolved Date:
2011-05-18
Component:
core-libs
OS:
solaris_8,windows_xp
Sub-Component:
java.net
CPU:
x86,sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.0_01,1.4.2_05,5.0,5.0u10
Fixed Versions:
7

Related Reports
Backport:
JDK-2147357 - https connections failing when connecting through a proxy
Backport:
JDK-2147925 - https connections failing when connecting through a proxy
Backport:
JDK-2171390 - https connections failing when connecting through a proxy
Backport:
JDK-2172640 - https connections failing when connecting through a proxy
Duplicate:
JDK-5075841 - HttpURLConnection through a proxy sometimes fails when keepalives are enabled

Sub Tasks

Description
FULL PRODUCT VERSION :
JRE 1.5.0_01 through 1.5.0_07

A DESCRIPTION OF THE PROBLEM :
Using IE browser or Mozilla firefox with a proxy setting pointing to a ISA proxy server on port 8080. The ISA proxy server has either Basic authentication OR, integrated windows authentication enabled. When the applet connection is being made with a secure (SSL) https connection - the connection fails with a security exception. This has been successfully working for our applet for years across all jre's. And works up to the introduction of 1.5.0_01 (yes it still works with 1.5.0).

If we sign the applet it solves the problem, or if we use http instead of https, or if we roll back to 1.4.x o 1.5.0. None of these are valid workarounds as we provide solutions across all types of scenarios. And yes we understand updating the policy file could solve this issue as well but again we cannot require our customer base to have to make changes to use our applet.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Using IE browser or Mozilla firefox with a proxy setting pointing to a ISA proxy server on port 8080. The ISA proxy server has either Basic authentication OR, integrated windows authentication enabled. Use https protocol for communcation.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Applet communication to the server should not require a signed applet or a policy file.  This is a regression from all other earlier versions of java.
ACTUAL -
Applet communication to the server through the proxy fails.

ERROR MESSAGES/STACK TRACES THAT OCCUR :

This is the exception with tracing enabled:

network: Connecting https://content1.skillsoft.com/contentlib6/Content/scp/en/PlayerStrings.properties with proxy=HTTP @ /10.20.99.254:8080
network: Connecting https://content1.skillsoft.com/skins/default_35bs4ssl_pc/21948.properties with proxy=HTTP @ /10.20.99.254:8080
network: Connecting https://content1.skillsoft.com/skins/default_35bs4ssl_pc/courseinfo.properties with proxy=HTTP @ /10.20.99.254:8080
java.security.AccessControlException: access denied (java.net.SocketPermission QAPROXY:8080 connect,resolve)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.proxiedConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.doTunneling(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
at java.net.URL.openStream(Unknown Source)
at com.skillsoft.shared.player.SecurityManager.f(Unknown Source)
at com.skillsoft.shared.player.PlayerContext.cb(Unknown Source)
at com.skillsoft.shared.player.PlayerContext.d(Unknown Source)
at com.skillsoft.shared.player.PlayerContext.b(Unknown Source)
at com.skillsoft.legacy.player.PlayerAppletContext.b(Unknown Source)
at com.skillsoft.legacy.player.PlayerAppletContext.<init>(Unknown Source)
at com.skillsoft.legacy.player.PlayerAppletContext.a(Unknown Source)
at com.skillsoft.legacy.player.PagePlayer.init(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
I can provide a launch site with the issue if necessary.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Signing the applet, creating a policy file, using http (instead of https) or rolling back to 1.5.0 or 1.4.2.x all solves the problem but are not acceptable workarounds for a commercial applet.

Release Regression From : 5.0
The above release value was the last known release where this  
bug was not reproducible. Since then there has been a regression.

Comments
EVALUATION

This issue can be reproduced with mustang and is not confined to ntlm authentication. Server names changed.

A simply test shows the problem.
------------------------------------
import java.net.*;
import javax.net.ssl.*;
import java.io.*;

public class TestTunnel
{
    public static void main(String[] args) throws IOException {
	Authenticator.setDefault(new MyAuthenticator());

	URL url = new URL("https://lightning:8443/servlet/EditRequest");
	HttpsURLConnection uc = (HttpsURLConnection) url.openConnection();
	uc.connect();
    }

    static class MyAuthenticator extends Authenticator
    {
	public PasswordAuthentication getPasswordAuthentication() {
	    return new PasswordAuthentication("tester", "tester".toCharArray()); 
	}
    }
}
------------------------------------
with the following policy file:
 grant {
    permission java.net.NetPermission "setDefaultAuthenticator";
    permission java.net.SocketPermission "lightning:8443", "connect,resolve";
 };
 
I have squid running on abcd:3128 with basic authentication enabled. efgh:8080 is an open proxy.

RUN THROUGH ABCD PROXY:
java -Dhttps.proxyHost=abcd -Dhttps.proxyPort=3128
     -Djava.security.manager -Djava.security.policy=.java.policy
     TestTunnel

Output:
Exception in thread "main" java.security.AccessControlException: access denied (java.net.SocketPermission abcd:3128 connect,resolve)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        at java.security.AccessController.checkPermission(AccessController.java:546)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at java.lang.SecurityManager.checkConnect(SecurityManager.java:1034)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.proxiedConnect(AbstractDelegateHttpsURLConnection.java:132)
        at sun.net.www.protocol.http.HttpURLConnection.doTunneling(HttpURLConnection.java:1365)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:168)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133)
        at TestTunnel.main(TestTunnel.java:14)


RUN THROUGH EFGH PROXY:
java -Dhttps.proxyHost=efgh -Dhttps.proxyPort=8080
     -Djava.security.manager -Djava.security.policy=.java.policy
     TestTunnel

Output:
  Exception in thread "main" javax.net.ssl.SSLHandshakeException:....

  This exception is an issue with cert validation. It proves that the
  tunnel has been created successfully. We do not need to complete the
  connection.

In the first case, running through abdc proxy, if you make a http connection before trying the https connection, the https connection may not throw the security exception. The authenticated connection to abdc from the first request may be retrieved from the cache and reused for the tunnel. Be careful here as basic authentication scheme supports preemptive authentication and this could be confusing your test results!

Solution:
  We need to determine proxies being passed in by the user versus proxies retrieved from the ProxySelector in ( or before ) AbstractDelegateHttpsURLConnection.proxiedConnect and not run the security check on the latter.
2006-08-25 
EVALUATION

Close as there is no reproducible test case.
2006-08-11 
EVALUATION

Based on customer's note, I point my browser to a proxy authentication server, still can't reproduce the bug, please send us your testcase and configuration so that we can do more evaluation.
2006-08-03


Hardware and Software, Engineered to Work Together