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
