× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Newbie question
  • From: "Scott Klement" <infosys@xxxxxxxxxxxx>
  • Date: 30 Sep 1999 10:04:15 -0500

Eric Strovink <strovink@acm.org> wrote:
>
> There are, of course, at least two problems with any remote java
>  client:
>
> (1) unless you "own" it, and run it standalone, it needs to be
>  downloaded from a web server, and it can only connect back to
>  that same host.

Thats what proxies are for, if you don't want to put it on your
AS/400, use a proxy.

> (2) it is insecure, at least from my reading of the current RFC's.

All telnet clients are insecure.  A java one isn't any more insecure
than any other telnet client.

>
> A knee-jerk solution to this (indeed, my knee-jerk solution to most
>  such issues these days) is to insert a 10-cent Linux box in the
>  middle.  In this case, the box proxies the telnet connections and
>  runs the webserver, does some firewalling, and encrypts
>  communication to the java client.  This saves the AS/400 sysadmin
>  the scary prospect of putting his/her machine "raw" on the net,
>  running a webserver, installing software, etc.  To him/her it's a
>  magic bullet
>

I think I see a flaw in that logic...

When you start up a java applet, it downloads and runs on the client
computer, not on the server!

This means that if your Linux box encrypts communication to the
AS/400, that the path from the Linux Box to the AS/400 is secure
and the path from the client to the Linux box IS NOT.   Since the
AS/400 and the Linux box are probably on the same LAN (after all,
in order for the Linux box to be the proxy, its going to also be the
firewall) this does not give you ANY added security -- unless of
course you're being hacked from inside your LAN :)

On the bright side...  if you're using TN5250, the data thats being
sent back and forth is in EBCDIC. :)   Its a bit less likely that
someone has a packet sniffer looking at EBCDIC codes!   Unless, of
course, he's attacking you specifically...


+---
| This is the LINUX5250 Mailing List!
| To submit a new message, send your mail to LINUX5250@midrange.com.
| To subscribe to this list send email to LINUX5250-SUB@midrange.com.
| To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.