Dedicated encrypted port for [external] communication with apps or via Emby Connect

[ellnic 26]

When talking to Plex users about how much I love Emby, most of the comments are fairly benign but one does seem to come up quite often: accessing Emby from the outside. I know this has been a headache subject for a few reasons, but I truly believe this may be the answer to the problem.

 

Thinking about accessing Emby externally via an app (and connect) we currently have to open a port which [at user choice] requires an SSL certificate (which requires a domain).... money getting spent. That open port then gives anyone with the public IP access to the web UI.

 

To combat this, my proposed solution would be that the web UI ports and the server communication ports should be split. I was configuring a Syncthing node the other night which put me onto this train of thought. For those of you who don’t know, syncthing is a decentralised file synchronisation tool that is similar in its function to Resilio - but way more awesome. The guys at syncthing decided to split the communication and web UI ports so that the nodes can still communicate, but it’s unlikely that they will be compromised. The web UI port by default is 8384, whereas the comms port is 22000 by default. This is brilliant, because you can open port 22000 and without your consent, it’s unlikely that an attacker will gain access to the cluster. Each node has a strong crypto cert, and without you providing certain details to another node about the first, it cannot gain access. Emby should work in a similar way to this.

 

So:

 

Emby’s HTTP and HTTPS ports should remain as is. If you want to access the web UI on the move by just going to your IP, you need to open those up and sort your SSL etc.

 

But: if you just want to be able to sign in from an app or via Emby connect, communications should be via a dedicated encrypted port which will give an attacker no web UI or other attack vectors by simply browsing to that IP/port. Presumably, an Emby connect account requests the public IP of the server and this is how it then connects? Great for dynamic IPs and no domains etc. It should still do this, but with a security token as well. The token would open the channel of communication then allow access via the encrypted port to apps, web UI etc.

 

I have been told that Plex can function a bit like this, the port can be opened but without external access to the web UI. Idk though, when I was last using Plex I didn’t access externally.

 

This would do away with let’s encrypt, get rid of any UPnP woes (as the forwarded port is useless without a token) and maybe help bring some Plexer’s in.

 

Thoughts? :-)

 

 

Sent from my iPhone using Tapatalk

Edited August 16, 2018 by ellnic

[Luke 37129]

We have this with http://app.emby.media

 

The html is hosted there which gives you one place to run the app from. But I really don't see how your idea does away with lets encrypt/ssl and upnp. If you the web app over https it will only be allowed to communicate with other domains or addresses over https, and those will need to be open and have a certificate attached to them.

[ellnic 26]

Ok, so let’s assume that I am a new Emby user, I’m switching from Plex:

 

I setup Emby server and want HTTPS.. I can’t, because I need a certificate. To get a certificate I need a domain. So I use it without HTTPS, which isn’t secure - but this is the only way to allow external access. So I have an open port in my router which points to a non-SSL web UI that is publicly accessible, ie a vulnerability.

 

Maybe I’ve barked up the wrong tree a bit here. The reason for suggesting the separate port is to have a port where the server can communicate with the app etc but the web UI NOT be accessible. Maybe this could also be achieved on the existing ports? Can an option be added to the server settings so that the web UI is only internally accessible?

 

The end result is to allow anyone to be able to port forward and get external access without needing domains and lets encrypt - which is what Plex users claim to be able to do.

 

I’m not suggesting we do away with UPnP and SSL, just that if UPnP were to automatically map on this non-web UI port, it wouldn’t matter. There would be no further action needed.

 

 

Additional:

 

From the Plex forums:

 

“Plex listens on port and 32400 and, for myplex, on an additional port you specify in the settings.”

 

This is what I am talking about. 32400 is the vulnerability if not secured, but myPlex uses another port for just myPlex which has no web UI. This is how users are not having to worry about gaining external access and setting up letsencrypt.

 

Emby needs this.

 

 

 

Sent from my iPhone using Tapatalk

Edited August 16, 2018 by ellnic

[mastrmind11 717]

Plex users have to route through Plex's servers to connect to their own server, which is how Plex is able to accomplish this.  Emby uses a different model. 

[Spaceboy 2500]

Also you can do domains and ssl certs for free. I even have cloudflare obscuring my public ip, again for free

[Luke 37129]

 

 

I’m not suggesting we do away with UPnP and SSL, just that if UPnP were to automatically map on this non-web UI port, it wouldn’t matter. There would be no further action needed. 

 

I don't see how anything would change. In fact, separating these functions across ports would require two ports to be open and mapped, thereby increasing the setup requirements for new users.

[ellnic 26]

Yes I know domains and SSL can be done for free... most Plex users don’t, though. You have to get the balance right though. A lot of these guys want easy, and easy domains and SSL comes with a cost to some people.

 

I think mastrmind11 has answered part of this conundrum, the connections all go via Plex. I know this isn’t Emby’s way of doing things - But I’m trying to think how we can we win over Plex users who absolutely cannot be bothered or do not understand how to setup domains and ssl, free or not?

 

Sorry for the confusion - I’m not talking about having 2 ports open, I’m talking about having the choice of either:

 

1. The existing setup - be that HTTP or HTTPS where the server is publicly accessible including the web UI. Needs letsencrypt for SSL and some setup.

 

OR

 

2. A single port, like an API port if you will, that outside apps can communicate with that is encrypted without the need for lets encrypt. Such a port would not give access to the web UI. Apps would handshake on that port then give a user entered key in a format such as xxxxxx-xxxxxxx-xxxxxxx-xxxxxxx-xxxxxxx. Only with the correct key would the app be allowed to access the server and the key could be revoked/changed in the server admin panel. Port scan the IP and you’ll find the port, but you’ll get no web UI, and no way to attack or access it without the key.

 

This would make external secure access as easy as Plex without the Plex model.

 

Is this not at all possible?

 

 

 

 

 

 

Sent from my iPhone using Tapatalk

Edited August 17, 2018 by ellnic

[Luke 37129]

You're mixing in two different things that are unrelated. For #1, yes we are interested in providing out of box ssl in the future.

 

But that doesn't relate to #2. Splitting the two functions onto separate ports will not make the server any more or less secure and will only increase user setup requirements. 

 

 

Only with the correct key would the app be allowed to access the server and the key could be revoked/changed in the server admin panel.

We already have this form of authentication.

[ellnic 26]

Ok thanks for humouring me :-)

 

 

Sent from my iPhone using Tapatalk