The thing that confuses me about that is if you have not installed the malicious MITM's root cert in your browser isn't that going to fail?
Or are these MITM's somehow signing stuff with well known root certs? That seems like it would be a much bigger story. Or are TOR users really accepting self-signed certs when passing around their bitcoin addresses?
Maybe there are bitcoin clients that don't validate the chain when doing TLS? Given the sorry security posture of so many exchanges this is somewhat more plausible.
They MITM connections that aren't encrypted and prevent them from becoming so.
Many bitcoin mixers are not HSTS preloaded. And to avoid creating a trail, TOR Browser doesn't save frequently visited sites, history for autocomplete, cached redirects, or cached HSTS headers between sessions.
And as Tor users prize secrecy, many don't bookmark their bitcoin mixer. Instead they key in the address manually - and sometimes they're used to doing without the https://www. prefix. And by convention, browsers use http when you do that.
The exit node then removes the http-to-https redirect, and presents the bitcoin mixer over http, with the bitcoin addresses replaced.
It's almost impossible for the Tor project to detect this, as the attackers only target a small whitelist of sites - so the Tor project can only detect attackers by guessing the sites on the attack whitelist.
However, the first request is over http, before it gets redirected and encrypted. This is where the malicious relay node would intercept and change the response.
This is actually what's going on. It's what HSTS and HSTS preloading protects you against, it's why Chrome is moving to just assuming HTTPS when you type domain names without specifying, and it's why Firefox now has "HTTPS only mode" where it goes further and just rewrites all HTTP as HTTPS (even in random links you follow) and gives you an interstitial caution page to decide if you really want to try HTTP when HTTPS fails.
People have all these fancy high-tech Hollywood-style theories about how they imagine things being attacked, but the reality is almost always far more boring.
Yeah. And for anyone unaware, this technique, SSL stripping, was made well-known (and perhaps pioneered?) by Moxie Marlinspike of Signal with his tool sslstrip back in 2011: https://github.com/moxie0/sslstrip. I believe that's what he was most famous for before Signal.
It's unfortunate that this very simple attack remains extremely successful even a decade later. I'm surprised Tor Browser didn't enforce HTTPS Everywhere for all domains by default years ago. HTTPS Everywhere was released in 2010, before sslstrip, even. HSTS and HSTS preloading helps, but individual site owners still have to explicitly submit their site to be added to the preload list.
HSTS preloading is hierarchical, so it's not necessary for individual site owners to submit, if the domain above yours opted its entire hierarchy in, you're in.
So if you own example.foo or example.dev you don't need to do anything and indeed can't choose, because Google (owners of the foo and dev top level domains) preloaded the entire TLD.
http://some.example.dev/ can still exist, but you can't go there in a typical modern web browser, it will take you to https://some.example.dev/ regardless. So software that knows it actually wants the plaintext protocol can use it, but your ordinary users can't get SSL stripped.
i highly doubt that. in fact i knew about ssl striping before i knew moxie or even sslstrip and this attack was probably already well known when someone came up with a seperate url scheme for https...
Yeah, "pioneered" was too strong of a word. I'm sure there's no way he could've been the first person to come up with the idea. He was just the one who widely popularized the attack and released a convenient tool for it.
For anyone who remembers it, "Firesheep" also had a big impact, too. It didn't do anything special or novel whatsoever, but it was a really easy-to-use tool that drove home to the average person just how dangerous plaintext HTTP was. Lots of people immediately started using it in school classes and logging into everyone else's Facebook and Twitter accounts. I'm not sure if it was the direct cause, but I know not long after that, all the big services began switching to HTTPS for everything rather than just login and payment pages.
There's probably some startup lesson buried in there...
That makes sense. I know the MITMproxy they mentioned re-signs the traffic, but it will not work unless you install its self-generated cert so I thought it was weird that the malicious exit nodes were using it.
Also, if someone is running a bitcoin exchange that has port 80 open for anything more than a redirect I would not do business with them.
> you have not installed the malicious MITM's root cert in your browser
PROTIP: Your browser already comes with all the malicious root certs a Five-Eyes-aligned attacker would ever need. The Tor Browser uses Mozilla's Root Store if you want to go see what's in it. To pick a random example look at VeriSign's root, the company that runs dot-com and dot-net, and manages dot-gov. Do you think they might be Best Fwends with the DoD/NSA/etc? https://www.ntia.doc.gov/page/verisign-cooperative-agreement
I also think it's a pretty safe bet that many many other roots are compromised many times over even if nobody ever willingly cooperated with anything.
This invokes a really stupid conspiracy theory, to achieve a very marginal goal, in a space where it would be easy to produce evidence if it was real and yet of course no effort is made to even look for such evidence...
> To pick a random example look at VeriSign's root
But why though? Verisign is not in fact operating a trusted CA, so that makes as much sense for an example as looking at some root you just minted on your laptop.
Most likely, as so often with conspiracy theorists, you didn't stop to see if the facts line up with your beliefs, after all "VeriSign" is named right there in a certificate Mozilla trusts, surely that's a smoking gun right?
Er, no. DigiCert owns the business behind that, collecting rights to names for a whole bunch of long obsolete CAs. The "smoking gun" CA that has the "VeriSign" branding is only trusted by Mozilla to sign S/MIME email certificates, something you likely couldn't care less about and certainly won't be using in the Tor Browser.
This all reminds me of what ekr said about this years ago, the most likely explanation for why we do not see practical attacks on security protocols like TLS is that it's almost always easier to find a weaker link elsewhere, see the parts of this thread explaining much simpler tricks that we know work.
I am not any sort of conspiracy theorist and am very offended at your insult. Why do you go online if you aren’t going to be nice to others? Intent is obviously unknowable, but here you are doing exactly that to me.
What you have proposed is a conspiracy theory, there is no practical evidence and tales of 5 eyes subversion of the root trust stores (in a world of certificate transparency) is just FUD. I’m sorry if you were offended by the parents reply, but I support their position and this is a virtual house of science, math and reason — I think you earned a serious push back when making a wild easily detectable and debunkable myth, when the practical explanation of the attack does not require such fantasies.
IMO you are a fool if you think every USA-based CA has not been NSLed for their private keys. I am saying it is impossible to know so good OpSec demands we assume the worst. Feel free not to act accordingly, but I will act like all TLS is broken all the time.
And now you are being offensive — This is a wild claim, and use of HSMs would prevent simply handing keys over in such cases. The most popular CA is let’s encrypt, it is offensive to claim that they are compromised, or that they have not taken steps to build a system that was difficult to compromise. One could argue they could be compelled to sign an arbitrary csr, however this would be detected by the CT infrastructure, and a big deal when discovered. You are free to act like everything is in the clear of course, but don’t cast negative FUD on good projects that actively protect the world. Trying to convince the world TLS trust system is hopeless broken is a very dangerous conspiracy theory to be peddling.
I support your right to discern your own risk level and act accordingly, and I hope you will allow me the same. After all, the fool is both the highest and lowest-value card :)
The concern here isn't state actors; just lowly exit node operators looking to skeeze a buck. Check the other comments for how it's actually done.
More importantly, I think your fear about state actors abusing trusted root certificates is unfounded. As soon as a malicious cert is found, the issuing root cert will be nuked from orbit by all the major browser vendors. It's not a viable option for state actors, especially when they have much better options (like the NSA tapping Google's internal networks, for example).
> To pick a random example look at VeriSign's root, the company that runs dot-com and dot-net, and manages dot-gov. Do you think they might be Best Fwends with the DoD/NSA/etc?
Even if that's true, why would the NSA exploit it for such a stupid and shotgun application as MITM'ing Tor exit nodes? It would basically be leaving a calling-card that results in a ton of pointless friendly-fire damage, and I don't think spies like to do stuff like that (you know, the whole cloak part of cloak and dagger).
Well one theory is that Tor Exit nodes aren't the only place that such an actor is "tapping" into network connections and can MITM the traffic. I.e. They might be tapping into the network at the ISP-level.
There's certificate transparency, it's required for all certificates, so if any root will issue fake certificate, you can catch and report it. So I'm not sure if that's a pretty safe bet.
Logging (for Certificate Transparency) isn't a policy requirement. In fact last time I looked, there are (special purpose, typically in industrial settings so their clients aren't web browsers) Intermediates under some roots that just aren't outfitted to be capable of logging at all. Their existence is not a policy violation.
Clients (most particularly, popular browsers such as Chrome) can and do require SCTs (effectively proof the certificate was logged) to accept a certificate, but that just means if you issue a certificate under a trusted root without logging it, it just won't work in such browsers until somebody logs it.
You can even do this intentionally, if you're Google for example you get yourself (unlogged) certificates for shiny-new-product.google.example and shiny-new-product.example on Monday, and you don't need to worry that some eagle-eyed journalist spots that in the logs before your official product launch on Thursday evening, live in front of millions of people. You can log the certificate yourself minutes before launch, then attach the SCTs and it'll work.
[Google even got this wrong once, mistakenly using a certificate they didn't have enough SCTs for due to a bug. Chrome rejected these certificates and so, for a brief period until they fixed the problem, Google's own sites didn't work in Chrome]
Now, that last part is technically not trivial to do correctly (chances are your existing web dev tooling can't do SCT stapling, or at least you'd need to go read a bunch of instructions that you aren't going to bother with) and so when you get a Let's Encrypt cert, or you buy something cheap from a reseller, it is already logged for you, the SCTs are baked inside the certificate you get -- but that's just because there isn't a big market for unlogged certificates, not because such certificates can't or mustn't exist.
Or are these MITM's somehow signing stuff with well known root certs? That seems like it would be a much bigger story. Or are TOR users really accepting self-signed certs when passing around their bitcoin addresses?
Maybe there are bitcoin clients that don't validate the chain when doing TLS? Given the sorry security posture of so many exchanges this is somewhat more plausible.