End-to-end encryption in the browser
blog.excalidraw.com
blog.excalidraw.com
If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.
Sure, there are a couple extra steps needed here:
- The website author needs to avoid casually throwing in dependencies (unlike perhaps the average JS project)
- HTTPS for loading code resources is crucial; maybe even CDNs need to be avoided
- The user needs to avoid having browser extensions enabled
But the fundamental problem doesn't seem different nor intractable.
* A native app can be installed once. A browser app is effectively downloaded fresh each time you use it. That give more exposure to attack. * A native app is downloaded, then run. A browser app does both in one step. Separation gives the user a chance to verify using hashes, signatures, etc, ideally cross checked from multiple different domains incase only the download server/primary domain is hacked. If there are sensitive user cookies, malicious javascript can steal them immediately on page load.
Native apps that update themselves can be a mess, but OS or package manager updates are generally carefully managed (I.E. apt).
For the CDN concern, sub resource integrity should work well (of course you need to verify that the version you hash is actually safe, which people sometimes skip). I think browser support is good these days.
But I agree, not intractable.
To reduce that risk, and temptation, we want to be in a model where the likelihood of detecting a compromised payload is increased. This is why software distributions like Debian are important, because they serve the same content to all their users, and there is a chain of verification that is established. One vigilant user is enough to detect that breach.
An even better solution is if the source code is available because it makes it easier for vigilant users to find those undesirable changes. This, paired with reproducible builds also allow to independently verify that the compiled output is indeed produced from that given source code.
Somewhere on that line we also have App stores which don't gives much more guarantees than the website but transfer that trust from the publishers to the application distribution platform. A compromised user still has the opportunity to capture the binary and submit it for analysis.
> In any E2E context you have to trust the client code.
I don't have to trust code which is continuously being delievered from the server. This is an intractable problem.
To add on to that, when there's an update, you usually can't diff it properly because large parts of the transpiled Javascript may change because of a one line change in the actual source code.
This is all assuming the website isn't actively trying to make it difficult for you to analyze their code.
At least if it's open source, you can inspect the source code then verify that the output is the same.
You have to trust it not to exfiltrate your local plaintext data, sure; but encryption and key management in a native app might be outsourced to a TPM chip, in a way where the native app can't steal the keys, nor decrypt anything "behind your back", in practical terms meaning there's a smaller surface-area of code to audit.
For native apps, you can install a particular version from source and not change it.
Seems the maintainer maded the point of protecting himself more than anything.
Even if Excalidraw _was_ compromised and someone put malicious JS code in the app, the total scope of the breach would be very limited. Records could only be exfiltrated on an individual basis, and only if the users opened their URLs and exposed the decryption key to the malicious Javascript payload.
This is a smart way to offer a free service without worrying too much about liability or compliance with the ever-expanding set of regional privacy laws.
What about something like a browser extension that queries an audit server for a list of signed hashes of ‘safe’ JS?
- Well-known code auditors could perform reviews of JS
- They could sign JS they find safe with their PGP keys and upload it to some server
- Users could choose to trust certain auditors
- Every time you visit a site that you choose to require this kind of validation, you could check that the hashed JS matches the key
I guess we’re going the way of PKI+SHA hashes of distributed binaries all over again though. Also, if the website updates JS, you’d need to wait for auditors to review it, and there’s a whole mess there (websites would probably have to serve beta versions of their code ahead of release so auditors could have time to review them). Finally, JS would have to be static across all users and I’m not sure how feasible this is.
There is some benefit, though? Now you are distributing the trust over ProtonMail and your trusted auditors. This could be useful if we find ProtonMail to be compromised one day. This might even spawn businesses aimed solely at reviewing websites’ code.
There has to be a better way to do this. How can we bring ‘code review’ to web applications?
I don't think there are any browser standards for that. I guess that such a webapp is too niche and this threat is extremely niche, so very few people would care for it to be a general purpose standard.
Now an attacker who dumps the server's disks doesn't compromise user data, they'd have to activate modify the website. This raises the bar of a successful targeted attack and aldosterone basically eliminates risk from untargeted attacks, which is well worth doing.
(Also now warrants that can compel disclosure have nothing they can target, eliminating Lavabit-style attacks. There's still the possibility of court orders making you write software like the proposed use of the All Writs Act against Apple, but that's on much less certain legal ground.)
It's true that this doesn't let you avoid trusting the provider, but you're not going to get that anyway - and this scheme is certainly no worse. (Arguably you're not going to get that on native apps either these days, thanks to closed-source app stores and automatic updates, and automatic updates are a very good thing.)
There is no guarantee, but security researchers often check the contents of apps like WhatsApp, Threema, etc. However, that doesn't help you if you specifically get a special version of the app that sends your content to the app writers. For websites, how hard this is depends on your infrastructure, but it is more or less trivial. For app stores like Google Play or apple app store, there is no such feature to push a special version to a subset of the population specified by name. You can only push it to entire classes of devices.
So suddenly Google, Apple, etc. have to be in on the attack which drastically reduces the number of people who can pull off supply chain attacks. Maybe you should be still worried about the US government, but while Saudi princes can bribe the Threema creator, they can't compel Apple to push a malicious update the Threema creator signed to select people only. So they'll have to hack the device via other means.
With the Android ecosystem specifically, because the OS base-image is customized by the device OEM, an interested state actor can inject a rootkit into devices in their own local market merely by suborning their domestic OEMs, and then manipulating trade tariffs to ensure that domestic citizens are incentivized to buy domestic OEM phone brands.
(Thankfully, this doesn't apply to devices sold into foreign markets, as nobody can predict what brand of phone an arbitrary foreign-citizen person-of-interest is going to choose to buy. Even if they contain the rootkit, there's low likelihood of there being a foreign surveillance system set up specifically with the hopes of seeing what foreign buyers of domestic-OEM devices are up to.)
They're not wrong, but also not the point of the article.
>As the maintainer of Excalidraw, I now sleep much better at night. If the hosting service gets compromised, it doesn’t really matter as none of the content can be decrypted without the key.
This seems to be the point of the article, and valid IMO. Yet on HN more and more we get dragged off on these larger state of the web topics. They're not wrong either, but I feel like the volume sort of drown out the point / valid topics too.
Currently we have some form of root of trust for HTTPS/TLS, code signing, trusted execution, that the OS or browser or chipsets distribute a set of "trusted" root certificates. For the consumers, they are implicitly backed by the big companies that manage the screening, auditing, and distribution of these certificates. But of course, these certificates have limited use cases that not yet covering the end-to-end encryption application for Web.
One way or another, we have to start our root of trust at some layer, either it's hardware, OS, drivers, or applications. But in general, the lower the layer gets, the lower the risk would be. Because it's easier for an evil actor to target specific user in higher layers.
There are more to be solved than just the root of trust for E2E on Web. For example, even if we can use trusted execution environment on a Web application to ensure secure key generation and key escore, we still have to face the problem of how to input or present the cleartext data with the user. If we still let the JS code to handle the cleartext in any way, there could still be a chance that the distributor of the JS code might steal them.
With that said, not only should we have a root of trust, but we also have to trust the UI provider that operates on the sensitive data for user input or display. The lowest UI layer is usually the OS, so even we have hardware root of trust, but if the trusted UI is in the OS layer, we would still be throttled at the level of trust on the OS layer.
Compared to just using HTTPS?
While there are ways the encryption can be removed or subverted that's a far cry from adding no benefit. Compared to just using HTTPS for client to server encryption, this protects the user from a bunch of server-based attacks. Certainly not all, but it does meaningfully raise the bar.
Keep in mind that security needs to be usable, and needs to exist in tools users actually use. If I'm a user if a web app, then browser based e2e encryption helps me. Downloading the diagram, installing PGP tools, figuring out how to use it, sending the file via a different mechanism... probably not something an average user wants to try.
But yes, if you run JavaScript, you're always trusting that site to not do a "quiet update" of the code to something malicious. I don't see any obvious way to counter that, short of downloading the JavaScript code & running it yourself.
With enough inspecting, debugging, and network watching you would be able to see what they're doing and how.
While I agree you can obfuscate this in the JS payload, it doesn't make e2e encryption in web apps "meaningless". It would just take one user doing some due diligence to expose the malice.
Nothing stops the owner of the service to run arbitrary JavaScript in Users' browser.
- Include in a header comment: the build URL, Git SHA-1 of the commit, and other metadata
- Sign the bundle using public/secret key cryptography
Having the build URL and sources URL help with discoverability and transparency, while integrity can be verified with the signature.
Adversary models now shift from the bundle provider to the CI/CD platform that runs the build, and any PKI used for the public key for signature verification. If the public key is versioned with the code, it can help reduce trust to a single entity (where the code is stored).
[1] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Alternatively, it would be possible to create a service worker that uses a local copy and makes much more of a deal about files changing - it could always confirm changes with the user before allowing a change. Security sensitive apps should probably be doing this.
Even native app packagers and languages can suffer from this when loading libraries dynamically (from search-path or symlink manipulation for example).
const encrypted = await window.crypto.subtle.encrypt(
{ name: "AES-GCM", iv: new Uint8Array(12) /* don't reuse key! */ },
key,
new TextEncoder().encode(JSON.stringify(content))
);
Honestly, I feel like whoever designed AES intended for people to make this mistake, because half of the sample code I see has this error, and it would have been easily avoided by specifying the IV length in the standard and requiring libraries to automatically generate it and prepend it to the ciphertext rather than letting callers have control over how it is initialized and stored.
window.crypto.getRandomValues(new Uint8Array(12));
If the author followed the MDN guides for it, they would have noticed that the example code also uses a random array. https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
PS The author didn't just copy something from a tutorial without knowing what he was doing, he actually asked for advice https://github.com/excalidraw/excalidraw/issues/610
Though I have two thoughts on that:
1. It wouldn't add very much complexity to implement random IV's. You can send it with the ciphertext, or in the generated URL. In my own project, I use btoa(JSON.stringify({ key: generatedKey, iv: randomIv })) and reverse the operation when the URL is accessed:
const fragmentData = window.location.hash.substr(1);
const keyParameters = JSON.parse(atob(fragmentData));
const key = HexMix.hexToUint8(keyParameters.key);
const iv = HexMix.hexToUint8(keyParameters.iv);
Edit #2: Ah-ha, and now I've learned something else from the Excalidraw team; I can skip my hex/uint & base64 conversions if I export the key as jwk.
2. There are a _lot_ of tutorials out there that incorrectly reuse the key with a fixed IV. I was more concerned about this being yet another tutorial that someone blindly follows and ends up reusing the key regardless.
BTW, regarding the AES comment: the authors of AES designed the block cipher, they didn't design the mode (GCM, which is CTR and GMAC). Nonce is a standard requirement for a stream cipher/stream mode of a block cipher/AEAD. In WebCrypto it's actually hard to skip setting the iv. And again, the author didn't make a mistake here.
You're right. From MDN:
> The Uint8Array typed array represents an array of 8-bit unsigned integers. The contents are initialized to 0.
..And the function signature for crypto.subtle.encrypt() describes the iv parameter for the algorithm:
> iv - A BufferSource — the initialization vector. This must be unique for every encryption operation carried out with a given key.
> Put another way: never reuse an IV with the same key.
https://developer.mozilla.org/en-US/docs/Web/API/AesGcmParam...
The code comment implies that the author knew the iv parameter should be unique - and yet passed an array of zeros every time.
Exactly, the key is always different.
> In this case, we only encrypt the content once with the random key so we don’t need an iv and can leave it filled with 0.
"We encrypt the content with that random key. In this case, we only encrypt the content once with the random key so we don’t need an iv and can leave it filled with 0 (I hope…)."
Anyone think that is a good idea?
In fact, using a random IV with AES-GCM is not exactly safe: 12-byte nonce is too small to avoid collisions with many encryptions. The recommendation is to not encrypt more than 2^32 messages with the same key if you use the random nonce.
Saving the diagram automatically and restoring when the site is revisited is a nice touch.
> I now sleep much better at night. If the hosting service gets compromised, it doesn’t really matter as none of the content can be decrypted without the key.
Which can be easily exfiltrated by the compromiser as they are now in a position to deliver and run arbitrary javascript in your users browser where the keys reside
Also, why can't I draw an actual non-flawed circle ?
I believe the biggest win is that existing content will not be accessible to a hacker even if they fully compromise the website, unless users re-open them. So, sure, plenty of content may get compromised if the site gets hacked, but some large percentage of old content will not be.
> Also, why can't I draw an actual non-flawed circle ?
Adding sloppiness when white boarding is a common pattern to indicate roughness. It subtly cues the viewer not to treat it as a completed product, and allows them more freedom to make changes. If you wanted clean lines, there are many web drawing tools for that too.
The attacker won't need to wait for the users to open a specific drawing - just browse to the website, from there they can grab the keys for all drawings they have assuming that not that many of them exist in the first place and the attacker has the list of key ids from the compromised backend.
It does call for a much more noisy and visible attack which is by itself a valuable mitigation.
So if I create an image today and encrypt it, only I see the key. If you hack the website tomorrow, you have access to my encrypted content, but not the key.
Now that you control the website, you can modify the code so that the key gets sent up every time a user encrypts or decrypts something. But you don't have any access to anything created before you hacked it, if no user decrypts it.
- The hosting service doesn't wipe physical disks they discard.
- The hosting service doesn't wipe virtual disks between customers.
- Your offsite backup provider gets compromised.
- Someone conducts a non- targeted attack, dumps whatever SQL database they see, and leaves before they get noticed.
- Someone conducts a targeted attack but gets noticed before they can develop a working patch to compromise the service.
- Someone (e.g., a government) pressures your hosting provider for data but doesn't want you to know. Modifying your JS files would risk being noticed.
On my laptop (a MacBook Pro) holding down the Shift key accomplishes that. As for the hand-drawn edges, that's just part of the aesthetic :-)
End-to-end encryption in the browser is not perfect security, as other comments are saying, but it’s significantly better than having user data in clear on a MySQL database somewhere.
PS. I’m the founder of Userbase.com — an open source service to help you build end-to-end encrypted web apps like this.
For example, with older of versions of Microsoft Office you cannot use a pound character in a hyperlink:
https://support.microsoft.com/en-us/help/202261/you-cannot-u...
Some email applications may unexpectedly strip the tag, attempting to be smart about handling it in the RFC 3986 sense (not anticipating this use-case at all). When the data appended to the # is a dependency to view the link, it can more easily render the link unusable.
> Excalidraw is a whiteboard tool that lets you easily sketch diagrams that have a hand-drawn feel to them.
It appears to be free open-source software on an MIT license.
I did the same thing but for text with https://anolog.org.
Sadly, since I used anonymous gists hosted on Github as my Data store, which they shut down last year, the service doesn't work anymore. :(
Javascript Cryptography Considered Harmful: https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
There are some out of date bits, but the core of the post is still as true as it was back in 2011.
Making an end-to-end encrypted web app with WebAssembly, WebCrypto, Service Workers and free TLS by Let's Encrypt is totally viable nowadays. Also, the Web userbase is largely using evergreen browsers like Firefox and Chrome.
Even a strict CSP doesn't totally close the hole.
It's sort of crazy how difficult (that's a euphemism—I would term it "impossible") it is to even attempt to secure browser-based crypto, over and above the normal challenges involved in crypto implementation. I wouldn't use clientside js crypto for anything more secret than a grocery list.
I thought urls weren't encrypted in HTTPS? Am I missing something?
So even if the URL isn't encrypted in HTTPS (it is though), it wouldn't matter.
The problem with URLs is that a lot of products will log the URL to disk, and many operators forget or aren't aware they might need to have security plans around data in the logs.
This is the reason not to put authentication tokens into URLs for example.
When the state users want to bookmark or share literally is the state that's encrypted anyway this mismatch isn't a threat. If I send you the URL for this drawing of a cat and then I'm astonished you can now see the drawing of the cat I've got real problems technology can't fix.
Having the key in the url seems insanely insecure to me.
The threat model the author tried to work around is not the user dumbly compromising their own work. The author wants to prevent proprietary and PII data from being stored on their own server. End-to-end encryption significantly reduces the author's potential liability hosting something like this in case something goes wrong.
I'll hit the URL bar and hit control-C. That's way better than any javashit which wants to touch my clipboard.
Copying the current URL also copies the key in that case. Now I'm accidentally sharing my encryption information with another user.
https://en.wikipedia.org/wiki/Server_Name_Indication#Securit...
Spend some time with wireshark running while you visit “google.com” in a web browser and you’ll get a better intuition on the topic.
https://github.com/Spark-Innovations/SC4
(Disclosure: SC4 is my project.)
It would probably be legal if the program also sent the crypto keys somewhere for later use.
It doesn't matter what your encryption scheme is. The TSA lock means the TSA can control the content. But the user assumes their communication isn't controlled by the TSA, because they are receiving instructions that appear normal.