[Icecast-dev] upcoming libshout beta/snapshot

[Philipp Schafft]

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