cuppie Posted January 3, 2013 Share Posted January 3, 2013 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 Link to comment
cuppie Posted January 4, 2013 Author Share Posted January 4, 2013 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 Link to comment
Lars_MQ Posted January 4, 2013 Share Posted January 4, 2013 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... Link to comment
cuppie Posted January 5, 2013 Author Share Posted January 5, 2013 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 Link to comment
karhukuoma Posted September 10, 2014 Share Posted September 10, 2014 Cuppie, can you share your reverse proxy configuration? Link to comment
Keyser Posted December 26, 2015 Share Posted December 26, 2015 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 :-)) Link to comment
Griga Posted December 26, 2015 Share Posted December 26, 2015 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. 1 Link to comment
Keyser Posted December 27, 2015 Share Posted December 27, 2015 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 :-) Link to comment
Griga Posted December 27, 2015 Share Posted December 27, 2015 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. 1 Link to comment
Recommended Posts