ThinClientSecurity

ThinClientSecurity

Status

Introduction

Provide a secure, encrypted session for thin client users.

Rationale

Security on LTSP terminals is an issue that will need to be tackled over the long term. Currently, everything that goes "Over the wire" with LTSP travels unencrypted: from the initial DHCP request to the entire X session. For many environments, security isn't a big issue, however some environments (i.e. banking institutions, public library kiosks, etc.) having an encrypted connection will be paramount.

Scope and Use Cases

  • A bank wants to implement LTSP thin clients for their tellers, but industry rules require that all transmissions over the wire are free from spoofing/snooping.
  • An Internet cafe wants to use thin clients, but the possibility of someone plugging a rogue laptop into the network is very high.

Implementation Plan

There are currently a couple of different ideas to work on:

  • Encrypting the network X session with ssh.
    • Proof of concept has been done with this.
    • Launch the X server on the local client.
    • Run a graphical widget which will obtain the userid and password.

    • Use expect to launch ssh, which authenticates with the server for the entered userid and password, and runs an X session (either GnomeSession, KDEsession, etc.) on the server. This displays back on the client via X forwarding provided by ssh.

    • Pros:
      • Simple to setup and maintain. Some shell scripting should be all that is required to integrate ssh into the login process.
      • Uses existing, well known technologies.
    • Cons:
      • Where do we store host keys on a diskless workstation? Do we generate a new one every time?
      • Messes up remote sound, as the server can't easily check the $DISPLAY environment variable to do the sound forwarding, as $DISPLAY is now set to something like 'localhost:10'. We should be able to use the $SSH_CLIENT environment variable instead.
      • What will be the processor impact on server doing ssh encryption for 50 or 100 workstations? Maybe we should look at using a simpler cypher, such as Blowfish, so that the cpu load is less.
  • Use FreeNX. It handles the connection via SSL, and can handle some of the sound issues a bit better.
    • Pros:
      • Better sound handling.
      • Low bandwidth improvements.
      • Encrypted connection.
    • Cons:
      • FreeNX is a good idea, but a bad implementation. It's a large collection of shell scripts and spaghetti code.
      • Server performance issues.

  • Use OpenVpn. It is a full VPN implemented over TLS/SSL. Given the TAP device support in kernels 2.4 (?) and above, an OpenVpn based solution can be implemented entirely in userland; no kernel patches neccessary.

    • Pros:
      • Native X can be used over the tunnel; equivilent to a connection provided by ipsec
      • Uses a set of well tested encryption / authentication protocols and libraries.
      • Tunnel can be established during boot with simple scripts; all further network activity is/can be encrypted.
    • Cons:
      • Although under active development for several years, it is not a particularily well known solution.
      • Scability would require the use of a PKI of some kind (certificate-based authentication), or a pre-shared key. I don't believe there is built-in support for dh-like anonymous encryption-without-authentication.

  • Have some local storage loaded with a kernel and an initrd. These will download a different digitally signed kernel and initrd, which sets up an IPv6 or IPsec connection for the rest of the session. Kernel switch is handled using "Two-kernel monty" (kexec) patch. [VáclavŠmilauer: see http://www.arcig.cz/~eudoxos/eb-linux/ for an implementation of this. We needed it to set up encrypted wireless link to the DHCP server to download kernel and initrd. I doubt it would be a usable base for anything else, but as a proof-of-concept it is OK. Note that kexec hes some hardware issues (like framebuffer). ]

    • Pros:
      • The only unencrypted transfer is the initial kernel download, but that would be digitally signed. That way we know we're dealing with a "safe" kernel.
      • After that, entire connection is encrypted. DHCP, NFS, and XDMCP are all encrypted.
    • Cons:
      • You need some kind of local storage medium (Compact Flash, USB key, CDROM, etc) to hold the initial kernel and initrd.
      • We still have to worry about processor impact on the server for a large number of connections.
      • If we've embedded the correct public key on the client to allow for the download of an "officially" signed kernel, how do we allow people to provide their own kernels if they need custom patches?

Data Preservation and Migration

Packages Affected

  • LTSP kernel and initrd with integrated kexec patch.
  • IPv6 support?
  • OpenSWAN?

User Interface Requirements

  • An interface will be needed for turning on or off "secure" LTSP. There may be some sort of interface needed for assigning keys to clients, depending on the implementation.

Outstanding Issues

UDU BOF Agenda

UDU Pre-Work

UbuntuDownUnder/BOFs/ThinClientSecurity (last edited 2008-08-06 16:37:33 by localhost)