Hi,
there seems to be some misunderstanding, so let me ask questions aimed
at clearing it up. I'll also add a bit of technical information you
seem to have missed.
adrelanos wrote (12 May 2013 21:24:59 GMT) :
>> * 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)
> No, that was not my concern.
I sincerely fail to understand how this can not be your concern, while
all non-imaginary problems you're describing below apparently involve
exactly this: running htpdate over Tor without first checking whether
Tor is working.
See below, and please enlighten me... and/or add non-imaginary
problems that do happen even if Tor is working -- I'd be delighted :)
>> * 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)
> As far I understand the tails_htp init script (in Tails), it does not
> check if the Internet (Tor) is available or not.
Unless I'm missing something, this service is started by
/etc/NetworkManager/dispatcher.d/20-time.sh, once networking is up and
Tor is working. AFAIK we don't rely on it working properly offline.
>> * some other cause I'm missing -- care to enlighten me?
> I think you may assume, if Tor knows "I can't connect" or "I am not
> fully connected yet", that it will send a reply on curl's SocksPort
> "offline", curl recognizes and instantly stops.
No, I'm not assuming that.
> Current situation:
> If Tor is censored - curl will instantly fail and tails_htp will inform
> about it.
Sure, but how can this happen unless the system is starting htpdate
over Tor, without first checking whether Tor actually works?
> I don't see any extra fingerprinting issues introduced by
> --connect-timeout + --max-time, under the assumption, that --max-time
> was accepted before already.
IIRC 180s for --max-time was arbitrarily chosen because it's the
default behaviour of a well-spread HTTP client library.
I doubt it's hard, for an attacker sitting at the exit node being used
(or at the ISP if not using Tor) to delay the initial connection a bit
longer than 60s and see if there's a timeout configured at this level,
regardless of --max-time. So the combination of --connect-timeout =
60s and --max-time = 180s is probably easily fingerprintable. I'd be
glad to be proven wrong, though :)
(I must admit I've not looked at --connect-timeout in details yet, and
I don't intend to do any such thing before someone else does their
homework first, so I've no idea if that timeout is about TCP or HTTP
connection yet, which makes it hard to discuss the matter at
hand seriously.)
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
