Little note, Microsoft Windows XP and Windows Server 2003 support TLS 1.0 with ciphers:
* TLS_RSA_WITH_RC4_128_MD5 * TLS_RSA_WITH_RC4_128_SHA * TLS_RSA_WITH_3DES_EDE_CBC_SHA * TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA * TLS_RSA_WITH_DES_CBC_SHA * TLS_DHE_DSS_WITH_DES_CBC_SHA * TLS_RSA_EXPORT1024_WITH_RC4_56_SHA * TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA * TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA * TLS_RSA_EXPORT_WITH_RC4_40_MD5 * TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * TLS_RSA_WITH_NULL_MD5 * TLS_RSA_WITH_NULL_SHA Source: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=vs.85%29.aspx - Windows Vista and Windows Server 2008 on: http://msdn.microsoft.com/en-us/library/windows/desktop/ff468651%28v=vs.85%29.aspx - Windows 7, Windows Server 2008 R2 and more on: http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx We can do housework :) BOCQUET Ludovic An XSF member XMPP Standards Foundation http://xmpp.org/ Le 03/11/2013 07:27, Phil Pennock a écrit : > 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
smime.p7s
Description: Signature cryptographique S/MIME
