Hot questions for Using Applets in tomcat

Question:

I am trying to run my applet with JDK8 but i'm getting below exception on java console at this line of my code

SplitPaneH = new JSplitPane(JSplitPane.HORIZONTAL_SPLIT);

Traces

Exception in thread "AWT-EventQueue-2" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.sun.swing")
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.checkPackageAccess(Unknown Source)
at sun.plugin2.applet.SecurityManagerHelper.checkPackageAccessHelper(Unknown Source)
at sun.plugin2.applet.AWTAppletSecurityManager.checkPackageAccess(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.jb2011.lnf.beautyeye.ch17_split.BESplitPaneDivider.<init>(BESplitPaneDivider.java:77)
at org.jb2011.lnf.beautyeye.ch17_split.BESplitPaneUI.createDefaultDivider(BESplitPaneUI.java:54)
at javax.swing.plaf.basic.BasicSplitPaneUI.installDefaults(Unknown Source)
at javax.swing.plaf.basic.BasicSplitPaneUI.installUI(Unknown Source)
at javax.swing.JComponent.setUI(Unknown Source)
at javax.swing.JSplitPane.setUI(Unknown Source)
at javax.swing.JSplitPane.updateUI(Unknown Source)
at javax.swing.JSplitPane.<init>(Unknown Source)
at javax.swing.JSplitPane.<init>(Unknown Source)
at javax.swing.JSplitPane.<init>(Unknown Source)
at TeleProvisionManager.InventoryPage.<init>(InventoryPage.java:382)
at TeleProvisionManager.MainFrame.createMainTab(MainFrame.java:2147)
at TeleProvisionManager.MainFrame.<init>(MainFrame.java:1253)
at TeleProvisionManager.LoginChangeGroupDlg.handleContinueButton(LoginChangeGroupDlg.java:791)
at TeleProvisionManager.LoginChangeGroupDlg.jbtnContinueActionPerformed(LoginChangeGroupDlg.java:489)
at TeleProvisionManager.LoginChangeGroupDlg.access$100(LoginChangeGroupDlg.java:56)
at TeleProvisionManager.LoginChangeGroupDlg$4.actionPerformed(LoginChangeGroupDlg.java:355)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicRootPaneUI$Actions.actionPerformed(Unknown Source)
at javax.swing.SwingUtilities.notifyAction(Unknown Source)
at javax.swing.JComponent.processKeyBinding(Unknown Source)
at javax.swing.KeyboardManager.fireBinding(Unknown Source)
at javax.swing.KeyboardManager.fireKeyboardAction(Unknown Source)
at javax.swing.JComponent.processKeyBindingsForAllComponents(Unknown Source)
at javax.swing.SwingUtilities.processKeyBindings(Unknown Source)
at javax.swing.UIManager$2.postProcessKeyEvent(Unknown Source)
at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)
at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)
at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$500(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

But it was worked well with JDK7. I am not getting what is the problem and how to solve it. And i tried downloading 'jsdg-stubs-jre1.5.jar' which contains sun.swing classes and copying that jar to WEB-INF/lib folder but no use. How to solve it please help me. TIA!


Answer:

"accessClassInPackage.sun.swing" which signifies that in Webstart it is not allowed to use the package sun.swing. You need to sign your applet, and with latest jdk 8 security, will block any applet signed with an untrusted certificate authority.So if you self sign this applet put low the security settings.untill it executes. As an example here.

The thing with java 8 is that we have the security level ranging from high to very high ,while on java 7 it ranged from medium and above.The setting was only intended to block malicious or unsigned apps in java 8.However sometimes it may cause trouble with active X controls.If your app is running using low setting ,good otherwise i suggest java7, unless you dont use enhanced features like lambda expressions and other stuff

Question:

All..

I am hoping someone who can confirm for me, what I read and what I have observed, regarding the Tomcat Java applet server?

I have Linux server running Tomcat (I built two new ones, but based the configuration off the previous two that were present when I came on the job). I am fairly new to Tomcat servers -vs- web servers.

When a client connects to the Tomcat server address...

  1. A static web page is served, with a link to a java applet:
  2. When they click a link, Tomcat serves up an applet to the browser.
  3. When the applet is served:
    • All connections and traffic that the applet creates is tunneled back to the Tomcat server? (pretty sure this is happening, and what is supposed to happen)
    • All connections connect through the client network connection? (All tests I have done can not confirm this.)

Is the tunneling a reason why Tomcat is used over just serving up the Java applet via a Apache server?

We have a SSL secure connection with certificates setup to allow https connections to the Tomcat server, and I am assuming all the data between Tomcat server and the applet is encrypted because of this?

Thanks!


Answer:

There's no good reason from what you've told us so far to use Tomcat over a lighter httpd such as apache or nginx - if it's really just serving a Java applet and web page (static content). The former two are application servers, and as that implies that means a little more than just static content - although it will serve static content just fine, too. But there is no "Default" integration between the two technologies. In particular - your data will not be encrypted by default, you've got to make sure that your applet makes secure request. Serving the applet offer SSL only protects the connection that actually serves the applet, not subsequent ones - though there's no reason these shouldn't also go through the same SSL endpoint, the applet has to initiate that, there's nothing "magical" going on.

Here's a good article on when you'd want to use one or the other.

As for the other part - there is a security model that comes with an applet. By default, the applet will only be able to make connections back to the server from which it came - this is to prevent certain kinds of "cross-site" attacks which were seen in the past. These days, different sites interoperating are more common so there are many technologies you could use to for that, if you need to - but applets are largely considered outdated and not widely used - but your end user may also configure applets to get around this default policy.

Here is information about the appliet security model, including network restrictions.

Question:

I have an applet that is being loaded from a secure tomcat server and right before the applet is loaded I get an error that the site certificate is not valid and cannot be used to verify the identity of this website. I’m not sure why this is an issue only when the applet starts to load because tomcat is setup using this certificate it is now saying isn’t trusted. If I hit continue that applet loads fine, but every new session I get this again.

I’ve found a work around by importing the COMODO RSA Organization Validation Secure Server CA into the Java Security Control Panel. This really isn’t an option for all of our users so I’m looking for other ways of fixing this.

When I check the security report of the site it says that the connection to the website is encrypted. The site certification is valid and certification path status says that it’s ok too. I had the tomcat admin import the COMODO RSA Organization Validation Secure Server CA into the keystore and it didn’t fix the issue.

The applet is signed with a valid signer certificate and runs fine once the user hits continue.

Any suggestion or help would be appreciated. At the least something to try or another thing to look at would be really helpful.


Answer:

The certificate error clearly says that the Certificate Authority that issued the certificate is not trusted. Which means you have to trust it explicitly by going into the browser's truststore to add it manually.

As far as I know, not all of the COMODO's root certificates don't come built-in in few softwares like Java, Chrome or even windows, unlike some major CA's like Entrust or GeoTrust or DigiCert or VeriSign and etc.

From the CA name you mentioned (COMODO RSA Organization Validation Secure Server CA), I only have this CA cert installed in my firefox browser. My Java, Windows and Chrome do not have it installed.

The only COMODO certs I see in my softwares are these (by default):

Chrome: (58.0.3029.110)

  • COMODO RSA CA

FireFox: (53.0.3)

Windows: (10)

  • COMODO RSA CA

Java: (1.8.0_121)

  • COMODO ECC CA
  • COMODO RSA CA
  • COMODO CA Limited

Note: These are the ones I see on my default installations. These may differ in your case.

Assuming is it the similar on your machine as well, this is what is causing the certificate error. I'm guessing that if you try to launch your applet in firefox you may not see the error, because the CA name you mentioned, I see it in the firefox installed by default.

But if you want to overcome this error in all major browsers without having to train your users on how to add them into the truststore or if you want to completely avoid asking your users to do this step, you may have to choose a CA that is trusted across all softwares and browsers by default.

Question:

I am trying to run my applet from IE11 (using JRE 8.31) and getting below Exception

java.net.SocketException: Unknown proxy type : HTTP
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.<init>(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessController.doPrivileged(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.connect(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$800(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

security: blacklist: hasBeenModifiedSince 0 (we have 1474524668053)

But with JRE7.08 it is running fine. After installing JDK8 it's not running. What was the problem ? Do i need to change any settings. Please help me.


Answer:

I have found solution for this i.e., configured invalid proxy settings in Control Panel --> Java --> General --> Network settings and those are differ with browser settings. So, selected Use browser Settings and tried again them it's working fine.