Re: [tor-dev] Onion Services and NAT Punching

2015-10-26 Thread Alec Muffett 

> On Oct 26, 2015, at 11:34, Alec Muffett  wrote:
>> Of course. All the cases where you set up a hidden service
>> exactly because your host is behing a NAT.
>> Like the webcam raspi I'm just booting up.
> 
> We run our tor daemons in a enclave network which can only connect outbound 
> to the Internet, or backwards into infrastructure.

Also, it's probably wise to point out that NAT-punching (and/or SOCKS-punching 
outbound) reduces cost of HS adoption for organisations that don't want to 
rejig their network architecture to permit "yet another listener"; it's an 
attractive proposition to say "it only connects outbound and rendezvouses 
(sic?) in the middle of the tor cloud" #ohThatsOkayThenNoFirewallChanges



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onion Services and NAT Punching

2015-10-26 Thread Alec Muffett 

> On Oct 1, 2015, at 06:15, Andreas Krey  wrote:
> 
>> Are there any use cases that:
>> * need NAT punching,
>> * don't need service location anonymity, and
>> * would benefit from lower latency?
> 
> Of course. All the cases where you set up a hidden service
> exactly because your host is behing a NAT.
> Like the webcam raspi I'm just booting up.

And like us.  We run our tor daemons in a enclave network which can only 
connect outbound to the Internet, or backwards into infrastructure.

-a



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] A layered transport

2015-10-26 Thread David Stainton 
wait... what?
What is this front tier?
Why would we want to use cryptographic protocols for bridges that
violate the end to end principal?


On Mon, Oct 26, 2015 at 8:44 AM, Da Feng  wrote:
> Hi:
>I've discovered that the GFW normally doesn't block https
> protocols. We can use a https front tier to distribute connections to
> actual bridges. The front tier encrypts an internal address identifier
> with its private key (no matching public key or public algorithm) and
> returns to user the encrypted identifier, part of which also includes
> the user's chosen password. Then when submitting requests, the user
> encrypt again with his password the items such as his timestamp,
> broswer headers. The request line to https server is no different from
> an ordinary one and include both the user encrypted item and front
> tier encrypted item. After the connection is established, data is
> relayed inside https between bridge and user.
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] A layered transport

2015-10-26 Thread Yawning Angel 
On Mon, 26 Oct 2015 15:44:59 +0800
Da Feng  wrote:
> Hi:
>I've discovered that the GFW normally doesn't block https
> protocols. We can use a https front tier to distribute connections to
> actual bridges. The front tier encrypts an internal address identifier
> with its private key (no matching public key or public algorithm) and
> returns to user the encrypted identifier, part of which also includes
> the user's chosen password. Then when submitting requests, the user
> encrypt again with his password the items such as his timestamp,
> broswer headers. The request line to https server is no different from
> an ordinary one and include both the user encrypted item and front
> tier encrypted item. After the connection is established, data is
> relayed inside https between bridge and user.

So... meek (https://trac.torproject.org/projects/tor/wiki/doc/meek),
the basis of which will probably also be used for bridge distribution
purposes in the future.

Regards,

-- 
Yawning Angel


pgpYXv2foZmjQ.pgp
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] [FWD: Re: Apple developer account + codesigning]

2015-10-26 Thread teor 

On 27 Oct 2015, at 05:41, Conrad Kramer  wrote:

>> On Oct 26, 2015, at 11:22 AM, Spencer  wrote:
>> 
>> Hi,
>> 
>>> Conrad Kramer:
>>> All resources in a bundle (e.g. an app or framework) are
>>> signed and the signatures are stored in a file named "CodeResources”:
>> 
>> Then what is in 'CodeSignature', Apple's signing stuff?
> 
> The `_CodeSignature` folder currently only contains the `CodeResources` file.
> The `CodeResources` file is simple XML.
> 
> The executables have their own signature in the `LC_CODE_SIGNATURE` load
> command in the Mach-O binary.

Reproducible builds will be much easier if the executable signatures are also 
placed in a separate file, rather than modifying the executable.

I'm guessing there's no option for detached executable signatures?

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
___
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]

2015-10-26 Thread Conrad Kramer 
> On Oct 26, 2015, at 11:22 AM, Spencer  wrote:
> 
> Hi,
> 
>> Conrad Kramer:
>> All resources in a bundle (e.g. an app or framework) are
>> signed and the signatures are stored in a file named "CodeResources”:
> 
> Then what is in 'CodeSignature', Apple's signing stuff?

The `_CodeSignature` folder currently only contains the `CodeResources` file.
The `CodeResources` file is simple XML.

The executables have their own signature in the `LC_CODE_SIGNATURE` load
command in the Mach-O binary.


Conrad


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Tor browser for other Projects

2015-10-26 Thread salutarydiacritical23 
Hello good people of Tor. As you know, your client side applications 
like Tor browser are unmatched by anything out there. They are the 
natural choice for other anonymous networks. Freenet is considering ways 
to interface with Tor browser for better privacy.


Disclaimer: I am not an official spokesperson for them.

I am testing the waters first before filing tickets on trac.

My idea is for Tor browser to include the FoxyProxy for redirecting 
browser requests to proxies based on URL patterns. Optionally there's 
color indicators for every proxy so users know what network they are 
visiting. You can add rules to block LAN accesses to keep users safe 
from misbehaving JavaScript. Rules can be added for I2P URLs too.


You'll need to disable the ads in the original addon but the code is 
DFSG compliant.


Like the transports, your client side applications are a new area for 
collaboration beyond your project. What do you say?



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

[tor-dev] [FWD: Re: Apple developer account + codesigning]

2015-10-26 Thread Mike Perry 
Here is some info about OSX codesigning, courtesy of Mike Tigas. It
sounds like undoing the codesigning to verify build (and signing
machine) integrity will be tricky. If anyone has more info on how to do
that, it would be appreciated.

- Forwarded message from Mike Tigas  -

Date: Fri, 10 Jul 2015 01:29:02 -0400
From: Mike Tigas 
To: Mike Perry 
Subject: Re: Apple developer account + codesigning

Hey Mike,

Cool seeing y'all at that CPJ thing briefly. Yeah, that account is what
you'll need to get the Apple-signed certs that let you codesign an app &
allow it to launch unimpeded -- regardless of App Store or not. Used to
be separate accounts for Mac vs iOS, but looks like it's just one
account for everything Apple. (More info in the middle below on how to
get the cert you need, etc.)



On another open-source thing I work on , we
have a cross-platform JRuby program that we turn into a .app for Mac. We
avoid the XCode IDE altogether (using a tool called `jarbundler` that
turns our jar into a Mac .app bundle for us) and use the command-line
"codesign" tool that comes with MacOSX or XCode (can't remember which).

The invocation is basically like:

codesign -f -s 'Developer ID Application: Mike Tigas (68QUP6KP2C)'
/path/to/Foo.app

Where the `-s` argument is the ID of the certificate you end up with
from Apple -- see my comment here about "For production builds...":


https://github.com/tabulapdf/tabula/blob/fe6b105ca4f84ea64975d8ddc876dce8d14b62a1/build.xml#L45-65

Once you have your Apple Developer account, link 3 in that comment is
where you'll get your cert. There's a little wizard for it that walks
you through it. (You want to be in Mac Apps -> Certificates -> All,
click + to add a certificate, and you want a Production -> Developer ID,
for an Application.)

In our case we had to manually sign another OSX framework (Java) that we
bundled with the app, so there's two invocations of the `codesign`
command. We previously didn't do that (in
https://github.com/tabulapdf/tabula/blob/c21b27c867ecdb578f97667310ea8b21e0751a68/build.xml#L45-59
), instead invoking `codesign` with the `--deep` flag, which tries to
recursively sign all executable binaries inside the target (but there's
some peculiarity with the Java OSX framework that prevented us from
doing it). So just throwing that out there as another option to try. If
this is for TBB or something else with a bunch of binaries inside,
you'll have to keep this in mind.

I've also discovered that this is a bitch to test, since once you've
bypassed codesigning to open an app (doing right-click and open instead
of double-clicking shows a prompt that allows a user to bypass the
warning https://support.apple.com/en-us/HT202491 ), the app's
whitelisted on your system. So I've historically messed up quite a few
releases by signing with the wrong key, missing some bundled framework,
etc, since my own work opens up fine on my own computer.



I remember us vaguely talking about reproducible builds and
verification, too. Guessing this ties in to the "removing signatures"
part of what you said? Of course anything that happens during and after
a codesign isn't reproducible for other users, but here are some notes
about what `codesign` and the App Store do to built apps, particularly
on iOS (but probably applicable to OSX too).
https://github.com/OnionBrowser/iOS-OnionBrowser/issues/58
https://github.com/WhisperSystems/Signal-iOS/issues/641#issuecomment-78202740

Essentially, codesign only touches executable binaries in the .app (see
that second link for info on how the binary's segments get moved around)
and also adds an SC_Info directory for codesign/DRM metadata. For App
Store apps, only the SC_Info gets modified for different users for DRM.
That makes it possible to actually verify an App Store app's integrity
by removing that directory to check hashes --
https://github.com/OnionBrowser/iOS-OnionBrowser/releases/tag/v1.5.11 --
but you won't have this problem since you're not gonna go that route.

The design (per that comment) doesn't seem to allow reversing the
signing process easily due to DRM encryption of parts of the binary --
though I'm not clear on which parts are due to `codesign` locally versus
magic that Apple performs on App Store-submitted applications. If the
`codesign` by itself doesn't encrypt the binary (i.e. if it just
rearranges the binary's segments & adds metadata & creates the
metadata/DRM directory), it might be possible to reverse it. Could be
worth someone exploring segment sizes/positions with `size` and `otool`
http://www.objc.io/issues/6-build-tools/mach-o-executables/ to determine
this for real.



Ah holy shit, that is a LOT of words. But hope that helps and isn't too
overwhelming. That's just about everything I know about this off the top
of my head.

Let me know if something isn't clear or if you run into any issues with
the Apple account or something

Re: [tor-dev] A layered transport

2015-10-26 Thread David Fifield 
On Mon, Oct 26, 2015 at 03:44:59PM +0800, Da Feng wrote:
> Hi:
>I've discovered that the GFW normally doesn't block https
> protocols. We can use a https front tier to distribute connections to
> actual bridges.

This is a good idea. HTTPS is a good cover protocol.

> The front tier encrypts an internal address identifier with its
> private key (no matching public key or public algorithm) and returns
> to user the encrypted identifier, part of which also includes the
> user's chosen password. Then when submitting requests, the user
> encrypt again with his password the items such as his timestamp,
> broswer headers.

If I understand this correctly, this is a defense against active
probing. You are saying that every HTTPS bridge has a password, and the
client must provide the correct password in order to use the bridge.
(Like ScrambleSuit or obfs4.) If the GFW tries to connect to the bridge,
it does not know the password, and therefore it cannot use the bridge.

> The request line to https server is no different from an ordinary one
> and include both the user encrypted item and front tier encrypted
> item. After the connection is established, data is relayed inside
> https between bridge and user.

You can already do something like this, except for the active probing
defense, using a PHP script and Tor Browser. First install this file on
an HTTP server:

https://gitweb.torproject.org/pluggable-transports/meek.git/tree/php/index.php

(Let's say it is installed at https://example.com/meek/index.php.) Then,
in the Tor Browser bridge configuration, enter the bridge line:

meek 0.0.2.0:1 url=https://example.com/meek/index.php

See "What to do if meek gets blocked" for some more options:
https://lists.torproject.org/pipermail/tor-talk/2015-January/036410.html
___
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]

2015-10-26 Thread Conrad Kramer 

> On Oct 26, 2015, at 10:23 AM, Ian Goldberg  wrote:
> 
> On Mon, Oct 26, 2015 at 06:06:36AM -0700, Mike Perry wrote:
>> Essentially, codesign only touches executable binaries in the .app (see
>> that second link for info on how the binary's segments get moved around)
>> and also adds an SC_Info directory for codesign/DRM metadata.
> 
> Wait; does that mean that things like configuration files, plugins, etc.
> are *not* signed?

They are signed. All resources in a bundle (e.g. an app or framework) are
signed and the signatures are stored in a file named "CodeResources”:

https://developer.apple.com/library/mac/documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html#//apple_ref/doc/uid/TP40005929-CH3-SW1


Conrad


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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]

2015-10-26 Thread Ian Goldberg 
On Mon, Oct 26, 2015 at 06:06:36AM -0700, Mike Perry wrote:
> Essentially, codesign only touches executable binaries in the .app (see
> that second link for info on how the binary's segments get moved around)
> and also adds an SC_Info directory for codesign/DRM metadata.

Wait; does that mean that things like configuration files, plugins, etc.
are *not* signed?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] [FWD: Re: Apple developer account + codesigning]

2015-10-26 Thread Spencer 

Hi,



Conrad Kramer:
All resources in a bundle (e.g. an app or framework) are
signed and the signatures are stored in a file named "CodeResources”:



Then what is in 'CodeSignature', Apple's signing stuff?

Wordlife,
Spencer

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