Consider explicitly allowing `digest` for non-secure origins

[Wren6991]

Follow-up to #28. Currently webcrypto requires a secure origin. This excludes, for example, web SPAs served on a local network without SSL. (I don't want to dwell too much on why people serve local web apps without SSL, except to say installing a new CA on all machines in your network just to use a local web app is a common anti-pattern that causes unnecessary exposure due to certificates being mismanaged.)

Please consider other use cases for webcrypto, e.g. SHA-256 for blob stores implemented on top of IndexedDB. Is the use of a secure origin relevant here? This was mentioned in the Bugzilla discussion in 2014:

I believe that UAs that wish to restrict the availability of Web Crypto to secure origins - or to restrict the set of operations (for example, perhaps only allowing digest() operations, but no keyed operations)

This was never properly addressed in the Bugzilla thread. The only response was this one, which mostly talked about signature verification rather than pure digest:

You are not protected from an attacker, at all, who can modify the code and insist that any arbitrary file has a "valid" signature. Or replacing the signature in transit.

This doesn't make much sense. In the described scenario the check could also be patched out, and preventing access to webcrypto would have achieved nothing. The point about replacing signatures in transit goes against the basic mechanics of how signatures work. Also, allowing digest alone, without signature operations, was never addressed after the first message that mentioned it.

I was invited to open this issue by #28 (comment). I don't think there are any issues with the definition of secure origins or secure contexts. However the resolution in #28 focused too much on the technical aspects and ignored the obvious human behavioural consequences. The hardest problem in security is still getting people to use the secure primitives you built. If someone hand-rolls a crypto implementation for non-SSL local deployments (or development) then there is a chance it could get re-used in secure contexts, and now you have hand-rolled crypto in secure contexts.

I don't think it ever makes sense to push people away from vetted implementations of standard algorithms. That's a policy decision though. The specific case of digest is different because these algorithms have other applications. There were open questions about digest in the original spec discussions that were never resolved.

[twiss]

Hi 👋 Thanks for opening an issue. A few notes:

This excludes, for example, web SPAs served on a local network without SSL. (I don't want to dwell too much on why people serve local web apps without SSL, except to say installing a new CA on all machines in your network just to use a local web app is a common anti-pattern that causes unnecessary exposure due to certificates being mismanaged.)

An alternative solution to this issue would be to allow devices managers to configure the browser to consider the local network as being secure.

IMHO, that would likely be a preferable solution, because then you also don't train users to click through "insecure website" warnings.

(FWIW, that's what I meant with this part of the issue being about the definition of secure origins.)

You are not protected from an attacker, at all, who can modify the code and insist that any arbitrary file has a "valid" signature. Or replacing the signature in transit.

This doesn't make much sense. In the described scenario the check could also be patched out, and preventing access to webcrypto would have achieved nothing.

So - the original discussion was not about whether it makes sense to replace an existing cryptographic check with one that's implemented natively, but whether it makes sense to have the cryptographic check at all. If it's the case that an attacker can just remove the check without detection, rendering it useless, then the answer is no. The fact that you can do something useless in JS code is not a very good argument for also providing a useless native API, IMHO.

It's true, however, that hash functions also have non-cryptographic uses, and those may be useful to expose natively, including in insecure contexts. However, this raises the question whether the current set of available hash functions (i.e. the SHA family) is most suitable for that purpose. For example, it might be useful to have SipHash or other non-cryptographic hash functions?

Separately, @davidben has been arguing that we should have a simpler and synchronous API for fast operations (such as hashing), e.g. in #167 (comment).

Perhaps, rather than exposing crypto.subtle.digest() to non-secure contexts, it might make sense to create new (synchronous, and non-[SecureContext]) sipHash(), sha256(), etc. functions (outside Web Crypto), to indicate that it's OK to use those for non-cryptographic purposes in insecure contexts?