The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-12-01T18:05:43Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/21Pass client command line args in as SOCKS args2022-12-01T18:05:43ZCecylia BocovichPass client command line args in as SOCKS argsThis allows us to move configuration from the `ClientTransportPlugin` line to the `Bridge` line.This allows us to move configuration from the `ClientTransportPlugin` line to the `Bridge` line.Ship Conjure in Alpha versions of Tor BrowserCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41455Tor Browser dev build cannot launch tor2022-11-17T18:04:25ZrichardTor Browser dev build cannot launch torThis happens to me on Linux Mint 21 (which I beleive is based on the 22.04 Ubunutu series). I did an in-place upgrade from Linux Mint 20.3 before this behaviour started happening. I have not tested to see if this happens on a fresh Linux...This happens to me on Linux Mint 21 (which I beleive is based on the 22.04 Ubunutu series). I did an in-place upgrade from Linux Mint 20.3 before this behaviour started happening. I have not tested to see if this happens on a fresh Linux install.
From IRC:
```
<richard> ok mystery.. not solved but narrowed down
<richard> so for some context, i'm having this tor failed to launch issue on my desktop PC which i just upgraded to Linux Mint 21 (based off of the latest ubuntu)
<richard> (this PC used to be able to build/run tor-browesr in the past no probem)
<richard> so, the issue occurs
<richard> when build tor-browseer and deploy over a freshly fetch'd 12.0a4 bundle
<richard> launch tor-browser, and it tries to launch tor, and tor exits with 127 error code (haven't tracked down deeper than that)
<richard> tor will launch from the cmdline no issue if i set the LD_LOAD_PATH appropriately first pointing to the shipped libs
<richard> if i first make build and make deploy
<richard> then copy the old/shipped firefox over the built firefox bin (but leave the rest as is) then everything launches fine
<richard> and finally
<richard> if i build a locally copy of tor, and drop it over the shipped version everything is fine
<richard> so if i build all the bins with the same toolchain (firefox and tor) then everything works fine
<richard> mix and match makes things sad
<richard> and a fresh un-touched 12.0a4 alpha also runs fine
<richard> anyway i'm unblocked for now and will open a ticket with the above findings and we can deal with it later
<ma1> is mix & match on any system something we actually (want to) support?
<richard> no, it's purely a build/development problem
<ma1> yes, I mean for developers.
<richard> yes we def want to support that :D
<richard> either that or we integrate tor into the tor-browser build process
<richard> :p
<richard> or some other smart solution
<ma1> I mean, doesn't mach boostrap install a local toolchain to work-around compat issues like this? Or am I completely missing the point?
<richard> so I *think* the problem is that my local dev firefox is being built with different versions of libs than the tor we ship with
<richard> and the deploy step we do is 'download the built bundle, copy our local firefox bins over'
<richard> so you get a mismatch of toolchaisn used for firefox vs tor
<richard> but like i said more investigation is needed to see what is actually failing
<richard> my desktop's clang is also now on version 14 vs my laptop on version 10 which who knows if that makes a difference vOv
<richard> (laptop dev env works fine, but i didn't do an OS upgrade there)
```
So the work-around is to build a local copy of tor, and deploy that over `.binaries/dev/Browser/TorBrowser/Tor/tor`. My best hypothesis so far is that `tor` is inheriting some sort of `LD_FOO` variable from `firefox` but we would need to look into this further.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40710relay: Add socket family to connections metrics2022-11-08T20:26:55ZDavid Gouletdgoulet@torproject.orgrelay: Add socket family to connections metricsThe newly added connection metrics on the MetricsPort lack the socket family (IPv4 or IPv6). It would be very much desirable to have them to differentiate.The newly added connection metrics on the MetricsPort lack the socket family (IPv4 or IPv6). It would be very much desirable to have them to differentiate.Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40708relay: Add congestion control stats to MetricsPort2022-11-17T20:08:52ZDavid Gouletdgoulet@torproject.orgrelay: Add congestion control stats to MetricsPortI will quote @mikeperry from IRC:
```
<+mikeperry> dgoulet: so a counter at the top of dos_note_circ_max_outq(), and a moving average of cc->cwnd in
congestion_control_vegas_exit_slow_start() are the two most useful easy a...I will quote @mikeperry from IRC:
```
<+mikeperry> dgoulet: so a counter at the top of dos_note_circ_max_outq(), and a moving average of cc->cwnd in
congestion_control_vegas_exit_slow_start() are the two most useful easy additions to metricsport that
I can think of for CC.. other points would be harder because they happen multiple times per circuit.
<+mikeperry> dgoulet: maybe a moving average of cc->cwnd upon circuit close?
<+mikeperry> dgoulet: oh hrmm.. I wonder if the Exit DoS is causing more XON/XOFF, actually
<+mikeperry> dgoulet: I suppose we could also count how often cc->vegas_params.delta and cc->vegas_params.ss_cwnd_max
get hit in congestion_control_vegas_process_sendme() if you are still on a metricsport rampage. just a
raw counter there might be interesting, and easy
```Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40697Check if keccak-tiny is impacted by CVE-2022-374542022-11-16T20:02:31ZAlexander Færøyahf@torproject.orgCheck if keccak-tiny is impacted by CVE-2022-37454Looks like at some generic SHA-3 implementations suffer from a buffer overflow described a bit more in depth here: https://mouha.be/sha-3-buffer-overflow/
I guess we should look if our fallback implementation suffers from this as well?Looks like at some generic SHA-3 implementations suffer from a buffer overflow described a bit more in depth here: https://mouha.be/sha-3-buffer-overflow/
I guess we should look if our fallback implementation suffers from this as well?Tor: 0.4.7.x-post-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40070Average bandwidth module complaining about invalid line2022-11-10T16:48:20ZHiroAverage bandwidth module complaining about invalid lineI have noticed the average bandwidth stats module is not completing cleanly on metrics.tpo update.
```
2022-10-20 00:08:42,342 WARN o.t.m.s.main.Main:76 Caught an exception when invoking the main method of the org.torproject.metrics.sta...I have noticed the average bandwidth stats module is not completing cleanly on metrics.tpo update.
```
2022-10-20 00:08:42,342 WARN o.t.m.s.main.Main:76 Caught an exception when invoking the main method of the org.torproject.metrics.stats.advbwdist.Main module. Moving on to the next module, if available.
java.lang.reflect.InvocationTargetException: null
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.torproject.metrics.stats.main.Main.main(Main.java:72)
Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 10, length 4
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3319)
at java.base/java.lang.String.substring(String.java:1874)
at org.torproject.metrics.stats.advbwdist.Main.main(Main.java:158)
... 5 common frames omitted
```
I have found out in the code that the date line is not formatted as it should somehow.
I have also found that the file ``/srv/metrics.torproject.org/metrics/work/modules/advbwdist/stats/advbwdist-validafter.csv`` and an invalid date in one of the recent lines. I have deleted that
For the future since it is difficult to understand why this is happening we should allow the exception to be logged so we can see the culprit line right away and then take the necessary steps to parse it properly.Metrics OKRs Q3-Q4 2022HiroHirohttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40646Don't build Español AR anymore2022-10-28T17:50:22ZPier Angelo VendrameDon't build Español AR anymoreIt seems we've switched to es-ES only elsewhere (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41369#note_2845075).It seems we've switched to es-ES only elsewhere (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41369#note_2845075).Sponsor 131 - Phase 5 - Ongoing Maintenancerichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40645Verify we no longer depend on any signed tags from sysrqb and gk , and remove...2022-12-20T14:33:29ZrichardVerify we no longer depend on any signed tags from sysrqb and gk , and remove them from torbutton.gpgSponsor 131 - Phase 5 - Ongoing Maintenancerichardrichardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40683Build issues (at least) on arm64 macOS2022-10-27T15:40:20ZAlexander Færøyahf@torproject.orgBuild issues (at least) on arm64 macOSDuring the meeting in Limerick, @tla, @eta and I ran into a build issue with C tor on iOS. This was due to an XCode update that arrived while we were in the meeting.
It turns out, this also impacts desktop builds on (at least) arm64 bui...During the meeting in Limerick, @tla, @eta and I ran into a build issue with C tor on iOS. This was due to an XCode update that arrived while we were in the meeting.
It turns out, this also impacts desktop builds on (at least) arm64 builds.
@mikeperry tested the same method we used to get iOS to build again and had to do a bit more work here:
```
#!/bin/sh
# libtor.a on MacOS Silicon is thin (arm64 only)
mkdir arm64
mv libtor.a arm64
cd arm64
ar x libtor.a
rm __.SYMDEF\ SORTED
cd ..
libtool -static arm64/*.o -o libtor.a
# libtor-testing.a on MacOS Silicon is thin (arm64 only)
cd src/test
mkdir arm64
mv libtor-testing.a arm64/
cd arm64
ar x libtor-testing.a
rm __.SYMDEF\ SORTED
cd ..
libtool -static arm64/*.o -o libtor-testing.a
```
We need to make sure to get this into Tor's build system for macOS users. We also need to make sure we don't break setups on x86-64 as well as people on older XCode's? The latter may be hard to do.Tor: 0.4.7.x-post-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/19Get Android Version in Rust2022-11-03T13:26:38ZcybertaGet Android Version in RustIn order to distinguish if getConnectionOwnerUid() is available (#18) and on the other hand to know if the app is allowed to read and parse from proc/ (possible in older Android versions) having a JNI wrapper that returns the Android ver...In order to distinguish if getConnectionOwnerUid() is available (#18) and on the other hand to know if the app is allowed to read and parse from proc/ (possible in older Android versions) having a JNI wrapper that returns the Android version seems to be useful. We may need that API in other circumstances as well in the future.Onionmasq 1.0.0: Initial releasecybertacybertahttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/17Wrap the protect(int) function via JNI2023-01-23T10:02:35ZAlexander Færøyahf@torproject.orgWrap the protect(int) function via JNIFrom Onionmasq, we need a way to call the Java function protect() on our guard connection to ensure it does not get tracked by the VPN state machine on Android.From Onionmasq, we need a way to call the Java function protect() on our guard connection to ensure it does not get tracked by the VPN state machine on Android.Onionmasq 1.0.0: Initial releaseankitgusai19ankitgusai19https://gitlab.torproject.org/tpo/network-health/metrics/monitoring-and-alerting/-/issues/20Add counts for nickname prefix and contact string to network monitoring scripts2022-09-23T16:20:19ZHiroAdd counts for nickname prefix and contact string to network monitoring scripts@gk showed me how https://nusenu.github.io/OrNetRadar/ keeps track of how many tor relays or bridges share the same nickname prefix or contact info.
It can be useful to start tracking these two features in Prometheus and eventually add ...@gk showed me how https://nusenu.github.io/OrNetRadar/ keeps track of how many tor relays or bridges share the same nickname prefix or contact info.
It can be useful to start tracking these two features in Prometheus and eventually add an alert to send an email when we see a large number of relays with the same information.Metrics OKRs Q3-Q4 2022HiroHirohttps://gitlab.torproject.org/tpo/core/tor/-/issues/40674Confidential: TROVE-2021-009: Improved DNS cache oracle2023-05-23T20:49:28ZpullsConfidential: TROVE-2021-009: Improved DNS cache oracleHi,
This is a new confidential ticket regarding the improved DNS cache oracle, to be presented (hopefully, conditionally accepted at time of writing) at USENIX Security 2023 in the paper "Timeless Timing Attacks and Preload Defenses in ...Hi,
This is a new confidential ticket regarding the improved DNS cache oracle, to be presented (hopefully, conditionally accepted at time of writing) at USENIX Security 2023 in the paper "Timeless Timing Attacks and Preload Defenses in Tor’s DNS Cache".
Below is the original report, lightly reformatted.
> # A timeless side-channel in tor's DNS cache
>
> Exit-relays currently maintain a DNS cache for all domains directly
> (with RESOLVE) or indirectly (with CONNECT) resolved by the
> exit. Domains are cached for five or 60 minutes, based on their
> *clipped* TTL. All circuits at an exit share the same DNS cache.
>
> One known way of determining if a domain is cached or not is to use
> time: a domain is considered cached or not depending on if the exit
> responds "fast" or "slow" to a request to resolve it. An attacker
> that learns if a domain is cached or not learns about destinations
> of earlier exit-traffic at the exit. Such information can be a
> privacy-harm, e.g., see the work on "Website Fingerprinting with
> Website Oracles" where the DNS cache is used to confirm traffic
> classification by constructing a so-called website oracle [1]. In
> general, it is more harmful if an attacker can confirm a website
> classification to an unpopular website on the Tor network (because,
> per definition, learning that an unpopular website was visited
> within some time frame is more information than learning that a
> popular website, like say YouTube, was visited within that same time
> frame).
>
> While prior attacks have used timing, we here report a *timeless*
> side channel attack in tor's DNS cache. This makes the attack much
> more robust than if based on time. We have made in the order of 10^7
> queries (only for our own domain) in the network with zero false
> positives. Not having any false positives is consistent with our
> understanding of the attack, see description below.
>
> ## The attack
> The attack is relatively straightforward:
> 1. Create a one-hop circuit to an exit.
> 2. Send a RESOLVE cell for an arbitrary domain name.
> 3. Send two RESOLVE cells in the same TLS record. The first RESOLVE
> cell is for a domain name that we want to check if it is
> (un)cached. The second RESOLVE cell is for a domain name that we
> know is cached. I.e., use domain name from step 2.
> 4. Observe the order in which the two RESOLVED cells are returned.
> The first RESOLVE query was uncached if the relative cell order
> changed, otherwise cached.
>
>
> The trick here follows from tor's handling of incoming RESOLVE
> cells. First of all, the two cells will be processed immediately
> after one another without any noise because they arrived as one
> unit. Secondly, responses to cached RESOLVE queries can be and are
> queued for sending immediately. Third, an uncached RESOLVE query
> has no response and so is scheduled with an event callback. This is
> where the change in order happens if the first RESOLVE cell is
> uncached. In contrast, the change in order does not happen if both
> RESOLVE cells are cached.
>
> Based on suggestions from Roger, we focused above on using the TLS
> record to force cells to arrive at an exit at the same time in a
> given order. Likely it's just as feasible to pack two small TLS
> records (one cell each) in one TCP packet.
>
> This setup can be run in parallel to create a timeless website
> oracle ("tlwo") for the entire Tor network without false positives.
> It works about as well with a multi-hop circuit: our two cells often
> get propagated in the same TLS records.
>
> See the attached tor-0.4.6.6--tlwo.patch for additional details on
> how to reproduce the attack. You will need to build a modified tor
> proxy and optionally run carml.
>
> ## The improved attack
>
> At a first glance the attacker can only learn whether a domain name
> was uncached or cached within the past five or 60 minutes (depending
> on clipped TTL). It is possible to infer the exact time that a
> domain was cached as follows:
> 1. Determine the expected clip value. For example, many domains are
> always clipped to five minutes because of how authoritative DNS
> servers set TTLs.
> 2. Repeatedly perform step 3 from the above attack, until the first
> RESOLVE request is no longer cached. Note down the time spent doing
> this as `t` seconds.
>
> If the expected clip was five minutes, the entry was cached `300-t`
> seconds ago. This means that the leaked information is finer-grained
> than one might expect and not particularly time-sensitive: an
> attacker has (at least) five minutes to query exits in the network.
>
> ## Defenses
>
> Our take on a defense is based on the assumption that the underlying
> issue leading to the timeless side-channel is unfixable /
> undesirable to sufficiently address: packing several cells into the
> same TLS record / TCP packet is a must for performance, adding
> latency to every DNS query is prohibitively expensive, and an
> attacker can always pretend being one or more relays providing cells
> packed in such a way that the attacker can infer if a domain was
> cached or not (if anything because of difference in time).
>
> ## A short-term mitigation
>
> One relatively easy *mitigation* is to randomize the TTL in
> `clip_dns_ttl()`. This would randomize the expiration time of the
> entry in the cache (see `set_expiry()`), which would make the
> cached/uncached state of a domain be within a time frame determined
> by the distribution that the randomness is sampled from. The goal is
> to at least get away from exact-second precision of the attack as-is
> today. Unfortunately, a website visit typically consists of multiple
> domains resolved at the same time the website is visited (with TTLs
> clipped long or short), so the randomness will cancel out to a
> degree. Regardless, this is something relatively easy to
> implemented with few downsides.
>
> When communicating to the wider community about the short-term
> mitigation, one could also emphasize the value of periodically
> injecting visits to particularly sensitive website in the network:
> "regularly check that the websites you care deeply about are
> reachable over Tor to add noise into the network's caches".
>
> ## Long-term defense
>
> After some thinking for a long-term defense, we landed on focusing
> on the purpose of the cache at exits in the first place. We consider
> only web-traffic here to explain the defense. Extending the defense
> to consider essential non-web domains is straightforward (e.g., base
> on the Cisco Umbrella list instead).
>
> The main purpose of the DNS cache is performance, with the added
> bonus of leaking less to DNS resolvers on cache hits. The DNS cache
> is only useful if there's a cache hit. In general, there are two
> cases when we can expect cache hits: (1) subsequent or concurrent
> streams connecting to the same domain *in the same circuit*, and (2)
> someone else visited a website with the same (or subset of) domains
> at the same exit within the time that domains are cached.
>
> For (1), we believe that the DNS cache could be *per circuit*: add
> `circuit ID` to each entry in the DNS cache, and only use cached
> entries for streams that were connected via the same circuit that
> injected the entry into the cache. These per circuit entries should
> be removed as soon as the circuit is closed. This leaves
> *inter-circuit* resolution performance identical to today. It also
> saves memory by not keeping entries around for longer than
> necessary, and more importantly, removes the privacy harm caused by
> caching rarely visited domains.
>
> For (2), we believe that the key is to determine which domains are
> likely to be useful to cache. Our initial analysis shows that there
> are surprisingly few domains that we can expect to be useful to
> cache (somewhere a bit more than top 100 most popular websites
> should be enough). This is because of the long-tail nature of
> website popularity (e.g., Alexa or Tranco lists), the size and usage
> of the Tor-network, TTLs used by popular websites today (~75% have
> TTLs below 300 seconds), and that most domains are unique to
> individual websites (~85% of domains on Tranco top 1k). Basically,
> for a domain, the question to cache or not boils down to how likely
> it is that another circuit will request the same domain (=website
> the domain is on) within its TTL (=five minutes).
>
> We are in luck here, because domains that are popular are those that
> are commonly visited in the network, so the privacy harm of
> inferring that they're cached is small (because we expected them to
> be cached somewhere already). On the flip side, rarely visited
> domains are those that may cause the most harm, but they're useless
> to cache, so we shouldn't.
>
> In gist, we think tor's DNS cache should only cache entries
> per-circuit and maintain an allowlist of domains that may be
> globally cached. At the cost of more complexity, this should result
> in negligible resolver performance impact on the network, remove a
> source of privacy harms, and reduce memory usage at exits.
>
> For the allowlist, we have submitted in parallel a research safety
> board request on network-wide measurements we could do to gain
> confidence in such a list. With some luck, we think it's possible to
> derive it from Alexa/Tranco/Cisco Umbrella lists ~monthly and still
> get most of the performance gain of the DNS cache.
>
> ## Extra: also for confirmation attacks?
>
> Recall that our attack also works with multi-hop circuits. If the
> way in which cells are packed into TLS records propagate somewhat
> intact through the Tor network, it would be trivial for an exit to
> introduce patterns that a guard could use to confirm where a circuit
> exited. For example, imagine an exit relay that always send one
> cell per TLS record. A guard relay could look for that.
>
> We tried a few variations of the above in Chutney - both sending
> fewer and more cells per TLS record when compared to a normal Tor
> relay. As long as an unmodified middle relay processes these cells
> in between, the introduced cell patterns are destroyed. For
> example, seven cells that arrived in separate TLS records get merged
> into a single TLS record by the middle relay. This is the reason
> why our attack still works across multiple hops: two cells come in,
> and they fit in a single TLS record and so are sent as such. Other
> channel cells may fill up a TLS record though, in which case our two
> cells could potentially be packed in two intermediate TLS records
> (thereby risking a false positive).
>
> We were able to preserve the introduced patterns if packet timings
> are also changed. This is a different unrelated attack vector,
> however [2].
>
> ## References
>
> 1. Pulls and Dahlberg, Website Fingerprinting with Website Oracles,
> PETS 2020
>
> 2. Luo et al., Exposing invisible timing-based traffic watermarks
> with BACKLIT, CSAC 2011
>
> Best regards,
> Rasmus Dahlberg and Tobias PullsTor: 0.4.7.x-post-stableRasmus Dahlbergrasmus@rgdd.seRasmus Dahlbergrasmus@rgdd.sehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40673Percentage fraction over 100% in logs2022-10-20T23:47:23Zcomputer_freakPercentage fraction over 100% in logs```
[notice] General overload -> Ntor dropped (635498) fraction 325.6826% is above threshold of 0.5000%
[notice] General overload -> Ntor dropped (568293) fraction 222.1682% is above threshold of 0.5000%
[notice] General overload -> Ntor...```
[notice] General overload -> Ntor dropped (635498) fraction 325.6826% is above threshold of 0.5000%
[notice] General overload -> Ntor dropped (568293) fraction 222.1682% is above threshold of 0.5000%
[notice] General overload -> Ntor dropped (448158) fraction 247.2855% is above threshold of 0.5000%
```
Can a percentage _fraction_ ever be over 100% ?Tor: 0.4.7.x-post-stableRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40644Safety checks for RTT BDP calc2023-12-31T20:22:57ZMike PerrySafety checks for RTT BDP calc@dgoulet and I noticed some potential but rare integer overflow cases for RTT-based cwnd calculation, while investigating queue use on test relays wrt the DoS. Basically if the clock is stopped, and a client manages to send a bunch of co...@dgoulet and I noticed some potential but rare integer overflow cases for RTT-based cwnd calculation, while investigating queue use on test relays wrt the DoS. Basically if the clock is stopped, and a client manages to send a bunch of control cells on a circuit that are not subject to congestion control, and the orconn is blocked, the channel queue can exceed the congestion window, which could cause the `cwnd = MAX(cwnd - chan_q, cc->cwnd_min)` in `congestion_control_update_circuit_bdp()` to underflow.
Should be very very hard to trigger, and not remotely exploitable, but maybe it could happen. Might as well add some checks.Tor: 0.4.7.x-post-stableMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40642Add parameter to cap cwnd during slow start2022-08-19T17:14:46ZMike PerryAdd parameter to cap cwnd during slow startAfter discussing queue overload with @dgoulet based on some analysis of trying to minimize `circ_max_cell_queue_size` for congestion control, and reviewing old simulator results, I realized that slow-start overshoot is still a component ...After discussing queue overload with @dgoulet based on some analysis of trying to minimize `circ_max_cell_queue_size` for congestion control, and reviewing old simulator results, I realized that slow-start overshoot is still a component cause of large queues. In shadow, the max cwnd after 4MB for normal circuits was ~4000 cells, but slow start maxed out as high as 20000 cells.
Unfortunately, our slow start increment (50%) is already pretty low. I think a better fix rather than lowering it further is to provide a parameter to exit slow start at some max (say 5000 or 10000). Then, steady state can ramp up or down depending on spare capacity after that max, without as much risk of overshoot.
I can write this and test it in shadow, and see if it helps reduce large queue sizes there without an impact on performance.Tor: 0.4.7.x-post-stableMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/arti/-/issues/525Check message types before decoding cells?2024-02-13T17:41:26ZNick MathewsonCheck message types before decoding cells?It would be lovely if we could reject unacceptable messages based on their message types before we even parse them into a `ChanMsg` or `RelayMsg`.
This change would reduce the some side-channel risks of our current eager parsing strate...It would be lovely if we could reject unacceptable messages based on their message types before we even parse them into a `ChanMsg` or `RelayMsg`.
This change would reduce the some side-channel risks of our current eager parsing strategy. (For example, suppose that we want to make support for onion-service-only messages optional. If we do that, then an attacker could tell when the client has onion service support by sending an unexpected INTRODUCE2 cell, and trying to figure out whether the bad cell was treated as an unrecognized message or a misformatted one.)Arti: Onion service supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40050Lower onionperf instance guard rotation period2023-02-12T04:16:33ZMike PerryLower onionperf instance guard rotation periodOur guard based instances may not be gathering enough datapoints of guards to do analysis on Guard cutoffs via filtering and for stable graphs on the website, because the rotation period is 12 hours.
To do this, we first need to look at...Our guard based instances may not be gathering enough datapoints of guards to do analysis on Guard cutoffs via filtering and for stable graphs on the website, because the rotation period is 12 hours.
To do this, we first need to look at how long it takes to learn a circuit build timeout, and then we may need to increase the measurement frequency to get more datapoints (I believe there is a sleep between datapoints as a tunable parameter).
So the pieces here are:
- [ ] Look at the amount of time between `DROPGUARDS` command and the `BUILDTIMEOUT_SET COMPUTED` control port event
- [ ] Look at how often we make measurements and make a call if we can increase this rate
- [ ] Lower the guard rotation period and increase the measurement period such that we get a better balance between guard and relay coverage
- [ ] Possibly disable measurement entirely between `DROPGUARDS` and `BUILDTIMEOUT_SET COMPUTED` to avoid wasting bandwidth
I will have to get a feel of how long it takes to learn a CBT on the instances to make good calls here for exact values, but in general, I think it is fine if we only get somewhere between 10 and 100 datapoints per guard rotation.Metrics OKRs Q3-Q4 2022HiroHirohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/15Secure connection between Conjure station and bridge2023-04-12T23:47:27ZCecylia BocovichSecure connection between Conjure station and bridgeThe Conjure station proxies TCP connections from clients to the deployed Conjure bridge (https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Conjure-Bridge). These connections are prepended with a plaintext PRO...The Conjure station proxies TCP connections from clients to the deployed Conjure bridge (https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Conjure-Bridge). These connections are prepended with a plaintext PROXY header that contains the client's IP address. We're working with the CU Boulder team on securing this connection through the use of SSH tunnels or Wireguard.Ship Conjure in Alpha versions of Tor BrowserCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/14Build conjure reproducibly in Tor Browser2023-02-01T15:13:39ZCecylia BocovichBuild conjure reproducibly in Tor BrowserAdd a conjure project to [tor-browser-build](https://gitlab.torproject.org/tpo/applications/tor-browser-build/) to produce a Conjure client binary and relevant torrc defaults.Add a conjure project to [tor-browser-build](https://gitlab.torproject.org/tpo/applications/tor-browser-build/) to produce a Conjure client binary and relevant torrc defaults.Ship Conjure in Alpha versions of Tor BrowserCecylia BocovichCecylia Bocovich