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. _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
