On a similar level, we use a SSL based extranet proxy to allow remote access
to our network.  Only those IP addresses and ports that you are configured
for will be made available to the client.  This was a turnkey solution that
didn't require any configuration on the iSeries.

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863



-----Original Message-----
From: Scott Klement [mailto:klemscot@xxxxxxxxxxxx]
Sent: Friday, March 19, 2004 2:49 PM
To: Midrange Systems Technical Discussion
Subject: RE: remote telnet with ssl



Heya James,

> Actually there should be very little difference between a VPN and SSL
> telnet.  After all, what is a VPN except TCP/IP encapsulated in an
> encryption scheme and then encapsulated again in TCP/IP?  SSL telnet is
> the same idea, except that the telnet protocol is encapsulated with
> encryption instead of the TCP/IP protocol.

That's true.  The security of the encryption is about the same between a
VPN and SSL telnet.  There are other factors besides the strength of
encryption to consider:

1) Authentication.  SSL uses a signed-certificate system to validate that
   the server is someone that you trust.  That's because SSL was designed
   for web sites providing online shopping for consumers, and the goal was
   to give the consumer confidence that his credit card data was viewable
   only to the business that he was buying from.  If you want two-way
   authentication, it's important that you remember to do the extra setup
   of requiring client-side certificates that the server trusts.  Not hard
   to do but it's an important to do, because with telnet usually it's
   the server your protecting, not the end-user.

   It's been ages since I've used a VPN, and I don't remember how/if they
   do authentication.  I would expect that they're similar, though.

2) Risk.  The levels of risk between a VPN are usually very different.
   With a VPN, your whole network is at stake if the attacker breaks
   through.  With SSL, only the telnet service on the one machine is at
   stake.   You can solve this VPN issue with an additional firewall, but
   that adds complexity.

3) Speed.  You can fit less data per-packet in a VPN connection because
   the TCP and IP packet headers are encrypted in the data of each packet.
   In effect, your passing two packet headers in each packed, reducing the
   amount of space for actual data.  With SSL telnet this isn't happening.

4) Convienience.  VPN allows access to the entire LAN, that means you can
   use it to do far more than just telnetting to one machine.  That
   provides a much higher level of convienience, especially for remote
   offices where many services may be required.

5) Trust.  When you're talking about letting a remote developer access
   your system, you generally want to only trust him with things that are
   directly related to him.  SSL telnet only grants access to one port on
   one machine, and that makes it easier to control what he's got access
   to.  You can accomplish the same thing with an additional firewall,
   but again, more complexity.

So, IMHO, SSL telnet is a much more secure option when allowing telnet is
all you want to do.   Not because SSL is in any way better encryption, or
even better authentication, but because there's less at stake if he breaks
through, and because when it's less complex, there are fewer points of
failure.

But that's just my opinion, please don't crucify me. :)

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2022 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.