[tor-dev] [RELEASE] Torsocks 2.2.0 stable

[David Goulet]

Greetings!

This is the release of Torsocks 2.2.0 stable version. One of the major change
between this version and the previous RC1 is that we added a check for Apple's
System Integrity Protection (a.k.a the next step for DRM protection in OS X
:P). This prevents torsocks to work for any binaries located in:

/usr/* (with an exception of /usr/local/*),
/System/*
/sbin/*
/bin/*

A note maybe to the packagers, the tarball is now compressed with xz. Apart
from that, mostly bug and portability fixes. Here is the ChangeLog:

2016-10-18 torsocks 2.2.0
* Use xz for dist tarball now
* Remove TODO as we use the bugtracker for those
* execve: only include xattr.h for Linux
* syscall: sched_getaffinity is only Linux
* close: Prefix debug messages with [close]
* Add check for Apple's System Integrity Protection.
* Quote the non-zero length check of $getcap.
* compat: Fix bad use of defined macro for OS X
* Use AC_USE_SYSTEM_EXTENSIONS to try to use POSIX extensions
* log: Fix whitespace in log.h
* syscall: OS X doesn't support sched_getaffinity()
* Fix memcpy buffer overrun in gethostbyaddr()
* Fix memcpy() buffer overrun in gethostbyname()
* Fix typo: catched -> caught
* syscall: Whitelist sched_getaffinity(2)

Tarball:
https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0.tar.xz
http://sbe5fi5cka5l3fqe.onion/~dgoulet/torsocks/torsocks-2.2.0.tar.xz
Sig:
https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0.tar.xz.asc
http://sbe5fi5cka5l3fqe.onion/~dgoulet/torsocks/torsocks-2.2.0.tar.xz.asc

Please let us know if anything went wrong or any bugs!
https://trac.torproject.org

Huge thanks to everyone who contributed by reporting issues, making patches
and testing!

Cheers!
David


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [prop269] Further changes to the hybrid handshake proposal (and NTor)

[John M. Schanck]

Hi BU,

bustao...@cryptolounge.net wrote:
> Perhaps my question is related to Michaels question, but above removing A, X,
> Y and server ID leaves the possibility of a person-in-the-middle who by
> manipulating public keys (resend 2A, instead of A, 2X instead of X, 2Y instead
> of Y) can force two (non-matching) session share the same value denoted
> SECRET,
> Does including these public values in the value SALT take care of such
> "attacks".

For the version in which A, X, Y, and ID were all in SALT, see [1]
for a proof of security (tldr; yes putting these values in SALT instead
of in the extractor secret input field prevents the attack you mention).

The new version drops Y from SALT (A, X, and server ID are still
included), but that's irrelevant because we've stopped relying on SALT
to bind the derived keys to the transcript. In the new version the
server response includes a MAC computed over the entire transcript.
Non-matching sessions that compute the same session key will abort (with
overwhelming probability).

The proof from [1] goes through with a small modification to Game 5
of Lemma 4.3: show 'auth' is uniformly random; use PRF property to
replace HMAC keyed by 'auth' with a random function; mention that 
matching MAC tags imply matching sessions or, with negl. probability,
a collision in the random function.

> RFC5869 Section 3.3 To Skip or not to Skip addresses that part, but I can't
> conciliate your statement that the server can choose its public material in
> a way to bias the entropy extractor. Or is this simply the same problem viewed
> from a different angle?

RFC5869 Section 3.3 is about skipping the call to HKDF-Extract... we
don't do that. See [2] section 3 for more details on exactly what has
changed from ntor.

Cheers,
John

[1] 
https://www.degruyter.com/view/j/popets.2016.2016.issue-4/popets-2016-0037/popets-2016-0037.xml
[2] 
https://gitweb.torproject.org/torspec.git/tree/proposals/269-hybrid-handshake.txt
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Note on my GPG key update

[Nick Mathewson]

On Tue, Oct 18, 2016 at 8:48 AM, Nick Mathewson  wrote:
> Hi! Please see
>
> https://people.torproject.org/~nickm/key-transition-statement-2.txt

Whoops!  That URL should be:

 https://people.torproject.org/~nickm/key-transition-statement-2.txt.asc

> for information on my updated GPG key.  Thanks!
>
> (I wouldn't ordinarily send this here, but this new key signs the Tor
> source and tags these days, so it's a good idea to make sure people
> know about it.  The most recent releases were signed with both my old
> key and my new key: this is the last time that I'm planning to be
> doing that, however, since it seemed to confuse a lot of software.)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Note on my GPG key update

[Nick Mathewson]

Hi! Please see

https://people.torproject.org/~nickm/key-transition-statement-2.txt

for information on my updated GPG key.  Thanks!

(I wouldn't ordinarily send this here, but this new key signs the Tor
source and tags these days, so it's a good idea to make sure people
know about it.  The most recent releases were signed with both my old
key and my new key: this is the last time that I'm planning to be
doing that, however, since it seemed to confuse a lot of software.)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [prop269] Further changes to the hybrid handshake proposal (and NTor)

[bustaoglu]

Quoting isis agora lovecruft :


Hello,

After discussion with John Schanck and Trevor Perrin over the last month,
we've decided to make some alterations to the specification for hybrid
handshakes in Tor proposal #269.

It seems that John, Trevor, and I are mostly in agreement about most
of the construction.

First, I'll try to summarise a list of changes and the reasoning/concerns
which provoked them.  For what it's worth, these concerns mostly involve
highly theoretical problems surrounding whether we model a hash function with
a random oracle or try to make some stronger claims to its properties, and
aren't due to any real world attacks (assuming that hash functions do what
you'd expect them to do and aren't something crazy like a NULL op or a
pineapple slicing machine).

Changes:

 1. [NTOR] Inputs to HKDF-extract(SALT, SECRET) which are not secret
(e.g. server identity ID, and public keys A, X, Y) are now removed from
SECRET and instead placed in the SALT.

Reasoning: *Only* secret data should be placed into the HKDF extractor,
and public data should not be mixed into whatever entropic material is
used for key generation.  This eliminates a theoretical attack in which
the server chooses its public material in such a way as to bias the
entropy extraction.  This isn't reasonably assumed to be possible in a
"hash functions aren't probablistically pineapple slicers" world.



Hi Isis,

Perhaps my question is related to Michaels question, but above removing A, X,
Y and server ID leaves the possibility of a person-in-the-middle who by
manipulating public keys (resend 2A, instead of A, 2X instead of X, 2Y instead
of Y) can force two (non-matching) session share the same value  
denoted SECRET,
Does including these public values in the value SALT take care of such  
"attacks".

RFC5869 Section 3.3 To Skip or not to Skip addresses that part, but I can't
conciliate your statement that the server can choose its public material in
a way to bias the entropy extractor. Or is this simply the same problem viewed
from a different angle?

Best

BU

--
http://cryptolounge.net

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 273: Exit relay pinning for web services

[Georg Koppen]

Philipp Winter:

[snip]

> 2. Design
> 
> 2.1 Overview
> 
>A simple analogy helps in explaining the concept behind exit relay
>pinning: HTTP Public Key Pinning (HPKP) allows web servers to express
>that browsers should pin certificates for a given time interval.
>Similarly, exit relay pinning (ERP) allows web servers to express
>that Tor Browser should prefer a predefined set of exit relays.  This
>makes it harder for malicious exit relays to be selected as last hop
>for a given website.
> 
>Web servers advertise support for ERP in a new HTTP header that
>points to an ERP policy.  This policy contains one or more exit
>relays, and is signed by the respective relay's master identity key.
>Once Tor Browser obtained a website's ERP policy, it will try to
>select the site's preferred exit relays for subsequent connections.

I'd like to pick up a point Tom briefly mentioned. The intended behavior
seems at first glance to violate Tor Browser's Tor circuit and HTTP
connection unlinkability requirement
(https://www.torproject.org/projects/torbrowser/design/#identifier-linkability)
which states:

"""
Tor circuits and HTTP connections from a third party in one URL bar
origin MUST NOT be reused for that same third party in another URL bar
origin.
"""

One could try to argue "well, we just make sure then that the middle
relays are different depending on the URL bar domain" but I'd like to
see an analysis if that actually helps. (fwiw: we could actually be fine
with respect to the HTTP connection linkability but that needs
double-checking at any rate)

Moreover, I'd like to see an analysis about what exactly an attacker
learns with your scheme if you take into account that websites are
comprised of a mix of resources that are fetched from domains which
might or might not have an ERP. Plus, I'd like to see some pondering
about the usability fallout if suddenly not all resources are loaded
over the same circuit anymore (because only some of the third party
domains have ERP while others do not). My gut feeling is that it would
break quite some websites. (it already broke things back then when we
isolated to the FQDN, see below)

>The following subsections discuss this mechanism in greater detail.
> 
> 2.2 Exit relay pinning header
> 
>Web servers support ERP by advertising it in the "Tor-Exit-Pins" HTTP
>header.  The header contains two directives, "url" and "max-age":
> 
>  Tor-Exit-Pins: url="https://example.com/pins.txt;; max-age=2678400
> 
>The "url" directive points to the full policy, which MUST be HTTPS.

I stumbled over this one: maybe "which MUST be served over HTTPS"?

>o Is a domain-level pinning granularity sufficient?

I think we should definitely start with that one. See #15933 (especially
comment 6) for some usability issues we run into when trying to isolate
to the FQDN.

>o Should we use the Ed25519 master or signing key?
> 
>o Can cached ERP policies survive a Tor Browser restart?  After all,
>  we are not supposed to write to disk, and ERP policies are
>  basically like a browsing history.

That is tricky. Ideally not but on the other hand this is a security
measure that loses much of its potential if not available over more than
one session. Those policies would need to get cleared if a user requests
a new identity at least. FWIW: Firefox is clearing HSTS state after a
Private Browsing Mode session is closed. However, Tor Browser is using
permanent Private Browsing Mode which does not do this currently (see:
#18589).

Georg



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] strange ARM results

[Rob van der Hoeven]

On Mon, 2016-10-17 at 09:29 -0700, Damian Johnson wrote:
> Hi Rob. I suppose it's possible arm is having a refresh issue but
> can't say there's a known bug around that. To double check try running
> tor-prompt and giving it 'GETINFO circuit-status'...

Hi Damian,

If I run tor-prompt and ARM side by side, the tor-prompt results are
updated when I do a GETINFO circuit-status. The ARM circuits page only
updates after a restart.

Maybe my system/configuration has something to do with the problem. I
run my Tor proxy (and ARM) on an Allwinner A20 ARM system with Debian
Jessie as OS. Debian does not use the latests versions of software...

> 
> https://stem.torproject.org/tutorials/down_the_rabbit_hole.html
> 
> This is the command arm uses to get the circuit information.
> 
> > ARM version 1.4.5 seems to be the latest version. I checked out NYX but
> > failed to get it running (Unable to load nyx's internal configurations:
> > [Errno 21] Is a directory: '/home/rob/src/nyx/nyx/settings')
> 
> Interesting! How did you attempt to run it? Nyx is under active
> development so quite possible I buggered something up but can't say
> I've seen this one. Please provide the exact commands you ran - for
> instance...
> 
> % git clone http://dccbbv6cooddgcrq.onion/nyx.git
> % cd nyx
> % ./run_nyx

I did:

git clone https://git.torproject.org/nyx.git
cd nyx
./run_nyx

Regards,
Rob
https://hoevenstein.nl


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Building Torsocks for Armv7 - Build error

[Luca Bertoni]

Goodmorning,
I hope this is the correct section where to ask about building Torsocks. If 
that is the wrong place I apoligize and ask for a reference that can help me.
So, I am trying to build torsocks for my armv7 smartphone. What I'm talking 
about is a cross-compilation, done using autools.
After I have generated the configure script executing autogen.sh I configure 
torsocks using "./configure --host=armv7" and that doesn't raise errors.
When I try to build it (using gnu-make) I get an error:
../src/lib/.libs/libtorsocks.a(log.o):(.data+0x0): multiple definition of 
`tsocks_loglevel'
test_connect.o:(.data+0x0): first defined here
I know what the error means but I can not figure out if I'm doing something 
wrong (that is the first time I cross-compile something so I am a newbie) or if 
there is a bug in the software. If it is a bug in the software I would like to 
submit it
I downloaded torsocks from github (latest tag/release) and I am trying to build 
it using Debian 8.6 and gcc (Debian 4.9.2-10) 4.9.2.

Thanks,
Luca.



Luca Bertoni___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev