Hacker News new | ask | show | jobs
by zrm 135 days ago
The second one doesn't seem excessively complicated and the latency could be mitigated by caching the CA for a reasonable period of time.

But if you're going to modify the protocol anyway then why not just put it in the protocol that a "server" certificate is to be trusted even if the peer server is initiating rather than accepting the connection? That's effectively what you would be doing by trusting the "server" certificate to authenticate the chain of trust for a "client" certificate anyway.
1 comments
account42 135 days ago
The complication of (2) is that it requires a server with a completely different protocol and port, that may or may not already be claimed by another server software than the XMPP server, to act in a specific way (e.g. use a compatible certificate).

The technical term for such cross-service requirements is "a giant pain in the ass".

link
zrm 134 days ago
That's assuming you're requiring the ordinary HTTPS port to be used. For that matter, why would it even need to use HTTPS? Have the peer make a TLS connection to the XMPP server to get the CA.

But it still seems like the premise is wrong. The protocol is server-to-server and the legacy concept that one of them is the "client" and needs a "client certificate" is inapplicable, so why shouldn't the protocol just specify that both peers are expected to present a "server certificate" regardless of which one initiated the connection?

link