[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #12671 [meek]: Does meek's network-facing browser run javascript?
#12671: Does meek's network-facing browser run javascript?
------------------------+-----------------
Reporter: arma | Owner: dcf
Type: defect | Status: new
Priority: normal | Milestone:
Component: meek | Version:
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
------------------------+-----------------
Comment (by dcf):
Replying to [ticket:12671 arma]:
> Can Amazon S3
(meek doesn't have anything to do with S3. You're thinking of
[http://www.cs.utexas.edu/~amir/papers/CloudTransport.pdf CloudTransport].
If meek used an Amazon service, it would be their CDN
[[doc/meek#CloudFront|CloudFront]], not their storage service S3.)
> Can Amazon S3 pass javascript to meek's network-facing browser (i.e. the
copy of Tor Browser that it runs with a separate profile), and it will run
it?
No, the headless browser doesn't interpret anything it receives, except to
base64-encode it and pass it back to meek-client.
[https://gitweb.torproject.org/pluggable-
transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/firefox/components/main.js#l1
Here is how the protocol looks.] We use an [https://developer.mozilla.org
/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIHttpChannel
nsIHttpChannel] and read the response with [https://developer.mozilla.org
/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIBinaryInputStream
nsIBinaryInputStream] as a binary string.
It's like when you do an XMLHttpRequest; the browser doesn't interpret or
run or display the response, even if it happens to contain HTML. It's not
as if we put a URL in the address bar and then read the response by
walking the rendered DOM.
And of course, there's no way for the CDN to affect what gets rendered in
your actual Tor Browser, because all that the CDN sees (and all the
headless browser sees) is encapsulated Tor TLS. The CDN is about as
privileged as your ISP or guard.
> Seems like disabling javascript would provide a way for S3 to
distinguish meek users from the typical web user, but leaving it enabled
would be sad (and surprising) for users who prefer to disable javascript.
That said, there are already other ways for S3 itself to learn that it's a
meek user, and there shouldn't be a way for an external observer to learn
whether they run it? And in that case it would be wise to lock down meek's
browser at least as much as tor browser itself?
You're right that we don't try to hide from the CDN; we need at least that
much from them. After all, the hidden domain name in all the domain-
fronted requests points straight to a meek-server instance on a Tor
bridge, so there is a trivial distinguisher. (E.g., Google would just
block the domain meek-reflect.appspot.com if they wanted to.)
[https://gitweb.torproject.org/builders/tor-browser-
bundle.git/blob/5400da654020a34edb9edee70a0583a89231c4fe:/Bundle-
Data/PTConfigs/meek-http-helper-user.js Here are the extra settings we
apply in the headless browser], mainly undoing some of Tor Browser's
configuration like the proxy setting. Other settings are inherited from
Tor Browser. We could disable JavaScript there, but I don't know whether
you'd call it defense in depth or voodoo. For example, we could also
disable image loading, in order to prevent the headless browser from
loading a tracking gif or something, but the extension doesn't work in a
way that could cause it to want to load an image.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12671#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs