1

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!

jewettg
  • 1,098
  • 11
  • 20

1 Answers1

0

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.

BadZen
  • 4,083
  • 2
  • 25
  • 48
  • Thanks for the response. This configuration is in support of an older system (which we hope to replace soon) that still uses Java applets user interfaces. No way around this. The TWO new servers I built were to help fix a java applet signing issue that would allow us to retire some "terminal servers" (and update the Linux OS) that was being used in a closed network setup to enable the use of an older version of Java that did not insist on signed code or check for expired code. – jewettg May 07 '15 at 15:13
  • Some a clarification question: In basically a public/intranet fire-walled type configuration, a client is served the java applet. The client can not reach the the database or authentication hosts directly, but the applet can reach the database or authentication hosts, so am I correct to assume that the traffic that the applet is tunneling that back through the Tomcat server? Obviously, I am not sure how this is being done. – jewettg May 07 '15 at 15:21