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
