Re: upcoming libshout beta/snapshot

Philipp Schafft <[email protected]> Tue, 28 Apr 2015 06:43:23 +0000
Newsgroups	gmane.comp.audio.icecast.devel
Organization	PH2
Message-ID	<[email protected]>
reflum,

On Mon, 2015-04-27 at 14:41 +0200, Roger Hågensen wrote:
> 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.

*nods*

> And DES is very old and AFAIK the key size is tiny on DES, though 3DES 
> is a little better but still old too).

I'm not aware of any 3DES attack. If you know anything please let me
know. Plain DES is considered broken for years.



> 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.

I'm not sure about this. I guess you need to provide a 'reputable
source' to conform with Mr. Rücker's requirements.


> 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.

I'm not too sure about this an the above. Here are two major problems I
think about:
      * If we limit too much we my end up and a set that is so small
        that there is no headroom. libshout installations have a
        lifespan of many, many years in the wild. I don't expect a
        half-life period<5a.
      * Because of the given problem we still have a *huge* amount of
        Icecast 2.3.2 and 2.3.3 we see in the wild. I doubt OpenSSL is
        much newer in all the cases (in many it will, but for sure not
        in all). Beside the security aspect (which is of cause very
        important) we also have the aspect of compatibility with older
        versions of software. Currently libshout builds with OpenSSL >=
        0.9.8f (I haven't checked on the ciphers). At least OpenSSL >=
        0.9.8o (2010) needs to be supported in my opinion as it's in
        Debian's LTS release.

I have not checked all the OpenSSL versions and what protocols, ciphers
and whatnot they support or don't support (yet). I think we need to find
a good tradeoff between security and usability as well as
maintainability both for users, administrators and developer team. Also
I think we should keep in mind what we try to protect: credentials for
sources (which can be changed at any time if leaked) and data that is
for broadcast. I'm really for strong security. I just think we need to
take care we can provide reasonable security for everyone, not perfect
security for some.

I will have some more test this week to find out if there are some
important limitations of relevant versions/setups we need to take extra
care of.

Have a good day and thank you very much for your input!

-- 
Philipp.
 (Rah of PH2)

_______________________________________________
Icecast-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/icecast-dev
signature.asc (application/pgp-signature, 490 B)