Re: [tor-relays] descriptor-id calc tool?
On Thu, Mar 02, 2017 at 01:11:00PM +, nusenu wrote: > nusenu: > > Shouldn't the first 2 or 3 hex digits of your output (after converting > > them to hex) without time option and the actual intro point FPs match > > when run at roughly the same time? > > > > example for duckduckgo: > > > > ./get-intro-points.py 3g2upl4pq6kufc4m [1] > > 3g2upl4pq6kufc4m:56782537778BEFC5A48080B58BE01E814AF9B5D3 > > 3g2upl4pq6kufc4m:769DBA4C0C992FCEA080618833FD7BF5AC1F4F41 > > 3g2upl4pq6kufc4m:744B753C7F5E0C6BDD240EE5D879A36C650D2B00 > > > > > > go run descriptor-id-calc.go 3g2upl4pq6kufc4m > > replica #0: sv5uuknuqvjgquf4hu4m6tvcyuyiyvw7 > > -> hex: 957B4A29B485526850BC3D38CF4EA2C5308C56DF > > > > replica #1: crpc4lkarusgflm5nblslpopg5qpvw7i > > -> hex: 145E2E2D408D2462AD9D685725BDCF3760FADBE8 > > > > they start with 95.. and 14.. but the actual intro points start with > > 56.., 76.. and 74.. ? > > I probably misunderstood how the design works. > > The introduction points are not chosen by calculating the descriptor-id > and finding the 3 HSDirs next to it (by sorted fingerprint). tldr: HSDir != IntroPoint. Introduction points are chosen by random by an onion service and unknown in advance. What is known in advance is only the onion address. Descriptor ID determines which HSDirs are responsible for storing corresponding descriptor. List of the current IntroPoints are embedded into descriptor (that's the reason we have descriptor thing in the first place). -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] descriptor-id calc tool?
On Tue, Feb 28, 2017 at 02:09:00AM +, nusenu wrote: > >> Is there a tool out there that tells me which HSDir is/will probably be > >> responsible for a given onion address (and at what time)? > > > > There's no tool, unless you can reverse SHA1. > > (Or brute-force a set of popular onion addresses.) > > I probably was not very clear in my question. I'm not aiming for the > reverse path, just the normal calculation a tor client does given an > onion address but instead of just calculating the current descriptor-id, > print descriptor-ids for the future N days for onion address M (for the > pre-prop224 world). FYI https://gist.github.com/nogoegst/895dde228496e04f409fc6d160a5de5a $ go run onion-desc-advance.go -time 1488288001 yrcfcqhja2ide7yh prints descriptor IDs for the given time for replica #1 and #2. HTH -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] assign_to_cpuworker failed
Petrusko: >> Probably there is a memory leakage somewhere that makes everything fail >> and get process eventually killed by OS. > You're right Ivan, > my bad ! > Swap has grown quickly and has been full... Ok, it was a test with > another instance... so I'll kill this other instance :( There is nothing wrong at your side. You're probably experiencing the same issue as in ticket I've mentioned earlier. "a memory leakage somewhere" means that this "somewhere" is a place in tor code and probably triggered remotely. This definitely ought to be fixed since it may be a DoS vulnerability (process crash). So if you have some details on this issue please report them to the mentioned ticket. Thanks, -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] assign_to_cpuworker failed
Petrusko:
> Got it too,
> Sooo many lines in my log file.
> [...]
> Jan 22 06:37:37.000 [warn] assign_to_cpuworker failed. Ignoring.
> Jan 22 06:37:37.000 [warn] assign_to_cpuworker failed. Ignoring.
> Jan 22 06:37:37.000 [warn] circuit_mark_for_close_(): Bug: Duplicate
> call to circuit_mark_for_close at ../src/or/onion.c:238 (first at
> ../src/or/command.c:579) (on Tor 0.2.9.8 )
> Jan 22 06:37:37.000 [warn] circuit_mark_for_close_(): Bug: Duplicate
> call to circuit_mark_for_close at ../src/or/onion.c:238 (first at
> ../src/or/command.c:579) (on Tor 0.2.9.8 )
> Jan 22 06:37:37.000 [warn] circuit_mark_for_close_(): Bug: Duplicate
> call to circuit_mark_for_close at ../src/or/onion.c:238 (first at
> ../src/or/command.c:579) (on Tor 0.2.9.8 )
> [...]
>
> Then 1 Tor process has crashed and restarted himself...
> The other Tor instance has not been this log...
On what hardware/OS this relay is running? It seems to be due to hitting
resource limits. { src/or/onion.c:238 + "assign_to_cpuworker failed" error }
Though neither circuit_mark_for_close() should be called twice nor tor
process should crash.
Do you see other warnings? Messages about the reason of tor termination?
btw, there is a ticket for this very issue:
https://trac.torproject.org/projects/tor/ticket/20059
As long as it happens at the same lines of code I guess all this has
common reason. "assign_to_cpuworker" error is a kinda consequence of
hitting rate-limits (likely RAM usage).
Probably there is a memory leakage somewhere that makes everything fail
and get process eventually killed by OS.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Atlas: Short term bandwidth charts missing ?
mistral.re...@posteo.net: > Maybe it's just me - but I tried three different browsers and > usually can't see the short term usage charts on Atlas, i.e. 3-days > and 1 week bandwidth charts are usually just blank. Two random > examples where I can't see the charts (but there is data; monthly and > yearly charts showing up quite well): > Sorry, if this is my local issue but I just can't find the reason for > it... Not just you. This data is gone. Though Atlas still 'plots' it. See https://trac.torproject.org/projects/tor/ticket/19553. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] assign_to_cpuworker failed
diffusae: > What does this warning mean? > > "Jan 13 09:31:49.000 [warn] assign_to_cpuworker failed. Ignoring." > > Do I need to reduce the number of connection to the relay or could I > ignore this message? As long as you don't have any warning around this one (clock jump is unrelated), I can say that if you had info log level you would see `circ->p_chan gone. Failing circ.` I guess that's just means that this circ got broken at the wrong time. This happens, but if you have many circuits it should be more visible. That's ok. btw, what is the number of connections on your relay (maybe I'm wrong)? -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] "[warn] Cannot make an outgoing connection without a DirPort" under BSD
pa011: > I am running (FreeBSD 11.0-RELEASE-p2) Tor 0.2.8.11 > getting following warnings while Self-testing indicates that DirPort is > reachable from the outside? > > Can these warnings be ignored, while Tor is running properly afterwards ? > Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a > DirPort. This is probably a bug. Try to switch log level to "info" - tor should provide a more detailed backtrace saying something like "Address came from...". Please don't forget to sanitize log from irrelevant private data. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-r@elays] What's a "useful" relay?
Rana: > Those opinions were backed by technical arguments, here are a few: > > - the numerous small relays that change their IP addresses burden > the network unnecessarily with frequent re-publishing of their > descriptors - small relays that carry a small number of circuits > actually DESTROY anonymity since the small number of circuits going > through them makes it easier to de-anonymize traffic; - anonymity is > much better served by a few large relays since they carry a lot of > circuits simultaneously, and for this reason DirAuths try to saturate > them before they direct traffic to small relays - the connections > through small relays are quickly saturated, making using the internet > a horribly slow and unpleasant experience - Isis, the bridge db and > bridge authority operator, has asked Tor people who make decisions > NOT to recommend that people run bridges on their small residential > connections, because the need to re-distribute information about > changed IP addresses is a major hurdle towards bridge adoption > > Or as one DirAuth operator summarized it: "On balance, the very small > relays do not contribute enough resources compared to the associated > costs to be worthwhile." > > All of which is exactly the opposite of what you are saying and what > was also my intuitive opinion. Yes, I agree here that bad relays are actually bad. If relays change their address frequently they tear down all the circuits. Bad. Relays that are too slow and unable to catch up with most of the network flow (have small number of circuits) are bad. Poor connectivity is also bad. All these concerns are truly legit. Thanks for summarizing them! This hugely depends on your definition of "small". If one is running a relay from their refrigerator or dishwasher that connects to the Internet over GPRS - there is no good. One shouldn't do that. By the way this definition is moving target; what is called "small" today isn't what was called "small" 2 years ago. If you feel that your setup is intrinsically bad then it's better to make something else cool from it. > Or as one DirAuth operator summarized it: "On balance, the very > small relays do not contribute enough resources compared to the > associated costs to be worthwhile." This is true for "very small" relays, yes. > All of which is exactly the opposite of what you are saying and what > was also my intuitive opinion. It isn't totally opposite. I ran a relay quite a while ago on RPi (Pi1B+, FreeBSD) and it was pretty good at it. Not so fast as "full-blown" ones but still (something around 1.2MBps). After reasonable period of time it had ~7000 open connections. > So I am interested to know if there are solid, TECHNICALLY SOUND > opinions in favor of use of small relays. If running a small relay is > just for feeling good and displaying political support for privacy > rights, then I am outta here. I feel good already and I have other > means of expressing my political support. I do agree with you, one should know if their relay is actually useful and won't harm the network. Sorry if I sound not so technically. If you have modern ARM then you have NEON so ChaCha20 should be better that AES. That said slow relays may become a bit faster. Location diversity as self-hosting is another argument (recall tons of OVH VPS relays). Some best practices definitely would be awesome to have about running on common (embedded) hardware. Clear notification like "your Commodore 64 is to slow to be a good relay" would also be useful. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What's a "useful" relay?
Rana: > So - what's the metric for calling a middle relay "useful"? Is it the total > number of bytes that it relays daily? > https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400C > C6 is sending about 0.85 GB every 24 hours. Is it a "useful" relay? Sure it is! If there were only blazing fast relays it would decrease anonymity because these relays would be placed in some datacenters and operated by small amount of people (entities). Tor network needs all kinds of relays to be strong. Diversity is about platform, location, connectivity, etc, etc. If you think that your relay is underrated or has poor performance try to adjust your hardware/settings. Anyway almost every relay operator has this kind of "operator anxiety". Don't worry. ;) -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Is MaxMemInQueues recognized my tor? (was: A Question about aes-ni and the use of RAM.)
Patrice: > And my other question is, does tor recognize this option? >> MaxMemInQueues 7000 MByte It does, see the man page or the source code. > Because I see nothing in the logs. > I am not 100% sure but I think tor gave a feedback when I used this > option in the earlier versions. You will not see anything in logs until this value isn't good and was adjusted by tor. For details, see compute_real_max_mem_in_queues() function in /src/or/config.c. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Is AES-NI enabled in tor? (was: A Question about aes-ni and the use of RAM)
Please don't mix multiple questions into one thread. Patrice: > does anyone know if the aes-ni support of the motherboard is used by > default? (I saw nothing in the logs.) Tor does not implement crypto itself (mostly) and relies on a cryptolibrary (which is OpenSSL/LibreSSL/etc) instead. Thus you should check if AES-NI is enabled in your cryptolibrary. An excerpt from StackOverflow answer [1] about it: $ openssl speed -elapsed -evp aes-128-cbc $ OPENSSL_ia32cap="~0x202" openssl speed -elapsed -evp aes-128-cbc "Output of the first line should be significantly faster than the second." If there is no AES-NI enabled in "OpenSSL" these two should give similar results. N.B. AES-NI is not a feature of *motherboard* - it's CPU instructions (NI stands for "New Instructions"). [1] http://stackoverflow.com/questions/25284119/how-can-i-check-if-openssl-is-support-use-the-intel-aes-ni -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reset torrc file
Sec INT: > I upgraded all relays and exits to 0.2.9.8 but the torrc file was > then renamed on all of them when the daemon restarted automatically - > this meant the torrc file was then recreated as defaut losing all my > settings and all relays exits were not working - this hasnt happened > in all other upgrades to new versions but was pretty inconvenient > when having to go back and replace all torrc files - is this normal? This should not happen, actually*. It solely depends on your package manager (this is who rewrites your torrc files), so consult its documentation how to deal with config updates. Please drop a hint here if you succeeded! * This never happened to me on many systems as they have some sort of config management. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] TransPort: Convert iptables to pf
diffusae: > I looked into the wiki and also find some pf rules, which are routing > all the traffic though Tor, but this only works locally. You're likely talking about this wiki: https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#AnonymizingMiddlebox1 I've tried these rules for Anonymizing Middlebox (though on modern OpenBSD) quite some time ago and it seemed to work fine. These should not only work locally - it's for entire LAN. Are these ones you tried? -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] confusing error from "tor --verify-config"
Patrice: > After I run the following command I`ve got no output. > Is this correct then? I expected a few lines somehow. > > su -c "/etc/init.d/tor --verify-config" debian-tor My bad, shell for debian-tor is set to /bin/false and so it prevents any command from running. Setting shell should "fix" this: su debian-tor -s /bin/sh -c "tor --verify-config" -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] confusing error from "tor --verify-config"
Pascal Terjan: > I would suggest running tor --verify-config as debian-tor user > instead of root I would suggest not running tor as root . :) As root you can do: su debian-tor "tor --verify-config" -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] asymmetry in connections
teor: > It takes about a week for a TLS connection to close if there is > traffic on it, or a few minutes if there is no traffic: ... > Old TLS connections in tor are marked not to be used for new circuits > after 7 days in connection_or_group_set_badness_. Thanks for the clarification! Though I can't see how do these two intersect. What is a path for TLS to close in "a few minutes if there is no traffic"? If there is no traffic (no circuits) on top of a TLS connection it still can be used in next 7 days, right? -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Cloning a relay - duplicate fingerprint
anondroid: > Out of curiosity, I wonder how the Tor network handles this? Do the > directory authorities drop one (or both) from the consensus? There are no "two" relays for one fingerprint since relays are "addressed" (named) by their keys (fingerprints). If one starts another relay with the same key it will be treated by the authorities as new descriptor for this key, i.e. another one will be pushed out from consensus. From another side, only two relays (read keys) are allowed per one IP address. Thus other than two relays on given IP address will also be pushed out from consensus. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Cloning a relay - duplicate fingerprint
Patrick DERWAEL: > --> cloned VM, changed IP and mac adresses, OS hostname, Tor nickname and > restarted the Tor service > > Surprise: the fingerprint of the clone is identical to the one of the > source VM There is no surprise. You've probably just cloned DataDirectory which contains long-term relay private key and edited only torrc (nickname, ports, whatever). Try to clear DataDirectory out and restart tor - it should regenerate the keys. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] asymmetry in connections
Rana: > On one of my relays I have 389 inbound, 38 outbound connections and 15 > circuits > > What's the connection between these 3 numbers and why such asymmetry in > inbound and outbound? I don't think that there is something meaningful hidden here. This is because TCP+TLS connections are bidirectional and it doesn't matter who started them (sent SYN). As circuits are multiplexed over TLS, it doesn't always reveal bijective dependency between number of circuits and number of TLS connections. Except that there are constraints: o there is ~1 circuit (not client ones) per TLS connection if a relay joined the network recently o one has ~7100 [number of relays] TLS connections if their relay is up for quite some time o TLS connection is not going to terminate if no circuits left on it* [*] I may be wrong about it. It holds true from my experience. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961
pa011: > Could you give some explanation please on the difference between: > -lots of challenge ACKs received exactly the same number of chacks as number of sent RSTs (fixed kernel, sysctl workaround, ...) > -one challenge ACK received just one chack during this connection > -two challenge ACKs received one chack after first RST burst, another one after second burst > -vulnerable 100chacks/s rate limit was hit twice > -zero challenge RFC5961 is not supported > -multiple challenge ACKs anything else, i.e. there are some random number of chacks received but less than number of sent RSTs, probably rate-limited Current (these) definitions are here [1]. But they are a subject of change, because I'm trying to improve scanning method (separating counters for each of bursts). [1] https://github.com/nogoegst/grill/blob/master/verdict/verdict.go -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961
pa011: > What about relays not on the list at all? You mean that are not subscribed for tor-relays@? btw, it would be awesome to give away t-shirts or something for running diverse relays. > I would assume that not everybody of that 23 percent does know what > exactly to do, apart from better running on BSD - could you please > give detailed recommendation for beginners - your discussion seems on > a high level :-) Agree, I personally don't see any way to notify these operators about what to do (except clear instructions at blog.tpo or tor-relays@). With pleasure. There is an awesome The Tor BSD Diversity Project. The instructions for BSD beginners can be found here [1]. [1] https://torbsd.github.io/relay-guides.html -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Atlas - location of relay changed
Hi Duncan, Duncan Guthrie: > > On the IRC channel, I was reassured that this was not a bad thing, > that GeoIP is inaccurate, for example. > > However, I am interested in what might have caused the relay to > change location listing like this? Just to be clear, this 'location' is hardly an actual location. This locations are based solely on GeoIP data, that is know to be inaccurate [1]. There are lot of ASes(ASorgs) that can span across countries. It's getting even more complicated... But one shouldn't rely on this data as being 'location' of relay (see e.g. 'Liberian' relay [2]). [1] https://trac.torproject.org/projects/tor/ticket/19437 [2] https://atlas.torproject.org/#details/BC630CBBB518BE7E9F4E09712AB0269E9DC7D626 -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 0.2.8.11 bridge + hidden service, restart loop
Probably this? > **Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [warn] Directory > /var/lib/tor/hidden_service/ cannot be read: Permission denied** > **Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [warn] Failed to > parse/validate config: Failed to configure rendezvous options. See logs > for details.** -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961
dawuud: >>> Maybe you could also implement my Tor guard discovery >>> attack that uses this vulnerability? >> >> Why not. I just don't know what the attack is. Can you point me to it? > > On second thought I guess we better stick to writing scanners because if we > start writing exploits then eventually some script kitty will come along and > try to attack the Tor network with it; and even though my attack might not > work > it involves doing various things that utilize resources on the Tor network; > so it would be bad for the health of the Tor network. Right, I didn't mean that to be an exploit but just a PoC of this attack vector. But you're right, I haven't thought that it will put load on the network, and doing this is definitely not OK. It's not just some harmless TCP segments, there is much more than this (circuit rebuilding, etc). > It's traffic profile would be obviously identifiable for passive network > observers. > A nation state actor would have much better/faster results using other > well known publicly documented Tor guard discovery attacks. > Pretty sure they like to be sneaky when they deanonymize Tor circuits. I doesn't mean that nobody would like to use it. There are attackers that use botnets to do their nasty business and they don't care much about how visible it is. > I would however be very interested to hear back from tor-relay operators > if any of them have found Challenge ACK counter values higher than > a million... which would indicate some kind of funny business. It may not indicate this. Since I was able to scan whole Tor network in just 7 minutes (someone can use more than 127 concurrent scans and scan even faster), it may indicate that there is some aggressive scanning is going on by multiple parties. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961
dawuud: > The Golang rewrite of the scanner is cool! Thanks! > btw i'm surprised you wrote > https://github.com/nogoegst/rough/blob/master/tcp.go > instead of using https://github.com/google/gopacket You shouldn't; rough is just a convenient wrapper on top of TCP-ish stuff from gopacket (it makes TCP hacks simpler). > Maybe you could also implement my Tor guard discovery > attack that uses this vulnerability? Why not. I just don't know what the attack is. Can you point me to it? > I've been asked to write a proof of concept but I don't feel motivated to do > so. > Also, there are some doubts about weather this guard discovery attack would be > feasible on the real Tor network... though we could probably make it work in > a test network. > > Now that such a small percentage of the Tor network is vulnerable it's > probably safe/responsible > for me to post my theoretic Tor guard discovery attack, right? Hmm, I *don't* think that 1/4 of the network is actually small percentage... [I think we should somehow encourage vulnerable relays to update their kernels to lower affected percentage below ~10-15%.] Also, you saying "guard discovery attack based on pure off-path TCP attack" make this *slightly* obvious. So if someone actually got it, it's likely that they're already exploiting it. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961
teor: > For Tor client path selection, it is typically the vulnerable consensus > weight that matters, not the number of relays. > (Except in the case of HSDirs, where the hash ring is unweighted.) > > Have you looked at the vulnerable consensus weight proportion? Thanks for the tip! Laziness just took over me then. It turns out that vulnerable consensus weight fraction is 0.249602 or 25%. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961
Hi tor-relays@, Getting back with more results on this. I've implemented CVE-2016-5696 scanner in Go [1] and scanned the Tor network several times [2]. First results I've got using technique similar to David's (sending 500 RSTs in one burst), second ones are got via another method (send 111 RSTs in burst and then 111 RSTs 1 second later*). Current statistics: 32% of Linux relays are vulnerable. That is 23% of Tor network. -- Now some magic! Those 3 NetBSD relays from before still behave like they are vulnerable Linuxes (as they did in David's scanner, and two of mine): $ cat grill-tor-2016-12-09 | grep -v Linux | grep vulnerable 78.47.45.36:9001,3F5440FF003DFF8A12AA308CFD4087FBC157ABE0,Tor 0.2.8.9 on NetBSD,200,1.847787ms,1.834238ms,vulnerable 86.62.117.171:63500,508004552343E5374B6570C76E9239AA23310684,Tor 0.2.5.10 on NetBSD,200,1.999138ms,1.839057ms,vulnerable 139.18.25.35:9001,8806C3E6FA42B07113F3A1553DE70C0A30101201,Tor 0.2.8.9 on NetBSD,200,3.936046ms,3.777501ms,vulnerable Yes, nmap -O reports them to be NetBSD hosts. Actually I don't know what's going on here. Thoughts: * relays are behind vulnerable Linux middleboxes * RFC 5961 got implemented partly in NetBSD and it is actually vulnerable * ??? Okay then. I've brought up NetBSD 7.0.2 VM and scanned it locally. 0 challenge ACKs. Fine. I've put it under vulnerable Linux DNAT and it was 'kinda' vulnerable (some small random amount of ChACKs). Probably I did something wrong here. I headed out and scanned netbsd.org (self-hosted?) and it's vulnerable also. I've lurked through NetBSD's src code and found some bits of RFC5961. But I was unable to see anything offensive. If someone have some insight on this dark magic, that would be awesome! --- Thanks for bringing up the diversity issue in light of this CVE, Alex! Just to make everyone feel sad today: $ cat grill-tor-2016-12-09 | grep -v offline | grep Linux | wc -l 6435 $ cat grill-tor-2016-12-09 | grep -v offline | grep -v Linux | wc -l 550 Sadly, Linuxes are typical ~2σ of the network. ;( Please run more different (e.g. BSD) relays! [*] I think it should be more accurate. [1] https://github.com/nogoegst/grill [2] https://gist.github.com/nogoegst/d2de330b794b47158b4cfbed0987b4de -- Happy life without suffering, Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] network scan results for CVE-2016-5696 / rfc 5961
Hi David, Thanks for your work! dawuud: > I added the scan output to the repo, this includes the output csv file > and a list of vulnerable relays: > > https://github.com/david415/scan_tor_rfc5961/blob/master/scan_archive/nov17_2016/probe_out.csv > https://github.com/david415/scan_tor_rfc5961/blob/master/scan_archive/nov17_2016/vulnerable_tor_relays FYI, I produced results with platform strings and fingerprints based on this data [1]. It's pretty interesting that there are not only Linux relays are 'vulnerable' (90 < ChACKs < 220) in David's scan: % cat combined_results.csv | grep -v notvulnerable | grep -v Linux | grep Tor Tor 0.2.8.9 on NetBSD,3F5440FF003DFF8A12AA308CFD4087FBC157ABE0,78.47.45.36:9001,1.08132791519,500,142,vulnerable Tor 0.2.5.10 on NetBSD,508004552343E5374B6570C76E9239AA23310684,86.62.117.171:63500,1.00646305084,500,103,vulnerable Tor 0.2.8.9 on NetBSD,8806C3E6FA42B07113F3A1553DE70C0A30101201,139.18.25.35:9001,1.02995896339,500,113,vulnerable Tor 0.2.7.6 on FreeBSD,9C5461498004325F87C0685BDA5DA99AC5335314,62.194.144.196:9001,1.06730103493,500,211,vulnerable Tor 0.2.8.9 on FreeBSD,BCFE548EA3FF8A0B3610779C238350124A8ED6DE,207.172.209.83:9001,1.06568193436,500,214,vulnerable Tor 0.2.7.6 on NetBSD,F88C4D522EE7BD8B18B6C6418B8548E6E6BC74E9,195.43.138.226:9001,0.994502782822,500,100,vulnerable After I've rescanned these relays myself for several times, FreeBSD ones stopped being 'vulnereable' while NetBSD ones somehow still reproduce 'vulnerable' Linux status. I don't know why does this happen, maybe someone can scan these relays (or maybe all NetBSD ones due to TCP stack specifics) themselves and get different results. Anyway these are just curious false positives. [1] https://github.com/nogoegst/scan_tor_rfc5961/blob/master/scan_archive/nov17_2016/combined_results.csv -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] OpenWrt
Nima Fatemi: > I'm curious to see if there are any openwrt users here and if by any > chance any of you is running a relay or a bridge on it. There are not many OpenWRT relays since on majority of OpenWRT devices there is no enough memory (like 32-64MB RAM). Thus tor daemon runs out of memory while parsing consensus. See this discussion [1]. [1] https://lists.torproject.org/pipermail/tor-dev/2016-May/010973.html -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new warn message: Duplicate rendezvous cookie in ESTABLISH_RENDEZVOUS.
George Kadianakis: > I took a brief look at the relevant code, and I'm also not sure what's > causing the issue. More digging required. Toralf Förster: > Something I should worry about ? I think one should emphasize that relay operators shouldn't worry about it since it's client(s) [hopefully not little-t-tor one(s)] who send such cells. Thanks everybody reporting about this issue! -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new warn message: Duplicate rendezvous cookie in ESTABLISH_RENDEZVOUS.
pa011: > Several of those warnings here as well on Oct 06 - on exit as on non > exit - at different times Sure, type of relay doesn't matter here since a rendezvous client picks random relay to act as Rendezvous Point. Somehow there are clients who send more than one ESTABLISH_RENDEZVOUS cell to the same relay with the same cookie. Most likely it's behavior of some alternative/modified tor implementation (since it started recently and at almost the same time?). At least I can't find a way little-t-tor is able to do this. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new warn message: Duplicate rendezvous cookie in ESTABLISH_RENDEZVOUS.
Toralf Förster: > nope, from "git blame" the appropriate line is part of git commit > 339df5df and that commit is already part of tor-0.2.4.11-alpha : > > commit 339df5df085e2115c01881cf628abe5ed3fbd456 I'm unable find change to this line in 339df5df085e2115c01881cf628abe5ed3fbd456. AFAICT, this line was introduced long ago in 2004 by a981c4099af25e8e38ca1fbe4870d09c54d0d20b (SVN commit) and never touched since then. I think we should dig deeper why does this happen (started to happen?). Is it a bug in tor that produces such duplicate cookies or it's in some independent/modified implementation. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reasons to avoid being a guard?
jensm1: > I am curious about possible reasons, why one wouldn't want to become > guard. Are there any risks or disadvantages that come with the guard flag? Probably because having clients connecting directly to this relay is not OK. E.g. some hostile ISP/upstream so one may decide not to endanger users by running a Guard relay there. Just a guess. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Middle relay
Marcel Krzystek: > Add the following to your .torrc file: > > ExitPolicy reject *:* It's non-exit, not a "middle-only" relay. Jim probably doesn't want to become a Guard. I'm not aware of such option. btw, we've recently discussed in #19625 [1] possibility of setting "peering policy". If this would be implemented one can restrict connections only to relays in consensus (but not bridges?). [1] https://trac.torproject.org/projects/tor/ticket/19625 -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] list of bridges
Ivan Semenov: > Hello, can I get some vanilla bridges pls Go to https://bridges.torproject.org/ and select 'none' as Pluggable Transport. Voila. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to include files into torrc?
David Goulet: > Not possible to "include" sub torrc files unfortunately. One surely can do mkfifo + cat. P.S. Ha-ha. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] halp #2
Markus Koch: > I just complied TOR (hurray!) on a NON-ROOT server. TOR -> Tor (tor here, I guess). > 1. Issue: I cant find the torrc file. I found out that the rest of the > stuff is in ~./tor but no torrc at all. Where is it/should I put it? There is no torrc installed. You can create it wherever you want and pass the path to it via '-f' option to tor: $ ./src/or/tor -f /home/bunny/lol-torrc On most of the systems it can be found at /etc/tor/torrc. > 2. Issue: I only need the complied TOR executable and I can safely > delete all the other stuff? Yes, 'tor' binary should be enough. You can keep default torrc if you want. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] HALP!
Roger Dingledine: > On Tue, Aug 23, 2016 at 10:53:04PM +0200, Markus Koch wrote: >>> Do the log files give you any hints? >> >> I copied all the stuff, checked it and deleted the old vps. So I >> only see the new logfiles and they are fine, tor finds everything >> but with a different fingerprint. If the config would be in a >> different dir on the old vps, how comes that there are config files >> in both dirs? > > Well, a different fingerprint means a different identity key. Maybe > you didn't copy the identity key over correctly? Just an idea: how about having a built-in feature in tor to backup/restore? This feature could make an "archive" with correct metadata. Thus relay operator won't bother to collect all relevant files and correct permissions. Also it would make it much easier to move a relay to absolutely different system (E.g. tor user was `debian-tor` and it's `_tor` on the new one. Also different locations, like Windows/Darwin/BSDs/Linux). Asking for comments before creating a ticket since this idea can be inherently wrong. Thanks, -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] GeoIP
Hi Fred, Fred Rauch: > Where does Atlas get its GeoIP data from? Can this be corrected? It's > not a huge issue but it would be nice for the correct country to be > displayed. Atlas is a JavaScript application that gets all the data from Onionoo [1] backend. And Onionoo in its turn gets [2] data from MaxMind's GeoIP database [3]. Thus it's as reliable as MaxMind GeoIP is reliable. Agree, it's not godd. Current status of this (or closely related) issue you can track at #19437 [4]. [1] https://onionoo.torproject.org/ [2] https://gitweb.torproject.org/onionoo.git/tree/INSTALL#n44 [3] https://geolite.maxmind.com/download/geoip/database/GeoLite2-City-CSV.zip [4] https://trac.torproject.org/projects/tor/ticket/19437 -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guard Flag without stable Flag
George Kadianakis: > I think this is OK. > > The patch that required Stable flag for Guard flag only got merged recently: Just for the record, the corresponding ticket [1] and commit [2]. > I'm not sure how many dirauths run a Tor version with that patch. % git tag --contains c4208ef65f58836670dab286bad0289259582124 tor-0.2.9.1-alpha So it's just 'moria1'. [1] https://trac.torproject.org/projects/tor/ticket/18624 [2] https://gitweb.torproject.org/tor.git/commit/?id=c4208ef65f58836670dab286bad0289259582124 -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] interesting tor platform string or tor bug?
nusenu: > Yes, both relays on that IP (same ORPort), changed from "Tor 0.2.7.6 > on Windows 8" to that non-ASCII string (that is why I knew he is > probably running Windows 8). Can this be undefined behavior of GetVersionEx() on Windows 10? (I'm not able to verify this) GetVersionEx() has been deprecated since Win8.1 [1]: > With the release of Windows 8.1, the behavior of the GetVersionEx API > has changed in the value it will return for the operating system > version. The value returned by the GetVersionEx function now depends > on how the application is manifested. And tor still use it [2] on all Windows versions. Maybe this version of tor is built from source and manifested for Windows 10 (by auto)? I can't see anything related to 'manifestation' in Tor's build scripts for Windows, so I guess that official binaries are not manifested for Win8.1 or Win10 and detect Win10 as 6.2 (Win8). [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx [2] https://gitweb.torproject.org/tor.git/tree/src/common/compat.c#n2711 -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] interesting tor platform string or tor bug?
Tim Wilson-Brown - teor: > Hmm, I can't find an actual descriptor with these characters in it. The > latest descriptor I can find for this relay has a normal platform line: > https://collector.torproject.org/recent/relay-descriptors/server-descriptors/2016-07-06-06-05-14-server-descriptors > > Could this be a bug in Atlas? Nope, Onionoo returns the same platform line [1]. [1] https://onionoo.torproject.org/details?lookup=7A9A7CD200D288DD7D78542779DE16070BC8BFFD -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
simon:
> As I see it, removing via directory authority consensus is still the
> cleaner way, especially in a case of ~100 similar nodes.
>
> What came to my mind was something like a bugtracker for bad nodes.
Yes, but it's too crafty and should be done by hand. Doing so is error
prone/unstable/complicated/unscalable if there is no algorithms to seed
sybils out (like ones by Philipp Winter et. al.) in automatic manner
integrated into DirAuths.
> This way, all node operators can file suspicious nodes to be excluded,
> which achieves more than blacklisting on their tiny fraction of the network.
> It would introduce more transparency because relay operators can
> actually see someone is working on getting a dir auth consensus and get
> status updates; or at least there is a discussion why there won't be any
> blocking.
As any reporting this can open new attack surface for 'report sybils'
who report against some relays to influence path selection.
With peering policy, I see it like relay operator can decide that they
do accept ('accept' policy) only 'this-group-of-relays' and nothing
more. In case when a new group of sybils appears it cannot be used with
the relay. It raises diversity in the network. So if something goes
wrong with global or fenced 'part' of the network, it can have less
damage since not all relays are affected.
It's more like not all relays on the Tor network are exits. And it's for
a reason, e.g. one can get into a legal trouble for running an Exit node
in some countries but everything is fine without exiting there.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
s7r: > The path of a circuit is selected by the client (i.e. user). So, > each and every relay / bridge, in order to be considered a valid one, > should be able to extend a circuit when requested to any other > relay, otherwise everything gets broken. So does everything break if there are connectivity issues? E.g. route leakage, country "border" blocking policy, filtering, traffic throttling, bad cabling... Relay operators do not have control over their upstream providers and the Internet routing (in most cases). > Setting this locally at relay side, with no way for the applied > change to reach the Tor client (user) will have terrible usability > effects. Is it supposed to be this way? I guess the whole scheme should be more fault-tolerant for such common network issues. Actually I've never seen any noticeable disruptions when some of my bridges were down or faulty. > Trying to come up with a way so that Tor clients / users can learn > about such changes will over complicate everything with no benefits > and additional attack surface. > By design the only clean way to deal with bad relays is to exclude > them from consensus, a consensus that everyone uses, change applied > only at directory authorities side -- this is why we use the > consensus majority system which is well studied and understood as > opposite to other more decentralized solutions. Yeah, agreed. This issue has to be researched rigorously (see #19625) and we should stick with things that we know for sure. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
Andreas Krey: > That will cause issues for everyone that happens to select your > relay and the 'blocked' relays in a circuit - the connections will > just fail, and the user will wonder what happened, and why TBB > doesn't work. Sure, I made a notice that you shouldn't do it if you care about the users (may be it was vague): > [Note also, that it makes performance poorer compared to the case > when it's defined by policy] grarpamp: > If it's deemed that relay operators should have local policies such > as "ExcludePeerRelays", try discussing towards a ticket for that > instead. The introduction of peering policy definitely solves this issue in a transparent and harmless way. Filed a ticket #19625 [1] to move this discussion there. Sebastian Hahn: > This is a good way to get marked as a bad relay. Please never > actually do this on a relay in the Tor network. Curious, never knew that. Could you please send a link or whatever that explains how this marking/detection works? By the way, the only way to 'mark relay as bad' I know is to assign BadExit flag (but it's only for exits). Is there something else? [1] https://trac.torproject.org/projects/tor/ticket/19625 Thanks, -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
simon:
> If I understood the documentation correctly, as a node operator I can't
> blacklist hosts individually (unless I'm putting them into MyFamily,
> which I don't want to).
AFAIK, there is no option in tor itself to exclude relays from the routing.
But you're still able to restrict connections with these nodes using
plain blocking at your firewall. So circuits through these relays are
not able to be built anymore. [Note also, that it makes performance
poorer compared to the case when it's defined by policy].
In case of PF it looks like:
{{{
table { 0.0.0.0 }
block in quick on egress from to any
block out quick on egress from any to
}}}
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
