[Standards] mutual authentication and XEP 178

Peter Saint-Andre stpeter at jabber.org
Mon Jul 30 16:05:20 UTC 2007

Philipp Hancke wrote:
> 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".

It seems we still have quite a bit of work to do...

Do you have any standards-related recommendations for improving the
situtation? If so, then let's discuss them on this list. If not, let's
discuss those on a more relevant list, such as Jadmin or xmppnet:


(I will forward my reply to the xmppnet list.)

> 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 second set were 291 servers listed at xmpp.net.

BTW, the servers listed at xmpp.net have not necessarily obtained a
certificate through the XMPP ICA. There is a two-step process:

1. Obtain an account at xmpp.net. This enables you to list your server
at xmpp.net and to request a certificate via the ICA, but neither step
is required once your account is approved.

2. Obtain a certificate via the ICA.

>   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

Clearly it would be beneficial for those involved with xmpp.net to check
the servers listed there on a regular basis to ensure cleaner data in
the server list. Probably we should also require servers to support XMPP
1.0 (duh) and potentially also to obtain and use a certificate from the
ICA within a certain period of time. This would make the xmpp.net server
list more meaningful.

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

Please note that the ICA checks the CN before issuing a certificate. So
I expect that the 17 certificates with a CN of "serverimplementation x"
were from the self-signed certificate category, not the certificates
issued by the ICA.

>   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



Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070730/ab4b0321/attachment.bin>

More information about the Standards mailing list