bcrypt

Tor Browser does more than just proxying. See my response above.

i run security at Brave and here's the answer from Taylor, our lead Tor dev:

Using the Tor network is one part of internet anonymity, serving to conceal where you are. But using the Tor network does no good if the application helpfully adds X-My-Actual-IP-Address: 123.45.67.8 to every HTTP request, and browsers tend to do a lot of things like that which we have to play whack-a-mole with. What we implement in Brave is somewhere between (a) naively just setting a SOCKS proxy, like you can do in vanilla Firefox or Chromium, and (b) mimicking everything about the Tor Browser and following the Tor Browser Design Document to the letter (https://2019.www.torproject.org/projects/torbrowser/design/). So, while you are right that there's more to Tor and that we're not the Tor Browser (and that's why we are careful to say 'private windows with Tor' and not 'Tor windows', per agreement with the Tor Project about branding), there's also more to what Brave does than just setting a SOCKS proxy like in Firefox or Chromium and leaving it at that.

Having visited her (I wrote the original post), I can say this is absolutely untrue. She is much, much better off in the prison among other inmates than in solitary. IIRC, solitary was one of the worst experiences she went through.

FWIW, Chelsea reads every single letter she receives unless it's illegible. Mail is much appreciated.

-yan (author of blog post)

Yeah, part of the nice/scary thing about HSTS is that it is a highly persistent cache. The browser is reluctant to clear it because it's a security feature. So HSTS pins can be stored for up to a year in FF/Chrome, even if you are deleting cookies regularly.

Tor Browser restricts js timing precision to 100 milliseconds, which makes this way harder. HTTPS Everywhere also creates a lot of false positives, although those can be subtracted out.

See discussion at https://trac.torproject.org/projects/tor/ticket/17423

[edit - just realized this may not answer the question you asked, which is leaks that take advantage of HSTS/HPKP/CSP. hopefully still useful info.]

I may write a blog post later about this, but here are a few that come to mind (only counting things that have demos or have been observed in the wild):

* css-visited browser history sniffing (fixed several years ago): http://dbaron.org/mozilla/visited-privacy * HSTS unique-subdomain combination supercookies: http://www.radicalresearch.co.uk/lab/hstssupercookies * lcamtuf's cache timing attack: http://lcamtuf.coredump.cx/cachetime/ * webrtc local ip leak: https://diafygi.github.io/webrtc-ips/ * panopticlick: https://panopticlick.eff.org/ * evercookie: http://samy.pl/evercookie

In addition to Egor's stuff, I'd recommend just reading the "Privacy and Security Considerations" sections of various RFC's and W3C specs. Lots of theoretical attacks in there that people simply haven't built demos for!

In case anyone's interested, slides are up at https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf and talk recording at https://www.youtube.com/watch?v=kk2GkZv6Wjs

In any case, I didn't minify or remove comments, so you can just view-source:http://zyan.scripts.mit.edu/sniffly/index.js

Yeah, I think the accuracy so far has been like 75-80% among my friends (once httpseverywhere is disabled). PS: you can check whether sites are in your HSTS cache in chrome at chrome://net-internals#hsts

I pulled the list of domains out of the Alexa Top 1M plus some domains that my friends run. But I'm not biasing results towards showing up as visited by popularity or anything like that.

I didn't set up analytics to figure out how accurate results are for the average person; having manually checked with a few people's browsers, I'd say the accuracy rate is ~75%.

adblocked domains are indistinguishable from hsts blocked domains in terms of timing. so they show up as false positives. a clever attacker could subtract them out though.

what browser and extensions? feel free to file a bug at github.com/diracdeltas/sniffly

interesting, are you using any browser addons? please file a bug at https://github.com/diracdeltas/sniffly, thanks

sort of. the hsts cache gets cleared when a private browsing session is closed or when you clear it manually in browser settings. it takes a long time (up to a year) to expire on its own.

creator here. sorry, i did not expected to be hn'ed. not running js is usually a good idea though!

There's actually a fair number of security researchers looking at browser-level exploits like those in JIT (c.f. pwn2own). My colleague Chris Rolhf co-authored a cool study on attacking JIT: https://www.nccgroup.trust/us/about-us/resources/jit/

That's really surprising. Thanks!

That's correct. I did not discover vulnerabilities in existing libraries or add backdoors to any of them. :)

The attack scenario described in the post is (1) attacker writes some plausible-looking patches to an existing library like jQuery, (2) attacker convinces library maintainer to merge the patches, (3) someone builds the library with a buggy minifier, which creates the actual backdoor.

OP here. Agree there probably isn't much benefit to minifying server-side code. However, I wouldn't be surprised if things like Closure Compiler were useful server-side.

Not convinced that HTTP2 will eradicate minifiers; it makes bundling files less useful, but minifying still gets rid of bytes. Then again, I'm not a web performance expert. :)