~emersion/soju#69: 
Ident protocol support

The ident protocol allows an upstream IRC server to correctly kill connections of a specific user, as opposed to all bouncer connections.

Possible solutions:

  1. Do like ZNC, write ident info to a file which can be read by an identd. This works file for a few users, but won't scale.
  2. Implement an ident server. If multiple services need an identd, it should be possible to add an ident demultiplexer forwarding requests to multiple identd servers.

Should we send the username? Or should we send an opaque token instead?

Status
RESOLVED FIXED
Submitter
~emersion
Assigned to
No-one
Submitted
5 months ago
Updated
3 months ago
Labels
enhancement

~emersion referenced this from #23 5 months ago

~emersion 4 months ago

There's also kiwiirc/identd which has an RPC.

~emersion 4 months ago

There is a guarantee that the ident remote address will be the one we connected to, so we can check that (at least according to a comment in the ircd-seven source code).

An unfortunate fact is that ident queries are performed by ircds as soon as the client connects, even if registration hasn't completed yet 1. So doing net.Dial and then storing the local/remote addresses is racy (and the race happens in practice, probably due to the TLS handshake taking some time to complete).

There are essentially two ways to fix the race:

  1. Pick the local and remote addresses prior to connecting. This has essentially two issues:
  • After we pick a local port but before we actually bind to it, another process can bind to the port.
  • A hostname may map to multiple IP addresses. The Go stdlib may try to connect to any of these, sometimes in parallel (e.g. in dual IPv4/IPv6 configurations). Picking the remote address prior to dialing forces a single IP address.
  1. In the identd server, if the remote/local address tuple is unknown, wait for a bit (with a timeout) to see whether we've just connected to it.
  • This prevents the use of a third-party identd.

~emersion 4 months ago

(2) also has the downside of potentially keeping identd connections alive more than necessary, and having to start a timer for each of these connections. Given that identd is an open-bar server, this is annoying.

For now I've just delayed the TLS handshake and that seems to be good enough.

~emersion 4 months ago

Considered doing per-network ident tokens to enhance privacy, but I'm worried about the abuse potential. It would be possible for a banned user to bypass the ban by specifying an alternative network address (e.g. by connecting via plain-text instead of TLS, or by connecting to an IP address instead of a domain name, etc).

Per-user ident tokens are probably good enough.

~emersion REPORTED FIXED 3 months ago

Done in 65302d3c1e8e990080e5309ad7a9f6fef43aa685.

Register here or Log in to comment, or comment via email.