This doesn't make sense in a world where post-registration SASL is
allowed, and should fix one case of an annoying login desync that's seen
in the real world.
Specifically, when a client sends its final AUTHENTICATE and Atheme
receives it, it sends an SVSLOGIN for that client. If the client sends
us its CAP END *before* we see the SVSLOGIN, the implicit abort will try
to abort the SASL session that's already succeeded.
Atheme interprets this as an instruction to forget about the successful
SASL session; you'll connect unidentified. But it's already sent
SVSLOGIN, which will log the client in ircd-side, causing ircd and
services views to differ until the user authenticates again manually.
I think allowing a SASL session to be aborted when it has already
succeeded is an Atheme bug, and it can still be triggered without this
change. But our behaviour here seems silly anyway.
Further to our implementation of the concept of "secure origins", we can
indicate to services that the client is connected securely, rather than
just that the client is using TLS. For example, connections from the
local host (from the IRCd's perspective) can be considered secure
against eavesdropping.
Allow this to factor into services' decision on whether to allow an SASL
negotiation or not. Atheme currently assumes this means the client is
using TLS, but I have changed that in atheme/atheme@412d50103c
When a server disconnects the client_exit hook will only be called once
but there could be multiple servers and clients behind that server.
After any client exits, check if the agent is still present.
When a server disconnects the client_exit hook will only be called once
but there could be multiple servers and clients behind that server.
After any client exits, check if the agent is still present.
Otherwise we'd send the * on to services as actual data, which is likely
to fail to decode it (it's not valid Base-64) and reply with an SASL ...
D F which will result in us sending a 904 numeric instead of a 906.
cf. https://github.com/ircv3/ircv3-specifications/pull/298#issuecomment-271336287
Reported-By: James Wheare
Otherwise we'd send the * on to services as actual data, which is likely
to fail to decode it (it's not valid Base-64) and reply with an SASL ...
D F which will result in us sending a 904 numeric instead of a 906.
cf. https://github.com/ircv3/ircv3-specifications/pull/298#issuecomment-271336287
Reported-By: James Wheare
This is a FIX FOR A SECURITY VULNERABILITY. All Charybdis users must
apply this fix if you support SASL on your servers, or unload m_sasl.so
in the meantime.
This is a FIX FOR A SECURITY VULNERABILITY. All Charybdis users must
apply this fix if you support SASL on your servers, or unload m_sasl.so
in the meantime.
Also fix up some return values and stuff to use bool (or void if
nothing). I just did it whilst I was here.
According to jilles, the return value used to signify whether or not the
client had exited. This was error-prone and was fixed a long, long time
ago, but the return value was left int for historical reasons.
Since the return type is not used (and has no clear use case anyway),
it's safe to just get rid of it.
This allows multiple improvements to m_sasl. With this change, the SASL
authentication gets aborted immediately when services are offline.
Additionally, we send the SASL ENCAP messages directly to the specified
SASL agent.
