[liberationtech] Snakeoil and suspicious encryption services

[Aymeric Vitte]

Interesting thoughts, please see my comments below.

Le 22/07/2014 03:48, Seth David Schoen a écrit :
> 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.

It was designed with this intention but this mechanism will be removed.

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

Yes and no, as I answered previously the nonce does secure a little bit 
the loading of something that the app needs to work, but as I wrote this 
does not secure anything at the end against a mitm, so https if people 
trust it or retrieve the code and inject it locally as I explained, 
please see my previous answers about this, and if people want to weight 
on why Mozilla and Google have decided this policy that forces us to do 
insecure things, then please go ahead.

And for the current phase there are no specific crypto keys for the 
users (it's doing the equivalent of the Onion Proxy inside browsers, no 
need for keys), for the final phase the crypto keys will be ephemeral.

>
> 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 am thinking about these issues since quite some time, unfortunately I 
reached the conclusion that you can not secure the code loading.

The only reliable way I think is to get the code from the site or some 
mirrors and check from different sources that it is the good one.

But you envision the fact that you could detect a change, I am not 100% 
sure but I still think that even if you can not stop a mitm from 
changing your code there are good chances, if you have foreseen it, that 
you can indeed detect it and tell it to the user, like for example 
including functions that checks what is in the code or objects once the 
code has been executed, this still could be detected and removed by the 
mitm, but not sure it can succeed each time if your checks are a kind of 
random code, to study... unfortunately such features would break the 
possibility to check the code as a whole based on its hash for example...

The IP addresses of the users: strangely among all remarks I got so far, 
nobody raised the issue that we could correlate the code loading with 
the anonymized circuits establishment if we can monitor the Tor/Peersm 
bridges, that's why there is the OK button to start the app, you can 
load it and start whenever you like making hard to correlate your 
activity. But again, this issue disappears if you execute the code locally.

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

Indeed extensions can be mitmed as easily as js code, the big difference 
is that it's easy for any skilled js people to check what is doing the 
js code, while it can be difficult for extensions I believe.

The problem remains that normal users can not do this, so back to the 
local code solution.

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms