Re: [tor-dev] Obfsproxy support for Tor Browser Launcher
Micah Lee: Would it be possible to include the current recommended obsfproxy version in this document? https://check.torproject.org/RecommendedTBBVersions That would be related to https://trac.torproject.org/projects/tor/ticket/8644 https://trac.torproject.org/projects/tor/ticket/8645 -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Launcher UI feedback follow up
Tom Ritter: Some small suggestions: - I'd flip the bottom and the top, with connect being on top. - Wording suggestion: This computer's internet connection is free of obstacles: [greenboldtext]My network operator does not threaten my person safety[/greenboldtext] This computer's Internet connection is [redboldtext]censored, filtered, or proxied[/redboldtext] Nitpick: you might be configuring someone else's computer, so “my” might not be appropriate. In some future, having stylized images on that screen could be great. In any cases, it's already quite an improvement. :) -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Haskell packages?
Hi Nikita! Nikita Karetnikov: I'd like to improve my Haskell skills. Are there any opportunities? I've been told there is at least one project that uses Haskell, which is not maintained. (For example, this page [1] mentions TorDNSEL, which was replaced by TorBEL.) TorDNSEL is providing an important service to the Tor community right now. It should be replaced by TorBEL at some point. But the later is not ready. In order to have TorDNSEL work on Debian Squeeze, I did some small changes to make it uses Control.OldException. But this does not work anymore on GHC 7.4. The later is the version currently in Debian Wheezy. If you wish to make weasel (one of Tor all mighty sysadmins) happy you could update TorDNSEL to the new APIs and make sure that it works on Debian Wheezy. How do you feel about it? Even if my Haskell is rusty, I'd be happy to have a look at your changes, if you want/need some reviews. :) -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Memorable onion addresses (was Discussion on the crypto migration plan of the identity keys of Hidden Services)
Matthew Finkel: Some months ago, the petname system interested me enough that I started to write a proposal for it. At this point, it's wound up in bitrot. Though I'd spent a bit of time working on it, there was no comprehensive way to accomplish it. One thing to remember about petnames is that they are *user defined*. […] The problem I ran into with this scheme is where the mappings should be stored - who is in control of this? In short, is this a mapping that Tor persistently stores or is it a client application that handles this. AND if it is a client application, that becomes a usabibility nightmare because if Tor Browser has an interface for it, then that's great but what if I'm using irssi and lynx on a headless system? If Tor maintains this database, then for the petname to perform as expected, every application would need to support a minimal Controller and have the ability to resolve the name mappings (and possibly append to them, also). What looks like a possible way to solve the problem you describe: The address book would be stored by the Tor daemon, in a persistent manner. A new host extension would be introduced so that when an application tries to connect to `torproject.myonions` through Tor, it will connect to the hidden service that holds the name `torproject` in the local address book. Editing the local address book would be done through commands sent through Tor control port. The Tor Browser could gain a new `about:myonions` page for GUI editing. Editing capacities could also be added to Arm for headless system. And we could even make the address book file human editable to have `vi` as a fallback. (I don't really like `myonions` but I'm sure someone will come with something better.) Usability wise, I wonder if we could implement some kind of web links that could quickly add a new name in the local address book (after user confirmation). -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PRELIMINARY: [PATCH 3/3] Replace 'TorDNSEL.System.Timeout' with 'System.Timeout'.
Nikita Karetnikov: Well, I agree. However, even obvious changes might be useful in the long term. The GNU Coding Standards, which I use as a guide, suggest the following: Subsequent maintainers will often search for a function name to find all the change log entries that pertain to it... [1] (For instance, cgit allows that.) It also helps when you're trying to fix bugs. Moreover, I often spot mistakes when I'm writing such messages. I both agree, but I also try to keep in mind than the (at least most) GNU Coding Standards were thought in a time when we did not have version control solutions as good as git. Using `git blame` or `git log -S` or `git log -G` will actually work better than a file by file summary. If you throw in the `-M` option, it'll work accross renames, for examples. Attached. Do you have any other comments? […] From 87ad0fe6f010b251aed042618dc82651294a477a Mon Sep 17 00:00:00 2001 From: Nikita Karetnikov nik...@karetnikov.org Date: Thu, 25 Jul 2013 20:29:08 + Subject: [PATCH 1/2] Reimport internal GHC functions from new locations. --- Why not put what you wrote in your description email in there? This was a good explaination of why the change was actually needed! :) GHC was recently changed to not allow you to use newtypes in FFI imports unless the constructor of the newtype is in scope. [1] [1] http://ghc.haskell.org/trac/ghc/ticket/5610 I am looking forward to the moment you'll have a patch set that builds. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PRELIMINARY: [PATCH 3/3] Replace 'TorDNSEL.System.Timeout' with 'System.Timeout'.
Nikita Karetnikov: Using `git blame` or `git log -S` or `git log -G` will actually work better than a file by file summary. If you throw in the `-M` option, it'll work accross renames, for examples. OK. But that information will be lost if we decide to change a VCS for some reason. Well, we could avoid switching to a VCS that would loose such valuable information! :) Why not put what you wrote in your description email in there? This was a good explaination of why the change was actually needed! :) GHC was recently changed to not allow you to use newtypes in FFI imports unless the constructor of the newtype is in scope. [1] [1] http://ghc.haskell.org/trac/ghc/ticket/5610 OK. So let me summarize: 1. I shouldn't explicitly name changed functions or modules. 2. I can add a small description (like the above) if it's appropriate. Did I forget anything? Feel free to develop your own style and taste. Some readings: http://who-t.blogspot.de/2009/12/on-commit-messages.html http://robots.thoughtbot.com/post/48933156625/5-useful-tips-for-a-better-commit-message http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history/ This is quite thorough: https://wiki.openstack.org/wiki/GitCommitMessages -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] High load even with 0.2.4.17-rc
(This would have probably been better asked on tor-relays@.) Leo Unglaub: to fix the load issues on my 5 relays i tryed the suggested development version of tor. But there is not difference at all on the exit relays. They all burn on 99% CPU usage at 23 MB/s bandwidth. Is there something special i have to do in the config to benefit from the new changes mad to quicker peerform the handshakes between the circuits? Tor 0.2.4.17-rc will prioritize ntor handshakes over TAP handshakes. But TAP handshakes are still processed, and they are not scarce at the moment. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] First draft of Requirements and Software Design for a Better Tor Performance Measurement Tool
Karsten Loesing:
Feedback in the form of patches to the LaTeX sources is most preferred,
though email replies are of course fine, too.
See attachments.
--
Lunar lu...@torproject.org
From 22fed7b7155481904cb92136f9d04777fad72fde Mon Sep 17 00:00:00 2001
From: Lunar lu...@torproject.org
Date: Fri, 6 Sep 2013 18:11:15 +0200
Subject: [PATCH 1/3] Use Selenium with the Tor Browser instead of plain
Firefox
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If we want Torperf to gather realistic data, it makes more sense to use the
browser recommended by the Tor Project to access the web — the Tor Browser —
instead of Firefox.
As the Tor Browser is based on Firefox, driving other Firefox versions should
not be too complicated, but the primary target should be the Tor Browser.
This also will also give us a framework to test the performance of Tor Browser
(present and future) patches.
---
2013/torperf2/torperf2.tex |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/2013/torperf2/torperf2.tex b/2013/torperf2/torperf2.tex
index b3eb955..1c643c0 100644
--- a/2013/torperf2/torperf2.tex
+++ b/2013/torperf2/torperf2.tex
@@ -207,7 +207,7 @@ stem or another parsing library.
\subsection{High priority experiments}
-\subsubsection{Alexa top-X websites using Selenium/Firefox}
+\subsubsection{Alexa top-X websites using Selenium and the Tor Browser}
One major reason for rewriting Torperf is to make its results more
realistic.%
@@ -216,10 +216,10 @@ It was suggested to track down Will Scott's torperf-like scripts, make
them public if needed, and do a trial deployment somewhere.%
\footnote{\url{https://trac.torproject.org/projects/tor/ticket/7516}}
An experiment making these more realistic measurements should use
-something like Selenium/Firefox to control an actual browser to make
+something like Selenium to control an actual Tor Browser to make
requests.
-As a variant, this experiment should be run with a Firefox that uses
-optimistic data.%
+As a variant, this experiment should be run with other Firefox versions, e.g.
+that one that uses optimistic data.%
\footnote{\url{https://trac.torproject.org/projects/tor/ticket/3875}}
\subsubsection{Static file downloads}
--
1.7.10.4
From 63f70cd36a7f5d14eb200c10f68ee16f07c38e90 Mon Sep 17 00:00:00 2001
From: Lunar lu...@torproject.org
Date: Fri, 6 Sep 2013 18:14:48 +0200
Subject: [PATCH 2/3] Using stream isolation features is probably the easiest
way to create new circuits
---
2013/torperf2/torperf2.tex |4
1 file changed, 4 insertions(+)
diff --git a/2013/torperf2/torperf2.tex b/2013/torperf2/torperf2.tex
index 1c643c0..6e8d2f5 100644
--- a/2013/torperf2/torperf2.tex
+++ b/2013/torperf2/torperf2.tex
@@ -239,6 +239,10 @@ value that is lower than the experiment period.
An alternative may be to send the \verb+NEWNYM+ signal to the tor process
after every stream.%
\footnote{\url{https://trac.torproject.org/projects/tor/ticket/2766}}
+The easiest path might be to leverage on the stream isolation features
+introduced in tor 0.2.3%
+\footnote{\url{https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/171-separate-streams.txt#l93}}
+and use a different SOCKS username/password for each requests.
The best way to extract these requirements is to read the source.%
\footnote{\url{https://gitweb.torproject.org/torperf.git/tree}}
--
1.7.10.4
From dac23d7068803745a70fc5ed7c81522f6ecc5822 Mon Sep 17 00:00:00 2001
From: Lunar lu...@torproject.org
Date: Fri, 6 Sep 2013 18:20:42 +0200
Subject: [PATCH 3/3] Also do upload tests using web browsers to gather more
data related to actual user experiences
---
2013/torperf2/torperf2.tex |3 +++
1 file changed, 3 insertions(+)
diff --git a/2013/torperf2/torperf2.tex b/2013/torperf2/torperf2.tex
index 6e8d2f5..e34706e 100644
--- a/2013/torperf2/torperf2.tex
+++ b/2013/torperf2/torperf2.tex
@@ -307,6 +307,9 @@ Similar to static file downloads, client and server timestamps can be
matched based on the random data that is posted to the server, or a digest
of that data.
+Ideally such upload tests should also be done using a full web browser
+drived by Selenium.
+
\section{Software design}
The previous sections outlined requirements to the Torperf rewrite and
--
1.7.10.4
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Pluggable transport weekly meeting
Ximin Luo: I assume people will be interested in creating Debian packages for these too. I am wondering if we should adopt a naming convention like tor-pt-sshproxy, tor-pt-flashproxy, tor-pt-obfsproxy etc - like how mozilla extensions are all called xul-ext-*. (We could even start a working group too.) ATM this would involve renaming obfsproxy, but I am about to package flashproxy, and thinking about what to name the package. I have heard people making the argument that obfsproxy, at least, was not specific to Tor and could perfectly be used with plain SSH. The prefix “tor-pt-” would not really be appropriate then. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] File verification GUI tool
Matt Pagan: If you go the browser extension route, there is a now defunct Firefox add-on called FireGPG that implemented GnuPG in the web browser. This add-on was discontinued in 2010 and it's primary focus was encrypting and decrypting gmail messages. […] I'd like to remember everyone that it was probably discontinued because in the end it turned to be a terrible idea. Tails wrote a statement about it: https://tails.boum.org/doc/encryption_and_privacy/FireGPG_susceptible_to_devastating_attacks/ Although an extension whose sole purpose would be to verify GnuPG signatures would not have the problem and seems like a good idea. At least, shipping it through addons.mozilla.org give the user some basic trust path. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Sponsor F: update; next meeting [in *two weeks*]
Matt Pagan: There still exists a bug in Mumble such that when network connections are routed through a proxy they leak DNS requests. This past month I've been reading QT documentation so that I can understand the Mumble code better and find the bug. After the meeting on IRC, velope suggested that fixing it might be as simple as implementing SOCKS5 with hostname. DNS leaks also occur with HTTP proxies, which shouldn't happen. See also: http://sourceforge.net/p/mumble/bugs/1033/ It's not as simple as implementing SOCKS5. Mumble contains a custom async resolution logic. The code is not great to follow, that's why I stopped the effort of trying to write a fix once Mikkel Krautz acknowledged the issue. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Attentive Otter: Analysis of Instantbird/Thunderbird
Mike Perry: + Leveraging the work done on TorBirdy, we can distribute Instantbird and Tor (and related components) in a single package, or as a combined addon. + Use Tor Launcher as the controller (sukhe recently added Thunderbird support) + Will allow seamless zero-configuration Tor usage for normal case, and will share Tor Browser's future Pluggable Transport support with no additional effort. + See the TorBirdy manual for more information: https://trac.torproject.org/projects/tor/wiki/torbirdy#TorBirdywithTorandTorLauncher I'd like to add that we can probably also leverage the work done on using Mozilla's updater in TBB to perform automatic updates of an Instantbird bundle. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] CPAProxy - a thin Objective-C wrapper around Tor
Claudiu-Vlad Ursache: - CPAProxy sets up Tor's DataDir in a temporary directory of an app's sandbox where it's not accessible by other processes. Should that directory be protected in any other way? Having DataDir temporary means that the client will pick new guards everytime it starts. This opens the door to more traffic correlation attacks. See the relevant FAQ for more details about entry guards: https://www.torproject.org/docs/faq.html.en#EntryGuards -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Torsocks 2.x issue - Need eyes on that
David Goulet: Now the issue was detected with firefox which uses a custom malloc hook meaning that it handles its own memory allocation. This hook uses mmap() that firefox redefines to be a direct syscall(__NR_mmap, ...) and remember that this symbol is hijacked by torsocks. […] It's a bit of a catch 22 because torsocks is basically looking for the libc syscall symbol but then it gets call inside that lookup code path... Wouldn't one way out be to also hook malloc to use a static buffer until dlsym() is done? The code snippet in the following answer is doing just that: http://stackoverflow.com/a/10008252 -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Torsocks 2.x issue - Need eyes on that
Lunar:
David Goulet:
Now the issue was detected with firefox which uses a custom malloc hook
meaning that it handles its own memory allocation. This hook uses mmap()
that firefox redefines to be a direct syscall(__NR_mmap, ...) and
remember that this symbol is hijacked by torsocks.
[…]
It's a bit of a catch 22 because torsocks is basically looking for the
libc syscall symbol but then it gets call inside that lookup code
path...
Wouldn't one way out be to also hook malloc to use a
static buffer until dlsym() is done? The code snippet in the following
answer is doing just that:
http://stackoverflow.com/a/10008252
Meh… scratch that. It looks like defining calloc() in libtorsocks.so is
not enough to have our own function called. Not sure why.
With the attached patch, at least we panic cleanly.
--
Lunar lu...@torproject.org
diff --git a/src/lib/syscall.c b/src/lib/syscall.c
index 0edd460..d520c0a 100644
--- a/src/lib/syscall.c
+++ b/src/lib/syscall.c
@@ -17,6 +17,8 @@
#include assert.h
#include stdarg.h
+#include stdlib.h
+#include stdio.h
#include common/log.h
@@ -112,6 +114,19 @@ LIBC_SYSCALL_DECL
LIBC_SYSCALL_RET_TYPE ret;
va_list args;
+#if defined(SYS_mmap) || defined(SYS_mmap2)
+ if (NULL == tsocks_libc_syscall) {
+ switch (__number) {
+ case SYS_mmap:
+#ifdef SYS_mmap2
+ case SYS_mmap2:
+#endif
+ fprintf(stderr, Panic! mmap has been called before we
had our hands on the real syscall()\n);
+ exit(EXIT_FAILURE);
+ break;
+ }
+ }
+#endif
/* Find symbol if not already set. Exit if not found. */
tsocks_libc_syscall = tsocks_find_libc_symbol(LIBC_SYSCALL_NAME_STR,
TSOCKS_SYM_EXIT_NOT_FOUND);
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] next globe update feedback
Philipp Winter: On Sun, Nov 03, 2013 at 11:23:18AM -0800, Damian Johnson wrote: I worked on a new update for globe... Damn this is awesome! I'm tempted to link to this from our front page (replacing Tor Browser in the project matrix on www.torproject.org, since TBB is already the featured item on the download page). Actually, it should rather replace Atlas. It no longer has an active maintainer (Karsten and I are just trying to keep it alive and fix small bugs) and is still not able to display bridge information. Maybe it's time to retire Atlas in favour of Globe? Quoting Karsten last July: “However, I don't have plans to retire Atlas just yet. I think it's fine to have more than one website providing access to Onionoo data. Yay, diversity.” https://lists.torproject.org/pipermail/tor-dev/2013-July/005122.html But the situation might have changed since then. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Bug 9665
Hi Fábio, Fábio Bertinatto: I would like to start contributing to Tor development thus I picked up a bug and tried to fix it. Great! :) It's the 9665: https://trac.torproject.org/projects/tor/ticket/9665 I don't know whether I understood the problem well or not but I came up with the attached (trivial) solution. Could someone please check if it's ok? Best course of action is probably to attach the patch to the ticket, and set the status to “needs_review”. Andrea or Nick are likely to take a look the next time they'll scan open tickets, if not earlier. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] recreated website png diagrams as svg
Justin Findlay: Item h under https://www.torproject.org/getinvolved/volunteer.html.en#OtherCoding discusses (at least) the images at this page, https://www.torproject.org/about/overview.html.en which look as if they're copied from some EFF presentation. I've recreated them as svg. Svg being a fairly standard vector markup, I supposed that it would be more amenable to automatic string replacement than a png (I'm not sure what wml is). Please look them over and give me feedback. If they are ultimately found acceptable, you are welcome to use them for the site. Thanks. I think they look great. :) But something has always bothered me with these diagrams: they make it look like Tor relays are run on everyone's computer. With Justin's revision, it looks like they are run on laptops. The vast majority of Tor relays are run on stable servers and most of the traffic flows through high capacity servers, hosted in datacenters behind high capacity links. So I think picturing a laptop might be misleading… -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Design for an exit relay scanner: feedback appreciated
Philipp Winter: I now have similar code which is based on stem: https://github.com/NullHypothesis/exitmap However, the problem with a parallel single-Tor-process design is that there is no easy way for scanning modules to figure out which exit relay they were attached to. The Tor controller just sees a bunch of incoming streams but once, one of these streams spots something fishy, it is difficult to figure out which exit relay is to blame. I am unsure about the meaning of the `cmd` parameter in the probe method of your modules. But, can't you pass the circuit ID (or an opaque wrapper object, actually) to the scanning module, and have the scanning module pass that to the stream attacher when it has a stream ready? (Feel free to ignore me if that sounds like non-sense. I only had a quick look at the code.) -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor project automation work
Nicolas Vigier: Ok, we can have a test rebuilding several times the files that are most likely to become non deterministic. However it would be better if we can find some way to trigger those non-deterministic builds with only two builds. Maybe we can try something like this : - a library that we put in LD_PRELOAD as a wrapper on readdir to return directory entries in random order instead of inodes number, so it's more likely to be different on each build. - a python library that we put in PYTHONPATH, to override dict.iterkeys to return keys in random order. If I understand ticket #10159 correctly, it was caused by iterkeys returning keys in the same order most of the time, but not all the times. I would suggest using reverse order instead of random order. Random order has the probability of being just like the original order. For readdir(3), have a look at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719845#39 -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfsproxy dns transport
George Kadianakis: b) You can write your own Python code and selectively steal code from obfsproxy. You will have to steal the code that does networking, Extended ORPort, environment variable parsing (pyptlib), SOCKS, etc. This might not be too hard. Could the shared code be used to augment pyptlib? I guess Extended ORPort is probably something that all Python pluggable transport implementations might want. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Patch to remove goto from sandbox.c
Hartmut Prochaska: I changed a function in sandbox.c to not use a goto statement. I didn't understood what use it had. Attached the patch file. See https://www.kernel.org/doc/Documentation/CodingStyle, Chapter 7, “Centralized exiting of functions” for a rationale. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [RELEASE] Torsocks 2.0.0-rc4
David Goulet: After a big code review from Nick and help from a lot of people contributing and testing, this is the release candidate 4 for the new torsocks. I was about to push the new version to Debian experimental, but it just breaks my SSH configuration too badly. The new version forbids listen() and accept(). That means that at least SSH options ControlMaster, LocalForward, and DynamicForward will not work. Being able to multiplex connections (ControlMaster) is pretty crucial to keep sanity when working over hidden services. Forwarding options allow a simple way to create to tunnel TCP connections to a remote system through SSH over Tor. I am not sure what is the right move here. Perhaps allowing listen on Unix sockets and localhost? Or maybe allowing listen() entirely? -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Mockup for a hidden services publishing tool
Matt Pagan: Before I get much further with this idea, is this project worth pursuing at all? You should have a look at APAF: https://apaf.readthedocs.org/en/latest/ It is able to configure new hidden services through a web interface, but even better, it is meant to setup both a Hidden Service and a piece of software serving things at the same time. Do you think this tool has potential to function as a point-click-publish hidden services software? IMO, no. If we want “point-click-publish”, we need to have the publishing software configure Tor. Unless you are a network administrator, you don't care about ports. You don't care about internal IP addresses. You just want to say: “I want to make a blog available”; and have the software reply: “Done, it's at: idnxcnkne4qt76tg.onion. Spread the address around.” I should not need to know anything else. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GoSC - Website Fingerprinting project
Marc Juarez: I think website fingerprinting is one of the most threatening attacks to Tor because it can be deployed with moderate resources and the information that can be extracted as a result is highly sensitive (e.g., browsing history). It basically defeats one of the main privacy guarantees offered by Tor which is unlinkability between sender and recipient or, in this particular case, between the user and the web server. However, I couldn't find any open project that tackles this problem in https://www.torproject.org/getinvolved/volunteer.html.en#Projects. That is why I'd like to propose a GoSC project for the implementation of tools (packages, classes, etc.) that contribute in the development of a countermeasure against this attack. Have you read Mike Perry's long blog post on the topic? https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-attacks It outlines future research work in evaluating the efficiency of fingerprinting attacks, and also mention a couple of promising defenses. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [RELEASE] Torsocks 2.0.0-rc5/6
David Goulet: Github tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc6.tar.gz TPO Tarball: https://people.torproject.org/~dgoulet/torsocks-2.0.0-rc6.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks-2.0.0-rc6.tar.bz2.asc) Also available from Debian experimental: http://packages.qa.debian.org/t/torsocks/news/20140317T212304Z.html -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Specs
Ahmed: Is this the latest version of Tor specification protocol? https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.txt You will find the latest specifications in that Git repository, yes. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Installing obfsproxy from wheezy-backports
irregula...@riseup.net: tl;dr obfsproxy from wheezy-backports raises exception about not finding Twisted although Twisted-core is installed. Please update to version 0.2.8-1~bpo70+1. It should fix the issue. Thanks for the report. It would be great if you could use the Debian bug tracking system next time. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A Child's Garden of Pluggable Transports
David Fifield: Have you ever wondered what makes the Tor protocol fingerprintable, and makes pluggable transports necessary? Have you wondered how obfs3 obscures byte patterns in Tor? What a flash proxy WebSocket connection actually looks like, and why it defeats IP blocking but not DPI? Then I have the wiki page for you: https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPluggableTransports It's a visualization of different pluggable transports, meant to be an aid to understanding. At the top is an ordinary Tor handshake, with some fingerprintable data fields highlighted. The following sections, one for each transport, show how those fields are hidden--or not. I tried to demonstrate aspects of different transports that I think are hard to intuit, such as what flash proxy rendezvous looks like, and how transports look under the encrypted layer that is visible to a censor. This is a beautiful and helpful piece of work. Thank you! -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PrivEX - Privacy
Tariq Elahi: What we would really like in order of importance is 1) a design review of our proposal, […] Maybe it's a non-issue but “better ask than sorry”. If I get it, the idea is to publish a list of visited domain names and how frequently they have been visited (with noise). Would the privacy of users be respected if a website contains a link to a per-visitor generated hostname (using DNS wildcards)? -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PrivEX - Privacy
Lunar: Tariq Elahi: What we would really like in order of importance is 1) a design review of our proposal, […] Maybe it's a non-issue but “better ask than sorry”. If I get it, the idea is to publish a list of visited domain names and how frequently they have been visited (with noise). Would the privacy of users be respected if a website contains a link to a per-visitor generated hostname (using DNS wildcards)? Please ignore me: “To further reduce the risk of inadvertent disclosures, it collects only information about destinations that appear in a list of known censored websites.” -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [PATCH] Add some words about meek in proposal 203
This is mostly David Fifield's words from an email exchange. --- I re-read proposal 203 the other day and wondered how it was related to the meek pluggable transport. As I might not be the only one, I thought it could be worthwhile to share David's answer. Feel free to improve! proposals/203-https-frontend.txt | 28 1 file changed, 28 insertions(+) diff --git a/proposals/203-https-frontend.txt b/proposals/203-https-frontend.txt index 26101b3..df30cd5 100644 --- a/proposals/203-https-frontend.txt +++ b/proposals/203-https-frontend.txt @@ -245,3 +245,31 @@ Side note: What to put on the webserver? Something to add to your HTTPS website rather than as a standalone installation. +Related work: + + meek [1] is a pluggable transport that uses HTTP for carrying bytes + and TLS for obfuscation. Traffic is relayed through a third-party + server (Google App Engine). It uses a trick to talk to the third + party so that it looks like it is talking to an unblocked server. + + meek itself is not really about HTTP at all. It uses HTTP only + because it's convenient and the big Internet services we use as cover + also use HTTP. meek uses HTTP as a transport, and TLS for + obfuscation, but the key idea is really domain fronting, where it + appears to the censor you are talking to one domain (www.google.com), + but behind the scenes you are talking to another + (meek-reflect.appspot.com). The meek-server program is an ordinary + HTTP (not necessarily even HTTPS!) server, whose communication is + easily fingerprintable; but that doesn't matter because the censor + never sees that part of the communication, only the communication + between the client and CDN. + + One way to think about the difference: if a censor (somehow) learns + the IP address of a bridge as described in this proposal, it's easy + and low-cost for the censor to block that bridge by IP address. meek + aims to make it much more expensive: even if you know a domain is + being used (in part) for circumvention, in order to block it have to + block something important like the Google frontend or CloudFlare + (high collateral damage). + +1. https://trac.torproject.org/projects/tor/wiki/doc/meek -- 1.7.10.4 signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] I have a group at internet archive that are interested in buying a lot of OnionPi's
Martin Kepplinger: Am 2014-06-29 08:57, schrieb Roger Dingledine: On Sat, Jun 28, 2014 at 10:11:24PM +0200, Moritz Bartl wrote: On 06/27/2014 09:44 PM, Virgil Griffith wrote: What is the current state of the art on this, and if it is ready for larger deployment want to buy about 50-100 of them. In my eyes, an access point that has a captive portal that teaches people about Tor and facilitates the download of Tor Browser etc is much better than transparent proxying. Right. Using a transparent torifying box as a client is dangerous, because your Internet Explorer or other normal browser will probably introduce surprising privacy problems compared to using Tor Browser. Using your middlebox as a firewall to prevent non-Tor traffic from transiting, i.e. to make sure you are using only Tor, is much safer but also much less sexy. what would be an approach to build that? the accesspoint would need a list of current entry nodes, which is, all public relays, right? (from the February 19th, 2014 of Tor Weekly News:) Rusty Bird announced [16] the release of corridor [17], a Tor traffic whitelisting gateway. corridor will turn a Linux system into a router that “allows only connections to Tor relays to pass through (no clearnet leaks!)”. However, unlike transparent proxying solutions, “client computers are themselves responsible for torifying their own traffic.” [16]: https://lists.torproject.org/pipermail/tor-talk/2014-February/032152.html [17]: https://github.com/rustybird/corridor -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Typos in 224-rend-spec-ng.txt
Tim: I've found a few typos in the first few sections of 224-rend-spec-ng.txt at https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spec-ng.txt Feel free to provide your fixes in the form of a patch. `git format-patch` can help crafting an email. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
isis: PS: why are we still shipping obfs2 bridges?! tl;dr: Because we have them. The protocol is known to be broken and fingerprintable. That's something we know. Not users. If BridgeDB is giving them out, then it must be that it's ok to use, right? We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
isis: We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol. Obfs3 is also broken, it's just that we haven't yet seen a DPI box do it IRL. That's news to me. Any pointers? -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
isis: We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol. Obfs3 is also broken, it's just that we haven't yet seen a DPI box do it IRL. If you want me to only hand out the holy grail, I'm never going to hand anything out. The holy grail will never exist, indeed. I fail too see why this would be a reason to continue giving out solutions that are known to be bad when they have suitable replacement. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
Matthew Finkel: I agree, and I think it's safe to assume that some nation-state adversaries do not have these capabilities yet. Users should choose obfs3 over obfs2, but if a user has a reason for requesting obfs2 then I don't think we should deny them. But aren't “we” the expert on the topic? Which reasons do you think a user might have to choose obfs2 over obfs3? Isn't it in an attacker interest to trick users into using obfs2? Should all HTTPS websites allow DES because users might have a reason to request it? Should OTR clients continue to support OTRv1 because users might a have a reason to request it [1]? Sorry, but as a fail to see good reasons, I just don't get the logic. For the Tor Browser, we stop even distributing the binaries as soon as a new version is out because we know the previous one to be insecure. Why should a broken protocol still be advertised? Why should addresses of insecure bridge still be distributed when we can just avoid them? What do users get out of retrieving obfs2 bridge addresses that they can't get when retrieving obfs3? What does the Tor Project get when misleading users? [1]: https://bugs.debian.org/725779 -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
isis: Lunar transcribed 2.9K bytes: Matthew Finkel: I agree, and I think it's safe to assume that some nation-state adversaries do not have these capabilities yet. Users should choose obfs3 over obfs2, but if a user has a reason for requesting obfs2 then I don't think we should deny them. But aren't “we” the expert on the topic? Which reasons do you think a user might have to choose obfs2 over obfs3? Isn't it in an attacker interest to trick users into using obfs2? Should all HTTPS websites allow DES because users might have a reason to request it? Should OTR clients continue to support OTRv1 because users might a have a reason to request it [1]? Sorry, but as a fail to see good reasons, I just don't get the logic. For the Tor Browser, we stop even distributing the binaries as soon as a new version is out because we know the previous one to be insecure. Why should a broken protocol still be advertised? Why should addresses of insecure bridge still be distributed when we can just avoid them? What do users get out of retrieving obfs2 bridge addresses that they can't get when retrieving obfs3? Alice's university sysadmin / corporate IT department / highschool administration / overly-conservative techie parents block tor, by protocol identification after watching Alice's tor handshake with the first hop. They block relays from the public list. Their firewall runs Bro or similar, and they're able to detect and block bridges too. [0] They see an obfs2 handshake, and they try to connect to the obfs2 IP:port using vanilla tor (without any PTs). It doesn't work. Isn't not their job to spend all day trying to figure out what that weird protocol was, and they're not savvy enough to realise that the handshake is also fingerprintable. That's where obfs2 still works just fine. But obfs3 will work just as fine. Why continue giving out obfs2 bridges? -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [android dev] probably a stupid noob question… but
CJ: … how may I add netcipher lib to an Android Studio project? I've searched on the Net, but nothing seems to match my needs :( sorry for this stupid question, but I'm a bit stuck (yes, first android app, blah)… I'm not sure there is much knowledge about Android apps amongst tor-dev subscribers. Maybe the Guardian Project's mailing list is more appropriate? https://lists.mayfirst.org/mailman/listinfo/guardian-dev -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Decentralized VOIP over Tor
ter...@safe-mail.net: I said decentralized VOIP because no central servers would be managing the communications. Any Tor node could possibly be a VOIP server. Tor is a transport network. Relays only transport data, they do not offer services other than what's needed for Tor clients to work. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] DNSSEC
merc1...@f-m.fm: Does anyone know why TOR does not use DNSSEC? The only documentation I found on the TORProject website for DNS does not actually explain how DNS works on TOR. I infer it must be TCP, as TOR can not do UDP, and I imagine that relay nodes must be the resolvers in order to resolve .onion domains. But beyond that there is no information on how it works. Seems to me that the lack of DNSSEC in TOR is a gigantic security hole. (DNS cache poisoning) See proposal 219 for the status of current efforts: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/219-expanded-dns.txt Please contribute if you can! -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] DNSSEC
merc1...@f-m.fm: On Mon, Sep 1, 2014, at 11:54, Mike Cardwell wrote: The exit nodes do the DNS requests. The client doesn't see an IP address. It connects to the Tor SOCKS interface and says, connect me to hostname example.com on port N. It doesn't look up the IP address of example.com and *then* connect to it. Hidden services don't have IP addresses and DNS resolution isn't involved in routing connections to them. So when I request to connect to example.com, that request goes all the way to the exit node, which then is supposed to do the DNS lookup? Again, this is impossible, as .onion domains would be bypassed. This is the development mailing list for Tor. Please refrain from posting more questions until you have a better understanding of the way Tor works: https://www.torproject.org/docs/documentation.html.en#UpToSpeed Everything you want to know about Tor design is available: https://gitweb.torproject.org/torspec.git -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Orbot Fails to Transparent Proxy on lge-e739
Jordan: I'm writing this not as a bug ticket: I'd like to try to get involved with fixing this issue (which is why I cc'd you, Nathan). Don't cross post. Also please use the appropriate channel for Orbot support: supp...@guardianproject.info Or if you believe this is worth raising on a developer's mailing list: https://lists.mayfirst.org/mailman/listinfo/guardian-dev -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] CGI and Hidden Services
ter...@safe-mail.net: Does CGI work the same way it does with regular websites when using it for Tor Hidden Services? Do the methods POST and GET work the same over Tor on Hidden Services? This is the mailing list about the development of Tor. Not about how to use Tor. You've already asked your question to tor-talk. That's fine, be patient. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Building TOR using Visual Studio
teor: Nick Mathewson: * Some people want to use paid versions of Visual Studio, and have paid for a version earlier than VS2013, and don't want to pay for a newer one. I sympathize with this: I've been on paid upgrade treadmills myself, and it's always tempting to save money by skipping steps in the upgrade treadmill. I've even paid for commercial compilers in my misspent youth. Are there no-cost, non-license-restricted compilers available for Windows that support C99? I assume MinGW fits: http://www.mingw.org/ MinGW is also what is used to build Tor for the Windows version of the Tor Browser (run on GNU/Linux). -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4proxy package in deb.tp.o
s7r: 2. Configured some obfs4 bridges using obfs4proxy. They work very good, however it's a little bit complicated since package obfs4proxy exists in Debian sid, but not in deb.torproject.org, so you have to add sid repo to sources.list, install obfs4proxy and then make sure you edit apt preferences or comment the sid repo from the list in order not to upgrade you entire Debian system with packages from unstable/testing branch. Received couple of emails from users wanted to deploy obfs4 bridges and were confused. Is it possible to include obfs4proxy in deb.torproject.org for Debian You should now be able to get obfs4proxy by using: deb http://deb.torproject.org/torproject.org obfs4proxy main The package should work on most Ubuntu and Debian versions. It is available for amd64 and i386. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4proxy package in deb.tp.o
s7r: Thank you! I can see the package in the main pool, but wanted to ask something: any reason why this is not available using: deb http://deb.torproject.org/torproject.org `$lsb_release -c` main Basically the same where Tor, tor-arm and obfsproxy are available too? Because obfs4proxy is in Go and statically linked. The same package can be used on many distributions. It could not be built on every suite though, as they don't have the needed build dependencies. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Producing automated screencasts for Tor Browser
Hi! Karsten Loesing: 2. Install Sikuli (http://www.sikuli.org/; thanks for Lunar for the suggestion!) either directly on these machines or on the virtual machine host or on a separate host in the same network. 3. Write a Sikuli script for each operating system and language, probably re-using large parts, to make all the necessary steps to download, verify, and run Tor Browser. This script may include steps for preparing the system by changing its language and for cleaning up afterwards. Ideally, this script can easily be maintained whenever Tor Browser changes. I had a quick chat with intrigeri based on their experience with using Sikuli to automate Tails testing. He told me they had issues with the OCR system and that they opted for having captured images everywhere in the end. Having to update images on new Debian releases is a bit of a pain but seems to be a manageable exercice. It saddens me a bit because having working OCR would be super awesome in that the same script could be used for multiple languages by looking at the actual software translation catalogs… So it might be worth experimenting a little bit again. 4. Record audio snippets in the various language that explain the steps that will later be performed in the screencast. Either include these as part of the Sikuli script, or put them together separately and add them to the recording later. I think it's worth experimenting a little bit with starting the audio tracks as part of the script. It would make it easier to put synchronisation point in the script, and it might smooth out timings in different languages more nicely. Are there scripts (as in a textual description of the scenes and voice over) already written down somewhere? -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [FWD: Re: Apple developer account + codesigning]
Mike Perry: > We want to do this for MacOSX as well. Does anyone happen to know if we can > use otool in some way to remove these LC_CODE_SIGNATURE sections easily, > and get the same exact binary as before signing? I don't know if it helps in the case but problem can also be approached the other way around: if Tor distributes the signatures, is there I way to stick them in the binaries I just built so that the signature is valid and the bytes are the same as the ones distributed by Tor. -- Lunar <lu...@torproject.org> signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] UX tag
Nima Fatemi: > May I encourage you to add "UX" tag (keyword) to the tickets you're > filing or working on that are related to usability in any ways? > > This is to get a sense of how many tickets and what workload is related > to usability in tor-related products. So I want to humbly ask you to use > the tag regardless of the help you may or may not need for that ticket. Tor Browser folks have been tagging tickets with tbb-usability: https://trac.torproject.org/projects/tor/tags/tbb-usability Do you want an extra tag for those? -- Lunar <lu...@torproject.org> signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] TUF Repository for Tor Browser
ban...@openmailbox.org: > Rehash of previous discussions on the topic: See #3994. > The major reasons why TBB is not in the Debian repository: > > * The reproducible build system depends on a static binary image of (then > Ubuntu) which runs counter to Debian policy. It's likely not a problem if built from source. > * TBB is based on Firefox ESR and not Iceweasel which also runs into the "no > duplicate source package" policy of Debian. I've discussed this with Debian security team a while ago and they are ok with duplicate source code as long as the updates are done in a timely manner. Tor Browser has a good record, so it's fine. > Reasons for unavailability of TBB .deb in the Tor Project APT repository: > > * The break neck speed of development A regular build could probably be automated via Jenkins. > * Its not easily packaged and the amount of effort needed is better spent > otherwise. As far as I understand, the main issue is that Tor Browser only works with a single (pre-populated) profile which can't be shared amongst multiple users. Once this is solved, and Tor Browser can be installed system-wide, getting a package should not be very hard. Hope that helps, -- Lunar <lu...@torproject.org> signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] TUF Repository for Tor Browser
ban...@openmailbox.org: > Thanks Lunar for the update. I thought the effort to upstream TBB had > completely stalled because there was no activity on #3994. Good to know its > still alive. > > Is there somewhere I could look to track progress besides that ticket? Don't misunderstand me. To the best of my knowledge, no one is working on this at the moment. I was just sharing my picture of the situation. -- Lunar <lu...@torproject.org> signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposals should have reviews. Let's make sure that happens. Here's a schedule.
Spencer: > >Nick Mathewson: > >proposals sit around for a long time > > > > Is there a summarized visualization of these, or is it sifting through > emails and tickets? Proposals are all kept in the “torspec” Git repository: https://gitweb.torproject.org/torspec.git/tree/proposals Once in a while Nick updates the status document giving a general overview: https://gitweb.torproject.org/torspec.git/plain/proposals/proposal-status.txt -- Lunar <lu...@torproject.org> signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GSoC'16 proposal: the Torprinter project (a Panopticlick-like website)
Pierre Laperdrix: > Thanks for the valuable feedback! > It would be great to have the features that you cite into the website. > For the first version, my point of view is to mainly focus on the added > value for developers which is to add/remove tests easily and get the > relevant data as easily as possible for them. With that, they can make > decisions on what to do next inside the Tor browser. For subsequent > versions, focusing on users could be really interesting if the rest > proves to be solid and stable. Makes sense. My main worry is that some users will be using it, even if it's aimed at developers, and that quickly we will find ourselves having to repeat over and over “we know about this issue, the fix is more complicated than it seems, we're on it, but if you really worry just switch the security slider to high”. As long as you have that in mind, and there's a basic way to display messages for users—this could just be a link to a wiki page—I think it'll be ok to add fancy stuff later. > For the internationalization, the framework that I plan to use (either > Play or Django) supports it through templating. This means that anyone > can contribute to the translation without writing a line of HTML. The > main file will be in English and I'll probably do the one in French at > the same time. One contributor who wants to help will just have to take > the English file and translate each line without having to find > scattered hardcoded strings through different HTML files. Great! :) As long as it's properly i18nized, localizations can come later. Although doing a first localization while i18ning might help you spot missing strings. -- Lunar <lu...@torproject.org> signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
George Kadianakis: > this is an experimental mail meant to address legitimate usability concerns > with the size of onion addresses after proposal 224 gets implemented. It's > meant for discussion and it's far from a full blown proposal. Taking a step back here, I believe the size of the address to be a really minor usability problem. IPv6 adressses are 128 bits long, and plenty of people in this world now access content via IPv6. It's not a usability problem because they use a naming—as opposed to addressing—scheme to learn about the appropriate IPv6 address. While I do think we should think of nicer representation for the new addresses than base32, and we should adress that, working on a naming system sounds like an easier way out to improve onion services usability than asking people to remember random addresses (be them 16 or 52 characters-long). (I now plenty of people who type “riseup” in the Google search bar of their browser to access their mailbox… They don't even want to/can't remember an URL. Hardly a chance they will remember an onion address, whatever its size.) Maybe it would be worthwhile to ask the UX team for input on the topic? -- Lunar <lu...@torproject.org> signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] "old style" hidden services after Prop224
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 s7r: > So, my opinion is to deprecate v2 entirely after a sane and > reasonable transition period. Apologies to whom this will create > headaches - technologically everything can be adjusted to v3 hidden > services, it's just some work required -- it's not going to be fun > but it's the clean way for the longer term future. For what its worth, we now have a social contract [1] that can help us evaluate such decisions. In any cases, v2 onion services are broken in several aspects. I think this is good be advertised even more (point 5, being honest about limits). The outdated crypto primitives are not my main concerns. I think the fact that an HSDir can learn onion service addresses, refuse to serve them, or track connections is really bad. Once v3 onion services are deployed, I believe the current set of problems in v2 conflict with social contract point 6, “we will never intentionally harm our users”. Having them continue to use a technology that doesn't deliver its initial promises when a better option is available feels like intentional harm to me. YMMV, obviously, but I think this is a good framework for having a discussion. (Should we move this to -project? Not sure.) [1]: https://blog.torproject.org/blog/tor-social-contract [2]: https://blog.torproject.org/blog/hidden-services-need-some-love See “Attacks by Hidden Service Directory Servers” - -- Lunar <lu...@torproject.org> -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX2CPzAAoJEEAsIlA9Nuk2gB8P/3SsrOeKNGG0jIB1kyED2LTu Nf47izPICYE+ekHljlUxnmMl7QgpQGAsvzVYQ9CXoPXn09oA7TyMlyWx0DSrUf6G cLIGoDVljnHvzAjNADtc4k2vEvT5gmIeIk19OwVepvCnjwGbYb+yDJthQRJ0Tf8V FZtwkDAEdLwfDpJIfUrgr5quPMLij+EjCDhzfuW7nv3JrHUcEe+AQogpFYjT/roX 4Zauj+T6OvAYMKgOzmpu36uoihWF4w/N6ITdBcAjFcZQXCKVenNAUH5TIXxshheb 3rVm92MnzhbMf3vGVhJWbrWGEFS7hhcshHSVIZC4KB4T5Pm8axr9XJ5X6OriS40J LK22xht/yEcXxhCeVO3O8rg3Tvwszw/Dtqv3/6ArTuZ4YXxnbC3HR4S60ypYbVr+ yi/0Id+Coszyu/NYOTqyTP50DNctpveqZ4zalfCPKNFnXddsvPTN5TQNFyuFG/o+ onoPOaPmAVtKOEXn1dTiAc3ys4ZGSdLFIcO9M3y7bxal0rdqb7nfTBundHEX8+5R Ah+IE9xRkEInRDEIYWCckVZ9FWCu5ycrM17KG2fenCvdjX84EoZSFPPAN/dDrKqB YZZFdLsR27w9N9sMcgGGNjxZ1YrEZQO40vvj7uSpqqm/mrGkw8aWroYB/v+cmv1F 5apnB6W1drX+pBOMDYd8 =9Ya/ -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Browser downloads and updates graphs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Karsten Loesing: >> If you feel that's interesting enough, would it be possible to >> also add the number of download of cryptographic signatures to >> the graph? > > Sure, added. Thanks! These are interesting datapoints regarding the “but nobody ever checks the signature” that I hear now and then. > That is something I'd like to add very soon, but I'd first want to > discuss whether the absolute numbers make sense before breaking > them down by operating system, release channel, and locale. > > I'll bring the database with me to Seattle. Maybe we can sit down > and run some queries on it together? This was fun last weekend > together with Georg and Nicolas, and it would for sure be fun with > you and other interested folks in Seattle. Sure! :) If we're going to get such graphs running as a way to measure the amount of Tor Browser users, I wonder if we should not also try to work with Tails' people to add their boot statistics, and maybe other projects who include Tor Browser without using the automated update mechanism. - -- Lunar <lu...@torproject.org> -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX4VnNAAoJEEAsIlA9Nuk2LBIP/i1+t1zCV3pRS4BnQI57w+/Z oW5mj7Aorz30mkXmLZYgR+R6/1MOycEdATEGNJro8ZPqee6Xv094ml4nEFv38dlh exrXn8AeQN1nxnnV6w1hO/rECBG7FJU7w1qXBmHG+UrqP1K4pXRjKhAbCZnFTTfr 2GBiLfaRDqMWHN6YgB/q2QgTk/uPlwpXfxJr2mHJKiJvJFTVGt0VnMm5TFSqDdEp LbY/S8A8683xyW+RxHZXl3FM4cZL8kOPRb4MYU+QykP+d2RTf4AbOwygNEHD0973 fhgGkJaHp7Tf8y0Gj2gTBD/FLz9vXy8/UjnCos+yf7FnjFunpP1rqmt4AHIVO1rF b8pERRvdvEmRnVQZ52EGydfExsGCwx8Z2VKqhXwtBt94pKhb+Hr3wXCl2MB8TeaY GrSty+fNDkxw2pl42axRT4I7E0iskso0g597JImDHfdTBy8vfH/hCP3kDk9AAzqe VNxNTRWSQ2wiGhgH0S/AqOIrPHhpzQ/3FJf6ziNo3CsspvJ8i/APGg2lWxz6PQNY jHSQhlc0oxMUFj5VonWWsJ+YPgqIPxVaa7gr8gnXcGmtZtQXDJ5a955+amKOImxS 2L26MDpHh7LplQL5xQvaMetgT7uhsMeJvjbM7E/q5/PjVHAfADQs2+KfMkDsGHfA cMZCuV4J7PkE4C3AEouI =8Ht0 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Browser downloads and updates graphs
Karsten Loesing: > On 11/09/16 18:13, Georg Koppen wrote: >> Here are the graphs showing initial downloads, update pings and >> update requests over time: > >> https://people.torproject.org/~karsten/volatile/torbrowser-annotated-2016-09-11.pdf > >> > Here's > > the same graph with more data, more request types, and of course a > lot more shininess: > > https://tor-metrics.shinyapps.io/webstats/ > > Note that this is just a prototype that will go away in the future > without notice. But if enough people like it we might run our own > Shiny Server at some point in the future. Enjoy! (And thanks, > Isabela, for suggesting Shiny!) If you feel that's interesting enough, would it be possible to also add the number of download of cryptographic signatures to the graph? I also would love to see a breakdown by operating systems if you consider it a reasonable thing to do. Seeing these graphs really made my day, I had been hoping for them for a long time (#10675 which maybe should be closed). Thanks a lot! Thanks, -- Lunar <lu...@torproject.org> signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519
Hi! Sorry to be late to the party. I still haven't seen UX concerns fully addressed, and I think we should not create a specification that will make the life of our users harder if we can avoid it. s7r: > George Kadianakis wrote: > > I have a more mature torspec branch now for your eyes and only. Please > > see branch `prop224_client_auth_4` in my torspec repo: > > > > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4 > > > > The changes are based on the feedback and discussion on this thread. > > I would like to state, since I seen it in older posts on this thread, > that I dislike the idea of generating at client side low entropy ed25519 > key pairs based on simple passwords. It may sound simple and good from > UX point of view, but we are decreasing the security of a very secure > auth scheme with it and enabling an over-the-hand practice that keys > come from client to HS and not vice-versa. I hope we can find a balance between “a very secure auth scheme” that will be too cumbersome to use for most users and “a secure and usable auth scheme”. I've been hoping we could get a nice UI in Tor Browser to access authenticated onion services for a while now (#8000). The difficult part UX-wise is that there is no way to differentiate between an onion service that is either non-existant, temporary unavailable or authenticated. (But it's good for security, so let's keep things that way.) How are users expected to give enter the private key in Tor Browser? Does the key have to be saved on disk? What should I have to do to browse an authenticated onion service when running under Tails without persistence enabled? I don't see how to streamline support for an amnesic system if I have to generate a unique keypair that I need to give to the onion service owner beforehand. Should we draw inspiration from miniLock? https://minilock.io/files/HOPEX.pdf (see slide 35) If I try to think of my experience as an admin, I see several cases where it would be much easier to give authentication token to users myself. User story: Elena has set up an Etherpad instance on her private server. She generates a handful of access codes before going to meet the newly formed copwatch chapter. After the end of the meeting, she can give out a piece of paper to all attendees so they can access the minutes and write up reports together in the future. You really don't want to have all attendees bring their computer or require them to meet with Elena at a later time. Hope that helps, -- Lunar <lu...@torproject.org> signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
