New issue
Advanced search Search tips

Issue 683864 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Jan 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

WebCrypto restricted to https only.

Reported by h...@andrew.im, Jan 23 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.67 Safari/537.36

Steps to reproduce the problem:
1. Implement WebCrypto 
2. Use on a non-ssl page 

What is the expected behavior?

What went wrong?
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 server generated 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 WebCrypto, only to find out its being restricted to secured pages (at least in chrome). This defeats the purpose of what we're attempting to do.

This is a very valid use case, as web technology continues to grow and more software is created using it, we should be able to protect our users information and take advantage of native cryptography outside of a https environment. 

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 56.0.2924.67  Channel: beta
OS Version: 10.0
Flash Version: Shockwave Flash 24.0 r0

Comment 1 by phistuck@gmail.com, Jan 23 2017 

This is a very intentional decision, so I would not count on it changing.

Regarding your use case, what about mapping sub domains you control to user IP addresses (user12312121.yourdesignateddomain.net)? This way you can use a single certificate for all of the subdomains and everything is still HTTPS.
(I do not know whether what I just wrote is feasible or valid, this is just an idea)

Perhaps you should post this to security-dev - https://groups.google.com/a/chromium.org/d/forum/security-dev - they may have better suggestions.

Comment 2 by ranjitkan@chromium.org, Jan 23 2017

Labels: Needs-Triage-M56

Comment 3 by h...@andrew.im, Jan 23 2017 

There are a couple of challenges with mapping a users IP to sub-domains.

Our websocket server that we ship doesn't support SSL, so we'd end up routing the traffic through our server and terminating SSL at the proxy. This will cause a lot of latency and removes the need for us to have Web Crypto. If it did support SSL, I could be wrong, but wouldn't we have to ship the certificate/key with the users server? Basically the goal here is to establish a direct websocket connection between a user and their own self-hosted server. The page the static HTML is hosted on could indeed be HTTPS, but insecure websockets are not allowed on secured pages.  

I would hope this is a decision that could be reviewed again, since Chrome is the only browser enforcing this rule. All it does is make development a headache and force myself and others to use Javascript based methods like asmCrypto, which is even more insecure.

Comment 4 by phistuck@gmail.com, Jan 23 2017 

#3 - post this to security-dev, the issue tracker is here for technical discussions.

Comment 5 by rsleevi@chromium.org, Jan 23 2017

Status: WontFix (was: Unconfirmed)
Marking WontFix. This is an intentional decision, and supported by the spec - https://github.com/w3c/webcrypto/issues/28 captures the W3C discussion (the Github discussion and the previous discussion on W3C's bugzilla)

Other UAs are not spec compliant - either with CR or with the editor's draft.
►

Sign in to add a comment