[Standards] mutual authentication and XEP 178
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
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards