Re: [tor-bugs] #28812 [Core Tor/Tor]: Duplicates of nodes descriptors can be found in consensus files

[Tor Bug Tracker & Wiki]

#28812: Duplicates of nodes descriptors can be found in consensus files
--+--
 Reporter:  wagon |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  not a bug
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 I think it is possible that both duplicates have non-zero bandwidth value.
 Probably, you want to say the following: relays are addressed by their
 fingerprints, and fingerprints of these duplicates will be always
 different. I don't know yet which parameters fingerprint hashes, but is it
 possible that somebody (probably, with malicious intentions) pushes to tor
 consensus two different nodes with the same fingerprints (e.g., running on
 different IP or ports)? In other words, what must be unique? Can we
 consider fingerprints as absolutely unique values in any valid consensus?
 Can we consider the above values "Iw3aijlAo3wtwMPpS81P+jXWBXM" and
 "kP1vdWn7duAfwAsWDXy1WEQWMFYf0AHhw03vmCUepdM" as absolutely unique?

 > Tor consensus doesn't provide any uniqueness guarantees.
 It may have some essential consequences for tor controllers.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28812 [Core Tor/Tor]: Duplicates of nodes descriptors can be found in consensus files

[Tor Bug Tracker & Wiki]

#28812: Duplicates of nodes descriptors can be found in consensus files
--+--
 Reporter:  wagon |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  not a bug
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * milestone:   => Tor: unspecified


Comment:

 Replying to [comment:2 wagon]:
 > Replying to [comment:1 nickm]:
 > > Probably not.  We consider two nodes to be different if they have
 different keys, and the same otherwise.
 > They cannot be different if they claim that they are using the same IP
 and the same ports. These two different tor instances cannot serve any
 useful purpose. Two different processes cannot listen on the same IP and
 port.

 Two different processes cannot listen on the same IP and port *at exactly
 the same time, on some operating systems*.

 And that's not even true: SSL multiplexing is a thing. Although SSL
 multiplexing probably isn't happening here, because the right way to load-
 balance tor relays is to make 2 tor relays on different ports, and let the
 network load-balance,

 > > As long as they don't stay up longterm or get assigned any important
 flags, it's not going to hurt anything.
 > How client can select which of them to use if both of them are on the
 same IP and port? Tor client doesn't know which of these duplicate keys
 the node in question is using in particular time moment.

 In both these cases, at least one of the duplicates has a 0 bandwidth. Tor
 clients will never select nodes with a 0 bandwidth for anything.

 > If you say that such nodes cannot work in network anyway, why they are
 included in consensus and distributed to clients? If you say that such
 nodes can work, we are in trouble again, because most probably they are
 unusable because of what I've said before.

 Relays with 0 bandwidths are measured by the bandwidth authorities. If the
 measurement fails with the wrong key, the bandwidth stays at 0.

 Relays are checked for reachability by the directory authorities. Relays
 that aren't reachable at a particular key, IP address, and port lose the
 Running flag, and are excluded from the consensus.

 But these checks take time, so inconsistencies can be present for a short
 time before being resolved.

 > How it can be not a bug?

 Because the Tor consensus doesn't provide any uniqueness guarantees. And
 any future uniqueness guarantees would need to be specified very
 carefully, because they are a denial of service risk.

 If you'd like to suggest some changes to Tor, we have a proposals process:
 https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

 > Meanwhile, I caught it again with another node (Tue Dec 11 03:59:04 UTC
 2018):
 >
 > {{{
 > r default Iw3aijlAo3wtwMPpS81P+jXWBXM 2018-12-11 02:07:48 218.221.211.72
 42958 0
 > m kP1vdWn7duAfwAsWDXy1WEQWMFYf0AHhw03vmCUepdM
 > s Running V2Dir Valid
 > v Tor 0.3.5.5-alpha
 > pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 > w Bandwidth=0 Unmeasured=1
 >
 > r default nvcZXCZwkee2bTJUZEBI9zpju40 2018-12-11 02:32:31 218.221.211.72
 42958 0
 > m PhWgGNtH2OHFrkO4YA18a9OqKm/491SwRwUYY+lCC/o
 > s Running V2Dir Valid
 > v Tor 0.3.5.5-alpha
 > pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 > w Bandwidth=0 Unmeasured=1
 > }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28812 [Core Tor/Tor]: Duplicates of nodes descriptors can be found in consensus files

[Tor Bug Tracker & Wiki]

#28812: Duplicates of nodes descriptors can be found in consensus files
--+--
 Reporter:  wagon |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  not a bug
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 Replying to [comment:1 nickm]:
 > Probably not.  We consider two nodes to be different if they have
 different keys, and the same otherwise.
 They cannot be different if they claim that they are using the same IP and
 the same ports. These two different tor instances cannot serve any useful
 purpose. Two different processes cannot listen on the same IP and port.
 > As long as they don't stay up longterm or get assigned any important
 flags, it's not going to hurt anything.
 How client can select which of them to use if both of them are on the same
 IP and port? Tor client doesn't know which of these duplicate keys the
 node in question is using in particular time moment.

 If you say that such nodes cannot work in network anyway, why they are
 included in consensus and distributed to clients? If you say that such
 nodes can work, we are in trouble again, because most probably they are
 unusable because of what I've said before.

 How it can be not a bug? Meanwhile, I caught it again with another node
 (Tue Dec 11 03:59:04 UTC 2018):

 {{{
 r default Iw3aijlAo3wtwMPpS81P+jXWBXM 2018-12-11 02:07:48 218.221.211.72
 42958 0
 m kP1vdWn7duAfwAsWDXy1WEQWMFYf0AHhw03vmCUepdM
 s Running V2Dir Valid
 v Tor 0.3.5.5-alpha
 pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 w Bandwidth=0 Unmeasured=1

 r default nvcZXCZwkee2bTJUZEBI9zpju40 2018-12-11 02:32:31 218.221.211.72
 42958 0
 m PhWgGNtH2OHFrkO4YA18a9OqKm/491SwRwUYY+lCC/o
 s Running V2Dir Valid
 v Tor 0.3.5.5-alpha
 pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 w Bandwidth=0 Unmeasured=1
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28812 [Core Tor/Tor]: Duplicates of nodes descriptors can be found in consensus files

[Tor Bug Tracker & Wiki]

#28812: Duplicates of nodes descriptors can be found in consensus files
--+--
 Reporter:  wagon |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  not a bug
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 Probably not.  We consider two nodes to be different if they have
 different keys, and the same otherwise.  Apparently a majority of
 authorities voted in favor of both of these identities, which is possible
 if they're both around at slightly different times.  As long as they don't
 stay up longterm or get assigned any important flags, it's not going to
 hurt anything.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #28812 [Core Tor/Tor]: Duplicates of nodes descriptors can be found in consensus files

[Tor Bug Tracker & Wiki]

#28812: Duplicates of nodes descriptors can be found in consensus files
--+--
 Reporter:  wagon |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor/Tor
  Version:  Tor: 0.3.4.9  |   Severity:  Normal
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Sometimes file `cached-microdesc-consensus` contains duplicates of some
 Tor nodes which differ only by keys. For example, today (Mon Dec 10
 17:17:29 UTC 2018) I saw these duplicates:

 {{{
 r Petibonum KDU6jCRTrb2O4BRxMMRdnGegVNc 2018-12-10 15:21:54 92.137.2.39
 443 8080
 m pEBO+WeONS3MuvMCPHWM1QOJiMGVWjTucOdGHMmBRNc
 s Running V2Dir Valid
 v Tor 0.2.9.16
 pr Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3 HSRend=1-2 Link=1-4
 LinkAuth=1 Microdesc=1-2 Relay=1-2
 w Bandwidth=0 Unmeasured=1

 r Petibonum bwz/Y5pp8y6UH51RU28xDghyqrc 2018-12-10 15:44:54 92.137.2.39
 443 8080
 m +Zq4u8cRhLR4ry1bEPidvOtULBP/PCAsioLRZnRa1gQ
 s Running V2Dir Valid
 v Tor 0.2.9.16
 pr Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3 HSRend=1-2 Link=1-4
 LinkAuth=1 Microdesc=1-2 Relay=1-2
 w Bandwidth=95
 }}}

 Is it a bug? Now
 
[[https://metrics.torproject.org/rs.html#details/28353A8C2453ADBD8EE0147130C45D9C67A054D7|this
 node]] is out of consensus.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs