unsubscribe
On Fri, Jul 22, 2016 at 10:00 PM, <tor-dev-requ...@lists.torproject.org> wrote: > 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-requ...@lists.torproject.org > > You can reach the person managing the list at > tor-dev-ow...@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 <i...@torproject.org> > To: tor-dev@lists.torproject.org > Cc: Philipp Jovanovic <philipp.jovano...@epfl.ch> > Subject: Re: [tor-dev] Tor with collective signatures > Message-ID: <20160721150507.ge8...@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 <yawn...@schwanenlied.me> > To: tor-dev@lists.torproject.org > Subject: [tor-dev] Further sandboxing Tor Browser (aka Tor + Firejail > redux). > Message-ID: <20160722041509.3c86f...@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 > *************************************** >
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
