4 ms·

> 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-aligne

by Lammy 6y ago

> 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 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.

vorpalhex 6y ago
The NSA is probably not stealing your bitcoin.
fpgaminer 6y ago
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).
vbezhenar 6y ago
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.
- tialaramex 6y ago
  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.
  - vbezhenar 6y ago
    Thanks, I didn’t know it’s not a requirement. Hopefully it’ll be a requirement for every CA in the future.
tialaramex 6y ago
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.
- Lammy 6y ago
  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.
  - randomhodler84 6y ago
    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.
    - Lammy 6y ago
tablespoon 6y ago
> 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).
- zo1 6y ago
  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.
deleted 6y ago
[deleted]

by Lammy 6y ago

vorpalhex 6y ago

The NSA is probably not stealing your bitcoin.

fpgaminer 6y ago

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).

vbezhenar 6y ago

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.

tialaramex 6y ago
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.
- vbezhenar 6y ago
  Thanks, I didn’t know it’s not a requirement. Hopefully it’ll be a requirement for every CA in the future.

tialaramex 6y ago

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.

Lammy 6y ago
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.
- randomhodler84 6y ago
  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.
  - Lammy 6y ago

tablespoon 6y ago

> 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).

zo1 6y ago
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.

deleted 6y ago

[deleted]