Summary
This blog post is a reminder that you should make sure that all your builds in the Java ecosystem access the artifact repositories
(e.g. Maven Central) via HTTPS instead of HTTP.
This often just means replacing the ‘http:’ in repository URLs with ‘https:’ in your build files (e.g. build.gradle, build.sbt, pom.xml) or your
own artifact servers.
It is a long known fact that downloading Java artifacts via HTTP has inherent security risks which might put your
company, customers or users at risk. See following posts for more information:
This is why in 2019 Jonathan Leitschuh of Gradle started an initiative to disable HTTP access to artifact servers in a coordinated way.
He has posted an update concerning the state of the initiative in January.
On January 13th 2020 HTTP access to JCenter will be disabled, the other repositories like Maven Central will follow on January 15th.
This means that you should make sure that your builds only access the artifact repositories via HTTPS or else they might stop working.
Hopefully, you switched your builds already a long time ago and don’t need to do anything.
Artifact repositories that will disable HTTP access
This is a non-complete list of artifact repositories, which will disable HTTP access. (Compiled from this Gist.)
It contains the links to the individual announcements in case you missed them.
It is in many ways better to switch all artifact repository access to HTTPS than to rely on this list.
JCenter (JFrog Bintray)
Maven Central
Spring (Pivotal)
Gradle
Conclusion
Switching artifact repositories to HTTPS-only is a good thing for the Java ecosystem, but still not enough… It might be a wake up call for some to think about
supply chain security in the world of software. Modern builds in most languages fetch myriads of direct and transitive dependencies, be it for building and testing
only or be it for delivering them as part of your product to a customer. Fetching dependencies over HTTPS mitigates potential Man-in-the-middle (MITM) attacks,
but it does not solve integrity or authenticity issues:
- Who assembled the artifacts I’m using?
- Are updates to the artifacts created by the same developer as previous ones?
- Are the contents of the fetched artifacts always the same for the same version?
These are issues which can only be solved by verifying the signatures of the artifacts and by checking the
cryptographic hashes of the downloaded artifacts. Luckily, the Gradle team is working on these issues…
Update (11 Jan 2020)
Added link to initiative update.