Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2024-02-12T20:13:15Zhttps://gitlab.torproject.org/legacy/trac/-/issues/7823Rate-limit facilitator interaction2024-02-12T20:13:15ZDavid Fifielddcf@torproject.orgRate-limit facilitator interactionFacilitator should rate-limit registrations and retrievals by IP ranges to avoid trivially flooding or exhausting the client database.Facilitator should rate-limit registrations and retrievals by IP ranges to avoid trivially flooding or exhausting the client database.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/13135Support base64-encoded fingerprints in `search` parameter2024-01-18T14:51:52ZSebastian HahnSupport base64-encoded fingerprints in `search` parameterWhen searching for relays, it'd be nice if we could also search (and list) the base64-encoded fingerprint, extrainfo-hash etc, so that it is easy to find the relays inside Tor's data dir.When searching for relays, it'd be nice if we could also search (and list) the base64-encoded fingerprint, extrainfo-hash etc, so that it is easy to find the relays inside Tor's data dir.https://gitlab.torproject.org/legacy/trac/-/issues/27155Include BGP prefix information in details documents2024-01-18T14:51:39ZnusenuInclude BGP prefix information in details documentsUse case:
* find relays in the same prefix (for example if a specific prefix has been hijacked)
* group relays by prefix
* is a requirement fore routing security related metrics (ROA, prefix length)
The RIPEstat API can be used as a so...Use case:
* find relays in the same prefix (for example if a specific prefix has been hijacked)
* group relays by prefix
* is a requirement fore routing security related metrics (ROA, prefix length)
The RIPEstat API can be used as a source and you can cache it if previous lookups were within the same /24 (IPv4) or /48 (IPv6) since that is the longest prefix length
https://stat.ripe.net/docs/data_api#NetworkInfo
example:
https://stat.ripe.net/data/network-info/data.json?resource=140.78.90.50
related: #26585https://gitlab.torproject.org/legacy/trac/-/issues/21378Archive bwauth bandwidth files2024-01-18T14:51:36ZTom Rittertom@ritter.vgArchive bwauth bandwidth filesThe raw bwauth votes (sample: https://bwauth.ritter.vg/bwauth/bwscan.V3BandwidthsFile) contain information such as last measured time, circuit failures and (eventually) scanner information. This can be used for debugging purposes.
Bloc...The raw bwauth votes (sample: https://bwauth.ritter.vg/bwauth/bwscan.V3BandwidthsFile) contain information such as last measured time, circuit failures and (eventually) scanner information. This can be used for debugging purposes.
Blocked by #21377, possible next steps in [#comment:14 comment 14].https://gitlab.torproject.org/legacy/trac/-/issues/26585improve AS number and name coverage (switch maxmind to RIPE Stat)2024-01-18T14:51:34Znusenuimprove AS number and name coverage (switch maxmind to RIPE Stat)
Onionoo currently uses maxmind for IP to as_number and as_name resolution.
This is fast as it is a local DB lookup but it is less up-to-date and has less coverage than RIPEstat https://stat.ripe.net/
This is a problem for tools that de...
Onionoo currently uses maxmind for IP to as_number and as_name resolution.
This is fast as it is a local DB lookup but it is less up-to-date and has less coverage than RIPEstat https://stat.ripe.net/
This is a problem for tools that depend on onionoo's as_name and as_number fields like Relay Search, OrNetStats and OrNetRadar
(I don't know maybe there are also others that are affected?)
Currently it might takes weeks or months before new ASes get added to maxmind so this information
is also missing when people lookup relays on Relay Search.
As of today onionoo is missing AS level data for about 100 relays,
but this value depends on how far we are away from the last maxmind update.
How about we use RIPEstat API as a data source + local cache.
To minimize the amount of required online queries against the RIPEstat API we can do the following
to create the IP to AS map initially (pseudocode):
if ip_prefix in cache
use cached entry
else
perform an online lookup (query RIPEstat API)
add new prefix entry to cache
expire cache entries after 15 days?
(it makes sense to log how many entries changed
after 15 days so we know whether this value is to large or to small)
This will significantly reduce the amount of required online API calls.
To give you an idea of the scale (based on onionoo data from a random
day in May 2018)
total relay records: 8116
unique IPv4 addresses: 7794
unique IPv4 BGP prefixes: 3884
each day about 50 new relays appear,
lets assume the worst case (every new relay is not in an
So on the estimated daily amount of queries you do would be around
4000/15+50 = ~320 requests/day = 1 req every ~4 minutes
which appears acceptable.
IP to prefixes (this can return multiple matches), as_number and as_name lookup:
https://stat.ripe.net/data/related-prefixes/data.json?resource=103.114.160.21
IP to prefix and as number (no as_name) lookup:
https://stat.ripe.net/data/network-info/data.json?resource=103.114.160.21
ASN to as_name lookup:
https://stat.ripe.net/data/as-overview/data.json?resource=AS40676
documentation:
https://stat.ripe.net/docs/data_apihttps://gitlab.torproject.org/legacy/trac/-/issues/24234Setting your security slider to "high" breaks Twitter2024-01-18T14:51:32ZNima FatemiSetting your security slider to "high" breaks TwitterI just realized twitter doesn't load properly when the security slider is set to "high". I was trying to figure out what triggers this but I also realized there's no apparent way to find out what things were blocked by the security slide...I just realized twitter doesn't load properly when the security slider is set to "high". I was trying to figure out what triggers this but I also realized there's no apparent way to find out what things were blocked by the security slider. Addons like NoScript, Privacy Badger or any ad blocker basically have this option where they show you what elements were blocked so you could investigate if there's a problem and manually whitelist them, but I find out it's not as easy with the security slider.
Attached is a screenshot of how it looks.
The workaround is to lower the security to medium.
![#24234:high-security-twitter.png, 700px](uploads/#24234:high-security-twitter.png, 700px)https://gitlab.torproject.org/legacy/trac/-/issues/23782Expose all possible query features in an "Advanced Search" HTML form2024-01-18T14:51:30ZcypherpunksExpose all possible query features in an "Advanced Search" HTML formAtlas does support much more than IP/nickname search. Most users do not know that.
An "Advanced Search" form should show all possible search fields and make it easy to create advanced queries without having to know every parameter.
- co...Atlas does support much more than IP/nickname search. Most users do not know that.
An "Advanced Search" form should show all possible search fields and make it easy to create advanced queries without having to know every parameter.
- country
- AS
- running
- flags
- first_seen_days
....irlirlhttps://gitlab.torproject.org/legacy/trac/-/issues/11410Weird downtime counter in globe?2024-01-18T14:51:30ZGeorge KadianakisWeird downtime counter in globe?This is Paul's bridge:
https://globe.torproject.org/#/bridge/6CE1370EDFE977E7A3124B7C1E543B533A1C6E9C
I've been checking that page for the past few days and it always reports '3 hours 50 minutes' of 'Downtime'. Which means that the brid...This is Paul's bridge:
https://globe.torproject.org/#/bridge/6CE1370EDFE977E7A3124B7C1E543B533A1C6E9C
I've been checking that page for the past few days and it always reports '3 hours 50 minutes' of 'Downtime'. Which means that the bridge was up 3 hours and 50 minutes ago.
Is this right? I think I've been getting the same number for the past few days.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/16020new field: measured flag2024-01-18T14:51:28Zcypherpunksnew field: measured flagHi Karsten,
I would find it usefull to have a flag measured/unmeasured in relay details objects.
Use cases:
- make graphs based on how big is the fraction of unmeasured relays (-> detect spikes and BWAuth problems)
- Atlas would be abl...Hi Karsten,
I would find it usefull to have a flag measured/unmeasured in relay details objects.
Use cases:
- make graphs based on how big is the fraction of unmeasured relays (-> detect spikes and BWAuth problems)
- Atlas would be able to display the flag, helping the operator with debugging
https://lists.torproject.org/pipermail/tor-relays/2015-May/006946.htmlhttps://gitlab.torproject.org/legacy/trac/-/issues/29399Retire host and services for tordnsel and check (chiwui)2023-11-22T17:25:39ZLinus Nordberglinus@torproject.orgRetire host and services for tordnsel and check (chiwui)Metrics team will re-implement the tordnsel and check services and have them deployment ready by end of March 2019. Once up on a new host, retire chiwui.tpo.Metrics team will re-implement the tordnsel and check services and have them deployment ready by end of March 2019. Once up on a new host, retire chiwui.tpo.anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/32239setup a cache frontend for the blog2023-11-22T17:25:39Zanarcatsetup a cache frontend for the blogdesign docs in https://help.torproject.org/tsa/howto/cache/
launch checklist:
1. alternatives listing and comparison (done)
2. deploy a test virtual machine by hand, say `cache-01.tpo` (done)
3. benchmark the different alternatives ...design docs in https://help.torproject.org/tsa/howto/cache/
launch checklist:
1. alternatives listing and comparison (done)
2. deploy a test virtual machine by hand, say `cache-01.tpo` (done)
3. benchmark the different alternatives (done, ATS and nginx comparable)
4. setup secondary node with Puppet, say `cache-02.tpo` (done)
4. validation benchmark against both nodes (done)
5. lower DNS to 10 minutes wait an hour (done)
6. open firewall (done)
7. lower DNS to 3 minutes (done, around 2019-11-05 16:00:00)
8. point DNS to caches (done)
11. raise DNS back to 1h if all goes well. (done!)
Post launch tasks:
1. update documentation to fill in information from template (done)
2. hit ratio stats in to Prometheus, separate ticket? (done, although missing syslog buffer, see #32461)
3. convert existing varnish setups into Nginx (probably requires Puppet refactoring, see #32462)
Disaster recovery:
1. flip DNS back to backendanarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/4427Support Firefox 8: Re-enable pre-installed addons2023-10-04T03:50:47ZMike PerrySupport Firefox 8: Re-enable pre-installed addonshttps://developer.mozilla.org/en/Firefox_8_for_developers looks Mostly Harmless. This shouldn't be too painful.https://developer.mozilla.org/en/Firefox_8_for_developers looks Mostly Harmless. This shouldn't be too painful.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2510bridge users who configure the non-canonical address of a bridge switch to it...2023-07-16T20:35:20ZRoger Dingledinebridge users who configure the non-canonical address of a bridge switch to its canonical addressIf I run a bridge with
```
Address 128.31.0.34
ORListenAddress 128.31.0.39
```
and then somebody runs their Tor client with
```
bridge 128.31.0.39
```
then it will connect, fetch the bridge descriptor, try to build a circuit by using 128...If I run a bridge with
```
Address 128.31.0.34
ORListenAddress 128.31.0.39
```
and then somebody runs their Tor client with
```
bridge 128.31.0.39
```
then it will connect, fetch the bridge descriptor, try to build a circuit by using 128.31.0.34, fail, and then sit there circuitless and bridgeless.
This bug is important because it means if you run a multihomed bridge, all the clients will immediately switch to using its single canonical address, ignoring all the other addresses you configured. If that canonical address gets blocked, the other addresses don't matter even if they'd still work.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26030Delete "Tor Messenger downloads and updates" section2023-06-29T14:26:57ZcypherpunksDelete "Tor Messenger downloads and updates" sectionhttps://metrics.torproject.org/webstats-tm.htmlhttps://metrics.torproject.org/webstats-tm.htmlhttps://gitlab.torproject.org/legacy/trac/-/issues/31874Automatically test the PTs of bridges2023-05-10T17:27:07ZPhilipp Winterphw@torproject.orgAutomatically test the PTs of bridgesWhen a new bridge is set up, our directory authority is testing its OR port and assigns it the `Running` flag if the OR port is reachable. Nothing however is testing a bridge's PT port(s). This resulted in several bridges having an unrea...When a new bridge is set up, our directory authority is testing its OR port and assigns it the `Running` flag if the OR port is reachable. Nothing however is testing a bridge's PT port(s). This resulted in several bridges having an unreachable obfs4 port, e.g., because the operator failed to whitelist the obfs4 port in their firewall. Let's fix this by testing a bridge's pluggable transport and alerting the operator if the PT is unreachable.
Obfs4proxy has client implementations for most of our currently-deployed PTs, so we could start by writing some glue code that takes as input a bridge line and makes obfs4proxy (and tor) connect to the given bridge.
Another question is where we should do the testing from. Our bridge authority and BridgeDB are the obvious candidates. Our bridge authority currently tests bridges' OR ports but we may not want it to also test PTs.
Finally, how should we let bridge operators know if their PTs are unreachable? We may want to send them an email (if they have contact information in their descriptor), and/or make their tor log a warning.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/29817dead disk on moly2023-03-22T20:59:23Zanarcatdead disk on molyone of the hard drives on moly has died. this was spotted by cymru's staff and confirmed when smartd was installed (#29709).
i have done some research on the machine to figure out what's up, and wrote the following reply to Cymru's peop...one of the hard drives on moly has died. this was spotted by cymru's staff and confirmed when smartd was installed (#29709).
i have done some research on the machine to figure out what's up, and wrote the following reply to Cymru's people:
> [...] I can confirm that one of the hard drives in Moly has failed, according to SMART metrics we have available.
>
> According to smartd, that disk is:
>
> [SEAGATE ST3600057SS 0008], lu id: 0x5000c5003b5bc36f, S/N: 6SL1G7Q60000N1497K0E, 600 GB
>
> It's a 600GB SAS drive. It's part of a megaraid RAID-10 array that has marked the drive as "Firmware state: Failed". I'll go under the assertiont his means the drive is dead.
>
> Being new here, I'm not familiar with the machine either. From what I can tell, it's a Supermicro X8DTU motherboard, and possibly an iXsystems iX1204-R700UB case. Does it look like this this picture?
>
> https://static.ixsystems.co/uploads/2017/08/1204h-t_front.png
>
> If so, the only datasheet I could find is this limited PDF:
>
> https://www.ixsystems.com/wp-content/uploads/2017/09/Server_Line_2017_WEB.pdf
>
> It *does* say the hard drives are hot-swappable, so in theory, it should just be a matter of replacing the hard drive.
>
> It looks like each drive has its own LED, hopefully the one with the amber warning light should be the dead disk. I've issued a command to the RAID controller to make it "flash" the drive LED, so hopefully that will allow you to locate it better.
>
> I *think* the disk controller is new enough for you to simply hot swap the drive with a new one without any other intervention on our part. But it might be better if we are available during the operation. [...]
I've created some documentation on the hardware RAID stuff here:
https://help.torproject.org/tsa/howto/raid/
we're at the waiting step now - we'll see if Cymru can do the replacement and when. i'm still not quite certain we can just hotswap the drive, but I'm hoping we can.anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/32519improve user onboard/offboarding procedures2023-01-23T21:43:54Zanarcatimprove user onboard/offboarding procedureswhile working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332). i added a no...while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332). i added a note about this in the [retire a user](https://help.torproject.org/tsa/howto/retire-a-user/) procedure, but then i realized there are probably many other such services that do *not* connect with LDAP.
On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't. Those services have been identified as particularly out of sync:
* blog.torproject.org, see also #33109
* email, see also #32558
* IRC, the @tor-tpomember group
* Nagios contacts (almost cleaned up, but will still need checking for sysadmins arriving/departing)
* Nextcloud (#32332)
* rt.torproject.org, see #34036 for an example audit
That list is not exhaustive.
Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.
So the following needs to be done here:
* [ ] document, in [new-person](https://help.torproject.org/tsa/howto/new-person/) and [retire-a-user](https://help.torproject.org/tsa/howto/retire-a-user), the various services to add/remove people to
* [ ] automate the above with a script or LDAP
Note that the two pages have different scope: `new-person` is about TSA while `retire-a-user` is broader. This should also be converged, probably in the broader sense.
Also note that a particularly tricky situation is when we want to do a *partial* removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.
The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 for that particularly tricky problem.https://gitlab.torproject.org/legacy/trac/-/issues/10845Make libeay32.dll and ssleay32.dll visible to pluggable transports2023-01-11T15:45:45ZDavid Fifielddcf@torproject.orgMake libeay32.dll and ssleay32.dll visible to pluggable transportsWhen we moved the pluggable transport executables into a PluggableTransports subdirectory, it broke some pluggable transport programs on Windows because they can't find the OpenSSL DLLs. To wit, it broke flashproxy-reg-appspot and flashp...When we moved the pluggable transport executables into a PluggableTransports subdirectory, it broke some pluggable transport programs on Windows because they can't find the OpenSSL DLLs. To wit, it broke flashproxy-reg-appspot and flashproxy-reg-email, because they use the M2Crypto Python module, which relies on OpenSSL. The effect was that the windows bundle was falling back to flashproxy-reg-http.
This patch makes a copy of libeay32.dll and ssleay32.dll in the PluggableTransports directory. This works because the directory containing an executable is part of the DLL search path of the executable.
http://msdn.microsoft.com/en-us/library/7d83bc18.aspx
Nothing is required for linux and mac because their RelativeLink scripts set LD_LIBRARY_PATH and DYLD_LIBRARY_PATH respectively to contain the directory with the OpenSSL dynamic libraries.
Alternative solutions may be to modify the PATH environment variable to include the directory containing tor.exe (which would have an effect similar to that of setting LD_LIBRARY_PATH in RelativeLink.sh), or to call [SetDllDirectory](http://msdn.microsoft.com/en-us/library/windows/desktop/ms686203.aspx) (I don't know if SetDllDirectory is inherited by subprocesses).Erinn ClarkErinn Clarkhttps://gitlab.torproject.org/legacy/trac/-/issues/10030Tor pluggable transport bundle does not work in OS X Mavericks2023-01-11T15:12:48ZTracTor pluggable transport bundle does not work in OS X MavericksWhen I attempt to run the TorBrowser bundle 2.3.25-13 or TorBrowser pluggable transports 2.4.16-beta-1 on OS X 10.9 Mavericks Vidalia gets as far as "Connecting to a relay directory" and makes no further progress.
When I look at the Adv...When I attempt to run the TorBrowser bundle 2.3.25-13 or TorBrowser pluggable transports 2.4.16-beta-1 on OS X 10.9 Mavericks Vidalia gets as far as "Connecting to a relay directory" and makes no further progress.
When I look at the Advanced logs I see messages that it "could not launch managed proxy executable at flashproxy-client". Same for obfsproxy.bin. The reason given for both is 'No such file or directory.'
The files, of course still exist in the package in the same folder as Vidaia and TorBrowser.
**Trac**:
**Username**: msfchttps://gitlab.torproject.org/legacy/trac/-/issues/5741TBB proxy bypass: Some DNS requests not going through Tor2023-01-05T18:15:18ZcypherpunksTBB proxy bypass: Some DNS requests not going through TorObserved behaviour:
When visiting certain websites, for example "http://bitcoincharts.com", with JavaScript enabled, a DNS request for the domain is made without going through Tor. This website is the only one I know of there it happens...Observed behaviour:
When visiting certain websites, for example "http://bitcoincharts.com", with JavaScript enabled, a DNS request for the domain is made without going through Tor. This website is the only one I know of there it happens. This is when running the latest Tor Browser Bundle, properly verified against the gpg signature.
Enabling NoScript to block all JavaScript seems to make the DNS request go away. This was verified by restarting Tor and then disabling JavaScript before visiting the site.
Expected behaviour:
No DNS request should be made through the normal internet, everything should go through Tor. The DNS requests leak information of which sites you are browsing in your Tor Browser.
How to reproduce:
1. Download and verify "tor-browser-gnu-linux-i686-2.2.35-10-dev-en-US.tar.gz"
2. Start up Wireshark to monitor your network, optionally filtering for "dns"
3. Unpack Tor and start it by running the "start-tor-browser" script
4. Once TorBrowser is open, go to "http://bitcoincharts.com/"
5. See DNS request for "bitcoincharts.com" being logged in Wireshark
System information:
Tor Browser Bundle for 32-bit Linux, version 2.2.35-10
Running on Fedora 16
Other:
This is not the first time some rarely triggered bug in Firefox causes Tor to be bypassed, and certainly will not be the last one. Since these bugs have a very high security impact I propose they are guarded against. How about running Firefox inside some kind of firewall that drops all network packets not going to Tor?Mike PerryMike Perry