Bittorrent

[slush]

>
> >Disagree. I wrote _port_ oriented QoS, not _content_.  There can be config
>
>  is encrypted between the client and the exit


But not between exit and target (well, we are not speaking about tunelling
any kind of SSL connection).


> >option to prioritize some port (port range) above other. Just because
> >somebody want to support HTTP transfer than other, but he dont want to
> fully
> >stop other services (torrents).
>
>      It appears that you do understand neither how tor works nor why it
> must
> work that way to protect anonymity.  Please familiarize yourself with the
> documentation available at the tor web site at http://www.torproject.org.


Thank you, I read it carefully. Lets summarize it:

* Traffic on exit node is decrypted (there is no encryption added by Tor
itself, just encryption on level of application protocol in some cases)
* Exit node knows target IP and port

Where is problem with anonymity? Why it is not possible to prioritize
traffic on exits? Please be specific and dont send me link to torproject. Of
course, you are welcome in specific comments.

It is not about critism to missing implementation in Tor. Im just wondering,
why it is bad design idea.



>     Every tor relay operator uses an exit policy, whether they use the
> ExitPolicy statement(s) in torrc or not.  I don't happen to see that it is
> my
> business, in general, what exit policies are used by other tor operators.


So, and ... ? I spoke anything about that?


    As noted above and in the tor documentation, all information regarding
> the user's proxied TCP connections through tor's SOCKS port is encrypted
> from that point onward until it reaches an exit relay.  To determine the
> destination port number of a proxied connection within the tor network
> would
> require providing a way to decrypt information passing through the circuit.
> Such decryption destroys both security and anonymity.
>

No. Not on exit. Again, Im not speaking about any kind of prioritization on
middle nodes.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20090219/1fc7590f/attachment.htm>