[Operators] How-to fight with SPAM accounts
dave at cridland.net
Sat Nov 21 06:27:29 CST 2009
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
>> attack than other networks. Part of raising the cost (mostly the
>> cost in
>> time) would involve requiring TLS with CA-issued certificates for
>> (perhaps we can get there eventually!). But as you say there is no
> If getting there was possible, why is that solution not applied to
> 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".
> The problem is mostly limited to what is called "starttls+dialback".
> Since that had never been officially specified, it seems that
> ignored possible interactions.
Does it really need official specification? What would such
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.
> Definition of a bogus certificate:
> * subject does contain the hostname (especially: CN=ejabberd)
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 forms.
> * 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
suggesting that until I get around to fixing it, I should use a
self-signed certificate, or one from my private CA?
> * 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.
> 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. In the latter case, I'd like to see
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Operators