- tor-dev - lists.torproject.org

Names for your Onions: Onion addresses in SSL certificates
by heddha 06 Dec '17

06 Dec '17

Dear list, I wrote an addon as a PoC for idea 3 of the blogpost in [0]. The idea was to extend the Tor Browser by a means of reading out the C/O/S/L fields of the SSL certificate, and, if a website contains an onion address in one of those fields, to automatically redirect users to it. As the web-extensions API doesn't contain a means of reading out certificate information [1], I implemented it as an add-on. You can find it here: [2]. As stated in the blog post, all fields mentioned above could theoretically be filled with an onion address. Unfortunately, I found a large drawback: A certificate from Letsencrypt doesn't contain the C/S/O/L fields, as Letsencrypt performs a validation of required fields only, and the subject field isn't required. All unvalidated fields are by default not included in the certificate [3]. It is therefore not possible to include an onion address in the proposed fields using Letsencrypt; these are only filled when extended validation is performed (during which the correctness of the entries seems to be validated as well). Non-organisational suppliers of websites will therefore not be able to include their onion addresses in their normal certificate, which will most likely limit the amount of certificates containing onion addresses to a few larger organisations (if any). To make this idea actually usable for a large amount of people, one would have or to use another field, the content of which is neither checked nor deleted from a certificate, or introduce a new field =) Kind regards, heddha [0]: https://blog.torproject.org/cooking-onions-names-your-onions [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1322748 [2]: https://github.com/heddha/sslOnions [3]: https://community.letsencrypt.org/t/maintain-subject-records-country-etc-in…

1 0

Start contributing to Tor
by Aruna Maurya 04 Dec '17

04 Dec '17

I am new to the community and would like to contribute and help along. I did a complete read up on how the Tor browser works, but I would like to delve in more and get acquainted with the code base, so that I understand and learn a lot in the process. I already cloned and built the Tor(core) and TorBrowser from source for easy understanding and primarily as it would help me to reproduce bugs as I work on them. Any further guidance is appreciated. Thankyou for spending the time to read this through. -- Regards, Aruna Maurya, CSE,B.tech, Blog <https://themindreserves.wordpress.com/> | Medium <https://medium.com/@arunamaurya>

3 4

Running Tor with a 15MB memory limit
by Nathan Freitas 04 Dec '17

04 Dec '17

I am currently supporting the iCepa project, an effort to get Tor to run as a Network Extension VPN on iOS. https://github.com/iCepa/iCepa The good news is that, after a long time, we have the whole thing somewhat working. The bad news is that after browsing a few pages through Tor, the extension is shutdown due to going over the extremely tiny 15MB available heap. More on this at: https://forums.developer.apple.com/thread/73148 https://developer.apple.com/documentation/networkextension My question is, does anyone else have experience running Tor within some extreme memory limits? Any guidance on configuring torrc for this? Any thoughts on build flags or changes that might reduce memory usage? We have already identified that the new compression features available in recent versions of Tor consume more memory, and we may have to disable those for now, for instance. Thanks for any thoughts! +n

2 1

Privacy Pass
by bancfc＠openmailbox.org 29 Nov '17

29 Nov '17

Hi. Are there any plans to include Privacy Pass addon in Tor Browser by default? Privacy Pass is the result of some great work by Ian and his team at University of Waterloo to spare Tor users the torture of solving infinite captchas from Cloudflare.[0][1] [0] https://privacypass.github.io/team/ [1] https://blog.cloudflare.com/privacy-pass-the-math/

4 3

[release] [protocol] Onionoo 4.4-1.8.0
by iwakeh 28 Nov '17

28 Nov '17

Hi there! Onionoo's protocol was extended and has a minor version jump to 4.4. Download available at: https://dist.torproject.org/onionoo/4.4-1.8.0/ Main protocol changes (also summarized in [0]): The version field, which was introduced in 4.1, is now available for bridges, too. The "recommended_version" parameter is provided as an additional search parameter. Details can be found in [1a], [1b], and [2]. The changes are already deployed on all onionoo.torproject.org instances and the update included an upgrade of the geoip data used in Onionoo. Reminder: a major *upcoming version* jump 5.0 lies ahead. Take note of the field "next_major_version_scheduled":"2017-12-17" in documents. Please direct comments and questions to the metrics-team mailing list [3]. Cheers, iwakeh [0] https://metrics.torproject.org/onionoo.html#versions_4_4 [1a] https://metrics.torproject.org/onionoo.html#details_relay_recommended_versi… [1b] https://metrics.torproject.org/onionoo.html#details_bridge_recommended_vers… [2] hhttps://metrics.torproject.org/onionoo.html#parameters_search [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Tor and DNS
by N6Ghost 25 Nov '17

25 Nov '17

hi all, saw an open item in the tor projects, about dns and other resource record types. this got me thinking about just trying to understand Tor and DNS. for what I gather so far, is Tor and dns is only about "a" records and quad records "aaaa", thats pretty much it. i think PTR also but just whats need for hostname lookup. I am assuming this means tor clients, and tor browsers but have yet to validate that. any other info on this would be helpful. still trying to dig around and find where the data may be. -N6Ghost

1 0

rendezvous on non-OR circuit with purpose Acting as rendevous
by Ian Goldberg 23 Nov '17

23 Nov '17

I just restarted my node, and saw this in the log: Nov 23 14:07:21.000 [warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending) What does this mean? I'm a little worried someone out there is playing games with the protocol...

2 1

Proposal: Move IPv6 ORPorts to the Microdesc Consensus
by teor 21 Nov '17

21 Nov '17

Hi all, We would like to move IPv6 ORPorts from microdescriptors to the microdesc consensus. This makes it easier for IPv6 clients to bootstrap and choose reachable guards. The proposal is inlined below, it is also available with the corresponding dir-spec updates in my torspec branch bug23826-23828 on GitHub: https://github.com/teor2345/torspec.git The tor code that implements these new consensus methods is in my tor branch on bug23826-23828 on GitHub: https://github.com/teor2345/tor.git The parent ticket for these related changes is #20916. The code changes are being tracked in #23826 and #23828, and the spec changes and proposal in #23898: https://trac.torproject.org/projects/tor/ticket/20916 If we've spoken about this, and I've left you out as an author, please let me know! Here is the proposal text: Filename: xxx-ipv6-in-micro-consensus.txt Title: Move IPv6 ORPorts from microdescriptors to the microdesc consensus Author: Tim Wilson-Brown (teor) Created: 18-Oct-2017 Status: Open Target: 0.3.3.x 1. Summary Moving IPv6 ORPorts from microdescs to the microdesc consensus will make it easier for IPv6 clients to bootstrap and select reachable guards. Since consensus method 14, authorities have voted for IPv6 address/port pairs (ORPorts) in "a" lines. Unreachable IPv6 ORPorts are dropped from the full consensus. But for clients that use microdescriptors (the default), IPv6 ORPorts are placed in microdescriptors. So these clients can only tell if an IPv6 ORPort is unreachable when a majority of voting authorities mark the relay as not Running. This proposal puts reachable relay IPv6 ORPorts in an "a" line in the microdesc consensus. This allows clients to discover unreachable IPv6 ORPorts, even if a minority of voting authorities set AuthDirHasIPv6Connectivity 1. 2. Proposal We add two new consensus methods, here represented as M and N (M < N), to be allocated when this proposal's implementation is merged. These consensus methods move IPv6 ORPorts from microdescs to the microdesc consensus. We use two different methods because this allows us to modify client code based on each method. Also, if a bug is discovered in one of the methods, authorities can be patched to stop voting for it, and then we can implement a fix in a later method. 2.1. Add Reachable IPv6 ORPorts to the Microdesc Consensus We specify that microdescriptor consensuses created with methods M or later contain reachable IPv6 ORPorts. 2.2. Remove IPv6 ORPorts from Microdescriptors We specify that microdescriptors created with methods N or later do not contain any IPv6 ORPorts. 3. Retaining Existing Behaviour The following existing behaviour will be retained: 3.1. Authority IPv6 Reachability Only authorities configured with AuthDirHasIPv6Connectivity 1 will test IPv6 ORPort reachability, and vote for IPv6 ORPorts. This means that: * if no voting authorities set AuthDirHasIPv6Connectivity 1, there will be no IPv6 ORPorts in the consensus, * if a minority of voting authorities set AuthDirHasIPv6Connectivity 1, unreachable IPv6 ORPort lines will be dropped from the consensus, but the relay will still be listed as Running, * if a majority of voting authorities set AuthDirHasIPv6Connectivity 1, relays with unreachable IPv6 ORPorts will be dropped from the consensus. We will document this behaviour in the tor manual page, see #23870. 3.2. Full Consensus IPv6 ORPorts The full consensus will continue to contain reachable IPv6 ORPorts. 3.3. Clients that use Full Descriptors Tor clients that use full descriptors already ignore unreachable IPv6 ORPorts, and have done so since at least 0.2.8.x. 4. Impact and Related Changes 4.1. Directory Authority Configuration We will work to get a super-majority (75%) of authorities checking relay IPv6 reachability, to avoid Running-flag flapping. To do this, authorities need to get IPv6 connectivity, and set AuthDirHasIPv6Connectivity 1. 4.2. Relays and Bridges Tor relays and bridges do not currently use IPv6 ORPorts from the consensus. We expect that 2/3 of authorities will be voting for consensus method N before future Tor relay or bridge versions use IPv6 ORPorts from the consensus. 4.3. Clients 4.3.1. Legacy Clients 4.3.1.1. IPv6 ORPort Circuits Tor clients on versions 0.2.8.x to 0.3.2.x check directory documents for ORPorts in the following order: * descriptors (routerinfo, available if using bridges or full descriptors) * consensus (routerstatus) * microdescriptors (IPv6 ORPorts only) Their behaviour will be identical to the current behaviour for consensus methods M and earlier. When consensus method N is used, they will ignore unreachable IPv6 ORPorts without any code changes. 4.3.1.2. IPv6 ORPort Bootstrap Tor clients on versions 0.2.8.x and 0.2.9.x are currently unable to bootstrap over IPv6 only connections when using microdescriptors. This happens because the microdesc consensus does not contain IPv6 ORPorts. When consensus method M is used, they will be able to bootstrap over IPv6 only connections using microdescriptors, without any code changes. 4.3.2. Future Clients 4.3.2.1. Ignoring IPv6 ORPorts in Microdescs Tor clients on versions 0.3.3.x and later will ignore unreachable IPv6 ORPorts once consensus method M or later is in use. (See #23827.) 4.3.2.2. IPv6 ORPort Bootstrap If a bootstrapping IPv6-only client has a consensus made with method M or later, it should download microdescriptors from one of the IPv6 ORPorts in that consensus. Previously, IPv6-only clients would use fallback directory mirrors to download microdescs, because there were no IPv6 ORPorts in the microdesc consensus. (See #23827.) 4.3.2.3. Ignoring Addresses in Unused Directory Documents If a client doesn't use a particular directory document type for a node, it should ignore any addresses in that document type. (See #23975.) 5. Data Size This change removes 2-50 bytes from the microdescriptors of relays that have an IPv6 ORPort, and adds them to reachable IPv6 relays' microdesc consensus entries. As of October 2017, 600 relays (9%) have IPv6 ORPorts in the full consensus. Their "a" lines take up 19 KB, or 33 bytes each on average. The microdesc consensus is 1981 KB, so this represents about 1% of its uncompressed size. Most tor clients are already running 0.3.1.7, which implements consensus diffs. We expect that most directory mirrors will also implement consensus diffs by the time 2/3 of authorities are voting for consensus method M. So we expect that this change will have a minimal impact, which is made even smaller by compression and consensus diffs. 6. External Impacts We don't expect this change to impact Onionoo and similar projects, because they typically use the full consensus. Metrics doesn't currently graph IPv6 usage in Tor, but would like to in future. -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------

3 4

Re: [tor-dev] GAEuploader now supports Windows
by Katherine Li 21 Nov '17

21 Nov '17

Hello Tor-Dev Community, GAE(Google App Engine) uploader now supports Windows, in addition to Mac and Linux. GAEuploader automates the process of uploading the meek code to App Engine. If you already have a Google account, it's pretty easy: the program will open a browser so you can authenticate and accept the App Engine terms of service, then upload the code under a domain name you choose. At the end, GAEuploader prints out a bridge line to paste into Tor Browser. The difference between this and the old meek-google is that the App Engine code you upload is just for you, not shared with anyone else. I would really appreciate user testing on GAEuploader. You can download it at: https://github.com/katherinelitor/GAEuploader/releases README: https://github.com/katherinelitor/GAEuploader Tor wiki page, containing step-by-step screenshots of how to use: https://trac.torproject.org/projects/tor/wiki/doc/GAEuploader If you have any questions, feedback or bug reports, please email me at katherineli.tor(a)gmail.com. I will respond promptly. Best, Katherine Li On Sun, Jan 22, 2017 at 3:53 PM, Katherine Li <katherineli.tor(a)gmail.com> wrote: > Hello Tor-Dev Community, > > GAE(Google App Engine) uploader has just released v1.0-beta. GAEuploader > enables clients to set up their own private meek-google in one easy step: > just run it and paste the bridge line into Tor Browser. > > Background information: Meek > <https://trac.torproject.org/projects/tor/wiki/doc/meek#Overview> is > pluggable transport that uses domain fronting. Meek-google got suspended > <https://lists.torproject.org/pipermail/tor-talk/2016-June/041699.html>, > but clients can set up their own Google App Engine app and configure their > Tor Browser accordingly. However, the process of creating and deploying the > Google App Engine can be confusing. GAEuploader significantly simplifies > this process for clients. > > I would really appreciate user testing on GAEuploader. You can download it > at: https://github.com/katherinelitor/GAEuploader/releases > README: https://github.com/katherinelitor/GAEuploader > Tor wiki page, containing step-by-step screenshots of how to use: > https://trac.torproject.org/projects/tor/wiki/doc/GAEuploader > > *GAEuploader runs on Mac or Linux, but currently does not support Windows. > *GAEuploader uses the Google Cloud SDK > <https://cloud.google.com/sdk/docs/#linux>. If you are interested in how > GAEuploader works, the README contains the list of commands that were run. > > If you have any questions, feedback or bug reports, please email me at > katherineli.tor(a)gmail.com. I will respond promptly. > > Best, > Katherine Li >

1 0

[release] [protocol] Onionoo 4.3-1.7.1
by iwakeh 20 Nov '17

20 Nov '17

Hi there! Onionoo's protocol was extended and has a minor version jump to 4.3. In addition, this release *prepares* a major *upcoming version* jump 5.0. Take note of the field "next_major_version_scheduled":"2017-12-17" in documents. Download available at: https://dist.torproject.org/onionoo/4.3-1.7.1/ Protocol changes (also summarized in [0]): Added support for a new "host_name" parameter to filter by host name and a new "unreachable_or_addresses" field with declared but unreachable OR addresses [1]. The changes are already deployed on all onionoo.torproject.org instances. Please direct comments and questions to the metrics-team mailing list [2]. Cheers, iwakeh [0] https://metrics.torproject.org/onionoo.html#versions_4_3 [1] https://metrics.torproject.org/onionoo.html#details_relay_unreachable_or_ad… [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0