Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Snakeoil and suspicious encryption services

Seth David Schoen schoen at
Mon Jul 21 18:48:36 PDT 2014

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="" 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="" 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 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, 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 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  <schoen at>
Senior Staff Technologist             
Electronic Frontier Foundation        
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107

More information about the liberationtech mailing list