XMPP Service Operators - 2021-02-01


  1. tom

    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

  2. tom

    This signature should have been impossible

  3. tom

    Is there anything else I can do

  4. tom

    Or perhaps make the CAA record more strict

  5. tom

    I have absolutely zero bussiness with cisco

  6. tom

    They should NOT be signing certs for my domain

  7. Ge0rG

    tom: 1. download the certificate chain for evidence preservation

  8. Ge0rG

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

  9. Ge0rG

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

  10. Ge0rG

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

  11. pepta.net

    tom: openDNS?

  12. pepta.net

    You should probably disable all these DNS hijacking providers.

  13. tom

    It's a warning about the cert being untrusted

  14. MattJ

    Easily signed for any domain then

  15. tom

    I see

  16. tom

    Would DNSSEC prevent this or can that just be stripped

  17. MattJ

    In theory...

  18. MattJ

    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

  19. MattJ

    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

  20. MattJ

    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

  21. jonas’

    browser and OS vendors

  22. MattJ

    DNSSEC/DANE is a nicer alternative to this

  23. MattJ

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

  24. MattJ

    I'll mark Microsoft as a browser vendor ;)

  25. jonas’

    MattJ, good question, I just checked debian and they just steal mozilla’s

  26. jonas’

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

  27. MattJ

    Yeah

  28. tom

    I use Debian's CA trust

  29. tom

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

  30. tom

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

  31. tom

    » 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.

  32. MattJ

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

  33. MattJ

    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

  34. tom

    Crazy how centralized it is

  35. tom

    But

  36. tom

    Wasn't there something that was supposed to replace this

  37. tom

    Called Convergence or something?

  38. MattJ

    Yeah, I don't know if that went anywhere

  39. MattJ

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

  40. MattJ

    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)

  41. pepta.net

    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.

  42. jonas’

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

  43. jonas’

    assuming DNSSEC on the domain, an entity like OpenDNS or Google cannot do anything

  44. jonas’

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

  45. jonas’

    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

  46. jonas’

    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)

  47. pepta.net

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

  48. jonas’

    (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)

  49. jonas’

    pepta.net, exactly

  50. jonas’

    those are the trust anchors

  51. pepta.net

    Ok so I agree with you. Thanks for info.

  52. tom

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

  53. tom

    Couldn't they just strip the signage information

  54. jonas’

    tom, not with a validating resolver

  55. tom

    I see

  56. tom

    Wait

  57. jonas’

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

  58. tom

    Does windows contain a validating resolver

  59. tom

    Or only openbsd's unwind

  60. jonas’

    I have no idea

  61. tom

    Thankyou for the help

  62. chunk

    That was a most interesting topic