Re: [tor-dev] RFC: obfsproxyssh
On Sat, 27 Jul 2013 09:52:52 +, Tom Ritter wrote: ... > I've always thought with SSH-based obsproxies, that you could > distribute the SSH private key to connect to the server with the > bridge IP address:port. I couldn't quite avoid the reflexive cringe at 'distribute private key'. :-) ... > So I think the value of requiring a login a the SSH-based obsproxy is > not for authentication but for scanning resistance. Ah, that's a cool idea. I was already assuming that a specific key would be used to select the tor service on the sshd, but making that key variable is a nice twist. (I didn't know the bridgedb has space for such info.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] how much havoc can a compromised baseband do to a Guardian ROM device?
Anyone knows whether a Nexus 4 baseband processor has r/w access to system memory? The firmware doesn't seem to be loaded at boot, so I presume it's entirely out of reach/ reversing? signature.asc Description: 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 much havoc can a compromised baseband do to a Guardian ROM device?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2013 09:00 AM, Eugen Leitl wrote: > Anyone knows whether a Nexus 4 baseband processor has r/w access to > system memory? The firmware doesn't seem to be loaded at boot, so I > presume it's entirely out of reach/ reversing? - From what I know, there has been nothing specific done (yet) in the Guardian ROM work to combat baseband attacks. Something interesting about the Nexus 4: http://www.ifixit.com/Teardown/Nexus+4+Teardown/11781/3 It appears to have two separate "modem" chips, perhaps related to extended support for LTE: Qualcomm WTR1605L Seven-Band 4G LTE chip Qualcomm MDM9215M 4G GSM/UMTS/LTE modem Searching for either of those parts online reveals a good amount of documentation, but not many specifics related to Android. +n -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR9m2TAAoJEKgBGD5ps3qp6BwQAIPEGGisxIWlz8TYO3409UYY oRLHs2J+pNeZ+FUL06lylwM2di2PeL0fZIv9g48yKegR3+9/3XkP9w2zUakj6zJa rMpSZ8Gl4YFxNFbT/ukAyaKxKezyhxPELjSihB/tJI5puYQcuhu9bMR2KrmhITiZ yghUDMJ5Wp+ETeA/+CKzw172hMT1gTz1ennYXotFFIZK+Ac0ucTud9JaAf4PsHM5 hfnDfQxsq4MlmBO6737WL9ilJqRTjUBO9t1BtoRVOQ/j/lcff7F0tSzxy3mxOAOe 0bm8Ox1n5POvMDNucytrGdopl+PPwewPZVtl5GjGXNsp9TsVm6Hdpl4xE3CyVyUI pdZStfiWWZ0Xz/LNAaErT7cORp5O/H0O9vtu2CYeQtH3w8k9ngPgBYkqbklJwpwA XwkmzeOYSdvTfmylsENhcWNjv58qprQFV6mMVwfZzPdj1Ik0dTlGIX7GYQoFjLhz oPk51/AjOrk8S66ySequSJto8Ngk8R5EsWABrw5ed5QjEJuictLUO1aLTBUqRVCB eOrkkiL2wPOVYfywqwzCpJovDcIvupiEdO2O0eJ9FGWbyQ2uasp5mMZXKblG8kjs 6BpqnRhjBBowCs8eOu6poDg/fm/OFrbiifY2inrr++TposIsiCriETrhVVZEqa9G XQE/4+Ujxenno2zYMSKq =beLf -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] how much havoc can a compromised baseband do to a Guardian ROM device?
On Mon, 29 Jul 2013 15:00:05 +0200 Eugen Leitl wrote: > Anyone knows whether a Nexus 4 baseband processor has r/w > access to system memory? How does this relate to tor development? -- Andrew http://tpo.is/contact pgp 0x6B4D6475 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] how much havoc can a compromised baseband do to a Guardian ROM device?
On Mon, Jul 29, 2013 at 09:44:52AM -0400, Andrew Lewman wrote: > On Mon, 29 Jul 2013 15:00:05 +0200 > Eugen Leitl wrote: > > > Anyone knows whether a Nexus 4 baseband processor has r/w > > access to system memory? > > How does this relate to tor development? In that Nexus 4 is the major supported platform for http://shadowdcatconsulting.com/ which comes with Orbot http://shadowdcatconsulting.com/apps/ and I know that tor-dev is read by people with clue, who ought to know the answer to my question and are interested in (semi-)trusted hardware for personal communication. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] how much havoc can a compromised baseband do to a Guardian ROM device?
On 07/29/2013 09:44 AM, Andrew Lewman wrote: > On Mon, 29 Jul 2013 15:00:05 +0200 > Eugen Leitl wrote: > >> > Anyone knows whether a Nexus 4 baseband processor has r/w >> > access to system memory? > How does this relate to tor development? It is a bit of a tangent, but understanding new ways in which Tor running on a smartphone might be compromised could be useful. Otherwise, happy to have the thread move here: https://lists.mayfirst.org/mailman/listinfo/guardian-dev +n ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Onionoo protocol/implementation nuances / Onionoo-connected metrics project stuff
Hi Karsten, (not sure whom to CC and whom not to, I have a couple of fairly specific technical questions / comments (which (again) I should have delved into earlier), but then again, maybe the scope of the tor-dev mailing list includes such cases..) @tor-dev: This is in regard to the Searchable metrics archive project, intersected with Onionoo stuff. I originally wanted to ask two questions, but by the time I reached the middle of the email, I wasn't anymore sure if they were questions, so I think these are simply my comments / observations about a couple of specific points, and I just want to make sure I'm making general sense. :) ..So it turns out that it is very much possible to avoid Postgres sequential scans - to construct such queries/cases which are best executed using indexes (the query planner thinks so, and it makes sense as far as I can tell) and whatever efficient (hm, < O(n)?) search algorithms are deemed best - for the metrics search backend/database; the two things potentially problematic to me seem to be: - when doing ORDER BY, making sure that the resulting SELECT covers / would potentially return a relatively small amount of rows (from what I've been reading / trying out, whenever a SELECT happens which may cover > ~10-15% of all the table's rows, sequential scan is preferred, as using indexes would result in even more disk i/o, whereas the seq.scan can read in massive(r) chunks of data from disk because it's, well, sequential). This means that doing "ORDER BY nickname" (or fingerprint, or any other non-unique but covering-a-relatively-small-part-of-all-the-table column in the network status table) is much faster than doing e.g. "ORDER BY validafter" (where validafter refers to the consensus document's "valid after" field) - which makes sense, of course, when you think about it (ordering a massive amount of rows, even with proper LIMIT etc. is insane.) We construct separate indexes (e.g. even if 'fingerprint' is part of a composite (validafter + fingerprint) primary key), and all seems to be well. I've been looking into the Onionoo implementation, particularly into ResourceServlet.java [1], to see how ordering etc. is done there. I'm new to that code, but am I right in saying that as of now, the results (at least for /summary and /details) are generally fairly unsorted (except for the possibility of "order by consensus_weight"), with "valid_after" fields appearing in an unordered manner? This of course makes sense in this case, as Onionoo is able to return *all* the results for given search criteria (or, if none given, all available results) at once. The obvious problem with the archival metrics search project (argh, we are in need of a decent name I daresay :) maybe I'll think of something.. no matter) is then, of course, the fact that we can't return all results at once. I've been so far assuming that it would therefore make sense to return them, whenever possible (and if not requested otherwise, if "order" parameter is later implemented), in "valid_after" descending order. I suppose this makes sense? This would be ideal, methinks. So far, it seems that we can do that, as long as we have a WHERE clause that is restricting-enough. select * from (select distinct on (fingerprint) fingerprint, validafter, > nickname from statusentry where nickname like 'moria1' order by > fingerprint, validafter desc) as subq order by validafter desc limit 100; , for example, works out nicely, in terms of efficiency / query plan, postgres tells me. (The double ORDER BY is needed, as postgres' DISTINCT needs an ORDER BY, and that ORDER BY's leftmost criterion has to match DISTINCT ON (x)) Now, you mentioned / we talked about what is the (large, archival metrics) backend to do about limiting/cutoff? Especially if there are no search criteria specified, for example. Ideally, it may return a top-most list of statuses (which in /details include info from server descriptors), sorted by "last seen" / "valid after"? Thing is, querying a database for 100 (or 1000) of items with no ORDER BY Is really cheap; introducing ORDER BYs which would still produce tons of results is considerably less so. I'm now looking into this (and you did tell me this, i.e. that, I now think, a large part of DB/backend robustness gets tested at these particular points; this should have been more obvious to me). But in any case, I have the question: what *should* the backend return (when no search parameters/filters specified, or very loose ones (nickname LIKE "a") are? What would be cheap / doable: ORDER BY fingerprint (or digest (== hashed descriptor), etc.) It *might* (well, should) work to order by fingerprint, limit results, and *then* reorder by validafter - with no guarantee that the topmost results would be with highest absolute validafters. I mean, Onionoo is doing this kind of reordering / limiting itself, but it makes sense as it can handle all the data at once (or I'm missing something, i.e. the file I linked to a
Re: [tor-dev] Onionoo protocol/implementation nuances / Onionoo-connected metrics project stuff
> > But would such arbitrary returned results make sense? It would look just > like Onionoo results, but - a (small) subset of them. Meant, But would such arbitrary returned results make sense? It would look just > like Onionoo results, but - a (small) subset of *all* the results in the > new-Onionoo backend, in our case. i.e., it'd be an arbitrary subset of a very large set of possible results. > > > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Onionoo protocol/implementation nuances / Onionoo-connected metrics project stuff
It should also be possible to do efficient *estimated* COUNTs (using reltuples [1, 2], provided the DB can be regularly VACUUMed + ANALYZEd (postgres-specific awesomeness)) - i.e. if everything is set up right, doing COUNTs would be efficient. This would be nice not only because one could run very quick queries asking e.g. "how many consensuses include nickname LIKE %moo% between [daterange1, daterange2]?" (if e.g. full text search is set up) but also, if we have to resort to sometimes returning an arbitrary subset of results (or sorted however we wish, but the sorting being done already on a small subset of results, if that makes sense), we'd be able to also supply info how many other results matching these particular criteria there are, and so on. The usefulness of all this really depends on intended use cases, and I suppose here some discussion could be had who / how would an Onionoo system covering all / most of all the descriptor+consensus archives and hopefully having an extended set of filter / result options be used? [1]: http://www.varlena.com/GeneralBits/120.php [2]: http://wiki.postgresql.org/wiki/Slow_Counting ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Onionoo protocol/implementation nuances / Onionoo-connected metrics project stuff
Last link of an unbroken email flood chain -- my (and perhaps only that one) last sentence may be aimed at a more general audience, reiterating: The usefulness of all this really depends on intended use cases, and I > suppose here some discussion could be had who / *how would an Onionoo > system* *covering all* [...] *the descriptor+consensus archives* [and > hopefully having an extended set of filter / result options] *be used*? As far as myself and my GSoC project is concerned, the most obvious use case is the proposed frontend (described in general terms, but with IMO some crucial specific points in the original proposal [1]). I suppose having the original planned use cases (what would this frontend require from the backend and so on, I mean) in mind makes the largest amount of sense, and that's what I'm aiming for at the moment. [1]: http://kostas.mkj.lt/gsoc2013/gsoc2013.html ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: obfsproxyssh
On 2013-07-29 00:05, Andreas Krey wrote: > On Sat, 27 Jul 2013 09:52:52 +, Tom Ritter wrote: > ... >> I've always thought with SSH-based obsproxies, that you could >> distribute the SSH private key to connect to the server with the >> bridge IP address:port. > > I couldn't quite avoid the reflexive cringe at 'distribute private key'. :-) > > ... >> So I think the value of requiring a login a the SSH-based obsproxy is >> not for authentication but for scanning resistance. > > Ah, that's a cool idea. I was already assuming that a specific key would > be used to select the tor service on the sshd, but making that key > variable is a nice twist. (I didn't know the bridgedb has space for > such info.) Yep, that's the idea. All of the arguments in the gigantic bridge line of doom are the equivalent of something like the shared secret component present in ScrambleSuit. The code's changed quite a bit since I've last posted (per discussion with asn a while ago, we decided that it would be better to use a "real" ssh client), so I have been working on a python script that wraps OpenSSH. Works fairly well under U*IX, but under Windows, there's a few issues that need to be addressed still. Regards, -- Yawning Angel ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Descriptor Monitors
Hi all. Over this last weekend I started taking advantage of stem's shiny new remote descriptor fetching module [1] to implement some simple monitors... * Descriptor Checker Hourly task that downloads the server descriptors, extrainfo descriptors, and consensus to check for malformed content. In the case of the consensus this downloads from each of the authorities to also ensure that they're all reachable... https://gitweb.torproject.org/atagar/tor-utils.git/blob/HEAD:/descriptor_checker.py * Sybil Checker Replacement for the consensusTracker.py I've been running for the last few years [2]. This checks for sudden influxes of new relays, such as the trotsky relays from 2010 [3]... https://gitweb.torproject.org/atagar/tor-utils.git/blob/HEAD:/sybil_checker.py Cheers! -Damian [1] https://stem.torproject.org/api/descriptor/remote.html [2] https://gitweb.torproject.org/atagar/tor-utils.git/blob/e537044:/consensusTracker.py [3] https://trac.torproject.org/projects/tor/wiki/doc/badRelays#trotsky ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
