06 Jan 2020 | Peter Stöckli
Your Java builds might break starting January 13th (if you haven't yet switched repo access to HTTPS)
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:
- How to take over the computer of any Java (or Clojure or Scala) developer (by Max Veytsman)
- Want to take over the Java ecosystem? All you need is a MITM! (by Jonathan Leitschuh)
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)
HTTP disabled on | January 13th, 2020 |
Affected Repo URL(s) | http://jcenter.bintray.com |
Announcement | Secure JCenter with HTTPS |
Maven Central
HTTP disabled on | January 15th, 2020 |
Affected Repo URL(s) | http://repo1.maven.org , http://repo.maven.apache.org |
Announcement | HTTP access to repo1.maven.org and repo.maven.apache.org is being deprecated |
Spring (Pivotal)
HTTP disabled on | January 15th, 2020 |
Affected Repo URL(s) | http://repo.spring.io |
Announcement | Goodbye http://repo.spring (use https) |
Gradle
HTTP disabled on | January 15th, 2020 |
Affected Repo URL(s) | http://repo.gradle.org , … |
Announcement | Decommissioning HTTP for Gradle Services |
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.