Post by @kopper@not-brain.d.on-t.work

ssrf protection being so underbaked in pretty much any toolkit is really disappointing and feels like some kind of indication of how little people cares about communicating with any machine not their own. "Just Allowlist Everyone In The Firewall 4Head" should not be The Solution

iceshrimp.net is stuck using http/2 for the foreseeable future because dotnet's http/3 does not seem to expose the ability for us to create our own socket for the connection to go through, all just to validate that the IP we're connecting to is not local. dns is not enough because you Can Just do http://127.0.0.1, and checking the domains ahead-of-time is obvious TOCTOU

(triggered by the recent mastodon release which had a ssrf bypass involving a weird uncommon ipv6 feature, which is not unexpected when everyone's expected to build this from scratch. at least in dotnet we can check IpAddress.IsLoopback and friends and if that breaks it's not our bug)

this mighe be solvable at a firewall layer, but that's another complication in deployment to go wrong / invisibly get ignored by people (or worse, "one click deployment") throwing a dockerfile at the wall

19 Replies

3 Boosts

kopper :colon_three:

@kopper@not-brain.d.on-t.work 1 hr. ago

it happened again

d@nny disc@

@hipsterelectron@circumstances.run 1 hr. ago

@kopper omfg

Fedify has to fetch the key before it can verify the signature

i didn't realize json-ld was this bad probably because reading 10% of the spec sent me into a fugue state

kopper :colon_three:

@kopper@not-brain.d.on-t.work 1 hr. ago

@hipsterelectron@circumstances.run that's not json-ld's fault, it's the same with http signatures. the "key id" is an url you have to resolve to load the actual key bytes

kopper :colon_three:

@kopper@not-brain.d.on-t.work 1 hr. ago

@hipsterelectron@circumstances.run pretty much everyone serves the key from the same endpoint as the actor itself, so it's just a roundabout way of saying "this is the actor who signed this request" which you verify by downloading their key and verifying the signature

~7 more replies

d@nny disc@

@hipsterelectron@circumstances.run 42 min. ago

@kopper having that be in the same protocol rather than out-of-band seems to undermine the basic assumption of a signature and now i'm wondering why crypto for users was considered a problem to solve before crypto between servers

kopper :colon_three:

@kopper@not-brain.d.on-t.work 40 min. ago

@hipsterelectron@circumstances.run to be fair it effectively works as "crypto between servers" because there isn't enough data to backlink actors to their objects (validating it's indeed true and not a forgery) and what is there is really performance-draining so everyone takes the url authority on the IDs and references and if it matches they consider it valid. this same-origin policy is why this works at all

d@nny disc@

@hipsterelectron@circumstances.run 35 min. ago

@kopper the web makes my head hurt

kopper :colon_three:

@kopper@not-brain.d.on-t.work 35 min. ago

@hipsterelectron@circumstances.run dont worry i dont think the rest of the web wants to take anything from activitypub for this. i hope not

kopper :colon_three:

@kopper@not-brain.d.on-t.work 34 min. ago

@hipsterelectron@circumstances.run there's this thing which the people who'd defend this kinda structure yell and i think you may get a kick out of it: https://indieweb.org/follow_your_nose

d@nny disc@

@hipsterelectron@circumstances.run 24 min. ago

@kopper i was going to mention providing a hash of the public key would at least allow for it to be implemented in a way that doesn't backdoor implementors. i'm kind of impressed (derogatory) at how it assumes the alternative to fetching a document-specified URL for everything is something like .well-known since that solves nothing cryptographically and none of this is necessary if you encode public keys as a top-level entity of the system. i wouldn't even hash the key i would just write it out directly but if you want to use public keys as a DRM system like the web loves to do then you need to map that key to some sort of ownership system

d@nny disc@

@hipsterelectron@circumstances.run 20 min. ago

@kopper it's incredibly upsetting to me that so-called "indieweb" doesn't consider it a basic protocol to manage key discovery since that was the fundamental problem with centralized services and TLS more generally. particularly if messages are going to be forwarded then it seems absurd to not incorporate better support for this but i suppose json-ld is so incredibly half-assed this would make sense to them. even if it means you literally can't process messages without contacting the literally centralized server

d@nny disc@

@hipsterelectron@circumstances.run 1 hr. ago

@kopper NOOOOO!!!!!!! NOOOOOO!!!!!!!

1 more reply

pancake :butterfly_::neofox_lesbian:

@natty@astolfo.social 4 wk. ago

@kopper@not-brain.d.on-t.work I don't think SSRF is possible to get rid of entirely. Even if you see the packet leave towards the default gateway, even if it leaves via the correct physical interface

I've been thinking about this for hours and hours, it feels like trying to solve this at transport layer is just bound to blow up because of some obscure setup

I guess one of the answers (no idea how many there are) might be to rip off Tor's exit nodes?

Maybe some link-layer protocol that lets you mark packets as "leave the local network immediately"?

d@nny disc@

@hipsterelectron@circumstances.run 1 hr. ago

@natty @kopper i absolutely think requests (which are weirdly named since they send data themselves) should be forwarded through a web of proxies as determined by the source and that this should cover both routing as well as transport

kopper :colon_three:

@kopper@not-brain.d.on-t.work 4 wk. ago

@natty@astolfo.social I think we can just start with making the kind of filtering you need to prevent it st the application layer easier to do and more prominently documented, before trying to modify the protocols themselves

pancake :butterfly_::neofox_lesbian:

@natty@astolfo.social 4 wk. ago

@kopper@not-brain.d.on-t.work "modify the protocols"

No I mean such things exist, I just haven't had the energy to research them

d@nny disc@

@hipsterelectron@circumstances.run 4 wk. ago

@natty @kopper i have very specific thoughts on protocols but they are kind of unhelpful here because i have been focused on extremely adversarial scenarios

1 more reply

kopper :colon_three:

@kopper@not-brain.d.on-t.work 4 wk. ago

activitypub does a lot of requests with zero in-protocol batching, so http/2 and /3 would actually be helpful if my model of how they work is accurate

in an adjacent point to the ending bit, reverse proxy configuration and cache middleware also share the same deployment concerns and only really result in people refusing to support any reverse proxy and cache not their own (see: bluesky pds scripts hardcoding caddy). the whole web backend deployment model seems outdated the instant you stop dedicating an entire machine for a software. this is why you get dockerfiles that ship their own copy of nginx that your already perfectly competent copy of nginx reverse proxy to

d@nny disc@

@hipsterelectron@circumstances.run 1 hr. ago

@kopper http/3 with quic uses the same mechanism as signal's double ratchet protocol for parallelism but it "can't parallelize headers" because of the separate incredibly fucked up protocol for header compression

Discussion

Discussion