fiji.sc are hosted through HTTP, and so are all ImageJ update sites. This enables MiM attacks to install harmful code at users computers that is then run on a powerful platform with full user credentials. The simplest mechanism to avoid this without loss of convenience is to serve everything through HTTPS. Can we do?
Thanks to Johannes’s efforts, we were finally accepted into the beta program for https://letsencrypt.org/. But following up on setting up HTTPS for all our servers is pretty low on our priority list. I can have our student sysadmin work on it after some other urgent tasks—hopefully we can have everything switched over by end of 2016.
OK—that’s far down the road. Why not use GitHub.com as a secure update site/ download mirror? I am mostly worried about downloading non-checksummed binaries to execute on the same account that I am using to type in my sudo passwor. For very good reasons, not a single modern software distribution channel is doing this any more (except for Icy).
Let me know if I can help.
Using GitHub as a raw file server like that is against their terms of service. Also, the ImageJ Updater does not support Git as a file backend (e.g., for writing the
I looked into Let’s Encrypt more today—as of today, it is now in public beta!—but it is still a little involved to set up. I’ll pass it along as a project for our student sysadmin. But he has two other critical priorities first: 1) fixing our server backups; 2) fixing the usage statistics to work again without crushing our servers. I personally think these are both more urgent than HTTPS.
We are finally getting close to HTTPS support for ImageJ update sites. Many of the sites hosted at LOCI are now working with certs in place (e.g., https://fiji.sc/ and https://mirror.imagej.net/) although most still have some unencrypted HTTP content elements.
Next week we will be migrating
sites.imagej.net to the new web server, which will allow it to support HTTPS.
We will post another update after that work is complete.
I would just like to raise attention to this again. Not only the official download and the ImageJ updater, but also the maven repository runs over http. That is, Fiji, ImageJ, and the ImageJ maven repository make users and developers download binaries over unencrypted and unauthenticated channels that do not have sensible security mechanisms to prevent man in the middle attacks. A man in the middle attacker can use the ImageJ updater, ImageJ downloads, and the maven repository to deliver modified binaries that will run on the target platform with full user permissions. ImageJ is used in scientific institutions that are significantly more interesting targets than random IoT devices, guaranteeing a homogeneous runtime environment with significant permissions. So no, this is not a safe and uninteresting niche. Installing an SSL certificate and hosting imagej.net over https should have the highest priority over any other projects. I am happy to help. BTW, Icy has the same problem, that does not make it better.
We have not forgotten, and I agree with your points. But there are too many other higher priorities. It is on @aneevel’s list and he works on it when he can. As I said above, we will post an update here when progress is made.
No. Issues of correctness (i.e.: things working at all, much less securely), as well as other security issues such as investigating and preventing potential hacker intrusions, take precedence over the HTTPS project.
If you honestly have time to devote to such Linux systems administration tasks, and want to be actively part of that maintenance effort, we can talk at the hackathon. But it is a substantial time commitment.
I have now fixed:
- The ImageJ 1.x site mirror: https://mirror.imagej.net/
- The wiki: https://imagej.net/
- The imagej.net 1.x mirror proxy: https://imagej.net/index.html
- The Fiji splash site: https://fiji.sc/
The Fiji update site (https://update.fiji.sc/) already worked.
The following resources on the dev box will be more challenging:
- http://code.imagej.net/ (e.g. http://code.imagej.net/maps/)
The challenge is that that server runs Apache 2.2 and wrangling the Apache config to handle multiple virtual hosts still eludes me. The configuration is subtly broken, working OK for http: right now, but not for https: yet. I will keep working on it.
After that, there will still be a problem because Java 6 cannot talk to HTTPS properly. So switching the Updater over to HTTPS will thoroughly harden the Java 8 requirement.
Great! Thanks @ctrueden. Looking forward to seeing you today.
I am more than willing to help figuring out how to configure Apache 2.2 at the hackathon or remotely.
Thanks a lot @ctrueden for making the update and download sites available over HTTPS.
https://fiji.sc/, https://update.fiji.sc/, https://imagej.net/, https://update.imagej.net/, https://sites.imagej.net/ all work. I.e. fresh downloads are secure.
Also, I tried to convince the ImageJ updater to fetch from HTTPS URLs and so far failed. I downloaded a fresh Fiji over HTTPS, I edited db.xml.gz and set the URLs to Fiji, ImageJ and Java8 update sites to HTTPS. Then I started and got three error messages that a secure connnection cannot be established because certificates could not be found:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1890) at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1885) at java.security.AccessController.doPrivileged(Native Method) at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1884) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1457) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254) at net.imagej.updater.XMLFileDownloader.start(XMLFileDownloader.java:92) at net.imagej.updater.FilesCollection.downloadIndexAndChecksum(FilesCollection.java:1147) at net.imagej.ui.swing.updater.ImageJUpdater.run(ImageJUpdater.java:145) at fiji.updater.IJ2Updater.run(IJ2Updater.java:78) at fiji.updater.Updater.run(Updater.java:30) at ij.IJ.runUserPlugIn(IJ.java:217) at ij.IJ.runPlugIn(IJ.java:181) at ij.Executer.runCommand(Executer.java:137) at ij.Executer.run(Executer.java:66) at java.lang.Thread.run(Thread.java:745)
So I followed the instructions in the accepted answer at http://stackoverflow.com/questions/6659360/how-to-solve-javax-net-ssl-sslhandshakeexception-error and imported the cetificates to
Fiji.app/java/linux-amd64/jdk1.8.0_66/jre/lib/security/cacerts (terrible SO thread BTW) however, the error persists. I have also tried to make sure that ImageJ starts with this JRE by starting it with the
--dry-run output. Now I am feeling a little bit lost. Any ideas?
AFAICT, this is only if you browse the files through the web browser. Did you try changing to https in a Maven POM for the
<repository> and see which protocol it uses when downloading actual artifacts?
So while it is probably fixable, I am not sure how much it matters for the common case.
You are using a too-old version of Java 8. The certs for Let’s Encrypt were only recently added in 1.8.0_101.
Problem with jdk version
@ctrueden, thanks! This is the one shipped with Fiji. I will replace locally. Should we ship a newer version then? At least when the default URLs to update sites are being replaced by HTTPS URLs.
Yes, I fear we will need to update the version shipped with Fiji, again. Unfortunately, there is still no mechanism to do that. It would be straightforward to add a simple check which tells people to update their Java, with a link to a wiki page explaining more. Programming the Updater to actually download a new Java would be much more involved, though.
The fact is that there will always be a conflict of requirements between shipping ImageJ/Fiji with “batteries including Java” and shipping ImageJ/Fiji without Java so that updates to the system Java affect it as desired.
One solution which has occurred to me is to add an explicit Java options panel in ImageJ itself, which the user can use to control which Java is used. Then you can pick between “embedded” and “system” or specify custom path to a JRE or JDK, etc. This is definitely something we will do in the future, but requires some work. Even with that in place though, we’d still need some custom logic to recognize that the version of Java being used is too old for some features, and recommend/explain to the user how to proceed if they want to enable those features.
Feel free to file an issue/issues.
Imagej.net HTTP blanket redirect to HTTPS
please help me test the next step towards HTTPS migration.
How to test
Install this update site (sharing HTTP link for older installations, change it to HTTPS if you like):
Please test things you usually do with the updater / uploader. Let me know of issues or anything unintuitive.
Switch to HTTPS URLs during update procedure
An installation running Java 7 < 7u111 or Java 8 < 8u101 will not be able to communicate via HTTPS and should raise a warning.
Otherwise a dialog should help you review the URL changes from HTTP to HTTPS. This dialog will also pop up in the future in case an installed update site URL gets changed on the list of available update sites (related discussion).
One can also manually check for URL updates by clicking
Manage update sites>
The rewritten webdav uploader should make it possible to upload to an update site via HTTPS. It also affects HTTP so please test!
Affected repos & PRs
Super thankful for code reviews!
Manually added sites, whitelisting of mirrors? @carandraug
Hi @frauzufall, supercool! Unfortunately, I get errors when building the pull requests in ui-swing and plugins-uploader-webdav
[ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /home/saalfelds/workspace/imagej/imagej-ui-swing/src/main/java/net/imagej/ui/swing/updater/SitesDialog.java:[137,69] method setURL in class net.imagej.updater.UpdateSite cannot be applied to given types; required: java.lang.String found: java.lang.String,boolean reason: actual and formal argument lists differ in length ...
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project imagej-ui-swing: Compilation failure: Compilation failure: [ERROR] /home/saalfelds/workspace/imagej/imagej-ui-swing/src/main/java/net/imagej/ui/swing/updater/SitesDialog.java:[137,69] method setURL in class net.imagej.updater.UpdateSite cannot be applied to given types; [ERROR] required: java.lang.String [ERROR] found: java.lang.String,boolean [ERROR] reason: actual and formal argument lists differ in length ...
Do you have an idea what that could be?
They depend on the imagej-updater PR. I did not push the according changes to the pom because I did not know how to upload dependencies to other PRs the best way. Hence the update site for testing how could I improve that?
@axtimwalde I added my SNAPSHOT dependencies to the repositories. Hope that helps.
@frauzufall Thanks a lot! I modified the poms to skip the scijava enforcer while developing with the snapshot dependency and hope that’s ok with you.
Updating Fiji works perfectly. I hope to find time later to test how uploading will do. What I did ischeck out the above mentioned three repositories and the imagej repository, build them all into my local Fiji installation, then sneak around in the updater settings, happily find all URLs be https, then run update and leave all the locally modified files untouched. Worked in that it didn’t complain, it also showed a smiley. I fully trust in that it actually uses the https URLs :).