On 13 nov. 2013, at 12:56, Dave Cridland d...@cridland.net wrote:
Then there's the same-cert shortcut, where the receiver connects to the
authoritative server and compares certs. This is an interesting case, because
we're deriving identity (and therefore authenticating) from the certificate,
but the certificate isn't sufficient to authorize - so we dialback to the
authoritative server and if the certificate matches, this is sufficient
authorization.
What we're now debating is whether we need a trusted identity in same-cert,
or whether a self-signed certificate is sufficient. We need to be assured
that the identity is unique - that is, that the private key is known only to
the authorized party, basically, and I'm personally concerned that there
could be cases of TLS and/or XMPP implementations shipping with a sample
certificate then used in production.
What do people think?
Dave.
I’ve added a table to the xmpp.net stats page showing which domains share a
public key:
https://xmpp.net/reports.php#sharesprivatekeys
It checks the SPKI field, so the certificates may be different but the public
key on them is the same.
Of course many are harmless false positives, there might be good reasons why
two domains share a key. But those of note are:
Prosody's default key:
F7:D9:2E:68:43:43:A9:EA:2E:BE:5F:FA:4B:B7:B9:25:EC:3C:03:5B:85:B5:C4:38:48:0E:8A:9A:71:66:E6:E6
Ejabberd's default key:
C5:78:17:B1:34:90:54:D0:5A:16:A4:C6:71:80:6D:C3:F8:8B:F1:31:3D:64:BD:42:8F:1F:C5:D9:21:EB:99:BE
Thijs
