RE: remote telnet with ssl -- MIDRANGE-L

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. :)