0

A lot of the web is moving to HTTPS, which to my understanding does two things: Making the data unreadable by third parties, and verifying it's coming from the expected sender. The latter seems unarguably good, but the first also has some downsides.

The noticeable downside I see is that it completely disables any more centralized caching (the browser itself could still cache). I am wondering if it would be possible to have HTTP traffic that is signed, so that no MitM could alter the data, but not encrypt it so that parties like CDN, the ISP or just the local network admin could configure it to be cached and significantly speed up the requests, and also decrease load on the origin servers.

I can see this is not for every application applicable, but for more static and insensitive data like for example Debian ISO download, Wikipedia or jQuery library files this could be used.

Would signed but unencrypted HTTP be possible? Is there a real use for this or am I missing something?

Improve this question
11
  • I don't understand. Cached content would be fetched once from the source. There would not be great savings to have that single fetch unencrypted.
    – schroeder ♦
    Commented Nov 16, 2022 at 12:14
  • @schroeder That would be true for just one device to the origin server, but not for hops in between. If I download a large static file like Debian ISO on my laptop in my office, and a colleague downloads the same file an hour later, they would not be able to use any cached version. If the office has a cache server locally setup, then with unencrypted data it could cache it, but not if the data is encrypted.
    – Jeroentetje3
    Commented Nov 16, 2022 at 12:50
  • How would your cache server know what you were downloading in order to serve a cached version unless it broke the encryption first? Once it is broken then the connection to the target source doesn't need to be not encrypted. It already knows.
    – schroeder ♦
    Commented Nov 16, 2022 at 12:58
  • @schroeder I am not entirely sure what you are asking in regards of breaking encryption, I am assuming encrypted data can't be broken. The cache server knows which cache to server based on the requested URL. 1. The user requests the file (httpX://debian.org/iso.iso), through the cache server, but first a miss. 2. The origin server sends this data, with a signature that it is the original owner, to the cache server, which both streams it to the user, and puts it in the cache (both the file and the signature). 3. A second user requests the file from the cache and verifies the signature.
    – Jeroentetje3
    Commented Nov 16, 2022 at 13:08
  • If the connection would be signed but not encrypted would not make any difference because not just the content but the connection would be "signed" and any cache server would still break the authenticity of the connection and thus the client would have to assume it is a Mitm attack and throw an error.
    – Robert
    Commented Nov 16, 2022 at 13:39

1 Answer 1

Reset to default
4

There is a standards draft called Signed HTTP Exchanges that allows authors to sign and package contents. Third-parties then can serve the contents, while users are still able to verify its integrity.

Improve this answer
2
  • 1
    Thank you for your answer. This definitely does look like it relates to my question, but it does seem to be focused on prefetching and very temporarily keeping the data. It is a maximum of 7 days cachable, and it is mainly used by resources that link to the data-in-question. It seems unlikely to be usable by caching software.
    – Jeroentetje3
    Commented Nov 16, 2022 at 13:00
  • 1
    Yes, it's not exactly what you asked for, just something that answers the question "Would signed but unencrypted HTTP be possible?" so I thought it might be worth mentioning.
    – Yogu
    Commented Nov 16, 2022 at 13:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .