31
Don't Trust, Verify (or: Validating Origin and Integrity without Public CAs) (blog.k3can.us)
submitted 2 months ago by to c/selfhosted@lemmy.world
6 comments fedilink hide all child comments
 

Wanted to share a quick blog post (see link) playing around with a couple methods of validating data origin and integrity without blindly relying on public CAs.

It's sort of a follow-up-to-a-follow-up on an earlier post about using Cloudlfare proxies to selfhost personal sites or services, but it really applies more to TLS and public CAs in general.

you are viewing a single comment's thread
view the rest of the comments
[–] 7 points 2 months ago (2 children)

Could mTLS be used instead to force the browser to validate the correct cert?

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] [S] 5 points 2 months ago* (1 child)

    Not directly, but I believe mTLS would break if the traffic was intercepted/altered, so it sort of works to test the connection.

    mTLS requires installing a certificate on the client device, though. If you're able to do that, then you're also able to pin the correct cert or install a custom CA. This would be the "enterprise" solution, as far as I know, but doesn't work well for public sites, since you can't always configure your end-users devices.

    Edit: mTLS is still very useful, though. I use it to secure some of my services. It just doesn't solve this specific problem.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 4 points 2 months ago

    I'll add: mTLS would only break because the client certs are typically signed by a private CA and the host is configured to only trust that specific CA (similar to the enterprise solution I referenced in the post).

    If, for some reason, the host was configured to trust all of the typical public CAs, then mTLS would theoretically share the same problem.

  • permalink
  • fedilink
  • source
  • parent