Shiri Bailem

2024-11-19 19:33:06

Randomly thinking about small protocols or protocol changes that I think should exist.

Prime example is Static HTTPS:
I think there should be a companion protocol to HTTPS for handling static requests. This would be great for caching, general performance, and even saving storage/bandwidth on things like ActivityPub.

The gist of it is that HTTPS uses a static set of keys to negotiate a dynamic set of keys and dynamically encrypts your entire conversation with the server. It's impossible to do any sort of caching on HTTPS without decrypting it first, but also there's no way to make it unique either without things like php sessions (requiring logins or backchannel confirmations).

How this would work, using the existing HTTPS keys, a request would be made similar to HTTP where the connection itself is unencrypted, but the host/url will specifically be encrypted and the payload of the data sent in return will be encrypted. If you were to cache it the same encrypted request will net the same encrypted data (unless the file behind it gets updated of course). If headers must be added then those can be encrypted separately as well, but also support unencrypted where not necessary... everything would be avoiding using headers in general for this, especially as the files are static.

(Optionally the html could also include a key explicitly for that file)

This means that anything in the middle can cache data without necessarily knowing anything about it. Meaning that something like Cloudflare could provide caching for an HTTPS website without also having to have the key.

Obviously in less secure cases where it doesn't include a special key in the html it will mean that if someone knows what site you're accessing (often an easy guess from IP unless it's something like a cloudflare protected site) they can potentially identify the file by matching to their own browsing... but these should be unimportant files anyways (ie. the google logo, css style sheets, etc), even if visible they'll be effectively signed and you'll know the site wasn't tampered with in transit.

But the really special case shines in things like the fediverse where when I make a followers-only post with a picture attached... right now either the picture is relying on obscurity (publically visible if you know the address) or it has to be embedded in the post as it's sent to the recipient.

This protocol would mean that the html of the post could include the key to the file. The receiving server wouldn't even need to support this protocol or have any change at all in ActivityPub standard to show this image, but the image would still be visible to the recipient so long as their browser or client supported it.

Example:
<a href="shttps://foggyminds.com/images/123456" key="101010101">
(obviously the key would be much longer usually)

A backwards compatible call when privacy isn't a concern (ie. google logo):
<a href="https://foggyminds.com/images/123456" shttps=1>
(Browser with no shttps support would use https normally, but one with that support would see the shttps=1 on there and change the protocol automatically)

#nerd #rant #protocols #https #webdev #http #ssl #web