[Standards] mutual authentication and XEP 178

[Philipp Hancke]

Tony Finch schrieb:
> enough that perhaps the document just assumes it will happen. This has led
> to a bug in ejabberd such that it presents the wrong s2s certificate on
> incoming connections to non-primary domains, and doesn't verify the
> target's certificate on outgoing s2s connections, leaving it open to
> spoofing attacks.

"Ubiquitous TLS on open network"...
let's review the current TLS usage on s2s in "the open network".

I used a xmpp-starttls capable version of openssl's s_client
tool to grab the s2s certificates two sets of servers.
Then I used openssl's verify tool to check the validity of
the certificates obtained. Finally I checked the expected identity.

The first set consisted of the servers from
http://www.xmpp.org.ru/serverlist/?viewdomain=alldomains:
3785 servers listed
  540 hostname unknown
  489 connection timeout
  336 connection refused
1129 servers did not advertise version=1.0 in their stream header (*)
  309 servers did not offer a starttls stream feature
  966 servers presented a certificate

of those 966 certificates,
  489 were self-signed
  111 were signed by an unknown CA
   89 were expired
  277 were considered valid (openssl verify return code 0)

Regarding the identities of those certificates,
  418 had a CN which had nothing to do with the host i wanted
      to connect to. 145 claimed to be "serverimplementation x" (**).
  238 were subdomains not using a wildcard certificate
      (i.e. icq.example using a certificate with subject example.com)
  310 had the expected identity in their certificate

Usable in terms of "considered valid" and "contains expected identity"
were only 166.


The second set were 291 servers listed at xmpp.net.
   5 hostname unknown
  16 connection timeout
  15 connection refused
  90 servers did not advertise version=1.0 in their stream header
  22 servers did not offer a starttls stream feature
142 servers presented a certificate

of those 142 certificates,
  18 were self-signed
  11 were signed by an unknown CA
   3 were expired
  80 were considered valid (openssl verify return code 0)

  50 had a CN which had nothing to do with the host i wanted
      to connect to. 17 claimed to be "serverimplementation x" (**)
   0 were subdomains not using a wildcard certificate - the list
     did not contain any so this is not unexpected
  92 had the expected identity in their certificate.

Usable in terms of "considered valid" and "contains expected identity"
were 62.

If anyone wants to play with the certificate data ping me offlist.

(*) doing non-representative iq-version queries this includes a large
     number of wildfire/openfire - which I found surprising
(**) that server implementation obviously has a serious documentation
      problem, but blaming them here would not lead anywhere