Tor Browser 6.0 is released
blog.torproject.org
blog.torproject.org
Perhaps each CDN could have a symlink in its root directory with the hash of each file it serves, redirecting to that file. Then you'd be able to find any file by its hash as long as you have the CDN host name.
EDIT: I see now this is a security measure (protection against a hostile CDN), rather than a way to avoid dependence on a single CDN. I hope what I suggest is still possible though.
I have no idea if this is problematic in practice, though.
Just 'uBlock Origin'. You are probably mixing up the names of µTorrent and uBlock Origin.
Source: see the Tor Browser docs on why they enable JS by default (though NoScript is installed and can be configured to block all JS, if you know the risks) https://www.torproject.org/docs/faq.html.en#TBBJavaScriptEna...
I know they're trying to serve users that can't be expected to play the whitelisting game, but they really should be stricter here. It's already trivial to differentiate a Tor user from a regular one, they might as well set the most secure defaults possible.
The main concern with adding uBlock Origin would be flipping bits that make your browser unique and stand out in the crowd. You can evaluate that risk based on your own operational profile.
[1] https://mailman.boum.org/pipermail/tails-dev/2016-January/01...
Altho I think the new security slider in Tor Browser effectively breaks that crowd out into those groups plus any individual whitelisting the user allows
I think it should just default the settings to the highest security level, but understand the design requirement that many users use Tor as their primary browser so need video, JAR's etc.
The user will be presented with a certificate error (or denied outright, depending on the browser). If the user decides to add an exception, only then will a handshake succeed and the MITM be possible (in this particular scenario).
The link you posted is indeed a MITM proxy for SSL, but it will generate certificate errors, as my grandparent said. Users will know the MITM attack is going on (unless the website doesn't use HSTS and the attacker has stolen/bought a signing key from a CA registered in your device's trust store).
When you use XPKI, you are trusting every single CA in the world to certify every single site in the world.
A sane PKI would limit what CAs are permitted to certify (e.g. TÜRKTRUST might be permitted to certify *.tr, but nothing else — not foo.br, bar.gov or baz.co.uk). But XPKI is neither a sane nor a secure PKI.
This scenario might be plausible for targeted attacks by nation states, but not for something as simple as public WiFi.
The fact that Trustwave still has their CA certificate proves you wrong. They provided a sub-CA to one of their customers for the purpose of MITM. They got a slap on the wrist, gave a promist that they'd never do it again, and that was it. Your browser still trusts this company that has demonstrated that they are perfectly willing to compromise the safety of the whole CA system for a sale.
It wasn't WiFi, but that's not really a relevant detail here. Selling certs for the purpose of MITM is.
[1]: https://wiki.mozilla.org/CA:Communications#February_17.2C_20...
With the existing system, certificate "errors" that are really just "warnings" should not be allowed to be bypassed. The fact that certificate errors can be ignored is something that should never have been allowed to take place. Unfortunately with the historical fact that legit certificates were inexcusably expensive to obtain for internal/test projects meant that self-signed certificates became commonplace.
We're waiting for a genius to come up with a new strategy for encryption that doesn't rely on trust being determined by a third party entity (ie: certificate authorities). Letsencrypt is nice and all, but it's still just a free workaround for a system nobody really wants. "It's not possible to do it any other way" is just pseudo-speak for "nobody has invented a better way yet".
Why the strategy for encryption has relied on public/private keys for so long with no real alternative strikes me as odd. After 30+ years, nobody has thought of something else?
https://tools.ietf.org/html/rfc6797#section-12.1
So you can encourage people to use HSTS and then get part of that behavior at least for individual sites.
The result? Weeks, even months, of not being able to use the domain without encryption, all because someone else previously had the domain added to the HSTS preload list. Removal from the preload list is by request only; there is no automation in place to detect the lack of an HSTS header to mean that the domain is no longer to be considered a participant. Even worse, the request to be removed can take an indeterminate amount of time to be disseminated to end users of the browser. The preload list is not pushed to clients via something like a daily digest; the list is hardcoded into releases of the browser. This means it can take an absurd length of time to see a domain removed from the list, as it depends on every individual user updating the browser to the latest version, and only once the vendor even gets around to updating the hardcoded list in a given release to include your domain's removal.
How such a mechanism was ever acceptable is beyond me. Domain ownership is technically fluid, and yet the implementation was designed in such a way as to assume that domain ownership never changes.
They probably wanted to encourage the new owner to use TLS as well.
Not really, I think you've hit the nail on the head. There are plenty of pie-in-the-sky proposals that start from an axiom like "we should replace the centralized CAs with a distributed, decentralized system", but so far I haven't heard of anything that is robust enough to credibly improve on the current architecture.
Off the top of my head, the closest things I can think of to what you're asking for are:
- Namecoin (depends on the Bitcoin blockchain, with everything that implies e.g. huge computational overhead, tight coupling to the volatile Bitcoin economy, and potential attacks from mining cartels etc.)
- The PGP web-of-trust (places additional burden on users who have to decide whether many different intermediaries are "trustworthy"; totally impractical for John Q. Public, in my opinion)
- CACert.org (still relies on a centrally trusted certificate issuer, but crowdsources the identity validation stuff)
If you have better ideas, let's hear them!
https://support.opendns.com/entries/46060260-FamilyShield-Ro...
They are trying to show a block page because this site is classified as Proxy/Anonymizer by OpenDNS, but they have to MITM the HTTPS connection in order to (try to) do so.
You might be able to avoid this censorship by using a different DNS resolver, depending how the airport wifi is implementing it.
Firefox's “Tracking Protection” is one of these.
Ouch
Many have put forth those users were using flash, plugins or were convinced to download and execute something, but we don't know do we? And until developers do, the Tor Browser bundle could have a vulnerability that could compromise its main purpose.
The zerodium price list has Firefox 0day at $30k[1] a pop - compared to $100k+ (today ~$1M) for Chrome
The long term solution for Tor Browser is to build on Chromium + Containers/VM + Isolating proxy
[0] https://www.wired.com/2013/09/freedom-hosting-fbi/
[1] https://www.wired.com/2015/11/heres-a-spy-firms-price-list-f...
Surely text-mode gopher would also be more secure? (Only half-joking)
I guess early nineties, late 80ies network C code is wonderful for security! On the plus side it let's less to audit. And you rewrite it in a secure language.
That would let you use your preferred browser, rather than being forced to use the browser Tor chose to bundle.
By bundling a separate browser, Tor can provide sensible defaults to protect users.
The default tor browser ensures most tor users look identical so malicious services cannot finger print individual users. It disables a small group of firefox features which make finger printing extremely trivia (RPC Chat, GPU access).
In most cases of people being de-anonimized on TOR they're normally running an alternative browser, or out of date TORbrowser.
isn't everyone using TOR today using tomorrow's out of date TORbrowser? Meaning that traffic today can be recorded and analysed for vulnerabilities tomorrow.
Its really hard to open an RPC chat session on packet logs. Or request GPU diagnostic information after the connection is terminated.
Most finger printing isn't just write/response times. Latency is a bad indicator of individuality. It's a lot more in depth and requires actively speaking to that browser and noting what features it does/doesn't present, how those features are unique, and how long certain tasks take to process.
Each individual piece of data is small (generally, some browser features make ID trivial), and common. But building up several can give you some confidence in an identity.
In theory by bundling Tor with a browser that has sane defaults and then sand boxing that from the rest of your applications, one can isolate specific communications to Tor with lower potential exposure.
There are VMs that do that but still wouldn't recommend that to someone that doesn't understand tor and networking. Even inside such a VM you'd still use Torbrowser.
It combines Tor and app-level security/privacy measures in an accessible way.
I'm curious why you believe this, outside a few watering hole attacks, and the (now-patched) CMU attack. Given a known-good entry guard, where is Tor broken?
Consider we have that system wide tor proxy instead of the torbrowser bundle. Now exit node operators get all your TCP traffic. It's fine if one knows what they're doing[0], but if that was the default way for the average user to get on Tor? A privacy and security disaster IMO. Not only would we not provide mediocre privacy, we'd actually endanger people.
[0] and you've got proper stream isolation, which I'm not sure how possible it is system-wide with unmodified software
https://www.usenix.org/legacy/event/leet11/tech/full_papers/...
https://www.torproject.org/projects/torbrowser/design/
There's probably a more specific statement from the Tor Project that I'm forgetting at the moment that sets forth the idea that you should only use Tor with Tor-aware client software (that controls what privacy leakages may occur at the application layer).
There are also tickets in Tor's TRAC issue tracker for Chrome. Once again, using Chrome securely would require several patches to source.
Actually, I'm pretty sure this is untrue. I'm reasonably certain we're actively working with the Tor Browser developers to get their patches merged into core (but preffed off) so that they don't have to maintain a stack of patches on top of Firefox.
(Disclaimer: Mozilla employee)
Keep in mind that even outside of a corporate environment, Windows is not private.
Why do apple users do this? Do you really not know what's under the hood of your macbook? Honest question.
Or are you saying it's because of weak hardware? Other, arguably more taxing software runs fine, but TorBrowser suffers from an uncanny slowdown.
I can tell you my last computer was a 4 x 1GB Kingston HyperX on a Q9450 Core 2 Quad with a Gigabyte GA-X48-DQ2 motherboard, and it's been a few years.
I only know my Mac has 16GB of RAM, and that's part of the beauty of it.
Also, since you can't tell from looking at the laptop (they are all identical since the first retina macbook from 2012), you must go to the 'about this mac' menu, which gives you the model name and revision date. In my case this is "Macbook Pro (Retina, Mid 2012)".
When I used to build my own PC's, I could tell you the brand, model, revision etc of every component inside, but since just about every internal part of an Apple laptop (motherboard, SSD, memory etc) is custom fabricated, there is no point in trying to remember what's inside. I know my laptop has the 'second fastest' i7 I could choose from in that time, and the 16GB memory option, but don't ask me which specific i7 or which DDR type I have, I don't know and honestly I no longer care.
Well, if you're a Mac user then presumably the hood of your car is welded shut.
An intuition behind that analogy, I think, is that people will appreciate the importance of being allowed to do car maintenance even if they don't do it: that non-car-tinkerers will still see the value in having a hood that they can open. For example, they'll want to be able to choose others to perform the maintenance or not be dependent on the manufacturer in an emergency. Maybe sufficiently Apple-like car companies will succeed in changing that intuition or have already changed it quite a bit?
To use your analogy: If our cars are the same model year but mine is faster and you're wondering why or just complaining about it, maybe you'd care what's under the hood then.
An i7-6700K will be and perform the same as any other 6700K, save for poor cooling and aftermarket overclocking.
Unless the model does something special with the components (it shouldn't) then just typing out the components is what matters, not whether (or when) Acer, Apple, or ASUS designed the chassis.
I can tell you that my thinkpad is an i7 with 16GB of memory, so if it ran slow on my machine I'd blame the browser.
My point was that you spend just as many keystrokes to tell the reader it's a late 2015 model macbook pro as you would to type out "i5/8GB" or whatever, but the phrase "late 2015 macbook" means literally nothing to some readers.