RS iphone webinterface with SSL offloading reverse proxy

[cuppie]

Hi,

 

I'm testing the RS webinterface for the iphone/ipad with an SSL offloading reverse proxy.

I'm testing with Pound and HAProxy.

The reason for this , is the possibility to use client certificates for authentication. So authentication is "safe enough" , and the login is automatic so more friendly.

 

 

So the client accesses the webinterface via https://tv.mydomain.com/iphone.

 

This is working fine when its done with a Windows pc , with internet explorer.

Video's are streamed fine with the embedded flowplayer.

 

But when accessing the same utl with an ios device (both iphone 5 and ipad 4 tested) the webinterface is also working fine.

Only when a stream is started , no connection is setup.

 

Some investigaton learns that the player on the ios device tries to access the stream on http instead of https.

More investigation learns that the windows client uses the streamint3.html file for setting up the stream.

The ios device uses streamint2.html.

 

Digging in the streamint2.html file show up the flowing line:

 

<video src="{srcurl}" {isipad}

 

is the protocol header also pased in the srcurl ? so http or https is in there ?

 

Any hints are very welcome.

 

Kind regards

 

Cuppie

[cuppie]

Hi,

 

Just sniffed an iphone web session , when starting a stream.

 

I can confirm now , that RS sends an http://tv.mydomain.com url as srcurl

 

Can somebody help me , to change the http: to http: in the srcurl ?

 

Cuppie

[Lars_MQ]

I doubt it will work. Simply because it would be highly inefficient to encrypt the TS stream (lots of data). So most likely it will cause stuck / stuttering video display. The biggest problem will be: the playlists for the IOS Streaming are generated automatically using the incomming client connection address (means proxy -> RS) so no it is not possible.

 

Think about what you want to secure. The streaming is on demand with several URL parameters and bound to an specific (client) IP. The webinterface delivering those paramters and the selection to stream has to be secured not the streaming per se...

[cuppie]

Lars,

 

Thanks for the explanation.

 

I've tested with entering the url manualy.

There's also another showstopper when using client certificates on the iPhone.

 

When the iPhone wants to start the stream on https, and the reverse proxy asks for the client certificate , it stops.

 

for now its working fine when the reverse proxy also listens on http

For maximizing security it only allows connections on http when the url start with http://tv.mydomain.com/upnp/stream.m3u8?streamid=

The rest of the communication is done over https with client certificates.

 

I gonna test this for some time.

 

I really like this setup.

 

Thanks again!

 

Cuppie

[karhukuoma]

Cuppie, can you share your reverse proxy configuration?

[Keyser]

Hi Cuppie (and others)

 

Sorry about resurrecting this thread, but I started a similar thread a couple of weeks ago.

We are now on RS 1.32 with the completely new /IOS web interface, and this exact problem still exists.

 

@devs: The srcurl still contains a specific reference to HTTP which escapes the reverse proxy and prevents the streaming session from being setup over the existing HTTPS session. While the workaround above works, I would really prefer for the entire session to run over HTTPS. I know it works flawlessly (from manually testing a HTTPS streaming session from my Iphone), so why not offer the opportunity by not hardcoding the protocol - like it's not done on the regular web interface where streaming over a https reverse proxy works flawlessly?

 

@cuppie: did you ever find a way to change the service so you do not need the HTTP listener workaround in your reverse proxy?

 

This is the last little niggle i have with RS after the almost perfect 1.32 release. In my opinion it's close to proper release status (i would however prefer that it didn't rely on a DVBViewer install but worked completely standalone :-))

[Griga]

The next RS release will explicitely support reverse proxies and read the X-Forwarded-Proto header field (among others), or if the reverse proxy does not provide it, it will use use a configured protocol. It will also be applied to the srcurl.

[Keyser]

The next RS release will explicitely support reverse proxies and read the X-Forwarded-Proto header field (among others), or if the reverse proxy does not provide it, it will use use a configured protocol. It will also be applied to the srcurl.

That is SO cool :-)

 

You guys reaaly rock. Any idea about a release time frame? Not in specifics, just if we are talking weeks, months or years :-)

[Griga]

Dunno. Not years.

 

There will be additional changes concerning security. Password protection will also apply to transcoded streams delivered by the web server, so if a password is set for the web interface, clients will have to handle it, at least URLs containing user data.

 

It's already implemented and subject to internal tests. However, ATM I'm more busy with DVBViewer Pro.