- tor-dev - lists.torproject.org

User experience issue
by Adam Shostack 14 Nov '14

14 Nov '14

Hi, I just had the fun experience of trying to walk someone who's not very technical and not familiar with Tor through downloading and installing the TBB. One element which came out was she was confused by the relationship between Tor, the Tor Browser Bundle, and Vidalia, and became frustrated by that experience. ("What's this Vidalia thing? I thought we were installing Tor!") I'm unsure if it would be appropriate/useful to file a bug, and so would like advice on if/how to tackle this. Adam

2 2

Re: [tor-dev] Of CA-signed certs and .onion URIs
by Jeremy Rowley 14 Nov '14

14 Nov '14

Great summary Tom, >From my perspective, getting .onion reserved is a pretty high priority. Once reserved, we can really eliminate it as an internal name and get onion listed as part of the PSL. I'm happy to help with this part of the project if I can. >Syrup-tan had an idea on irc: Have a DV certificate sign a certificate >that is valid for the .onion URL, and display the URL of the DV >certificate. This doesn't eliminate phishing - I can register >facebok.com and then get that displayed. But doing bootstapping off >DNS and DV certificates is a fairly low bar in terms of the cost to a >.onion operator. (There are other concerns here, I'm not completely >comfortable with repurposing the EV indicator in this way. Asa on irc >had the good point that if we did this, maybe we'd want to change the >EV green to another color just to be a little bit different. Not that >I really expect users to notice that though...) This is similar to what I was thinking by proposing that CAs have both a non-onion and onion name in it. If you do that and both are validated as part of the same certificate order, you could give users an indicator that the non-onion name is related to the onion name in the certificate. >Allowing an organization to purchase an EV certificate from a CA, and >display the organization's name in the address bar, is another way - >albeit a very high bar in terms of cost to an onion operator. I'm hoping the cost won't be high - I'm interested in this solely as something that supports Tor and companies like Facebook who want to give users greater privacy. Like you, I'm not looking to make EV certs required for onion operators. Instead, I'd like to see them permitted under the industry standards for companies looking to prominently promote their onion services. The biggest penalty of requiring EV is that it locks out individuals - which is very bad. I've proposed EV for individuals several times on the forum. Probably time to bring it up again. >But there should be at least one more solution in >the short to long term (e.g. a petname approach). Unfortunately, if >the time between now and the 'long term' solution is too long, it >locks out everyone who can't get an EV cert - which is a legitimate >concern. Perhaps after there's a spec Tor likes, some large >organization concerned about preventing phishing could throw some >engineering time at the problem. Jeremy

1 0

OONI weekly dev meeting reminder
by Arturo Filastò 13 Nov '14

13 Nov '14

Hello Oonitarians, This is reminder that today (Thursday 6th of November 2014) there will be the weekly ooni dev meeting in #ooni on irc.oftc.net. The time will be: 18:00 UTC 19:00 CET 13:00 EST 12:00 CST 10:00:00 PST You are all invited to attend! ~ Arturo

1 1

Defending against guard discovery attacks by pinning middle nodes
by George Kadianakis 12 Nov '14

12 Nov '14

Hey Nick, this mail is about the schemes we were discussing during the dev meeting on how to protect HSes against guard discovery attacks (#9001). I think we have some ideas on how to offer better protection against such attacks, mainly by keeping our middle nodes more static than we do currently. For example, we could keep our middle nodes for 3-4 days instead of choosing new ones for every circuit. As Roger has suggested, maybe we don't even need to write the static middle nodes on the state file, just use new ones if Tor has restarted. Keeping middle nodes around for longer will make those attacks much slower (it restricts them to one attack attempt every 3-4 days), but are there any serious negative implications? For example, if you were unlucky and you picked an evil middle node, and you keep it for 3-4 days, that middle node will always see your traffic coming through your guard (assuming a single guard per client). If we assume you use a non-popular guard node (with only a few clients using it), the middle guard might be able to think "Ah, the circuit that comes from that guard node is always user X" making your circuits a bit linkable from the PoV of your middle node. What other attacks should we be wary about? Maybe partitioning attacks based on client behavior? And how should we move this forward if we decide it's worth it? Should we start writing a Tor proposal? Thanks!

8 26

Gap between advertised and utilized bandwidth
by Karsten Loesing 12 Nov '14

12 Nov '14

Hi George, I found this in my IRC backlog from November 7, 2014: 20:34 #tor-dev: < asn> karsten: how should one read these graphs https://metrics.torproject.org/bandwidth.html#bandwidth-flags ? 20:34 #tor-dev: < asn> karsten: can the gap between two lines be interpreted as available (unused) bw? 20:35 #tor-dev: < asn> karsten: so the gap between the yellow lines is the available guard bw? 20:35 #tor-dev: < asn> karsten: but there is not that much available exit bw, right? so it's not entirely accurate. These are all fine questions. First of all, the gap between two lines is *supposed* to be interpreted as available (unused) bandwidth. Advertised bandwidth is the number of bytes that all relay together were willing and capable to handle. (It's the minimum of the three bandwidth numbers contained in server descriptors.) Bandwidth history is the number of bytes that all relays together actually handled. (It's the sum of byte histories contained in extra-info descriptors.) So, the difference of the two should be the number of bytes that was left unused, in theory. However, I can't say how accurate this comparison is. If I had the time to investigate, I'd start by downloading the latest descriptor archives from CollecTor and comparing advertised bandwidths and bandwidth histories per relay. If you or somebody else wants to do that I might be able to give them a hand. All the best, Karsten

2 1

tor packet handling
by Mohiuddin Ebna Kawsar 12 Nov '14

12 Nov '14

Hi, I want to develop extension(intrusion detection) for tor. for that i have to extract TCP and IP header from packet. I need to know where and how tor handle packet(TCP/IP). is it in buffer.c / connection.c ? Regards Kawsar

2 1

Re: [tor-dev] Pluggable-transport implementations of your website fingerprinting defenses
by David Fifield 10 Nov '14

10 Nov '14

On Sun, Nov 09, 2014 at 08:23:33PM -0500, Xiang Cai wrote: > I started to work on csbuflo code a long time ago, and I wasn’t using any > version control software back then, so I don’t have file commit history either… > Sorry about that. > > However, I only modified several core files based on openssh-5.9p1 source code: > clientloop.c > serverloop.c > packet.c > misc.c > and related header files. A simple diff between these files and the original > ssh code will tell you what I modified. > > I am not sure if the code is directly useable for your purpose, but I’ll > briefly talk about what my code does, and hopefully, it will give you some help > when reading the code. > > The code actually implements the Glove system, which requires that both the > client and server have a transcript of “super traces”. — I believe the location > of the transcript is hardcoded as ‘/var/tmp/st.txt’ in my code … > When visiting a website that is not shown in the transcript, the system falls > back to use CSBuFLO scheme. I see. Thanks for the references. Building this code into a pluggable transport would be more work than I had originally supposed. If there were a minimal network client and server, only implementing the website fingerprinting defense, then I wouldn't mind spending half a day to make them into a pluggable transport. But as it stands, it looks like it will be more work, essentially a reimplementation. David Fifield

1 0

Re: [tor-dev] Hidden Service authorization UI
by Nathan Freitas 10 Nov '14

10 Nov '14

On Sun, Nov 9, 2014, at 07:50 AM, George Kadianakis wrote: > Hidden Service authorization is a pretty obscure feature of HSes, that > can be quite useful for small-to-medium HSes. ... > For example, it would be interesting if TBB would allow people to > input a password/pubkey upon visiting a protected HS. Protected HSes > can be recognized by looking at the "authentication-required" field of > the HS descriptor. Typing your password on the browser is much more > useable than editing a config file. We have been working on implementing an OnionShare feature for Orbot, as a plugin/add-on. Since the client and the server are both one simple app, it seems like we could easily implement the HS Authorization feature. Since the goal is to share a file with a small audience, the second "client key" approach seems to be the best, most secure approach to me. Any thoughts?

1 0

Re: [tor-dev] HSDir Auth and onion descriptor scraping - actual stats
by Gareth Owen 10 Nov '14

10 Nov '14

OK. curiosity got the better of me. I took a random sample of 20,368 HS descriptors and just 131 were authenticated - that's about 0.6%. The code I used is here: https://github.com/drgowen/tor-research-framework/blob/master/src/main/java… Best Gareth PS - I only took a sample (rather than the whole batch) because each HS descriptor is in its own file and it takes ages to process - nevertheless, because of the way its collected the sample should be representative. -- Dr Gareth Owen Senior Lecturer Forensic Computing Course Leader School of Computing, University of Portsmouth *Office:* BK1.25 *Tel:* +44 (0)2392 84 (6423) *Web*: ghowen.me

1 0

HSDir Auth and onion descriptor scraping
by grarpamp 10 Nov '14

10 Nov '14

> George K: > I suspect that HS authorization is very rare in the current network, > and if we believe it's a useful tool, it might be worthwhile to make > it more useable by people. Is anyone making their HSDir onion descriptor scraping patches available somewhere? I'd suspect the rarity of HS authorization could also be determined with that since some fields would be obfuscated and thus not match patterns. s/scraping/logging/ rend--spec.txt: 2. Authentication and authorization. 2.1. Service with large-scale client authorization 2.2. Authorization for limited number of clients 2.3. Hidden service configuration 2.4. Client configuration

3 4