[Operators] IM Observatory @ xmpp.net
xmpp-operators+phil at spodhuis.org
Sun Nov 3 06:27:55 UTC 2013
On 2013-11-01 at 14:01 +0100, Thijs Alkemade wrote:
> 1) Enable cipher with less than 128 bit keys (DES, EXPORT-*, not 3DES,
> which is assumed 168).
> 3) Enable SSLv2.
> We can debate about 4) for a long time, but 1), 2) and 3) have been bad
> practices for at least a decade, some even longer than Jabber exists. I don't
> buy that there is a client out there that doesn't support at least AES or RC4,
> 1024 bit certs or TLS 1.0.
While I fully agree that those suites are too weak to be used, I'm a
little confused about why it's ranking so highly here.
For my clarity of understanding: if SSLv2 is not supported, then the
handshake includes a signed hash across the handshake details,
preventing a downgrade attack, does it not?
So as long as SSLv2 is not allowed and the server private key is long
enough to have a reasonable expected lifetime (avoiding compromise and
more problems than just the attacker's ability to sign a downgrade
attack), surely a server operator can offer suites as weak as they like
and it's only an issue if they configure the server to force its choice,
rather than honouring the client's? It's then the client's
responsibility to not support suites too weak to meet the user's
Thus if a server operator has to continue to support a chat client in an
embedded device which is very dated and underpowered (TV Set top box or
somesuch), they might well choose to support some otherwise dubious
choices, knowing that it can't impact on the more up-to-date clients.
So why does a server offering such ciphersuites cause it to be
downgraded, if they're not forced on normal clients and the server
_does_ (also & preferentially) offer suites which meet current best
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 455 bytes
Desc: not available
More information about the Operators