[tor-dev] Fact-checking a claim about relay/bridge fingerprint authentication
Cecylia, Arlo, Serene, Shelikhoo, and I are writing a research paper
about Snowflake. Here is a draft:
https://www.bamsoftware.com/papers/snowflake/snowflake.20231003.e6e1c30d.pdf
We're writing to check a factual claim in the section about having
multiple backend bridges. Basically, we wanted it to be possible for
there to be multiple Snowflake bridge sites run by different groups of
people, and we did not want to share the same relay identity keys across
all bridge sites, because of the increased risk of the keys being
exposed. Therefore every bridge site has its own relay identity, which
requires the client to know the relay fingerprints in advance and that
it be the client (and not, e.g., the broker) that decides which bridge
to use.
1. Is our general description (quoted below) of the design constraints
as they bear on Tor correct?
2. Is §4.2 "CERTS cells" the right part of tor-spec to cite to make our
point?
https://gitlab.torproject.org/tpo/core/torspec/-/blob/b345ca044131b2eb18e6ae0d5f23643a92aeff34/tor-spec.txt#L707
https://github.com/turfed/snowflake-paper/blob/e6e1c30dde6716dc5e54a32f2134f19068a7f395/snowflake.tex#L2146
A Tor bridge is identified by a long-term identity public key.
If, on connecting to a bridge, the client finds that the
bridge's identity is not the expected one, the client will
terminate the connection \cite[\S 4.2]{tor-spec}. The Tor client
can configure at most one identity per bridge; there is no way
to indicate (with a certificate, for example) that multiple
identities should be considered equivalent. This constraint
leaves two options: either all Snowflake bridges must share the
same cryptographic identity, or else it must be the client that
makes the choice of what bridge to use. While the former option
is possible to do (by synchronizing identity keys across
servers), every added bridge would increase the risk of
compromising the all-important identity keys. Our vision was
that different bridge sites would run in different locations
with their own management teams, and that any compromise of a
bridge site should affect that site only.
In my own experiments, providing an incorrect relay fingerprint leads to
errors in connection_or_client_learned_peer_id:
https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.13/src/core/or/connection_or.c#L1897
[warn] Tried connecting to router at 192.0.2.3:80 ID=
RSA_ID=2B280B23E1107BB62ABFC40DDCC8824814F80A71, but RSA + ed25519 identity
keys were not as expected: wanted + no
ed25519 key but got 2B280B23E1107BB62ABFC40DDCC8824814F80A72 +
1zOHpg+FxqQfi/6jDLtCpHHqBTH8gjYmCKXkus1D5Ko.
[warn] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a
relay. (Unexpected identity in router certificate; IDENTITY; count 1;
recommendation warn; host at
192.0.2.3:80)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PT bridge reporting significant numbers of IP addresses after upgrade to 0.4.8.6; Conflux related?
Hi, I'm highly suspicious of commit 3e18507dc75afcf0c6560e966c9f18942406b0c8 which adds a call to geoip_note_client_seen with a NULL (==no PT) in src/core/or/channeltls.c It's fine for DoS defense, but it's likely what's messing up stats. Regards, trinity-1686a On Tue, 3 Oct 2023 at 21:12, David Fifield wrote: > > The Snowflake bridges do not expose their plain ORPort (they have > `ORPort 127.0.0.1:auto` in torrc), and consequently they have always > reported ≈0 IP addresses in the bridge-ip-transports line of > bridge-extra-info descriptors, with virtually all connecting IP > addresses being instead attributed to the snowflake transport. (The > count is low but nonzero, which I have rationalized as tor making some > small number of internal connections, or something.) > > I upgraded one of the two Snowflake bridges from 0.4.7.13 to 0.4.8.6 on > 2023-09-24. Since then, the number of IP addresses has been roughly > equal to the number of snowflake IP addresses. The ORPort is still not > exposed; these are not external vanilla bridge users. Did something > change between these versions that might cause PT connections to be > double-counted, once for the transport and once for ? > > Here are excerpted bridge-extra-info descriptors from before and after > the version upgrade. Note the bridge-ip-transports lines. > > ``` > @type bridge-extra-info 1.3 > extra-info crusty5 91DA221A149007D0FD9E5515F5786C3DD07E4BB0 > master-key-ed25519 1y9CAtinlbrhDuYBSOBNiCU9Ck1lcY7LErxnzhtxVks > published 2023-09-19 10:46:08 > transport snowflake > bridge-ip-versions v4=13528,v6=1384 > bridge-ip-transports =8,snowflake=14912 > ``` > > ``` > @type bridge-extra-info 1.3 > extra-info crusty5 91DA221A149007D0FD9E5515F5786C3DD07E4BB0 > master-key-ed25519 1y9CAtinlbrhDuYBSOBNiCU9Ck1lcY7LErxnzhtxVks > published 2023-09-29 17:33:20 > transport snowflake > bridge-ip-versions v4=2880,v6=336 > bridge-ip-transports =1632,snowflake=1592 > ``` > > Below is a time series for a whole month. > The thing to notice is not the overall decrease in users on 2023-09-20; > that's due to > https://forum.torproject.org/t/problems-with-snowflake-since-2023-09-20-broker-failure-unexpected-error-no-answer/9346. > Rather, the thing to notice is that before 2023-09-24, ≈ 0; and > after, ≈ snowflake. > > date snowflake > 2023-08-30 4 45240 ← running 0.4.7.13 here > 2023-08-3121193412 > 2023-09-0130195647 > 2023-09-0240200405 > 2023-09-0340201730 > 2023-09-0442195097 > 2023-09-0535190842 > 2023-09-0630189694 > 2023-09-0726191524 > 2023-09-0835195833 > 2023-09-0932196244 > 2023-09-1027146972 > 2023-09-11 6 55491 > 2023-09-1218182519 > 2023-09-1317173536 > 2023-09-1421161396 > 2023-09-1521166379 > 2023-09-1616174350 > 2023-09-1717165063 > 2023-09-1823164734 > 2023-09-1932164075 > 2023-09-2023121623 > 2023-09-21 2 25268 > 2023-09-22 0 4314 > 2023-09-23 0 746 > 2023-09-24 239 606 ← upgrade to 0.4.8.6 on this day > 2023-09-25 1919 1900 > 2023-09-26 3533 3470 > 2023-09-27 11919 11687 > 2023-09-28 20242 19890 > 2023-09-29 26583 26100 > 2023-09-30 25929 25400 > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] PT bridge reporting significant numbers of IP addresses after upgrade to 0.4.8.6; Conflux related?
The Snowflake bridges do not expose their plain ORPort (they have `ORPort 127.0.0.1:auto` in torrc), and consequently they have always reported ≈0 IP addresses in the bridge-ip-transports line of bridge-extra-info descriptors, with virtually all connecting IP addresses being instead attributed to the snowflake transport. (The count is low but nonzero, which I have rationalized as tor making some small number of internal connections, or something.) I upgraded one of the two Snowflake bridges from 0.4.7.13 to 0.4.8.6 on 2023-09-24. Since then, the number of IP addresses has been roughly equal to the number of snowflake IP addresses. The ORPort is still not exposed; these are not external vanilla bridge users. Did something change between these versions that might cause PT connections to be double-counted, once for the transport and once for ? Here are excerpted bridge-extra-info descriptors from before and after the version upgrade. Note the bridge-ip-transports lines. ``` @type bridge-extra-info 1.3 extra-info crusty5 91DA221A149007D0FD9E5515F5786C3DD07E4BB0 master-key-ed25519 1y9CAtinlbrhDuYBSOBNiCU9Ck1lcY7LErxnzhtxVks published 2023-09-19 10:46:08 transport snowflake bridge-ip-versions v4=13528,v6=1384 bridge-ip-transports =8,snowflake=14912 ``` ``` @type bridge-extra-info 1.3 extra-info crusty5 91DA221A149007D0FD9E5515F5786C3DD07E4BB0 master-key-ed25519 1y9CAtinlbrhDuYBSOBNiCU9Ck1lcY7LErxnzhtxVks published 2023-09-29 17:33:20 transport snowflake bridge-ip-versions v4=2880,v6=336 bridge-ip-transports =1632,snowflake=1592 ``` Below is a time series for a whole month. The thing to notice is not the overall decrease in users on 2023-09-20; that's due to https://forum.torproject.org/t/problems-with-snowflake-since-2023-09-20-broker-failure-unexpected-error-no-answer/9346. Rather, the thing to notice is that before 2023-09-24, ≈ 0; and after, ≈ snowflake. date snowflake 2023-08-30 4 45240 ← running 0.4.7.13 here 2023-08-3121193412 2023-09-0130195647 2023-09-0240200405 2023-09-0340201730 2023-09-0442195097 2023-09-0535190842 2023-09-0630189694 2023-09-0726191524 2023-09-0835195833 2023-09-0932196244 2023-09-1027146972 2023-09-11 6 55491 2023-09-1218182519 2023-09-1317173536 2023-09-1421161396 2023-09-1521166379 2023-09-1616174350 2023-09-1717165063 2023-09-1823164734 2023-09-1932164075 2023-09-2023121623 2023-09-21 2 25268 2023-09-22 0 4314 2023-09-23 0 746 2023-09-24 239 606 ← upgrade to 0.4.8.6 on this day 2023-09-25 1919 1900 2023-09-26 3533 3470 2023-09-27 11919 11687 2023-09-28 20242 19890 2023-09-29 26583 26100 2023-09-30 25929 25400 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [Update] Network Status APIs
Greetings Tor devs, I wanted to give a quick update on the progress of the Network Status APIs[0]. First of all, a couple of weeks ago we have deployed an initial version of the service internally so that we can benchmark and test it and see how it holds. Plus, we now have developed three more APIs: `/details`, `/clients`, `/weights`. In total, we now have covered almost every endpoint that is currently provided by onionoo. Just to give you a little bit more insights, `/summary` and `/details` fetch data from the Network Health team database and return a response identical to the one that onionoo clients expect right now. On the other hand, `/clients`, `/weights` and `bandwidth` will proxy the request to VictoriaMetrics. In the upcoming weeks we plan to stabilize and test these endpoints further and do some perf improvements. Meanwhile, we are also working on documenting the APIs so that potential clients know how to use them, when they'll be available. Those can be found in the project's repo Wiki[1]. Please do reach out to me, hiro or GeKo if you have any ideas or feedback you'd like to share with us. Cheers, Matt [0]: https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/ [1]: https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/-/wikis/API-Documentation ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
