Re: [tor-talk] Tor Browser Bundle with Chromium

["zaki@xxxxxxxxxx" <zaki@xxxxxxxxxx>]

This is chromium bug[1] deserves more stars from the privacy community that
wants to choose to use Chrome/ Chrome OS via tor. It's a different
privacy/security trade off depending on your threat model.

Chrome is getting much more friendly towards multiple simultaneous profiles
which makes it usable to have a privacy hardened profile.

I suspect the first place we see a build system attack is in court
documents or a Lavabit type scenario.

[1] https://code.google.com/p/chromium/issues/detail?id=447978

On Thu, Feb 19, 2015 at 2:34 PM, Mike Perry <mikeperry@xxxxxxxxxxxxxx>
wrote:

> Seth David Schoen:
> > Luis writes:
> >
> > > What are the reasons that makes building a Tor Browser using Chromium
> > > not such a good idea? I recall reading somewhere that while making a
> Tor
> > > Browser with a Chromium base would have its benefits due to Chromium's
> > > superior security model (i.e. sandboxing), there are "serious privacy
> > > issues" that would have to be solved to make that possible.
> > > My question is what are those issues? What is preventing someone from
> > > digging out all the Google integration and possible privacy-endangering
> > > features and making a Tor Browser Bundle out of it?
> >
> >
> https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs
> >
> > I think that list is kept relatively up-to-date.
>
> You might also like:
>
> https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study#chrome
>
> In particular, this paragraph is relevant to the recent Superfish MITM
> (see
> http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/
> ):
>
> "The worst offender on this front is the use of the Microsoft Windows
> CryptoAPI for certificate validation, without any alternative. This bug
> means that certificate revocation checking and intermediate certificate
> retrieval happen outside of the browser's proxy settings, and is subject
> to alteration by the OEM and/or the enterprise administrator. Worse,
> beyond the Tor proxy issues, the use of this OS certificate validation
> API means that the OEM and enterprise also have a simple entry point for
> installing their own root certificates to enable transparent HTTPS
> man-in-the-middle, with full browser validation and no user consent or
> awareness."
>
> In fact, I tried to argue with Ryan Sleevi and Adam Langley about the
> dangers of using CryptoAPI in this way, but I got crickets in response.
> I believe that supporting such MITMs is a deliberate policy from Google
> corporate that they cannot change. Adam went so far as to tell me that I
> should just fork Chromium, because they would not even consider merging
> an alternate browser-only cert store, even as a user option.
>
> However, since our ultimate goal with any browser fork is to re-merge
> with upstream so we don't have to maintain invasive patches like this, a
> corporate-level blocker on basic security patches is a non-starter for
> any project involving Chrome.
>
>
>
> P.S. How I miss the days when the outlandish doomsday scenarios that I
> imagined were still merely hypothetical. It seems every week a new
> nightmare comes true. (Man, I sure hope I'm wrong about the likelihood
> of wide-scale software build system attacks. I kind of like having
> computers).
>
>
>
> --
> Mike Perry
>
> --
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
>
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk