RE: remote telnet with ssl

On Fri, 19 Mar 2004, jt wrote:

> What I have never understood is whether Kerberos, SSH, SSL, TLS, VPN and/or
> IPV6 if it has any security stuff.. Whether ANY of these (and I'm sure I'm
> missing a few) run the exact same encryption methods or not??  If not, SEEMS
> like would be an advantage to the added overhead as it would appear to be
> harder to crack both at the same time, but dunno if that's the case at all.

They can use the same encryption, or they can use different encryption
schemes.  Many, if not most, allow you to choose an encryption scheme.

If there are multiple layers of encryption it is impossible to crack or
decrypt them simultaneously.  Each layer must be completed before starting
on the next (per packet).  While it is true that additional layers would
make things harder to crack, this advantage is far outweighed by the
disadvantages of complexity and overhead.  A single layer of proper
encryption already provides enough protection for almost everything.
Unless you're sending out nuclear launch codes.  In which case don't use
the internet...

> Afaik, none of these are sufficient to store and forward legal votes, btw.

I don't think the encryption protocols is the root of the problems of
e-voting.  More likely the moronic and breath-takingly stupid
implementation of the systems as a whole.  But this is completety OT
(sorry list and David).

> | It is similar to running a VPN over a VPN (which is
> | entirely possible).
>
> Never thought-a that one.  Again, different VPNs run different encryption
> schemes??

Again, this is often configurable.  However the authentication is often
different.  Scott's excellent post to this thread points out some ways in
which the various protocols differ in this respect.

Perhaps it is useful to think of IP (meaning Internet Protocol, not
Intellectual Property) and the other protocols as an onion.  Like an onion
has many layers, so does TCP/IP and related protocols.  Let's look at an
example, sending the letter 'a' over telnet:

1.  The telnet client sends the letter 'a' to the operating system
networking stack.  The letter 'a' is the core of the onion in this
example.  It is the data we are interested in.

2.  Because the telnet client uses the TCP protocol (defined when it uses
the socket() call) the network stack slaps on some TCP headers.  These
have information like the ports used, packet sequence, and a bunch of
other stuff.  These TCP headers are now the second layer of the onion.  So
far we have the 'a' and some TCP headers.  Now the OS hands the TCP packet
off to the next layer of the network stack...

3.  Since we are communicating over an IP network the IP layer receives
the packet.  The IP layer only sees the outermost layer of the onion
(technically this isn't true - but it only *cares* about the outermost
layer).  So all the IP layer is the TCP headers.  The IP stack throws
another layer onto this.  Now we are up to three layers on our onion.  The
IP stack is now going to do things like route the packet, put it on the
correct network interface, forward it, etc.  Eventually it finds it's way
onto the...

4.  Transport layer.  The hardware usually takes care of this part.  When
the OS gives the IP packet to the ethernet card the card puts on another
layer appropriate for ethernet transmission.  Other transmission methods
(like frame relay, wireless, etc.) use different layers here.

Every higher (actually lower) protocol puts another layer on the onion.
The key point here is that each protocol only sees the outermost layer.
It doesn't make a lick of difference generally to the protocol what is
inside the internal layers.  All each level has to do is add (or remove)
the outermost layer.

As it turns out this is a really good thing.  Since only the outerlayer is
visible (i.e. the layers are opaque) we can send anything we want on to
whatever layer we want.  Like encryption.  We can insert an encryption
step at any point in the chain.  We can redirect almost any layer to
output to almost any other layer.  So we can for example redirect an IP
layer into an application layer instead of the transport layer.  That way
we can add encryption or change the ports or paint the thing green if we
want.  This is precisely how VPNs work.

Because of the onion layered nature of network protocols, you can't really
work with multiple layers at once.  IOW, you can't use the same encryption
method on multiple layers and then decrypt them all at once.  Not only
does the opaque nature of the network stack prevent this, but so does the
encryption methodology itself.  Using our example of the letter 'a', let's
suppose that using RSA 1024-bit public key cryptography the result of
encrypting the letter 'a' is the string 'asdf'.  Suppose we then encrypt
that using the same method and the result is 'fdsa'.  There is no way to
do both steps of decryption at once.  We must first complete decrypting
'fdsa' to 'asdf' before we can decrypt 'asdf' to 'a'.

Bs pbhefr jr pbhyq nyy whfg tb onpx gb gur tbbq byq qnlf bs ebg13...

James Rich

Zvpebfbsg vf abg gur nafjre.
Zvpebfbsg vf gur dhrfgvba.
AB (be Yvahk) vf gur nafjre.
        -- Gnxra sebz n .fvtangher sebz fbzrbar sebz gur HX, fbhepr haxabja