https connections failing when connecting through a proxy with 1.5.0_01
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.
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)
[2926 byte] By [
suzannepa] at [2007-10-2 23:31:08]
You seem to have identified all the possible solutions. Sun seem to have fixed a security hole in HTTPS in 1.5.0_01.Signing the applet seems like the least painful solution.
ejpa at 2007-7-14 16:11:50 >
I've looked through the release notes for 1.5.0_01 and cannot find anything indicating that they fixed a security hole that would cause this. And what "security" rule are we breaking? We are talking to the same server, just through a proxy.
It seems like it's a combination of http and https - that perhaps the header for the proxy communication is using http instead of the secure https.
The security hole seems to have been that permission to connect to the proxy host/port wasn't checked for https connections (but it probably was for http connections).What goes over the wire is always HTTP: https just puts the same stuff over SSL (and adds more header fields).
ejpa at 2007-7-14 16:11:50 >
Well this is definitely a sun bug and not a security hole patch. I have more information on this issue.
My applet connects to the proxy server and downloads all sorts of files, class files and property files etc. It then tries to access a file that may or may not be there - so it gets a file not found exception if it doesn't exist. The applet handles that nicely - and then moves on. The very next file it tries to access we get an security access denied - even though it's on the same server - through the same proxy and the file exists.
If I throw in a dummy file so i don't get the file not found exception - the applet moves along merrily and gets beyond the access denied exception - until it comes across another snafu.
Opening and closing a url connection without reading off the input stream (just to validate if the file is there) - works - until you try to open another url input stream - then you get the security exception on that file.
Once I worked through that it came across one more oddity. Opening a file twice in a row - the second open causes a security exception. (it's similar to the above issue)
And lastly (and no I'm not done working through them all) if you call http.getContentType() on a valid URL connection - you get a security access denied exception. If I eliminate that call - the error goes away and the file is accessed and read properly.
All of the handling of opening and closing streams in our applet is legal and safe and works up until 1.5.0_01. I'm slowly finding the patterns that cause the exceptions and in some cases I am able to work around them. As you can see most file i/o is succeeding - it's only in "special" cases that cause security exceptions - when it certainly shouldn't be - and once the security exception occurs the applet generally dies - or runs in a very unpredictable state.
Just putting more information out there in case this helps anyone - or in case anybody has more insight.
calling setUseCaches(true) seems to solve the security access exception when opening a file for a second time.
Here's more from the trace - I've turned network debugging on. I'm not sure what it's telling me though.
access: access allowed (java.net.NetPermission getProxySelector)
access: access allowed (java.net.SocketPermission QAPROXY resolve)
network: Connecting https://loadbal1.amr.smtf.ds/scp63ssltest/Content/cca/cust_01_a01_bs_enus//output/T16/T16.xml with proxy=HTTP @ QAPROXY/10.20.11.254:443
access: access allowed (java.net.SocketPermission loadbal1.amr.smtf.ds resolve)
access: access allowed (java.net.NetPermission getCookieHandler)
access: access allowed (java.net.SocketPermission 10.20.11.200:443 connect,resolve)
access: access allowed (java.net.SocketPermission QAPROXY resolve)
access: access allowed (java.net.SocketPermission 10.20.11.254:443 connect,resolve)
access: access allowed (java.lang.RuntimePermission writeFileDescriptor)
access: access allowed (java.util.PropertyPermission line.separator read)
access: access allowed (java.lang.RuntimePermission readFileDescriptor)
access: access allowed (java.util.PropertyPermission line.separator read)
access: access allowed (java.awt.AWTPermission listenToAllAWTEvents)
access: access allowed (java.awt.AWTPermission listenToAllAWTEvents)
access: access allowed (java.lang.reflect.ReflectPermission suppressAccessChecks)
access: access allowed (java.lang.reflect.ReflectPermission suppressAccessChecks)
access: access denied (java.net.SocketPermission QAPROXY:443 connect,resolve)
> access: access denied (java.net.SocketPermission QAPROXY:443 connect,resolve)
You need a SocketPermission granting this in your policy file. You seem to have a SocketPermission which permits {QAPROXY,resolve} as it is granted further up, so just refine that entry or add another. Maybe it's the port number: note that 443 < 1024.
ejpa at 2007-7-14 16:11:50 >
I cannot ask our customers to modify their policy file.
What i don't understand is why it sometimes succeeds and other times fails. I'm loading all sorts of files via the same mechanism. It's almost like some upper threshold is reached. Once I get in that state - i can no longer download any files of that type - I get security exceptions continuously.
By the way: access: access allowed (java.net.SocketPermission 10.20.11.254:443 connect,resolve)That address is QAPROXY - and it is resolving earlier in the trace. Why is one of them referencing it by IP address and the other host name?
Here's another snippet of the applet when it's first started and accessing files and QAPROXY is resolved. So I'm trying to understand what is putting it in this state of no longer being able to use the proxy:
access: access allowed (java.net.SocketPermission loadbal1.amr.smtf.ds resolve)
access: access allowed (java.net.NetPermission getCookieHandler)
access: access allowed (java.net.SocketPermission 10.20.11.200:443 connect,resolve)
access: access allowed (java.net.SocketPermission QAPROXY resolve)
access: access allowed (java.net.SocketPermission 10.20.11.254:443 connect,resolve)
access: access allowed (java.lang.RuntimePermission writeFileDescriptor)
access: access allowed (java.util.PropertyPermission line.separator read)
access: access allowed (java.lang.RuntimePermission readFileDescriptor)
access: access allowed (java.util.PropertyPermission line.separator read)
access: access allowed (java.net.SocketPermission QAPROXY:443 connect,resolve)
Hmm this is looking like a bug, unless different classloaders are involved somehow. Isn't there a java.security.debug setting which dumps the applicable domain? that might be interesting
ejpa at 2007-7-14 16:11:50 >
Sun is opening it as a bug - it should show up in the bug database in a few days. For those of you interested here is the link. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446855
One thing to watch out for is where the permissions being granted are printed from, in terms of context. That is for example, the jre will have privileges to download the jar/classes from the webserver (through the proxy), without having to add this permission to the .java.policy file. It will also have access to property files or resources that may be required. But when you try to create a new http/https connection from user/applet code, this will be restricted to the privileges granted by the .java.policy. The sandbox model.
This however does not explain why it runs ok with 1.5.0 and not with 1.5.0u1 or greater.
One other thing to watch out for when running your tests is that a URLConnection will not actually try to connect to the underlying resource until you call the connect method, or indirectly through getResponseCode or getInputStream. URL.openConnection does not initiate a tcp connection.
Hi suzannep,Is the server which you used in the code attached to bug report still alive? I can't reproduce the bug using your code.Thanks,Edward
Are there any updates on this. The linked bug didnt show any new recent activity.
Which code or site are you referring to?
I refer to the url you used in the attached TestAppletHttps.java test code. And never mind, the other tests you provided later on worked.
