tor-dev

tor-dev@lists.torproject.org

4 participants
3591 discussions

Filtering of DA and bootstrap
by Fabio Pietrosanti (naif) 17 Jan '12

17 Jan '12

Hi all, in a network where the Directory Authority hard-coded in Tor code are filtered a Tor client cannot bootstrap. But as far as i understood there are (hundreds?) of Tor DA Mirror. If so, packaging the Tor clients periodically, bundling the latest consensus with the software, would provide higher chance for a client to bootstrap, finding an unfiltered Tor DA Mirror. Is this assumption true? Fabio

2 1

Size issues with Orbot statically linking OpenSSL
by Nathan Freitas 17 Jan '12

17 Jan '12

With the recent problems related to SSLv3 with versions of OpenSSL less than 1.0.0f, we have been investigating how to deal with this on Android for Orbot. Historically, we have used the version of OpenSSL provided by the Android device itself, which has ranged from 0.9.8 to 1.0.0e (the latest on ICS 4.0). We have now produced a build of OpenSSL 1.0.0f with the necessary Android patches, and statically linked this into the Tor binary we ship inside of Orbot. (We already do this for LibEvent, … [View More]

4 6

New paper by Goldberg, Stebila, and Ostaoglu with proposed circuit handshake
by Nick Mathewson 16 Jan '12

16 Jan '12

Crypto people who have been following threads about the circuit-establishment handshake will be interested in the new paper, "Anonymity and one-way authentication in key-exchange protocols", by Goldberg, Stebila, and Ostaoglu. Here's the version they updated today: http://www.cacr.math.uwaterloo.ca/techreports/2011/cacr2011-11.pdf If we're moving to an improved handshake, this might be a good candidate to consider. The protocol itself is on page 14. Some notes, written by a guy who knows … [View More]

8 29

Sanitizing IPv6 addresses in bridge descriptors
by Karsten Loesing 16 Jan '12

16 Jan '12

Hi Linus, Ian, list, now that we have bridges running on IPv6 addresses, some bridge operators enabled that feature on their public bridges and published descriptors to the bridge authority. I wonder how to sanitize these addresses for metrics data. (Currently, lines containing IPv6 addresses are simply discarded in the sanitized output.) Here's how we sanitize IPv4 addresses (from https://metrics.torproject.org/formats.html#bridgedesc): > Replace IP address with IP address hash: Of … [View More]

3 5

Transitioning to new crypto (again, but with substance)
by Watson Ladd 14 Jan '12

14 Jan '12

Dear all, After thinking hard about the issues involved with new cryptography in Tor I came to the following idea for a somewhat reasonable upgrade path for OP's and OR's that preserves everyone's privacy and security at all points (to the extent that this is possible: new connections are by new clients). The only issue is what actually goes out on the wire needs to be though through. First note that the connection between the identity used to ensure EXTEND cells go over canonical connections … [View More]and the keys actually presented by two OR's that have formed a connection can be pretty much arbitrary: it isn't necessary for the client to know what it is. So we could have each OR have an identity key that stays 1024 bit RSA for old ORs while newer ORs trust some snazzy new elliptic curve key, while using the same 1024 bits to form the identity. Note that if we use elliptic curves to secure the endpoints,(and don't mind incompatibility with old clients) the RSA key doesn't even need to be an RSA key. Also note that the Tor directory spec permits new types of lines. In particular we could have a curve-ident-key line and a curve-onionkey line each containing base-64 encoded keys, and a curve-sig line that's a signature of the rest of the entry, except for the RSA signature. The RSA signature would be as normal. To an old client this looks exactly like an old style directory entry. To a new client this looks like the elliptic curve key is the root of trust. This is OK: fiddling with an RSA signature doesn't let you fool a new client into thinking things about identities, because the identity is derived from the RSA key which is signed with the curve-ident-key. The onion-key is trusted by both the curve-ident-key and the RSA identity key. It is still possible to selectively invalidate one signature, but that signature is the RSA signature: the curve-ident-signature is also covered by the RSA signature. This would have the effect of ensuring that only new clients can connect to the OR: we could require that new clients still check the RSA signature to prevent this. Lastly comes the problem of EXTEND cells. All the OR before the new extension has to do is copy what is given to it without caring about the version. To signal versions we can just use length: 64 bytes vs. 128 bytes. Sadly this signals what version a client is, but an OR can guess anyway by how it was connected to if it lists both descriptors. One thing I have not taken on is the use of the new keys in the TLS negotiations.We could extend the CERTS and AUTH cells to include them as possible types, and this is possibly the best solution. I also haven't addressed the problem of UDP transport: TLS has issues where instead of sending another packet to be processed by the next router it resends a dropped packet, holding up the queue. I've probably missed a lot of issues here, but hopefully this moves the conversation forward. Sincerely, Watson Ladd [View Less]

2 2

Extending deadline for small features in 0.2.3.x by one week (to the 13th)
by Nick Mathewson 11 Jan '12

11 Jan '12

Hi, all! Previously, I had set the deadline for merging small features into 0.2.3.x as Jan 6. Due to work that had piled up or suddenly appeared in the new year, I wasn't able to get patches reviewed this week as much as I wanted, so I'm going to push the small-feature merge window back to Jan 13. This is the deadline for me to merge stuff, not for stuff to get submitted: I probably will not consider any patches where the first version is submitted after Monday, unless they are surprisingly … [View More]

3 5

A way to block chinese active probe
by Fabio Pietrosanti (naif) 09 Jan '12

09 Jan '12

Hi all, here's a second chinese-probe discrimination behavior that should allow to detect them, and block it. http://pastebin.com/RNcNDYcw Like the TCP SYN one, this blocking tricks is based on the fact that the OS & software they run on their server pool to make active-tor-probing have to be highly optimized, as they need to manage a huge amount of outbound connections. Does anyone would like to re-test this behaviour (also for Windows/OSX) and in case make a small patch for tor. Now … [View More]

1 0

Re: [tor-dev] Browser-based proxies for circumvention
by Kevin Dyer 08 Jan '12

08 Jan '12

>>> A sample session goes like this: >>> 1. The user starts a connector and a Tor client. The connector sends its >>> address to the facilitator, so that a proxy will know where to >>> connect to. (We call this step "rendezvous.") >>> 2. A flash proxy appears in a browser and asks the facilitator for an >>> address. >>> 3. The facilitator sends a remembered client address to the proxy. >>> 4. The proxy connects to … [View More]

2 1

Using a conf.d instead of a monolithic config file
by warms0x 07 Jan '12

07 Jan '12

I'm looking to start developing a Tor module for Puppet, one of the primary difficulties in making things work together "nicely" is the monolithic configuration file. Has there ever been plans or discussion about using a conf.d-style directory to store configuration file fragments? It would be useful to be able to drop fragments for hidden service configurations, etc into a directory to be picked up by the Tor daemon. If I provided the patches to make this possible, would it be useful? Cheers, -warms0x

2 1

DuckDuckGo, iOS and other stuff.
by caine tighe 03 Jan '12

03 Jan '12

tor-devers, So we are currently developing v2 of DDG applications and I'm personally interested in getting you guys involved. I think that there is serious value in ensuring Tor is an option for both Android and iOS. Currently we support Tor via Orbot on Android via the HTTP/S proxy method since the SOCKS method is known to have DNS leaks. Since the applications will be distributed via the respective stores, and specifically in the case of iOS, we cannot rely on the whole rooted / … [View More]

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev