headers
Andrew F | 23 May 2013 17:35
Picon

Chrome browser and sand boxing.

I have Googled and searched the Tor website, but I have not found any information on chrome's sandbox feature and Tor.  Specifically with flash. 
Is there any information out their on this? 

Thanks
_______________________________________________
tor-dev mailing list
tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Permalink | Reply | 0 comments |
headers
Petter Solberg | 23 May 2013 14:46
Picon

Hidden services performance

Hi.


We are two master thesis students at the Norwegian University of Science and Technology (NTNU) which is looking into the performance of hidden services. We have already set up 19 physical Linux servers connected by gigabit Ethernet to be able to benchmark hidden services in a private tor network. We have also some public servers that we plan to utilize ( https://atlas.torproject.org/#search/disasterTor ). This mail is to inform you of our work and a request for ideas in where some bottlenecks are and if someone have done some previous research before.

Without any modifications to Tor we have been able to have a throughput of 180Mb/s through a single hidden service.


If you have some Ideas or a comment. Please reply.



Regards

Petter Solberg (pettso AT stud.ntnu.no ) &  Bram Bezem ( bezem AT stud.ntnu.mo )
_______________________________________________
tor-dev mailing list
tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Permalink | Reply | 1 comment |
headers
Micah Lee | 22 May 2013 19:26
Gravatar

www.torproject.org

I just opened a ticket for this:
https://trac.torproject.org/projects/tor/ticket/8940

Right now the way to check for the current TBB version is by loading
https://check.torproject.org/RecommendedTBBVersions.

It would be really helpful if there were a way to check the current
version of TBB from a URL at https://www.torproject.org/. The main
website has a .onion address, and all of the Tor mirrors listed at
https://www.torproject.org/getinvolved/mirrors.html.en are mirrors of
the main site, not check.

So if you want to only use the hidden service or only use a mirror
(because *.torproject.org is blocked on your network), there's no way to
easily know the current recommended version.

--
Micah Lee
 <at> micahflee


_______________________________________________
tor-dev mailing list
tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Permalink | Reply | 0 comments |
headers
bones44x6013 | 22 May 2013 19:03

[Fwd: Welcome to the "tor-dev" mailing list]

Hello again,

Now that after several hours of work, we have come full circle back to the
same email address I used for my original contacting you? I was not
allowed to contact you through this address because I was not a registered
user of this system?  Now that I am a registered user of this system, I
still have the same questions for you...Is this your most secure form of
communication and is it safe for me to send you this information via a MS
word document here through this email?

This information should only be viewed by top Tor Developers and
Management it is not meant for general discussion or a general discussion
board viewing.  This is the reason for my asking again about this again. 
I am providing you with a new technique for the secure communications of
bridge address network locations.  This method is proven and will work for
you.

Bones44

---------------------------- Original Message ----------------------------
Subject: Welcome to the "tor-dev" mailing list
From:    tor-dev-request@...
Date:    Wed, May 22, 2013 4:25 pm
To:      bones44x6013@...
--------------------------------------------------------------------------

Welcome to the tor-dev@... mailing list!

To post to this list, send your email to:

  tor-dev@...

General information about the mailing list is at:

  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

If you ever want to unsubscribe or change your options (eg, switch to
or from digest mode, change your password, etc.), visit your
subscription page at:

  https://lists.torproject.org/cgi-bin/mailman/options/tor-dev/bones44x6013%40tormail.org

You can also make such adjustments via email by sending a message to:

  tor-dev-request@...

with the word `help' in the subject or body (don't include the
quotes), and you will get back a message with instructions.

You must know your password to change your options (including changing
the password, itself) or to unsubscribe.  It is:

  zenuokna

Normally, Mailman will remind you of your lists.torproject.org mailing
list passwords once every month, although you can disable this if you
prefer.  This reminder will also include instructions on how to
unsubscribe or change your account options.  There is also a button on
your options page that will email your current password to you.

_______________________________________________
tor-dev mailing list
tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Permalink | Reply | 1 comment |
headers
Jon Smithe | 19 May 2013 20:40
Picon

Questions pertaining to client to directory authority communications

Hello!
 
I have been reading through the various tor specifications trying to understand how this all works, so please forgive any ignorance of the protocol on my part. There seems to be a fair amount of gaps about specifically how various communications take place; for instance if we consider the very beginning of the communication chain, Directory Authorities, we have the dir-spec.txt file which outlines rather well what type of information can be retrieved from the directories, but not what communication protocol is actually being used.
 
It appears that the usage of HTTP is fairly inherent, but this seems like it is only a partial answer as only some of the trusted authorities seem to speak HTTP on the address & port combination compiled into tor, moreover at least some of the authorities do not appear to implement the specification entirely. For instance, the trusted authority at MIT, 'morial' is listening on port 9131, however attempting to retrieve the network status document from it via a GET request to /tor/status/all.z results in no output at all. I would assume if this was a matter of needing to connect via SSL that I would receive an error due to a bad handshake, but I get nothing back. This holds true for at least one of the other trusted authorities listening on a non-HTTP related port (turtles). So for those servers, exactly what protocol is being used and is it documented anywhere other than the source code?
 
Then, for instance, if we connect to 'tor26', which does respond to HTTP requests and attempt to retrieve a v2 network status document via the /tor/status/all.z URI, we receive a 404 although it appears the document that should exist there exists on other URIs, it's not entirely clear if this is just outdated code, specific to particular versions of the protocol (tor26 does have the no-v2 flag set which might be the issue?) or what exactly.
 
So the question is, are there accurate specifications anywhere that focus not only on the semantics of cryptography and rationale behind certain choices but also the specifics of how exactly the protocol works or am I 'stuck' with reading the source code? I suspect that it is the later, so my question would be is there anyplace where the control flow is somewhat documented? (As the flow is somewhat disjointed at least in part to the way libevent works and other such aspects that make it difficult to parse if you're not familiar already with how everything is interconnected).
 
I have other questions about aspects of the protocol, but I will  mostly save those until I understand the basic blocks of it better. But to exemplify somewhat, it does seem that the introduction of guard nodes would cause an inverse of desired effect; there appears to be about 1000-1100 guard nodes versus a several thousand relays, and about 800-900 exit nodes so it would seem that mitigating the attack where an attacker controlled C number of nodes is essentially pointless as one would only need to control a set number of guard and exit nodes and can more or less ignore the relays in between, so whereas you needed say C/N nodes previously, one would only need Cg/Ng (Cg controlled guards / Ng Number of guards). If we then factor in that it seems possible that a guard or relay can essentially indirectly control the route a circuit takes through the network by continually causing cell extensions to fail for all relays and exit nodes that they do not control, then the value for Cg would seem to not need to be overly large or at least not approach the values of C or Cg (C/N or Cg/Ng).
 
This seems incredibly reasonable for attackers that have state level resources (What is 1,000 computers to China? Iran? ...the United States?) and because the algorithm for selecting guards appears to be based entirely on stability and bandwidth; metrics we can expect a government to have plenty of on hand. I understand that rotation is supposed to ease this somewhat, but at least according to the academic paper out of Waterloo that Roger co-authored, it would appear that this actually facilitates the compromise of more clients than eases the problem, with the most secure (in the lab) situation being a single guard. (I understand that in practice this will not be realistic as it creates a bottle-neck in a variety of ways, e.g. firewalls and DDoS).
 
 
I suspect many of the questions I have will be answered as I better familiarize myself with the protocol, so of the few I've enumerated,  they can be thought of exemplifications that I expect will hash themselves out as I progress through the source and specifications.
 
Thanks a lot!
 
Jon
_______________________________________________
tor-dev mailing list
tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Permalink | Reply | 3 comments |
headers
Marti Raudsepp | 19 May 2013 16:37
Gravatar

RFC patch: systemd socket activation

Hi list,

The attached patch implements support for systemd socket activation.

For people who don't know what that is: systemd is an "init" system
for Linux. Socket activation means that systemd binds all the sockets
in advance, and only spawns Tor once somebody attempts to connect.

More information here: http://0pointer.de/blog/projects/socket-activation.html

I rarely use Tor, so there's no reason to have it running all the time
(wasting battery on my laptop), but it's also annoying to launch it
manually every time. Socket activation is ideal for this use case.

There are 3 changes to the startup process:
1. Before loading the configuration, Tor identifies all sockets passed
in by systemd and creates pending_socket_t objects. I considered
reusing connection_t, but that seemed to require way more modification
to the code.
2. After parsing configuration, when Tor would otherwise create new
listeners, it first tries to match up the address/port to existing
pending sockets. If a pending socket does not match, it opens a new
one as usual.
3. After configuration parsing is done, Tor closes all remaining
unmatched systemd sockets and logs a warning for each one.

This infrastructure can also be used to support "launch-on-demand"
with launchd on OS X, but I have no experience with that.

Known problems:
* TCP and UDP sockets work, but Unix sockets are not currently yet implemented.
* It's impossible to support hibernation as is for systemd sockets --
the systemd daemon still keeps a reference to the listener socket even
after we close it, and it's impossible to re-bind the port later.
* Closing unmatched sockets is a bad idea for the same reason: systemd
still keeps it open and connections hang forever. Perhaps a better
solution is to keep the socket and simply reject all connections,
ditto hibernating connections?

I have added the source of sd-daemon.c into Tor -- it's easier to
manage this way and we don't introduce any new library dependencies
(it's 804 LoC total). This approach is also encouraged by systemd
itself. The code turns into a no-op when built on Windows.

Full patch is attached, also available as individual commits from my
GitHub clone (branch "systemd"):
https://github.com/intgr/tor/tree/systemd

Regards,
Marti
Attachment (tor-systemd.patch): application/octet-stream, 39 KiB
_______________________________________________
tor-dev mailing list
tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Permalink | Reply | 4 comments |
headers
Christian Kujau | 18 May 2013 06:08
Picon

Your server has not managed to confirm that its ORPort is reachable

Hi,

I had to reboot my bridge for a (Ubuntu) kernel upgrade but now it cannot 
confirm that the ORPort is accessible:

May 17 20:20:36.000 [notice] Tor 0.2.4.12-alpha (git-a1bb0df9be95ce7a) opening log file.
May 17 20:20:36.000 [notice] Not disabling debugger attaching for unprivileged users.
May 17 20:20:36.000 [notice] Your Tor server's identity key fingerprint is '...'
May 17 20:20:36.000 [notice] Configured hibernation.  This interval began at 2013-05-13 10:00:00; the
scheduled wake-up time was 2013-05-13 10:00:00; we expect to exhaust our quota for this interval around
2013-05-20 10:00:00; the next interval begins at 2013-05-20 10:00:00 (all times local)
May 17 20:20:36.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
May 17 20:20:37.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
May 17 20:20:37.000 [notice] Configured to measure statistics. Look for the *-stats files that will first
be written to the data directory in 24 hours from now.
May 17 20:20:40.000 [notice] We now have enough directory information to build circuits.
May 17 20:20:40.000 [notice] Bootstrapped 80%: Connecting to the Tor network.
May 17 20:20:41.000 [notice] Bootstrapped 85%: Finishing handshake with first hop.
May 17 20:20:41.000 [notice] Bootstrapped 90%: Establishing a Tor circuit.
May 17 20:20:42.000 [notice] Registered server transport 'obfs3' at '0.0.0.0:30001'
May 17 20:20:42.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:20001'
May 17 20:20:43.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
May 17 20:20:43.000 [notice] Bootstrapped 100%: Done.
May 17 20:20:43.000 [notice] Guessed our IP address as ... (source: ...).
May 17 20:40:43.000 [warn] Your server (...:9001) has not managed to confirm that its ORPort is reachable.
Please check your firewalls, ports, address, /etc/hosts file, etc.

I have not changed my tor configuration (honest! :-)) and Tor 
0.2.4.12-alpha (from deb.torproject.org) was running fine before. This 
particular bridge is running inside an Amazon EC2 instance and I can reach 
port 9001 from the outside:

$ nc -w1 -vnz xx.18.xx.xxx 9001
Connection to xx.18.xx.xxx 9001 port [tcp/*] succeeded!

And I can see that request on the bridge when tcpdump'ing :9001, so it's 
not a network issue. I'm not sure what "/etc/hosts" should have to do with 
it, but I haven't modified this either. I'm strace'ing the tor process now 
to see what it's doing but couldn't find anything suspicious so far.

Any thoughts?

Christian.
--

-- 
BOFH excuse #139:

UBNC (user brain not connected)
_______________________________________________
tor-dev mailing list
tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Permalink | Reply | 3 comments |
headers
not me | 18 May 2013 04:07
Picon

building from source in a 64-bit windows environment..

Hi,

It seems fairly self-evident that tor hasn't been build for 64-bit
windows and questionable whether it's ever been built in an
environment that doesn't utilize mingw. There are literally hundreds
of thousands of warnings about integer truncation, at least some of
which seem somewhat problematic (64-bit pointer being stored in a
32-bit integer (why?! why?!)), a small amount of signed/unsigned
comparisons or sign extensions, and a bunch of calls to functions
without including the proper header files or using the correct
function name ('open()' vs '_open()' without including io.h) and so
on.

This of course is ignoring all the calls to
str{,n}cpy/{v,}s{,n}printf/etc and posix function names long since
deprecated (fileno() vs _fileno()) and so on. Errors relating to MSVC
finally including a stdint header (cstdint) and typedef's for intptr_t
not producing the right size primitive, etc.

I realize that many/most/all of the developers here are going to see
no problem with using mingw, but if you spend some time looking
underneath the hood and reviewing the code generated by mingw v. msvc
both in terms of security features and general performance, I can't
feel that its a prudent or responsible choice to produce anything
under windows using GNUs development tools. So I'd prefer to just
eliminate all such 'fixes'.

Moving to 32-bit isn't an option either, I'd have to switch out far
too many dependencies that frankly are a bit more important, and well
I need 64-bit for some aspects and it's only been a decade since AMD
released their first 64-bit chip.

So, has anyone out there successfully built tor with a 64-bit msvc,
and if so, you don't happen to have a list of voodoo tricks you
performed or a diff or similar?

Thanks.
_______________________________________________
tor-dev mailing list
tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Permalink | Reply | 22 comments |
headers
George Kadianakis | 17 May 2013 15:23

Discussion on the crypto migration plan of the identity keys of Hidden Services

Greetings,

I'm supposed to write a Tor proposal for the migration of the
long-term identity keys of Hidden Services. When I began writing the
proposal, I realized that some of my choices might not be appreciated by
Hidden Service operators, and that starting a discussion thread might be a
good idea before writing the proposal.

The problem with the current long-term HS identity keys is that they
are RSA-1024 keys which are considered weak, and they need to be
upgraded to a cryptosystem with higher security properties.

One of the main issues with this operation, is whether Hidden Services
will be accessible using their *old* identity keys even after the
migration.

That is, when we change the identity keys of a Hidden Service, its
onion also changes (since the onion is the truncated hash of its
public key). This will be quite problematic for Hidden Services that
have a well-established onion address.

There are basically two ways to do this:

a) After the transition, Hidden Services can be visited _only_ on
   their _new_ onion addresses.

   This is quite brutal, but it's the most secure and unambiguous
   option (might also be easier to implement and deploy).

   This change can be enforced both on the client-side, by rejecting
   any old RSA-1024 HS keys, and on the server-side, by only
   publishing the new keys in HS descriptors.

   To make the transition easier, we could prepare a tool that
   generates a new identity keypair before the flag day, so that
   Hidden Service operators can learn their future onion address
   beforehand and announce it to their users.

b) After the transition, Hidden Services can use both old and new
   onion addresses.

   This might result in a more harmonious transition, where Hidden
   Services advertise their new onion address to users that visit
   them in their old address.

   .oO(It would also be interesting to do a redirection on the Tor
   protocol layer ("I got this descriptor by querying for the old
   onion address, but it also contains a new onion address. I should
   probably use the new one."), but I don't think it's possible to
   redirect the user without knowledge of the application-layer
   protocol (e.g. 302 for HTTP). Still, a Tor log message might be
   helpful.)

   The cons of this approach is that supporting both addresses might
   make the HS protocol more complicated and painful to implement, and
   it might also result in some Hidden Services never moving to the
   new onion addresses since clients can still visit them using the
   old insecure ones.

   This approach has a stricter variant, where the old addresses can
   only be used during a transitionary period (a few months?). After
   that, clients _have_ to use the new addresses. Of course, this
   means that we will have to do two flag days, coordinate Tor
   releases, and other no fun stuff.

I'm probably moving towards the latter option because the former will
make many people unhappy.

Thoughts?

(This is not a thread to select the cryptosystem we are going to
use. It will derail the discussion, and we might also need to select a
specific type of cryptosystem in the end (e.g. a discrete-log-based
system) so that schemes like
https://trac.torproject.org/projects/tor/ticket/8106
can be possible.).

_______________________________________________
tor-dev mailing list
tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Permalink | Reply | 15 comments |
headers
Gordon Morehouse | 16 May 2013 19:50
Gravatar

obfs3 and Android

Hi there, I know a user in China with an Android device who is having
trouble with the GFW.  I run private bridges for a couple friends in odd
places and recently upgraded to obfs3, but after inquiring on IRC this
morning I found that Android doesn't have obfs3 support yet:

17:17 < gamambel> gmorehou: unfortunately, not yet. someone has to
either implement obfs3 in C, or make the new python obfsproxy work on
Android. i don't think anybody is working on that yet.

Just a quick question (apologies if it's a repeat) from a totally
Android-naive developer: is using Jython a possibility to speed the
availability of obfs3 on Android?  Last I knew, which was in the dark
ages, some Python code could be tortured into running on Android devices
by compiling it with Jython.  Just curious if this has been considered
or not.  I don't know what Android-specific problems there may be, but I
know that in general Jython lags behind the latest stable Python, so
e.g. code written against Python 2.7 might need to be tweaked to run
against 2.5, etc.

--

-- 
Sent from my device
_______________________________________________
tor-dev mailing list
tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Permalink | Reply | 0 comments |
headers
Jamie Nguyen | 15 May 2013 13:25

Tor Browser source tarball not available

Hi, the source at this link is missing:

https://www.torproject.org/dist/torbrowser/tor-browser-2.3.25-8-src.tar.gz

I'd be very grateful if someone could upload it please.

Kind regards,

--

-- 
Jamie Nguyen

_______________________________________________
tor-dev mailing list
tor-dev@...
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Permalink | Reply | 0 comments |

Gmane