Do not mandate secure context for SubtleCrypto

[andrewmd5]

I run a project that allows people to remotely manage their machines in any web browser.

As you may know, browsers usually refuse to load non-secure content from secure pages. We aren't able to generate an SSL certificate for each user, so our publicly hosted client is not https. But we still need to protect user data.

Whenever a connection is made to a self-hosted server (over websocket), a unique RSA key pair is generated on the server for that connection. The client then generate AES credentials, encrypts them using the public key and sends them to the server. After that all traffic to and from the client is encrypted using AES.

So in our attempts to speed up our decryption, we implemented web crypto, only to find out its being restricted to secured pages (at least in chrome). This pretty much defeats the purpose of what we're attempting to do.

This is a very valid use case and the standard should not dictate what context it can be used in.

[wseltzer]

See the WG's consensus call on this issue: https://lists.w3.org/Archives/Public/public-webcrypto/2016Aug/0047.html

[arashbm]

If the code is not loaded in a secure context, how are you going to protect the users from malicious code being loaded on your page request to compromise the whole deal e.g. by changing your generated AES secret key with a known one and man in the middling the socket?

[plehegar]

Based on previous group discussion and other comments, mandating secure context for SublteCrypto remains.

[bradisbell]

It's disappointing that SubtleCrypto is only available in secure contexts. It has uses that do not require this... hashing, for example.

Please leave it up to users to decide what sort of security they require.

[twiss]

It has uses that do not require this... hashing, for example.

Even hashing typically requires a secure context to give a meaningful security benefit. For example, let's say a web app downloads a file from an untrusted source, and decides to check the hash to verify its integrity. If the web app is not in a secure context, an attacker can trivially change the source code to remove this check or change the expected hash.

[bradisbell]

Even hashing typically requires a secure context to give a meaningful security benefit. For example, let's say a web app downloads a file from an untrusted source...

Your comment illustrates my point. Authors of this specification cannot know all the use cases, which do include atypical use cases. Therefore, it makes sense to defer to the software developers who represent the users who want to use their computers for useful tasks. Let's not artificially restrict what is possible.

In my case, I'm hashing to calculate cache keys for an optimization. Without direct browser support, I'll just fall back to doing this using some unoptimized script. The result of restricting SubtleCrypto in this case only serves to damage the user experience.

I don't mean to trivialize the importance of security and secure browsing contexts. All I'm saying is that the decision of whether cyrpto libraries should be used in a particular context should be made by developers and users, not by the specification authors.

[twiss]

In my case, I'm hashing to calculate cache keys for an optimization.

At the risk of coming across as facetious, the Web Cryptography API aims to provide cryptographic hash functions. Your use case doesn't necessarily require a cryptographic hash function. In fact, it's plausible that a non-cryptographic hash function (or something like SipHash) implemented in JavaScript or WebAssembly may prove faster than a cryptographic hash function implemented natively. In any case, I empathize with your use case but it's not one that Web Crypto was intended to serve.

[blaine]

Just to add a scenario where secure contexts aren't possible or desirable, but fast (i.e., not in JS) hashes are:

I've built a small server that runs on a microcontroller. The client interacts by connecting over a captive portal, and can upload a file. To enable sync, the client computes the hash of all the files it has, and negotiates with the server to come up with all the files that either party is missing. It's a simple use-case, but the lack of SSL means that we're going to have to register a domain and serve an (expiring) SSL certificate from a device that doesn't have an internet connection (and thus will stop working after a year unless regular updates are pushed, which is a lot more complexity and honestly a security risk because now the private key will be on a publicly-accessible microcontroller) for a use-case that doesn't depend on SSL at all for its security.

It would be nice if "local-first" use cases were supported by the web platform. Doing this in WASM is now, finally, possible, but adds to the complexity (for no security benefit), and arguably is a simpler approach that obsoletes most of WebCrypto's hashing algorithms. There are plenty of "behind-the-firewall" (e.g. IoT devices without domain-attached certs) and offline scenarios where SSL is simply not fit for purpose.

(update: in the meantime we'll be using https://github.com/Daninet/hash-wasm or similar. If the w3c and browser vendors are going to continue to be overly prescriptive as to what should or shouldn't be possible, and meanwhile developers can just bypass the w3c's pronouncements, I would suggest deprecating the subtlecrypto hashing apis.)

[szmarczak]

Not supporting plaintext contexts has a negative impact. Users are forced to use third party libraries for those features, which increases possible points of failure since those libraries are not as solid as browser implementations.