Allow WebCrypto on HTTP
h...@andrew.im
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.
As suggest on the issue, 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.
Ryan Sleevi
Ryan Sleevi
h...@andrew.im
By locking people out from an API that is meant to protect information, you're forcing people to use insecure methods to achieve their goals.
As my colleague put it, you're not preventing people from using crypto in the web, you're just preventing them from using the fastest method for it. It seems a bit silly to take an "all or nothing" stance.
Anyway, thanks for the time. The simplest solution here is to inconvenience our users by making them install an extension for Chrome and just falling back to asmcrypto for those who won't.
Andrew Sampson
Ryan Sleevi
As a workaround, you could create a secure iFrame which does the encrypting and decrypting and pass messages from it to the rest of the system and to it from the rest of the system (since HTTP can load HTTPS and not vice versa).(I am not advocating that, but it could be a solution. It is not really secure, just like the rest of your HTTP solution)☆PhistucK
--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.
Ryan Sleevi
What about an HTTP page that window.open an HTTPS page and passes message to it? Would that still work (I do not know if it does currently)?☆PhistucK
Ryan Sleevi
Out of curiosity, localhost is considered a secured context, so why are other internal ip's such as 192.168.1.1 not?For instance if I serve my client over HTTPS to a user and they attempt to connect a local instance on their network, it will fail, which leads them to using an insecure page to accomplish their goal.
kane...@gmail.com
> I run a project that allows people to remotely manage their machines in any web browser.
That is, OPTIONS http://192.168.1.24/keypair_communicate replies with:
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: POST
#(cookies probably not needed) Access-Control-Allow-Credentials: true
#(if headers needed) Access-Control-Allow-Headers: x-keypairID
Access-Control-Max-Age: ${DEVICE_AUTO_UPDATE_INTERVAL}
Then, on the device webserver check that the Origin: is https://app.example.com or example-app-dev.localdomain ; if it's not, give a 403 and don't process the request.
The UI problem of registering and switching between devices is left as an exercise for the reader...
Ryan Sleevi
I believe the best solution for you is to have a HTTPS jsapp page that performs the calculations and communicates with the device using CORS.
That is, OPTIONS http://192.168.1.24/keypair_communicate replies with: