Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:41:10Zhttps://gitlab.torproject.org/legacy/trac/-/issues/13978Get tor working with ns-32020-06-13T14:41:10ZteorGet tor working with ns-3We could use ns-3's direct code environment (DCE) or perhaps their sim kernel to run tor.
```
[14:29] <Yawning> (you know what would be a neat gsoc project? figuring out how to get Tor to play nice with ns-3)
[14:31] <Yawning> (yes, we...We could use ns-3's direct code environment (DCE) or perhaps their sim kernel to run tor.
```
[14:29] <Yawning> (you know what would be a neat gsoc project? figuring out how to get Tor to play nice with ns-3)
[14:31] <Yawning> (yes, we have shadow, but ns-2/ns-3 is the standard for certain kinds of research)
[14:33] <teor> Yawning: re ns-3, that would be porting tor to the Direct Code Execution environment?
[14:34] <Yawning> teor: yah, or looking at it
[14:34] <Yawning> ideally running a full test network
[14:34] <teor> Do we know how large the gap is?
[14:35] <Yawning> no idea
[14:35] <Yawning> last time I was doing this sort fo work, it was called ns-2
[14:35] <Yawning> :P
[14:38] <Yawning> teor: I was really suprised that they wrote shadow instead of extendign ns, but I never asked why they did that
[14:38] <teor> they?
[14:39] <Yawning> them tor folks
[14:39] <Yawning> :P
[14:39] <teor> It looks like we'd have to avoid clock_gettime in ns, and might have to be really careful around threads and processes
[14:40] <Yawning> yah, it's not something I'd expect to be easy
[14:40] <teor> According to http://www.nsnam.org/docs/dce/release/1.0/manual/html/dce-user-tech.html#api-coverage
[14:40] <Yawning> but it'd be really strong for stuff likelooking at kist
[14:41] <teor> And we might be missing some important APIs
[14:41] <teor> s/we/DCE/
[14:42] <Yawning> hey, that's why I said it was a gsoc project :P
[14:42] <Yawning> for a really really enthusiastic student
[14:42] <dgoulet> hrm ns-3 is an offline simulator and by that I mean it does not use the OS network stack for experiment, not sure if that would reflect correctly reality
[14:43] <teor> The kernel can be used, see http://www.nsnam.org/docs/dce/release/1.0/manual/html/dce-kernel.html
[14:43] <teor> Well, kernel sources
[14:44] <Yawning> teor: that's new-ish
[14:44] <Yawning> but yeah
[14:44] <dgoulet> ouf work++ to make it work with the kernel eheh
[14:45] <Yawning> dgoulet:all the researchers do their modeling with ns and then write the kernel patches :P
[14:45] <dgoulet> reserach and kernel patch in the same sentence! wow :P :P
[14:46] <Yawning> yah well the tcp research community is filled with interesting people >.>
[14:46] <dgoulet> Yawning: I guess if you want to implement some new nice TCP congestion algorithm in kernel, that makes sense but testing userspace app on top of that, does that work well?
[14:46] <teor> Well, I know what I need to do next, and it's not this :-)
[14:46] <Yawning> for something like what we want to do in certain cases?
[14:47] <Yawning> I'd want a lot of the tooling or something similar >.>
[14:47] <Yawning> but yeah, ENOTIME
[14:47] <Yawning> and maybe shadow does all of what I want
[14:47] <dgoulet> right for sure a nice big network simulation would be awesome
[14:48] <teor> Yawning: ENOMEM as well, sometimes
[14:48] <Yawning> if for say we wanted to move to sctp or a udp transport, we'd need simulation capabilities like this
[14:48] <dgoulet> indeed
[14:49] <Yawning> (and it's the sort of tool that people that cound do "how to make tor faster" would be faimilar with)
[14:49] <Yawning> just an idle thought, if I find a younger version of myself with more time on their hands than I have, I'll suggest it to them :P
```Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/11331rewrite tor in rust-lang2020-06-13T14:35:08Zcypherpunksrewrite tor in rust-langRust provides many features that would benefit Tor like memory safety, etc. Writing C code that is safe is super hard (even for exeperienced Tor devs).Rust provides many features that would benefit Tor like memory safety, etc. Writing C code that is safe is super hard (even for exeperienced Tor devs).Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/9755Migrate Tor to libphenom2020-06-13T14:32:01ZcypherpunksMigrate Tor to libphenomlibphenom is supposed to be faster than libevent. https://github.com/facebook/libphenom/commit/c2753c2154a0cffc0bd70e8f28dd0ea884aab4fdlibphenom is supposed to be faster than libevent. https://github.com/facebook/libphenom/commit/c2753c2154a0cffc0bd70e8f28dd0ea884aab4fdTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/9733Generate statistics about compromise due to traffic correlation with differen...2020-06-13T14:31:57ZAaron JohnsonGenerate statistics about compromise due to traffic correlation with different guard selection and rotation parametersGuards can protect even better against traffic correlation if rotate them slower and/or choose fewer of them. To help decide if these changes are worth it, we should use path simulation and some reasonable adversary models to generate st...Guards can protect even better against traffic correlation if rotate them slower and/or choose fewer of them. To help decide if these changes are worth it, we should use path simulation and some reasonable adversary models to generate statistics about the security that results.Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/9165Evaluate datagram-based transports; build and merge as appropriate2020-06-13T14:30:04ZNick MathewsonEvaluate datagram-based transports; build and merge as appropriateThis is an omnibus ticket to serve as parent for work involving transports other than TLS-over-TCP for client->relay and relay->relay communication. This isn't about pluggable transports for anticensorship purposes; it's about using non...This is an omnibus ticket to serve as parent for work involving transports other than TLS-over-TCP for client->relay and relay->relay communication. This isn't about pluggable transports for anticensorship purposes; it's about using non-TCP mechanisms for better performance.Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/7830UDP over Tor2020-06-13T14:26:08ZproperUDP over TorI am interested to transfer UDP over Tor to the destination server.
https://blog.torproject.org/blog/moving-tor-datagram-transport
What happened to that?I am interested to transfer UDP over Tor to the destination server.
https://blog.torproject.org/blog/moving-tor-datagram-transport
What happened to that?Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/6001Transport IP packets over Tor2020-06-13T14:19:59ZAndrew LewmanTransport IP packets over TorAs listed here, https://www.torproject.org/docs/faq#TransportIPnotTCP, the ability to transport IP would enhance usability and functionality of Tor from a user perspective. Solving the challenges and enabling this will make Tor a more va...As listed here, https://www.torproject.org/docs/faq#TransportIPnotTCP, the ability to transport IP would enhance usability and functionality of Tor from a user perspective. Solving the challenges and enabling this will make Tor a more valuable tor for a wider range of usecases.Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/6000Promote users to relays2020-06-13T14:19:58ZAndrew LewmanPromote users to relaysAs listed here, https://www.torproject.org/docs/faq#EverybodyARelay, we would like to promote users to relays if their client meets certain conditions.As listed here, https://www.torproject.org/docs/faq#EverybodyARelay, we would like to promote users to relays if their client meets certain conditions.Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/5992META: Decentralize directory authorities as far as safely possible2020-06-13T14:19:57ZAndrew LewmanMETA: Decentralize directory authorities as far as safely possibleWe currently rely on a handful of directory authorities and their operators to generate and maintain the consensus of the Tor network. They're also the default place to go for clients to bootstrap into the network. Some research has been...We currently rely on a handful of directory authorities and their operators to generate and maintain the consensus of the Tor network. They're also the default place to go for clients to bootstrap into the network. Some research has been started into replacing the individual directory authorities with anonymity-preserving distributed hash table (DHT) models. Further this work, using simulators and/or private tor networks for handling future growth and expansion of the public tor network.Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/4855Allowing TOR to use LAN and other connections, not only internet2020-06-13T14:16:37ZTracAllowing TOR to use LAN and other connections, not only internetSince the threat of internet censorship, I've been looking for a system that allows connected computers to share data anonymously, and even create 'alternate internets' via mesh networking. I believe this would be a great feature for TOR...Since the threat of internet censorship, I've been looking for a system that allows connected computers to share data anonymously, and even create 'alternate internets' via mesh networking. I believe this would be a great feature for TOR, and wanted to suggest it for a while. This is what I had in mind:
Currently, TOR locates nodes on the internet and sends data between them. My request is making internet no longer be a requirement for TOR, but just one way of connecting. By giving TOR the ability to reach nodes on other computers using any means of communication... including a Local Area Network, WIFI, and maybe even Bluetooth.
There are two reasons why I suggest this. The first is to allow computers without an internet connection (but part of a LAN) to connect using TOR. For instance, let's say an user has been banned by his ISP from using the internet at all (happens in some countries). However, he can still be part of the LAN in his area. One of his neighbors runs a TOR node, which either exits to an internet connection or leads to another TOR node that does. The disconnected user could travel to the exit node from computer to computer, TOR acting as usual from there on.
The second reason is to make TOR usable for 'alternative internets'. This is an idea of the future, but with the fear of censorship I see it coming. Basically, an area of computers which can contact each other could establish its own private network to share data, host websites, etc. without touching the actual internet. But despite not finding any software that can do this (let alone anonymously), users creating an alternate internet could still be persecuted for sharing "illegal data" if they are caught. Using TOR's system, it would be impossible to tell who in the network is hosting what.
How TOR could do mesh networking and private internet: There is a LAN network running multiple computers, none of them connected to the actual internet. One of them wants to host a website accessible to the cloud. He would create a TOR node for that, exiting to the folder where he's hosting his files or website. The user wanting to reach his page would write the IP or URL in his web browser, then TOR would go from node to node inside the cloud, looking for the computer hosting that page. Once it finds it, it establishes a permanent connection, encrypting it using any available nodes it can relay the connection through in that cloud.
In my opinion, TOR would be a great candidate for this, and would allow even more users to connect, share data and evade censorship. It could even combine both ideas... by connecting to a LAN node, then an internet node, then going through another group of LAN computers, etc. TOR could automatically choose the best path to a resource, such as determining if it's located on the internet or a direct device, if to use an internet or a LAN node, etc. So all the user must do is type the URL and have TOR figure where and how to find it. I believe this would extend possibilities greatly, and really hope the idea can be considered.
**Trac**:
**Username**: MirceaKitsuneTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/4812MapAddress should perhaps work without AllowDotExit2020-06-13T14:16:26ZTracMapAddress should perhaps work without AllowDotExitSebastian irc story is that MapAddress should work without setting AllowDotExit to 1.
Manual page story is that AllowDotExit is extremely dangerous.
This torrc configuration..
MapAddress livelyblog.com livelyblog.com.veronika.exit
Ma...Sebastian irc story is that MapAddress should work without setting AllowDotExit to 1.
Manual page story is that AllowDotExit is extremely dangerous.
This torrc configuration..
MapAddress livelyblog.com livelyblog.com.veronika.exit
MapAddress *.livelyblog.com *.livelyblog.com.veronika.exit
..spews out the following story in tor's log:
[warn] The ".exit" notation is disabled in Tor due to security risks. Set AllowDotExit in your torrc to enable it.
[warn] Invalid onion hostname [scrubbed]; rejecting
MapAddress does not work without AllowDotExit as of todays git. I have not tried other versions.
If Sebastian story about MapAddress should work without AllowDotExit is true then Tor has a bug which could pretty please be fixed.
**Trac**:
**Username**: oyvindsTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/3028META: Support non-clique topologies on the network2020-06-13T14:10:07ZtagnaqMETA: Support non-clique topologies on the networkhttps://lists.torproject.org/pipermail/tor-relays/2011-April/000759.html
See it like a long term feature request :)
(if there is not one yet)https://lists.torproject.org/pipermail/tor-relays/2011-April/000759.html
See it like a long term feature request :)
(if there is not one yet)Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/1880Enhanced Security Suggestion2020-06-13T14:06:08ZTracEnhanced Security SuggestionCould a random traffic delay be incorporated into the routing algorithm, in order to thwart traffic timing on the nodes. Random packing of data might also be necessary to avoid the detection of packet sizes through the nodes?
**Trac**:...Could a random traffic delay be incorporated into the routing algorithm, in order to thwart traffic timing on the nodes. Random packing of data might also be necessary to avoid the detection of packet sizes through the nodes?
**Trac**:
**Username**: foreverTor: very long term