Comment by MattJ100
2 years ago
XMPP supports channel binding, which is not mentioned in this post but would have prevented this attack. Unfortunately jabber.ru is running server software from 2016, and that old version doesn't support it.
Pinning is problematic these days, because certificates are short-lived and renewed frequently. Users would be constantly asked to accept new certificates on a monthly basis, and they wouldn't think twice about clicking 'Accept' on an attacker's certificate then.
Channel binding works regardless of the certificate, and ensures the TLS stream is terminated by the entity you exepect.
The focus on (lack of) CT/SCT support in XMPP clients puzzles me, because it would not have detected this attack at all, which used valid CT-logged certs from Let's Encrypt. SCT verification would help detect theoretical issuance from another CA if they had a strict CAA record in place (they did not). But even then, channel binding is more privacy-friendly and does not depend on a third party.
Pinnig is based on the keypair, not the cert. You can renew and not break pinning, right?
Also you can phase in a new cert with pinning.
Yes, you can pin the public key instead, which is generally more helpful. But most ACME clients (including the "official" certbot) default to rotating the key too. That can be disabled, but it's a problematic default for this use case which means clients can't just enable pinning.
How can it be disabled in certbot?
1 reply →
If you care enough to pin, purchasing actual certificates isn't that hard is it?