Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:31:25Zhttps://gitlab.torproject.org/legacy/trac/-/issues/27712Introduce Finite State Machine abstraction into Tor codebase2020-06-13T15:31:25Zrl1987Introduce Finite State Machine abstraction into Tor codebaseThis would make e.g. our SOCKS code easier to understand and maintain.This would make e.g. our SOCKS code easier to understand and maintain.Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/24326tor browser error failed to take over tor network2020-06-13T16:54:00ZTractor browser error failed to take over tor networkI recently installed the tor browser and it was working fine than I started getting programme error's with my operating system which is window's then the tor browser stopped working and come's up with the error failed to take over tor ne...I recently installed the tor browser and it was working fine than I started getting programme error's with my operating system which is window's then the tor browser stopped working and come's up with the error failed to take over tor network. I've since had more problem's with the internet and window's how ever window's say's there are no viruses or malware installed on my pc but I continue to have major error's and problem's. I can't seem too be able to connect to the tor browser and I've got too reconnect to the tor network according to the error's I've had this problem with the last device I installed the tor network on as well it's been happening for over a year. I've also got multiple error's with the tor web site when I tried to report this problem I've got the screen shot's I'll upload when I can get on my pc and get the programme's to start working properly. Can I please be emailed at liam_seigel@hotmail.com in regard's to this matter because Tor isn't working properly on my pc.
**Trac**:
**Username**: liam672Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/22992master pubkey of the hidden service quantum computer resistance2020-06-13T15:11:58ZTracmaster pubkey of the hidden service quantum computer resistance what will be done if quantum computers can compute the private key of the ed25519 master pubkey "of the hidden services". Large-scale/medium scale quantum computers would possibly be able to compute the private key of the master pubkey ... what will be done if quantum computers can compute the private key of the ed25519 master pubkey "of the hidden services". Large-scale/medium scale quantum computers would possibly be able to compute the private key of the master pubkey of the hidden service then they would be able to impersonate the hidden service.
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1901
**Trac**:
**Username**: DbryrtfbcbhgfTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/22498Offline directory authorities need a way to post their certificate to other a...2020-06-13T15:10:01ZteorOffline directory authorities need a way to post their certificate to other authoritiesWe have wanted to be able to run (the signing parts of) a directory authority offline for a while, because it's more secure.
So I have been experimenting with an offline (ORPort and DirPort unreachable) directory authority on the test n...We have wanted to be able to run (the signing parts of) a directory authority offline for a while, because it's more secure.
So I have been experimenting with an offline (ORPort and DirPort unreachable) directory authority on the test net.
Almost everything works: it posts votes, downloads votes from other authorities, signs consensuses, and posts its signature. It could easily do these things using a 3-hop Tor path.
But once its authority certificate expires, it has no way to post it to the other authorities.
A workaround is to overwrite another authority's cached-certs file with the missing authority certificate file. But this is nasty.
We should make authorities accept certificate posts, and post their certificates to one another.Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/22340META: allow exits to restrict on something more sophisticated than IPs2020-06-13T15:09:16ZNick MathewsonMETA: allow exits to restrict on something more sophisticated than IPsRight now exit nodes only support IP-based restrictions... and in microdescriptors, those IP-based restrictions are summarized as port-based restrictions. From time to time people ask for restrictions based on other things, like AS ids,...Right now exit nodes only support IP-based restrictions... and in microdescriptors, those IP-based restrictions are summarized as port-based restrictions. From time to time people ask for restrictions based on other things, like AS ids, hostnames, etc.
I'm not sure I see a way to do this that would actually be worth the difficulty, much less one that would work... but perhaps there are benefits I'm not seeing?
Creating this as a meta-ticket so I can close other things as duplicates of itTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/22339META: Implement some form of jurisdiction/geography/topology-aware routing2020-06-13T15:09:16ZNick MathewsonMETA: Implement some form of jurisdiction/geography/topology-aware routingThis is a parent ticket for all of the tickets about using some information about the world or the internet in order to try to pick better routes.This is a parent ticket for all of the tickets about using some information about the world or the internet in order to try to pick better routes.Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/21468What is preventing Bridge Enumeration?2020-06-13T15:06:19ZTracWhat is preventing Bridge Enumeration?What is preventing an attacker to start up a few mid-nodes and enumerating all IPs and substracting those from the list of publicly known entry-nodes to get a list of (all) unlisted bridges?
Seems a lot cheaper than dpi and except for a...What is preventing an attacker to start up a few mid-nodes and enumerating all IPs and substracting those from the list of publicly known entry-nodes to get a list of (all) unlisted bridges?
Seems a lot cheaper than dpi and except for a few false positives due to bots pinging it should be quite accurate
Is this an inherent and known flaw to the bridge infrastructure that we have to live with or am i missing some keypoint?
**Trac**:
**Username**: doelove1Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/20226Support DNS-MX resource records with .onion-filtering for TOR as secure/anony...2020-06-13T15:01:42ZTracSupport DNS-MX resource records with .onion-filtering for TOR as secure/anonymous email transport protocollHi,
while a lot of bright minds are working on transport and end-to-end content encryption of email, the problem of transport meta-data anonymization is still unsolved.
This can be solved by a network of private SMTP-servers interconne...Hi,
while a lot of bright minds are working on transport and end-to-end content encryption of email, the problem of transport meta-data anonymization is still unsolved.
This can be solved by a network of private SMTP-servers interconnected via TOR hidden-services like [Own-Mailbox](https://www.own-mailbox.com/#HowWork).
The easiest way to connect the .onion-hostname of a SMTP-server with a clearnet mail-domain is to use the .onion-hostname of a SMTP-server as a primary MX DNS resource record. To avoid leaking by a fallback to the clearnet mail-servers (secondary MX records) it is very helpful if TOR is able to resolve MX-records AND remove non-.onion-domains from the MX-RRs.
Bottom-line: This would allow encrypted and anonymous email communication with TOR onion-routing as transport protocol instead of plain TCP.
**Trac**:
**Username**: renneTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/18267Enable Exit Policy by Autonomous System Numbers2020-06-15T23:33:09ZnaifEnable Exit Policy by Autonomous System NumbersThis ticket is to improve Tor in a way to enable Exit Policy to be able to accommodate AS numbers, other than just IP addresses/netblocks and ports.
This requirements come up when measuring how to make a Tor Exit Relay that enable conne...This ticket is to improve Tor in a way to enable Exit Policy to be able to accommodate AS numbers, other than just IP addresses/netblocks and ports.
This requirements come up when measuring how to make a Tor Exit Relay that enable connections only to high traffic, but very likely not abuse-generating, websites of major internet destinations.
Assuming that i may wish to make a Tor Exit nodes only for those destinations where we know there's high traffic to be routed trough the Tor Network, but with a limited risks of ISP/Provider takedown due to those large corporations not being automatic-abuse-generating, i tried to collect the numbers of AS for each of the following:
Google (17 AS)
Facebook (1 AS)
Twitter (3 AS)
Microsoft (28 AS)
Yahoo (59 AS)
Wikipedia (3 AS)
Linkedin (9 AS)
Github (1 AS)
Cloudflare (5 AS)
The amount of netblocks part of those AS are a lot and i don't think they will fit the Exit Policy. When it has been tried to load the list of all Italian netblocks (like at #993), weird things happened and it basically didn't worked out.
If Tor servers and clients would become AS-aware, then it would be possible to run a Tor Exit node, deciding to refine an exit policy for very-limited-liability and very-limited-abuse-generating-setup that could probably make it easier to run Tor also on my home broadband line (not being abuse generating destinations, my home ISP won't cut me the subscription!).
That's something that could become a brick of a building block to reach a point where the end-user (Tor Browser users) maybe able to route some traffic out by default (ex: route only the top target AS destinatation that would dynamically enable to offload the "bulk-but-not-abuse-generating" network traffic)Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/18119.onion domain names can be really short2020-06-13T14:53:37ZTrac.onion domain names can be really shortIt's quite easy now to use [vanity generator](https://github.com/lachesis/scallion) to generate .onion domain names such as aaaaaaaaaa<6 random chars>.onion . If onion router will be able to resolve any currently invalid, shorter domains...It's quite easy now to use [vanity generator](https://github.com/lachesis/scallion) to generate .onion domain names such as aaaaaaaaaa<6 random chars>.onion . If onion router will be able to resolve any currently invalid, shorter domains, such as zxczxc.onion to aaaaaaaaazxczxc.onion - we'll have have domains, that anyone can actually remember and those are much more convenient.
**Trac**:
**Username**: azazarTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/18020RFE: Introduce privsep to secure OS and hidden service keys2020-06-13T14:53:19ZTracRFE: Introduce privsep to secure OS and hidden service keysI'm not sure if anything has been implemented to prevent running tor process to read hidden service private key after (not during) startup or to browse OS filesystems.
For example after heartbleed issue OpenBSD has implemented couple of...I'm not sure if anything has been implemented to prevent running tor process to read hidden service private key after (not during) startup or to browse OS filesystems.
For example after heartbleed issue OpenBSD has implemented couple of another protection layers to restrict a running daemon using private keys to be read them after startup.
This is commit message from OpenBSD's relayd (load-balancer) so you can get an idea what is the reason:
''Introduce privsep for private keys:
- Move RSA private keys to a new separate process instead of copying
them to the relays. A custom RSA engine is used by the SSL/TLS code
of the relay processes to send RSA private key encryption/decryption
(also used for sign/verify) requests to the new "ca" processes instead
of operating on the private key directly.
- Each relay process gets its own related ca process. Setting
"prefork 5" in the config file will spawn 10 processes (5 relay, 5
ca). This diff also reduces the default number of relay processes
from 5 to 3 which should be suitable in most installations without a
very heavy load.
- Don't keep text versions of the keys in memory, parse them once and
keep the binary representation. This might still be the case in
OpenSSL's internals but will be fixed in the library.
This diff doesn't prevent something like "heartbleed" but adds an
additional mitigation to prevent leakage of the private keys from the
processes doing SSL/TLS.''
See marc.info/?l=openbsd-cvs&m=139782935008235&w=2
Thus it would be nice if tor would privsep so a new tor process could not access the key directly.
Privsep would also help people in the future to "sandbox" logical functionality of tor (eg. OpenBSD's pledge, seccomp etc...), so it would not be possible for example to browse whole OS filesystem etc. in the future.
**Trac**:
**Username**: jiribTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/17142allow remote portforwarding on exit nodes2020-06-13T14:49:21ZTracallow remote portforwarding on exit nodesSome VPNs allow to setup portforwarding. Tor exit nodes could provide a similar feature. the client tells an exit node that it should forward port x to a hidden service which could be a conventional hidden service or a temporary one for ...Some VPNs allow to setup portforwarding. Tor exit nodes could provide a similar feature. the client tells an exit node that it should forward port x to a hidden service which could be a conventional hidden service or a temporary one for a normal client. the exit node then asks the hidden service if that is realy him who asked. then the client could set up a dynamic dns and update it everytime he switches the exit node. (binding it to the circuit might be possible too but is too unstable)
the advantages are:
* hidden services can be accessed from the internet without a tor2web service.
* not only webhosting is accessible from the outside internet
* average users could have anonymous inbound connections
disadvantages:
* how to do port usage limiting if the exit node doesnt know an ip?
**Trac**:
**Username**: iwtcitpTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/17068encourage tor users to visit websites at the same time of the day2020-06-13T14:49:06ZTracencourage tor users to visit websites at the same time of the dayto reduce the risk of traffic correlation attacks users could be shown the time of the day or week when most tor users access a specific website. if enough people change their habits security will improove. to avoid network traffic peeks...to reduce the risk of traffic correlation attacks users could be shown the time of the day or week when most tor users access a specific website. if enough people change their habits security will improove. to avoid network traffic peeks the usage statistic could be weighted with network load.
**Trac**:
**Username**: elypterTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/17040Blockchain as Root-CA for human-readable .onion domains2020-06-13T14:49:00ZTracBlockchain as Root-CA for human-readable .onion domainsThe .onion domain has been officially approved as a special domain by the IETF. :)
Onion domains are decentralized and secure inside the TOR network, but not human-meaningful. Human brains have problems to remind and assign them to serv...The .onion domain has been officially approved as a special domain by the IETF. :)
Onion domains are decentralized and secure inside the TOR network, but not human-meaningful. Human brains have problems to remind and assign them to services. This problem is called Zooko's triangle. ([https://en.wikipedia.org/wiki/Zooko's_triangle)](https://en.wikipedia.org/wiki/Zooko's_triangle)
The scandals in the last three years with certificate authorities issuing not-validated certificates and intermediate-certificates or being hacked have shown certificate authorities are not reliable which breaks security of SSL/TLS.
The Namecoin project project has proven it's possible to solve Zooko's triangle using a blockchain as distributed database to assign globally-unique self-registered IDs of any format to an asymmetric key-pair of a blockchain wallet. (https://wiki.namecoin.org/index.php?title=Identity)
So I suggest to use a blockchain as Root-CA.
How it can work:
Registering name/creating certificates:
1. User uses the TOR-client to create and save (e.g. paper-wallet) an asymmetric wallet key-pair.
1. User uses the TOR-client to send a registration request for the tuple <self-choosen ID>:<public asymmetric key> to the blockchain network
1. The nodes in the blockchain-network confirm the registration request
1. User uses the TOR-client to create X.509 server-certificates with the Common Name '<self-choosen ID>.onion' signed with the <private asymmetric key> of the blockchain wallet
1. TOR client uses the triple <self-choosen ID>:<public asymmetric key>:<private asymmetric key> from the X.509-certificate to register a hidden-service
Root-CA-lookup:
1. The TOR-client can use an overlay-filesystem to present the tuple <self-choosen ID>:<public asymmetric key> from the blockchain as X.509-root-certificate files in the SSL root-certificate-directory of the operating system (e.g. /etc/ssl/certs on Linux).
2. Authentication applications (e.g. TLS/SSL) find the virtual X.509 root-certficates in the filesystem like any other x.509-certificate.
**Trac**:
**Username**: renneTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/16979Prevent selection of ajacent nodes from the same cooperative jurisdictions2020-06-13T14:48:47ZcypherpunksPrevent selection of ajacent nodes from the same cooperative jurisdictionsWhen the ajacent nodes are selected from the cooperative jurisdictions there is a chance that anonimity is undermined with sharing of the data from surveillance networks.
I propose
1 create an ajacency matrix Coop[i,j] describing jurisd...When the ajacent nodes are selected from the cooperative jurisdictions there is a chance that anonimity is undermined with sharing of the data from surveillance networks.
I propose
1 create an ajacency matrix Coop[i,j] describing jurisdictions cooperating. High values mean more cooperation, zero mean no cooperation above some ground level.
Coop[i,j]!=Coop[j,i] in general case, for example Germany shares more data with the US than the US with Germany.
2 Let i-th node have jurisdiction A_i.
Then the probability of taking any node with jurisdiction A_{i+1} as next hop should be
(number of jurisdictions)/Coop[A_i,A_{i+1}]Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/15998suggestion: distributed captcha mechanism for hidden service DDOS defense2020-06-13T14:46:01ZTracsuggestion: distributed captcha mechanism for hidden service DDOS defenseHad an idea and couldn't find a previous
instance via search. If the idea is
impractical or otherwise deficient feel
free to close this ticket.
Lately many hidden services have come under
sustained DDOS attacks and have struggled
to re...Had an idea and couldn't find a previous
instance via search. If the idea is
impractical or otherwise deficient feel
free to close this ticket.
Lately many hidden services have come under
sustained DDOS attacks and have struggled
to remain operable.
A possible way to mitigate this problem
might be to enhance Tor to support some
sort of mechanism to push captcha processing
out to either introduction points or
rendezvous points so that DDOSers cannot
overload hidden service systems.
Numerous designs seem possible and I am
not sufficiently steeped in the workings
of Tor to venture a suggestion, but
if the idea is of use I imagine there
will be no shortage of approaches.
However it does occur to me that it
could perhaps be implemented in two stages,
first a "quick-n-dirty" approach that
is limited in scope and then a follow-
on generalized approach that perhaps
allows hidden services to push
configurable captcha generation logic,
perhaps in the form of LUA scripts
or some similar mechanism.
**Trac**:
**Username**: hdqdak8v32aorTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/15742Speed up local onion access if hidden service is hosted on same client.2020-06-13T14:45:24ZcypherpunksSpeed up local onion access if hidden service is hosted on same client.Client--->Tor(*:9150,hosting XXXXXXXXX.onion)<--->Internet
Current version:
Client->Tor [find XXXXXXXXX.onion]
Tor->Internet [same]
Internet->Tor [XXXXXXXXX.onion is you]
Tor->Client [send XXXXXXXXX.onion data]
Future version:
Client->...Client--->Tor(*:9150,hosting XXXXXXXXX.onion)<--->Internet
Current version:
Client->Tor [find XXXXXXXXX.onion]
Tor->Internet [same]
Internet->Tor [XXXXXXXXX.onion is you]
Tor->Client [send XXXXXXXXX.onion data]
Future version:
Client->Tor [find XXXXXXXXX.onion]
Tor-Tor [It's me!]
Tor->Client [send XXXXXXXXX.onion data]Tor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/14424Enhance policies (exit, reachableaddresses, etc) to support hostnames2020-06-13T14:42:10ZTracEnhance policies (exit, reachableaddresses, etc) to support hostnamesHello. First of all, amazing software! Thank you for this. I was wondering if there is a way to edit torrc to only connect to comcast, att, mit.edu etc..As you can edit the file to only connect to US servers, but I need it for specific I...Hello. First of all, amazing software! Thank you for this. I was wondering if there is a way to edit torrc to only connect to comcast, att, mit.edu etc..As you can edit the file to only connect to US servers, but I need it for specific ISP's. Thank you!
**Trac**:
**Username**: KyuskeTor: very long termhttps://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 term