Hi,
anonym wrote (12 Apr 2012 13:52:00 GMT) :
>> 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.
Those people use SSH, know about static DHCP leases, and setup port
forwarding. I don't think they are our target userbase for Tails
server. So please let's take a step back from what the tiny population
of "people who run a server at home" are used to do. They're simply
not relevant for Tails server. So let me reiterate, hopefully more
clearly, what I meant with "I don't think the user can ensure this IP
is left free for this specific system?"
Most home modem/routers run a DHCP server on the LAN. Most home users
use this DHCP server without knowing what DHCP is, without being aware
their home router is a computer that runs DHCP server software, let
alone it can (sometimes) be configured.
In this context, if you want to run a server with a static IP, you
have to ensure this IP is left free for this specific system, that is
to somehow explain the DHCP server it should leave that IP apart so
that it does not get assigned to another box, or to setup a static
DHCP lease.
I think Tails server users should absolutely *not* need to do this.
Or did I miss an easy way to solve this static addressing problem when
a DHCP server is running the place?
>> 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.
I think this is already supported by live-boot / live-config.
I agree we want to support this case too (seriously lower priority
IMHO, though).
> 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.
Yeah, the USB stick must be able to produce some information that
allows it to authenticate itself somehow.
> Do we actually have to run this in initramfs? Why not early init?
Oh, you're absolutely right.
Sorry for spreading confusion.
>>> 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.
Yes. This was exactly what I expected Julien to reply.
>>> 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?
My "maybe" was about the firewall holes.
>> This holes do not need to be permanent:
[...]
> 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.
Sure. This was exactly what I expected Julien to reply.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
