[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7085 [Tor bundles/installation]: Integrate Cryptocat Browser Extension into Tor Browser Bundle
#7085: Integrate Cryptocat Browser Extension into Tor Browser Bundle
--------------------------------------+-------------------------------------
Reporter: kaepora | Owner: erinn
Type: enhancement | Status: new
Priority: normal | Milestone: TorBrowserBundle 2.2.x-stable
Component: Tor bundles/installation | Version: Tor: unspecified
Keywords: | Parent:
Points: | Actualpoints:
--------------------------------------+-------------------------------------
Comment(by kaepora):
Replying to [comment:29 mikeperry]:
> Replying to [comment:27 kaepora]:
>
>
> > Replying to [comment:26 mikeperry]:
> >
> >
> > > Second, I am very concerned that there were XUL XSS bugs in the chat
windows. To me, that's a bad sign. Ideally, I'd like to see something on
your side (ie a tag in your bugtracker or some other document you wrote)
that enumerates the patches that resulted from your first audit.
> > >
> > >
> >
> > The patches in which we fixed the audit bugs are enumerated (perhaps
incompletely) in this [https://blog.crypto.cat/2012/11/security-update-
our-first-full-audit/ blog post].
> >
> >
>
> This is great. You should show this to whoever you contact about further
audit. Bugs tend to come in groups of similar nature, and seeing the types
of mistakes you made will help the second auditor find more of them.
>
Thanks :-)
>
>
> > > Third, while it does look like the audit was extremely thorough, I
think I'd prefer a second one for this reason. XUL XSS is quite serious,
and since you're writing a network-facing app with lots of user and
network provided content, its critical that your code receives lots of
this type of review.
> > >
> > >
> >
> > Very well. Who would you recommend to perform the second audit? If you
can give me a preferred auditor or a list of auditors that the Tor Project
would feel comfortable with, I have no problem getting in touch with them.
> >
> >
>
> A quick search for "Firefox extension XSS" and related queries turns up
Roee Hay and Roberto Liverani as previous folks who have done similar
audits. I don't know these people, but I suppose an email couldn't hurt.
>
> You should also send Dan Veditz an email (dveditz at mozilla). He is a
very Tor-friendly Mozilla security engineer. He might be too busy to give
you a full review, but I bet if you also mention that integration with
Mozilla's Social API is something you're considering, he might be able to
justify devoting his time for such a review. Or at least point you in the
right direction for getting a better understanding of the security issues
the Social API team has had to deal with. I bet they are similar in
nature.
>
> I can also do a review later, but for the next month or two I will be
extremely busy trying to get TBB working with Firefox 17ESR. I also think
the people I mentioned might actually be better at it than me (except
perhaps for spotting potential proxy bypass issues). My approach with
Torbutton has mostly been "Zomg, don't ever interact with or display
content window material in XUL." Sadly, even that failed me when
implementing the content window JS hook injection. Luckily, Dan Veditz
came to the rescue in that case :).
>
I'll get in touch with Dan Veditz.
>
>
> > > Fourth, I guess I am mildly concerned about the crypto security. I
don't believe it's impossible to do crypto with JS, but I would prefer it
if the underlying primitive implementations also had a chance for review,
especially since our inclusion of this addon would probably be seen as
endorsement of its crypto and security by many.
> > >
> > >
> >
> > Our OTR implementation has been reviewed. If there is a specific type
of further review you would wish to ask for, we can see it done.
> >
> >
>
> I think Nick is the person to best answer this. Or Ian himself. I also
thought Moxie's observations on the website version were spot-on. Has he
looked into the browser version?
Moxie has commented positively on the switch to a plugin version and has
been optimistic in general. He has not audited the code (or at least, he
hasn't informed me), but he was the person who recommended the team behind
our first audit.
>
> Things that come to my mind include:
>
> Is your implementation fully compatible with other OTR and MPOTR
implementations? Verifying this to be the case can be one way to probe for
implementation errors.
Our OTR implementation is fully compatible with Pidgin-OTR and Adium-OTR.
We have tested this thoroughly.
>
> One question academic researchers in need of racking up publication
count will drool over is "Can content window JS extract side channel info
about your crypto operations?" If the JS scheduling mechanism is
predictable/discoverable and/or runs in the same thread, the answer here
might actually be "Yes. Very Yes.". Unfortunately, the publication bias in
academia may very well cause them to structure their experiments such that
the answer is "Yes" anyway regardless of threading model or content window
JS timer resolution... :/
What you wrote here really draws on how new all this research is. Hence
our long, careful and uncertain discussion...
I'll get some stuff done on my end and get back to you. Thanks for being
considerate and open, it really means a lot.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7085#comment:30>
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