Why Your App Shouldn’t Use HTTP. Anywhere.
In October 2018, Google kept its HTTP “name and shame” promise when the Chrome team flipped a switch. That switch was to officially mark any site with an http:// scheme as insecure.
For some sites, the “nohttp” movement had begun in earnest.
But, changing the browser protocol is really only the first step. It’s time to clean up your build process. It’s time to clean up your documentation. It’s even time to clean up your old-school XML namespaces.
It’s time to stop using HTTP. Everywhere.
Let’s take a quick trip down the HTTPS memory lane. After that, you’ll see where http:// trickles into your application and why that's bad. Finally, you'll learn how to use the latest addition to this movement, nohttp from the Spring team.
Going nohttp: A Brief History
In January 2015, Mark Nottingham published a W3C paper outlining the need to move the web over to HTTPS. Many of you will remember the days when HTTPS was essentially the realm of authentication and financial transactions.
In fact, at the time that paper was written, barely 40% of Internet traffic was using HTTPS. You can see the following percentages of pages loaded over HTTPS by Chrome by various countries in 2015:
But, the evidence was mounting against ISPs that tampered with each HTTP response. And, against websites that tracked users.
The simple fact was — and still is — that HTTP offered no guarantee that you were actually seeing the page you requested. Since that was about 80% of websites at the time, that meant the lion-share of the Internet.
But it’s haaaard!
At that time, much of the Internet wasn’t using HTTPS because it had been historically difficult and expensive to set up.
In April 2016, Let’s Encrypt, a non-profit security organization, was launched. Let’s Encrypt began making HTTPS certificates available free of charge.
They followed that up by developing an open-source protocol for setting up SSL certificates. This eventually resulted in two simple commands you could run on your server to upgrade to HTTPS.
Difficult and expensive? No longer.
But it’s sloooow!
Another barrier was a relic from the dark ages of the Internet: HTTPS was demonstrably slower than HTTP.
Actually, HTTPS performance hasn’t been a performance problem for a very long time, as Adam Langley from Google said about this back in 2010:
SSL/TLS accounts for less than 1% of [our] CPU load, less than 10KB of memory per connection and less than 2% of network overhead.
This Site Is “Not Secure”
HTTPS was now fast, cheap, and easy to use. It was time to grease the wheels.
The Google Chrome Security team made a proposal that Chrome start changing their security indicators.
Their research showed that their current indicators did almost nothing to inform the user about insecure connections. One user innocently asked, “Why does the website have a purse icon next to it?”
If a user could mistake a padlock for a purse, how could the Chrome team inform the population of something as complex as channel security?
In the end, the Chrome team progressively changed the way they warned users about using http:// websites:
- In January 2017, Chrome would add the words “Not Secure” before any HTTP website where credentials or credit cards were being accepted
- The following year in September, it would ramp that up to any HTTP website at all
- In October 2018, any HTTP website, when credentials or cards were being entered, the “Not Secure” message would turn red
Okay, now what?
These days, browser HTTPS is at an all-time high, thanks to many factors. In the space of just four years — 2015 to 2019 — browser HTTPS traffic has moved from a tragic 40% to an admirable 80%.
Again, you can see the same chart here, just focused on 2019 now:
Honestly, this is one of the great triumphs of the security community. Let’s quickly pat ourselves on the back! Then, recognize the next problem to solve — the non-browser HTTP traffic in software that you build.
Repositories
The fact is that the exact same principles apply when it comes to non-browser, HTTPS traffic.
Take, for example, the fact that most software depends on additional software, which an app likely downloads at build time from one or more artifact repositories.
If you’re using Maven, you’d indicate one of these dependencies like so:
And, you’d expect to get this dependency from a repository.
However, if you point to a repository using HTTP:
you have the same lack of guarantee you have when using HTTP in the browser.
By pointing to http://repo1.maven.org/maven2, you lack the guarantee that:
- You are actually talking to Maven Central
- You received the dependencies asked for without an intermediary having modified it
Which dependencies would you like to know for sure they are what they say they are? I’m pretty sure you’d say the same thing I do when my kids ask which of them I love the most: “All of them.”
Happily, the fix is easy: Simply point to https://repo1.maven.org/maven2 instead. Now, when you build your project, you'll download its dependencies from a known and trusted location.
Documentation
What about in your documentation?
When users read your documentation, certainly they will click on the links that you provide to other sites:
For more information about this feature of our product, check out
this article.While 90% of the top 100 sites use HTTPS by default and 96% of them work with HTTPS, we are still a long way from websites turning off port 80 altogether.
This means that there is still a small window where a visitor could be compromised by clicking an HTTP link that you provide them in your documentation.
You might be thinking, “ but HSTS!” …it doesn’t help in this scenario.
True… HSTS is supposed to force browsers to talk HTTPS even if the user requests HTTP, but
1. The site you are linking to may not be using HSTS. It’s certainly still an optional feature, and
2. If it’s the first time the visitor has visited that site, the HTTP payload can be intercepted and any redirection to HTTPS prevented. It’s common for developers to forget that the HSTS header isn’t actually respected by browsers unless it’s part of an HTTPS response.
The simple fix is to point to the https:// version of the site to which your documentation links.
Tests
You may have integration tests that reach out to external services.
I have a test, for example, that confirms correct integration with Keycloak, an open-source OAuth 2.0 Authorization Server, which looks something like this:
Would you agree that it would be a good thing to know for sure that my integration test is really talking to Keycloak? Also, to know that the response I’m getting back is the unaltered response from Keycloak?
Consider the scenario where you don’t have confidence that your CI/CD pipeline is telling you the truth, and you can see why simple maneuvers over to HTTPS are valuable.
Namespaces
XML namespaces are pretty curious since they are usually arcane-seeming things that we simply copy-paste from library documentation (ah look, documentation again). We likely don’t think about XML namespaces very much.
However, consider the following XML payload:
This is certainly an older version of Spring, but I did, for the sake of illustration, lift it from the results of googling for “spring beans xml”.
Now to be clear, Spring ships with the corresponding DTDs, and so it resolves them locally, by default. All safe and sound.
But if Spring ended up calling out for some reason, there would be no guarantee that the code is actually getting the DTD it requested. This could lead to an XXE vulnerability.
The great thing is that modern Spring can resolve these locally with HTTP or HTTPS, so the following will work:
And with that very simple change, you get an extra layer of security. If Spring does actually make this call to download the DTD, it will be over HTTPS.
You Need HTTPS with XSDs, too
This is a smaller problem with more modern XML definitions that use XSDs:
XML resolves namespaces via a key-value pair. The http://www.springframework.org/schema/beans is the key, and the value is http://www.springframework.org/schema/beans/spring-beans.xsd.
The value is the one you’re concerned about.
For the same reasons already explained, this should instead be:
Demo Time
Okay, now that you’re ready to get rid of any reference to http:// in your projects, how should you proceed?
Doing a manual search is okay, but it’s cumbersome, and you’ll forget.
You need something that is going to run quickly, on every build of your code. This makes sure that your CI/CD pipeline doesn’t ship your artifact if it was built usinghttp://.
To follow along, then, you’ll need a simple Java project that has references to http:// in it.
Second, you’ve hopefully at least seen Gradle or Maven before and are comfortable at least tweaking it.
And if you aren’t using Java, maybe consider applying these same principles to a plugin in your own language!
Note that while we’ll focus on Java, your project needs only be JVM-based and at Java 1.8 or higher (sorry no Android support just yet).
Scrubbing with nohttp
The simplest way to confirm zero references to http:// in your Java project is by introducing the following Gradle plugin:
Then run gradle nohttp or gradle check and watch it go to work! The result will be a list of http:// links that should be changed.
nohttp with Maven
If you’re using Maven, then there’s a bit more boilerplate, but the concept is the same. Simply add the plugin to the <plugins> section of your pom:
And then add the following into a file you’ll name nohttp-checkstyle.xml:
Finally, run mvn checkstyle:check or mvn verify to see it go to work.
Exclusions
Of course, there are always exceptions, even begrudging ones.
There will be a website here or there that doesn’t use HTTPS. There will be XML namespaces that aren’t served over HTTPS. There will be third-party software (or even parts of Java itself!) that hardcodes its usage of HTTP.
Or, quite simply, your project may be huge and you need to change things a bit more iteratively.
In these cases, you can create a whitelist of exclusions.
Exclusions with Gradle
nohttp currently has slicker support for Gradle than Maven. So, it’s quite easy to add exclusions by simply introducing a file called etc/nohttp/whitelist.lines into your project.
The file can have regular expressions in it, like so:
Once you build again, you’ll see nohttp suppressing errors for URLs matching the given patterns.
Exclusions with Maven
Doing the same with Maven is still quite simple, but it requires one extra step.
Remember the nohttp-checkstyle.xml file you added? Just check the NoHttpCheck module definition like so:
And, it will work the same as the Gradle plugin.
Of course, you can edit value to point to a different file location.
Exclusions with Checkstyle
nohttp is based on the Checkstyle project.
So, you can also use standard Checkstyle exclusion syntax to skip a block of code:
Because you already included Checkstyle when you added nohttp to your project, no further configuration is necessary for this to work.
Summary
Okay, so you’ve seen the immense efforts and benefits that have come from the browser HTTPS movement. The next step is non-browser.
You can start with simple things, like links to repositories, your documentation, your tests, and your namespaces.
For Java projects, the nohttp project makes this a cinch. Simply add to your project, configure, and enjoy the additional layer of security.
