[tor-dev] tor-dev Digest, Vol 66, Issue 17

[Nathan Kettle]

unsubscribe


On Fri, Jul 22, 2016 at 10:00 PM, <tor-dev-request at lists.torproject.org>
wrote:

> Send tor-dev mailing list submissions to
>         tor-dev at 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 at lists.torproject.org
>
> You can reach the person managing the list at
>         tor-dev-owner at 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 at torproject.org>
> To: tor-dev at lists.torproject.org
> Cc: Philipp Jovanovic <philipp.jovanovic at epfl.ch>
> Subject: Re: [tor-dev] Tor with collective signatures
> Message-ID: <20160721150507.GE8911 at 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 at schwanenlied.me>
> To: tor-dev at lists.torproject.org
> Subject: [tor-dev] Further sandboxing Tor Browser (aka Tor + Firejail
>         redux).
> Message-ID: <20160722041509.3c86ffa5 at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
> ------------------------------
>
> End of tor-dev Digest, Vol 66, Issue 17
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160722/335071a6/attachment.html>