- tor-dev - lists.torproject.org

trac component for check.tpo?
by nusenu 26 Jan '18

26 Jan '18

what is the correct trac component to report that check.tpo is down? Webpages/Website? http://downforeveryoneorjustme.com/check.torproject.org -- https://mastodon.social/@nusenu twitter: @nusenu_

2 1

Re: [tor-dev] Marker branch for current tor release(s)
by teor 25 Jan '18

25 Jan '18

Hi, Tor branches are a question for tor-dev@, I am directing all responses there. Also, I fixed the top-post. > On Jan 5, 2018 00:48, "Andreas Krey" <a.krey(a)gmx.de> wrote: > > https://www.torproject.org/download/download.html.en in the source code 'tab' > states the current stable and alpha version of tor. > > Would it be possible to publish the current states as branches 'stable' and > 'alpha' (or 'testing', or 'unstable') in the git repo? What do you mean by "alpha" and "stable" ? When tor 0.3.2.9 is released next week, there will be no alpha version. When this happens, do you want master, or the latest stable? When there are multiple supported tor versions, which one should be stable? At the moment, we support 0.2.5 and 0.2.9 as long-term support, and 0.3.0 and 0.3.1 as regular releases. Should stable be 0.3.1 (and change to 0.3.2 next week)? Do you want a long-term support branch as well? Should it be 0.2.5 or 0.2.9? > That would help us tor-from-source builders to just fetch the repo, and > if the respective branch changes, to rebuild and redeploy. Looking for a > new release tag or screen-scraping said web page is a bit hairy, and feels > unnecessary. If you want something that's easier to scrape, and signed, check for new source releases at: https://dist.torproject.org/ We provide the latest Tor Browser version through a URL (which I can't remember right now). Maybe we could do the same thing with Tor. > On 5 Jan 2018, at 23:17, Chad MILLER <chad(a)cornsilk.net> wrote: > > I second this. > > There's a recommended-versions list in the consensus, but you have to already have Tor available and running to get it. No, you don't need Tor: $ curl http://197.231.221.211:9030/tor/status-vote/current/consensus-microdesc | grep server-versions | tr "," "\n" | tail -1 0.3.2.8-rc Or you can do this far more reliably in Python using stem: https://stem.torproject.org/ > Maybe also publish in a DNS TXT record or something? Is that secure? Can you sign a TXT record? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

4 7

Pluggable transports research
by Jodi Spacek 25 Jan '18

25 Jan '18

I'm a master's student at the University of British Columbia (Vancouver, Canada) where I'm primarily researching anonymous systems and censorship. I would be delighted to contribute to pluggable transports. Of particular interest is image and audio data stenography - is anything is in the works for this or is it outdated? My aim is to add this functionality while fully testing and evaluating it as part of my thesis project. I refer to the list of idea suggestions here: https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/ideas Any guidance is greatly appreciated. Thanks so much! Jodi p.s.: Please advise if this is not the correct mailing list. and perhaps belongs in tor-assistants. If so, I will inquire there once my access is (hopefully!) granted. -- www.jodispacek.com

5 5

tor failing to resolve some dns records
by blaze glory 23 Jan '18

23 Jan '18

3 2

WIP proposal for migration to TLS 1.3
by isis agora lovecruft 23 Jan '18

23 Jan '18

Hello, It's not done yet; it probably has errors; it definitely has omissions; it's still riddled with "XXX"s everywhere… but here's a work-in-progress draft proposal for migrating our link protocol(s) to use TLS 1.3: https://gitweb.torproject.org/user/isis/torspec.git/log/?h=tls13 It's not quite ready for a whole bunch of feedback yet, since I'm still reading through all the specs and writing the proposal. However, if you're super knowledgeable about TLS 1.3 and have opinions or ideas or see a mistake/misunderstanding somewhere, please feel free to share! Thanks! Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

1 0

No Control Socket when DisableNetwork 1
by iry 20 Jan '18

20 Jan '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor Developers, According to the Tor manual: https://www.torproject.org/docs/tor-manual-dev.html.en > DisableNetwork 0|1 When this option is set, we don’t listen for or > accept any connections other than controller connections, and we > close (and don’t reattempt) any outbound connections. Controllers > sometimes use this option to avoid using the network until Tor is > fully configured. (Default: 0) However, it seems when DisableNetwork is set to 1, /var/run/tor/control does not exist anymore making us cannot get a controller from socket file. (stem.control.Controller.from_socket_file() is affected in this case: https://stem.torproject.org/api/control.html#stem.control.Controller.fro m_socket_file) To reproduce this, I tested both Tor 0.3.1.9 and 0.3.2.9 on Debian Stretch: When DisableNetwork 0, run: systemctl --no-pager restart tor@default > user@host:~$ ls -l /var/run/tor/ total 1328 srw-rw---- 1 debian-tor > debian-tor 0 Jan 19 21:14 control -rw-r----- 1 debian-tor > debian-tor 32 Jan 19 21:14 control.authcookie -rw-r----- 1 > debian-tor debian-tor 1350116 Jan 19 21:14 log srw-rw-rw- 1 > debian-tor debian-tor 0 Jan 19 21:14 socks -rw-r--r-- 1 > debian-tor debian-tor 6 Jan 19 21:14 tor.pid When DisableNetwork 1, run: systemctl --no-pager restart tor@default > user@host:~$ ls -l /var/run/tor/ total 1244 -rw-r----- 1 debian-tor > debian-tor 32 Jan 19 21:00 control.authcookie -rw-r----- 1 > debian-tor debian-tor 1269005 Jan 19 21:00 log I searched on Tor-trac but did not find any similar report. Therefore, would you please tell me wether Tor intentionally behaves like this or this is a bug? (If this is a bug, I can definitely help to report it to Tor-trac.) Thank you so much! Best Regards, iry -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlpifX0ACgkQoUtNvG3N 1TwLsBAAn8W3H7VMwiR9UwnVJoXOZ0iWRLbF/JdtDUjXcG1/cQmK5aEHtbVCy4Jl VOWYKBJeHxZAmHlBC+ZR3E/vyDesatjPDIPvzUuwYN3T0COFpMyN71ipOjs1KqYP GFFgLFzClQHvnThe59TIEomVcdXIt9ebPU3QmVxnNhvB/KKggKOgTuYd/n8R0efe 0kAl5/8vZZv4/IiorRkF/ltQwmnOTR1V2H1OrOOHM/AyxLGfwGO9KffznRDX/BN4 AdM4MWpMh3+DKCKgJZpf3Gzwcn7d6DvL74YQVIhmwofoxEOCBD/f+iYeJKkoVPw7 Pd8YHkYvXqCRqHBFfTEe4BtZdcxK2k3FXbUcbKahFDYMtdotdzknf542f6+Bbt+p hmiuJT8bX/Kn2dBzonbqJuh2XEBA2y6OqqhJaVoJr5l6tWyghp18BsA2m6W4mg2H ApkUTv0YsQ8guXckfJP2LOhXxKWN0yncQ7bMzGZSfSwtqGwrDxFFWk2V8vXIrWWL X5pz3oObvQB9eUJcKix2C29kJSGBry68Ts1x4MnL14CDw0WqNqAqe0O3IAiCANjl CU+z9P129eb/pdYXW/OTFnVyWhQBXNvCRHTZB7Yvym+dN4B6MD3uOkH9THf9BaCF yVCOK1c04/sfqADnpE3Rhkr98iix3N2gbdOod/10T+GyG4OBh64= =Oh0M -----END PGP SIGNATURE-----

3 3

(no subject)
by blaze glory 16 Jan '18

16 Jan '18

1 0

Error-Correcting Onions with Bech32
by nullius 12 Jan '18

12 Jan '18

# Synopsis The Bech32 standard for error-correcting base32 strings was developed explicitly for relative ease and reliability in human communication of pseudorandom bitstrings. I invite discussion of specifying Bech32 as an alternative means for representing RFC 7686 .onion domain names. Should the response hereto be positive, then I will offer a formal proposal. I have written and released a tool which automatically recognizes and encodes/decodes .onion addresses in Bech32. To complement whatever I here say, please get a hands-on feel for Bech32 .onions: https://github.com/nym-zone/bech32 Manpage (yes, a real manpage!): https://raw.githubusercontent.com/nym-zone/bech32/master/bech32.1.txt # Background: About Bech32 Bech32 is specified by the Bitcoin BIP 173 standard,[1] co-authored by Pieter Wuille and Greg Maxwell. According to Mr. Maxwell, “Bech32 is designed for human use and basically nothing else”; the underlying research and development process involved extensive testing with human users, analysis of NIST visual confusability data, and the integration of a BCH code with strong error correction and detection properties. [1] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki I refer to BIP 173 for further explanation of Bech32’s design properties, its rationales, and the limits of its error handling. A specific application of Bech32 is Bitcoin’s new address format for the future, which I call “Bravo Charlie Addresses” after the letters “bc” specified for Bitcoin addresses in the standard’s “human-readable part” (HRP). However, the standard was written to permit general use in other applications. Having in hand a standard explicitly designed to ease the pain which wetware suffers when it comes into contact with pseudorandom gibberish, the cypherpunk in me is overjoyed at the potentials. One is a concept which I call “PGP Descriptors”, which I am currently working to specify with a few extra features and nuances. And of course, I think of .onions! # Bech32 for .onion I hereby nominate “onion” as the logical HRP for RFC 7686 .onion special-use domain names. Here is Bech32 .onion by example, using my bech32 tool with its built-in .onion support to encode and decode the name for the Tor Project’s .onion equivalent of its “www” site: ``` $ bech32 -e expyuzz4wqqyqhjn.onion onion1yh0c5eeuksscs8fdyd8406 $ bech32 -d onion1yh0c5eeuksscs8fdyd8406 expyuzz4wqqyqhjn.onion ``` The string is longer, because it contains 6 base32 characters’ worth of error-correcting code. N.b. also, the foregoing should work just fine for v3 onions (formerly prop-224). Imagine the impact on users who have a practical need to transmit a .onion address by verbal communication, or via a handwritten note. Now they can get some help with errors, instead of wondering why they can’t connect to a nonexistent .onion site. The standard enjoins applications against autocorrecting Bitcoin addresses, so as to prevent even the slightest possibility of causing funds loss by being too “helpful”. But in applications where it would be safe to do so, Bech32 can indeed correct small errors (as well as reliably detecting much worse errors). I suggest that such automatic correction would be suitable for .onion addresses. Bech32 co-author Dr. Wuille (sipa) has published Javascript reference code, plus a Javascript error-correction demo, under an MIT license. Perhaps this may be easily adapted into Torbutton, for automagic decoding of Bech32 “onion1” to .onion domains in the Tor Browser address bar. The code is in the same repository whence I copied the Bech32 reference C code I use internally in my tool: https://github.com/sipa/bech32 # Conclusion—or, to be continued... An alternative representational format with error-correcting codes will make .onion addresses more human-friendly. I look forward to the day when “onion1” addresses can be passed by handwritten notes, vocalized with a radio alphabet, stuffed into QR codes, scrawled on parchments placed in bottles tossed to sea, rocketed into space, and then conveniently transformed with appropriate corrections into the DNS-style .onion format specified by RFC 7686. Here’s to the alternative Onion format of the future! -- nullius(a)nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested: 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE) “‘If you’re not doing anything wrong, you have nothing to hide.’ No! Because I do nothing wrong, I have nothing to show.” — nullius

6 15

New Fallback Directory File Format
by teor 12 Jan '18

12 Jan '18

Hi all, Some time in the next few weeks, the Tor fallback directory mirror file format will change. This affects stem and Relay Search, which parse this file. Change Description Here is a list of changes to the file format: * the "weight" line has been removed, and replaced with a Tor config default (#24679, #24681) * the comma that separates fallback C strings is now on its own line * a "nickname" comment has been added (#24600) * an optional "extrainfo" comment has been added (#22759) The added fields will be populated with placeholders until the list is rebuilt (#22271). This will hopefully happen some time in the next few weeks. Requesting More Extra Info Caches There are only a few fallbacks that cache extra-info documents. I checked 67, and only 4 cached extra-info documents. atagar, do you want me to ask some fallback operators to set DownloadExtraInfo 1? What number or proportion would you like? (We allow approximately 25% of fallbacks to go down before we start to rebuild the list. In the worst case, this can mean that ~40% are down at some point.) Example Entries A sample entry in the new format, using actual relay info: "5.9.110.236:9030 orport=9001 id=0756B7CD4DFC8182BE23143FAC0642F515182CEB" " ipv6=[2a01:4f8:162:51e2::2]:9001" /* nickname=rueckgrat */ /* extrainfo=1 */ , The current fallback file in the new format, with placeholders: https://github.com/teor2345/tor/blob/ticket22759_tree/src/or/fallback_dirs.… A small sample fallback file in the new format, with actual relay info: https://trac.torproject.org/projects/tor/attachment/ticket/22759/fallback_d… Please let me know if you would like any changes to the format. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

4 14

Agnostic Tools: Code Dev and Support For
by grarpamp 12 Jan '18

12 Jan '18

> I'm interested in helping you guys with Tor development. I don't really care > what I work on, except I do not support .onion websites (though I am willing > to be convinced otherwise) so I would prefer not to participate directly in > their development. I have plenty of experience with writing code Folks in convo before have covered some of these areas and more that one could surely find or think of... Philosophical... Why does someone want to support and develop for Tor, or any other overlay p2p anonymity network, or crypto, for that matter? When even a fix to the manpage could be read and used by onion users and operators, same for metrics, lists, or any other part of the ecosystem. Does one fear "bad" things, association, or support "good" things? Does freespeech, anonymity, privacy, human rights sound "good"? What is "bad"? Censorship? Theft, Dictatorships, Police States, whether one's own, that of the Enemy, or that of the Oppressed? Cryptocurrency, anonymity, free markets, privacy, messaging... "bad"? "Good" [only] when used to defeat "bad" things inside or outside of [mal]functional democracies that assert majority force over minorities who have forced no one? Ricochet, Signal, GPG... "bad"? New technology that forces change over old entrenched ways... "bad"? Are anonymous forums where professional therapists give pro bono counseling to even the most reviled, depraved, criminal, socially scarlet lettered and outcast... "bad"? Materials and talk of religion? Are datamining, traffic archiving, exploits, cleartext... "good"? Tor has exits... do people realize how much of both what they like to "support", and abhor, travels over those exits? The variety of traffic there is no different than onions. Should exits be unsupported? What about the internet, or printing presses, should those tools be unsupported? Are they "bad", get their makers looked askew? Onions, exits, internet, presses, hammers... all simply agnostic tools. Tools can be used to build great things, to defend, or to wield in bloody murder. And what of biases over certain agnostic tools instead of over the separate "good" or "bad" uses of them? Do other tool builders and users have to wonder if their tools are being compromised by those with such biases? What of when those with biases end up needing the tools themselves, what will be the tool quality, or their ability to do "good" with them? Have people taken the time to explore the onion space to find and participate in all the "good" things they like therein, to create and grow them, or even engage in counsel and advocacy against the "bad"? What tools would be needed to do that? Yes, people are free to work on what they like... including giving deep thought as to what they like and don't, and why, and how supporting agnostic tools can actually fit with that. Are not your pens tools? Who likes those? Who supports those? What if they didn't? Pens... write code. Tech, fun, politic... Amounting to consideration feature X may prevent or diminish a better archictecture on balance for some higher importance feature Y. That should be covered open devops as usual. Or if the *technology* or *code* of eg: eepsites onions, or other subsets of various projects are not in their interest or knowledge practice area. Ok. Or if the features provided by any overlay network or tool are deemed flawed, and the technical or political effort to get them fixed, or rearchitecture, or correctly advertised, or called out within as bunk, is too high, therein it may be better to abandon them and or speak out freely as such.

4 6

Volunteering for Tor
by Charles Hunt 12 Jan '18

12 Jan '18

After 15 years of desktop support, I am following my passion to be a Python3 programmer. I am still an amature programmer, but I aced the python fundamentals course from Coursera to flesh out my skills. I would like to continue developing my programming skills by volunteering for Tor. Do you have something I can help with? Thank you. Charles

3 3

Re: [tor-dev] A suggestion for differential private statistics gathering
by Eyal Ronen 11 Jan '18

11 Jan '18

Hi Tim, First of all thanks for your detailed and quick response. I am sorry for my delayed response as I am attending Real World Crypto (BTW if there are any devs here it will be nice to try and meet). I will try to answer your questions and remarks below. >Hi Eyal, > >Thank you for letting us know about your research. > >You've emailed an internal discussion list, so I'm going to direct all >responses to the public tor-dev@ list. That is the list where we discuss >changes to Tor. > >Please see my response below: > >> On 7 Jan 2018, at 20:31, Eyal Ronen <eyal.ronen(a)weizmann.ac.il> wrote: >> >> I am a PHD student, and have just published online a paper, that shows a protocol that I think might be relevant to the TOR network. >> The protocol allows a server to privately learn information from a client, and is resilient to a situation where a malicious adversary wants to temper with the statistics. >> The main use case in our paper is learning popular passwords, > >Are you aware of this password list? >(It has no privacy apart from hashing the passwords, because the >passwords are already publicly available in data breaches.) > > https://www.troyhunt.com/introducing-306-million-freely-downloadable-<https://www.troyhunt.com/introducing-306-million-freely-downloadable-pwned-…> pwned<https://www.troyhunt.com/introducing-306-million-freely-downloadable-pwned-…> -passwords/<https://www.troyhunt.com/introducing-306-million-freely-downloadable-pwned-…> One of the assumptions of our paper is that if we blacklist known vulnerable passwords, we will change the passwords distribution and new passwords will become "popular". We enable the server to continually learn the changing password distribution. Another example is that the previously popular password "superman" might be replaced today with the password "wonderwoman", and we want to be able to learn this kind of changes. > >> but we believe that it might also be usable for other cases in the TOR network. As we do not know the needs and challenges in the TOR network, we would greatly appreciate any feedback from the TOR metrics community. > >I would be interested in an explanation of the tradeoffs between the >16 and 32 bit versions of the protocol. In particular, we may not be >able to provide servers with 4 GB of RAM for the 32 bit protocol. > >What would we lose with a 16 bit version? Is a 24 bit version possible? Any bit number is possible , and without any impact on security. The number of bit is the size of the domain or histogram of items you want to measure. If you use a low number of bits, you can have collision between different measured values, that may change the statistics. For example, lets assume we want to find out popular sites in the TOR network. We encode the sites IP. If you use 32 bit version, you can measure each IP individually. Otherwise you use a truncated a hash of the IP address. Now when you find a heavy hitter, you know what possible IP contributed to this measurement. But you can't know which one or more IP addresses are the popular ones. However I believe that this might not be a problem. One of the main differences to other solutions is that we work in the "Local model" and do no require any "Tally Reporters" to protect the data or for answers to be aggregate on the relay servers. The only place that needs to store the whole histogram is the one server that aggregates all of the information. I think that it greatly reduce the communication and implementation overheads of the solution. I think that the main differences are the one above and our provable malicious resilient. There are other differences but I think that this is the most relevant one. If we don't care about malicious users or relays we can use the semi honest version, that takes have almost zero computation requirements, and can be done either by the user, or by the relay. If we want to use the malicious resilient, it is a bit more costly, and we need to think of the right way and place to incorporate it. If it sounds interesting I will like to find a possible use case that I can try and design the best tailored solution for you. And we can try to prove the security and complexity of the solution, and verify this with safety board. If needed I have a POC written in Python to be easily understandable, but I can easily implement it using TOR's cryptographic package of choice. I will also try to go over the current proposal on the other papers in more details. Thanks again, Eyal Ronen > >> The paper is titles "How to (not) share a password: Privacy preserving protocols for finding heavy hitters with adversarial behavior" and can be found at https://eprint.iacr.org/2018/003 >> >> The abstract is: >> "Bad choices of passwords were and are a pervasive problem. Most password alternatives (such as two-factor authentication) may increase cost and arguably hurt the usability of the system. This is of special significance for low cost IoT devices. >> >> Users choosing weak passwords do not only compromise themselves, but the whole eco system. For example, common and default passwords in IoT devices were exploited by hackers to create botnets and mount severe attacks on large Internet services, such as the Mirai botnet DDoS attack. >> >> We present a method to help protect the Internet from such large scale attacks. We enable a server to identify popular passwords (heavy hitters), and publish a list of over-popular passwords that must be avoided. This filter ensures that no single password can be used to comprise a large percentage of the users. The list is dynamic and can be changed as new users are added or when current users change their passwords. We apply maliciously secure two-party computation and differential privacy to protect the users' password privacy. Our solution does not require extra hardware or cost, and is transparent to the user. >> >> The construction is secure even against a malicious coalition of devices which tries to manipulate the protocol in order to hide the popularity of some password that the attacker is exploiting. We show a proof-of-concept implementation and analyze its performance. >> >> Our construction can also be used in any setting where one would desire to privately learn heavy hitters in the presence of an active malicious adversary. For example, learning the most popular sites accessed by the TOR network." > >Tor Proposals > >There is a current proposal to add privacy-preserving statistics to Tor >using a scheme that's based on PrivCount: > > https://gitweb.torproject.org/torspec.git/tree/proposals/288-<https://gitweb.torproject.org/torspec.git/tree/proposals/288-privcount-with…> privcount<https://gitweb.torproject.org/torspec.git/tree/proposals/288-privcount-with…> -with-shamir.txt<https://gitweb.torproject.org/torspec.git/tree/proposals/288-privcount-with…> > >PrivCount is limited to counters with integer increments, so we can't >easily find the most popular site (the mode), or calculate the median. > >We discussed the proposal on tor-dev@, and decided that we could add >more sophisticated statistics later. We would appreciate your feedback >on the proposal. In particular, please let us know if there is anything >we should change in the proposal to make it easier to extend with schemes >like yours in future. > >Here is the proposal thread: > > https://lists.torproject.org/<https://lists.torproject.org/pipermail/tor-dev/2017-December/012699.html>pipermail<https://lists.torproject.org/pipermail/tor-dev/2017-December/012699.html>/tor-dev/2017-December/012699.html<https://lists.torproject.org/pipermail/tor-dev/2017-December/012699.html> > > >Anyone is welcome to submit Tor proposals, the process is described here: > > https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt > > >Related Research > >There was a paper at CCS 2017 that sounds very similar to your scheme: > >Ellis Fenske, Akshaya Mani, Aaron Johnson, and Micah Sherr. Distributed >Measurement with Private Set-Union Cardinality. In ACM Conference on >Computer and Communications Security (CCS), November 2017. > >Source: http://safecounting.com/ > >Can you explain how your scheme differs from PSC? > > >There's a forthcoming paper at NDSS 2018 that measures a single onion >site's popularity with differential privacy using PrivCount: > >Inside Job: Applying Traffic Analysis to Measure Tor from Within >25th Symposium on Network and Distributed System Security (NDSS 2018) >Rob Jansen, Marc Juarez, Rafael Galvez, Tariq Elahi, and Claudia Diaz > >Source: https://onionpop.github.io/ > >But the measurement was limited to one site, because PrivCount can't >calculate the modal value from set of samples. So I can see the >advantages of a scheme like yours over PrivCount. > > >Your Own Research > >And finally, if you do want to do research on the public Tor network, I >would recommend contacting the Tor Research Safety Board for advice: > > https://research.torproject.org/safetyboard.html > >T > >-- >Tim Wilson-Brown (teor) Best regards, Eyal

1 0

Re: [tor-dev] Public Key Chaos
by thomas.hluchnik＠netcologne.de 11 Jan '18

11 Jan '18

Am Wednesday 10 January 2018 17:37:57 schrieb Azat Khuzhin: > Nick suggested me to upload my key to repo (github), to make people know > that at least I have admin rights to that repo. > > But now I remembered, that my github account has attached gpg key to it, > you can see it here: > https://github.com/libevent/libevent/releases/tag/release-2.1.8-stable > > Does this enough for your needs? No, not really. Let's assume, an evil 3rd party is redirecting my download (by DNS spoofing or that), using a fake web server certificate. This would enable the attacker to exchange the libevent package + the checksum files + signature file. This fake signing key could be uploaded to the key servers by them, pretending it were your personal key. If I would trust in that, the tor network would be in danger. TOR executables would rely on insecure shared libraries. The only way for establishing trust is: the signature must be created with a GPG key which was signed by other trustworthy persons. For example, Nick's key is signed by many people since many years. So I have no doubt that files which are signed with that key are really from Nick. If he signs your key, then I can trust in files, signed with your key. If you are going to sign more packages in the future, don't hesitate to collect further signatures from other trustworthy persons or organizations. Best Regards, Thomas Hluchnik

1 0

Block Global Active Adversary Cloudflare
by debug 11 Jan '18

11 Jan '18

Is there any specific reason why there is no comment from Tor-team for this issue? https://trac.torproject.org/projects/tor/ticket/24351

3 4

Tor dev help
by Beastr0 11 Jan '18

11 Jan '18

Hey guys, For the time being I would prefer to not have my real name attached to Tor so I hope you don't mind if I introduce myself as Beastro. I love Tor and its mission. I was wondering if you guys had any projects that I could help out with? I can write code in python, java, C and also have plenty of experience with plenty other languages. As a student, I don't have a ton of time, so I can only spend maybe an hour or two a day helping out. Let me know if there's anything I can do! Best, - Beastro Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 5

Why do DirAuths take that long to update a relay's version information?
by nusenu 11 Jan '18

11 Jan '18

Hi, the goal of this email is to avoid a false positive warning for relay operators on atlas but the root cause might be in core tor. background: I really liked when irl added the big red warning to atlas when a tor relay runs an outdated (aka not running a "recommended") tor version because it actually triggered operators to upgrade, an important step toward a more healthy network. The problem is: This big red banner on atlas has false-positives which confuses operators [0]. Originally this has been an onionoo bug which has been fixed in v1.8.0, but it happens again and Karsten had the feeling that tor dir auths do not update the version information of a relay after it upgraded (and uploaded a new descriptor). I looked into one example and can confirm what Karsten suggested [1]. Let me show you that example of FP 1283EBDEEC2B9D745F1E7FBE83407655B984FD66. Data has been provided by Karsten and is available here: [2]. That relay was running 0.3.0.10 and upgraded to 0.3.0.13 and uploaded his first descriptor with 0.3.0.13 on: 2018-01-09 10:14:00,server,,0.3.0.13 except for bastet dir auths did not care and still said this relay runs 0.3.0.10: 2018-01-09 11:00:00,consensus,,0.3.0.10 2018-01-09 11:00:00,vote,bastet,0.3.0.13 <<<< note 2018-01-09 11:00:00,vote,dannenberg,0.3.0.10 2018-01-09 11:00:00,vote,dizum,0.3.0.10 2018-01-09 11:00:00,vote,Faravahar,0.3.0.10 2018-01-09 11:00:00,vote,gabelmoo,0.3.0.10 2018-01-09 11:00:00,vote,longclaw,0.3.0.10 2018-01-09 11:00:00,vote,maatuska,0.3.0.10 2018-01-09 11:00:00,vote,moria1,0.3.0.10 2018-01-09 11:00:00,vote,tor26,0.3.0.10 2018-01-09 12:00:00,consensus,,0.3.0.10 2018-01-09 12:00:00,vote,bastet,0.3.0.13 <<<<<< 2018-01-09 12:00:00,vote,dannenberg,0.3.0.10 2018-01-09 12:00:00,vote,dizum,0.3.0.10 2018-01-09 12:00:00,vote,Faravahar,0.3.0.10 2018-01-09 12:00:00,vote,gabelmoo,0.3.0.10 2018-01-09 12:00:00,vote,longclaw,0.3.0.10 2018-01-09 12:00:00,vote,maatuska,0.3.0.10 2018-01-09 12:00:00,vote,moria1,0.3.0.10 2018-01-09 12:00:00,vote,tor26,0.3.0.10 even 6 hours later this is unchanged. Then the operator upgraded from 0.3.0.13 to 0.3.1.9 and uploaded his first descriptor: 2018-01-09 16:39:01,server,,0.3.1.9 this remained "unnoticed" by all dir auths until longclaw voted for the new version: 2018-01-09 23:00:00,consensus,,0.3.0.10 2018-01-09 23:00:00,vote,bastet,0.3.0.10 2018-01-09 23:00:00,vote,dannenberg,0.3.0.10 2018-01-09 23:00:00,vote,dizum,0.3.0.10 2018-01-09 23:00:00,vote,Faravahar,0.3.0.10 2018-01-09 23:00:00,vote,gabelmoo,0.3.0.10 2018-01-09 23:00:00,vote,longclaw,0.3.1.9 <<<<< 2018-01-09 23:00:00,vote,maatuska,0.3.0.10 2018-01-09 23:00:00,vote,moria1,0.3.0.10 2018-01-09 23:00:00,vote,tor26,0.3.0.10 On 2018-01-10 02:38:07 the relay uploaded a second descriptor with v0.3.1.9 and almost all dir auths agreed immediately: 2018-01-10 02:38:07,server,,0.3.1.9 2018-01-10 03:00:00,consensus,,0.3.1.9 2018-01-10 03:00:00,vote,bastet,0.3.0.10 2018-01-10 03:00:00,vote,dannenberg,0.3.1.9 2018-01-10 03:00:00,vote,dizum,0.3.1.9 2018-01-10 03:00:00,vote,Faravahar,0.3.1.9 2018-01-10 03:00:00,vote,gabelmoo,0.3.1.9 2018-01-10 03:00:00,vote,longclaw,0.3.1.9 2018-01-10 03:00:00,vote,maatuska,0.3.1.9 2018-01-10 03:00:00,vote,moria1,0.3.1.9 2018-01-10 03:00:00,vote,tor26,0.3.1.9 So it took the operator 17 hours to convince enough dir auths that he upgraded. I can see multiple reasons why this can make sense (as the tor version is actually not that relevant consensus data) but maybe it was not clear what the side effects of not updating that field are. While I believe there is still another onionoo issue, this should also be improved. Thoughts? [0] http://lists.nycbug.org/pipermail/tor-bsd/2018-January/000620.html [1] https://trac.torproject.org/projects/tor/ticket/22488#comment:11 [2] https://trac.torproject.org/projects/tor/attachment/ticket/22488/task-22488… -- https://mastodon.social/@nusenu twitter: @nusenu_

2 2

prop279 global wildcard '*' exploits
by nullius 10 Jan '18

10 Jan '18

At https://trac.torproject.org/projects/tor/ticket/24774#comment:5 , nickm stated: >I'm not sure that the sandboxing section is necessary. We should say >that _all_ plugins should only access the network over Tor, unless they >are using some comparably strong anonymity mechanism. [...] In reply https://trac.torproject.org/projects/tor/ticket/24774#comment:6 , I ask: >The proposal as written states under §3.2, specifically discussing >`'*'`: > >>Perhaps we trust the name plugin itself, but maybe the name system >>network could exploit this? > >What does this mean? Is there any specific information on what >potential exploits the spec authors have thought of? '''Would >requiring Tor-only connections prevent these potential exploits?''' I >should ask on `tor-dev`. Per the discussion in the current version of the spec (686aaf1), there is concern that a '*' plugin may try to resolve ordinary DNS names. But this separate, quoted statement assumes a trustworthy plugin, which I take to mean that it would not grab .com, etc. So, what was the concern behind that statement? (And are there any other potential exploits, which may or may not be prevented by requiring name resolution through Tor?) -- nullius(a)nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested: 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE) “‘If you’re not doing anything wrong, you have nothing to hide.’ No! Because I do nothing wrong, I have nothing to show.” — nullius

1 0

Public Key Chaos
by thomas.hluchnik＠netcologne.de 10 Jan '18

10 Jan '18

Hello all, I am just going to update my tor server, building packages from source. I do that not only for tor but also for libevent. So I downloaded the tarballs plus signature from libevent.org and that's what I found: $ gpg --verify libevent-2.0.22-stable.tar.gz.asc gpg: Signature made Mon Jan 5 16:16:20 2015 CET using RSA key ID 8D29319A gpg: Good signature from "Nick Mathewson <nickm(a)alum.mit.edu>" gpg: aka "Nick Mathewson <nickm(a)wangafu.net>" gpg: aka "Nick Mathewson <nickm(a)freehaven.net>" gpg: aka "[jpeg image of size 3369]" $ gpg --verify libevent-2.1.8-stable.tar.gz.asc gpg: Signature made Sun Jan 29 19:42:03 2017 CET using RSA key ID 8EF8686D gpg: Good signature from "Azat Khuzhin <a3at.mail(a)gmail.com>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 9E3A C83A 2797 4B84 D1B3 401D B860 8684 8EF8 686D $ gpg --list-sigs "Azat Khuzhin" pub 2048R/8EF8686D 2010-06-10 uid Azat Khuzhin <a3at.mail(a)gmail.com> sig 3 8EF8686D 2010-06-10 Azat Khuzhin <a3at.mail(a)gmail.com> sub 2048R/7A34F923 2010-06-10 sig 8EF8686D 2010-06-10 Azat Khuzhin <a3at.mail(a)gmail.com> While nickm(a)alum.mit.edu was signed by many, many people, I find no signature for "Azat Khuzhin <a3at.mail(a)gmail.com>" at all. How can I trust that key? How can I be sure that libevent 2.1.8 is a good package? Why has Azat Khuzhin public key no signature from Nick Mathewson or anyone else? I don't trust that package for now until I find it signed with the keys of at least Nick Mathewson and Niels Provos. Correct me if I a wrong. Best Regards, Thomas

1 0

Proposal 285: Directory documents should be standardized as UTF-8
by Nick Mathewson 10 Jan '18

10 Jan '18

Filename: 285-utf-8.txt Title: Directory documents should be standardized as UTF-8 Author: Nick Mathewson Created: 13 November 2017 Status: Open 1. Summary and motivation People frequently want to include non-ASCII text in their router descriptors. The Contact line is a favorite place to do this, but in principle the platform line would also be pretty logical. Unfortunately, there's no specified way to encode non-ASCII in our directory documents. Fortunately, almost everybody who does it, uses UTF-8 anyway. As we move towards Rust support in Tor, we gain another motivation for standarding on UTF-8, since Rust's native strings strongly prefer UTF-8. So, in this proposal, we describe a migration path to having all directory documents be fully UTF-8. 2. Proposal First, we should have Tor relays reject ContactInfo lines (and any other lines copied directly into router descriptors) that are not UTF-8. At the same time, we should have authorities reject any router descriptors or extrainfo documents that are not valid UTF-8. Simultaneously, we can have all Tor instances reject all non-directory-descriptor directory documents that are not UTF-8, since none should exist today. Finally, once the authorities have updated, we should have all Tor instances reject all directory documents that are not UTF-8. (We should not take this step until the authorities have upgraded, or else the behavior of updated and non-updated clients could be distinguished.) 2.1. Hidden service descriptors' encrypted bodies For the encrypted bodies of hidden service descriptors, we cannot reject them at the authority level, and so we need to take a slightly different approach to prevent client fingerprinting attacks. First, we should make Tor instances start warning about any hidden service descriptors whose bodies, post-decryption, contain non-utf-8 plaintext. At the same time, we add a consensus parameter to indicate that hidden service descriptors with non-utf-8 plantexts should be rejected entirely: "reject-encrypted-non-utf-8". If that parameter is set to 1, then hidden service clients will not only warn, but reject the descriptors. Once the vast majority of clients are running versions that support the "reject-encrypted-non-utf-8" parameter, that parameter can be set to 1.

5 6

Re: [tor-dev] [tor-project] Intent to Minimise Effort: Fallback Directory Mirrors
by teor 09 Jan '18

09 Jan '18

Hi all, I'd like to move this thread to the tor-dev list. I made a list of Core Tor tickets at the end of this email. Let's talk about them on tor-dev. Here's some background: Rebuilding the fallback list takes a lot of effort! So I'm picking up this tor-project thread while the latest fallback rebuild is fresh in my mind. The rebuild took a day or two of my time for regular changes. And another day or two for once-off changes. We made a few changes to streamline the process: * atagar and I wrote scripts that make it easier to generate fallback lines, and get operator contact details [0] * pastly, atagar and irl helped out with code reviews and list format changes, which should make the list easier to read and parse * pastly and nickm helped out with fallback list updates and backport Having this help meant that I had time to make the process better. Thanks! But there's still more we can do: > On 29 Aug 2017, at 11:12, teor <teor2345(a)gmail.com> wrote: > >> On 28 Aug 2017, at 18:15, Linus Nordberg <linus(a)torproject.org> wrote: >> >> teor <teor2345(a)gmail.com> wrote >> Sat, 26 Aug 2017 22:39:52 +1000: >> >>> So I can't see any reasons to keep running opt-ins. >> >> Are we listing non-exits? > > Yes. Non-exits and under-used exits are the best fallback directory > mirrors, because they are under less load. > >> I suppose those might see a radical change in >> their "IP reputation" when they end up on the blocklists after the next >> ransomware attack. Exits are already in the lists. > > Yes, there is a higher risk that a fallback will end up on one of these > lists. But all public Tor relays are at risk of ending up on a list like > this. Because of the higher risk, we will continue to ask relay operators to opt-in [1]. So we need to find people to help with this process every 6-12 months. And make it more efficient. >> On 28 Aug 2017, at 19:34, Silvia [Hiro] <hiro(a)torproject.org> wrote: >> >> On 26/08/17 15:44, nusenu wrote: >>>>> use ContactInfo >>>>> as a way to collect the intention of relay operators to opt-in/opt-out >>>>> of the fallback directory mirrors list. >>>> This is a good idea, *if* we still think an opt-in is necessary. >>> >>> Isn't that way to collect operator intentions also useful in opt-out >>> mode? (instead of continuing to use emails) Or how do you plan to >>> collect the opt-out info? >> >> Why are emails preferred over other methods? Another options would be >> wrapping a script that ops can run to create a cyberpunk trac ticket and >> opt-out. This is probably easier than merging emails. But maybe we do >> not want to handle this through trac. >> >> I'd be happy to help w/ that eventually, and the fallback script. > > This is a good idea. > > At the moment, I take emails sent to me or tor-relays, and turn them > into trac comments or trac tickets. If we put it directly on trac, > anyone could handle the ticket. The most time-consuming part of the rebuild is the opt-in process. Here's what we do at the moment: [2] 0. Send an email to tor-relays to ask operators to opt-in 1. Run a script to find fallbacks whose details have changed, and email tor-relays to ask operators if their details are permanent Here are the most time-consuming steps: 2a. Receive personal emails and emails to the list with fallback details 2b. Generate an updated fallback line for each relay [0] 2c. Update the whitelist And these steps are quick: 3. Run the update script to generate a new list 4. Write a changes file 5. Announce the new list 6. Backport the list to all supported Tor versions Here are some things I'd like to change: Just have relay fingerprints in the fallback whitelist [3] The fallback script checks relay details, but it can just rely on Onionoo to say when the address last changed. This removes step 1 and step 2b. Add a torrc option and descriptor line to opt-in as a FallbackDir [4] This is inspired by nusenu's "ContactInfo" idea, and Hiro's "bot" idea. Having a descriptor line and torrc option gets us a more reliable implementation, and it's easier for relay operators to use. And there's no need for an email bot or trac bot. This removes step 2a and step 2c, for tor versions with this feature. For tor versions without this feature, we can use the simpler fingerprint list. Make the hard-coded authorities into a separate include file with a standard format [5] We'll also change the fallback file format (again, sorry!) to make them consistent. This makes it easier for stem, metrics-lib, and other Tor implementations to use the same authorities and fallbacks. This makes step 5 easier (for libraries that use fallbacks). Let's discuss these changes on the tor-dev list! T [0]: https://gitweb.torproject.org/tor.git/tree/scripts/maint/generateFallbackDi… https://gitweb.torproject.org/tor.git/tree/scripts/maint/lookupFallbackDirC… [1]: https://trac.torproject.org/projects/tor/ticket/24789 [2]: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectory… [3]: https://trac.torproject.org/projects/tor/ticket/24838 [4]: https://trac.torproject.org/projects/tor/ticket/24839 [5]: https://trac.torproject.org/projects/tor/ticket/24818 -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------

2 2

Relay diversity master thesis
by Robin Descamps 07 Jan '18

07 Jan '18

Hello, I already sent this message to the metrics team, but they advice me to address it to the dev team, which seem to be more relevant. I realise this year a master thesis, in the Université catholique de Louvain in Belgium, about measuring the utility brought to the Tor network diversity by adding a new relay, according to its configuration. I added to this message my master thesis plan, as well as a poster that presents a summary of the key elements. May I ask you advices/feedback about this master thesis plan? Since I would like this project to bring a real contribution to the Tor development, I want to make sure that all the steps I will perform are useful and/or worth it. The master thesis plan: https://drive.google.com/open?id=1XEOSS29owavKJ_cJJAVaPiJe34Ez6XXx The poster: https://drive.google.com/open?id=1BlF2U-Kexyz6ihVSqvsVHv4PUsvXATc4 Thanks, Robin Descamps

3 2

Re: [tor-dev] A suggestion for differential private statistics gathering
by teor 07 Jan '18

07 Jan '18

Hi Eyal, Thank you for letting us know about your research. You've emailed an internal discussion list, so I'm going to direct all responses to the public tor-dev@ list. That is the list where we discuss changes to Tor. Please see my response below: > On 7 Jan 2018, at 20:31, Eyal Ronen <eyal.ronen(a)weizmann.ac.il> wrote: > > I am a PHD student, and have just published online a paper, that shows a protocol that I think might be relevant to the TOR network. > The protocol allows a server to privately learn information from a client, and is resilient to a situation where a malicious adversary wants to temper with the statistics. > The main use case in our paper is learning popular passwords, Are you aware of this password list? (It has no privacy apart from hashing the passwords, because the passwords are already publicly available in data breaches.) https://www.troyhunt.com/introducing-306-million-freely-downloadable-pwned-… > but we believe that it might also be usable for other cases in the TOR network. As we do not know the needs and challenges in the TOR network, we would greatly appreciate any feedback from the TOR metrics community. I would be interested in an explanation of the tradeoffs between the 16 and 32 bit versions of the protocol. In particular, we may not be able to provide servers with 4 GB of RAM for the 32 bit protocol. What would we lose with a 16 bit version? Is a 24 bit version possible? > The paper is titles "How to (not) share a password: Privacy preserving protocols for finding heavy hitters with adversarial behavior" and can be found at https://eprint.iacr.org/2018/003 > > The abstract is: > "Bad choices of passwords were and are a pervasive problem. Most password alternatives (such as two-factor authentication) may increase cost and arguably hurt the usability of the system. This is of special significance for low cost IoT devices. > > Users choosing weak passwords do not only compromise themselves, but the whole eco system. For example, common and default passwords in IoT devices were exploited by hackers to create botnets and mount severe attacks on large Internet services, such as the Mirai botnet DDoS attack. > > We present a method to help protect the Internet from such large scale attacks. We enable a server to identify popular passwords (heavy hitters), and publish a list of over-popular passwords that must be avoided. This filter ensures that no single password can be used to comprise a large percentage of the users. The list is dynamic and can be changed as new users are added or when current users change their passwords. We apply maliciously secure two-party computation and differential privacy to protect the users' password privacy. Our solution does not require extra hardware or cost, and is transparent to the user. > > The construction is secure even against a malicious coalition of devices which tries to manipulate the protocol in order to hide the popularity of some password that the attacker is exploiting. We show a proof-of-concept implementation and analyze its performance. > > Our construction can also be used in any setting where one would desire to privately learn heavy hitters in the presence of an active malicious adversary. For example, learning the most popular sites accessed by the TOR network." Tor Proposals There is a current proposal to add privacy-preserving statistics to Tor using a scheme that's based on PrivCount: https://gitweb.torproject.org/torspec.git/tree/proposals/288-privcount-with… PrivCount is limited to counters with integer increments, so we can't easily find the most popular site (the mode), or calculate the median. We discussed the proposal on tor-dev@, and decided that we could add more sophisticated statistics later. We would appreciate your feedback on the proposal. In particular, please let us know if there is anything we should change in the proposal to make it easier to extend with schemes like yours in future. Here is the proposal thread: https://lists.torproject.org/pipermail/tor-dev/2017-December/012699.html Anyone is welcome to submit Tor proposals, the process is described here: https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt Related Research There was a paper at CCS 2017 that sounds very similar to your scheme: Ellis Fenske, Akshaya Mani, Aaron Johnson, and Micah Sherr. Distributed Measurement with Private Set-Union Cardinality. In ACM Conference on Computer and Communications Security (CCS), November 2017. Source: http://safecounting.com/ Can you explain how your scheme differs from PSC? There's a forthcoming paper at NDSS 2018 that measures a single onion site's popularity with differential privacy using PrivCount: Inside Job: Applying Traffic Analysis to Measure Tor from Within 25th Symposium on Network and Distributed System Security (NDSS 2018) Rob Jansen, Marc Juarez, Rafael Galvez, Tariq Elahi, and Claudia Diaz Source: https://onionpop.github.io/ But the measurement was limited to one site, because PrivCount can't calculate the modal value from set of samples. So I can see the advantages of a scheme like yours over PrivCount. Your Own Research And finally, if you do want to do research on the public Tor network, I would recommend contacting the Tor Research Safety Board for advice: https://research.torproject.org/safetyboard.html T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0

Call for review of Tor Relay Guide (#24497)
by nusenu 05 Jan '18

05 Jan '18

Hi, since the instructions on the website on how to setup a Tor relay are lacking information and clear guidance we have been working on improving it. The current version lives in the wiki and it reached a point where it makes sense to get reviews. https://trac.torproject.org/projects/tor/wiki/TorRelayGuide If there are major changes you would like to see please discuss them on the ticket before proceeding in the wiki: https://trac.torproject.org/projects/tor/ticket/24497 looking forward to your feedback and reviews! thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

#24526: neeeds review: require ContactInfo+MyFamily for multi-relay operators
by nusenu 04 Jan '18

04 Jan '18

Hi, it would be great if someone could review this change so we can move forward on this topic: https://gitweb.torproject.org/nickm/tor.git/commit/?h=bug24526&id=fbb6f9a18… https://trac.torproject.org/projects/tor/ticket/24526#comment:7 thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 1

Re: [tor-dev] Did tor-wiki-changes ML break?
by Damian Johnson 03 Jan '18

03 Jan '18

Hi nusenu. Yup, a CenturyLink technician is coming in a few hours to restore my connection. Note to self: losing home internet connectivity sucks. Cheers! -Damian from a coffee shop On Jan 3, 2018 2:38 AM, "nusenu" <nusenu-lists(a)riseup.net> wrote: Hello Damian, Damian Johnson: > Hi nusenu. Yup, I was just thinking about that. CenturyLink did some > work on my apartment's connection yesterday that knocked it offline. > Probably just needs the router to be rebooted but I'm visiting with > family through new years so the r2e instance will be unavailable until > then. are you planing to bring this functionality back any time soon? thanks for considering it, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_ _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

2 1