[Bu9818]

>affected 100% of the connections to XMPP STARTTLS port 5222 (not 5223)

Why did they only target the STARTTLS port? On a related note, I would never use the STARTTLS port (opportunistic encryption) if I knew that the server had a regular TLS port...

[upofadown]

>I would never use the STARTTLS port (opportunistic encryption) if I knew that the server had a regular TLS port...

That is what XMPP clients tend to do...

These days XMPP servers tend to default to requiring TLS on both 5222 and 5223 (Let's Encrypt has changed everything). Prosody does this for example. It doesn't even support port 5223 by default anymore. Port 5223 was never an official port assignment.

So it is very possible that the MiTM was only done on port 5222 because that was the only port that clients were using.

[KirillPanov]

Easier to conceal the attack.

The MiTM attacker can pass through a command stream without STARTTLS. If they intercepted 5223 they would have to do their own client-side TLS handshake with the attacked server, which would look really obvious to anybody doing TLS fingerprinting on the server: all of a sudden, 100% of their clients have the exact same TLS fingerprint.

Stop outsourcing your PKI to ICANN, folks. Domains are not public keys.

[MattJ100]

They were doing their own TLS handshake - that's how the attack was discovered (the attacker presented a different certicate, which eventually expired, presumably due to negligence). They were decrypting and re-encrypting.

[KirillPanov]

Read it again:

> they would have to do their own client-side TLS handshake

By intercepting the STARTTLS port the attacker can merely decrypt -- rather than, as you wrote, decrypting and re-encrypting.

[fuzzy2]

This is not what the attackers did however. From the original article (not this one):

> Traffic dump on port 5222, the connection is hijacked on application level (L7), the server receives replaced ClientHello message from the client.

[MattJ100]

I don't know what jabber.ru's policy is, it's running a very old version of ejabberd. But you would be hard-pressed to find an XMPP server that would allow authentication without TLS. Starttls makes no difference.

[octacat]

It is pretty simple. 5223 port is called "legacy SSL". So, because it is legacy, clients would, by default, use 5222 + starttls. I.e. majority of clients connect with 5222.

Also, I've never understood why they've moved 5223 (regular TLS) into deprecated. It was pretty useful to enable SSL on AWS ELB on this port. Which is not possible with 5222, because it does XML stuff before switching to TLS.

I would speculate it is to not keep 2 ports open or something, was a reason to move it to deprecated. + you can do some cleartext communication before switching to TLS (not like it is that useful).