Hacker News Reader

Comment by minitech | Hacker News Reader

> Since this is browser crypto, and not native execution like Magic Wormhole, all of this is irrelevant; the important distinction between the two projects isn't that one uses a lesser cryptosystem, but rather that the other uses real end-to-end cryptography and the other uses client-server cryptography pretending to be end-to-end.

Is my reading of this as a vague and misleading way of saying that because the code responsible for the encryption is provided by the server it doesn’t count as end-to-end encryption accurate? Or is it an even vaguer hint towards something else?

View on HN

I don't know what's "vague" or "misleading" about it. Almost every HTTP transaction you have with a server providing browser-based cryptography offers the server another opportunity to alter the code that handles cryptography secrets. It's not a matter of "software update", though that's where this discussion always seems to be pushed; it's every individual operation of the application.

People --- including the author of this application, if I'm reading it right --- talk about the need to "audit" these kinds of applications. But there's no such thing as "auditing" a browser Javascript application. The code it feeds you on startup is not necessarily the code that you are running at any given point during its execution. The entire web security model is based on the idea that the origin is the root of security; that's why we gave it a special name.

Compare with Magic Wormhole (a project I'm in no way affiliated with), which has the same basic functionality, and in which the server has no ability to subvert the cryptography used to transmit files; not on a run-by-run basis, or on a file-by-file basis, or even a protocol-message-by-protocol-message basis.

This is an old argument, one widely (though not absolutely) shared among software security engineers, so it's a little rich to see people express shock at reading it here. You can disagree with me; many have, over the years. But you can't claim it's an argument from left field.

You can't invent your own definition of end-to-end encryption. There is a material difference between a service which end-to-end encrypts your files – even if it sends you the code to do so – and one which does not.

When a user logs into 1Password.com, they're using end-to-end encryption. The master password and secret key never leave the browser. The server never receives the key and therefore does not have a way to access the contents of password vaults.

This is very different from an application which, by design, sends your plaintext data to remote servers.

The English phrase we use to describe this difference is "end-to-end encryption".

I have not in fact invented my own definition of end-to-end encryption, and yours is not the first application --- nor is browser crypto the only cryptography setting --- that has tried to claim "end-to-end security" for a design where both ends implicitly trust the server.

It’s vague because “client-server cryptography pretending to be end-to-end” could be referring to any of a number of different flaws when you could just be specific in the first place in as many words, and it’s misleading because actual client-server encryption in this case leaks private data to the server passively, which is a significant difference. Feel free to popularize a separate term for this if you don’t like “end-to-end”.

With E2E encryption you need to trust the developer of the software and the distribution channel (apt, App Store, web server). The GP comment is parroting the claim that browser based E2E encrypted systems are inherently less secure than native apps because web servers are untrustworthy systems for delivering software.

Does native software have fundamentally more trustworthy distribution channels than web servers? I see the argument in some cases - apt always delivers the same binary for the same request (I assume). And the App Store does binary signing, rather than just TLS. But plenty of native software is just installed via the developer’s website anyway. And if the developers host the website, they’re already a party you have to trust. Giving them more trust doesn’t change much - they could just slip something nasty in the binary if they wanted your data.

I still don’t totally buy it.

A key aspect is that for native apps its harder (not necessarily impossible) to just at a selected point in time deliver malicious code to a selected user, with nothing persisting it. Compared to a native app that's installed in a way that it can't modify itself (and thus needs to deliver a vulnerable or malicious version during installation) that's very weak - arguably an app that can invisibly update itself is somewhere inbetween.

With a web app you always load the code from the server - while at the same time using E2E to protect yourself against said server...

I agree with this analysis. We'd love to offer more assurances that the code hasn't changed out from under you when using Wormhole.app. We really need a better way to "pin" a site to a current version and only update it with user consent.

Right now, we're limited by the capabilities of the web platform and will probably need to ship a native app to accomplish this.

What about using sub resource integrity to allow users to request a specific JS version using its integrity attribute in the URL, that way shares also use the same pinned version, and can check/verify the integrity themselves or via some centrally informative place as well.

The problem here is that there's no good way in the browser Javascript runtime to verify the current execution environment. All you can check are the script assets you load, not whether your current running code has been eval'd into something malicious.

This is a very old debate that we're recapitulating here; if you sense that I'm being less than forthcoming about it, it's because there's something like 11 years of history of it in the search box below the page.

I don't much care about the argument here. I'm have two things to say in this thread:

1. "Wormhole" is a bad name for a new secure file transfer system, since one of the better-known cryptographic file transfer systems is already named "Magic Wormhole" and has the command "Wormhole". It's confusing, and especially annoying since there's no dispute that Magic Wormhole is more secure than this application --- even if you think, incorrectly, that browser Javascript crypto is "end-to-end", there's no coherent way to suggest that it's as secure as the native Magic Wormhole program.

2. AES-GCM is not in fact a perfectly cromulent AEAD; it is an imperfectly cromulent AEAD, and one most designers would probably do well to avoid (use XSalsa-Poly1305, with random nonces).

I really don't understand this "if I disagree with an argument, it's fulmination" point you keep trying to make. Further: I haven't called you names at any point in this discussion --- that's a line you're starting to cross. I think perhaps we should just disengage. I'm not asking you to respond to me. If you feel we're not getting anywhere, we don't have to keep talking.

I don't think you're doing a very good job of advocating for this person; if you were arguing this way with someone else on my behalf, I'd ask you to stop.

Fair, adios. Would appreciate if you actually respond to subresource integrity question. Why isn’t that valid? One could couple this with a CSP that restricts eval and Function or what ever is necessary. This all seems to be just about browsers in general.

It is in fact about browsers in general. They're a very hostile environment for cryptography.

I think the argument against web-based software is that because you effectively re-download the application on every visit, there are more opportunities for a compromised provider to serve you a malicious version of the application.

I suppose it's the difference between TOFU (Trust On First Use) and BEEF (Beware Each & Every Fetch).

Okay, I made up that second acronym, but it seems like a reasonable name for that threat model. Anyway, as the sibling comment points out, the distinction is fairly moot if you have an auto-updating native application.

To improve the situation for native applications, it would make sense to use a tamper-evident log like Trillian[0] so that a package manager or auto-updater can be sure that it is receiving the same binary as every other user (and possibly after a sufficient delay to allow reviewers to raise the alarm about the corresponding reproducibly-buildable source code).

Applying this to web applications is more tricky, but can be done using the bookmarklet-dataURI trick[1] which effectively allows the user to freeze a copy of a web app "bootloader" that pulls in the remaining resources after checking their signatures against a hardcoded public key (as well as against a Trillian log).

[0] https://transparency.dev/application/add-tamper-checking-to-...

[1] https://news.ycombinator.com/item?id=17776456

Thanks for the pointer to bookmarklet data uri trick - that's clever.

I posted this elsewhere in the thread, but just wanted to mention it again in this context. Hyperboot [1] uses AppCache to give users the benefits of explicit, immutable versioning with control over upgrades using the html-version-spec while preserving the simplicity of passing around a URL.

It offered the usability benefits of web apps – you can give someone a URL and they can immediately load the app – with the security of installed apps – doesn't change without warning.

Unfortunately, AppCache is being removed from the web platform and there's no way to use ServiceWorker to accomplish the same thing.

[1]: https://github.com/substack/hyperboot

Yes, it's a pity that AppCache and ServiceWorkers won't be able to support this use case. Also, the data URI trick comes with its own limitations, such as the fact that the address bar won't present an actual domain name or padlock, so it has a slightly worse user experience than normal websites.

One simple way that the web platform could be improved, then, would be to adopt something like the Hashlink proposal[0], which would allow the hash of the initial "bootloader" to be stored in the query string. If this were possible then a simple bookmark would suffice, or a URL sent in an email, as your comment suggests.

[0] https://w3c-ccg.github.io/hashlink/

> I think the argument against web-based software is that because you effectively re-download the application on every visit, there are more opportunities for a compromised provider to serve you a malicious version of the application.

Maybe. Lets imagine Google Chrome's update servers were compromised for a day, and the servers hosting a somehow equally popular e2e web based chat app were compromised for a day.

For chrome, it will effect fewer users (most people only update chrome every month, so it only hits 1/30 users). Whereas every user who opened the chat app would be compromised.

The problem on google chrome would be easier to detect, because it wouldn't be able to pinpoint a specific user. Everyone gets the same bad code.

An infected version of chrome would do a lot more damage than a website (because native desktop apps aren't sandboxed at all).

And when the website clears the infection the next day, all infected users of the chat app would have the malicious code removed from their system[1]. But unfortunately, an infected copy of chrome would presumably have its update mechanism stripped out, so it would stay evil much longer. Though maybe this is a wash, because Microsoft and Apple have malicious software detection and removal built into their OSes.

I don't see this as a slam dunk for native software.

> To improve the situation for native applications, it would make sense to use a tamper-evident log like Trillian

This is a fantastic idea. I'd love to see this explored more, and I wonder if we could do something similar some day built into browsers for web apps.

Interestingly it also makes a strong case for apps (like chrome) not having their own binary responsible for updates. Apps on phones are more secure because a malicious binary can't stop itself being removed via Apple / Google's app stores.

And of course, we need better system level application sandboxing in order to reduce the impact of this sort of attack. Its crazy that a malicious binary on my computer can download and modify all data on my computer (owned by any app), and access network shares using my credentials.

[1] I think - there might be ways to prevent this with evil service workers. Does anyone know?

> (most people only update chrome every month, so it only hits 1/30 users).

What do you base that on? My understanding is that a system with Chrome installed will check for updates every 5 hours[0], and I assume most people accept the update on the day that they see it is available.

> The problem on google chrome would be easier to detect, because it wouldn't be able to pinpoint a specific user.

I'm also not clear what you mean here. An attacker could decide to target a victim by their IP address, or any detail about their computer which is available to Chrome.

I agree with you though about native applications being able to do more damage, and possibly persisting on a machine for longer.

> Apps on phones are more secure because a malicious binary can't stop itself being removed via Apple / Google's app stores.

On the other hand, the user isn't secure against threats from the app stores themselves, not least the threat to Availability when an app store uses a kill switch to delete an app without warning.[1]

[0] https://support.google.com/chrome/a/answer/6350036?hl=en

[1] https://www.macworld.com/article/191897/iphone_killswitch.ht...

> My understanding is that a system with Chrome installed will check for updates every 5 hours

Ah yes. I was thinking that chrome releases a new version every month, and imagining hackers infecting a new version of the browser. But you’re right - if hackers hit the update system and managed to deliver malicious code for more than 5 hours, they would get almost everyone to download their payload. Yikes.

As for targeting users, most update mechanisms use CDNs, and the attacks against update systems I’ve heard about just put nasty files in the CDN. To go after a single user you would also need to reconfigure the CDN to deliver different files to different IP addresses - which, well, it would depend on the attack vector.

> Is my reading of this as a vague and misleading way of saying that because the code responsible for the encryption is provided by the server it doesn’t count as end-to-end encryption accurate?

This is how I read tptacek's comment as well. It's vague and misleading to say that any code provided to a client by a server cannot be end-to-end encryption.

By that logic, even something like the Signal Desktop client (which has an auto-updater) is not end-to-end encryption. This is a not a reasonable or honest definition of end-to-end encryption.

The point of end-to-end cryptography is not having to trust servers. Your argument is that a system that appears to need to trust its server on an HTTP-request-by-HTTP-request basis must be end-to-end, because browsers on either side also do some cryptography. But that's not how it works.

You can't invent your own definition of end-to-end encryption.

There is a material difference between a service which end-to-end encrypts your files – even if it sends you the code to do so – and one which does not.

Services like Dropbox or WeTransfer receive plaintext copies of your files. Firefox Send did not. And Wormhole, using the same design, does not either.

See https://news.ycombinator.com/item?id=26884466.

Reply on news.ycombinator.com