[Operators] IM Observatory @ xmpp.net

Ludovic BOCQUET lbxmpp at live.com
Sun Nov 3 09:39:06 UTC 2013


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/operators/attachments/20131103/f1daf827/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3736 bytes
Desc: Signature cryptographique S/MIME
URL: <http://mail.jabber.org/pipermail/operators/attachments/20131103/f1daf827/attachment.bin>


More information about the Operators mailing list