Send tor-dev mailing list submissions to
tor-dev@lists.torproject.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
or, via email, send a message with subject or body 'help' to
tor-dev-request@lists.torproject.org
You can reach the person managing the list at
tor-dev-owner@lists.torproject.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of tor-dev digest..."
Today's Topics:
1. Re: Tor with collective signatures (isis agora lovecruft)
2. Further sandboxing Tor Browser (aka Tor + Firejail redux).
(Yawning Angel)
----------------------------------------------------------------------
Message: 1
Date: Thu, 21 Jul 2016 15:05:07 +0000
From: isis agora lovecruft <isis@torproject.org>
To: tor-dev@lists.torproject.org
Cc: Philipp Jovanovic <philipp.jovanovic@epfl.ch>
Subject: Re: [tor-dev] Tor with collective signatures
Message-ID: <20160721150507.GE8911@patternsinthevoid.net>
Content-Type: text/plain; charset="utf-8"
Nicolas Gailly transcribed 59K bytes:
> Hi,
>
> Here's a new version of the proposal with some minor fixes discussed
> with teor last time.
>
> 0.4:
> - changed *included* to *appended*
> - 3.2: end of paragraph, a valid consensus document contains a majority
> of CoSi signatures.
> - Acknowledgments include teor and Tom Ritter.
>
> As always, critics / feedbacks / thoughts are more than welcome :)
>
> Thanks !
>
> Nicolas
>
> Ps: Our team and I are going to be at PETS this year, so if you don't
> have time now to
>
> read the whole thing, but you are still willing to know about CoSi and
> how it could improve
>
> Tor security, I/we will be happy to talk with some of you there also.
Hello all,
At PETS this afternoon, Nicolas Gailly, Philipp Jovanovic, Ismail Khoffi,
Georg Koppen, Nick Mathewson, and I met to discuss the collective signing
proposal. I'm just going to breifly summarise the discussion here.
One of the major concerns voiced was that, if we made it mandatory that a
collective signature on a consensus be verifiable (for some N number of
signers, where N might be all of them but it's not important) for a client to
accept and use a consensus, then attacks upon the witnesses (or any disruption
to the witness signing system) will cause clients to no longer be able to
bootstrap. Conversely, if we made it so that it only emitted some warning
when the collective signature could not be verified, then (likely) no users
would see this warning (or even if they did, they'd treat it in the same
manner as a TLS certificate warning and simply click through it).
There is also concern that, with enforcing collective signatures, that the Tor
network has a larger attack surface w.r.t. (D)DoSing: an adversary could DoS 5
of the 9 DirAuths *or* they could DoS whatever necessary percentage of the
witness servers. Additionally, an adversary who controls some portion of the
witness servers may DoS other witnesses in order to amplify the relative
proportion of the collective signature which they control.
There was some discussion over whether to integrate this into core tor, or
rather to just use Nicolas' CoSi Golang tool in a separate process. Everyone
agreed that rewriting something from Go to C is suboptimal.
One idea was if we used CoSi, but rather than "don't trust/use a consensus if
it doesn't have a good CoSi" we could use it as a mechanism for clients to
report (to some system somewhere? perhaps part of the prop#267 consensus
transparency logs?) when CoSis don't verify successfully.
Another idea was to use CoSi to sign the metadata file which Firefox's updater
uses to learn where to fetch updates so that a client would know that the same
Tor Browser updates were being served to other different vantage points.
Todo list:
1. It's not super necessary, but more analysis of the bandwidth overhead for
running this protocol would be nice, i.e. network-wide overhead, not just
the overhead for a single witness.
2. It would be nice to have some RFC-like description so that alternate
implementations could be created, e.g. include encodings, state machines,
message formats. (We strive to maintain our specifications with the
delusion that there are secretly hundreds of other tor implementations in
every existing language, and that any of them should be compatible if they
follow the specification.)
3. Update the proposal to mention that each DirAuth would have their own
tree, thus the consensus document in the end would have somewhere between
5 and 9 CoSi signatures.
4. There's a typo in §5.2: s/witnesse's/witnesses'/
Thanks, everyone, for the great discussion!
Best regards,
--
♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1240 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160721/6614fee3/attachment-0001.sig>
------------------------------
Message: 2
Date: Fri, 22 Jul 2016 04:15:09 +0000
From: Yawning Angel <yawning@schwanenlied.me>
To: tor-dev@lists.torproject.org
Subject: [tor-dev] Further sandboxing Tor Browser (aka Tor + Firejail
redux).
Message-ID: <20160722041509.3c86ffa5@schwanenlied.me>
Content-Type: text/plain; charset="utf-8"
I felt randomly inspired, so I spent some time poking at my firejail
Tor Browser sandboxing effort, and made progress towards something more
robust. In particular, I switched to using AF_LOCAL (aka AF_UNIX)
sockets, via a brute force-ish approach, which seems to be working
well, despite some caveats.
In theory, this raises the difficulty of proxy bypass type things
significantly (in that you need a sandbox escape sploit to use
AF_INET/AF_INET6). In practice, who knows, for what it's worth the
subterranean reptiloids who beam thoughts into my head from their
satellite installations reassure me that it's safer.
WARNING:
* If you are not comfortable with running/configuring a system
tor daemon, keeping it up to date, and keeping it in sync with the
one shipped with Tor Browser when it diverges, stop reading, and
wait for the Tor Browser people to come up with their own sandboxing
solution.
* If you expect me to provide any sort of help beyond "merging
sensible patches", likewise stop reading, and wait for the Tor
Browser people to come up with their own sandboxing solution.
Really.
Prerequisites:
* A system tor daemon with the Control port and Socks port exposed as
AF_LOCAL sockets, with permissions configured such that the user
running Tor Browser can write to both. Due to torbutton quirks,
having a SocksPort on 127.0.0.1:9050 is also a good idea, though not
strictly necessary.
* A recent version of firejail (nb: I did not test this with a USER_NS
kernel. It may be better, it may be worse.).
Setup:
1. Clone https://git.schwanenlied.me/yawning/tor-firejail
2. (Optional) Back up your Tor Browser install so you can go back to
the way things used to be when you mess up.
3. Follow the instructions in the README.md, adjusting paths as
appropriate. It should be self explanatory. If it's not, revert
back to how things were, and wait for a more official solution.
Depending on how your tor is setup, you probably need to set a bunch
of env vars (At a minimum, TOR_SKIP_LAUNCH is required. Everything
else depends on how the control/socks sockets are setup, and where
they live, the modified start-tor-browser script has more
documentation in comments.).
4. Run start-tor-browser, use lsof/netstat/whatever to verify that the
AF_LOCAL sockets are being used.
Caveats:
* The security of this assumes that the firejail options I use to
enforce address family restrictions work as advertised.
* You need a system-wide tor, because if you tried to run the tor
daemon inside the sandbox, it won't be able to access the network.
* The firejail profile I provide disallows access to everything in the
user's home directory except for the directory that actually
contains Tor Browser. Edit the profile to change this if you care
about it. I like the behavior for various reasons so I'm not going
to change it.
* The `about:tor` display falsely reports an error unless there's a
SocksPort on 9050, due to torbutton. You can alternatively lie to
torbutton about where the listener is if you engage in control port
related tinfoil hattery.
* You need to repeat parts of the installation steps after updating.
How it works:
* firejail's sandbox forbids all non-AF_LOCAL sockets.
* A small stub is injected into the firefox process at runtime via
LD_PRELOAD that fixes up socket calls to go to the system wide tor
instance's AF_LOCAL sockets.
Random thoughts:
* The stub should be adequate for using other similar sandboxing
solutions (eg: flatpak's bubblewrap, Google's thing, whatever). The
code is compact, and is something anyone half way competent could
write in 15 mins or so (it may have dumb bugs, dunno). Using the
stub on it's own without the sandbox would be a horrible idea.
* Assuming Tor Browser works as advertised, the only reason it needs
control port access for this sort of use case is the circuit display
(as of torbutton commit 36d849291ec0b20a58cccc2cd846fcd2540c9bbe,
sending NEWNYM should be unnecessary if domain isolation is
applied to everything).
Regards,
--
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160722/f13f9776/attachment-0001.sig>
------------------------------
Subject: Digest Footer
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
------------------------------
End of tor-dev Digest, Vol 66, Issue 17
***************************************