cyREST
cyREST copied to clipboard
cytoscape
Add https support
Communications via https would be beneficial.
Jetty and Karaf are fully capable of supporting HTTPs; sorting out SSL certificates without requiring anything of the casual user could require some careful scripting.
In the branch issues/83, https is enabled for the jetty server.
A key will have to be generated. I used this command:
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass 123456 -validity 360 -keysize 2048
The following line will have to be pointed to the generated key, and CyREST will have to be built locally for it to work: https://github.com/cytoscape/cyREST/blob/d026681e3da5f29edeefcdc49fd67b0fb1469781/src/main/java/org/cytoscape/rest/internal/task/OSGiJAXRSManager.java#L174
From there, the gentlest, non-root version of getting the https to work without warnings on Chrome was to access this url: chrome://flags/#allow-insecure-localhost
Mind you, this is ONLY for local browser access; how it interacts with other https services is yet to be seen.
This appears to be a good resource to do things programmatically:
https://www.humankode.com/asp-net-core/develop-locally-with-https-self-signed-certificates-and-asp-net-core
Regarding the last comment, at least the linux method works. The downside is that certutil is part of a package that requires sudo to install.
There was a suggestion that some of this can be solved by having a sudo/admin query in install4j. Still not a total solution.
Maybe if there's a way to get a CA to recognize localhost keys?
Possible workaround: generate a subdomain (of NDEx, for example: cyinstance.ndexbio.org), which has a DNS entry of 127.0.0.1
Apparently, some sites do this for almost the same reason we would: https://stackoverflow.com/questions/23782782/why-do-some-public-hosts-resolve-to-127-0-0-1
From there, it's a matter of serving the correct certificate (as in the above thread).
This may present a security vulnerability, as the same certificate may have to be distributed with every Cytoscape install, and may expire periodically.
Relevant:
https://stackoverflow.com/questions/16697939/communicating-from-https-website-to-http-server-on-localhost-cross-domain
https://stackoverflow.com/questions/6793174/third-party-signed-ssl-certificate-for-localhost-or-127-0-0-1
And a thread about the relevant security issues:
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/eV89JXcsBC0
For the above solution (having a cytoscape.org subdomain registered with a CA, and having that subdomain registered in a DNS as 127.0.0.1) there are some major problems.
The primary one, as mentioned in https://medium.com/@Zemnmez/%C3%BCbersicht-remote-code-execution-spotify-takeover-a5f6fd6809d0 and the above mentioned https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/eV89JXcsBC0 is that when anyone can get their hands on the private certificate, they can, in the best case, revoke that certificate. In the worst case, they can pretend to be that server.
The final nail in the coffin for the DNS/127.0.0.1 approach is that letsencrypt specifically says not to do it: https://letsencrypt.org/docs/certificates-for-localhost/
The ray of light here is that 127.0.0.1 is treated very differently than localhost. This is also specified in https://letsencrypt.org/docs/certificates-for-localhost/ which references a w3.org Candidate Recommendation which singles out 127.0.0.1 vs localhost: https://www.w3.org/TR/secure-contexts/#localhost and specifies that 127.0.0.1 is 'Potentially Trustworthy'.
In practice, this means some adopting browsers will accept references to 127.0.0.1 from https sources.
Take, for example, the following two links: https://petstore.swagger.io/?url=http://localhost:1234/v1/swagger.json https://petstore.swagger.io/?url=http://127.0.0.1:1234/v1/swagger.json
In Chrome, both work fine. In Firefox, only 127.0.0.1 works; localhost is blocked. In Safari, both are blocked. In Edge, both are blocked.
Since this is literally the recommendation of letsencrypt, it might warrant just switching CyRESTs internal references and the Clouds references to simply using 127.0.0.1.
I will look for more info to see if Edge and Safari have any plans on heeding w3.
Edge appears to have addressed this issue: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11963735/
I am updating my edge version to see if this is the case.
Related issues in chromium and firefox:
https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e https://bugzilla.mozilla.org/show_bug.cgi?id=903966
After edge update (to version 42.17134.1.0) is confirmed to be able to access 127.0.0.1 from an https page.
~WebKit (Safari) is apparently in the WONT FIX camp: https://bugs.webkit.org/show_bug.cgi?id=171934~
WebKit (Safari) has re-opened the bug, but it isn't resolved: https://bugs.webkit.org/show_bug.cgi?id=171934