Don't Trust, Verify (or: Validating Origin and Integrity without Public CAs)
(blog.k3can.us)
from K3can@lemmy.radio to selfhosted@lemmy.world on 18 Aug 11:05
https://lemmy.radio/post/14840316
from K3can@lemmy.radio to selfhosted@lemmy.world on 18 Aug 11:05
https://lemmy.radio/post/14840316
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.
threaded - newest
Could mTLS be used instead to force the browser to validate the correct cert?
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.
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.
If there’s a concern that an adversary can rewrite hashes then why is there not a concern the public key could also be rewritten and the hashes signed with the fake key?
There is.