Russ,
you are right about the theoretical impossibility of fully
securing the ltsp installations. That said, encrypting the X traffic, in
particular the login process, is of great value, because it hinders the
casual and/or unsophisticated attacker.
I am beginning to see that there is a great need to securely
authenticate users to the server. I hate physical tokens - people forget
them or give them away. I was thinking in terms of a thumb print scanning
mouse combined with a passphrase. Unfortunately I couldn't find anything
readily available that would work without a huge expenditure. If you have
seen something along those lines or have other ideas, please write. I
think we need to lessen the vurnelability of the ltsp based systems. And
if you want a real headache, think hand held wireless bar code scanning
terminals, with *no* encryption available, like those from Symbol. julius
On Fri, 1 Nov 2002, R P Herrold wrote:
> On Fri, 1 Nov 2002, Jason A. Pattie wrote:
>
> > --[PinePGP]--------------------------------------------------[begin]--
> > This would have to be done via a VPN tunnel as SSH only tunnels TCP
> > traffic, not UDP. IPSec for Linux is implemented in the FreeS/WAN
> > package. You could also try to use CIPE or some other encrypted
> > tunneling package (Zebedee comes to mind) that also supports UDP packets.
> >
> > Christian Nygaard wrote:
> > > Hi are anyone encrypting the LTSP X11 & XDM traffic to the server and
> > if so how?
>
> It cannot be done within the scope of the present LTSP model.
> It probably cannot be done across broadcast network physical
> layer (OSI layer 1).
>
> 1. The ltsp boot sequence runs:
>
> Layer 2 (MAC) broadcast seeks an IP from a DHCP server -- no
> strong authentication possible here absent a non-broadcast
> point-to-point path from end unit to DHCP server -- transiting
> a switch does not help, for switches may be made to fail open,
> trivially. dsniff, ettercap, and the libnet packet factory
> tools are widely available audit tools -- they are of
> sufficient strength to accomplish this.
>
> [Possibly (and I do not think there is a working
> implementation of this), the Intel hardware encryption NIC
> _might_ be able to do this -- but these cards run over $150
> each -- key management and physical layer issues and a MitM
> ('man/monkey in the middle') will remain.]
>
>
> 2. IP assignment forgery
>
> At this point, we can hijack the connection with a rogue DHCP
> server, a DoS aimed at the 'real' DHCP server, and insert our
> our reply IP information. Then we can taken over the boot
> process; see the later steps on why this hurts. At this
> point on, there are no special tools needed for the hijack --
> just the willingness to set up the hijack tool from BSD or GPL
> licensed sources.
>
>
> 3. False kernel insertion
>
> At this point, we are running IP (layer 3) and tftp'ing,
> starting with UDP; same hijack options exist. We can now also
> point the DHCP client at a rogue TFTP server, and insert our
> our reply rogue boot-strap kernel. This is just a reprise of
> the step above.
>
>
> 4. Private keying hijack
>
> A boot-strap kernel is smart enough so that it can pull a
> kernel across which can talk IPSEC -- but we can see every
> 'bit' in both kernels and reverse engineer, perhaps by running
> it in a Bochs virtual machine; perhaps with a userspace kernel
> hosting solution -- being in userspace, we can stop it at any
> time and catch, reverse, and automate takeover of clever
> internal data structure and code obscuring routines. If time
> critical decoding is occurring, the authmated process can
> decode through those sections.
>
> Particularly, we can 'follow along' with any DH key exchange
> and dynamic session key nonce dialog; static keying is even
> easier to compromise.
>
> -------------------------------------------------
>
> Simply stated, the LTSP model is readily compromised at
> several points by a determined attacker; the crypto cannot be
> securely started across the wire, without physically secure
> hardware with a tamper proof dynamic key generator within the
> layer 2 hardware.
>
> Could we get this into the FAQ, please?
> -- Russ Herrold
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.openprojects.net
