Hi,
jvoisin wrote (13 Apr 2012 20:26:54 GMT) :
> I'll go with some of the remaining ones:
Great.
Please update your application before Sunday, 12:00 AM GMT, to match
the progress that was made recently.
> Dealing with multiples tails-server on the same LAN:
> This is not a problem, since the hostname is set during
> the setup; it's up to the user to take care to not name multiples
> servers with the same name.
All Tails currently ship with a common hostname.
So, in case it's leaked, they're not distinguishible from the other.
Moving away from this has consequences that should not be considered
lightly. I'd really prefer to avoid doing it at all, if possible.
A given tails-server already has (at least) one identifier: it's
.onion hidden service name. Maybe we could keep the current (amnesia)
hostname even for tails-server, but configure avahi to announce the
.onion name on the LAN (replacing .onion with .local, I guess)?
Is it possible? How does this sound?
> What if the screen is broken but the keyboard is still available ?
> We must find a way to tell to the user when he should
> enter his passphrase, and the result of the operation
> (good/bad passphrase).
> A good solution could be to communicate thought the
> keyboard's capslock LED.
> For example:
> - Continuous blink : please enter your passphrase
> - Two quick-blink : good passphrase
> - No more blink until the user can input his passphrase
> again, in case of bad passphrase.
> Since not every keyboards have a capslock LED,
> we could use the system speaker instead;
> but since this involve waking up the whole house
> when the server is booted up, I prefer the LED solution.
I like such hardware / software hacks very much, but... do we really
want to spend time supporting specifically this usecase, given we
already are designing a generic solution to remotely boot any
tails-server from the LAN?
> As previously said, in order to authenticate the server,
> the user must carry a private key (dropbear approach),
No. Some identifier of the server's public key.
> or a certificate fingerprint (webpage approach).
I expect the full certificate to be much easier to integrate,
as explained in details by anonym earlier in this thread.
> But the server must also have an unencrypted partition,
FYI Tails 0.11 and later best supported installation method creates
a "Tails" system partition that may be useful to store such data.
It shall be copied, at some point in the boot process, to the relevant
places where it'll be used by the software that needs it.
How and when?
> to carry public keys (dropbear), and certs (webpage).
No. Key pair in both cases. One may call it a certificate in the case
of the HTTPS one, if you prefer, but the server certainly needs its
private key too.
> Since the dropbear approach will require user authentication,
> in order to provide a password-less shell access, the webpage one
> does not : tails-server does not care about who you are,
> the only thing that matter is that you have the right passphrase.
Looks good. But then, why require user authentication for the dropbear
approach? Why not connecting to a dedicated user whose shell is merely
a passphrase prompt?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
