intrigeri:
> Hi!
>
> adrelanos wrote (17 Feb 2013 20:19:21 GMT) :
>>> Endless data attacks. An attacker responds to a file download request
>> with an endless stream of data, causing harm to clients (e.g. a disk
>> partition filling up or memory exhaustion).
>
>> Affected:
>> - tails_htp
>
> Acknowledged.
>
>> - Tails security check perhaps?
>
> The default LWP::UserAgent's timeout is 180 seconds, so no, it's
> not vulnerable.
>
> But anyway: an attacker who is able to implement this attack against
> tails-security-check can also reply wrong information, and this
> entirely break the whole purpose of the tool. So, I'd say that we
> don't care about the endless data attack at all here.
>
>> - wherever else where you are using a scripted download (didn't check
>> more throughly than a fast grep for curl)
>
> Thanks for having a look!
>
> I've also grep'd for wget and LWP, and found no other such thing.
>
>> We're in luck. A fix doesn't appear to be that complicated. Curl
>> supports --max-time.
>
>> Adding a timeout between, well, 120 and 300 seconds?
>
>> Whatever a good timeout value would be, it's probable best not the hard
>> code let's say for example 120 seconds.
>
> I would happily take a patch against our htpdate fork that adds a 180
> seconds timeout. Interested?
I try. Where should I push my branch? And please don't overestimate my
git skills.
Do you have a submit a patch guide?
>> I think it may be best to add a random extra delay between maybe 0 and
>> 300 seconds seconds so the attacker doesn't know for sure if Tor, the
>> wifi, the network broke down or if the user was using --max-time.
>
> This minor change might help hiding, to a member of our HTP pool, the
> fact that someone using wget
Nit pick: curl
> over Tor to retrieve their homepage
> without the associated resources, that the client is using htpdate (I
> would need to be convinced that adding timeouts at random looking
> values while everybody else uses values such as 180s would actually
> help, though.). Well, this could be worth researching further.
> Current htpdate does not really try to hide who it is, does it?
No, but it has been discussed.
https://tails.boum.org/todo/have_htpdate_send_GET_instead_of_HEAD/
Together with automating firefox. It's still on my long list and I
haven't made process yet.
> Have I missed some other attack this change would defeat?
It's also about slow retrieval attack (which could also simply be a bug
or busy server). From ISP perspective it affects the the traffic
fingerprint.
Example: one server is very busy and doing something effectively being a
slow retrieval attack (not on purpose), then the ISP might fingerprint
htpdate.
