XMPP Service Operators - 2021-02-01

someone is signing fake certs trying to mitm my users. I have already deployed CAA so https://cdn.nuegia.net/ef1847ca-08a5-460b-86f2-37c6f6185253/3693708094_20210201_113722.jpg

This signature should have been impossible

Is there anything else I can do

Or perhaps make the CAA record more strict

I have absolutely zero bussiness with cisco

They should NOT be signing certs for my domain

tom: 1. download the certificate chain for evidence preservation

tom: is that certificate chain rooted with a trusted root CA, or is there a warning about it being untrusted?

tom: is the report from a user behind a corporate firewall?

Anybody can create a certificate claiming to be Cisco, and I can imagine a "TLS inspection firewall" to behave in this way

tom: openDNS?

You should probably disable all these DNS hijacking providers.

It's a warning about the cert being untrusted

Easily signed for any domain then

I see

Would DNSSEC prevent this or can that just be stripped

In theory...

DNSSEC aside, the (fragile) CA ecosystem basically involves a set of trusted CAs promising that they will only issue signed certificates to the domain owners

Anyone can set up a "CA" and issue certificates for any domain they like, but browsers/software will alert for certificates from any CA that they aren't preconfigured to trust

Who is trustworthy is decided by the browser vendors, and the list of people who can issue legitimate certs for any domain is pretty long and includes a bunch of people you probably wouldn't want to trust yourself

browser and OS vendors

DNSSEC/DANE is a nicer alternative to this

jonas’, does any OS vendor manage their own trust anchors, rather than depending on Mozilla to make those decisions?

I'll mark Microsoft as a browser vendor ;)

MattJ, good question, I just checked debian and they just steal the one from mozilla ✏

Yeah

I use Debian's CA trust

https://packages.debian.org/sid/ca-certificates

Is there any CA's that I probably shouldn't trust in there your talking about MattJ?

» Please note that Debian can neither confirm nor deny whether the certificate authorities whose certificates are included in this package have in any way been audited for trustworthiness or RFC 3647 compliance. Full responsibility to assess them belongs to the local system administrator.

I'm a stranger on the internet, don't trust me ;)

Seriously, I don't know... I tend to deselect some random ones, 80% of everything is on just a few roots anyway now due to Let's Encrypt

Crazy how centralized it is

But

Wasn't there something that was supposed to replace this

Called Convergence or something?

Yeah, I don't know if that went anywhere

I think Certificate Transparency logging may have come from that direction though

so audited CAs are supposed to publicly announce all certificates they sign (and as a domain owner you can theoretically use this to ensure nobody is issuing certificates for your domain without your knowledge)

If you rely on any DNS based solution like DNSSEC/DANE, but the client (or you) uses a DNS hijacking providers, this won't be of any use, as any param could be changed by the DNS provider itself.

pepta.net, you have to distinguish different layers of DNS here

assuming DNSSEC on the domain, an entity like OpenDNS or Google cannot do anything to hijack something ✏

because there is a chain of verification from the root zone down to your records which cannot be broken by a man in the middle

your DNS service provider (i.e. the entity which publishes the DNS records of *your* zone) however can of course do some hijacking, same for the parent zones of your zone (i.e. if you have foo.example.com, then example.com., com., and the root zone could do nasty things to you)

So you mean root zone cert is not returned by DNS request but preloaded by soft?

(but the attacks get much more tricky and much more obvious the farther up in the chain you are, hence being the root zone is not really helpful to attack foo.example.com., as you’d also have to forge a plausible com. zone for that)

pepta.net, exactly

those are the trust anchors

Ok so I agree with you. Thanks for info.

So cisco could not send hijacked replies for my domain if i used dnssec

Couldn't they just strip the signage information

tom, not with a validating resolver

I see

Wait

the validating reolver would see the DS records from your parent zone and know that your zone publishes signatures

Does windows contain a validating resolver

Or only openbsd's unwind

I have no idea

Thankyou for the help

That was a most interesting topic