4 ms·

The author suggests that using CORS to allow https://zoom.us https://zoom.us with http://localhost:19421 http://localhost:19421 is possible. This is factually

The author suggests that using CORS to allow https://zoom.us https://zoom.us with http://localhost:19421 http://localhost:19421 is possible. This is factually incorrect. Mixed content policies prevent the http: origin from communicating with the https: origin. "For very intentional reasons, the browser explicitly ignores any CORS policy for servers running on localhost." That last sentence is incorrect – Chrome does respect CORS headers for localhost webservers. It's only partially incorrect. In most cases, CORS will not work with localhost, at least without a self-signed certificate trusted by the browser.

chrisfosterelli 7y ago
This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is possible and not factually incorrect. If for some reason that doesn't work for your app, the post also mention two secure alternatives: the native client can install a self-signed cert, or you can use a browser extension with the native messaging API. [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=903966 https://bugzilla.mozilla.org/show_bug.cgi?id=903966 [1]: https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e https://chromium.googlesource.com/chromium/src.git/+/130ee68... [2]: https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165 https://github.com/w3c/webappsec-mixed-content/commit/349501...
- deleted 7y ago
  [deleted]
- zenexer 7y ago
  I'm fairly certain that these patches didn't land until recently, at which point the design decisions were probably already made at Zoom. (I don't know much about Zoom, but that seems like a reasonable assumption.) Additionally, these changes aren't likely to apply to Firefox ESR or IE for a while. In Zoom's case, I highly doubt CORS on its own was a viable solution. Maybe in 2026, a decade after the patch, sure, but in the current climate, it's not reasonable to expect that all users will be using browsers that have adopted these changes in 2019.
  - chrisfosterelli 7y ago
    These are from years ago, and as mentioned there are two other alternatives discussed. There's no excuse to not checking origin at all. They could have even used the image hack and then checked the origin.
- reda-alaoui 7y ago
  We tested this on Fifefox on April 2019. It is still blocked.
  - chrisfosterelli 7y ago
    > If for some reason that doesn't work for your app, the post also mention two secure alternatives: the native client can install a self-signed cert, or you can use a browser extension with the native messaging API. (Also you might want to verify you were using 127.0.0.1 and that you had the headers correct)
    - reda-alaoui 7y ago
      Yes I know. Installing a self signed certificate is easy on Edge and Chrome. But did you ever try to do it dor Firefox? Firefox has its own certificate store implementation and only native code to manipulate it. So it’s easier to provide a valid certificate instead even if it means that the private key is exposed. Concerning the extensions, this was not practical until the recent unification under web extensions. I never tried.
yeldarb 7y ago
Could they sign and distribute a cert for localhost.zoom.us and point the DNS at 127.0.0.1?
- jdfellow 7y ago
  No, because you'd have to distribute the private key for the local webserver to be able to sign the connection challenge.
  - azdle 7y ago
    But that's just a reason why it would be a bad idea, not a reason that they couldn't do it or that it wouldn't work. I would think that they could distribute the cert (and the key) and have it work. [Edit] Unless browsers detect that it's a local IP address behind the domain name and still consider it a special case of origin.
  - sascha_sl 7y ago
    it's not the nicest solution, but I don't see the problem with a public certificate and public private key (yeah not the most elegant wording) that is literally issued to `localhost` or `127.0.0.1` (not localhost.zoom.us because that still goes through DNS once and could be hijacked)
  - Spivak 7y ago
    Plex solved this problem is pretty much the way you describe. https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
- tgsovlerkhgsel 7y ago
  They could, but if they distribute the private key, which they would, the private key would be considered compromised, and the CA would be required to revoke the certificate within something like 24h of being notified with appropriate evidence (e.g. a copy of the key or a special message signed with the key). In the case of LetsEncrypt certificates, there is even an API for this revocation. However, given how ineffective revocation is, it unfortunately could still be a viable strategy. The easier approach is, of course, using the fact that browsers now consider http://127.0.0.1 http://127.0.0.1 (and/or http://localhost http://localhost) a secure origin to avoid this issue.

chrisfosterelli 7y ago

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is possible and not factually incorrect. If for some reason that doesn't work for your app, the post also mention two secure alternatives: the native client can install a self-signed cert, or you can use a browser extension with the native messaging API. [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=903966 https://bugzilla.mozilla.org/show_bug.cgi?id=903966 [1]: https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e https://chromium.googlesource.com/chromium/src.git/+/130ee68... [2]: https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165 https://github.com/w3c/webappsec-mixed-content/commit/349501...

deleted 7y ago
[deleted]
zenexer 7y ago
I'm fairly certain that these patches didn't land until recently, at which point the design decisions were probably already made at Zoom. (I don't know much about Zoom, but that seems like a reasonable assumption.) Additionally, these changes aren't likely to apply to Firefox ESR or IE for a while. In Zoom's case, I highly doubt CORS on its own was a viable solution. Maybe in 2026, a decade after the patch, sure, but in the current climate, it's not reasonable to expect that all users will be using browsers that have adopted these changes in 2019.
- chrisfosterelli 7y ago
  These are from years ago, and as mentioned there are two other alternatives discussed. There's no excuse to not checking origin at all. They could have even used the image hack and then checked the origin.
reda-alaoui 7y ago
We tested this on Fifefox on April 2019. It is still blocked.
- chrisfosterelli 7y ago
  > If for some reason that doesn't work for your app, the post also mention two secure alternatives: the native client can install a self-signed cert, or you can use a browser extension with the native messaging API. (Also you might want to verify you were using 127.0.0.1 and that you had the headers correct)
  - reda-alaoui 7y ago
    Yes I know. Installing a self signed certificate is easy on Edge and Chrome. But did you ever try to do it dor Firefox? Firefox has its own certificate store implementation and only native code to manipulate it. So it’s easier to provide a valid certificate instead even if it means that the private key is exposed. Concerning the extensions, this was not practical until the recent unification under web extensions. I never tried.

yeldarb 7y ago

Could they sign and distribute a cert for localhost.zoom.us and point the DNS at 127.0.0.1?

jdfellow 7y ago
No, because you'd have to distribute the private key for the local webserver to be able to sign the connection challenge.
- azdle 7y ago
  But that's just a reason why it would be a bad idea, not a reason that they couldn't do it or that it wouldn't work. I would think that they could distribute the cert (and the key) and have it work. [Edit] Unless browsers detect that it's a local IP address behind the domain name and still consider it a special case of origin.
- sascha_sl 7y ago
  it's not the nicest solution, but I don't see the problem with a public certificate and public private key (yeah not the most elegant wording) that is literally issued to `localhost` or `127.0.0.1` (not localhost.zoom.us because that still goes through DNS once and could be hijacked)
- Spivak 7y ago
  Plex solved this problem is pretty much the way you describe. https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
tgsovlerkhgsel 7y ago
They could, but if they distribute the private key, which they would, the private key would be considered compromised, and the CA would be required to revoke the certificate within something like 24h of being notified with appropriate evidence (e.g. a copy of the key or a special message signed with the key). In the case of LetsEncrypt certificates, there is even an API for this revocation. However, given how ineffective revocation is, it unfortunately could still be a viable strategy. The easier approach is, of course, using the fact that browsers now consider http://127.0.0.1 http://127.0.0.1 (and/or http://localhost http://localhost) a secure origin to avoid this issue.