Re: [Tails-dev] [GSoC] [tails-server] Ideas and challenges a…

Delete this message

Reply to this message
Autor: intrigeri
Data:  
A: julien.voisin
CC: The Tails public development discussion list
Assumpte: Re: [Tails-dev] [GSoC] [tails-server] Ideas and challenges about asking the user's passphrase on boot
Hi Julien,


jvoisin wrote (11 Apr 2012 23:38:01 GMT) :
> I have some questions/ideas about tail-server, especially about the
> early boot process; and I'd like to share them to get
> advices/options.


Glad to read this.

> I think that a good way to get the passphrase would be to setup
> a simple webpage, available on the LAN (for now, I only consider
> that the machine has one interface : the LAN).


See bellow an alternative idea.

> But this raise (at least) two majors concerns:


> 1. Disclose the server's presence on the network
> In order to be able to type his passphrase on the webpage,
> the user must know where is his tails-server on his network.
> The first (and easiest) solution would be to hardcode
> tails-server's ip during the setup of the persistence USB key;
> but this solution require to know on which network will
> tails-server run.


tails-server is expected to run on a LAN with a DHCP server (needs to
be added to the specs, btw), so I don't think the user can ensure this
IP is left free for this specific system? Custom static leases are
often not an option. Given this, I don't see how the static IP way
would be a practical solution. Did I miss anything?

> This is why I think that the "best solution" would be to use avahi,
> but this may require some digging into tails firewall.


Maybe. This holes do not need to be permanent:

  * On server side, that could be only while dropbear is running.
  * On the client side, only while the network is probed for servers.
    This probably can be made "safe enough", with enough care and
    thought: one should seriously study what exact additional attack
    surface it adds, for what attacker, and when.
    BTW, this calls for a client-side GUI rather than a web interface.
    We don't want the web browser to start / stop avahi.


> 2. Run a webpage
> Setup a php/apache seems a little bit overkill;


Absolutely.

> I think that some python (or perl) magic will be sufficient.


A simple CGI would probably do, but a CGI is useless without
a (lightweight -- remember we're in initramfs) webserver in front
of it. Or did I misunderstood what you meant with "some python magic"?

See bellow for an alternative, SSH-based solution that provides
encryption, server authentication, and optionally user authentication.

> Using https would of course be nice, but since this implies using
> self-signed certs (right ?), it might scare users.


If you decide to go the HTTP way: I agree self-signed certs, unless
well integrated into the client's persistent configuration, are
a no-go. Such integration is a must.

Remaining issues for the HTTP thingie:
How would the client be authenticated by the server?
Would it need to do it at all?

> Additionally, since tails-server will only run the
> "passphrase-webpage" on LAN, man-in-the-middle is unlikely
> to happen.


I totally disagree. This threat model does not look acceptable to me.

Many LANs where tails-server is to be deployed contain at least of
untrusted computer, that is the modem/router provided by the ISP.
This computer often also gets to see all local traffic, given it often
has an integrated switch.

> What do you think ?


I think you should have a look to the cryptsetup / dropbear
integration that's available in Debian to support remotely booting
a "fully" (but /boot) encrypted system. Basically, dropbear runs from
the initramfs, one connects to it using a SSH client, writes the
passphrase to a FIFO using a command like the one that follows, and
the initramfs does everything else:

# /lib/cryptsetup/askpass 'p: ' > /lib/cryptsetup/passfifo

How about forgetting the web interface, and writing a client-side GUI
that allows the user to enter the passphrase, and transparently does
what needs to be done (over SSH) behind the curtains?

Hints:

  * allows the client to authenticate the server in a transparent way:
    server's SSH host key generated at tails-server initial
    configuration time; made persistent on the server's stick along
    with the private key and on the client's stick (in
    ~/.ssh/known_hosts) -- but how would the files be transferred from
    the server stick to the client one? Maybe setup the server stick
    from a running client one, with SSH client persistence enabled, to
    start with?
  * authenticate the client using SSH key too, and forget about the
    root password?


Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc