capivarinha-s3.s3.de.io.cloud.ovh.net serving 403s to Bridgy Fed for images

[derspyy]

At first I thought this may've been a limitation, but I've seen posts from Gargron with images being shared from Mastodon.social to Bluesky.

I'm the admin for capivarinha.club and I've noticed that images don't go through :/

I have a S3 bucket setup on my instance, but it seems like a regular practice, so I'm stumped!

Example:

https://capivarinha.club/notes/9ypqwkyqfgw30mau

https://bsky.app/profile/Agatha.capivarinha.club.ap.brid.gy/post/3l57rhsogdph2

[derspyy]

we also don't seem to be getting images from bluesky on AP, but i couldn't figure out if it worked in other instances

[snarfed]

Hi! Your server seems unhappy, https://capivarinha.club/ is failing to connect over SSL and http://capivarinha.club/ (no https) is serving a "Malware and Phishing" error page.

[derspyy]

uuuuhh what's the bridgy fed UA and ip addresses? may be caught up on some bot protection...

[snarfed]

That was me in my browser at a coffee shop, probably on Comcast Business. So, typical end user IP, headers, etc.

[snarfed]

It's loading ok for me now at home. 🤷

[snarfed]

Ah, the issue here is, that image is a webp, which Bluesky supposedly doesn't support.

...however, they actually do seem to support it, at least sometimes, even though they claim they don't. I've asked about this in bluesky-social/atproto#2845

[snarfed]

As for the other direction not working, that's #1000 (comment) . Misskey/Sharkey evidently can't handle one bit of (valid) AS2 that Bridgy Fed sometimes sends, image values that are bare string URLs. I may eventually try to tweak that format to make the *keys accept it.

[derspyy]

Ah, the issue here is, that image is a webp, which Bluesky supposedly doesn't support.

...however, they actually do seem to support it, at least sometimes, even though they claim they don't. I've asked about this in bluesky-social/atproto#2845

oh wow! do they JUST accept jpeg and png? users on sharkey CAN disable webp encoding but it raises the storage costs a bit and may be annoying to ask people to enable...

[snarfed]

Sorry, no, I take it back, they only claim to not accept webps for profile images. (And they actually do, details in that link, but that's a separate question.)

Looking at Bridgy Fed's logs, the issue was that Bridgy Fed got an HTTP 403 error when it tried to fetch https://capivarinha-s3.s3.de.io.cloud.ovh.net//a982f2eb-ef42-4f02-be02-c0a0ad7f1586.webp, 2024-09-28 13:22:02 UTC.

[derspyy]

wow, is it happening with other media running under ovh domains?

[snarfed]

Bridgy's User-Agent is Bridgy Fed (https://fed.brid.gy/). Info on its IPs here, the Google Cloud link: https://support.google.com/a/answer/10026322

[snarfed]

wow, is it happening with other media running under ovh domains?

good question, I don't know yet.

[snarfed]

Searching logs, this is the only URL that BF has fetched in the last 30d on a cloud.ovh.net subdomain.

Scratch that, searched wrong. I'll check out the others and report back.

[derspyy]

ok! be sure to tell me if there's anything you need me to test in the instance. also gave some insight on the other issue as well.

[snarfed]

OK, it's been fetching from a nmber of other cloud.ovh.net subdomains, but over the last 30d, capivarinha-s3.s3.de.io.cloud.ovh.net is the only one that's been returning 403s.

Those image fetches evidently redirect to URLs on obj.04.si. We're fetching other things successfully from obj.04.si and other subdomains, notably misskey.04.si.

[derspyy]

could it be some kind of blacklisting? uceprotectl3 lists the ip for my s3 bucket as malicious (not the same IP as other buckets because of the various server options)

though i don't think 403 would be the proper response

[snarfed]

Honestly I couldn't tell you. The double // in the path seems odd, but probably not the problem, since it's serving ok elsewhere. The obj.04.si dynamic DNS hostname is also unusual, I wonder if that's part of the problem, but I don't know.

[snarfed]

In case it helps, here's the 403 response body:

<?xml version='1.0' encoding='UTF-8'?>
<Error><Code>AccessDenied</Code><Message>Access Denied.</Message><RequestId>tx68e1dc2752a04be58e8b0-0066f802fb</RequestId></Error>

[derspyy]

i'll ask ovh directly!

[derspyy]

ok, their support system is super buggy and is taking a while... although i've noticed that our images are handled normally by other instances

[qazmlp]

This may be an OVH CDN issue. Castopod had regular problems with them (though I don't know the details): https://podlibre.social/@Castopod/113222566494909053

[derspyy]

oh, yeah: https://public-cloud.status-ovhcloud.com/incidents/bqp22gdvcd31

[snarfed]

@derspyy sounds like there may not be anything here for Bridgy Fed specifically to do, so I'm tentatively closing. Feel free to reopen if you disagree!

[derspyy]

agreed! i'll update when ovh closes their issue. thx for the attention 💜

[derspyy]

i read this

Because it is sometimes a bug, and a security bug, defensively designed server stacks and firewalls will assume the substring '//', in any incoming request is a possible attempt to exploit a bug, and therefore they will block it by returning 403 Forbidden, 404 Not Found, or 400 Bad Request - without ever actually further processing the URI or request.

(referring to a traversal attack)

i changed the links to swap the // to /sharkey/ and it seems like it works now : ) maybe good to note ??

source: https://stackoverflow.com/questions/10161177/url-with-multiple-forward-slashes-does-it-break-anything

[snarfed]

Aha, good find!