I’m pleased to announce the nohttp project, which lets users find, replace, and prevent the usage of http://.

Background

Today, Jonathan Leitschuh published a blog titled Want to take over the Java ecosystem? All you need is a MITM!. The blog demonstrates that hundreds of Java libraries are downloading dependencies over HTTP. This opens the projects up to potential MITM (man in the middle) attacks.

Unfortunately, there were multiple Spring projects that were using HTTP to download dependencies. Fortunately, we uncovered no signs of a successful MITM attack. We have also addressed the issue to ensure that no MITM attacks can be made in the future.

Spring Team Reaction

The Spring Team takes security very seriously. Since discovering that there were Spring projects downloading dependencies over HTTP, we have taken measures to ensure that a MITM attack cannot happen in the future. The most obvious change is to update Maven repository locations to use HTTPS. However, we have taken this much further by switching to using HTTPS (almost) everywhere.

It is 2019, so, hopefully, it is apparent why we want to remove the usage of HTTP. Using HTTPS is fast, simple, and available for free, so there are no excuses for continuing to use HTTP. As developers, it is important that we help the world transition to use HTTPS everywhere (even static sites need HTTPS).

We certainly are not the only ones trying to eliminate HTTP usage. Let’s Encrypt was formed to make HTTPS free, automated, and open. Chrome has updated its UI to indicate that HTTP is insecure. Maven Central has deprecated the use of HTTP. The list goes on.

Replacing HTTP with HTTPS

The Spring team has gone to great lengths to update all of our URLs to use HTTPS. This includes everything from our Maven repository URLs, to Apache License, to documentation links. There are some instances where using HTTPS was not possible. For example, some sites we link to do not support HTTPS, XML namespace identifiers must match the identifier in the document, and so on.

HTTPS XML Locations through the Classpath

In our efforts to eliminate HTTP usage, Spring Framework has been updated to resolve XML locations that use HTTPS locations through the classpath. Previously, this was only done for URLs that used HTTP. Consider the following XML configuration:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">

The [https://www.springframework.org/schema/beans/spring-beans.xsd](https://www.springframework.org/schema/beans/spring-beans.xsd) URL is resolved through the classpath instead of requiring a network connection.

Notice that the XML namespace name, which is an identifier, cannot be changed to use HTTPS. This is not ideal from the perspective of being able to put security controls in place, but the name is never requested over a network, so it poses little harm to users.

Infrastructure Updates

The Spring team has updated all our hosts to ensure that HTTPS is being used. Each site supports HTTPS, redirects to HTTPS, and uses Strict Transport Security.

A potential MITM means that our build infrastructure could have been compromised. In response to this, we repaved all of our build infrastructure and rotated all of our credentials.

New Security Controls

While it is important to react to a security incident, it is also important to put security controls in place to ensure the problem does not happen again.

We have updated our build boxes to block HTTP traffic to ensure that this cannot happen again. To protect developers and our users, we have created the nohttp project. This project can be used to find, replace, and prevent http:// usage while being pragmatic about allowing URLs that cannot change (such as XML namespace names). For additional details, refer to the project’s site.

Join Us

We hope that you will join the revolution to help eliminate the usage of HTTP.