[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Is "gatereloaded" a Bad Exit?
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: Is "gatereloaded" a Bad Exit?
- From: grarpamp <grarpamp@xxxxxxxxx>
- Date: Thu, 10 Feb 2011 17:15:05 -0500
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Thu, 10 Feb 2011 17:15:14 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=omANP2S8AXP2KW55Yt1JfLOsm+Q+FkjcPe7hekt4xHs=; b=FZivkSVj30+GSe622EUaGplPSNYVrq+jR0Za7vjrBn/wrrTgWDQaEIuI83cYpQ++gU lYB4MCEBKRJB/N06WwlOGD+z+RuECZWowCaBUi/qcfUxHTcLy2C5M8kSAZr5v3UnKNc1 /LN4k+ACxXENvGSzArQaoIA7dfWI55zp8cmQw=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ooXOMec0NrsQWNKI+6ovgxrMcmRbFizl7zC6H7Xv8Dm3hoheOuvpU69WkP91A3+ShC XkuKkxCgmCkLshepXJ/SDySB/qUCdYzuh5424/5Sg8WFBD8AINwHj0dZCggqUObrasal 5MHmX2v+9IGs7UOFK3KXyEvYki6FXqe3b/+dM=
- In-reply-to: <201102100149.p1A1nai0016735@xxxxxxxxxxxxx>
- References: <201102100149.p1A1nai0016735@xxxxxxxxxxxxx>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
Been a fencesitter on this since posting the note about recording
traffic that helped send this thread over the top. For once, I'm
in agreement with Scott :) (and others)
Badexiting based on exit policy seems rather silly as it will prevent
nothing. And because of that, doing so is security theatre. Which
sends both the project into questionable practice and the user into
misplaced trust. If anything, the user should be educated instead.
Nothing keeps an operator from dropping a gig split between 80 and
443. And if you defend against their rate limiting of 443 down to
a meg, at best you've doubled their cost per eligible volume. No
big deal. And due to typical protocol distribution on the open
internet, if you force all operators to a fixed selection of 'ideal'
policies, the cost per volume doesn't really change beyond that.
It also seems the distribution of traffic around the nodes, operators,
and globe won't change either... a broadbase level up is more likely,
so there's no win there.
Further, take the top fifth of exits by bandwidth, even take them
all. No one can provably say whether or not any of them are recording
traffic. And only a fool would trust an operator's (or shill's)
statements to the contrary. The only way one can be sure is to stand
watch over the node itself, in person.
And lastly, some hat (or entity) packet groping their exit, or
handfull of same, is the least of your worries. They're just a
nuisance. It's the PA's and GPA's that one should be worried about.
Seems everyone forgot that. They will always follow bandwidth,
oppurtunity, interesting things and anomalies. Per the distribution
notes above, and the architecture of Tor, exit policy doesn't seem
likely to be interesting to a GPA.
Badexit should be reserved only for those exits that are physically
broken... modification of expected cleartext, corrupted ciphertext,
certificate games, packet mischief, dns issues, upstream path issues,
The right thing to do with unprovable consipiracy theories such as
exit sniffing, is to push it out to userland and provide tools for
the user to manage it as desired.
Some have suggested various node ranking metrics... Country,
'suspicious' strings in the nickname, 'suspicious' CIDR blocks,
PTR's, ISP's etc, the preselected metrics and exit set of the
'badtornodes' guy, Scott and others, node keysigning parties,
importable wiki [.onion] node config lists, and so on.
Exit policy is currently at the operator's pleasure, need and design.
If exit policy mandates will help solve some Tor scalability or
attack vector issues, in a substantive way, from an engineering
standpoint, fine. But please, don't claim it makes users any more
'safe' from sniffing.
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/