04/12/2012 11:52 AM, intrigeri:
> 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.
Actually, most people I know prefer to use static IP configurations for
all servers on their LAN, and some people I know don't use DHCP at all.
> Given this, I don't see how the static IP way
> would be a practical solution. Did I miss anything?
The only drawback I can see with allowing this is that the static IP
configuration would have to be unencrypted and stored separately from
the Tails server config some how. Luckily it can easily be achieved
specifying it on the kernel cmdline, and having the The Tails server
configuration tool modifying the syslinux menu file accordingly. If none
is given the default should of course be DHCP.
Something slightly unrelated I just realized is that Tails server must
have unencrypted persistence for being able to store certificates both
in the dropbear and web server approaches for remotely unlocking the
encrypted Tails server configuration. Hmm.
>> 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)
Do we actually have to run this in initramfs? Why not early init?
>> 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.
Perhaps a "Tails server" persistence preset (stored at ~/.tails-servers)
could host these? Any certificates found there would be added to
iceweasel on as soon as Tails has opened the persistent volume and found
this preset.
An issue with both this approach and the corresponding step in
intrigeri's dropbear approach (i.e. putting the fingerprint in
~/.ssh/known_hosts) is that the user must have chosen these persistence
presets *before* installing the Tails server. That is unless we are
willing to start adding *and* *activating* presets while Tails is running.
>> 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 is the bigger question to me, i.e. how to locate the (most likely
DHCP-using) Tails server. Therefore avahi/zeroconf, or similar, seems
absolutely necessary. Or am I missing something?
> This holes do not need to be permanent:
>
> * On server side, that could be only while dropbear is running.
The same applies for a web server hosting the unlock page.
> * 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.
I suppose this may be the bane of the web server + HTTPS approach.
OTOH, the web server approach allows a ridiculously simple client-side
GUI in Tails that starts/stops avahi, and scans and lists Tails servers
(and yes, there can be many, so it should be possible to distinguish
between them some how). When clicked, iceweasel simply opens the
selected server. This should even be doable in fairly small shell script
using zenity :).
I think it still is a pretty nice advantage to be able to unlock the
Tails server from any avahi/zeroconf-aware OS compared to just from
another Tails instance.
(Note that I'm personally content with this dropbear + clientside GUI
approach. I'm just being the devil's advocate here so that when we
decide not to do something, we do so for the right reasons.)
Cheers!
