Greetings,
another important Hidden Service issue, is the guard enumeration
attack that was described by the "Trawling for Tor Hidden Services:
Detection, Measurement, Deanonymization" paper (in section VII) [0].
A trac ticket was created to fix this issue (#9001 [1]). The most
popular solution so far seems to be the 'Virtual Circuit' concept. The
idea here is that if you have already created a circuit to a
Rendezvous Point, and then that circuit fails and you need to connect
to a different RP, then maybe you could reuse the previous hops of the
circuit and only change the last hop to the new RP.
This is an interesting concept and useful in other occasions too. For
example, if the network is flooded with CREATE cells (like during the
recent botnet invasion) and relays reject them because of increased
workload, then maybe clients shouldn't build entirely new circuits to
send CREATE cells to different relays (because building new circuits
increases the total load of the network even more).
However, this concept must be designed carefully and in a
security-conscious way. Reusing parts of old circuits to connect to
new nodes might result in unexpected attacks.
More solutions have been proposed in #9001, like "guard node layers",
which need further investigations.
If you think you can contribute to this topic, please write your ideas
in this mailing list or in ticket #9001.
Enjoy.
[0]: www.ieee-security.org/TC/SP2013/papers/4977a080.pdf
[1]: https://trac.torproject.org/projects/tor/ticket/9001
----- Forwarded message from katana <katana(a)riseup.net> -----
Date: Mon, 14 Oct 2013 09:27:41 +0200
From: katana <katana(a)riseup.net>
To: cypherpunks(a)cpunks.org
Subject: Re: [linux-elitists] Browser fingerprinting
Message-ID: <525B9CED.20907(a)riseup.net>
User-Agent: Thunderbird
Hi,
> Check out firegloves. It's outdated, and I'd love to see it getting
> some love, but it's a great POC for anti-fingerprinting in Firefox.
In <http://www.cosic.esat.kuleuven.be/publications/article-2334.pdf>
about their FPDetective Framework
<http://homes.esat.kuleuven.be/~gacar/fpdetective/>, the authors wrote
about Firegloves:
"Additionally, Firegloves limits the number of fonts that a single
browser tab can load and reports false dimension values for the
offsetWidth and offsetHeight properties of HTML elements to evade
JavaScript-based font detection. We evaluated the effectiveness of
Firegloves’ as a countermeasure to fingerprinting, and discovered
several shortcomings. For instance, instead of relying on offsetWidth
and offsetHeight values, we could easily use the width and the height of
the rectangle object returned by getBoundingClientRect method, which
returns the text’s dimensions, even more precisely than the original
methods. This enabled us to detect the same list of fonts as we would
without the Firegloves extension installed. Surprisingly, our probe for
fonts was not limited by the claimed cap on the number of fonts per tab.
This might be due to a bug, or to changes in the Firefox extension
system that have been introduced after FireGloves, which is not
currently being maintained, was first developed. Although Firegloves
spoofs the browser’s user-agent and platform to pretend to be a Mozilla
Firefox version 6 running on a Windows operating system, the
navigator.oscpu is left unmodified, revealing the true platform.
Moreover, Firegloves did not remove any of the new methods intro-
duced in later versions of Mozilla Firefox and available in
the navigator object, such as navigator.mozCameras and
navigator.doNotTrack."
I add: OK, the naviagtor.oscpu issue can be fixed easily, but the
timezone feature doesnt't work too with enabled JavaScript.
---
Katana
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.comhttp://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
Not sure the following is entirely clear or complete,
but I tried to capture the concerns from the meeting
and the ensuing discussion.
Hope it helps.
Arlo
Attentive Otter Plan
====================
Goal
----
Add instant-messaging to the Tor browser bundle in order to provide a secure
communication tool which supports the free flow of information online.
Overview
--------
Instantbird [1] is a cross-platform IM client based on Mozilla's XULRunner.
The following presents the necessary steps to turn Instantbird into the
future Tor Messenger.
A Way Forward
-------------
1. Remove libpurple dependence
This is a trivial amount of work and changes to the build to support it would
be accepted upstream. They are already considering moving libpurple, and the
added protocols it supports, to an add-on for reasons of licensing/code
quality. JS implementations of the following protocols exist: XMPP, Google
Talk, Facebook, IRC, Twitter, with Yahoo landing soon and AIM/ICQ started but
further away.
2. OTR support
Instantbird currently lacks support for OTR. Two pieces are needed here: a
suitable OTR implementation, and an interface between the client and that
library (essentially, the role that pidgin-otr plays).
To get started, for the OTR library, a js-ctypes wrapper of libotr should be
used in conjunction with the message observer API. Code [2] from a few years
ago towards this end has been written but probably needs to be dusted off and
extended. An effort is underway at Mozilla to implement OTR in JS using NSS,
which could be dropped in as a replacement. A patch has been submitted [3] but it looks far from complete, so I wouldn't expect it anytime soon. When asked, they said it won't be ready for *a while*. Should the NSS implementation fail to materialize entirely, they would still be willing to take the
ctypes wrapper and libotr, as it doesn't present any licensing issues. In his
analysis, Mike suggested converting the ctypes wrapper to an XPCOM
wrapper but it's unclear why that's preferable.
The front-end side seems like a larger undertaking. This involves not only
the interaction with the message observer API but handling the quirks in the
various protocols (think /me in IRC), authentication including SMP, and
importing and storing long-term keys. Sukhe estimated at least a month of
development time and expressed an interest in being the one to undertake it.
On the bright side, the Instantbird team seems eager for OTR support and this
work will most likely be upstreamed.
3. Disable logging
An add-on may be required to ensure certain desirable configurations, like
logging disable by default. A difference in goals between UX for the
average user and the TIMBB user may force us to maintain these changes.
4. Tor controller
Tor Launcher will be used as the controller. Sukhe has already reported
having this working.
Using only JS protocol implementations means all traffic goes through
nsIChannels, making proxy support fairly easy to verify. For DNS,
network.proxy.socks_remote_dns should be set. DNS SRV should not be an issue
seeing as how it isn't supported by Mozilla [4]. Should test for other
UDP traffic leaks.
5. Messaging window
Jail it to type=content. Preferably everything is displayed in plaintext,
with HTML disabled or at least sanitized with an XSS filter [5]. Disable JS
and other features. Make use of all the preferences from TorBirdy.
6. Installer and updates
Leverage the work that's already being done on Mozilla's updater for the TBB.
7. Deterministic builds
Deterministic builds for the TBB was a major undertaking. I can't imagine
this case being any different, less the experience and groundwork already
laid.
8. Sandboxing
Come up with a practical, cross-platform way to sandbox the application.
I don't have an answer here. Maybe you do.
9. Audit
- Instantbird's render attack surface (content window, XSS filter, etc.)
- Crypto in NSS and how JS uses it
- Interface between the UI and OTR
- Proxy by-pass
- And more ...
10. Translations
Instantbird is available in 14 languages, including French and Spanish.
However, none are RTL and we want to support Arabic and Farsi. Messaging
should already work for RTL languagues though, they've fixed a few bugs
to ensure it, and reflecting the UI is reported to not be a ton of work.
They are definitely willing to accept patches here.
11. Other considerations
- Disable Instantbird's built-in auto-updater and crash reporter
- For sure OTR on by default, but maybe disallow any non-OTR comm. entirely
- CA verification: TOFU mode? Pin popular domains?
- Disable older TLS/SSL suites
- Consider the interaction between all three Tor bundles (FF, TB, IM). Tor
Launcher could attempt to authenticate and read settings from an already
running control port.
- Choose a different default profile folder (to avoid picking up plugins
and other unsafe settings)
References
----------
[1] http://instantbird.com/
[2] https://gitorious.org/fireotr/fireotr
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=779052#c20
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=14328
[5] https://mxr.mozilla.org/comm-beta/source/chat/modules/imContentSink.jsm
Hey everyone,
I am running some Chutney tests, and I want to go deeper than just running
the bootstrap script and watching logs. Does anyone have advice on how to
get the most out of Chutney?
Thanks!
Charlie
Just a gentle reminder that the PT meeting is today in few hours:
Friday - Oct 11 at
CEST: 18:00
BST (Summer GMT): 17:00
UTC: 16:00
EST: 12:00
MNT: 10:00
PST: 9:00
@ #tor-dev on irc.oftc.net
asn is going to moderate the session. (I have a very slow connection but
I'll try to join)
See you all there,
Vmon
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
The Boisterous Otter project requires us to offer assistance to users
through instant messaging.
Current plan: use an XMPP server allowing anonymous connections from a
web interface on one side, and have the support team use an authorized
account for each language.
The full report is viewable on the wiki at
https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Boisterous….
(Thanks to Lunar & Erinn for assisting with this)
- --
- -Phoul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJSV320AAoJEJ01Zvx7KO7YOgwQALmsJsnyVRUQ07CiqmxI+zle
dNsROZvnNvhfPyza5McBjxckXQ5fD5tgCL5TMxzkBD3ICFQgZWByrX/bMN2ZFfx0
nh12TCs64TvMFAXnTVKRopBYfkas/uSs3PhM4vnPULJ+mDbFoMNKXkJP42s7jkGK
D3q2+2k/yR9mu9IVLI9agKppR/L1Yq/lPzt9DFo0YZyIrI0nNrn9hFMCGQKuCl0u
S40DWXXtUXn1a0qg4mFKGurrVua7ZvMeLqmZExhLMY8AnFBP40ELP0mmM0KkQg1F
kW0ijmybEMcPwKsWltTNzwHj8pg7dLjD19/ZrVMjIhjinap0XDqcyjqJD3T1J4KE
ti0+wZ7wXRfjJs6eA0otfu6xfF5JGYvOd9KniN567aPxjCVb2s1Gm60zA1PGQwAe
npT3WTm4z02SHThEeS4NPJi1Vvt0WLGlHo6v5p0Fr+/g1dYqEmTK+6+kAHk+e2CS
OXSvJ16rj7kncLMf9SImvbk0+nojC9qT/jgJQm4IBgxzSq+TVNwn463JpCdpCI6m
wfqxAAqy3V+ZjG+KxZTrxRST/s5rdhKi+iiZUzgqx0SC/hEqWEoId+2q3DPyb69h
exBV0eUE0XsHKi12qySOef7BfQXO2q15cdUcu+9VzqULcwP+xKd5NziVDMWd95fj
skzK8xFSm4Epdpp65VWI
=CISa
-----END PGP SIGNATURE-----
Dear Team,
For completeness' sake I am attaching to this email the report I wrote last
week in order to summarize what the project APAF is about, and what there is in
common between it and the Otter/Cute proposal.
Eventually, feel free to add it to the trac page.
After reading ["Cute" design and challenges], though, I think the report lacks
an exhaustive description of APAF's threat model.
In APAF's documentation, the only document vaguely resembling a threat model is
embarassingly poor in terms of content[0]. If still possible, I would like to
remedy writing a more detailed one during this week-end, maybe really
pentesting the application with your help this time.
Does this sound visible to you?
["Cute" design and challenges]
<https://trac.torproject.org/projects/tor/attachment/wiki/org/sponsors/Otter…>
[0]
<http://apaf.readthedocs.org/en/latest/threat_model.html>
--
mi.
It'll be in #tor-dev.
If you want to be in the `to` field for future emails, announcements,
and so on (rather than just reading them on `tor-dev` or
`tor-assistants`), you should add your name, IRC nick, and email to
the [Buoyant wiki
page](https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Buoy….
-Tom
On 8 October 2013 16:20, Tom Lowenthal <me(a)tomlowenthal.com> wrote:
> People of Earth, heed my call!
>
> Based on feedback that Boisterous Otters has too much to do, and on
> the fact that current Boisterous meetings are using their full time on
> only half the topics, we're splitting Boisterous into two components.
>
> The first component is going to stick with the name Boisterous, and
> deals with the first two activities: the helpdesk, and l10n. If you're
> already working on these things, nothing is changing for you, and you
> may be able to stop reading this right here.
>
> The second component is picking up the name **Buoyant**, and will deal
> with the remaining activities:
> * written materials on general communications security
> * short videos multi-language training videos
> * outreach to Iranians and the Iranian diaspora
> * social-media, radio, and television outreach.
> * training, and train-the-trainer work
>
> If that sounds like your cup of tea, kettle of fish, or flagon of ale,
> then you should come help us get started by filling in this [Doodle][]
> **by Wednesday afternoon** so that I can plan a meeting at the end of
> this week or the beginning of next. Please fill out the Doodle if
> you're definitely coming, and plan to be part of the core effort. If
> you just want to show up to spectate or lend a hand, there's no RSVP
> needed.
>
> I plan to look at the Doodle around 1700-1900h Pacific tomorrow, and
> I'll use whatever it says then to try and pick the best time. I'll
> send the time out to tor-dev, bcc-ing everyone who's expressed an
> interest or answered the poll. That's 24 hours to give me your
> availability, but only about 16 hours between when I send out the time
> and the first possible meeting slot, so check your mail tomorrow
> evening Pacific.
>
> If you have any specific suggestions about venue, format, or other
> running *of the meeting*, and you plan to be there, please reply
> publicly or privately before I send out the scheduling meeting. If you
> have specific plans about how to git'er done, you can either email me,
> or bcc me on a tor-dev-bound email with an appropriately-ottery
> subject line. Do note, however, that other folks may not be able to
> read your suggestions if you send them less than 12 hours before the
> meeting. I'll try to read them anyway, but that's only out of the
> kindness of my heart.
>
> Questions on a postcard please,
> -Tom
>
> [Doodle]: http://doodle.com/pm5cfunbcwuyrwh6
Hey Nick,
I pushed the recent HS proposals to my torspec git repo.
You can find them on branch 'hs_experimentation' at
https://git.torproject.org/user/asn/torspec.git .
My next step would be to write the anti-enumeration crypto part of
xxx-hs-id-keys-and-onion-leaking.txt (as I started doing with
c8b7e40).
Feel free to work on them. Maybe send me an IRC message before you
start touching them so that we don't do change the same areas of the
spec.
Hello cute pals. We didn't have a meeting today due to scheduling. If
you think you want to work on making point-click-publish hidden
services a reality, and hidden services better in general, then this
is what you should do:
1. [Note down when you're free next week.][1]
2. Add your name, IRC nick and email to the [Cute wiki page][2].
3. Read [Sina's proposal][3].
I'm planning to read [this Doodle][1] and send out updates on Friday
morning (Pacific). If you haven't filled it out by then, I won't be
able to account for your preferences. Please fill out the doodle only
if you think that I need to consider your availability before
scheduling the meeting. If you just want to spectate, no RSVP is
needed, you can just lurk in #tor-dev. Please make sure that you only
fill out times that you can actually make it.
Future emails about Cute Otters will be sent `to` the email addresses
listed on the [Cute wiki page][2], `cc`'ing `tor-dev` and
`tor-assistants`. If you want to get messages "to" you, you should add
yourself to the team listing on the [Cute wiki page][2].
Sina has produced an [outline of the publishing system][3] we're
planning to build. You should read it, help him improve it, and come
to the meeting next week prepared.
That's all for now,
-Tom
[1]: http://doodle.com/wqr9phdck23mac7u
[2]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Cute
[3]: https://lists.torproject.org/pipermail/tor-dev/2013-October/005558.html