tor-dev

tor-dev@lists.torproject.org

5 participants
3594 discussions

Why is my bridge not publishing statistics?
by David Fifield 05 Jun '17

05 Jun '17

I searched for the Snowflake bridge in Atlas, and couldn't find it. Its fingerprint is 2B280B23E1107BB62ABFC40DDCC8824814F80A72. Its torrc is stock "Last updated 9 October 2013 for Tor 0.2.5.2-alpha" except for these settings: ContactInfo David Fifield <dcf(a)torproject.org> SOCKSPort 0 ORPort 9001 BridgeRelay 1 ExtORPort auto ServerTransportPlugin snowflake exec /usr/local/bin/snowflake-server --acme-hostnames snowflake.bamsoftware.com --acme-email dcf(a)torproject.org --log /var/log/tor/snowflake-server.log ServerTransportListenAddr snowflake 0.0.0.0:443 Its ORPort 9001 is blocked by the local firewall, because it is meant to be only a Snowflake bridge, and not a vanilla bridge. (Most of the default Tor Browser obfs4 bridges are configured the same way, with their ORPort blocked.) There are these messages in the log (which I exxpected): [warn] Your server (37.218.242.151:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Why is the bridge not appearing in Atlas? I initially suspected https://bugs.torproject.org/18050, whose changelog entry is: - Check that both the ORPort and DirPort (if present) are reachable before publishing a relay descriptor. Otherwise, relays publish a descriptor with DirPort 0 when the DirPort reachability test takes longer than the ORPort reachability test. Closes bug #18050. Reported by "starlight", patch by "teor". Bugfix on 0.1.0.1-rc, commit a1f1fa6ab on 27 Feb 2005. But if it's the case that an unreachable ORPort causes descriptors not to be uploaded, then why do the default obfs4 bridges appear in Atlas? For example: https://atlas.torproject.org/#details/D9C805C955CB124D188C0D44F271E9BE57DE2… https://atlas.torproject.org/#details/D3D4A456FCB5F301F092F6A49ED671B84B432… https://atlas.torproject.org/#details/11A3982C417AF37230F576006405BE5338F41… Actually, now that I look at it, I notice some other default bridges are not present in Atlas, for example the two from https://bugs.torproject.org/21917, which went out in Tor Browser 6.5.2: C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4 0BAC39417268B96B9F514E7F63FA6FBA1A788955 What's going on and how can we fix it? You can find a list of default bridge fingerprints here: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-D…

4 12

Safe post-quantum RSA? So says DJB and others
by Hugo Maxwell Connery 01 Jun '17

01 Jun '17

Interesting (and surprising): https://eprint.iacr.org/2017/351.pdf /Hugo

2 1

[PATCH] fix GCC 7 implicit fallthroug warnings
by Andreas Stieger 30 May '17

30 May '17

Hello, 6 patches that fix -Wimplicit-fallthrough in GCC 7 on master, by adding __attribute__ ((fallthrough)); or break, as required. Additionally, the patch fixes the same on maint-0.3.0, the warning is no longer present in master. 0001-Fix-implicit-fallthrough-warning-in-GCC-7-in-tor_gzi.patch Please review, Andreas -- Andreas Stieger <astieger(a)suse.com> Project Manager Security SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

2 2

specific From: for tor-bugs ML emails (like tor-wiki-changes)
by nusenu 25 May '17

25 May '17

Hi, I like how tor-wiki-changes ML emails have a specific From: so you can directly see who made a change without looking into the body of the email. It would be great if we could get the same level of information into the From of tor-bugs ML emails. (currently it is a static string "Tor Bug Tracker & Wiki") regards, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

1 0

onionoo.tpo hardly reachable
by nusenu 24 May '17

24 May '17

Hi Karsten, onionoo is hardly reachable since about 17 hours ago. Is this only externally facing or will this also cause onionoo to miss descriptors internally? Any ETA on when this will improve? thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 10

txtorcon 0.19.3
by meejah 24 May '17

24 May '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fixing another regression, 0.19.3 causes txtorcon to (once again) correctly work with SocksPort lines containing unix socket options when used with txtorcon.connect(). Thas bug was introduced in 0.19.0 which reduced the number of GETINFO and GETCONF calls (to help filtering-proxies). You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.19.3 https://github.com/meejah/txtorcon/releases/tag/v0.19.3 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.19.3.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.19.3.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check f73396667909a3c7a98f4dd865edf4ed6a2518ee5a935d92e18b8a479ec244fd txtorcon-0.19.3.tar.gz e0901f7743a43ed6389f0de31c1f547d89b32723a5ae9316d6cae9ad8eacdbea txtorcon-0.19.3-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJZJTJVAAoJEMJgKAMSgGmn5woIAIyFRa7NhSNm/zMMJE92jtgA C3UY55q3FF4VycC7K77EkaudHPMqlr9MA3EeGkx4NVu0KAX7lIT4GFCsZTlnOdXm rglZ7FFYh49KoAWSMGCMJ7LlauYUitXptynte3lWcqbvjGJkCqMd6WuXslTooSI2 68gq/aoTbXoHWNg1C6DtBhR0JqvN+Vq7ARHyqc4bDloh1LXAvEUwsbKvDtrpXTbe eRwMlKTKoUXhXjxO37NtoNSxT6HUFNcOFOYcLnWtBMPty9W90xY2wC1LbWwYymbY Pk97OUceSyoHxAGsBYjKCdTXEWB6TO5lmHE3+t48OqiYt4ELAWkJFUBf5d6Mnto= =ZRcE -----END PGP SIGNATURE-----

1 0

Further New Hope Improvements
by bancfc＠openmailbox.org 24 May '17

24 May '17

New paper released a week ago makes further improvements on New Hope, reducing decryption failure rates, ciphertext size and amount of entropy needed. This new version will be submitted as a NIST PQ competition candidate. https://eprint.iacr.org/2017/424

2 1

Latest draft policy on handling tor security issues
by Nick Mathewson 23 May '17

23 May '17

Hi, all! I put this on the wiki, but I think it should have more attention. https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Securit… It's the draft policy that we're using to guide our action when we run into security issues in the program "tor". It's not finalized, but we've been trying to follow it as we notice issues in order to identify any problems in it. It's had some review already, but more is always welcome. Have a look! -- Nick

1 0

Tomorrow (5/23) is a core-tor trac-attack day!
by Nick Mathewson 22 May '17

22 May '17

Hi! At our meeting just now, the network team discussed our needs for a more organized set of trac tickets about past and previous versions. (This is about tickets against Tor itself, though if you want to jump in on some other component, you're welcome to do so!) So, tomorrow, I'm planning to spend (nearly?) all my work hours on #tor-dev, working on organizing trac tickets. And more help is always welcome! Drop by and say hi and help us clean out our bugtracker! Areas of interest will be: * Wrapping up tickets that are associated with older release milestones * Trying to make sure all current-milestone tickets get owners * Making sure 0.3.2.x is not just a dumping ground for "things we didn't get around to doing in 0.3.1.x." * Improving the accuracy of the "easy" keyword by applying it to more tickets and removing it from any that weren't so easy after all. * Looking for a way to get the "Tor: Unspecified" milestone under control. I'm likeliest to be around during 1230-1800 UTC and 2230-0000 UTC. best wishes, -- Nick

1 0

Clarifications on guard-spec.txt
by Roger Dingledine 19 May '17

19 May '17

Hi folks! I'm catching up on my proposals, and I really like guard-spec.txt. Nicely done! I made some fixes that I hope are straightforward: https://lists.torproject.org/pipermail/tor-commits/2017-May/122942.html https://lists.torproject.org/pipermail/tor-commits/2017-May/122948.html https://lists.torproject.org/pipermail/tor-commits/2017-May/122986.html And I have four remaining questions/topics that could use some feedback from the spec authors/implementors rather than just having me bust in and change things. --------------------------------------------------------------- A) We don't really say what we mean by "adding" a guard to an ordered list. In particular: > We add new members to {CONFIRMED_GUARDS} when we mark a circuit > built through a guard as "for user traffic." When we say "add", do we mean "append" here? > To compute primary guards, take the ordered intersection of > {CONFIRMED_GUARDS} and {FILTERED_GUARDS}, and take the first > {N_PRIMARY_GUARDS} elements. If there are fewer than > {N_PRIMARY_GUARDS} elements, add additional elements to > PRIMARY_GUARDS chosen _uniformly_ at random from > ({FILTERED_GUARDS} - {CONFIRMED_GUARDS}). Similarly, does "add" mean "append"? > Once an element has been added to {PRIMARY_GUARDS}, we do not remove it > until it is replaced by some element from {CONFIRMED_GUARDS}. Confirmed > elements always proceed unconfirmed ones in the {PRIMARY_GUARDS} list. This one looks like a bug as currently stated: by "proceed", do we mean "precede"? --------------------------------------------------------------- B) In Sec 4.10, whenever we get a new consensus, we: > For every guard in {SAMPLED_GUARDS}, we update {IS_LISTED} and > {FIRST_UNLISTED_AT}. In the old design, we also believed the Running flag in the new consensus, that is, we marked the guards as reachable again. It looks from sampled_guards_update_from_consensus() like we no longer do that. Is that old behavior considered a bug and we intentionally stopped, or did we not consider it? I am ok with "that was stupid behavior, so we stopped", but if we didn't know that we used to do it, maybe we should decide whether it is stupid behavior. :) --------------------------------------------------------------- C) In Sec A.4, in the state file we have > "bridge_addr" -- If the guard is a bridge, its configured > address and OR port. Optional. How does this play with bridges that have pluggable transports? In my "bridge obfs2 128.31.0.34:51715" line, the ORPort of the bridge is not listed. It looks from https://trac.torproject.org/projects/tor/ticket/21027 like we did some fixing here, but the spec didn't get an update? --------------------------------------------------------------- D) In Sec 4.8, when a circuit succeeds: > * If this circuit was <usable_if_no_better_guard>, it is now > <waiting_for retry>. You may not yet attach streams to it. > Then check whether the {last_time_on_internet} is more than > {INTERNET_LIKELY_DOWN_INTERVAL} seconds ago: > > * If it is, then mark all {PRIMARY_GUARDS} as "maybe" > reachable. > > * If it is not, update the list of waiting circuits. (See > [UPDATE_WAITING] below) [Where INTERNET_LIKELY_DOWN_INTERVAL has been picked as 10 minutes.] To make sure I understand this one, consider the following scenario: * We go offline, and our current circuits fail. * We try to make new circuits through each of our primary guards, failing for each (because we're offline) and marking them down. * Then we move to the remaining confirmed+usable ones, and mark those down too. * Then we work through the rest of USABLE_FILTERED_GUARDS, marking them down too. As we mark them down, USABLE_FILTERED_GUARDS shrinks, causing us to add new elements to SAMPLED_GUARDS to replenish USABLE_FILTERED_GUARDS. * After we've brought SAMPLED GUARDS to 60, we stop adding new ones. At this point, we are out of tries: > * Otherwise, if USABLE_FILTERED_GUARDS is empty, we have exhausted > all the sampled guards. In this case we proceed by marking all guards > as <maybe> reachable so that we can keep on sampling. Does this mean that we mark our *already-sampled* guards as reachable, thus making USABLE_FILTERED_GUARDS big again, and we loop through the above steps again, and we keep looping until we come back online? The above "so that we can keep on sampling" phrase confuses me, because it seems like there's no way that we would arrive at "USABLE_FILTERED_GUARDS is empty" without also having SAMPLED_GUARDS at its maximum size: > Whenever we are going to sample from {USABLE_FILTERED_GUARDS}, > and it contains fewer than {MIN_FILTERED_SAMPLE} elements, we > add new elements to {SAMPLED_GUARDS} until one of the following > is true: > > * {USABLE_FILTERED_GUARDS} is large enough, > OR > * {SAMPLED_GUARDS} is at its maximum size. So, perhaps we mean "so that we can keep on trying circuits"? Or, oh! Do we mean "sampling from USABLE_FILTERED_GUARDS", not "sampling from GUARDS"? Ok, proceeding with my scenario: let's further say that we're offline in such a way that we get quick failures for the connect attempts, so we burn through each connect attempt at one per second, meaning we blow through our CONFIRMED set within the first 10 minutes of going offline. Let's also say we come back online within those 10 minutes. A circuit (to some guard in SAMPLED_GUARDS) succeeds, and the circuit is now of type <waiting_for_better_guard>. Since last_time_on_internet isn't very long ago, and there aren't any other circuits open, the new circuit becomes <complete>, and we mark this new guard as CONFIRMED, and stick it on the end of the CONFIRMED set. We keep using the newly CONFIRMED guard (since it's the only one we think is reachable) for about a half hour, at which point the PRIMARY_GUARDS_RETRY_SCHED schedule makes us forgive our primary guards, and we switch back to our favorite primary guard. Do I have it right? Thanks! --Roger

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev