[tor-dev] Release: obfs4proxy-0.0.11
Hello, I just tagged obfs4proxy-0.0.11. The primary changes are an alteration to how the obfs4 transport handles connections after the handshake failed, based on a report and assistance from Sergey Frolov. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.11.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.11.tar.xz.asc Changes in version 0.0.11 - 2019-06-21: - Update my e-mail address. - Change the obfs4 behavior for handling handshake failure to be more uniform. Thanks to Sergey Frolov for assistance. - Bump the version of the utls fork. Regards, -- Yawning Angel signature.asc 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] Release: obfs4proxy-0.0.10
On 5/3/19 1:48 PM, Steve Snyder wrote: > FYI, obfs4proxy no longer recognizes address:port in this form: > > ServerTransportListenAddr obfs4 [000.000.000.000]:443 > > Note the square brackets. Tor 0.3.5.8 / 0.4.0.5 still parses this > syntax, and obfs4proxy used to too. As of 0.0.10 it no longer does. Odd. None of that code, both in obfs4proxy and goptlib, has changed for years. I'll look at it when I have a moment. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.10
Hello, I just tagged obfs4proxy-0.0.10. The primary changes are a minor fix to the meek_lite behavior when using `utls` as the TLS implementation, and a series of updates (primarily following upstream) to the `utls` library. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.10.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.10.tar.xz.asc Changes in version 0.0.10 - 2019-04-12: - Disable behavior distinctive to crypto/tls when using utls. - Bump the version of the utls fork. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.9
Hello all, I just tagged obfs4proxy-0.0.9. The main features of this release are primarily related to improving the behavior of the `meek_lite` transport. Since some of the changes are major, I will expand on them separately from the brief summary given in the ChangeLog. * A forked version[0] of https://github.com/refraction-networking/utls is now used to mask the TLS signature. This results in a ClientHello that should resemble modern versions of Firefox by default. While the utls profile is named `HelloFirefox_63`, a cursory examination leads me to believe that there are no differences in FF 65. The bridge line option `utls=` will allow specifying the behavior, with (case-insenstive) string representations of the utls fingerprint names. `none` will revert to the previous behavior. Not all fingerprints were tested and or are guaranteed to work. Development was primarily done with `HelloChrome_70, `HelloFirefox_63`, and `HelloChrome_71` (experimental). While I can not vouch for the mimicry accuracy of every single profile, all of the profiles that attempt to mimic browsers should function fairly well[1], though this partially depends on the the configuration of the host doing the fronting. * meek_lite now has HPKP[2] style public key pins for all of the Microsoft CA certs that are used to sign Azure leaf certificates. This is only enabled when `utls` is being used, because I'm lazy. If Microsoft happens to change their CA certificates prior to the next release, 2024-05-20, or you are ok with being actively man-in-the- middled for some reason, adding `disableHPKP=true` to the bridge line will disable certificate pin validation. HPKP headers in HTTP responses are ignored, only the static pin list is consulted. * Due to a shift in my philosophy, portions of the new code are released under the GNU General Public License v3. Exceptions to the viral nature of the license will be considered on a case-by-case basis. Contact me for more details. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.9.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.9.tar.xz.asc Changes in version 0.0.9 - 2019-02-05: - Various meek_lite code cleanups and bug fixes. - Bug 29077: uTLS for ClientHello camouflage (meek_lite). - More fixes to HTTP Basic auth. - (meek_lite) Pin the certificate chain public keys for the default Tor Browser Azure bridge (meek_lite). Regards, -- Yawning Angel [0]: obfs4proxy WILL NOT build with the upstream version of the library, and the Firefox fingerprint will not function with Azure using the upstream version. [1]: For "I can watch Eluveitie music videos on youtube over it" definitions of "fairly well". [2]: Yes, the HPKP spec is rather dead in the wild with a lot of people giving up on it. It is my opinion that in this context having such a mechanism makes sense. signature.asc 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] RFC: Using `utls` in meek_lite.
On 1/24/19 7:38 AM, David Fifield wrote: > I see, you're right. It has to do with the reuse of the initConn. A proper "general" solution that solves that problem and the ALPN issue is to have a `initConn` and `http.RoundTripper` instance per destination host, and some additional locking. With more implementation cleverness this could be brought down to two `http.RoundTripper` instances, and a host -> pointer + net.Conn map, and some locking. But for something like meek_lite where the number of destination hosts is not large, the existing wrapper works fine and I don't see much reason to over engineer it. Regards, -- Yawning Angel signature.asc 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] RFC: Using `utls` in meek_lite.
On 1/24/19 6:47 AM, David Fifield wrote: > // This also assumes that req.URL.Host will remain constant for the > // lifetime of the roundTripper, which is a valid assumption for > meeklite. > > Am I wrong, or is the actual restriction less strict? You can reuse the > roundTripper for different hosts--the ServerName is taken from the addr > argument to dialTLS--but only if those different hosts negotiate the > same ALPN, because the choice of http.Transport or http2.Transport is > made only once and persists for the lifetime of the roundTripper. The lock protecting `roundTripper.initConn` is only held in `dialTLS`, and the `roundTripper.transport` is not protected by a lock at all. If the target host changes and there is simultaneous access (two threads call into `roundTripper.RoundTrip` right after initialization simultaneously), there is no guarantee that the connection used to create the inner `http.RoundTripper` instance will be passed to the correct thread. Regards, -- Yawning Angel signature.asc 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] using obfs4 to tunnel to a SOCKS proxy server
On 1/23/19 10:42 AM, Hans-Christoph Steiner wrote: > uniqx got the setup working with obfs4 connecting to a port on the > server side, like a webserver. Weŕe trying to figure out a way to make > this obfs4 setup to behave like an SSH port forward, but weŕe banging > our heads against the concept. You don't/can't, with mainline obfs4proxy. > For example, could the obfs4 server side provide a generic SOCKS proxy? There is no functionality for doing such a thing in mainline obfs4proxy. What currently will work is any one of: * Stick a proxy server of your choice behind the obfs4proxy server. From the application end it will essentially be connecting to a (for example) SOCKS5 proxy over another SOCKS5 proxy. * Connect the obfs4proxy server to a load-balancer or reverse-proxy that re-dispatches requests to the correct location based on the SNI block or `Host` header (depending on how you want to treat TLS). Regards, -- Yawning Angel signature.asc 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] RFC: Using `utls` in meek_lite.
(Whoops I sent my last reply directly instead of to the list. It wasn't all that important for the general public, and lists.tp.o has been flaky for me recently anyway.) On 1/21/19 5:22 PM, David Fifield wrote: > As for the TODO, my plan was was to expose a "utls" SOCKS arg to make it > configurable per bridge, and just reuse the utls Client Hello ID names: > utls=HelloChrome_Auto Done. https://gitlab.com/yawning/obfs4/commit/e4020b18f7aaafe9f4cb345630bfe18a5e44a8d2 As long as there's enough bridge line interoperability between implementations, I'm not particularly bothered if other people actually do use utls.HelloGolang or not, I'm choosing not to. As a side note: Implementing support for the missing DH groups in utls is likely trivial (assuming you don't care that it's vartime, extremely bad for actual TLS, fine for meek_lite) and would increase compatibility a good amount. That said HelloChrome_Auto and HelloIOS_Auto both work fine against the Azure bridge, so it might not be worth the effort. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] RFC: Using `utls` in meek_lite.
Hello, I just pushed a change to obfs4proxy master to use `utls` to mask the ClientHello signature (currently Chrome 70.x). https://gitlab.com/yawning/obfs4/commit/4d453dab2120082b00bf6e63ab4aaeeda6b8d8a3 I understand that this is being worked on for the original meek (see: https://bugs.torproject.org/29077), but I felt inspired and it was relatively easy to get something working. Caveats: * This is only lightly tested, and may be doing something wrong or distinct. It seems to work well enough to watch videos over it. YMMV. * Azure uses HTTP 2. Not really a problem. * `utls.HelloFirefox_Auto` will fail to handshake with Azure due to an incompatible group being negotiated. * `utls.HelloChrome_Auto` ironically fails to handshake with `google.com` in a standalone test case for me. * `utls.HelloIOS_Auto` seems to work in all cases, so I may switch to that before I tag. Questions, comments, feedback appreciated, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.8
Hello all, I just tagged obfs4proxy-0.0.8. This includes a few minor bugfixes in an official tagged release, and changes the primary upstream repo to one hosted on gitlab. Moving forward issues and patch merge requests should be filed on the gitlab issue tracker. While I will attempt to examine other existing locations for such things, response may (will) be delayed. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.8.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.8.tar.xz.asc Changes in version 0.0.8 - 2019-01-20: - Bug 24793: Send the correct authorization HTTP header for basic auth. - (meek_lite) Explicitly set Content-Length to zero when there is no data to send. - Added optional support for building as a Go 1.11 module. Patch by mvdan. - Change the canonical upstream repo location to gitlab. Regards, -- Yawning Angel signature.asc 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] WTF-PAD and the future
On 08/02/2018 08:26 PM, Mike Perry wrote: > Should we consider recommending basket2 also? No. > Is anyone running bridges with it? Probably not, I guess :/. No one should be, it is incomplete, buggy, and needs a re-design. As a side note, I question the utility of a PT that has the AGPL3 network interaction requirement, though there is an exception for bridges distributed via BridgeDB and those shipped with Tor Browser. Regards, -- Yawning Angel signature.asc 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] Sandboxed Tor Browser should be officially developed
[Well, I already got my first bit of automated spam from the last post, so I might as well reply again.] On Sat, 16 Jun 2018 20:34:03 -0700 Chelsea Holland Komlo wrote: > As you pointed out, this project is no longer being actively > maintained. While someone on the Tor Browser development team can > answer more thoroughly, my understanding is that the original > maintainer moved on from working on this project. The Tor development > teams are quite small, so (like many open source projects) there are > more projects than people to support them. Essentially, yes. TLDR: I do not have the resources to dedicate to maintaining this, and in the long term the project should be replaced by a correctly re-designed Tor Browser that can sandbox itself anyway. In a more concrete terms, the "correct" thing to do would be for a non-trivial amount of work to be put into making Tor Browser support better isolation and sandboxing on it's own, rather than someone be stuck with trying to retrofit it to do things that the current design and architecture are ill suited to doing. Till something like that happens, a large amount of time, effort and code will be spent on replicating existing functionality such as the launcher, updater and configuration interface. This requires extensive changes to the existing Tor Browser design. As an example of what would be required, M. Finkel's design proposal[0] describes the steps required to change the Tor Browser architecture to something that is less nightmarish to sandbox, and provides better component isolation. As far as I am aware, there is no one working on that either. There are other fundamental unresolved questions specific to Linux sandboxing (eg: X11, D-Bus) that need to be resolved in a user-friendly manner (eg: blocking all of D-Bus a la `sandboxed-tor-browser` is unacceptable for mass adoption), but the better isolation brought on by the architectural change on it's own would be an improvement over a vanilla Tor Browser install, and it would let whoever is working on such things, focus on such things, rather than being forced to re-implement large parts of Tor Browser. Regards, -- Yawning Angel [0]: https://lists.torproject.org/pipermail/tbb-dev/2018-January/000743.html pgp4CNrRmOJJf.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] Sandboxed Tor Browser should be officially developed
I wasn't going to reply to this because the last time I posted to this list, I got flooded with spam, but fine. On Sat, 16 Jun 2018 18:01:04 +0200 juanjo wrote: > I do not understand why Sandboxed Tor Browser is now deprecated when > it should be the new thing in security features. It works well and > stopped already some 0days in the past and today I see that not only > is officially "*WARNING: Active development is on indefinite hiatus"* > (https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux), > the last commit is from 3 months ago, but still it works well. And > today I see that for the Firefox 60 ESR this support will be removed > (https://gitweb.torproject.org/builders/tor-browser-build.git/commit/?id=dc355882e235178d0a1889a7d96c5721faad2716). Because there was no funding for development. > Is there a hidden agenda to allow LEA/governments to exploit Tor > Browser users easily? Because I don't think maintaining the sandboxed > version is that much work and it is a great protection for many users. LOL. > So please, make Sandboxed Tor Browser an official thing. Fuck you, pay me. Regards, -- Yawning Angel pgpG9InkdTvYV.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] permission denied when running snowflake-client with debian-tor user
On Mon, 11 Jun 2018 13:24:19 -0400 Arlo Breault wrote: > When you launch the client binary without providing a broker url > it tries to create a named pipe (mkfifo) to do signalling. > > https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/rendezvous.go#n161 The PT spec explicitly forbids this behavior, to avoid this problem. https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt#n188 > "TOR_PT_STATE_LOCATION" > > Specifies an absolute path to a directory where the PT is > allowed to store state that will be persisted across > invocations. The directory is not required to exist when > the PT is launched, however PT implementations SHOULD be > able to create it as required. > > PTs MUST only store files in the path provided, and MUST NOT > create or modify files elsewhere on the system. > > Example: > > TOR_PT_STATE_LOCATION=/var/lib/tor/pt_state/ Regards, -- Yawning Angel pgpmVyAiuBs22.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] Pluggable transports research
On Wed, 24 Jan 2018 16:42:52 -0800 Jodi Spacek <jodi.spa...@gmail.com> wrote: > I'm a master's student at the University of British Columbia > (Vancouver, Canada) where I'm primarily researching anonymous systems > and censorship. I would be delighted to contribute to pluggable > transports. > > Of particular interest is image and audio data stenography - is > anything is in the works for this or is it outdated? My aim is to add > this functionality while fully testing and evaluating it as part of > my thesis project. I refer to the list of idea suggestions here: > https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/ideas As far as I am aware (nb: haven't been keeping up with research in this area), no one has come up with a good solution to the issues mentioned in: Geddes, J., Schuchard, M., Hopper, N., "Cover Your ACKs: Pitfalls of Covert Channel Censorship Circumvention". https://www-users.cs.umn.edu/~hoppernj/ccs13-cya.pdf Regards, -- Yawning Angel pgpzXR9N4Leyb.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] No Control Socket when DisableNetwork 1
On Sat, 20 Jan 2018 04:40:53 -0500 Roger Dingledine <a...@mit.edu> wrote: > My second suggestion would be to get a Tor binary and run it yourself, > not as part of a package. If it works there, then you know that your > next steps are to figure out why your package isn't working for you. With a torrc that looks like this: DataDirectory /tmp/tor ControlPort unix:/tmp/tor/control.sock SocksPort unix:/tmp/tor/socks.sock DisableNetwork 1 Running 0.3.1.9 I got from my distribution's package manager: Jan 2013:31:28.986 [notice] Opening Control listener on /tmp/tor/control.sock And a trivial test that exercises the control port works: amiens :: ~ % nc -U /tmp/tor/control.sock PROTOCOLINFO 250-PROTOCOLINFO 1 250-AUTH METHODS=NULL 250-VERSION Tor="0.3.1.9" 250 OK So digging into this further probably requires the "next steps". I still recommend a bit of a wait for tor to open the AF_UNIX socket. While it usually is nearly instantaneous on modern systems, I had intermittent problems with "the socket isn't there" related to trying too fast. Regards, -- Yawning Angel pgpQp7PSFkFus.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] No Control Socket when DisableNetwork 1
On Fri, 19 Jan 2018 23:22:00 + iry <i...@riseup.net> wrote: > According to the Tor manual: > https://www.torproject.org/docs/tor-manual-dev.html.en > > > DisableNetwork 0|1 When this option is set, we don’t listen for or > > accept any connections other than controller connections, and we > > close (and don’t reattempt) any outbound connections. Controllers > > sometimes use this option to avoid using the network until Tor is > > fully configured. (Default: 0) > > However, it seems when DisableNetwork is set to 1, > /var/run/tor/control does not exist anymore making us cannot get a > controller from socket file. > (stem.control.Controller.from_socket_file() is affected in this case: > https://stem.torproject.org/api/control.html#stem.control.Controller.fro > m_socket_file) I'm fairly certain you are doing something wrong, because I'm using a tor process that was launched with DisableNetwork set to 1 in the torrc, and toggled to 0 via the ControlPort right now to browse the web (Tested with the copy of 0.3.1.9 that is distributed with Tor Browser). https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tree/data/torrc https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tree/src/cmd/sandboxed-tor-browser/internal/tor/tor.go#n342 To reproduce this working, if anyone out there still uses the sandbox I wrote, and can get a working browser without using an external tor instance, ta dah, it's working. Normal Tor Browser has a similar launch process, and can even be coaxed into using AF_UNIX sockets (though it's utterly pointless to do so). nb: It can take a while for the control port to actually be available after the tor daemon is spawned. The best way I found to deal with this is via using `ControlPortWriteToFile` since the file gets created after the control port listener is created. You could also use something like inotify on Linux, but that's non-portable. Regards, -- Yawning Angel pgpbZpZhxZdpl.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] Prop-279 for Onion Alternative Name Representations (Re: Error-Correcting Onions with Bech32)
On Mon, 1 Jan 2018 08:45:57 + nullius <null...@nym.zone> wrote: > On 2017-12-31 at 10:48:52 +, Yawning Angel > <yawn...@schwanenlied.me> wrote: > >This is pointless because internationalized domain names are > >standardized around Punycode encoding (Unicode<->ASCII), and said > >standard is supported by applications that support IDN queries. > > > >I am firmly against this change, and I'm not particularly thrilled > >by the thought of homograph attacks either. > > Happy New Year, Yawning; and apologies for the delayed reply. I > thought I’d best work up some code for an object demonstration of why > I urge the importance of UTF-8 (and also embedded spaces, which I > forgot to mention explicitly). I'm aware of the use cases for IDNs. > As for Punycode vs. UTF-8: > > Homograph attacks are not “solved” by Punycode any more than they > would be fixed by base64ing all addresses. Punycode is not a > security feature; to the contrary! CVE-2013-7424, CVE-2015-8948, > CVE-2016-6261, CVE-2016-6262, CVE-2017-14062 Need I say more? Sigh, the problem is encoding format agnostic. My point was, by allowing non-ASCII characters the onus is on *someone* to solve the problem of homograph attacks (which admittedly is a bit of a tangent). I'm painfully aware that all browsers, including Tor Browser have utterly inadequate solutions here. > I know that as you say, applications which handle a string as a > “domain” will Punycode it before Tor even sees it. But my thinking > from the beginning was not in terms of DNS names. One of my > constructive criticisms of prop-279 is that it makes that assumption. It makes that assumption because it is an entirely reasonable thing to do in the context of Tor. > Dare to dream outside the quasi-DNS box about how .onion addresses > can be represented! I will quote Alec Muffet here: > a) if Onion addresses suddenly stop looking very-similar-to DNS > addresses, Tor risks returning to a world where special expertise is > necessary to build software for it, thereby harming growth/adoption The current proposal can get "very similar-to DNS addresses" IDNs by using the same encoding format that DNS uses. Regards, -- Yawning Angel pgpy2ZSIgrhQ_.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] Prop-279 for Onion Alternative Name Representations (Re: Error-Correcting Onions with Bech32)
I commented on the ticket but I'll do it here for completeness sake: On Sun, 31 Dec 2017 10:12:53 + nullius <null...@nym.zone> wrote: > I also proposed changes to permit the UTF-8 characters required for > representing names in languages other than American English, and some > other technical improvements. I added status code 5 to support > plugins which can discern when a name is in a recognized format, but > is intrinsically invalid e.g. due to checksum failure; and I expanded > the description of status code 2, for plugins which do not have TLDs > but do recognize a definite syntax. This is pointless because internationalized domain names are standardized around Punycode encoding (Unicode<->ASCII), and said standard is supported by applications that support IDN queries. I am firmly against this change, and I'm not particularly thrilled by the thought of homograph attacks either. > Given appropriate prop-279 changes, I won’t need to draw a proposal. > I’ll simply write code! It's worth keeping in mind that no one to my knowledge has implemented prop 279 in the tor code itself, though there is (IIRC) a python kludge that kind of allows development. Regards, -- Yawning Angel pgpEeie9zpgdb.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] Proposal 286: Controller APIs for hibernation access on mobile
On Thu, 30 Nov 2017 07:55:49 -0500 Nick Mathewson <ni...@torproject.org> wrote: > Filename: 286-hibernation-api.txt > Title: Controller APIs for hibernation access on mobile > Author: Nick Mathewson > Created: 30-November-2017 > Status: Open [snip] Is this a general call for feedback/questions? If so, what do you have in mind for Pluggable Transports? Currently I can count on zero fingers, the number of PTs that honor hibernation state, or that have provisions for something like a hibernation state. I assume that if this was to be solved, the hibernation code would need to tear down/respawn PTs, or someone needs to design an out of band IPC mechanism between tor and PTs that can signal hibernation status. The current approach to this problem involves toggling `DisableNetwork`. See: https://trac.torproject.org/projects/tor/ticket/13213 Regards, -- Yawning Angel pgpNsBQxLDZgm.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] Proposal 284: Hidden Service v3 Control Port
On Thu, 9 Nov 2017 10:13:45 -0500 David Goulet <dgou...@ev0ke.net> wrote: > > > Ok fun! I'll add this. Good catch! And control-spec.txt should be > > > updated. > > > > > > To be consistent then we could ask for a as well: > > > > > > "ED25519-V3:" > > > > > > ... which contains the ed25519 private key. > > > > If it were up to me, I'd spec the blob as opaque, and then actually > > use something that's sensible and consistent with the torrc and on > > disk files for easy interoperability like Base64 of the private key > > (I haven't check to see what encoding is used for on disk EdDSA > > keys, I assume PEM). > > Unfortunately not, it is custom to tor I believe with this 32 bytes > header: > > "== ed25519v1-secret: type0 ==\0\0\0" > > ... followed by the private key (64 bytes). See > crypto_write_tagged_contents_to_file(). > > Not sure we can change that within the 032 freeze. So the approach > would be to Base64 the raw bytes of the key (excluding the header). > Using tor HS key file, it would be something like: > > $ tail -c+33 hs_ed25519_secret_key | base64 -w 0 > > Considering the current situation with the encoded file on disk of > the key, I think this is kind of the simplest approach? Yeah. Just the Base64ed private key (excluding that header and things) seems reasonable. -- Yawning Angel pgpRS2OrGZWk9.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] PQ crypto updates
On Sun, 17 Sep 2017 21:04:28 -0400 Nick Mathewson <ni...@alum.mit.edu> wrote: > I think the first step here is to instrument relays to figure out what > fraction of their cryptography is relay cell cryptography: this could > tells us what slowdown we should expect. (It _should_ be about a > third of our current cell crypto load, but surprises have certainly > been known to happen!) I'd also argue that instrumenting an high traffic client is important (if only so that there aren't unpleasant surprises later in the form of the clients hosting spacebookgopheri.onion or whatever exploding). There was some discussion about obtaining profiler output for this particular case, but AFAIK nothing really happened[0]. > The current performance we have is much faster than 13 cpb -- we're at > approximately one AES, plus one third of a SHA1. (The "one third" is > because only clients and exits do the SHA1 step.) I wonder how many of the relays have support for hardware assisted SHA. (nb: I don't have access to ARMv8, Ryzen or a sufficiently new Intel system, so I don't know how good the implementations are) Regards, -- Yawning Angel [0]: And depending on the sort of traffic the HS is serving, this may/will be dominated by public key cryptography... pgpgYWUPh3W_D.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] PQ crypto updates
On Tue, 22 Aug 2017 20:47:06 +0200 Peter Schwabe <pe...@cryptojedi.org> wrote: > Yawning Angel <yawn...@schwanenlied.me> wrote: > > Hi Yawning, hi all, > > > Ultimately none of this matters because Prop. 261 is dead in the > > water. Assuming people want the new cell crypto to be both fragile > > and to resist tagging attacks, Farfalle may be a better choice, > > assuming there's a Keccak-p parameterization such that it gives > > adequate performance. > > At what number of cycles/block on what architecture(s) would you call > the performance "adequate"? Note, I'm not hating on Farfalle, I need to look at it more, and the last time I gave serious thought to this question in a Tor context was back around the time Prop 261 was being drafted. The answer to this from my point of view is "not slow to the point where the network falls over", which I'll admit is extremely handwavy, but truth be told, I have no idea what fraction of the relays are on what micro architectures these days. Looking at the Farfalle and Kangaroo 12 papers, Kravette may be ok with AVX2 assuming I'm extrapolating correctly. But, while it's probably reasonable to assume that all the fast existing relays have AES-NI, I do not know what fraction of those predate AVX2. Part of me thinks that focusing on raw primitive performance is a bit silly (even though I'm the one that brought it up), because just about anything will likely deliver adequate performance if the cell crypto used more than one core[0]. Sorry I don't have anything more concrete. :( Regards, -- Yawning Angel [0]: And another part of me kind of wants to say "eat the overhead of a MAC per hop and use AES-GCM-SIV or something". pgpMDM6QwTKuq.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] PQ crypto updates
On Sun, 20 Aug 2017 16:32:17 + Taylor R Campbell <campbell+tor-...@mumble.net> wrote: > > ... I'm not seeing your point. Even prior to that paper, AEZ > > wasn't thought to be quantum resistant in anyway shape or form, and > > providing quantum resistance wasn't part of the design goals of the > > primitive, or really why it was being considered at one point for > > use in Tor. > > I would expect AEZ to have essentially the same post-quantum security > as, e.g., AES or any other symmetric crypto -- square root speedup by > Grover. Yes and? My point was that quantum speedups that existed prior to the paper alone, were sufficient to render the primitive insecure in a post quantum setting. Something that's broken being more broken is non-interesting, in particular when the impetus for even considering the something (as is the case for AEZ and Tor), had nothing to do with PQ cryptography in the first place. > However, this paper is not about the conventional notion of > post-quantum security -- what is the cost, to an adversary with large > a quantum computer, of breaking ordinary users of the cryptosystem? -- > but a radically different notion of security for users who > inexplicably choose evaluate AEZ in a quantum superposition of inputs > and reveal that superposition to an adversary. Believe it or not, I did read the paper. > It is not surprising that when users abuse their crypto primitives in > an astoundingly bizarre way, to reveal quantum superpositions of > outputs, the original security claims of the classical crypto > primitives go flying out the window! I'm having trouble parsing that, perhaps my English is failing me. Ultimately none of this matters because Prop. 261 is dead in the water. Assuming people want the new cell crypto to be both fragile and to resist tagging attacks, Farfalle may be a better choice, assuming there's a Keccak-p parameterization such that it gives adequate performance. Regards, -- Yawning Angel pgp8RMxKugm9s.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] PQ crypto updates
On Sat, 19 Aug 2017 04:11:16 - ban...@openmailbox.org wrote: > Boom headshot! AEZ is dead in the water post quantum: > > Paper name: Quantum Key-Recovery on full AEZ > > https://eprint.iacr.org/2017/767.pdf ... I'm not seeing your point. Even prior to that paper, AEZ wasn't thought to be quantum resistant in anyway shape or form, and providing quantum resistance wasn't part of the design goals of the primitive, or really why it was being considered at one point for use in Tor. Regards, -- Yawning Angel pgpKHB9bVRRUJ.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] Names for your onions
On Sun, 25 Jun 2017 10:42:51 +0200 heddha <heddha@unicorn.university> wrote: > -BEGIN PGP MESSAGE- > > hQIMA+0TUowTVIVZAQ//aBI9TzgVTB3R7DIMVB1JL7TzSMOanIjSJkNfDNKI15kC > 4sX6k0hJdBgIcELuqc9qmUYR0AfkZ+aJz1bPLETrv1IMCa/cB8ymDZreINJhk7BI > Qk6UM3PcutB7neTH3FR7DkVtSi23AOfOmlf0kNTSRZuMMB4gZO3KfZXGRWq1+FJ3 > [snip] Why are you sending PGP encrypted e-mail to a public mailing list. -- Yawning Angel pgpqOKwG4UPWF.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] Pluggable Transports 2.0 Specification, Draft 2
On Tue, 20 Jun 2017 21:27:35 -0700 David Fifield <da...@bamsoftware.com> wrote: > Even closely affiliated projects like Orbot haven't been able to use > pluggable transports strictly according to the spec, because of the > various constraints on mobile platforms. This is basically totally and utterly wrong. https://gitweb.torproject.org/orbot.git/tree/orbotservice/src/main/java/org/torproject/android/service/TorService.java#n1691 (The extra acrobatics are for programatically generating the config to handle the binary's install path being system dependent, which is beyond the scope of the PT spec itself.) Orbot can use normal Pluggable Transports just fine, and has at various points in time used: * obfsproxy (C) * obfsclient (C++) * obfs4proxy All basically exactly as specified by the Pluggable Transports spec. The only problem in this regard has been "Python on Android was a nightmare" which precluded the deployment of obfsproxy (Python). This has little to nothing to do with the Pluggable Transport spec itself. Perhaps you mean iOS? In which case, yeah, implementing something that's based around fork + exec, on an OS that doesn't allow that, is difficult, go figure (https://github.com/mtigas/iObfs for how it's done). > The API of the 2.0 spec is based on the internal architecture of > obfs4proxy, which is de facto the main implementation of most of > Tor's pluggable transports. I don't think that's a good idea, because the API was written by me, for me, to fit my use-cases (and I'm more and more dissatisfied with Go, to the point where all my new "for fun" code is going to be in C++ or D). But if it works for them, great I guess. I didn't use the API when I was working on basket2, so this has 0 impact on anything I will be doing, or anything that I've written. > But it failed in being "pluggable" in another sense: it's not easy to > share common transport modules beyond Tor (in either direction). It > would be great if the new spec can realize that second sense of > pluggability. I still don't understand what was so hard about implementing the old API, on anything but iOS. The "2.0" spec still doesn't have any provisions for using AF_LOCAL instead of the loopback interface, go figure. It's not as if I bring it up every time this topic comes up or anything right? Regards, -- Yawning Angel pgpAUxpskG3Pw.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] Pluggable Transports 2.0 Specification, Draft 2
On Tue, 20 Jun 2017 14:07:39 -0400 Brandon Wiley <bran...@blanu.net> wrote: > Attached is the second draft of the Pluggable Transport 2.0 > Specification. If you have feedback on this draft, please send me > your comments by July 20. I'll raise this because it bothers me, but maybe the other people who drafted the original document don't care as much as I do. I find the attribution in the acknowledgments section entirely inadequate. I explicitly credited all previous authors when I last rewrote the specification for a reason. Regards, -- Yawning Angel pgpgdLflv6ASe.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: sandboxed-tor-browser-0.0.5
Hello, I just tagged sandboxed-tor-browser 0.0.5. Binaries will be built when the next Tor Browser build happens (soon). Astute readers will notice that I skipped the release announcement for 0.0.4, which was tagged yesterday. This is due to changes related to e10s being enabled in the next alpha release, that were caught after the 0.0.4 tag was created. Changes in version 0.0.5 - 2017-04-13: * Bug 21764: Use bubblewrap's `--die-with-parent` when supported. * Fix e10s Web Content crash on systems with grsec kernels. * Add `prlimit64` to the firefox system call whitelist. Changes in version 0.0.4 - 2017-04-12: * Bug 21928: Force a reinstall if an existing hardened bundle is present. * Bug 21929: Remove hardened/ASAN related code. * Bug 21927: Remove the ability to install/update the hardened bundle. * Bug 21244: Update the MAR signing key for 7.0. * Bug 21536: Remove asn's scramblesuit bridge from Tor Browser. * Fix compilation with Go 1.8. * Use Config.Clone() to clone TLS configs when available. The main major change is the eradication of support for the `hardened` series, as the Tor Browser team will be dropping it starting from the next release (#20814). The impact on `sandboxed-tor-browser` + `hardened` users is thus: * (< 0.0.4) Will not correctly transition to the alpha channel. Sorry. The bundle may or may not be rendered non-functional by the transition update, I don't have a good way to test the Tor Browser auto update infrastructure with updates that haven't been released yet. * (>= 0.0.4) When `sandboxed-tor-browser` is launched, it will detect the `hardened` bundle and force a reinstall. This will eradicate the existing bundle directory obliterating user customization, bookmarks, and downloads (unless the download directory is overridden). A warning dialog box is displayed prior to booting the user back to the installation screen. Known issues: * Sending SIGINT to `sandboxed-tor-browser` (or likely otherwise killing the process) will leave the firefox process running on ESR52 + e10s builds, *unless* bubblewrap is version 0.1.8 or newer. Exiting firefox normally works as intended. Regards, -- Yawning Angel pgpHTTlzoNyE4.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] Control-port filtering: can it have a reasonable threat model?
On Mon, 10 Apr 2017 19:35:24 +0400 meejah <mee...@meejah.ca> wrote: > Obviously as per my other post I agree with fragmented / limited views > given to "real" applications of the control-port. However, personally > I don't see the point of implementing this in 'tor' itself -- existing > control-port filters are "fairly" limited code, typically in "safer > than C" languages anyway. So then you have the situation where > there's a single trusted application (the filter) conencted to the Tor > control-port. I agree with this, because it's basically required to do certain things, and for certain adversarial models. > Ultimately, it would probably be best if there was "a" robust > control-port filter that shipped as part of a Tor release. So if that > means "must implement it in C inside Tor" I guess so be it. I moderately disagree with this. It's not clear to me if a one size fit's all solution (that supports all "first class platforms" and use cases) would be easy to develop initially, and it will take continuous love and care to support everything that people want to do. By "first class" platforms in this context (since it's more client facing) I'll start off with "Whatever Tor Browser happens to be packaged for" as a first pass narrow definition. Even if this was shipped, I'm trying to keep the external dependencies required for correct sandbox functionality to a minimum, and something that's part of the bundle it downloads/auto updates doesn't feel great to me. > Maybe this would be a good target for "experiment with Rust" if > anyone's excited about writing control-port code in Rust...? I disagree with this, but since it'll never be used by the sandbox, my disagreement shouldn't stop anyone. -- Yawning Angel pgpEwYYfnw948.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] Comments on proposal 279 (Name API)
On Sat, 8 Apr 2017 08:47:51 +0100
Alec Muffett <alec.muff...@gmail.com> wrote:
> However: on this conference call it was made abundantly clear to all
> present - one could almost hear fingers being wagged - that it would
> be a bad thing for Onion addresses to (1) contain anything other than
> alphanumerics and non-leading-hyphens, (2) collide with IDNs and
> PunyCode.
>
> Now: I flatly do not know where this is documented; it may possibly
> be some intersection of DNS and HTTP RFCs, and if we want to take the
> approach that "everything should be permitted unless it is explicitly
> forbidden!" then yes we should go chase those documents down so that
> we have rationales for our self-imposed bondage.
Ironically, I struggled with this a bit when I pushed for making tor
clients reject "obviously malformed" destinations right when they hit
the SOCKS server.
From what I remember/can tell, RFC 1912 has the rules on what a valid
`hostname` is, RFC 2181 suggests that DNS server implementations should
not enforce restrictions on what a valid `hostname` is, and from
experience enforcing strict RFC 1912 on the real internet breaks
`nytimes.com`.
RFC 6125 mandates "LDH Lables" (RFC 5890), but is only applicable to
TLS.
> However if we want to seek the path of least resistance and effort,
> the answer is obvious to any seasoned network administrator:
>
> * alphanumeric
> * (whatever DNS label length)
> * (whatever DNS overall length)
> * single, and only single, dots at label separators
> * single, and only single, hyphens as spacers
> * (i'm trying to think if there are any more obvious constraints, but
> can't)
>
> ...which will traipse merrily through any system one cares to name.
tor currently enforces most of those (label length is notably not
checked), and also allows:
* `_` because `core3_euw1.fabrik.nytimes.com` despite what the RFCs
say.
* Trailing `.` used sometimes to make it explicit that the domain is
absolute.
See: https://gitweb.torproject.org/tor.git/tree/src/common/util.c#n1080
> That's a lovely idea; one more to add to the mix is the process
> documented at:
>
> https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md
>
> ...of hijacking addresses out of the DHCP network space and using
> them to configure interfaces with genuine, resolvable Onion names.
> It makes SSH and Apache configuration really clear when you can use
> the genuine onion address in configuration ("Listen") directives, etc.
>
> But then that's /etc/hosts - that's *not* what goes to a Certificate
> authority to be signed, and it's the latter that the committees get
> exercised about.
Sure.
> Hyphenation, readability studies, boutique & frou-frou name schemes
> invented at the Tech University of Mercedes-Benz, and other shooting
> ourselves in the foot can, and should, come later. :-)
I'd be ok with, and would likely even advocate for "If you want your
naming system to be shipped with Tor Browser, it should follow certain
guidelines, including mandatory syntax, a label registry, and etc",
which is a matter of policy.
But that to me is orthogonal to "there should be a flexible way to
offload name resolution" (a matter of implementation).
In practical terms the tor code would need modifications to allow
anything super exotic anyway, and I doubt anything will actually get
shipped with Tor Browser[0] till long after prop 224 is fully
implemented.
Regards,
--
Yawning Angel
[0]: As much as I hate the fact that port 80 and 443 are basically the
only things that matter, that's basically the situation.
pgpmAOpHG284K.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] Comments on proposal 279 (Name API)
On Fri, 7 Apr 2017 11:44:03 +0100 Alec Muffett <alec.muff...@gmail.com> wrote: > If I was in charge, I would say that we risk overthinking this, and it > would be better to: > >- mandate use of fully DNS-compliant syntax, including but not > limited to: acceptable max length, max label length, charset and > composition Fully DNS-compliant only limits max length and max label length, unless there's something that supersedes RFC 2181. I'm fine with both of those restrictions. >- declare a registry of short, valid labels, in the > second-from-right position in the name >- reserve "tor" and "name" in that registry (ie: *.tor.onion, >*.name.onion) >- park the entire issue for 12 months I intentionally left a lot of this unspecified because one of the use cases I envisioned was an "/etc/hosts" analog that lets users easily: * Stick all their hidden services under their own name hierarchy. eg: git.yawning -> .onion * Increase mobile quality of life by aliasing their HSes to addresses consisting entirely of emojis. eg: . -> .onion * Force redirect any site to anything else, really. eg: git.example.com -> .onion banner.ads.and.malware.example.com -> 127.0.0.1 social.spacebook.trackers.example.com -> 127.0.0.1 I could do this with MapAddress, but a plugin would make my life easier, especially since it beats editing multiple torrc files. (Going further into this rabbit hole, I assume most exits won't resolve the OpenNIC TLDs... What do I do if I want to view `example.pirate` or whatever over Tor?) > Hence "parking" the issue because this is all meaningless until > prop224 addresses ship, and there should be plenty of time in the > next 12 months for people to think about how to fill the usability > space with $PET_IDEA, and to my mind the changeover period between > 80-bit and 256-bit addresses should be long enough that nobody need > fret about it right now. IMO the existing onion addresses already are a usability disaster. It should be easy for researchers to experiment with designs to solve the problem *now* before prop224 addresses make a bad situation worse. There's also a world of difference between implementing/shipping the capability to override the name resolution via plugins, and "Shipping the YawningCoinNamezTLD plugin with Tor Browser, enabled by default". Regards, -- Yawning Angel pgpcFgEVzbcBe.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] Control-port filtering: can it have a reasonable threat model?
f the user configures it that way, otherwise, all it can do is repeatedly NEWNYM" is what I think I ended up with. Though I have the benefit of being able to force all application network traffic through code I control, which makes life easier. Regards, -- Yawning Angel pgptOXuQ3TKU8.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] Pluggable Transports 2.0, draft 1 Specification
On Mon, 27 Mar 2017 04:03:47 -0500 Brandon Wiley <bran...@blanu.net> wrote: > I am familiar with the dual stack problem generally, where servers > have both IPv4 and IPv6 IP addresses. I was not involved in any > conversations regarding the dual stack problem for Pluggable > Transports specifically. If you could point me to any documentation > on this issue, that would be helpful. Alternatively, if you could > explain what the issue is and what possible solutions you'd like to > see in a future Pluggable Transports specification, that is something > we could make happen in future specifications revisions. None of the things I've mentioned are new concerns, and I brought all of them up (and more) a long time ago back when I was giving thought to the PT spec. I've basically given up at this point, and to be honest I gave up shortly after I initially started making noises about improving the spec because it was clear that while I was trying to improve the existing interface while preserving the overall architecture, everyone else was far more interested in "lets make everything into a bunch of library code". https://lists.torproject.org/pipermail/tor-dev/2015-September/009432.html https://trac.torproject.org/projects/tor/ticket/21261 https://trac.torproject.org/projects/tor/ticket/11211 Regards, -- Yawning Angel pgp_mZKMWdACY.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] Proposing "Post-Quantum safe handshake implementation" as GSoc Project
On Thu, 23 Feb 2017 00:01:29 + isis agora lovecruft <i...@torproject.org> wrote: > > The bad news is that, work on it is on going, and it does not make a > > good GSOC project because, the bulk of the implementation work will > > likely happen before the summer. > > It will? Probably? If people take what I say out of context, or as a promise of anything, they may end up disappointed, but I don't really care. > > > 2. Implement the NewHope-Simple algorithm[1] because we'll not be > > > able to use the Vanilla NewHope as it is protected by some > > > patents. I wasn't able to find any implementation of NewHope > > > Simple. So can the Vanilla NewHope Implementation be tweaked to > > > convert it into NewHope Simple? Or would we have to write it from > > > ground up? I don't know about the patent laws regarding it. > > > > I haven't talked to Peter in a while (and will ask him after I send > > this), but I am not aware of any patent claims against the vanilla > > NewHope algorithm (and the NewHope-Simple paper does not mention > > this at all either). > > Sorry, I'm being deliberately vague about this because I don't want > to feed the patent trolls or provide a weapon to anyone who wants to > fight against good crypto, but the patent exists, and it affects > nearly all lattice-based handshakes. NewHope simple is not affected. I spoke with some people and got filled in. I'm not going to look at the claim, because that's something for a legal department somewhere to sort out, and not my problem. Since the Simple variant is easier for others to implement, and sidesteps the random asshats issue, I don't think this is a big deal anyway. Regards, -- Yawning Angel pgpdnajay_jz2.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] Proposing "Post-Quantum safe handshake implementation" as GSoc Project
On Sat, 18 Feb 2017 14:07:40 +0530 Jaskaran Singh <jvsg1...@gmail.com> wrote: > I'm particularly interested to work on making TOR Handshakes > Post-Quantum Safe. I feel that this should be implemented at the > earliest because adversaries could store the network traffic and > decrypt it later on using Quantum Computers when they're invented. So there's good news and bad news. The good news is that PQ handshake stuff will happen, sooner rather than later. The bad news is that, work on it is on going, and it does not make a good GSOC project because, the bulk of the implementation work will likely happen before the summer. [snip] > 2. Implement the NewHope-Simple algorithm[1] because we'll not be able > to use the Vanilla NewHope as it is protected by some patents. I > wasn't able to find any implementation of NewHope Simple. So can the > Vanilla NewHope Implementation be tweaked to convert it into NewHope > Simple? Or would we have to write it from ground up? I don't know > about the patent laws regarding it. I haven't talked to Peter in a while (and will ask him after I send this), but I am not aware of any patent claims against the vanilla NewHope algorithm (and the NewHope-Simple paper does not mention this at all either). That said, implementing NewHope-Simple is trivial given NewHope (an afternoon if that), so it's not something that worries me much. Regards, -- Yawning Angel pgpfwXt5HySuw.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] Prop224 oppurtunity: keygen, crypt, sign, encoding tools
On Thu, 16 Feb 2017 16:59:00 + Vi Grey <vig...@riseup.net> wrote: > I can take a shot at it if people are okay with it being written in > Go. I'm not sure if Yawning would be willing to do a review of the > code, as I know Yawning does Go stuff. I would need to build this > functionality in a project I'm working on anyways. This sort of tooling should (IMO) ideally be written in C, like `tor-gencert`. Don't let my opinion here stop you or anything, and it's just my opinion and does not reflect that of anyone else. Regards, -- Yawning Angel pgpyUrdmhe0TU.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: sandboxed-tor-browser-0.0.3
Hello, I just tagged sandboxed-tor-browser 0.0.3. Binaries will be built when the next Tor Browser build happens (soon). The dependencies (both build and runtime) have changed, end users should install `libnotify` in the unlikely event that it is not already present, though basic functionality should not be broken even if it is missing. The major changes since last version are: * 32 bit x86 support has been deprecated. * Numerous installer/updater improvements including periodic background update checks (requires libnotify for notifications) and using `.onions` when fetching installer/updater metadata. * Fixes for various crash/functionality bugs, including problems relating to certain versions of bubblewrap failing to launch with errors related to `setsid`[0]. Full details are available in the ChangeLog, and the code is still at https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/ Regards, -- Yawning Angel [0]: If people are encountering this, particularly with the Debian package, either upgrade `sandboxed-tor-browser` to the new release, or update bubblewrap to 0.1.7 or later. pgpvVzcP1lEqo.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] archive.is and archive.fo are using CloudFlare. Is the TorBrowser add-on cfc useless now?
On Wed, 18 Jan 2017 12:15:05 +0100 Christian Pietsch <christian.piet...@digitalcourage.de> wrote: > Considering that cfc was created in order to evade the CloudFlare > captcha, this is quite a disappointment. Is cfc useless now? Can it be > fixed? It was a proof of concept that I no longer have time to work on. > What is the reason why archive.org is not used? I hear they are almost > done setting up an onion service for the Internet Archive. Because, out of all the similar services that are available, I like archive.is the most. Regards, -- Yawning Angel pgpsmCmx8FO59.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] non-anonymous ephemeral onion services with stem
On Wed, 28 Dec 2016 12:19:17 -0800 Micah Lee <mi...@micahflee.com> wrote: > And when other processes connect to the Tor control port and run > create_ephemeral_hidden_service, those onion services wouldn't be > non-anonymous? They'll be non-anonymous (as in, the options are global). This also will not work if there is a SOCKS port configured. Basically, unless you are launching your own copy of the tor daemon, just for non-anonymous HSes, it's a terrible idea to use these options in general. Regards, -- Yawning Angel pgpA9Ze34XqQF.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] Can I modify obfs4 proxy code for my purpose?
On Fri, 16 Dec 2016 15:17:20 +0100 (CET) <trmo...@tutanota.com> wrote: > 1. I wanna build a password protected obfs4 proxy sever with my VPS. > I don't need that much privacy in terms of MITM for this. > I just wanna know if it is ok to build such server in Tor network. Huh? I don't see the point since client access requires a priori knowledge of the server's public key. I probably won't merge changes, but as long as you comply with the license I don't care. Regards, -- Yawning Angel pgpGoi22epWzS.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] Release: sandboxed-tor-browser 0.0.2
On Tue, 13 Dec 2016 22:33:34 -0500 Roger Dingledine <a...@mit.edu> wrote: > I also look forward to the binaries that are coming this week. I > imagine there will be some sharp edges for folks whose Linux distro > doesn't easily come with the right version of bubblewrap -- so it > would be great if people here could help us identify and resolve > those sharp edges. The only system(s) where this is an issue as far as I know is Ubuntu and derivatives (Unless you don't trust AUR, in which case, Arch Linux also doesn't have a package). It's worth keeping in mind that the only place (by design) that the sandbox code checks for the `bwrap` binary is `/usr/bin/bwrap` because people should be getting their bubblewrap from a trusted source, and I am envisioning a bright future when it's available as a package for all distributions. Regards, -- Yawning Angel pgpoaSz3CAKUu.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: sandboxed-tor-browser 0.0.2
Hello, I tagged sandboxed-tor-browser 0.0.2 (0.0.1 is also tagged, but it has a few issues), so this is the obligatory release announcement. Official binaries should be available sometime next week, so I strongly suggest that people wait till then, unless they feel confident in installing the build time dependencies, and building the binary. This is the non-developer alpha version of the sandboxing approach outlined in: https://lists.torproject.org/pipermail/tor-dev/2016-September/011444.html A lot has changed since then, the primary changes are numerous improvements to the sandbox, the addition of graphical UI, and the removal of the "you need a tor daemon as a system service" requirement. It is still very much an alpha (up from a proof of concept tech demo), so there will be rough edges and bugs, some potentially major. Features: * A Gtk+3 based UI for downloading/installing/updating Tor Browser, configuring tor, and launching the sandboxed browser. Think `tor-browser-launcher`, that happens to run Tor Browser in a bunch of containers. * Linux seccomp-bpf + namespace based containers for Tor Browser, that attempts to prevent/mitigate exploits and reduce the amount of personally identifiable information to a minimum, centered around bubblewrap (runtime dependency). Known system incompatibilities: * 64 bit kernel, 32 bit userland is not supported. * X32 (x86_64 with 32 bit pointers) is not supported. If you have to ask what this is, and how it's different from normal 32 bit x86, you don't have it. * Systems that do not store the dynamic linker/loader cache in `/etc/ld.so.cache` in glibc 2.2 format are not supported. * Ubuntu does not have a sufficiently recent bubblewrap package available for any current release, up to and including `yakkety` (16.10). The package that is available in `universe` SHOULD NOT be installed, and WILL NOT work. Errata: * On systems where gstreamer libraries are pulled in as part of the base firefox runtime dependencies, the libraries can find their way into the sandbox without the need for explicit user intervention, if "Extra Audio/Video Codecs" is enabled in the sandbox configuration. As far as I am aware, and on the systems I have tested, none of the modern distributions have system libraries built this way. If the sandbox manages to launch Tor Browser with the option disabled, you are not affected by this. The exact functionality, usage, and caveats are documented at: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux The code is at: https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/ Regards, -- Yawning Angel pgpOyKIkmUfTt.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] TBB Isolation Impact on Alternative Anon Nets
On Mon, 05 Dec 2016 17:08:17 +0100 ban...@openmailbox.org wrote: > TBB sandboxing is a great hardening measure. I was wondering if there > are side-effects such as breaking setups that involve using anonymous > networks other than Tor. Such as: > https://thetinhat.com/tutorials/darknets/i2p-browser-setup-guide.html Well, i2p doesn't expose a tor control port, so that would break, yes. > As a workaround we can document how to toggle the TBB variable to > disable this. Of course the best solution is having the isolation > compatible with alternative setups if you consider this (minority) > use-case worthy of your effort. It's not a TBB variable. All of this stuff will be opt-in for the near/medium future anyway (eg: under Linux, the sandboxing component will be a separate download). The initial release will not have support for things like this at all. So the answer is, don't use the Linux sandboxing stuff until this sort of thing is supported, if you have a really exotic config that you want to have work[0]. Regards, -- Yawning Angel [0]: The version number is going to be "0.0.1", and as of now I'm far more concerned with getting the common use cases fully supported. pgpAqGpr5NsYS.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] prop224: What should we do with torrc options?
On Thu, 24 Nov 2016 11:13:06 +1100 teor <teor2...@gmail.com> wrote: > > On 24 Nov. 2016, at 11:04, Yawning Angel <yawn...@schwanenlied.me> > > wrote: > > > > On Thu, 24 Nov 2016 01:43:15 +0200 > > s7r <s...@sky-ip.org> wrote: > >> I agree that this would be "the technical way" to do it, but real > >> world usability kind of prevents us to do it this way. The spec for > >> ADD_ONION indeed does not say that v2 hidden services will be > >> supported forever and it clearly SHOULD NOT, but it also doesn't > >> make much sense to abolish it at the first Tor release supporting > >> v3 services (because if we make ADD_ONION == v3 (best) this is > >> what we are doing). > > > > Even I don't think `BEST` should be changed to Ed25519 immediately, > > especially when the code is being stabilized. > > So I think we should have an option: > > OnionServiceCreateV3 0|1 > > Create V3 onion services by default when using HiddenServiceDir and > ADD_ONION BEST. > > Which defaults to 0 for at least the first release containing the new > code, and then defaults to 1 for at least one release, and then > is deprecated. This seems like a sensible plan to me. -- Yawning Angel pgpq2OHmTkmu_.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] prop224: What should we do with torrc options?
On Thu, 24 Nov 2016 01:43:15 +0200 s7r <s...@sky-ip.org> wrote: > I agree that this would be "the technical way" to do it, but real > world usability kind of prevents us to do it this way. The spec for > ADD_ONION indeed does not say that v2 hidden services will be > supported forever and it clearly SHOULD NOT, but it also doesn't make > much sense to abolish it at the first Tor release supporting v3 > services (because if we make ADD_ONION == v3 (best) this is what we > are doing). Even I don't think `BEST` should be changed to Ed25519 immediately, especially when the code is being stabilized. That is a completely orthogonal to the fact that people that have dumb limitations like: > Bitcoin Core - latest versions detect if you use Tor and automatically > use ADD_ONION to create v2 services, and, important: it doesn't > support yet the v3 address types because of their length. This way > people behind NAT running it can be better connected by accepting > incoming connections without an open port, some people don't want > their upstream provider to know they are using this app, etc. Should be using `NEW:RSA1024` explicitly. The override is there for a reason, and the key type is part of the serialized data that tor returns to you when you have it generate a key, precisely to avoid this sort of problem. Their fix: "Replace line 473 of bitcoin/torcontrol.cpp with `private_key = "NEW:RSA1024";`". Our fix: "Add another command, that does essentially the same thing, because people picked the wrong options, then later deal with the fallout from people getting used to the temporary command, and crying when it's deprecated." I say "they should fix their code". > I don't think it's productive to ask users to already support a new > feature upon our first release providing the said feature. If they aren't using existing interfaces correctly, when correct behavior has been part of the interface since support for it was added, quite frankly it's their problem. Regards, -- Yawning Angel pgpyANCyxWO1_.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] prop224: What should we do with torrc options?
On Thu, 24 Nov 2016 01:18:46 +0200 s7r <s...@sky-ip.org> wrote: > Yes, this looks good to me as well. As for ADD_ONION, I think we > should give the people that use it automatically for other apps a > change until they upgrade to be compatible with v3, so for the > transition period as long as v2 is supported (but not recommended) in > the network, ADD_ONION controller command will create a v2 service, > and we add another controller command: ADD_ONIONV3 that will create > v3 services. When v2 is permanently gone, we make ADD_ONION a synonym > to ADD_ONIONV3, remove the RSA1024/SHA1 code and we're all set. What. Why. Anyone right now, that explicitly wants a v2 service going forward, should use `ADD_ONION` correctly. It takes the type of key for a reason. Regards, -- Yawning Angel pgp2wVUuKfIgH.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] prop224: What should we do with torrc options?
On Wed, 23 Nov 2016 03:12:22 +0400 meejah <mee...@meejah.ca> wrote: > David Goulet <dgou...@ev0ke.net> writes: > > > 1) Once v3 is released, from that point on _no_ v2 service will be > > allowed to be created by "tor" itself. It will always be possible > > to do it by hand by creating an RSA key and putting it in the > > service directory (see 3 below). > > +1 or +2 at least :) > > > Ok here it is. Please comment, improve, or propose! :) > > How does ADD_ONION fit in? It's forward compatible by design, since you have to specify a key type when you handle key management, and Tor gets to do whatever it wants if you ask it to generate a key with the `BEST` algorithm. Assuming people who use it aren't explicitly asking for RSA1024, their apps will magically switch to using Ed25519 automagically one day, when their tor is updated. (People who expect `NEW:BEST` ADD_ONION-ed services to always give RSA1024 based HSes, should fix their code since the spec makes no guarantee that `BEST` will be RSA1024.) Regards, -- Yawning Angel pgpM1AZw5zcVy.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.7.
Hello all, I just tagged obfs4proxy-0.0.7. This affects relay side functionality and fixes bugs, so it is a recommended upgrade for relay operators. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.7.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.7.tar.xz.asc Changes in version 0.0.7 - 2016-11-15: - Support configuring the obfs4 IAT parameter as the sole ServerTransportOption on bridges, and correctly checkpoint the argument to the state file. - Correctly use the derived epoch hour when generating the server obfs4 ntor handshake response to be more tollerant of clock skew. - Reuse the read buffer when consuming obfs4 frames over the network to reduce memory consumption. Patch by oxtoacart. Thanks to the Lantern people for the memory consumption fix. Regards, -- Yawning Angel pgppffwG5KkO7.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] [Proposal] A simple way to make Tor-Browser-Bundle more portable and secure
On Sun, 30 Oct 2016 15:19:59 -0500 Tom Ritter <t...@ritter.vg> wrote: > On Oct 29, 2016 12:52 PM, "Yawning Angel" <yawn...@schwanenlied.me> > wrote: > > > > On Sat, 29 Oct 2016 11:51:03 -0200 > > Daniel Simon <ddanielsim...@gmail.com> wrote: > > > > Solution proposed - Static link the Tor Browser Bundle with musl > > > > libc.[1] It is a simple and fast libc implementation that was > > > > especially crafted for static linking. This would solve both > > > > security and portability issues. > > > > This adds a new security issue of "of all the things that should > > have ASLR, it should be libc, and it was at one point, but we > > started statically linking it for some stupid reason". > > If this is accurate, that statically linking will enable pre-built rop > chains because libc is at a predictable memory address, I would > strongly oppose it for this reason alone. > > It would be a major step backwards in security. The right thing *might* happen, if you build everything with -fPIE (Tor Browser does this), for "libc symbols being in consistent locations relative to the randomized base address of the executable" definitions of "right thing". This is subtly different from "libc symbols are at consistent locations relative to the randomized base address of the library, for that exact copy of libc", when using a dynamically linked libc. Life is a lot better with selfrando, so in practice my objections on this ground mostly go away in the hardened build, since it applies load time randomization to all the functions (RANDOMIZE ALL THE THINGS). All that said I'm still not convinced why "the user may use a different glibc than other users" on it's own is a compelling reason to ship a statically linked libc: 1) Tor Browser pulls in lots of other things from the host system, some unconditionally (X11, Gtk+), some depending on availability (GNOME, libthai, etc). Only fixing libc seems like it doesn't help much (and I suspect that glibc version diversity isn't that large to begin with). I sincerely doubt that the Tor Browser developers want to be in the business of compiling Xorg, Gtk+ or $deity help them, GNOME. 2) I don't see why this needs to be "statically linked". Tor Browser ships other libraries as dependencies (libevent, openssl, libstdc++), and unless libc is magically special, it could be shipped as yet another shared library. In particular, there is no performance gain to be had by statically linking things because Tor Browser is built -fPIE. 3) Regarding portability, I'm not sure I understand "The Tor Browser Bundle can't be run on systems that don't use glibc, making it unusable due to different syscalls" argument. System calls are provided by the kernel, and have nothing to do with libc. Assuming the author meant "ABI compatibility issues"... If there are bugs that arise from "a Tor Browser component assumes/requires non-standard glibc behavior at the source level" then that should be fixed. Most of these things are probably upstream Firefox issues. As far as runtime compatibility goes, this is a lot of work (initially and continuing) to support the fraction of the userbase that's using a rather non-standard libc. I do not know if the Browser developers have such resources. nb: Not a browser developer, they will chose to do what they wish. Regards, -- Yawning Angel pgpHFc_oU8BQF.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] [Proposal] A simple way to make Tor-Browser-Bundle more portable and secure
On Sat, 29 Oct 2016 11:51:03 -0200 Daniel Simon <ddanielsim...@gmail.com> wrote: > > Solution proposed - Static link the Tor Browser Bundle with musl > > libc.[1] It is a simple and fast libc implementation that was > > especially crafted for static linking. This would solve both > > security and portability issues. This adds a new security issue of "of all the things that should have ASLR, it should be libc, and it was at one point, but we started statically linking it for some stupid reason". Having to rebuild the browser when the libc needs to be updated seems terrible as well. > > What is Tor developers' opinion about this? I personally don't see > > any drawbacks and would be interested in discussing this further. There, opinions. Regards, -- Yawning Angel pgpxDkrgsynV0.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] performance of CREATE/CREATED handshake
On Thu, 13 Oct 2016 15:05:05 +0200 Rob van der Hoeven <robvanderhoe...@ziggo.nl> wrote: > This is what I was looking for. Running the benchmark on two very > different systems was revealing: on my Pentium G620 the ntor > server-side time was ~300 uSec, an Allwinner A20 system completed the > server-side code in ~10600 uSec. One of the things on my TODO list is to use NEON for the X25519 scalar mult on ARM targets that are capable of such since it's a decent performance increase, at least on 32 bit ARM. One day I will also get an Aarch64 target and figure out optimization there, since it's the way of the future. Regards, -- Yawning Angel pgpqs3v89ZtsZ.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] performance of CREATE/CREATED handshake
On Wed, 12 Oct 2016 13:37:24 +0200 Rob van der Hoeven <robvanderhoe...@ziggo.nl> wrote: > 2) The average CPU-time it takes to perform a CREATE/CREATED > handshake. This "depends" entirely on your CPU and which handshake is used, though I don't particularly consider TAP handshake performance relevant because it is slow and superseded by ntor. `src/test/bench` will give concrete numbers (~140 usec on a modern Intel processor). Regards, -- Yawning Angel pgpXVP7Ehjree.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] Proposal 273: Exit relay pinning for web services
On Wed, 5 Oct 2016 16:09:15 -0400 Philipp Winter <p...@nymity.ch> wrote: > The proposal is in draft state. We have several open questions that > we are still wrestling with in Section 2.6. Any feedback is greatly > appreciated. You can track the evolution of our proposal online: > <https://github.com/NullHypothesis/exit-pinning> Seems reasonable, but How is this better than "Tor Browser will honor and aggressively utilize onion addresses in Alt-Svc headers[0]". Eg: Alt-Svc: onion="onionsarelongandsilly.onion:443"; ma=86400 Regards, -- Yawning Angel [0]: https://tools.ietf.org/html/rfc7838 pgpzT1xmkebfr.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] More tor browser sandboxing fun.
On Wed, 21 Sep 2016 23:31:27 +0200 Stanisław Kosma <sta...@riseup.net> wrote: > At this point no further audit of X11 is necessary. It is well > understood that it is insecure by design. In fact why would you need > an audit, take look at X11 API for yourself: > * X11 client: Please send me all keyboard events > * X11 server: As you wish Indeed. This is part of it, yes. > That does not mean that you are without options. Firejail X11 > sandboxing guide [0] recommends running X11 applications inside a > separate X11 server (like Xpra or Xephyr). If anything I'd opt to use xf86-video-nested, but really the correct answer is "Use Wayland". There shouldn't be anything stopping people from using a nested X solution with sandboxed-tor-browser, since it honors DISPLAY and writes out a new ~/.Xauthority in the sandbox tmpfs, as long as the secondary X server puts the AF_LOCAL socket in the traditional location under /tmp. > If you combine this with Flatpak or Snappy, maybe something good will > come out of this. I would rather bet on Flatpak [1]. It is not there > yet, but seems to be solving right problem. bubblewrap is the sandboxing implementation used by Flatpak, so there's already a good amount of code reuse. I could have opted to re-package Tor Browser as a Flatpak app, and my launcher approach re-implements lots of functionality provided by Flatpak, however: * I wanted to do things that required (at the time) bubblewrap git master. * Flatpak has it's own install/update infrastructure. I'd rather avoid having to repackage the bundle and updates. This way, the only infrastructure that's used is the Tor Project stuff that already exists, and people don't have to trust me that I did such things correctly. * Doing things this way gave me more control over the sandbox environment. -- Yawning Angel pgp3SdAZl2YPc.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] More tor browser sandboxing fun.
Hi, Note: * Don't use this unless you are capable of debugging it. * Don't use this if you need strong security (though the author believes it is an improvement over unsandboxed Tor Browser, and the previous sandboxing attempts). * Don't re-package it, it's not ready for that. In addition to stewing in my infinite self-loathing, I made a serious attempt at sandboxing Tor Browser again. It works, is kind of neat, and isn't totally horrible, so I'm showing what's available. Where: https://git.schwanenlied.me/yawning/sandboxed-tor-browser This builds a lightweight launcher process that will: * Handle installing/updating Tor Browser, while being rather paranoid about having a good trust root (hard copies of PGP keys, the update service's cert chain, and the MAR signing key are included and enforced). * Run the updater in a sandboxed environment without network access. * Run Tor Browser in a sandboxed enviornment with the Tor SocksPort being the only way to get beyond the host. There's a bunch of caveats, and some functionality that's intentionally broken, and certain annoyances that require a Tor Browser patch or two to fix, but it appears to work fairly well. The README.md file has more detailed documentation on how it works, the sandbox environment, and the various caveats. -- Yawning Angel pgp9rUAnxRERr.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] How to query HS hostname from control port
On Thu, 08 Sep 2016 22:44:42 +0400 meejah <mee...@meejah.ca> wrote: > > Anyone who wants to open a ticket here, or has a counter > > argument? :) > > As a *slight* counter-argument to adding on-disk services to the > GETINFO, that would make it harder to distinguish between on-disk > services and ADD_ONION -based ones. Not sure how much of a practical > problem this is, though (worst-case would be that a controller would > have to load all 'hostname' files to confirm which ones are on-disk > vs. ADD_ONION). Perhaps a *third* GETINFO, e.g. "GETINFO > onions/permanent" would be safest...? Adding a third option would probably be the best, followed by extending the response syntax. As I said, the `GETINFO` stuff was added explicitly along and for the `ADD_ONION` command, with semantics to match. Regards, -- Yawning Angel pgpic5de9hs8Z.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] How to query HS hostname from control port
On Thu, 08 Sep 2016 13:55:05 +0300 George Kadianakis <desnac...@riseup.net> wrote: > I guess a side question here is why those GETINFO commands only > return the ephemeral onion services and not all of them. Because when I added it, it was part of the ADD_ONION code, and I was too lazy to make it cover the other stuff. > Anyone who wants to open a ticket here, or has a counter argument? :) Beyond the usual concerns of "the control port allows access to too much, and has no concept of isolation or ACLs, and this would be a step towards the worse", not really. Regards, -- Yawning Angel pgpnyUWOb1Zrr.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] Pluggable transport idea: TLS session resumption
On Wed, 7 Sep 2016 14:24:12 -0700 David Fifield <da...@bamsoftware.com> wrote: > The protocol as just described would be vulnerable to active probing; > the censor could test for servers by sending them garbage session > tickets and seeing how they respond. But that's easy to fix. We can, > for example, let the client and server have a shared secret, and have > the server treat the session ticket as the client part of an obfs4 > handshake--which conveniently resembles a random blob. If the session > ticket doesn't pass obfs4 authentication, then the TLS server can > respond as it naturally would if a client sent an invalid session > ticket; i.e., issue a new ticket and do a full handshake (then send > dummy data, I guess). The server can also honor its own legitimately > issued tickets, but still send dummy data in response. Only clients > who know the shared secret will be able to access the proxy > functionality of the server. Don't use the obfs4 handshake for this (or anything new, really). It's possible to do better. > In order to block such a transport, the censor will have to look at > features other than the server certificate. It could, for example: > * block all session tickets (dunno how costly that would be) That's not really feasible, since the correct behavior is to fall back to the standard handshake, being that this is an optimization. Though this depends on what clients do when the connection process is closed after the ClientHello is sent. > * statefully track which tickets servers have issued, and block >connections that use an unknown ticket. This is probably feasible, particularly by the sort of people that have been looking at ClientHello already anyway. Regards, -- Yawning Angel pgpddkLfzEkmq.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] How to query HS hostname from control port
On Mon, 5 Sep 2016 09:01:01 -0400 Jesse V <kernelc...@riseup.net> wrote: > On 09/05/2016 12:43 AM, meejah wrote: > > Could you use ADD_ONION instead? Why are you using the on-disk API > > if you don't want to give your thing permission to read those > > directories? > > I'll consider it, but I want the onion service to be relatively > permanent. It would best if the hostname didn't change every time tor > restarted. You realize that ADD_ONION supports using an existing private key right? Like this: ADD_ONION RSA1024:[Blob Redacted] Port=80,192.168.1.1:8080 Regards, -- Yawning Angel pgpEl9QFnDfsy.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] Further sandboxing Tor Browser (aka Tor + Firejail redux).
On Fri, 22 Jul 2016 15:20:00 + Patrick Schleizer <patrick-mailingli...@whonix.org> wrote: > I think this could be wrong: > > TOR_CONTROL_COOKIE_AUTH_FILE=/var/run/tor/control_auth_cookie That block was supposed to be in a bunch of if statements. Fixed. The default path that gets set is unchanged. > Debian /usr/share/tor/tor-service-defaults-torrc uses: > CookieAuthFile /var/run/tor/control.authcookie So? I don't use Debian for development. > Common paths are: > - /var/run/tor/control.authcookie > - /var/lib/tor/control_auth_cookie I write software for me, default configs will continue to reflect how my development environment is setup. I assume people can use setenv/export to override it, or if it bothers them that much, use vi/nano/pico/ed/ex/emacs/xemacs. As a side note, there's zero real reason for this particular env var to exist at all (See #16017), beyond "no one has cared enough to write what should be a simple branch". Regards, -- Yawning Angel pgp6r8Yi9bwDg.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Further sandboxing Tor Browser (aka Tor + Firejail redux).
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 36d849291ec0b20a582cd846fcd2540c9bbe, sending NEWNYM should be unnecessary if domain isolation is applied to everything). Regards, -- Yawning Angel pgpSoO0kTZ48l.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] SHA-256 checksum mismatch
On Thu, 02 Jun 2016 03:59:04 -0400 Tuuranton <tuuran...@protonmail.ch> wrote: > The SHA-256 checksum of the downloaded file > https://www.torproject.org/dist/torbrowser/6.0/TorBrowser-6.0-osx64_en-US.dmg > is on my computer > 0f4f6ca01028c2956c811dd94d67a76feb507cad176c031f32e6f95873003b4c > > the SHA-256 checksum of the file > TorBrowser-6.0-osx64_en-US.dmg > should be > d68d01889ba38764ebf2057b3cd3263f638a74205031a6d1df11ab8ca13a3618 > > > Why the mismatch? "sha256sums-UNSIGNED-build.txt" Guess the actual release blog post didn't carry over the blurb covering this (though 6.0a5 did): > We plan to post instructions for removing the code signing parts on > our website soon. This should make it easier to compare the bundles > we build with the actual bundles we ship. The instructions don't exist yet, see #18925. Regards, -- Yawning Angel pgpzl3AUBi06f.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] Memory usage of Tor daemon
On Fri, 20 May 2016 12:03:59 -0400 Tim Wilson-Brown - teor <teor2...@gmail.com> wrote: > > On 20 May 2016, at 11:59, Yawning Angel <yawn...@schwanenlied.me> > > wrote: > > > > What's strange about it. The client does the path selection. To > > build a circuit, the client must know the public keys/ip/port for > > the entire path and the exit policy. > > Clients could get away with only knowing the key fingerprints for > relays in their paths, except for their Guards, which are the only > relays they connect to directly. (This might mean a protocol > redesign, because I think we send IP and port as well as fingerprint > at the moment.) There's a reason why the EXTEND2 cells contain an IP/port, and also why nodes don't enforce "traffic was from/is to something in the consensus". The current existing design requires exactly what I stated (Everything required for a client to craft an `EXTEND2` cell with a ntor payload). > But do we really need to? No. The person is complaining about something with 16 MiB of non-volatile storage anyway. In general I would be against clever crypto based approaches to limit the amount of data the client downloads, just because "client knows everything and does path selection" is easy to reason about/analyze/implement. Maybe in the extreme long term this will make sense. Regards, -- Yawning Angel pgpTjMnf5PvJc.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] Memory usage of Tor daemon
On Fri, 20 May 2016 12:03:35 +0200 Rob van der Hoeven <robvanderhoe...@ziggo.nl> wrote: > This worries me. If in the future the router list grows, my router > (and many other routers running Tor) can run out of memory. For me, > it looks a little bit strange to have an in-memory database of the > router list. Is there a reason for having this data in memory? And, > can something be done about it? What's strange about it. The client does the path selection. To build a circuit, the client must know the public keys/ip/port for the entire path and the exit policy. A few things could be done: * Figure out the necessary crytographic trickery to allow client driven path selection without the full microdescriptor list a la TvdW's recent-ish blog post. * Work off the microdescriptors saved to non-volatile storage. Intuitively this seems like a bad idea due to: * This is a lot of code, for a niche use-case. * Similar concerns apply to "the absolute minimum amount of flash that the manufacturer thinks they can get away with" being too small to hold the microdescriptor list. * Most embedded devices probably don't want to be writing out the microdescriptor list to non-volatile storage either, because flash is garbage. * Carry on keeping the working set in RAM under the assumption that manufacturers will ship more RAM in their routers as time goes on. Regards, -- Yawning Angel pgpZj0Moo4rgo.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] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope
On Thu, 12 May 2016 11:58:56 +0200 Jeff Burdges <burd...@gnunet.org> wrote: > On Thu, 2016-05-12 at 05:29 +, Yawning Angel wrote: > > and move the handshake > > identifier into the encrypted envelope) so that only the recipient > > can see which algorithm we're using as well (So: Bad guys must have > > a quantum computer and calculate `z` to figure out which post > > quantum algorithm we are using). > > This sounds like a win. > > We still do not know if/when quantum computers will become practical. > It was only just last year that 15 was finally factored "without > cheating" : http://www.scottaaronson.com/blog/?p=2673 > > We do know that advancements against public key crypto systems will > occur, so wrapping up the more unknown system more tightly sounds > wise. > > > In the shorter term, SIDH would take only one extra cell, maybe none > if tweaked downward, as compared to the four of New Hope, and > whatever NTRU needs. This variation might be good or bad for > anonymity, but it's sound better if fewer nodes can compare the > numbers of packets with the algorithms used. Well, if we move the handshake identifier inside the AE(AD) envelope, we can also add padding to normalize the handshake length at minimal extra CPU cost by adding a length field and some padding inside as well. It would remove some of the advantages of using algorithms with shorter keys (since it would result in more traffic on the wire than otherwise would have been), but handshakes will be indistinguishable to anyone but space aliens and the final destinations... Regards, -- Yawning Angel pgpBkG_E2gckQ.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] RFC-ish: basket2 (aka obfs5)
Hello, So I've been somewhat productive as of late and have been working on the successor to obfs4. I have a "oh my god, you wrote how much code, with no documentation" minimum-viable-product-ish release that appears to work, though ABSOLUTELY NO ONE SHOULD USE IT YET, because I will break bridge line/protocol wire compatibility intentionally at least once before release. The code: https://git.schwanenlied.me/yawning/basket2 (Really, don't use it, at all. I will ignore cries of help, mercilessly mock people that attempt to chase a moving target, and laugh as I break things). The documentation: Hahahahahahahahahahahahahahaha (It should be self explanatory). A brief overview of the improvements: * Client can now negotiate the link padding/delay algorithm at handshake time with the server (no more `iat-mode=blah` argument), and defaults to something which injects delay. * Link cryptography changed to a XChaCha20/Poly1305 construct, with AVX2 used for the ChaCha20 when available, and the framing construct it self is a lot better designed. * Handshake is X25519 + NewHope or X448 + NewHope based (available algorithms specified as part of the bridge line), with X25519 (Elligator2) for authentication. * SHA-3/SHAKE are used as the handshake routines. * When adding IAT on a burst basis, the code attempts to detect bulk data transfer resulting in less delay for large downloads/uploads. * Server side buffering reduced by 50% (not sure if that'll stick, I need to think about some of this stuff). TODO: * Implement a "expensive" padding option for bridges that can afford to run such a thing. (WTF-Pad, CS-BuFlo, or Tamaraw, not sure yet. WTF-Pad is a bit harder to implement than I'd like...) * Improve the lightweight padding algorithms instead of using what is essentially the same as obfs * Finish support for user authentication. * Write a formal specification. * Debug, debug, debug. * Write an AVX2 Poly1305 so it goes faster on boxes that matter (my laptop). * (Maybe) Write NEON and 32 bit x86 assembly optimized versions of the custom crypto, so it runs faster on various low end shit boxes. NEON is more important to me than 32 bit Intel (and a low end Atom does ChaCha20 at 40 MiB/s or so anyway...). Anyway, this is sort of a heads up that something like this is in the works, and is approaching alpha state, though DID I MENTION NOT TO USE IT YET? Questions/Comments/Feedback welcome as always. Regards, -- Yawning Angel pgpJd9awd19ii.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] [Proposal] Obfuscating the Tor Browser Bundle initial download
On Mon, 9 May 2016 15:09:37 -0400 Blake Hadley <moosehad...@gmail.com> wrote: > Hey everyone, > > [How it's currently done] > > Distributed by get...@torproject.com, the URL makes it pretty clear > what you're downloading. > Dropbox: > https://www.dropbox.com/s/mz9ug2rzvj85791/torbrowser-install-5.5.5_en-US.exe?dl=1 > Google Drive: > https://docs.google.com/uc?id=0B76pDbk5No54VHowTEprZnBfWlU=download > GitHub: > https://github.com/TheTorProject/gettorbrowser/releases/download/v5.5.5/torbrowser-install-5.5.5_en-US.exe > > [Security problem] > > The download URL on Google Drive is somewhat obfuscated, but once the > download is started, the filename that the browser requests is > 'torbrowser[...]' > An environment I was working in has started to block the files based > on name, and it would be very easy for an adversary monitoring network > traffic to detect users downloading it. The environment you're were in was mounting a MITM attack to break TLS, or has compromised your box, because the only component of the URL that is visible otherwise is the host in the SNI field. In such an environment, gettor in general isn't unblockable because there is no privacy/security for the request/response messages. Regards, -- Yawning Angel pgpAcHbYWXvYq.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] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope
On Sun, 08 May 2016 02:00:51 +0200 Jeff Burdges <burd...@gnunet.org> wrote: > On Sat, 2016-05-07 at 22:01 +, Yawning Angel wrote: > > how an adversary will be limited to just this information, and not > > things that enable a strong attack on it's own like packet timing > > escapes me > > Yes, it's clear that an adversary who can get CPU timing can get > packet timing. > > It's not clear if some adversary might prefer information about the > seed to simplify their larger infrastructure, like say by not needing > to worry about clock skew on their exit nodes, or even choosing to > compromise exit nodes soon after the fact. The ultimate simplification would be "snoop the loopback interface and see all the cleartext instead of messing with this timing attack nonsense". :P > > Hmm? The timing information that's available to a local attacker > > would be the total time taken for `a` generation. > > Really? I know nothing about the limits of timing attacks. I just > naively imagined they learn from the timing of CPU work vs memory > writes or something. What's there to derive key generation timing information from that isn't "observe traffic to the SocksPort, along with traffic upstream and compare times". There might be better ways, that somehow don't involve totally pwning the box, but it's not immediately obvious to me. If we're going to talk about improving `a` generation overall, rejecting samples only if they are > 5 * q (and using `% q` per sample) is probably a net win since it lowers the rejection rate by a factor of ~4x... Regards, -- Yawning Angel pgp8OzmUl7Hra.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] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope
On Sat, 07 May 2016 23:46:28 +0200 Jeff Burdges <burd...@gnunet.org> wrote: > On Sat, 2016-05-07 at 13:14 -0700, Watson Ladd wrote: > > I'm not sure I understand the concern here. An attacker sees that we > > got unlucky: that doesn't help them with recovering SEED under mild > > assumptions we need anyway about SHAKE indistinguishability. > > We're assuming the adversary controls a node in your circuit and hence > sees your seed later. You get unlucky like over 400 times, so, if > they can record enough of the failure pattern, then their node can > recognize you from your seed. Hmm? The timing information that's available to a local attacker (how an adversary will be limited to just this information, and not things that enable a strong attack on it's own like packet timing escapes me) would be the total time taken for `a` generation. So. the evil observer on Alice's side gets: * The total number of samples (N). Bob (or Eve) gets: * The seed, which may correspond to something that required N samples. I don't think there's much pattern information available to the attacker on Alice's side, but I may be missing something... Regards, -- Yawning Angel pgpKwAhU3ejBu.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] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope
On Sat, 7 May 2016 19:41:59 + (UTC) lukep <lu...@tutanota.com> wrote: > Thanks isis for this, it looks really good, I look forward to seeing a > similar protocol for SIDH! (and X25519+NEWHOPE+SIDH !) When there is a sufficiently fast SIDH implementation, it might be worth considering (MS Research's is less slow than prior attempts at this, but misses the mark). On Sat, 07 May 2016 22:51:27 +0200 Jeff Burdges <burd...@gnunet.org> wrote: > On Sat, 2016-05-07 at 19:41 +, lukep wrote: > > It's hard to guarantee that any fixed, finite amount of SHAKE > > output will be sufficient for any rejection sampling method > > like gen_a. I think that being in the position to gather the timing information required on the client side means the adversary has won already, so I'm not seeing the issue here apart from an abstract theoretical sense. > Isn't some small multiple usually enough? I think 1024 is large > enough to tend towards the expected 42%ish failures. > > Also, can't one simply start the sampling over from the beginning if > one runs out? For clarity regarding what the code does now: The reference code generates excess output from the initial SHAKE call, and samples from that, and incrementally squeezes out an additional block one at a time as required (Enough for 1344 elements, with each additional squeeze providing 21 elements). (The rejection sampling algorithm is somewhat wasteful since it discards 2 bits of input per sample as well, but what's done now is easier to implement.) > I've no idea if an maybe an arithmetic coding scheme would be more > efficient. > > > Or let a be a system-wide parameter changing say on a daily basis? > > I mentioned using the Tor collaborative random number generator for a > in my other message, but only as feint to get to the meat of my > argument that Isis and Peter's proposal sounds optimal. I think > rotating a network wide a would get messy and dangerous in practice. > > If bandwidth is an issue, then a could be derived from the ECDH > handshake, thereby making it zero cost. Err. I'm not sure how that will work without rejection sampling that exposes timing information, maybe I'm missing something. I had a brief discussion with Dr. Schwabe regarding using deterministic `a` generation for unrelated reasons, with something time based being tossed around, but requiring a global clock isn't that great, and leaks clock skew information (Though I would use something like H(tweak | unixTime / 3600), which is rather coarse...), and as a peace of mind thing, I do prefer randomizing `a` on a per-connection basis. But anyway like I said, I don't think this is an issue. Regards, -- Yawning Angel pgpNMRQIf9EPO.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] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope
On Fri, 6 May 2016 19:17:11 + isis <i...@torproject.org> wrote: > [XXX We think we want to omit the final hashing in the production > of NTOR_KEY here, and instead put all the inputs through SHAKE-256. > --isis, peter] > > [XXX We probably want to remove ID and B from the input to the > shared key material, since they serve for authentication but, as > pre-established "prologue" material to the handshake, they should not > be used in attempts to strengthen the cryptographic suitability of > the shared key. Also, their inclusion is implicit in the DH > exponentiations. I should probably ask Ian about the reasoning for > the original design choice. --isis] Oh I missed this. B at a minimum needs to be part of `auth_input`, though probably does not need to be part of `secret_input`. Per RFC 7748: Designers using these curves should be aware that for each public key, there are several publicly computable public keys that are equivalent to it, i.e., they produce the same shared secrets. Thus using a public key as an identifier and knowledge of a shared secret as proof of ownership (without including the public keys in the key derivation) might lead to subtle vulnerabilities. Regards, -- Yawning Angel pgpwL77iPpQGl.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] Quantum-safe Hybrid handshake for Tor
On Wed, 20 Apr 2016 18:30:14 + (UTC) lukep <lu...@tutanota.com> wrote: > Beware that the definition of newhope has changed! The authors have > published a new version of this paper and some of the numbers are > different. The parameter for the binomial distribution has changed > from 12 to 16, the probability of failure has changed from 2^-110 to > 2^-64, the core hardness of the attack has increased from 186 to 206 > bits on a quantum computer, and the timings have increased slightly > too. I track the paper and reference code in the implementation I maintain. FWIW, the performance hasn't changed noticeably, unless there's something newer than 20160328. > I'm not sure that the newhope algorithm has settled down yet. There's > also a new paper on IACR called "How (not) to instantiate ring-LWE" > which has some ideas on how to choose the error distribution - this > might mean that newhope has to change again?? Most of the changes since the paper has been released have been minor. The last major algorithmic change I'm aware of was 20151209 which altered the reconciliation mechanism (I don't particularly count the March changes that changed the on-the-wire encoding format to be major, it's just a more compact way to send the same things). Kind of a moot point since by the time any of this will actually be used in core tor things would have settled. And my gut feeling is RingLWE will have performant, well defined implementations well before SIDH is a realistic option. Regards, -- Yawning Angel pgplNCEOAyDgG.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] prop224: HSDir caches question with OOM
On Sat, 16 Apr 2016 20:30:29 +0300 s7r <s...@sky-ip.org> wrote: > I agree that teor's O(Kn) is the best approach from performance (no > additional memory allocations), simplicity and efficacy point of view. > O(Kn) algorithm will clear the entries only based on their expiration > time, it won't care to clean the v2 / v3 caches in equal measure which > is good, given that we do not know how long HS operators will take / > need to upgrade their services to prop 224. > > The tap vs ntor situation was a good measure, but the threat model was > different (we were trying to ensure new clients using ntor get > resources from relays with priority as opposite to non-updated botnet > zombies using tap). In the current situation we care about v2 and v3 > HS caches exactly the same, for an unknown period of time which might > not be short, so we shouldn't penalize v2 in any way. We do? I can think of numerous reasons as to why v3 is objectively better, and why we should incentive people to move towards 224 style HSes... What I want is possible with Teor's 2nd algorithm (which is adequate). Make Cache A the v2 cache, and if we've freed enough ram after purging expired entries from A in a given time period, we terminate rather than touching cache B. In effect this makes it slightly less likely for entries in the B cache to be deallocated (we probably should also halt once we have reached our target deallocation amount when attempting to compact either cache, rather than continuing to purge the rest of the time interval, it's the OOM handler, and an addition, a compare and a branch is cheap enough to be done in a loop). > This needs to be covered regardless how often a HSDir has its OOM > triggered. I don't think we should assume it's hard to flood HSDirs > with descriptors until the memory is full. > > Now that HSDirs will need to handle two caches, is 20% of the total > memory allocated for HS descriptors a good value? What harm would > increasing it to let's say 25% do? It would decrease memory available for other things, where other things is "all HSDirs are expected to first and foremost be relays, and do normal relay things like relaying traffic, before being HSDirs". I don't remember if it's possible to opt out of being a HSDir or not (likewise, with the move to make all relays be dir caches, we already are increasing memory pressure on "things that are comically undersized that shouldn't ever be HSDirs or DirCaches in the first place") Regards, -- Yawning Angel pgptbYKlfcCFk.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] Request for feedback/victims: cfc-0.0.2
On Sat, 2 Apr 2016 18:14:26 -0400 Ian Goldberg <i...@cs.uwaterloo.ca> wrote: > On Sat, Apr 02, 2016 at 07:19:30PM +, Yawning Angel wrote: > > It's not a request header set by the browser. archive.is is acting > > like a HTTP proxy and explicitly setting X-F-F. > > I wonder what would happen if the browser *also* set X-F-F...? Unfortunately, it appears that archive.is tramples over X-F-F if it is already set. Maybe others will have better luck engaging with the operator(s) of archive.is than I have. Regards, -- Yawning Angel pgpHSqIn1dO_s.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] Quantum-safe Hybrid handshake for Tor
On Sun, 03 Apr 2016 16:37:45 +0200 Jeff Burdges <burd...@gnunet.org> wrote: > On Sun, 2016-04-03 at 06:52 +, Yawning Angel wrote: > > Your definition of "reasonably fast" doesn't match mine. The > > number for SIDH (key exchange, when the thread was going off on a > > tangent about signatures) is ~200ms. > > What code were you running? I think the existing SIDH implementations > should not be considered optimized. Sage is even used in : > https://github.com/defeo/ss-isogeny-software > I've no idea about performance myself, but obviously the curves used > in SIDH are huge, and the operations are generic over curves. And > existing signature schemes might be extra slow due to this virtual > third or fourth party. I know folks like Luca De Feo have ideas for > optimizing operations that much be generic over curves though. http://cacr.uwaterloo.ca/techreports/2014/cacr2014-20.pdf Is "optimized" in that, it is C with performance critical parts in assembly (Table 3 is presumably the source of the ~200 ms figure from the wikipedia article). As i said, i just took the performance figures at face value. I'm sure it'll go faster with time, but like you, I'm probably not going to trust SIDH for a decade or so. Regards, -- Yawning Angel pgp9GCP5wFcaj.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] Advice regarding Cloudflare
On Sun, 3 Apr 2016 00:37:45 -0700 Ryan Carboni <rya...@gmail.com> wrote:> > > > (as opposed to the people that seem to think that Exits > > should actively combat abuse by having the capability for > > censorship). > > > > > Well, a large number of exit nodes already have the capability for a > man-in-the-middle attack. This capability could very well be a default > option. There's legal/ethical issues with that sort of thing. In the bright future (more modern versions of HTTP for example), encryption is going to be the default. An anonymity system that mounts active-man-in-the-middle attacks against TLS (or QUIC's encryption) isn't anything I'll be working on. > b) In your magic world, how would accessing any site that uses > > multiple hosts for content to work? > [snip] > This might seem patronizing, but you seem genuinely ignorant. No. I was wondering how a poorly thought out idea is supposed to not negatively impact anonymity given that bundling multiple endpoints over a single circuit is good for anonymity. It was a genuine technical question. [snip] > By any reasonable definition of ethics, one must find a middle > ground, and essentially, Cloudflare has all the negotiating power, > unless you plan on personally battering down the doors of Cloudflare. Well, I did write an addon that just fetches content from archive.is whenever I get a Captcha. Does that count? > Perhaps a maximum of 63 domain names (forgot Cloudflare only has a > dozen IPs) per Tor circuit could be done. You have a definition of "a dozen" that doesn't match one that I'm familiar with (https://archive.is/eSl37). Anyway, it's easy for clients to request multiple circuits. An anonymity system where the Exit possesses linkable client identifiers between circuits/sessions is also a poor anonymity system. *plonk* -- Yawning Angel pgpMTdGCtT5sV.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] Request for feedback/victims: cfc-0.0.2
On Fri, 01 Apr 2016 18:21:10 +0200 Jeff Burdges <burd...@gnunet.org> wrote: > Are there any more sites where CloudFalre appears on archive.is? > > https://www.aei.org/publication/gen-michael-hayden-on-apple-the-fbi-and-data-encryption/ > https://archive.is/7u5P8 > > It's some particularly harsh CloudFlare configuration perhaps? Without knowing how archive.is works, and how CloudFlare works, it's hard to tell. Since archive.is sets "X-Forwarded-For", it's not particularly hard to figure out if a Tor user is the one requesting a snapshot. I requested a new snapshot and the captcha error page in the archive shows that the IP of my exit, so part of the ClouldFlare infrastructure at least peeks at the header. I'll probably add support for other (user-configurable?) cached content providers when I have time. The archive.is person doesn't seem to want to respond to e-mail, so asking them to optionally not set X-F-F, seems like it'll go absolutely nowhere. Regards, -- Yawning Angel pgpbdDFFzx9_I.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Request for feedback/victims: cfc-0.0.2
Hello, Thanks for the feedback so far. [ PEOPLE THAT HAVE BIG SCARY ADVERSARIES IN THEIR THREAT MODEL STILL SHOULD NOT USE THIS. ] New version with changes some that add functionality, some code of quality stuff, hence a version bump to 0.0.2, especially since it'll probably be a bit before I can focus on tackling the TODO items. Source: https://git.schwanenlied.me/yawning/cfc XPI: https://people.torproject.org/~yawning/volatile/cfc-20160327/ Major changes: * Properly deregister the HTTP event listeners on addon unload. * Toned down the snark when I rewrite the CloudFlare captcha page, since I wasn't very nice. * Additional quality of life/privacy improvements courtesy of Will Scott, both optional and enabled by default. * (QoL) Skip useless landing pages (github.com/twitter.com will be auto-redirected to the "search" pages). * (Privacy) Kill twitter's outbound link tracking (t.co URLs) by rewriting the DOM to go to the actual URL when possible. Since DOM changes made from content scripts are isolated from page scripts, this shouldn't substantially alter behavior. * (Code quality) Use a pref listener to handle preference changes. TODO: * Try to figure out a way to mitigate the ability for archive.is to track you. The IFRAME based approach might work here, needs more investigation. * Handle custom CloudFlare captcha pages (In general my philosophy is to minimize false positives, over avoiding false negatives). Looking at the regexes in dcf's post, disabling the title check may be all that's needed. * Handle CloudFlare 503 pages. * Get samples of other common blanket CDN based Tor blocking/major sites that block Tor, and implement bypass methods similar to how CloudFlare is handled. * Look into adding a "contact site owner" button as suggested by Jeff Burdges et al (Difficult?). * Support a user specified "always use archive.is for these sites" list. * UI improvements. * More Quality of Life/Privacy improvements (Come for the Street Signs, stay for the user scripts). * I will eventually get annoyed enough at being linked to mobile wikipedia that I will rewrite URLs to strip out the ".m.". * Test this on Fennec. * Maybe throw this up on addons.mozilla.org. Regards, -- Yawning Angel pgpKqMog0USwp.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] iObfs: obfs4proxy on iOS
On Sat, 26 Mar 2016 21:44:54 + Mike Tigas <m...@tig.as> wrote: > iObfs is an effort to build obfs4proxy for iOS and to also build out > some techniques for actually making it usable within other > Tor-enabled iOS apps. You may have heard me or n8fr8 discuss the idea > at the dev meeting a few weeks ago. I'm not in love with the name I > gave it (it's a placeholder that stuck around), but such is life. The > repository is currently hosted at [1]. > > [1]: https://github.com/mtigas/iObfs Why stick with Go. obfs4 as a protocol isn't exactly complicated and I've provided the tricky bits of crypto in a few places to make it possible to implement in other languages... Regards, -- Yawning Angel pgpsBhQno5yzo.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] Request for feedback/victims: cfc
[I hate replying to myself.] On Wed, 23 Mar 2016 09:15:36 + Yawning Angel <yawn...@schwanenlied.me> wrote: > My "proof of concept" tech demo is what I consider good enough for > use by brave people that aren't me, so I have put up an XPI package > at: https://people.torproject.org/~yawning/volatile/cfc-20160323/ I noticed some dumb bugs and UI issues in the version I pushed so I changed a lot of things and uploaded a new version that should be better behaved. In particular: * It is now Content Script based, and does IPC so it may survive the transition to sandboxed/multiprocess firefox better. * It will always inject a button into the DOM instead of trying to display browser UI stuff (content scripts are supposed to have isolation...). * The UI selection pref is removed. * The ask on captcha option for behavior is removed, since a button always will be there to bypass it. * Loading lots of pages that end up displaying street signs *should* now behave correctly. The old release is under `./old` for posterity. Sorry for the inconvenience, -- Yawning Angel pgpUUD0w2JeqL.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Request for feedback/victims: cfc
Hello, Inspired by https://trac.torproject.org/projects/tor/ticket/18361 I've been working on way to improve the situation. My "proof of concept" tech demo is what I consider good enough for use by brave people that aren't me, so I have put up an XPI package at: https://people.torproject.org/~yawning/volatile/cfc-20160323/ The source: https://git.schwanenlied.me/yawning/cfc (Requires the Firefox SDK aka Jetpack to package). By default the addon will: * Rewrite the CloudFlare captcha error page with messages that reflect my perception of reality[0]. * Rewrite imgur ".gifv" links to ".gif". Under "Tools->Addons->Extensions" you can configure the addon to: * Automatically fetch a cached copy of pages hosted on CloudFlare infrastructure from archive.is. * Automatically fetch a cached copy of pages that present a CloudFlare captcha from archive.is. * Pop up a UI widget asking if you want to fetch a cached copy of the page from archive.is each time you encounter a captcha. * Disable the snarky error message replacement (Requires a restart to take effect, because I'm lazy). * Disable the gifv URL rewrite. TODO: * Support a user definable blacklist (eg: If you want to always use archive.is to access gawker.com or other clickbait bullshit, you should be able to easily do so). * Add more general quality of life things. * Think about making it work on Fenec (It currently will not because PopUpNotifications are handled differently, among other things). * Rewrite the internals to prepare for e10s. WARNING: * If archive.is is evil, they can track you across page fetches trivially, because this sort of use case is outside of Tor Browser's current threat model (Yes, CloudFlare/Google can also do the same thing currently, who do you trust more?). * PEOPLE THAT HAVE BIG SCARY ADVERSARIES IN THEIR THREAT MODEL SHOULD NOT USE THIS. If you don't know how to install addons given as XPI files, you shouldn't be using this. This is only tested on 6.0a4 (Linux/64 bit). It *should* work on everything that isn't Orfox that's relatively modern, YMMV. Regards, -- Yawning Angel [0]: A very cynical/adversarial take on things. Opinions are my own, etc, and I don't care if you're offended. pgpS7slMkLTl3.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] Quantum-safe Hybrid handshake for Tor
On Thu, 3 Mar 2016 16:33:42 + (UTC) lukep <lu...@tutanota.com> wrote: > Hi, > I'm trying to understand the hybrid protocol that's described here. > The server generates the parallel secret PAR_SEC or P and then > computes C = ENCRYPT( P | B | Y, QSPK); > The client decrypts C to get P and then uses it combination with the > ECC secret E: secret_input = E | P | QSPK | ID | PROTOID > > So E is secret, P is generated by the server, QSPK ID and PROTOID are > all public. So IF ECC is broken and IF the server has been > compromised (big IF's!) then everything is known. If the server is compromised, the client loses regardless of handshake mechanism because said compromised server has access to the plaintext. > I guess my point is that the client isnt contributing any secret > information to the quantum-safe part of KEY_SEED. Is that OK? Yes. I'd rather both sides contribute, but since `P | B | Y` is transmitted encrypted to a ephemeral key generated by the client, baring the "the server is compromised" case (which is irrelevant) the construct should hold. See RFC 4432, RFC 5246 7.4.7.1 for this sort of thing being done with RSA. Note: The Ring-LWE variant of this hybrid construct would fulfill the "both sides contribute material" clause (yay). Regards, -- Yawning Angel pgpcIxGIJ0_41.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] Tor not affected by recent openssl security advisories
On Thu, 28 Jan 2016 10:35:21 -0500 Nick Mathewson <ni...@torproject.org> wrote: > Somebody always asks whether Tor is affected by each OpenSSL advisory, > so I'm sending this mail in order to get a URL to send people to. :) > > Here are today's advisories: >https://mta.openssl.org/pipermail/openssl-announce/2016-January/61.html > > With respect to the first ( "DH small subgroups (CVE-2016-0701)" ), > Tor is not affected because we set the SSL_OP_SINGLE_DH_USE() option. > We started setting this option back in Tor 0.1.1.9-alpha, back in > 2005. It's also worth noting that newer (0.2.7.x) versions of Tor should not be doing DHE except when talking to old versions of Tor, linked against old versions of OpenSSL as ECDH is both mandatory and preferred in the current stable series. All versions of OpenSSL that predate support for ECC have been EOLed and no longer receive security fixes, so if your system is using OpenSSL 0.9.8 (or 1.0.0 for that matter though it has ECC), you are strongly encouraged to upgrade to something that is being maintained. Regards, -- Yawning Angel pgpznz8AGqVM0.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] Tor not affected by recent openssl security advisories
On Thu, 28 Jan 2016 18:05:51 +0100 Tim Kuijsten <i...@netsend.nl> wrote: > > It's also worth noting that newer (0.2.7.x) versions of Tor should > > not be doing DHE except when talking to old versions of Tor, linked > > against old versions of OpenSSL as ECDH is both mandatory and > > preferred in the current stable series. > > Is ECDH currently mandatory or did you mean ECDHE? Yes. It uses ECDH with Ephemeral keys. Really, unless you vendor's OpenSSL library is doing something Really Silly, or is ancient, this will Do The Right Thing (TM). -- Yawning Angel [0]: Bow before your new NIST overlords, etc. pgpWk1gbZz6Dk.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.6
Hello all, I just tagged obfs4proxy-0.0.6. There aren't many significant changes, and the internal changes primarily affect the client side initialization, so those of you that are perfectly content with obfs4proxy-0.0.5 can continue to use the existing version without issue. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.6.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.6.tar.xz.asc Changes in version 0.0.6 - 2016-01-25: - Delay transport factory initialization till after logging has been initialized. - Add a meek client implementation (WARNING: Does not support using a helper to normalize TLS signatures). The brave people that want to use it can do so as the "meek_lite" transport, with identical bridge lines to the real meek-client. This means "It's blatantly obvious that you're using a HTTPS client written in Go because the ClientHello is rather distinctive". The benefit is that it is a lot easier to package than meek-client + the external helper, and this can probably save binary size on things like Android. An example bridge line would be: Bridge meek_lite 0.0.2.0:1 url=https://meek-reflect.appspot.com/ front=www.google.com It has received moderate testing when I was on a business trip, and appears to function as intended, given the design constraints. There are minor internal API changes (which caused issues delaying the release) motivated by "meek's behavior is unlike most other transports" but I expect such things to be straight forward to those that actually hack on the code. Thanks to the person on Github for filing a pull request which saved me time debugging. Regards, -- Yawning Angel pgp65xew5gP_U.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] Introducing Snowflake (webrtc pt)
On Mon, 25 Jan 2016 14:34:42 -0800 Serene <keroser...@riseup.net> wrote: > Anyhow, if Snowflake seems like it would be useful / desired here, it > would be awesome if we had more help getting it stable, polished, > audited, deployable, etc... Neat. Yes, this will be useful. What are your plans for getting https://github.com/keroserene/go-webrtc to build completely in a deterministic manner? The several hours isn't per platform right? (The "easy way" is not going to cut it for distribution). What are your plans for actually getting the server side to scale well? Since you're using cgo you will run into Really Interesting behavior wrt OS threads as you try to increase concurrency. Regards, -- Yawning Angel pgpLU1pLkbv_I.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] Introducing Snowflake (webrtc pt)
On Mon, 25 Jan 2016 15:32:55 -0800 Serene <keroser...@riseup.net> wrote: [snip] > > What are your plans for actually getting the server side to scale > > well? Since you're using cgo you will run into Really Interesting > > behavior wrt OS threads as you try to increase concurrency. > > Right now, the server side is the same websocket relay from > flashproxy. Webrtc currently happens just between the client and > browser proxy - this already yields all the benefits listed above (as > we assume the volunteer proxy has no problem connecting to Tor) This seems sensible. > However, it might be worth having webrtc on both sides. We already > have prepared a webrtc server plugin, which the client plugin has > successfully connected to directly. To use a snowflake proxy in > between would require establishing two separate webrtc peerconnections > per circuit. Maybe that's worth doing - but I'm not sure about the > plan there, if we do decide to go that route. Ah that's what that was. If you don't use it then, you won't have lots of misery fighting with cgo's quirks. Regards, -- Yawning Angel pgpH3WhBnsvR9.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] SyslogIdentityTag considered to be backported to 0.2.7?
On Thu, 21 Jan 2016 20:06:51 + nusenu <nus...@openmailbox.org> wrote: > I like weasel's [1] SyslogIdentityTag feature that is available in > debian 0.2.7 packages only. > > The ticket [1] suggests that it will be included in tor 0.2.8.x > (milestone). Would you consider to backport it to 0.2.7 as well so > other platforms can make use of it before we see tor 0.2.8 (without > having to ask every package maintainer to maybe ship packages with > the patch applied)? The only thing that gets backports to stable releases are security and compatibility fixes. Regards, -- Yawning Angel pgpvwFQU9G7hh.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] Is it possible to specify voluntary delays in my Tor client?
On Wed, 20 Jan 2016 08:15:48 + David Stainton <dstainton...@gmail.com> wrote: > The Differences Between Onion Routing and Mix Networks > https://ritter.vg/blog-mix_and_onion_networks.html Not implemented yet in tor (see prop 254), but this is the current state of the art in link padding as a traffic analysis defense. http://arxiv.org/abs/1512.00524 This is follow up research from M. Juarez's GSOC project which prototyped the framework used when writing the paper and evaluating the various algorithms. Regards, -- Yawning Angel pgp5P4NZJRXsk.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] ENGINE_get_default_ECDx missing?
On Mon, 18 Jan 2016 19:43:37 +0100 Gisle Vanem <gva...@yahoo.no> wrote: > Isn't OpenSSL 1.1.0 supported yet? Scratching head... We fix it when it breaks but it's not a high priority or something currently tested against. When 1.1.0 has a stable release, this will change, but people building against master or the pre-releases are currently on their own. Thanks for the patch though. Regards, -- Yawning Angel pgpasWyLTDBte.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] Entry/Exit node selection
On Mon, 18 Jan 2016 13:53:47 -0400
"Evan d'Entremont" <e...@evandentremont.com> wrote:
> Is there any reason why Tor doesn't select exit nodes which are as
> close as possible to the intended host?
The generic way to ask this question is "AS-aware path selection".
One big general issue is, "there is no accurate map of how ASes are
geographically distributed".
> If I connect to Tor and request a resource from a server on ISP A,
> would in not make sense to enforce an exit node also on ISP A, or if
> not, as close as possible?
Load balancing. Relay capacity is likely not distributed in a way that
matches intended desitnations.
> As well, entry guards should be as close as possible to the user,
> limiting the ability of others to log the connection.
This loses extremely quickly once you have adversaries that can force
ISPs to run relays ("You mean, we send a NSL to Comcast and we get to
be the Guard for all Tor users that are Comcast customers?").
Ditto load balancing concerns.
> In short, it's safer that only my ISP see a connection rather than my
> ISP, a backbone provider, the entry guard's ISP, etc. Systems like
> XKeyscore wouldn't even see the traffic in this case. It seems that
> selecting an exit country may actually be detrimental to anonymity by
> forcing traffic over the (monitored) internet backbone.
Hiding Tor use isn't part of Tor's threat model. The current situation
wrt e2e correlation and AS diversity is sub optimal, but the current
plan is to add link layer padding as a defense (Though it comes at a
~60% cost).
Regards,
--
Yawning Angel
pgpO62WxpcC58.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] Entry/Exit node selection
On Mon, 18 Jan 2016 14:26:04 -0800 Spencer <spencer...@openmailbox.org> wrote: > > > > Evan d'Entremont: > > ... select exit nodes ... > > > > It would be best if people could select their own path (: You can with the control port. Moving it to a first class feature would be a terrible idea for anyone that isn't a researcher because people will likely get the path selection horrifically wrong. Regards, -- Yawning Angel pgp8i36ArwBOJ.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] Transparent proxying: automagically add firewall rules
On Mon, 11 Jan 2016 16:43:10 + Rene Bartsch <m...@bartschnet.de> wrote: > Hi, > > transparent proxying to TOR Hidden Services is a great feature of the > TOR daemon when it comes to other applications/protocols than HTTP > and surfing. It would also be great with privacy appliances (e.g. > Mailpile using TOR as secure SMTP transport channel). > > John Does have problems with such a setup because of the NAT firewall > rules. > > So I suggest the TOR daemon should automagically set the necessary > NAT-rules on Windows, Linux and BSD when "TransPort" and > "VirtualAddrNetworkIPv[4|6]" are configured in torrc. This is unlikely to happen because the "sensible automagic thing" will probably break on various configurations, and more practically, tor attempts to drop privileges as soon as possible leading it to be unable to alter or clean up said rules on HUP/exit. Others are free to disagree, patches will be evaluated if someone writes them. Regards, -- Yawning Angel pgp2yHXnYiOR_.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] Quantum-safe Hybrid handshake for Tor
(Note: Snipping liberally for brevity) On Mon, 4 Jan 2016 11:56:54 -0500 Zhenfei Zhang <zzh...@securityinnovation.com> wrote: > 2. On NTRU vs NTRU-Prime vs R-LWE and others. > The QSH is modular designed to suite any quantum-safe encryption > algorithm. So we can chose any one we want for trail. And > furthermore, we can also hybrid, say ECC, NTRU and R-LWE, to give a > bit more confidence in case one of the quantum-safe encryption > algorithm turns out to be not quantum safe, or broken. Hybridizing all 3 probably will get somewhat expensive (though not prohibitively so), nickm and I have branches to thread the client side circuit build crypto which will help mask the performance penalty of this proposal in general (not yet merged, shouldn't require changes to your branch). > That been said, we chose NTRU for several reasons. NTRU is more > mature than R-LWE from our point o view. NTRU has a full spec, a > reference implementation, and is standardized by several bodies; > while for R-LWE, since it enables many interesting cryptographic > primitives, such as FHE, there has been many different parameter > proposals, which leads to some kind of confusion as to which one > should reference to. At the current time, if I had to pick one, I'd use the newhope variant of Peikert's KEM scheme (And in fact was going to amend the proposal to specify that as the Ring-LWE primitive). The BCNS proposal has gotten slightly more scrutiny, but it's slower, has larger keys, and provides a lower security level than newhope. > We are happy to roll out any above encryption algorithm as you see > fit. But our proposal is mainly about the QSH approach. I think the > best option for now is to buildin a QSH for Tor, with a flexible > API that allows us to switch between algorithms when fit. And for now > use any quantum-safe encryption algorithm that is ready to be used. > After all, any QS encryption is better than nothing. Agreed. I like the QSH design, though I still want to use FIPS 202 (SHA-3/SHAKE) instead of HMAC-SHA256/HKDF-SHA256, due to "Since we're changing things anyway, we may as well future proof here too". > 3. License > I am sorry I am not familiar with the license. But my general feeling > is that Security Innovation is willing to let Tor to use NTRU for > free. We just need to work out the suitable license to make this > happen. I'm glad to hear that. My main concern here is that if, say Debian Legal thinks that the existing FOSS patent wavier is insufficient to allow NTRU to be included in Debian packages till 2017, this will significantly hamper the relay side uptake of the safer primitives due to the Debian monoculture on our relays. I can do the Ring-LWE work, since the QSH primitive is modular so that there will be options for people that have more stringent license/patent policies than we do. If I were to prioritize handshake selection, I would lean towards NTRU + Ring-LWE, over NTRU, over Ring-LWE based on what the peer supports. > > As I recall, the product form parameter sets are extra encumbered. > > Apart from key/ciphertext size and a minor performance > > differential, is there any reason to not use one of the X9.98 > > parameter sets (Eg: EES613EP1) > > Yes we can use non-product form polynomials, if everyone agrees on it. > Non-product form polynomials will make key generation and decryption > a bit slower, but those cost are on the client side. It has no impact > on the load of server side. Client side for Tor is somewhat deceptive because Hidden Services act as the client when connecting to the Rdv point, so we do care about performance there too. I fully expect that the gains that we will get from separate work due to improved threading will pay for the CPU cost increases here, but I'll need to do some benchmarking to be certain. > > * "For 128 bits quantum security, use NTRU_EESS743EP1." should be > > "For 256 bits" (Section 2.3). > > NTRU_EESS743EP1 provides 256 classical security and 128 bits quantum > security. Please see > https://eprint.iacr.org/2015/708.pdf > for arguments of those security levels. Ah gotcha, I haven't seen that paper and I was going off the initial estimates, thanks for the clarification. Regards, -- Yawning Angel pgpP9Y2gM0JOm.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] Quantum-safe Hybrid handshake for Tor
On Sun, 3 Jan 2016 04:16:17 -0500 grarpamp <grarp...@gmail.com> wrote: > http://safecurves.cr.yp.to/ > > Just another link. None of those algorithms will hold up to a quantum computer, and apart from for TLS (where we use the NIST curves) we already use "safe" Curve/Ed25519. So I don't know why you're bringing it up. This is discussion regarding how to prevent a total disaster in the event of a Curve25519 break. nb: Migrating to X448 would possibly hold up longer than Curve25519 would since it requires a bigger quantum computer. But performance isn't that great without using vectorization. > > Additionally, without AVX2, signing is glacially slow, clocking in > > at ~200 ms on an Haswell i5. The same hardware does our existing > > ntor handshake in ~230 usec. > > Haswell i5 seems to have AVX2, as do all Haswell's, > perhaps you refer to Ivy Bridge i5's which do not... Or, perhaps I meant exactly what I said, because the implementation I happened to benchmark (which I coincidentally, happened to write) does not use AVX2 (it doesn't, since it was written to be portable) and I wanted non-vectorized performance numbers (I did). I know the algorithm is faster when vectorized but that does little good for what I suspect are a substantial fraction of the relays. -- Yawning Angel pgpVHGynyC38h.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] Quantum-safe Hybrid handshake for Tor
On Sat, 2 Jan 2016 17:18:56 -0800 Ryan Carboni <rya...@gmail.com> wrote: > And yet the NSA is moving to prime numbers. So? In terms of prioritization, ensuring all existing traffic isn't subject to later decryption is far more important that defending against targeted active attacks that require hardware that doesn't exist yet. > A large public key isn't a very good reason to not adopt quantum-safe > crypto, it just means that it requires having the Tor project to be > able to scale to a larger degree. I suggest hash tables, a percentage > of which are pseudorandomly downloaded. Otherwise the Tor project > won't scale to 10x the relays ... even ignoring quantum cryptography. Nope. Every client needs to know the public key of every relay or we're worse off vs active attackers. To put numbers into things for the bandwidth/storage overhead for having SPHINCS256 keys for every relay, currently the full list of microdescriptors for a consensus is ~3.2 MiB, with 6960 relays. This is roughly 9.3 MiB of extra information that would need to be downloaded in terms directory information, and ~41 KiB per hop of extra traffic as part of the circuit build process. Additionally, without AVX2, signing is glacially slow, clocking in at ~200 ms on an Haswell i5. The same hardware does our existing ntor handshake in ~230 usec. Increasing the amount of work each hop needs to do to establish a circuit by 3 orders of magnitude to the point where a single core on a relatively modern processor can process 5 circuit creations/second would kill the Tor network. (I'm done arguing over this. If you think relays should have PQ signature based identity keys, then feel free to write a patch. I view other things as more important, and will focus my efforts elsewhere.) Regards, -- Yawning Angel pgpqMyparA0Gu.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] Quantum-safe Hybrid handshake for Tor
On Fri, 1 Jan 2016 19:33:31 -0800 Ryan Carboni <rya...@gmail.com> wrote: > The first step should be replacing the long-term keys with > quantum-safe crypto. Wrong. There are NO usable PQ signature primitives that are suitable for deployment. Adding 1408+ bytes to every single microdescriptor is not a realistic proposition. Signing is also quite expensive unless you have AVX2, and will decimate circuit build performance. Protecting against Quantum Computer equipped active Man-In-The-Middle attacks is the least important thing to do in terms of user safety. By modifying the link handshake to incorporate a PQ key exchange algorithm with ephemeral keys as in the proposal, user data being generated right now will be protected from bulk decryption later, in the event of a Curve25519 break (probably by a large enough Quantum Computer), which is a far more realistic threat to be concerned about. -- Yawning Angel pgpd2rsvSvxx5.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] Quantum-safe Hybrid handshake for Tor
Hello, On Thu, 31 Dec 2015 20:51:43 + isis <i...@torproject.org> wrote: [snip] > I feel like there needs to be some new terminology here. It's > certainly not post-quantum secure, but "quantum-safe" doesn't seem > right either, because it's exactly the point at which the adversary > gains appropriate quantum computational capabilities that it become > *unsafe*. If I may, I suggest calling it "pre-quantum secure". :) Post-quantum forward-secrecy is what I've been using to describe this property. [snip] > However, if we were to go the route of using NTRU, we'd likely want > to instead use Dan Bernstein's NTRU Prime parameters, in order to > eliminate some of the inherent algebraic structure of the ideal > lattice which might possibly be exploited. [0] [1] That's a non-trivial amount of work, though I have issues with the parameter selection as well, that the authors of the proposal may be able to qualify. As I recall, the product form parameter sets are extra encumbered. Apart from key/ciphertext size and a minor performance differential, is there any reason to not use one of the X9.98 parameter sets (Eg: EES613EP1) > Also, what is the current state of patents on NTRU? My understanding > is that NTRU is dual-licenced as GPLv2+ and commercial, [2] however, > Tor is currently BSD licenced. Would it be necessary to relicense > Tor as GPLv2+? Will the GPL exceptions continue to be applied to > further patents on optimisations and improvements/protections for > NTRU? There's a FOSS patent grant, and Tim Buktu has a 3BSD NTRU implementation. (NB: The only implementation I looked at in depth is the reference Java code.) https://github.com/tbuktu/libntru It additionally supports deciding how encumbered you want the library to be (support for the product form parameter sets can be disabled at compile time). Note: Debian packaging of the library is stalled due to concerns over licensing, and the bug thread ends in a "take it to legal". https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802259 The worst case here from our perspective depending on what Debian Legal (or Fedora Legal etc etc etc) thinks about the whole thing is that we would need to feature gate (at compile time) NTRU support till 2017/2020 (depending on parameter set choices). > > 2. quantum-safe authentication: there is no quantum-safe > > authentication in this protocol. We believe that authentication can > > wait, as future (quantum) adversary cannot come back to present > > time and break authentication. Hence, we use ntor authentication to > > keep the proposal compact and simple. It will be a future work > > after this proposal. > > Not to delay progress on making Tor post-quantum secure, but if we > tackled both encryption and authentication in parallel, we'd better > able to compare the advantages and disadvantages of schemes, given > that we can take overhead fully into account, e.g. total added > keysize(s). For example, if we were to add something like a McEliese > CFS signature (code-based) or an XMSS signature (hash-based) to add > authentication, on top of already using some lattice-based > cryptosystem like NTRU, we would have two quite large keys, with one > or both needing to be distributed, for each relay. I personally don't think that any of the PQ signature schemes are usable for us right now, because the smallest key size for an algorithm that isn't known to be broken is ~1 KiB (SPHINCS256), and we probably can't afford to bloat our descriptors/micro-descriptors that much. If we decide we want to add PQ authentication with one of the current primitives Right Now, we could do something like: * Add a SPHINCS256 key to "the list of long term relay keys" and distribute it in descriptors/microdescriptors. (~1KiB binary, lots bigger b64ed). * The responder signs all the public parameters with their SPHINCS key as part of the key exchange (Go find the SIGMA paper). (+41 KiB binary, for the signature). But I would view that as premature (there's more important things that need to use PQ signatures first, like the consensus) due to primitive maturity/usability/overhead concerns. Other changes that should/could be made to the proposal: * "For 128 bits quantum security, use NTRU_EESS743EP1." should be "For 256 bits" (Section 2.3). * We have the opportunity (and code in master) to start using the FIPS 202 primitives. Since we need to modify the ntor code to anyway, we should use SHA-3 and SHAKE256 instead of HMAC-SHA256 and HKDF-SHA256 respectively. * Is it worth migrating our ECC to X448? I'll be fleshing out the proposal to specify 0x0103 around newhope, since the hybrid construct would be similar past the details of the key exchange itself. Regards, -- Yawning Angel pgptTYTGEFnsJ.pgp Description:
Re: [tor-dev] Proposal 262: Re-keying live circuits with new cryptographic material
On Mon, 28 Dec 2015 17:43:57 -0500
Nick Mathewson <ni...@torproject.org> wrote:
> 2. RELAY_REKEY cell operation
>
>To rekey, the circuit initiator ("client") can send a new
> RELAY_REKEY cell type:
>
> struct relay_rekey {
> u16 rekey_method IN [0, 1];
> u8 rekey_data[];
> }
>
> const REKEY_METHOD_ACK = 0;
> const REKEY_METHOD_SHAKE128_CLIENT = 1;
>
>This cell means "I am changing the key." The new key material will
> be derived from SHAKE128 of the aez_key concatenated with the
> rekey_data field, to fill a new shake_output structure. The client
> should set rekey_data at random.
This should be SHAKE256 to be consistent with our initial AEZ key
derivation. We're squeezing less data than the SHAKE256 rate, and we
need the same number of Keccak calls for either primitive during the
absorb phase, so there is no performance difference.
--
Yawning Angel
pgpeuirnSMomn.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
