Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2021-07-29T15:06:00Zhttps://gitlab.torproject.org/legacy/trac/-/issues/7349Obfsbridges should be able to "disable" their ORPort2021-07-29T15:06:00ZGeorge KadianakisObfsbridges should be able to "disable" their ORPortIn the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPo...In the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPort of obfsbridges.
Maybe it should make the ORPort bind on localhost. But what happens if the transport proxy is not on the same host as the ORPort?Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7126Multipath consensus integrity verification2020-06-13T14:23:39ZMike PerryMultipath consensus integrity verificationWe want to allow clients to use old consensuses safely without the directory authorities producing new ones. One of the problems with this is ensuring that directory mirrors don't game this time period to feed clients their favorite stal...We want to allow clients to use old consensuses safely without the directory authorities producing new ones. One of the problems with this is ensuring that directory mirrors don't game this time period to feed clients their favorite stale consensus that is still acceptable.
A related problem is "Can we do anything to mitigate malicious targeted consensus delivery in the event that a majority of dirauth signing keys are compromised?"
The common approach for this type of problem is multipath Perspectives-style key authentication. There are several ways we could authenticate the consensus documents in this model. For example, an append-only data structure such as a signed git repo could be created to store consensus hashes for all time. Tor clients could also be modified to store their own chain of observed consensus hashes in a file. In this way, potentially targeted users could drop their consensus hash history onto a USB key, mail it, relocate or otherwise bootstrap an alternate path to the git repo, and verify their connection was not compromised.
A more streamlined Tor-based solution is to extend current Tor directory protocols to allow the set of directory mirrors from #572 to be queried about the latest consensus time they have seen, and for the hash for that consensus time. Clients could then query k of these mirrors, determine the most recent consensus hash that all k mirrors agree on, and request that consensus document from the mirrors that have it. Such requests would be authenticated by the dir mirror identity keys, which would be stored in the Tor source code as part of #572.
This would require additional directory commands ("Tell me the timestamp on your most recent consensus" and "Tell me the hash of that consensus"), as well as some client logic.
The client logic is likely to be the complicated part. It's possible that the dirport commands could be added earlier, allowing us to experiment with various client approaches on the longer term.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/12599Fix the functionality of UpdateBridgesFromAuthority2020-06-13T14:37:30ZGeorge KadianakisFix the functionality of UpdateBridgesFromAuthority`UpdateBridgesFromAuthority` is currently disabled by default because it's not very useful since the authorities are usually censored anyway.
We should think of a nice way of adding back this functionality. You can read a bit of backsto...`UpdateBridgesFromAuthority` is currently disabled by default because it's not very useful since the authorities are usually censored anyway.
We should think of a nice way of adding back this functionality. You can read a bit of backstory here:
https://lists.torproject.org/pipermail/tor-relays/2014-June/004823.htmlhttps://gitlab.torproject.org/legacy/trac/-/issues/6546Replace check.tp.o with internal mapaddress + JSON/XML object2020-06-15T23:15:06ZJacob AppelbaumReplace check.tp.o with internal mapaddress + JSON/XML objectWe need to replace check.torproject.org with something that scales and something that fails closed. I propose that we create a special address that signals a given exit with a DirPort to return a status - like a TorCheck currently does.
...We need to replace check.torproject.org with something that scales and something that fails closed. I propose that we create a special address that signals a given exit with a DirPort to return a status - like a TorCheck currently does.
Mike have some ideas. This would remove the need for check.torproject.org entirely in our software, at least.