[Operators] How-to fight with SPAM accounts
fippo at goodadvice.pages.de
Sat Nov 21 09:41:29 CST 2009
Dave Cridland wrote:
> On Sat Nov 21 12:07:33 2009, Philipp Hancke wrote:
>> Peter Saint-Andre wrote:
>>> As I always say, we don't need to be perfect, just more difficult to
>>> attack than other networks. Part of raising the cost (mostly the cost in
>>> time) would involve requiring TLS with CA-issued certificates for s2s
>>> (perhaps we can get there eventually!). But as you say there is no magic
>> If getting there was possible, why is that solution not applied to SMTP?
>> Besides, the TLS situation on s2s is a huge mess... and will continue to
>> be so while you accept "bogus certificates" (as defined below) at
> That really depends on what you mean by "accept".
Accepts connections from servers that use such certificates. Since SASL
EXTERNAL does not apply to those connections, dialback is used to verify
them. The question is whether that is a good thing, because it hides
problems instead of solving them.
>> The problem is mostly limited to what is called "starttls+dialback".
>> Since that had never been officially specified, it seems that developers
>> ignored possible interactions.
> Does it really need official specification? What would such
> specification say?
If a dialback request is received after starttls, what is supposed to
happen? Do you ignore the certificate? Do you reject the connection?
RFC 3920 advised the latter (section 14, automated client), -bis
seems to advocate the former (220.127.116.11.1 sub-case #3).
> The only interesting case is where you can do a certificate match and
> elide the actual db:verify, but that's an optimization rather than
> anything particularly exciting.
It is an example of an interaction between dialback and TLS that makes
>> Definition of a bogus certificate:
>> * subject does contain the hostname (especially: CN=ejabberd)
oops... there is a "not" missing.
> No, no. That one is *fine*, assuming that a subject alternative name
> contains the jid. There are also several cases of CA issued certificates
> which do not cover certain jids, particular component and service
> domains, in which case the logical thing to do is fallback to another
> form of authentication, or disconnect if there are no other acceptable
The certificates I meant only contained only a CN - no id-on-xmppAddr or
dnsname extensions. And that CN was not set to the sender domain used in
>> * subject is valid but certificate is expired - even expired since
>> January 2009.
> Mine's expired some time ago. The result I expect to see is that it's no
> longer offered SASL EXTERNAL, which, indeed, it isn't. Are you
That is what I see also. I've also seen a few cases where the remote
server actually tried to enforce EXTERNAL and rejected the connection.
> suggesting that until I get around to fixing it, I should use a
> self-signed certificate, or one from my private CA?
Your server (and mine, too) is misconfigured. We might not even notice
that because everything seems to work normally and nobody complains.
If the same happened with our HTTP servers, we would fix that ASAP,
because that is less work than answering all those "my browser
shows a warning when connecting to your server" questions.
>> * certificate is revoked (that even worked with 0178 style auth when
>> I tested it)
> Revocation is a particularly interesting case, yes. In this case, one
> could take the view that use of the certificate is actively prohibited.
> I'm not 100% convinced one couldn't - again - fall back to other trusted
> forms of authentication, though.
>> * ...
>> Note that I did not include self-signed certificates or certificates
>> issued by a CA which is not well-known. Those are probably better
>> handled in a ssh-like approach.
> Leap of faith? The problem then comes on change - it'd mean a manual
> intervention once a year per foreign domain using a self-signed
> certificate. Or, alternately, one could use leap-of-faith to elide the
> dialback entirely, until it failed to match. However, since all the
> attributes of the certificate are in this case asserted and validated by
> the certificate owner themselves, it's deeply unclear to me why those
> attributes should be trusted at all, so this scenario appears, to me, to
> encompass all the above.
I would probably implement that in a way such that accepting the
certificate requires a manual interaction by the server admin - which
just shifts responsibility to the human element ;-)
Dialback or "ask my trusted peer servers" might be other
>> Just another piece of "not really relevant" criticism.
> It's not actually clear if you're complaining that X.509 authentication
> is not always used, or that it's used erroneously.
> In the former case, you're quite correct, but short of managing to issue
> everyone with a certificate, I don't see how that can work. In my case,
> for example, since I use a subdomain of my brother's domain, it requires
> a logistically complicated trust chain in order to validate my domain
> with StartCom.
I doubt that requiring a certificate will ever work for such reasons.
The main problem is keeping "open federation" while maximizing security.
By taking those "bogus" certificates out of the equation, we could
increase the number of cases where x509 authentication is used
in a meaningful way.
More information about the Operators