Icecast - Nov 2017 - both ssl and non-ssl stream on the same socket

Hi.

I configured icecast to serve a stream over ssl and it plays nice in Chrome
and VLC. But on plain http I get *connection reset*. This stream's url is
the same for many years now, and it is included in many radio directories,
TuneIn and other apps. I can't change it or break it.

Is there a way to have a stream that servs the content over ssl and plain
http in the same time, depending on the request?

Thank you.

Alex G.
www.ortodoxradio.ro
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20171102/de18e574/attachment.htm>

I guess icecast has to be rewritten to support STARTTLS in that case,
but I guess this is a limitation in the HTTP protocol.

But what you can do is use port redirection if you know that certain
sources or clients will connect over SSL and then redirect them to the
other port based on their source ip..? I don't know if that could be an
option?

--
Marius

Den 02.11.2017 14.12, skrev Alexandru Matei:
> Hi.
>
> I configured icecast to serve a stream over ssl and it plays nice in
> Chrome and VLC. But on plain http I get /connection reset/. This
> stream's url is the same for many years now, and it is included in
> many radio directories, TuneIn and other apps. I can't change it or
> break it.
>
> Is there a way to have a stream that servs the content over ssl and
> plain http in the same time, depending on the request?
>
> Thank you.
>
> Alex G.
> www.ortodoxradio.ro <http://www.ortodoxradio.ro>
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20171102/525daa03/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20171102/525daa03/attachment.sig>

Hi Alexandru,

On 11/02/2017 02:12 PM, Alexandru Matei wrote:
> I configured icecast to serve a stream over ssl and it plays nice in
> Chrome and VLC. But on plain http I get /connection reset/. This
> stream's url is the same for many years now, and it is included in many
> radio directories, TuneIn and other apps. I can't change it or break
it.
> 
> Is there a way to have a stream that servs the content over ssl and
> plain http in the same time, depending on the request?
I am using this feature successfully with the icecast-kh branch since ~6
months.

from https://karlheyes.github.io/

since 2.4.0-kh5

8/5/2017
[..]
* autodetect SSL connections on incoming sockets. No need for <ssl> in
listen-socket now but is still there for compatability.
* add <ssl-private-key> in <paths> to allow for combined PEM or for
separate SSL key/certificate files.
* select https/http URL in autogenerated m3u based on incoming request.


hth,
.kloschi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x88BD7C00.asc
Type: application/pgp-keys
Size: 3128 bytes
Desc: not available
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20171102/e032347f/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20171102/e032347f/attachment.sig>

There is a discussion of this problem at:
https://stackoverflow.com/questions/22453782/nodejs-http-and-https-over-same-port
Some of the solutions depend on the clients honouring redirects (301
status code). Essentially, they boil down to running an http and https
server on two separate ports, and a simple service on your original
port which checks the first byte of the connection. If it is 22, it is
an SSL connection, and is redirected to the https port, if it is not
22, it is redirected to the http port. If for some reason a redirect
doesn't work, it would also be possible to forward the connection to
the appropriate port inside this service, but that would have more
system overhead.
The solutions there are generally based on using node.js on the server
to implement the redirector, but it could be done in almost any
language that supports sockets...

On Thu, Nov 2, 2017 at 9:43 AM, Marius Flage <marius at flage.org>
wrote:
> I guess icecast has to be rewritten to support STARTTLS in that case, but I
> guess this is a limitation in the HTTP protocol.
>
> But what you can do is use port redirection if you know that certain
sources
> or clients will connect over SSL and then redirect them to the other port
> based on their source ip..? I don't know if that could be an option?
>
> --
> Marius
>
> Den 02.11.2017 14.12, skrev Alexandru Matei:
>
> Hi.
>
> I configured icecast to serve a stream over ssl and it plays nice in Chrome
> and VLC. But on plain http I get connection reset. This stream's url is
the
> same for many years now, and it is included in many radio directories,
> TuneIn and other apps. I can't change it or break it.
>
> Is there a way to have a stream that servs the content over ssl and plain
> http in the same time, depending on the request?
>
> Thank you.
>
> Alex G.
> www.ortodoxradio.ro
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>

Good morning,

On Thu, 2017-11-02 at 15:12 +0200, Alexandru Matei
wrote:
> Hi.
> 
> I configured icecast to serve a stream over ssl and it plays nice in Chrome
> and VLC. But on plain http I get *connection reset*. This stream's url
is
> the same for many years now, and it is included in many radio directories,
> TuneIn and other apps. I can't change it or break it.
> 
> Is there a way to have a stream that servs the content over ssl and plain
> http in the same time, depending on the request?
This is a feature provided by Icecast2 2.5.x which is the current
development version. (Icecast2 2.4.x is in feature-freeze and is only
updated for important and/or security bugs.)

When setting the TLS mode to "auto" Icecast will automagically detect
if
a client requests no TLS, TLS via RFC2817, or via RFC2818[0].

Note that the development version is not stable yet, but I think it's
totally worth to have a look at. You can clone the current development
version from git[1].

I would also be happy to hear about your experience.

With best regards,

[0]
https://wiki.xiph.org/Icecast_Server/known_https_restrictions#TLS_Mode_compatibility_charts
[1] https://wiki.xiph.org/Icecast_Server/Git_workflow#Cloning_the_Repo

-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon: +49.3535 490 17 92

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20171103/6b070309/attachment.sig>