Aymeric Vitte writes: > You obviously don't know what you are talking about or just did not > get what I explained or just do not understand http versus https or > the contrary, or just do not understand the web, what's on client > side (browser) or on server side, or don't get that your extension > can be mitmed too including its signature. > > So unfortunately I have to stop this discussion right here with you, > not to waste the time of serious people on this list, if you want to > restart with another tone, then please go, but first checkout what > is writen on Peersm site, everything is explained, including your > focus on elementary mitm issue, your arguments and judgement are so > basic that I am wondering why I am answering it, you should do some > reading, and if you can trivially defeat Peersm, then just show us > how
The Peersm homepage is loaded over HTTP and right at the bottom says </div><script type="text/javascript" id="script" src="https://peersm.com/node-browser.js"; nonce="90f64442274ffb89dd6a1c409f28404e35d514f6"></script> Well, that nonce is probably different for different users. An attacker (like the barista) can make that get loaded as </div><script type="text/javascript" id="script" src="https://peeersm.com/node-browser.js"; nonce="90f64442274ffb89dd6a1c409f28404e35d514f6"></script> The version of the node-browser.js file there can be slightly changed to leak the user's crypto keys by synthesizing an HTTP GET to some other host with the user's private keys as part of the URL. The security of your crypto protocol is not relevant to this attack because substituting a modified client leaks key material _outside of your protocol_, much as redirecting http://www.mozilla.com/ via a captive portal and then giving users a backdoored download of Firefox would allow leaking TLS session keys (without breaking TLS). It's true that the user could detect the change if they view source, but the change may be a very small percentage of the real code, so it's a pretty significant practical question how the user will detect the change. (And will the user be willing to check what is currently 456 kB of Javascript every time they use Peersm?) There have also been some tricks to make it hard for the user to view source (or to make the source that appears look wrong). Hopefully future browsers will reliably show authentic source code, but even if they do, we're left with the "how does the user know that this 456 kB of Javascript is really right?" problem. The fact that it was apparently loaded from the right domain is not very satisfactory by itself, both because of small typos, attempts to make it look like the Javascript was loaded over a CDN for efficiency reasons, and maybe homoglyph attacks, while even if the user is sure that it was genuinely loaded over HTTPS from peersm.com, there is still a risk that you as the software developer could somehow be forced to give particular users a fake version (based on their client IP address), or that the peersm.com server could be hacked and could give some users a fake version without your even realizing it. I would be happy to accept that browser extensions only partially address these threats -- especially threats of attacks by the browser extension developer, or involving attacks against the extension developer's infrastructure. We have better assurances that the network operator can't substitute Javascript code for the Javascript code that we wanted (by installing the browser extension only over HTTPS, and not re-downloading it every time). But currently, we don't have a good assurance that the browser extension we got is the same one that everyone else got (and that may have been audited), nor that we get the same updates as all other users. I think it's quite important for browser developers and browser extension developers to address these limitations. -- Seth Schoen <[email protected]> Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at [email protected].
