[Icecast-dev] upcoming libshout beta/snapshot

Tue Apr 28 04:09:17 PDT 2015

Hi,

On 28/04/15 09:43, Philipp Schafft wrote:
> 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.

Depends on the keying option of 3DES. Only option 1 (three independent 
keys) seems reasonably secure at currently effective 112 bits. Option 2 
has 80bits effective and option 3 is equivalent to DES. So by example, 
I'd hope that allowing 3DES doesn't open us up to its option3, which 
would be easily factored and broken even by 90's standards.

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

That is not what I said.
What I said was that I'd prefer if there would be a proven/reputable 
list that we could adopt for the client side.

The rationale behind that is, that it would have avoided the process 
that we're currently going through, including all possible pitfalls.

To further expand, as it is pretty obvious, the client side cipher list 
doesn't, or even shouldn't be identical to the one for the server side, 
as it needs to fulfill different requirements.

By assembling such a list ourselves it becomes our responsibility to 
ensure safe choice of ciphers and avoiding putting something in that 
would allow an adversary to break security. OpenSSL is notorious for 
having many, possibly interacting options that can weaken or even 
destroy security if not handled with great care and diligence.

>> 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'm not entirely convinced that the oldest of distros need to be our 
measure for what is a new feature.
Else we might as well wheel in Red Hat Enterprise Linux 4 (currently on 
Extended Life Cycle Support), which apparently sports openSSL 0.9.7a, or 
Suse Linux Enterprise Server 10 (currently on Extended Support) at 0.9.8a.

To explain why: I'm afraid that enforcing compatibility with some old 
version, like 0.9.8 series, will force us to erode security of our 
future facing security options.
In my opinion, if someone wants to run the combination of Icecast with 
SSL on a distro that's long out of regular support, they will need to 
deal with the fact that an out of the box current libshout as shipped by 
a recent distro will not work. I think that's better than a potentially 
false sense of security across all openssl versions.

If we can find a way to support those, that doesn't introduce additional 
risk, then I'm happy to have it.

> 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 don't think that is an excuse for inferior security, but I also hope 
you didn't mean it as such. It is not our call to make about the 
importance of security for transported data that we can not foresee.

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

We just need to ensure it's security for everyone and not insecurity for 
everyone, else we might as well stay plain text.I think we're on the 
same side with this one.

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

I'm looking forward to hear about that and am most grateful for the work 
you do on this.

Cheers

Thomas