Recurring TLS / ISP blocking on `t3.storage.dev`: what is the supported long-term endpoint for browser/public traffic?

1

We are seeing the same recurring issue with t3.storage.dev again.

Symptoms:

  • requests to https://t3.storage.dev fail from some residential / ISP networks
  • browsers show ERR_SSL_PROTOCOL_ERROR
  • botocore / SDKs fail with TLS / SSL validation errors
  • switching the exact same workload to https://fly.storage.tigris.dev makes it work immediately

This does not look like an app bug. It looks like t3.storage.dev is intermittently getting blocked / intercepted on some network paths.

Related threads:

From the outside this seems to be a known recurring issue, not an isolated report.

Questions:
2. If t3.storage.dev is still recommended, what is the mitigation when ISPs / security vendors block or intercept it?
3. Should users proactively migrate away from t3.storage.dev for end-user traffic?
4. Can Fly/Tigris update the docs with a clear decision table:

  • Fly app to Tigris
  • public browser downloads
  • presigned URLs
  • custom domains
  • non-Fly backends

Right now the safest operational move seems to be “use fly.storage.tigris.dev or a custom domain when t3.storage.dev is blocked”, but it would help to have an official long-term recommendation.

2

Apologies for the issue you are facing. We are looking into what a good long term solution would be for serving public buckets.

In the meantime I would recommend using a custom domain and putting your public buckets behind that.

3

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

5

Thanks for your report. We have a new domain for public content, t3.tigrisfiles.io, as well as two additional domains for quick failover.

When you create a new public bucket without a custom domain:

// Tigris CLI
tigris bucket create my-public-bucket --public

// flyctl
fly storage create \
  --name my-public-bucket \
  --public

// AWS CLI
aws s3api create-bucket \
  --endpoint-url https://t3.storage.dev \
  --bucket my-public-site \
  --acl public-read

your content is available immediately at https://my-public-site.t3.tigrisfiles.io/. You can later set a custom domain.

For public content, we recommend using a custom domain. CNAME records should point to t3.tigrisbucket.io, e.g. foo-bucket.t3.tigrisbucket.io, for new custom domains. If you have an existing custom domain for your public bucket, it will continue to work as before.

In case there are any issues with any domain, we provide two additional domains for failover:

  • t3.tigrisbucket.io
  • t3.tigrisblob.io

More details are in this topic: Introducing t3.tigrisfiles.io for public content

And even more details in the announcement: Introducing t3.tigrisfiles.io for public content | Tigris Object Storage