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.
Comments 0
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.