Hi, as some of you might know Philipp has been working hard on adding TLS support to libshout, and a few other things. Originally we were planning to publish a beta or snapshot today, but we didn't manage to agree on a openssl client side cipher list yet. If anyone happens to know about proven secure settings, just like the Mozilla labs settings for server side, please let us know. We want to have secure and future proof defaults that will work with the current Icecast server cipher list and maybe also the one we used previously. We hope to have something sorted out within a week. Cheers Thomas PS: cc'ing mixxx-dev as requested by Philipp.
On 19/04/15 08:15 PM, "Thomas B. R?cker" wrote:> If anyone happens to know about proven secure settings, just like the > Mozilla labs settings for server side, please let us know.You mean like https://wiki.mozilla.org/Security/Server_Side_TLS ? -r
On 04/20/2015 05:47 AM, Ralph Giles wrote:> On 19/04/15 08:15 PM, "Thomas B. R?cker" wrote: > >> If anyone happens to know about proven secure settings, just like the >> Mozilla labs settings for server side, please let us know. > You mean like https://wiki.mozilla.org/Security/Server_Side_TLS ?Yes, that's what we used for the Icecast server default cipher list, now if Mozilla has that for the *client* side, that would be interesting. I looked around but didn't see it. There seem to be subtle differences of what makes sense and what needs to be configured, when compared to a server. TBR
reflum, On Sun, 2015-04-19 at 20:15 +0000, "Thomas B. R?cker" wrote:> Hi, > > as some of you might know Philipp has been working hard on adding TLS > support to libshout, and a few other things. > > Originally we were planning to publish a beta or snapshot today, but we > didn't manage to agree on a openssl client side cipher list yet. > If anyone happens to know about proven secure settings, just like the > Mozilla labs settings for server side, please let us know. We want to > have secure and future proof defaults that will work with the current > Icecast server cipher list and maybe also the one we used previously. > > We hope to have something sorted out within a week.Here is what wasn't heard last week: Some general words first: * Ciphers are symmetric in the sense that both parties need to agree on them. Both provide a list, both reject some they don't support or don't want to use. * Lists need at least one matching set. They should have more than a single one to ensure there are no future problems by one rejecting the only matching one. * Each party is responsible to provide only ciphers that are suitable for the kind of data they send. No party is responsible to do a sensible choice for what the other party sends. See those simple examples: 0) A server asking a client for a very secure channel to protect what the client is sending isn't very useful. The client could send the information to some random other location anyway. 1) A server may only send public documents but want to provide prove of identity. A 'no encryption' mode maybe selected by the server. This is very valid. In this example the client want to provide personal information when accessing the information (which may or may not be required by the server). The client want this information well encrypted and will require strong encryption. * ciphers that are broken or considered weak should be considered the same as no encryption when designing new components. A bit more specific on our case: * libshout needs to communicate mainly with Icecast. It may also communicate with forks, branches or similar products. It's becoming more a generic HTTP client but is not limited to that. * I'm not aware any other software it communicates with in the wild is supporting TLS at all. * There is no browser interaction. Never. * My conclusion on this is that we should focus on compatibility with Icecast (including older versions). I tested with both Mozilla's 'Modern' and 'Intermediate' list. Both work well with all versions of Icecast (official) as well as current -kh. -- Philipp. (Rah of PH2) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20150426/c8b4256f/attachment.pgp
On 2015-04-26 18:15, Philipp Schafft wrote:> I tested with both Mozilla's 'Modern' and 'Intermediate' list. Both > work well with all versions of Icecast (official) as well as current -kh. >In that case my suggestion is for libshout to only focus on using the Modern list then as it explicitly excludes DES and RC4 and MD5. While HMAC-MD5 (for some password uses) and filehashing (as a alternative to CRC32) use is still fine any other use of MD5 is potentially vulnerable. RC4 (the original) has a weakness with the first n bytes of the stream, so unless it's the modified RC4 then that really shouldn't be used either. And DES is very old and AFAIK the key size is tiny on DES, though 3DES is a little better but still old too). BTW! Could libshout simplify the cipher list further than Modern? If it's not too much too ask, could your re-run the tests only this time with SHA256 ciphers as the minimum (in other words excluding SHA / SHA1). SHA1 should not really be used if it can be avoided (it's still fine for HMAC-SHA1 though and as a CRC32 filechecksum alternative) as some known weaknesses exists. Also is it possible to use TLSv1.2 only? (in other words excluding TLSv1.1) By the looks of it TLSv1.2 uses SHA256 for all ciphers (basically excluding the use of MD5/SHA1). So if TLSv1.2 works fine with Icecast then those old hash methods can be avoided fully. -- Roger H?gensen, Freelancer, http://skuldwyrm.no/