[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Bittorrent



>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