Currently, Signal in the browser relies on the WebCrypto API.
In principle, the WebCrypto API is fantastic - well-build cryptographic primitives, written in native code, executable from the JSVM.
In practice, using the API involves making calls to window.crypto - which could be anything.
Consider the following line of attack, which could be exploited by a plugin, or script, that has access to the browser window in which libsignal is running:
- Come up with a bogus myFakeGetRandomBytes(typedArray) method that generates non-random stuff.
window.crypto.getRandomBytes = myFakeGetRandomBytes- Import signal as normal.
I believe this exploit speaks to the absolute necessity of keeping the browser environment isolated from normal userland browser, which is probably a madhouse of unsafe code running, reading the page, etc. If you must run the signal protocol in-browser, run it in Electron, or as a Chrome app (Signal Desktop currently does the latter).
In the future, we may think about moving toward emscripten-compiled dependencies for cryptographic primitives. At the end of the day, window.crypto can be absolutely anything. If we can bundle all primitives with the rest of the application code, we can verify the integrity of that one JS bundle, e.g. with subresource integrity.