On Wed, Nov 13, 2013 at 1:27 PM, Thijs Alkemade <[email protected]> wrote:
> > On 13 nov. 2013, at 12:56, Dave Cridland <[email protected]> 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. > > Right. There are some interesting cases where you might deliberately and legitimately have multiple certificates with the same private key, in particular where hardware crypto is involved. > 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 > > Ouch. I think we should recommend strongly somewhere that XMPP implementations do not ship with a default key. To state the obvious, this means that any TLS channel not using PFS on these default keys is decryptable; the private key is, in effect, compromised. > Thijs
