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