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