The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-29T14:38:48Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33618Add IPv6 Support to is_local_addr()2020-06-29T14:38:48ZTracAdd IPv6 Support to is_local_addr()We propose this optional change, to improve the accuracy of IPv6 address
detection from directory documents.
Directory servers use is_local_addr() to detect if the requesting tor
instance is on the same local network. If it is, the dire...We propose this optional change, to improve the accuracy of IPv6 address
detection from directory documents.
Directory servers use is_local_addr() to detect if the requesting tor
instance is on the same local network. If it is, the directory server does
not include the X-Your-Address-Is HTTP header in directory documents.
Currently, is_local_addr() checks for:
* an internal IPv4 or IPv6 address, or
* the same IPv4 /24 as the directory server.
We propose also checking for:
* the same IPv6 /48 as the directory server.
We choose /48 because it is typically the smallest network in the global
IPv6 routing tables, and it was previously the recommended per-customer
network block. (See [RFC 6177: IPv6 End Site Address Assignment].)
Tor currently uses:
* IPv4 /8 and IPv6 /16 for port summaries,
* IPv4 /16 and IPv6 /32 for path selection (avoiding relays in the same
network block).
Source: https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1099
**Trac**:
**Username**: kimimaroTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33437Unsuccessful compilation of tor on FreeBSD system with libssl.so.112020-09-23T13:43:20ZTracUnsuccessful compilation of tor on FreeBSD system with libssl.so.11+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files a...+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files are attached.
Notes:
- compilation of **0.4.2.6** with **libssl.so.9** was successful
- compilation of **0.4.2.6** with **libssl.so.11** was unsuccessful
----
**Trac**:
**Username**: stillicideTor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33247Prop 312: 3.2.7. Publish IPv4 Descriptor on Guessed IPv6 Reachability Failure2020-07-24T17:04:58ZteorProp 312: 3.2.7. Publish IPv4 Descriptor on Guessed IPv6 Reachability FailureDepends on disabling descriptor publication on reachability
failures in legacy/trac#33223.
Should be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
If both reachability checks succeed, relay...Depends on disabling descriptor publication on reachability
failures in legacy/trac#33223.
Should be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
If both reachability checks succeed, relays should publish their IPv4 and IPv6 ORPorts in their descriptor.
If only the IPv4 ORPort check succeeds, and the IPv6 address was guessed
(rather than being explicitly configured), then relays should:
* publish their IPv4 ORPort in their descriptor,
* stop publishing their IPv6 ORPort in their descriptor, and
* log a notice about the failed IPv6 ORPort reachability check.
See proposal 312, section 3.2.7, Guessed IPv6 Reachability Failure part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n567Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33246Prop 312: 3.2.7. Automatically Enable an IPv6 ORPort2020-07-22T13:56:19ZteorProp 312: 3.2.7. Automatically Enable an IPv6 ORPortAfter we implement legacy/trac#33233, relays (and bridges) should try to open an IPv6 ORPort.
The ORPort should be opened on the port configured in the relay's ORPort
torrc option. Relay operators can use the IPv4Only and IPv6Only optio...After we implement legacy/trac#33233, relays (and bridges) should try to open an IPv6 ORPort.
The ORPort should be opened on the port configured in the relay's ORPort
torrc option. Relay operators can use the IPv4Only and IPv6Only options
to configure different ports for IPv4 and IPv6.
If the ORPort is auto-detected, there will not be any specific bind
address. (And the detected address may actually be on a NAT box, rather
than the local machine.) Therefore, relays should attempt to bind to all
IPv4 and IPv6 addresses (or all interfaces).
Some operating systems expect applications to bind to IPv4 and IPv6
addresses using separate API calls. Others don't support binding only to
IPv4 or IPv6, and will bind to all addresses whenever there is no specified
IP address (in a single API call). Tor should support both styles of
networking API.
In particular, if binding to all IPv6 addresses fails, relays should still
try to discover their public IPv6 address, and check the reachability of
that address. Some OSes may not support the IPV6_V6ONLY flag, but they may
instead bind to all addresses at runtime. (The tor install may also have
compile-time / runtime flag mismatches.)
See proposal 312, section 3.2.7, IPv6 ORPort part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n540
Once this ticket is implemented, we should test the different IPv4/IPv6 configs listed in legacy/trac#33235.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33245Prop 312: 3.2.6. Add an AddressDisableIPv6 torrc option2020-07-21T13:02:03ZteorProp 312: 3.2.6. Add an AddressDisableIPv6 torrc optionShould be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
Relays (and bridges) that have a reachable IPv6 address, but that address
is unsuitable for the relay, need to be able to disable IPv6...Should be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
Relays (and bridges) that have a reachable IPv6 address, but that address
is unsuitable for the relay, need to be able to disable IPv6 address
resolution.
Currently, relays are required to have an IPv4 address. So if the guessed
IPv4 address is unsuitable, operators can set the Address option to a
suitable IPv4 address. But IPv6 addresses are optional, so relay operators
may need to disable IPv6 entirely.
We propose a new torrc-only option, AddressDisableIPv6. This option is set
to 0 by default. If the option is set to 1, tor disables IPv6 address
resolution, IPv6 ORPorts, IPv6 reachability checks, and publishing an IPv6
ORPort in its descriptor.
See proposal 312, section 3.2.6:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n498Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33239Prop 312: 3.2.3 Limit Directory Authority Addresses to Address and ORPort2021-08-23T15:12:44ZteorProp 312: 3.2.3 Limit Directory Authority Addresses to Address and ORPortFor security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Since local interface addresses are
implicit, and may depend on DHCP, directory authorities do not use this
address resolution ...For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Since local interface addresses are
implicit, and may depend on DHCP, directory authorities do not use this
address resolution method (or any of the other, lower-priority address
resolution methods).
See proposal 312, section 3.2.3, directory authority case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n388Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33238Prop 312: 3.2.3. Use Local Interface IPv6 Address2020-07-03T13:21:32ZteorProp 312: 3.2.3. Use Local Interface IPv6 AddressThis ticket depends on `Address IPv6` support in legacy/trac#33233.
If they don't have usable Address or ORPort addresses, relays (and bridges) should use publicly routable addresses
from the OS interface addresses or routing table, as ...This ticket depends on `Address IPv6` support in legacy/trac#33233.
If they don't have usable Address or ORPort addresses, relays (and bridges) should use publicly routable addresses
from the OS interface addresses or routing table, as their IPv4 and IPv6
addresses.
Tor has local interface address resolution functions, which support most
major OSes. Tor uses these functions to guess its IPv4 address. We propose
using them to also guess tor's IPv6 address.
We also propose modifying the address resolution order, so interface
addresses are used before the local hostname. This decision is based
on our principles: interface addresses are local, trusted, and reliable;
hostname lookups may be remote, untrusted, and unreliable.
If the local interface addresses are unavailable, tor opens a UDP socket to
a publicly routable address, but doesn't actually send any packets.
Instead, it uses the socket APIs to discover the interface address for the
socket. (UDP is used because it is stateless, so the OS will not send any
packets to open a connection.)
Tor already ignores private IPv4 interface addresses on public relays. We
propose to also ignore private IPv6 interface addresses.
See proposal 312, section 3.2.1, general case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n359Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33235Prop 312: 3.2.1. Test Address torrc Option Configurations2020-07-01T20:27:30ZteorProp 312: 3.2.1. Test Address torrc Option ConfigurationsThis ticket depends on IPv6 Addresses in legacy/trac#33233, and automatic IPv6 ORPorts in legacy/trac#33246. These tests should be in CI, or they should be repeated after each change.
We should support the following combinations of addr...This ticket depends on IPv6 Addresses in legacy/trac#33233, and automatic IPv6 ORPorts in legacy/trac#33246. These tests should be in CI, or they should be repeated after each change.
We should support the following combinations of address literals and hostnames:
Legacy configurations:
1. (A) No configured Address option
2. (B) Address IPv4 literal
3. (C) Address hostname (use IPv4 and IPv6 DNS addresses)
New configurations:
1. (D) Address IPv6 literal
2. (E) Address IPv4 literal / Address IPv6 literal
3. (F) Address hostname / Address hostname (use IPv4 and IPv6 DNS addresses)
4. (G) Address IPv4 literal / Address hostname (only use IPv6 DNS addresses)
5. (H) Address hostname (only use IPv4 DNS addresses) / Address IPv6 literal
If we can't find an IPv4 or IPv6 address using the configured Address options:
* No IPv4: guess IPv4, and its reachability must succeed.
* No IPv6: guess IPv6, publish if reachability succeeds.
Combinations A and B are the most common legacy configurations. We want to support the following outcomes for all legacy configurations:
* automatic upgrades to guessed and reachable IPv6 addresses,
* continuing to operate on IPv4 when the IPv6 address can't be guessed, and
* continuing to operate on IPv4 when the IPv6 address has been guessed, but it is unreachable.
See proposal 312, section 3.2.1, testing notes:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n270Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32910trace: Add tracepoints and userspace tracer support2020-07-10T17:24:17ZDavid Gouletdgoulet@torproject.orgtrace: Add tracepoints and userspace tracer supportTor-dev email: https://lists.torproject.org/pipermail/tor-dev/2019-December/014111.html
These are what needs to be done but they sorta need to be together to make sense thus this one ticket:
a. Add a series of tracepoints in tor code b...Tor-dev email: https://lists.torproject.org/pipermail/tor-dev/2019-December/014111.html
These are what needs to be done but they sorta need to be together to make sense thus this one ticket:
a. Add a series of tracepoints in tor code base. I propose to start with circuit and cell level tracepoints for now.
b. Add USDT (User Statically-Defined Tracing) probes support which is used by SystemTap, DTrace and perf.
c. Add LTTng support which if enable also emits USDT.
d. Integrate all this to our build system.
About(d), the consensus among the network team is that it should NEVER be enabled in production and should be a configure switch.
I believe if we add on top a torrc option, it might not be that useful in the end considering the configure switch but mainly it will degrade performance since the check needs to be at runtime for every tracepoint.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32822Make authorities add their own IPv6 address to trusted dir servers2020-07-02T13:50:11ZteorMake authorities add their own IPv6 address to trusted dir serversAuthorities add themselves to trusted dir servers, but they don't add their own IPv6 addresses.Authorities add themselves to trusted dir servers, but they don't add their own IPv6 addresses.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/21044ORPort self reachability test happens also when it shouldn't2020-08-06T14:38:06Zs7rORPort self reachability test happens also when it shouldn'tI think we did not cover all cases when the self reachability test before publishing descriptors was introduced.
I am running a bridge with `PublishServerDescriptor 0` and `ORPort 127.0.0.1:443` because I want to run it just to do some...I think we did not cover all cases when the self reachability test before publishing descriptors was introduced.
I am running a bridge with `PublishServerDescriptor 0` and `ORPort 127.0.0.1:443` because I want to run it just to do some responsible testing without hammering the public Guards used by other clients. The bridge is configured with `PublishServerDescriptor 0` so it means I don't need a descriptor, I don't intend to make the bridge (or relay) public.
When a bridge is run in the conditions described above the log is spammed (exactly one log message at every 20 minutes) with:
```
[warn] Your server (PUBLIC_IP:443) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
```
and
```
[warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor address PUBLIC_IP. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.
```
What it did wrong:
- It guessed the public IP address and tried to make the self test on that address, regardless it's not the address explicitly configured at `ORPort`. `Address` is not set in this setup.
- Based on the second log message, I think it even overwritten the address used with `ORPort` with the public IP address that it guessed and built the descriptor.
- It infinitely tries once every 20 minutes and logs a message that the descriptor cannot be published (and my intention based on the options configured is exactly not to publish one even if the tests were successful).
What Tor should do:
- Bypass the protocol to guess `Address` (the public IP address) when `ORPort` / `DirPort` is explicitly configured as a loopback address or NAT address. This will have a logic follow-up (which I think we already do, but want to make sure) like this:
- Bypass self tests when `ORPort` / `DirPort` address is explicitly configured as a loopback address or NAT address (simplest thing would be to treat these cases as like `AssumeReachable 1` is set). Such addresses cannot be tested from the public internet anyway.
- `PublishServerDescriptor 0` maybe should not even build a descriptor at all, or at least bypass the self tests in this case too, it does not make sense to try to test something we never want to publish. Or, only make 1 attempt to test and log a message stating success or failure.
legacy/trac#19919 is kind of related, it treats as it should the cases where `ORPort` is explicitly configured as a public address. In this ticket we cover an extension for cases where `ORPort` is a loopback or NAT address.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2178We launch dummy descriptor fetches more often than needed2020-09-22T15:11:40ZNick MathewsonWe launch dummy descriptor fetches more often than neededRight now, we have code in update_router_descriptor_downloads() to launch a fetch for authority.z if we want to learn our IP from a directory fetch. We do this if:
* We're a server
* We don't have the Address option set
* At le...Right now, we have code in update_router_descriptor_downloads() to launch a fetch for authority.z if we want to learn our IP from a directory fetch. We do this if:
* We're a server
* We don't have the Address option set
* At least 20 minutes have passed since we last launched a router descriptor download
* At least 20 minutes have passed since we last launched a
Per discussion in bug legacy/trac#652, we could be even more quiet about launching these fetches. We could also require that
* At least 20 minutes have passed since we last launched *any* appropriate directory op.
* At least 20 minutes have passed since we got a new incoming connection on what we think our IP is.
* At least 20 minutes have passed since we got confirmation of our current IP in a NETINFO cell
We could also make the "20 minutes" value configurable by a networkstatus parameter.
This is a minor issue, since the current behavior is inelegant, but not actually hurting anything.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/web/community/-/issues/178Get feedback about Onion Guides to partners2021-02-02T14:23:31ZGabagaba@torproject.orgGet feedback about Onion Guides to partnersShare onion guides and zine with 3 or 4 partners and collect feedback.Share onion guides and zine with 3 or 4 partners and collect feedback.Sponsor 84: Onion GuidesGusGushttps://gitlab.torproject.org/tpo/ux/design/-/issues/2Create layout for Onion Guides fanzines2020-11-23T19:25:06ZAntonelaantonela@torproject.orgCreate layout for Onion Guides fanzinesCreate a zine ready to localize in ES and PT with onion guides content.Create a zine ready to localize in ES and PT with onion guides content.Sponsor 84: Onion GuidesAntonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/tpo/web/community/-/issues/152Update Onion Routing and Onion Services graphs in multiple portals2020-12-14T22:14:21ZAntonelaantonela@torproject.orgUpdate Onion Routing and Onion Services graphs in multiple portalsAfter our work with the OTF Learning Lab, we have new and amazing graphs to share the functioning of the onion routing and also onion services. I'll start a to-do list here, but let's feel free to edit it if we find more places where thi...After our work with the OTF Learning Lab, we have new and amazing graphs to share the functioning of the onion routing and also onion services. I'll start a to-do list here, but let's feel free to edit it if we find more places where this content should belong.
**To-do**
- [ ] https://community.torproject.org/onion-services/overview/
- [ ] https://support.torproject.org/onionservices/#onionservices-2
📦 [OTF_LearningLab_OnionRouting.zip](/uploads/e627e7e0a0304633d5b3936f1761b769/OTF_LearningLab_OnionRouting.zip)
📦 [OTF_LearningLab_OnionService.zip](/uploads/c3911e7839e8e86c52c953114cc6a517/OTF_LearningLab_OnionService.zip)
📦 [__OTF_LearningLab_Icons.zip](/uploads/382b203d20cf23d77adc7798795af60b/__OTF_LearningLab_Icons.zip)Sponsor 84: Onion GuidesGusGus2020-11-30https://gitlab.torproject.org/tpo/web/community/-/issues/151[Onion Services] Add new ways to deploy your onion site2021-03-25T15:07:32ZGus[Onion Services] Add new ways to deploy your onion site@Hiro developed different ways to deploy onion sites with terraform, heroku. We should promote it in a special page or/and update our docs to include it.
- [ ] terraform
- [x] ansible
- [ ] heroku@Hiro developed different ways to deploy onion sites with terraform, heroku. We should promote it in a special page or/and update our docs to include it.
- [ ] terraform
- [x] ansible
- [ ] herokuSponsor 84: Onion GuidesGusGushttps://gitlab.torproject.org/tpo/web/community/-/issues/116[Onion Services] How to use DoS protections2021-08-23T16:31:49ZGus[Onion Services] How to use DoS protectionsRecently asn and dgoulet released a framework explaining how to configure your Onion Service to limit some DoS attacks. We should have a how to use this feature.Recently asn and dgoulet released a framework explaining how to configure your Onion Service to limit some DoS attacks. We should have a how to use this feature.Sponsor 84: Onion GuidesGusGushttps://gitlab.torproject.org/tpo/core/arti/-/issues/24Resolve all issues marked with "XXXXM3"2020-10-27T17:12:14ZNick MathewsonResolve all issues marked with "XXXXM3"These issues in the code are minor things I should resolve before moving to even a pre-alpha.These issues in the code are minor things I should resolve before moving to even a pre-alpha.M3: Cleanup and tidyNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/22Add low-level logs all over tor-proto2020-10-20T16:41:07ZNick MathewsonAdd low-level logs all over tor-protoBefore we move forward, it'll be a good thing to have debug and trace logs all over the tor-proto crate.Before we move forward, it'll be a good thing to have debug and trace logs all over the tor-proto crate.M3: Cleanup and tidyNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/21Add async "close" methods to circuits and streams2020-10-20T18:48:04ZNick MathewsonAdd async "close" methods to circuits and streamsThese methods should block incoming queues, flush outgoing queues, then drop the circuit or stream.These methods should block incoming queues, flush outgoing queues, then drop the circuit or stream.M3: Cleanup and tidyNick MathewsonNick Mathewson