1596714 - TLS Certificate validity is not considered for cached resources

Status: RESOLVED DUPLICATE of bug 660749

(Core :: Networking: Cache, defect)

Description

[florian.dehling]

Attachment: Conference paper with detailed description

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Safari/605.1.15

Steps to reproduce:

Referring to a research form 2015 (https://doi.org/10.1016/j.cose.2015.07.004) we revisited a browser cache poisoning attack that utilizes the equal treatment of files transmitted via valid and invalid (e.g. self-signed) TLS certificates.

1. Set up a nginx web server to host a HTML and a JavaScript file.
2. Issue a LetsEncrypt certificate for this server.
3. Prepare a second nginx configuration that is using a self-signed certificate.
4. Request the website by using the nginx configuration with the self-signed certificate (click through the TLS warning).
5. Request the website again using the nignx configuration that is using the LetsEncrypt certificate.

We will give a talk about this observations at NordSec 2019. More details can be found in our paper (attached).

Actual results:

After step 4, the JavaScript file that was transmitted using an invalid TLS certificate gets stored in the browser cache.
When requesting the same resource again (step 5) the JavaScript file that was transmitted in step 4 is loaded from the browser cache. No TLS warning appears to the user.

Expected results:

Files that are transmitted in TLS sessions that are using different certificates should not be mapped to the same HTTP cache key in the browser cache. It would be appropriate to not cache any files if the browser detects a broken TLS certificate.

Comment 1

[Honza Bambas (:mayhemer)]

This is duplicate of bug 660749.