Open samsiegart opened 1 year ago
We've been seeing this issue more frequently now reported by several users. Personally I find that refreshing over and over does not get around the error anymore.
It might be something to do with the ISP, but difficult to track down the root cause. Potential course of action could be to inquire with cloudflare, or look into other ipfs hosting methods such as fleek.co or https://www.pinata.cloud/
I got a clean trace.
the error is SSL_R_WRONG_VERSION_NUMBER: 247 triggered from https://github.com/google/boringssl/blob/b6e0eba6e62333652290514e51b75b966b27b27c/ssl/tls_record.cc#L231C28-L231C54
The relevant parts of the trace:
I am strongly suspecting this is some "ISP protection system" blocking the request. In the case of XFinity, their "advanced protection" system is notorious for being whimsical in its blocking attempts. It would be interesting to see if this issue reproduces with such systems disabled.
I would also love to get a dump of the handshake response seen by Chrome as erroneous.
It might be possible to capture with Wireshark, or simply through curl
(if it gets blocked/intercepted):
curl --trace - --no-progress-meter -o /dev/null https://bafybeigd3ovwhyteh4ny3avvr32ok5zdxilngoz46vnsxtadfqaxtnuw44.ipfs.cf-ipfs.com/
If this is indeed a content filtering system causing issues, I'm not sure what solution is while keeping IPFS hosting.
Seems like safebrowse, which apparently my ISP (xfinity) uses, is blocking cf-ipfs and other gateways (see screenshots below). For me, the only gateways that work that support origin
are dweb.link and nftstorage.link (which seems to redirect to dweb when I try to access the dapp-inter hash). I've had mixed results with dweb.link, sometimes it times out and isn't able to load the dapp, even though it can ping the TLD successfully.
I don't see a good way to get around this. If we simply ping each gateway before redirecting, it could be the case that they don't have the app bundle readily available and the app doesn't load. If we try and load the whole app, maybe just loading the bundle directly from the jumper page to be more sure, requesting from multiple gateways concurrently, it would result in a lot of large requests at once, and there's no guarantee any of them would work as described above.
Apparently this safebrowse thing is able to be turned off through my xfinity settings, which I could try doing, but I'm not sure it's reasonable to expect/instruct users to turn that off. Hopefully cloudflare can take this up with the ISP and get it fixed long term. We have an ongoing support ticket with them and have updated it with this info, currently pending their next response.
When going to app.inter.trade, it redirects to the cf-ipfs URL but the page fails to load. Refreshing a few times seems to fix it. This only happens occasionally.