Daniel Quinn

Enabling Data Compression in RIPE Atlas

Daniel Quinn

3 min read

0 You have liked this article 0 times.
0

We’d like to enable gzip compression on all of RIPE Atlas' measurement API calls — but thanks to the BREACH vulnerability, doing so could mean that some enterprising individual with an obscene amount of time on their hands might be able read the contents of the responses. This means measurement results as well as metadata for measurements — including the small number of measurements not marked as “public”. We believe the drawbacks are negligible, but we’re looking for community support.


 

Currently, API downloads can be very big and, by extension, very slow for anyone not on a ridiculously fast network. This impacts bulk data downloads, as well as any API calls the pages on RIPE Atlas may make to generate a chart or map. This translates into long waits and potentially expensive data transfers if you’re on a mobile network.

As this data is highly repetitive, compressing it results in a reduction of up to 90%, so the benefit is significant.

The BREACH vulnerability allows someone with a lot of patience and ingenuity a means of decrypting data sent over SSL if they have advanced knowledge of some of the contents of that stream. It’s been shown to be an effective brute-force method of reading entire HTTPS responses, so when the vulnerability was exposed, we dropped gzip compression across the board on https://atlas.ripe.net .

Later, we developed a selective way to enable compression, turning it on only when the returned data was already public information. This method also strips any user-related data (such as your session cookie), so if someone were dedicated enough to attempt to breach these responses, there would be zero reward.

What we are proposing now is that we enable this selective compression for responses that might contain non-public data, specifically all RESTful measurement API calls. These responses make up the majority of data shared through the RIPE Atlas project, so compressing them offers the biggest benefit to the community.

This would mean that someone with enough time, energy, and opportunity could potentially read responses from these APIs even over SSL. The risk, however, is very low (on account of the effort required) and the benefit to the attacker would be minimal, since that same data could be acquired by scheduling measurements of their own.

Specifically, these changes would apply to the following:

  • Measurement results
  • Measurement metadata

From our perspective, this does not appear to be a problem, but RIPE Atlas is a community project and it’s only appropriate that we offer the community the opportunity to respond to proposals like this one.

So, please let us know if you have any feedback on this issue. Our intention is to enable compression on the API services in the coming weeks.

0 You have liked this article 0 times.
0

About the author

Daniel Quinn Based in Amsterdam, Netherlands

I'm a Canadian software engineer who's been living in the Netherlands since 2011. I primarily operate in the web space, writing Python (Django) these days, but I've been doing this since 1999 so I've worked with a number of languages and environments. Presently, I work for the RIPE NCC, entirely on the RIPE Atlas project, primarily in the areas of the UI and REST API, though I'm also responsible for the Sagan result parser.

Comments 0