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 requirements. 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 practices? -Phil
pgpBi2KrXKnnm.pgp
Description: PGP signature
