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
