KK20 Posted October 21, 2014 Posted October 21, 2014 Updated from java 7r67 to 8r25 and noticed that java is ignoring all my proxy settings. 7r67 works just fine, 8r25 does not. I can uninstall 8r25 and reinstall 7r67 and things start to work again. This is the error in the java console (just connecting to the "verify java" on java.com: network: Connecting https://www.java.com/applet/JavaRemovalTool/launch.jnlp with proxy=DIRECT network: Cache entry not found [url: file:/C:/Program%20Files%20(x86)/Java/jre1.8.0_25/lib/ext/sunec.jar, version: null] network: Cache entry not found [url: file:/C:/Program%20Files%20(x86)/Java/jre1.8.0_25/lib/ext/sunjce_provider.jar, version: null] network: Connecting http://www.java.com:443/ with proxy=DIRECT as you can see, proxy=DIRECT is bad. I.E. uses "auto" as we have a PAC file available. Again, this hasn't changed from as long as I can remember with java. There is no overriding \Sun\Java\Deployment\deployment.config and the deployment.properties within only contains the security setting=HIGH (same as 7r67). The users deployment.config is as follows: #deployment.properties #Tue Oct 21 11:57:40 BST 2014 deployment.security.revocation.check=NO_CHECK deployment.trace=true install.disable.sponsor.offers=false deployment.version=8 deployment.browser.path=C\:\\Program Files\\Internet Explorer\\iexplore.exe deployment.modified.timestamp=1413889060883 deployment.security.TLSv1.2=false deployment.log=true deployment.console.startup.mode=SHOW deployment.security.TLSv1.1=false #Java Deployment jre's #Tue Oct 21 11:57:40 BST 2014 deployment.javaws.jre.0.product=1.8.0_25 deployment.javaws.jre.0.registered=true deployment.javaws.jre.0.osname=Windows deployment.javaws.jre.0.platform=1.8 deployment.javaws.jre.0.path=C\:\\Program Files (x86)\\Java\\jre1.8.0_25\\bin\\javaw.exe deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se deployment.javaws.jre.0.enabled=true deployment.javaws.jre.0.osarch=x86 this mirrors the working deployment.config for 7r67 - same proxy settings (i.e. none so it defaults to "browser settings"). #deployment.properties #Tue Oct 21 12:15:47 BST 2014 deployment.expiration.decision.timestamp.10.67.2=1413889571 deployment.security.revocation.check=NO_CHECK deployment.trace=true install.disable.sponsor.offers=false deployment.javaws.splash.index=C\:\\Users\\administrator\\AppData\\LocalLow\\Sun\\Java\\Deployment\\cache\\6.0\\splash\\splash.xml deployment.version=7.21 deployment.expiration.decision.suppression.10.67.2=false deployment.javaws.appicon.index=C\:\\Users\\administrator\\AppData\\LocalLow\\Sun\\Java\\Deployment\\cache\\6.0\\appIcon\\appIcon.xml deployment.browser.path=C\:\\Program Files (x86)\\Internet Explorer\\iexplore.exe deployment.modified.timestamp=1413890147995 deployment.expiration.decision.10.67.2=later deployment.log=true deployment.console.startup.mode=SHOW #Java Deployment jre's #Tue Oct 21 12:15:47 BST 2014 deployment.javaws.jre.0.registered=true deployment.javaws.jre.0.platform=1.7 deployment.javaws.jre.0.osname=Windows deployment.javaws.jre.0.path=C\:\\Program Files (x86)\\Java\\jre7\\bin\\javaw.exe deployment.javaws.jre.0.product=1.7.0_67 deployment.javaws.jre.0.osarch=x86 deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se deployment.javaws.jre.0.enabled=true deployment.javaws.jre.0.args= resulting java console for 7r67 shows that the proxy is being grabbed successfully: network: Connecting https://www.java.com/applet/JavaRemovalTool/launch.jnlp with proxy=HTTP @ /10.1.1.236:8180 as indeed our proxy is 10.1.1.236:8180 I am at a complete loss as to why it refuses to accept the proxy settings in 8r25 especially as I can remove reinstall 7r67 without issue. Any ideas?
KK20 Posted October 21, 2014 Author Posted October 21, 2014 7u71 & 7u72 exhibit the same behaviour, they both end up with proxy=direct in the console. I dug out 7u60 to see if that worked and it did. Still baffled, ive tried manually setting the proxy within java control panel but to no effect - still proxy=direct in the console. The changed in control panel are reflected in the deployment.properties file so I know the settings are saving. I can edit the deployment.properties to enable/disable the console so again java is reading this file - simply ignoring the proxy settings...
Arthur Posted October 21, 2014 Posted October 21, 2014 Have you tried setting the proxy in your deployment.properties file? # Proxy settings deployment.proxy.type=1 deployment.proxy.bypass.list=[color="#FF0000"]*.domain.example[/color] deployment.proxy.bypass.local=true deployment.proxy.http.host=[color="#FF0000"]10.1.1.236[/color] deployment.proxy.http.port=[color="#FF0000"]8180[/color] deployment.proxy.same=true deployment.proxy.socks.host= deployment.proxy.socks.port= deployment.proxy.bypass.local.locked deployment.proxy.http.host.locked deployment.proxy.http.port.locked deployment.proxy.same.locked deployment.proxy.socks.host.locked deployment.proxy.socks.port.locked deployment.proxy.type.locked
KK20 Posted October 21, 2014 Author Posted October 21, 2014 (edited) had a try with that file and nada, still proxy=DIRECT. I did a configuration dump in the console and it appears to be trying ---------------------------------------------------- Dump deployment properties ... ---------------------------------------------------- active.deployment.proxy.bypass.list = *.domain.example active.deployment.proxy.bypass.local = true active.deployment.proxy.http.host = 10.1.1.236 active.deployment.proxy.http.port = 8180 active.deployment.proxy.same = true active.deployment.proxy.type = 1 I even put incorrect proxy details in (which should "stall" java just like it does IE) but that did the same. NOTE I left the *.example.domain in there as a marker for finding things - it shouldn't do any harm. edit: thought the winhttp proxy settings might need updating (netsh winhttp import proxy source=ie) no difference. Edited October 21, 2014 by KK20
Arthur Posted October 21, 2014 Posted October 21, 2014 What do you have in your deployment.config file? Mine looks like this. deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties deployment.system.config.mandatory=true
Sylv3r Posted October 21, 2014 Posted October 21, 2014 We had the same issue and messing about with the deployment.properties eventually did sort it, although I admit I was on days!
Arthur Posted October 21, 2014 Posted October 21, 2014 Do you have both the 32-bit and 64-bit versions of the JRE installed? Are you using the 32-bit or 64-bit Internet Explorer?
KK20 Posted October 22, 2014 Author Posted October 22, 2014 (edited) no, 32 bit only and 32 bit IE. Firefox portable works. I'm installing a fresh brand new W7 machine this morning (not imaged, installed from MVLS ISO) our <"%Windir%\Sun\Java\Deployment> deployment.config is #System Deployment Properties #Tue Jan 28 08:59:10 GMT 2014 deployment.security.level=MEDIUM Security is medium as I last tried 7u72 which still accepts medium. 8u25 was the same but HIGH security. I have also tried setting the proxy from deployment.config and removing the properties file. I just tried explicitly setting a deployment.config with your settings; no change still proxy=direct. Arthur, do you use a proxy or have JAVA proxy settings in your environment? Does your JAVA pick up your proxy in your java console? Edited October 22, 2014 by KK20
KK20 Posted October 22, 2014 Author Posted October 22, 2014 I have managed to sort a partial workaround. If I set the PROXY in IE as a hard coded proxy rather than our PAC file then it works. If I use either "automatic" to get our WPAD from DNS then it fails with proxy=direct, if I set an autoconfiguration file with our PAC file then again it fails with proxy=direct. If I set a proxy value then it works. this is not a fix as our PAC and WPAD has various settings inside to farm different hosts to different proxies as appropriate, sending all request to one proxy will not suit our needs. This is also changed behaviour from 7u67 and 7u60 which worked just fine. The freshly minted machine exhibited the same behaviour (no software, no AV, no updates just base OS installation and java 7u71). This also means that my proxy settings within the java control panel are being totally ignored and the settings within IE are taking precedence - I can prove this by putting one proxy in IE, one in the java control panel and the proxy in IE wins.
KK20 Posted October 24, 2014 Author Posted October 24, 2014 Raised as a bug https://bugs.openjdk.java.net/browse/JDK-8062034 I found a workaround, basically if you use dnsResolve in your proxy.pac/wpad.dat then it seems 7u71+ bugs out of the script so defaults to proxy=DIRECT. If a different method is used (such as dnsDomainIS) then 7u71+ works fine. This is acceptable for us as I don't have a lot of domains I need to forward to DIRECT. 1
jonwitts Posted November 27, 2014 Posted November 27, 2014 Just come across this issue today whilst testing Java 1.8 update 25 in our domain... Looks like from the bug report you raised it has been fixed, but not until 1.8 update 40! Has anyone else got Java 8 working behind a proxy with IE? Jon
KK20 Posted November 27, 2014 Author Posted November 27, 2014 I assume you use a WPAD/PAC? Instead of something like var resolved_ip = dnsResolve(host); use if (isPlainHostName(host) || url.substring(7, 11)=="10.1" || url.substring(8, 12)=="10.1" ) not the nicest of workarounds but good enough for us.
jonwitts Posted November 27, 2014 Posted November 27, 2014 Our WPAD/PAC is auto-generated by our Smoothwall device and we then use DNS / DHCp and point IE at the proxy.pac file... Not too sure how I would go about editing our WPAD entry like that... I might put it Smoothwall's way and see what they say...
mac_shinobi Posted November 27, 2014 Posted November 27, 2014 (edited) There is an issue with java after version 7 update 67 where by the dns resolve function does not work with pac files. Let me try and find the link https://bugs.openjdk.java.net/browse/JDK-8062034 Think its this one but will confirm for sure when im back at work tomoz Work around is to install the working version of java so version 7 update 67 ( latest version of java where the dnsResolve function in java worked ) or use google chrome / firefox We reverted some users to an earlier version of java Edited November 27, 2014 by mac_shinobi
jonwitts Posted November 27, 2014 Posted November 27, 2014 That is marked as a duplicate of this one: https://bugs.openjdk.java.net/browse/JDK-8061643 which is showing as resolved for version 8u40... Guess we have to wait for them to release the fixed version...
Arthur Posted November 27, 2014 Posted November 27, 2014 There is an issue with Java after version 7 update 67 where by the dnsresolve function does not work with pac files. There is a workaround... www.edugeek.net/forums/windows-7/144034-java-8-r-25-proxy-not-being-used-issue.html#post1236870
mac_shinobi Posted November 27, 2014 Posted November 27, 2014 There is a workaround... www.edugeek.net/forums/windows-7/144034-java-8-r-25-proxy-not-being-used-issue.html#post1236870 Lost - whats the work around ? Also will confirm the bug url tommorow when im back at work
Arthur Posted November 27, 2014 Posted November 27, 2014 what's the workaround? Use dnsDomainIs instead of dnsResolve. 2
jonwitts Posted November 27, 2014 Posted November 27, 2014 Have asked Smoothwall if they can help implement this fix... http://www.edugeek.net/forums/smoothwall-direct-support/145977-java-8u25-smoothwall-wpad-pac-issue.html
KK20 Posted November 28, 2014 Author Posted November 28, 2014 (edited) Lost - whats the work around ? Also will confirm the bug url tommorow when im back at work I posted the workaround 6 posts above yours: if you use this: var resolved_ip = dnsResolve(host); then use this if (isPlainHostName(host) || url.substring(7, 11)=="10.1" || url.substring(8, 12)=="10.1" ) If you cant change your PAC/WPAD then you are pretty screwed. Java basically barfs when it sees a call to dnsResolve kicking you out of the WPAD (defaulting to DIRECT). The only alternative (other than hosting your own WPAD) is to set clients proxy setting manually and hope "local address bypass" is good enough for you (it isn't for us when we have 2 proxies...) what i'm doing is basically checking for http://10.1 or https://10.1 (good enough for our proxies) then moving those on. Obviously you might have far more complex WPAD/PAC files then I do. Edited November 28, 2014 by KK20
mac_shinobi Posted November 28, 2014 Posted November 28, 2014 That is marked as a duplicate of this one: https://bugs.openjdk.java.net/browse/JDK-8061643 which is showing as resolved for version 8u40... Guess we have to wait for them to release the fixed version... This is the correct Bug Link --> https://bugs.openjdk.java.net/browse/JDK-8061648
Arthur Posted November 28, 2014 Posted November 28, 2014 This is the correct bug link Their workaround is a bit risky. When you must use an autoconfig-script in your environment - there's no workaround except sticking to Java 8u20 or Java 7u67; but those have critical security advisories. 1
KK20 Posted November 28, 2014 Author Posted November 28, 2014 (edited) If you have a smoothwall box then download the generated WPAD; from there it is fairly trivial to host your own PAC/WPAD on your own webserver and it only takes a DNS change to implement. As far as the webserver, simply add a MIME type to your web server for the .PAC/.DAT and you are pretty much good to go. There have been issues in the past with people struggling with host headed WPAD but ours works just fine in its own host headed internal website (W7 & W8.1 clients). Edited November 28, 2014 by KK20 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now