[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Proposal: Separate streams across circuits by destination port or destination host
- To: or-dev@xxxxxxxxxxxxx
- Subject: Re: Proposal: Separate streams across circuits by destination port or destination host
- From: Nick Mathewson <nickm@xxxxxxxxxxxxx>
- Date: Thu, 26 Aug 2010 14:44:32 -0400
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-dev-outgoing@xxxxxxxx
- Delivered-to: or-dev@xxxxxxxx
- Delivery-date: Thu, 26 Aug 2010 14:44:39 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=KS3MkBKBREX8k6bHSroot4vfpvjDRyxt5wDT88kQjpI=; b=annNpFKtL3eFvU7wXL5Xd8TCRWrWNExS++mNHEF8BRDtn5koAq/dLUaFRz2r5S5aRy VMgmqzsfSNGfSVMyGLkqdmlLjFOZYe51S5e9sKiJxrXs+gebVtxKZ0FojgV5L73lVBCw 3eUWFCwSetneJT4ixImC3NcPU1C1XOoGxRElA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=L8XWIF8hdyaKSr67cDfpzdP6IFmcuYkUb+aR4ej+tnNoCHJG0DrlRFyFgLcAB3KBgU H/bohHrNDtmpl6N/wgZ/0EQtDGJMNkeZjHS+SVAM5YUzglWz3AlhwjK2dXdgnT3B/Lzl 6UOW1EVWSmrbw7lFv1g6ILLbC+8GxdFq0X+Pc=
- In-reply-to: <201008252212.28875.robert@xxxxxxxxxxxxxxx>
- References: <4C49AF2D.5090603@xxxxxxxxxxxxx> <201008252212.28875.robert@xxxxxxxxxxxxxxx>
- Reply-to: or-dev@xxxxxxxxxxxxx
- Sender: owner-or-dev@xxxxxxxxxxxxx
On Wed, Aug 25, 2010 at 5:12 PM, Robert Hogan <robert@xxxxxxxxxxxxxxx> wrote:
> So this is my take on the thread so far:
>
> - We've zoned in on the fact that this proposal is really about isolating
> applications on circuits rather than ports on circuits.
>
> - Isolating by destination address is likely to increase the number of
> circuits the client builds by some scary quantity.
>
> - There is a potential attack if we isolate by port number alone. A
> malicious website could server resources over a variety of port numbers,
> learn our exit nodes for each, and then presumably correlate our activity
> on port 443/80 with our activity on any services we use that it happens to
> provide on any of the other ports.
>
> - We can achieve some/a lot of the benefits sought by the proposal if we
> isolate streams based on the information provided by the socks request
> itself. The things people have suggested are:
> 1 Socks authentication info (username/pass)
> 2 Socks listener address/port
> 3 Socks protocol
> 4 Socks client IP
> 5 Info in /proc/pid/cmdline garnered from the client's port number
>
> My own view is that 1 to 4 above could be used to determine the choice of
> circuit even in the absence of an IsolateStreamsBy* option. 5 is ugly and
> generally won't work if running as a 'tor' user so can be discarded.
I tend to agree wrt 1..4.
5 is not only ugly but also hard and unportable. I spent a lovely
evening a couple of weeks back reading the sources to "lsof" to see
how they answer the "what process is using this socket" question, and
the games that lsof needs to play are fiddly, platform-specific, and
sometimes grossly inefficient. My hat is off to the lsof authors and
maintainers, but we do not want to try to do what they do.
> I think the only argument for making item 1 optional would be so that
> people know about it. Maybe it can be an option and on by default.
Personally, I think it's fine to have all of 1..4 on-by-default and
maybe even "always on". I am having a hard time thinking of a use
case where somebody is using socks username/password or multiple socks
listeners or multiple socks protocols or connecting from multiple
client IPs and where they would _want_ the streams from these
different socks usage profiles coalesced into different circuits
together.
--
Nick