New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please require a secure origin (Bug 25972) #28

Closed
mwatson2 opened this Issue May 23, 2016 · 25 comments

Comments

Projects
None yet
@mwatson2
Collaborator

mwatson2 commented May 23, 2016

Bug 25972 from bugzilla:

As with service workers implementations want to require a secure origin in order to get access to cryptographic functionality. We should make that a requirement in the specification so that implementations do not have to reverse engineer each other.

In particular you want to refer to the origin of http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#entry-settings-object

Secure origin is defined by https://w3c.github.io/webappsec/specs/mixedcontent/

Ryan probably knows which flavor of secure origin is to be used here.

@hhalpin

This comment has been minimized.

Contributor

hhalpin commented Jun 20, 2016

Add text saying "Developers should use Secure Origins, although this is not strictly required."

@mwatson2 mwatson2 self-assigned this Jul 11, 2016

@mwatson2

This comment has been minimized.

Collaborator

mwatson2 commented Jul 11, 2016

Discussion on 7/11 call suggest requiring a secure origin, in the stronger sense of requiring the top-level browsing context to be secure.

@mwatson2

This comment has been minimized.

Collaborator

mwatson2 commented Jul 12, 2016

I assume that the secure origin test should be performed as the first step in each WebCrypto method. This would mean that errors due to WebIDL type conversion would still occur on insecure origins, but then you would get the secure origin test failure.

IIUC, Chrome's current implementation does algorithm normalization and possibly other parameter validation before checking for the secure origin.

mwatson2 added a commit to mwatson2/webcrypto that referenced this issue Jul 12, 2016

@mwatson2

This comment has been minimized.

Collaborator

mwatson2 commented Jul 12, 2016

PR #122

@bdhess

This comment has been minimized.

Contributor

bdhess commented Jul 14, 2016

-1 for requiring a secure origin (though I'm okay with it being recommended).

The "Secure Messaging" use case, for example, doesn't require TLS in order to preserve the privacy of the exchange, so long as only ciphertext is transmitted. Simply put, we don't want the extra roundtrips associated with establishing a TLS session when they are superfluous to the actual security solution, since this leads to a worse end-user experience with no tangible benefit.

@domenic

This comment has been minimized.

domenic commented Jul 14, 2016

Whatever you do, please do not use the incumbent or entry settings objects here. Current settings object is more correct. See https://readable-email.org/list/public-script-coord/topic/multiple-globals-and-you

@ddorwin

This comment has been minimized.

ddorwin commented Jul 14, 2016

Looking at https://w3c.github.io/webappsec-secure-contexts/#new, would it be simpler to add [SecureContext] to GlobalCrypto, Crypto, and/or SubtleCrypto?

@domenic

This comment has been minimized.

domenic commented Jul 14, 2016

That would probably work, although it would have different normative effects than adding a guard. (Adding a guard causes errors at call time, whereas [SecureContext] prevents the interfaces from existing at all.)

@mwatson2

This comment has been minimized.

Collaborator

mwatson2 commented Jul 14, 2016

@bdhess Without a secure origin, you can only make security arguments with respect to passive attackers. An active attacker - one who can modify the pages served to the client - has full access.

Privacy against passive observation is not without value and this is the argument I have used in the past against requiring a secure origin. However, we'd need some evidence that there were users with that use-case as a requirement (my company was one of those, but no longer).

@mwatson2

This comment has been minimized.

Collaborator

mwatson2 commented Jul 14, 2016

@ddorwin Yes, that would seem to me to be simpler and clearer. However the secure context specification recommends both. I am not sure why, since if the interface is only exposed in secure contexts the guard could never fail. @mikewest ?

@bdhess

This comment has been minimized.

Contributor

bdhess commented Jul 14, 2016

@mwatson2 In our operating environment, there's no sensitive data or PII that's emanating from the client. Ultimately, our use of Web Crypto is entirely to provide security around server-provided assets. So the protection of client-side key material is therefore a concern for us, but as I understand it, out of scope for Web Crypto.

@mikewest

This comment has been minimized.

Member

mikewest commented Jul 15, 2016

Yes, that would seem to me to be simpler and clearer. However the secure context specification recommends both.

Adding the [SecureContext] IDL attribute to the relevant interfaces should indeed be enough. The API won't be exposed in non-secure contexts, and since the state of a context can't change, the explicit guard in the algorithm is redundant (though probably worth noting next to the algorithm in any event). If you're ok with the implications (hiding the interface rather than throwing), then that sounds like a totally reasonable way to address the issue.

mikewest added a commit to w3c/webappsec-secure-contexts that referenced this issue Jul 15, 2016

Clarify recommendation for restricting new features.
w3c/webcrypto#28 noted that the current recommendations were confusing
as they suggested both throwing and hiding the interface. This patch
clarifies that either/or is completely acceptable.
@annevk

This comment has been minimized.

Member

annevk commented Jul 18, 2016

Is it web-compatible to hide the API from insecure contexts? That's the main tradeoff solution-wise.

@mikewest

This comment has been minimized.

Member

mikewest commented Jul 18, 2016

Safari and IE both ship prefixed variants of the crypto.subtle APIs. I imagine developers would have to be feature-detecting anyway if they don't want to error out on those browsers.

@ericroman920

This comment has been minimized.

ericroman920 commented Jul 20, 2016

Marking with [SecureContext] SGTM.

-1 for requiring a secure origin (though I'm okay with it being recommended).

Note that Chrome already doesn't allow Web Crypto over non-secure origins. So clients needing to support Chrome will have to address this in their implementation regardless.

IIUC, Chrome's current implementation does algorithm normalization and possibly other parameter validation before checking for the secure origin.

Chrome (currently) does the origin check after (most) WebIDL checks on the parameters, but before things like "algorithm normalization", and rejects with NotSupportedError in that case. Hence it is not very consistent as far as what parameters have been processed. Marking with [SecureContext] avoids that problem.

What should happen when structured (de) cloning a CryptoKey into an insecure context? Under the crypto.subtle is hidden model, I presume you could still postMessage a CryptoKey to an insecure context. Is that relevant?

@bdhess

This comment has been minimized.

Contributor

bdhess commented Jul 25, 2016

@ericroman920

Note that Chrome already doesn't allow Web Crypto over non-secure origins. So clients needing to support Chrome will have to address this in their implementation regardless.

So the contention is, since Chrome has already defined a behavior, there's no point in discussing changes that would make the spec inconsistent with Chrome's present behavior? This seems like a really backwards way of developing community standards. I'm not the first person to object to this behavior:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972#c6
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972#c20
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972#c22

From the record, it's pretty clear that Chrome came to this decision based on the assumption that there exists no scenario in which there is value in being able to use the Web Crypto API in an insecure context. Including myself, there are at least four commenters who've disputed that.

@annevk

This comment has been minimized.

Member

annevk commented Jul 26, 2016

I suspect that were you to ask the people that objected to this in the past again, they are probably more agreeable to this now. E.g., Mark commented in this very thread saying so.

Also, the concerns Ehsan raised there were mostly about the original solution easily being bypassed. Secure contexts addresses those concerns. He didn't really state any use cases for Web Crypto in insecure contexts and I don't really think you have clearly done so either.

mwatson2 added a commit to mwatson2/webcrypto that referenced this issue Aug 26, 2016

@mwatson2

This comment has been minimized.

Collaborator

mwatson2 commented Aug 26, 2016

New PR using [SecureContext]: #131

@ericroman920

This comment has been minimized.

ericroman920 commented Aug 26, 2016

A problem with PR #131 is that it marks window.crypto as [SecureContext].

This means that window.crypto.getRandomValues() is no longer accessible on insecure contexts.

I don't believe we want that change -- getRandomValues() has always been available on insecure contexts.

Instead I propose marking only SubtleCrypto (i.e. window.crypto.subtle) as [SecureContext].

@mwatson2

This comment has been minimized.

Collaborator

mwatson2 commented Aug 26, 2016

@vijaybh

This comment has been minimized.

vijaybh commented Aug 29, 2016

I'd lean towards requiring a secure origin here. I feel a little sad about losing hash capability in insecure origins (since that is not sensitive in any way, similar to getRandomValues) but overall given the current threat landscape I believe it is better to strongly protect key material even if we take this bit of collateral damage.

@mwatson2

This comment has been minimized.

Collaborator

mwatson2 commented Sep 13, 2016

The CfC for this issue was approved.

@jeremyVignelles

This comment has been minimized.

jeremyVignelles commented Jan 8, 2018

Hi,
I don't think that enforcing HTTPS everywhere is a good solution, especially with that API.

I am currently developing a distributed app that works on a local network, without internet access. Each node has a little "admin" interface. Due to the cost of having and maintaining a PKI, especially for small clients, I don't want this admin interface to be on HTTPS.
Having a self-signed certificate is not an option either, because of all the security warning that would cause the user to skip the warning without even looking at it, making the whole thing as vulnerable as plain HTTP.

For the solution I designed, I implemented a key exchange mechanism over HTTP and encrypt only sensitive data as needed. But on first try with chrome on another computer, I realized that my thing is entirely broken.

I want to use new APIs, but the work of having HTTPS on each node is a no-go for me, and in the end of the day, I can't make my site any safer by using this API... that's really too bad. It's like telling a homeless to give his address when he wants to buy a blanket to cover himself...

That being said, I suppose that I need to find a crypto library... Which is just the same as using webcrypto from insecure origin, but with more js weight, less maintained code and less performance.

@aleksey-bykov

This comment has been minimized.

aleksey-bykov commented Feb 4, 2018

this pisses me off greatly, i just want to calculate my sha1 using your super secure web crypto shit, and it cant because well, i don't care about being all cryptic, i just need my sha1 please, looks like you got lost in definitions, not everything named "secur..." needs to be turned off

@olizilla olizilla referenced this issue Mar 29, 2018

Open

WebCrypto #8

@m5x

This comment has been minimized.

m5x commented May 15, 2018

I do not want to be rude but whoever came with the idea that crypto should not be available in non-secure context was probably only thinking about his narrow set of usage scenarios. We have an intranet exam server for schools which they use separately in every class room for computer-based final exams. We cannot use HTTPS because schools cannot buy certificate for every intranet computer they want the exam server to run on and we do not want to use self-signed certificate because browsers would issue warnings which we want to avoid. So we use window.crypto.subtle to implement our own asymmetric cryptography to protect sensitive information on the wire. Now we will have to use some JS crypto library which will only increase bundle size and decrease performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment