Emby Connect / https

[aptalca 71]

Hi,

 

When I connect through emby connect, I get insecure http connection rather than the https set up.

 

I set up emby server with my custom domain and a letsencrypt cert. In the settings, I have https set to be reported as the external address. Upnp port forward is disabled and I manually forwarded only the https port on the router. When I use the custom domain address, I can access my server remotely with https and it works beautifully.

 

I believe some of the apps also use the https connection because in the android app, I get a pop up every once in a while to accept the letsencrypt certificate.

 

But when I connect through emby connect in a browser, I always get forwarded to app.emby.media on an http connection. My guess is, that address is proxying my https connection, because that's the only port that's open to the wan. It really defeats the purpose of setting up ssl because my data is still sent over http. Is there any way to make sure emby connect actually forwards to the https custom domain when connecting remotely?

 

Sure, I can use the custom domain to connect rather than emby connect, but then I would need two separate addresses, one for remote and one for local (as far as I know, if go the the external address from the LAN, emby thinks I'm remote and transcodes everything).

 

Also, how can I make sure that all the apps I'm using are connecting through https without the http proxy in between?

 

Thanks

[Happy2Play 9782]

Are you actually using https://app.emby.media  or http://app.emby.media?

Edited April 25, 2017 by Happy2Play

[aptalca 71]

  I was clicking on the "Sign In" link on the emby website, which points to http

 

I just tried the https version of app.emby.media and it is a secure connection. I'll use that in my bookmark from now on. The only downside is, if I'm on the LAN, chrome complains that it is insecure due to mixed content loading (from the local ip via http). I can live with that.

 

Thanks

[aptalca 71]

Ok, did a little bit more testing.

 

Based on the chrome connection logs, the app.emby.media first tries to load content from my server's local ip. If that's unsuccessful, it tries to connect to the external ip.

 

With chrome, when connected to https://app.emby.media, I can give it permission to load mixed content (from http), but I have to do it every time the page is opened. Without that, it cannot connect locally and has to load content from the https interface.

 

I think it would be much simpler if the app.emby.media site simply forwarded to the local ip or the external ip based on local availability rather than proxying both.

[Luke 42080]

Can you explain what you mean a little more:

I think it would be much simpler if the app.emby.media site simply forwarded to the local ip or the external ip based on local availability rather than proxying both.

We don't actually proxy or forward anything. If you check the local and remote addresses that are displayed on the front page of the Emby Server dashboard, those are the addresses that it tries to connect with. Does that make sense?

[aptalca 71]

Hi Luke,

 

Perhaps proxy was not the right word. Let me summarize my understanding of what happens when you connect to app.emby.media. I guess the website is running a javascript code (actually a few) that first try to connect to the local ip and if that fails, it connects to the remote ip. The connections are made from the client browser. Once thing I'm not clear on is, if the connection to app.emby.media is over http and the remote connection to the emby server is over https, is it still protected from snooping by the ISP? As you know the UK and the US both have issues regarding that. I am assuming the connection is not secure and the ISP would see the requests and part of the data.

 

Here are the four scenarios based on different connections to app.emby.media:

 

1) http connection, local server: Connects to the local ip through http, everything works

2) http connection, remote server: Connects to remote ip through https, however, the connection to emby.media is over http so see the above concern

 

3) https connection, local server: Tries to connect to local ip through http, chrome blocks it due to mixed content, then it connects to remote ip through https, everything transcodes

4) https connection, remote server: Tries to connect to local ip through http, chrome complains about mixed content, then it connects to remote ip over https, everything works as expected (transcoding)

 

As you can see the scenarios 2) and 3) have potential issues, with potential provacy breach in scenario 2) and a forced remote connection in scenario 3). Another minor issue with this method is that the user is unaware of whether a local or a remote connection is established with the server until they play something and see that it is throttled and transcoded.

 

Now, if my privacy related assumption above is incorrect, and there are no issues with streaming through http://app.emby.media when the connection to the server is over https, I can go ahead and use the http version of the site and it will work fine (although I still wouldn't know whether a local connection was successful or not, but it's not a big deal)

 

My suggestion was to have a basic javascript code that tries to connect to the local ip, and depending on the outcome, it does a temporary redirect (302?) to either the local or the external address. That way, the user knows exactly whether it is a local or an external connection and the local would be http and the external would be https.

 

Thanks

[Luke 42080]

To answer the question, no, in that case you would need to use the https version of the online web app at:

 

https://app.emby.media

 

However be aware that in this scenario, you will need an SSL cert that the browsers will accept, such as LetsEncrypt. They generally will reject the self-signed cert that is included with Emby.  Let us know if this helps. Thanks !

[aptalca 71]

To answer the question, no, in that case you would need to use the https version of the online web app at:

 

https://app.emby.media

 

However be aware that in this scenario, you will need an SSL cert that the browsers will accept, such as LetsEncrypt. They generally will reject the self-signed cert that is included with Emby.  Let us know if this helps. Thanks !

 

I do just that, I have a letsencrypt cert that I use. But like I wrote above, the mixed content in the browser (chrome) creates issues and prevents any local connection and forces the connection to be remote/external every time.

Edited May 1, 2017 by aptalca

[Luke 42080]

There's really no way to override that in the browser I'm afraid.

[Luke 42080]

The only other thing you could do is use the http version of http://app.emby.media

 

Then in the server hosting settings, enable the option to report https as the remote address. Then the local connection will be allowed under http.

[aptalca 71]

Hi Luke,

 

Here's a proof of concept for my suggestion. It is a basic js script that tests local IP connectivity by checking for the emby logo, if successful, it redirects to the local IP through http, if not, it redirects to the external IP through https. No issues with privacy or browser warnings due to mixed content, etc. The user also gets feedback on whether the connection is local or external. All credit goes to https://ardamis.com/2012/04/04/javascript-detection-redirection-if-intranet-site-is-accessible/

 

Please note, this proof of concept uses hardcoded values for my local and external addresses, but could easily be modified for emby connect integration. 

 

Also note that I'm using my own letsencrypt cert with a custom subdomain from duckdns (free ddns provider) as the external address.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Intranet Detection Script</title>
<script type="text/javascript">
<!--

var internalURL = 'http://local.ip:8096/web/home.html';
var publicURL = 'https://customsubdomain.duckdns.org:8920/web/home.html';
var detectionCounter = 0;
var detectionTimeOut = 5;
var detectionImage = 'http://local.ip:8096/web/css/images/logo.png?' + (new Date()).getTime();
var detectionElement = document.createElement('img');
detectionElement.src = detectionImage;

function detectIntranet() {
    detectionCounter = detectionCounter + 1;
    //  alert('Attempt ' + detectionCounter + ': Sniffing intranet connection by loading an internal resource at ' + detectionImage);
    if (detectionElement.complete) {
        if (detectionElement.width > 0 && detectionElement.height > 0) {
            //      alert('Attempt ' + detectionCounter + ': The intranet resource was loaded!');
            window.location = internalURL;
        } else {
            //      alert('Attempt ' + detectionCounter + ': The intranet resource could not be loaded!');
            window.location = publicURL;
        }
    } else {
        if (detectionCounter < detectionTimeOut) {
            setTimeout("detectIntranet()", 1000);
            //      alert('Attempt ' + detectionCounter + ': Still trying to load: ' + detectionImage);
        } else {
            alert('Attempt ' + detectionCounter + ': Gave up trying to load: ' + detectionImage);
            //    window.location = publicURL;
        }
    }
}

window.onload = function () {
    detectIntranet();
}

//-->
</script>
</head>

<body>
</body>
</html>

[Luke 42080]

That's not something we want to do. The online web app is it's own app. It's not going to redirect to your local web app.

[aptalca 71]

Ah, ok. I understand that the web app is meant to be its own app.

 

How about this suggestion (last one I promise  ):

 

User connects to http://app.emby.media and if local connection works, the user stays at the http version and everything works fine.

 

If local connection fails, the user is redirected to https://app.emby.media which connects to the external https address to access the server with https all around. That would solve all the issues I brought up above.

 

You would have security/privacy when connecting remotely and you wouldn't get the mixed content errors when connecting locally

[Luke 42080]

No, we can't do that because the browser treats that as two different web apps, each with their own data storage. there would be no way to carry over saved credentials.

 

Additionally, once you navigate to https there would be no way to navigate back to http without a browser warning. So what you have to do is pick the one you want from the beginning.

[aptalca 71]

Got it. Well, I give up.

 

Thanks for entertaining my ideas 

[Swynol 375]

if you have a decent router you can add static-host-mappings. 

 

on my router i set a static host map so that emby.mydomain.com resolves to my internal IP of my emby server. that way when on my LAN and i browse to https://emby.mydomain.com it resolves to my local IP. (no cert errors and no mixed content errors)

 

Then from external i use the same https://emby.mydomain.com which resolves to my external IP and then using port forward it gets to where it should Internally. 

 

EDIT: forgot to mention i use NGINX for all my external to internal traffic and it forces a HTTPS connection. luckily all the Emby apps i use support HTTPS.

Edited May 4, 2017 by Swynol

[aptalca 71]

if you have a decent router you can add static-host-mappings. 

 

on my router i set a static host map so that emby.mydomain.com resolves to my internal IP of my emby server. that way when on my LAN and i browse to https://emby.mydomain.com it resolves to my local IP. (no cert errors and no mixed content errors)

 

Then from external i use the same https://emby.mydomain.com which resolves to my external IP and then using port forward it gets to where it should Internally. 

 

EDIT: forgot to mention i use NGINX for all my external to internal traffic and it forces a HTTPS connection. luckily all the Emby apps i use support HTTPS.

 

 

Thanks for the suggestion. I set up split dns through the dns resolver and you're right. The cert is intact and emby server recognizes it as a local connection.

 

Did you set up an nginx reverse proxy for emby? Care to post your config?

 

I do have an nginx/letsencrypt docker container for reverse proxy and use it for various app guis but haven't proxied emby server yet. I'm instead forwarding a port for emby and use the letsencrypt cert from the nginx container.

[Swynol 375]

@@aptalca

 

ye i didnt like the way Emby uses custom certs as your private key is accessible without a password. So thats one of the reasons i use a reverse proxy. i have a thread on it here - https://emby.media/community/index.php?/topic/44757-setting-up-ssl-for-emby-wip/

 

or just my emby config.

	##EMBY Server##
	
	server {
    listen [::]:80;
    listen 80;
    listen [::]:443 ssl;
    listen 443 ssl;
    server_name emby.mydomain.com; 
	
        ssl_session_timeout 30m;
        ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
		ssl_certificate      SSL/cert.pem;
		ssl_certificate_key  SSL/private.key;
        ssl_session_cache shared:SSL:10m;
		if ($scheme = http) {
        return 301 https://$server_name$request_uri;
    }

     location / {
        proxy_pass http://192.168.10.10:8096;  

		proxy_hide_header X-Powered-By;
		proxy_set_header Range $http_range;
		proxy_set_header If-Range $http_if_range;
		proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        #Next three lines allow websockets
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
		add_header X-Frame-Options "SAMEORIGIN" always;
		add_header Content-Security-Policy "frame-ancestors mydomain.com, emby.mydomain.com;"; #ONLY NEEDED FOR iFRAME
    }
	

}

[aptalca 71]

Excellent, thanks so much

[Luke 42080]

Great work guys.