Re: [Tails-dev] Endless Data Attack and Defense

Delete this message

Reply to this message
Autor: intrigeri
Data:  
Dla: The Tails public development discussion list
Temat: Re: [Tails-dev] Endless Data Attack and Defense
Hi,

adrelanos wrote (12 May 2013 17:32:47 GMT) :
> intrigeri:
>> adrelanos wrote (06 May 2013 09:10:36 GMT) :
>>> This means, it will wait a hardcoded 180 seconds in any case, even if
>>> Tor is totally unable to connect (network down or censored). The
>>> connection won't fail and curl won't exit before 180 seconds are over.
>>
>> I don't think we run htpdate in Tails before Tor is working. Do we?


> No, but that's beside the point.


> Just imagine Tor won't connect because there is no network or because
> Tor is censored.


IMHO, whether a proposed change fixes a real problem or an imaginary
one is not beside the point.

> It's just that tails_htp (curl) would wait 180 seconds for every try.
> And it can be quite a lot tries before tails_htp finally gives up.
> Before that, there is no feedback whats happening.


I acknowledge such a failure mode can happen outside of Tails, but
this takes some special conditions, e.g.:

  * Tor censorship + a system that runs htpdate over Tor without
    checking whether Tor actually works (which our fork of htpdate is
    not designed to deal with)
  * a badly configured upstream router + a system that runs htpdate
    without checking whether the Internet is reachable (which our fork
    of htpdate is not designed to deal with)
  * some other cause I'm missing -- care to enlighten me?


For the record, I don't mind supporting these usecases as long as it's
easy, does not make Tails any worse, and I don't have to do the work.

> The point of --max-time 180 is to defeat an endless data attack (or
> bug), not to wait 180 seconds for a connection just because a single
> server is unreachable. Hence, I thought additionally adding
> --connect-timeout is necessary.


Why not. I'm happy to reconsider this proposal once it comes with
a discussion about the added fingerprinting potential, balanced with
the importance of the real problems the proposed change fixes :)

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