Subject: Re: [Uta] On prohibiting RC4

From: "Joe St Sauver" <[email-masked]>
Date: Fri, 7 Mar 2014 13:14:49 -0800 (PST)

Hi,

Franck commented:

#I think the problem is in ciphersuite selection, it is the client that propose
#a list of ciphers and the server that picks the one it likes. The whole
#selection process seems not standardized or with little control settings. 

Well, the process is negotiated... servers can vary tremendously in terms of
the preferences they express, and clients can vary tremendously in terms of
what they support. The result can be a bit of a stew.

For web servers, I'm a huge fan of the Handshake Simulation that's part of 
the output of https://www.ssllabs.com/ssltest/index.html -- you can see
what you'll typically get for a given client connecting to a given
server -- but obviously that's for web servers. 

For the SMTP case, https://starttls.info/ provides at least broad 
information (key size, weakest/strongest accepted cipher)

http://www.checktls.com/index.html is another interesting tool that some
folks have mentioned to me (I haven't worked with it much personally to-date)

For *web browsers*, client test suites such as
https://www.ssllabs.com/ssltest/viewMyClient.html do a nice job of exposing
the cipher suites preferences expressed by the browser (ditto
https://cc.dcsec.uni-hannover.de/ )

I'm not aware of a good client test page for MUA SSL/TLS support (that may
partially be a function of issues around keeping POP/IMAP clients from
promiscuously sharing credentials with third party testing pages).

#What the string should be? How hard is it to manage this string and keep it up
#to date? Can this work group (or the TLS one) provide some regular advice? 

The Applied Crypto Hardening Project is a nice resource for folks who 
just want to get a recommended configuration string for various products:
https://bettercrypto.org/static/applied-crypto-hardening.pdf

Regards,

Joe

Disclaimer: all opinions my own