Part 1 says that they use SSL-stripping attacks to replace cryptocurrency addresses with their own address, allowing them to capture e.g. transfers to a crypto mixer.
https://nusenu.medium.com/how-malicious-tor-relays-are-explo...
https://nusenu.medium.com/how-malicious-tor-relays-are-explo...
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.
Moral of the story, if you a are a site operator use HSTS. And if you're on tor, you should maybe consider configuring things so you only use tls.
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.
Verizon puts an MITM proxy from Mcaffe on people's routers (with their consent) that does this.
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.
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).
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.
> 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.
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).
Here's an example with HN (notice the protocol in the req/res):
$ curl -v http://news.ycombinator.com
[...]
< HTTP/1.1 301 Moved Permanently
< Location: https://news.ycombinator.com/
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.
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.
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...
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...
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.
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.
The result looks like this: https://imgur.com/otaBerJ
No MITM of encrypted connections needed.
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.