[Operators] How-to fight with SPAM accounts

[Dave Cridland]

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
> jabber.org.

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  
> developers
> ignored possible interactions.
> 
> 
Does it really need official specification? What would such  
specification say?

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  
concrete examples.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade