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:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
