Forcing HTTPS for HTTP users

[sevealin 0]

Hello!

 

First post! I have some users who access Emby remotely. I just recently setup a valid certificate for HTTPS. I've noticed the users connecting to the HTTP web client still (port 8096). My secure connection mode is set to "preferred, but not required". If I change it to "Required for all remote users", no users can login (they receive an invalid login error). The users have the Emby server added with the HTTP port, not the HTTPS port (8920). 

 

Is there a way to move them all to the HTTPS port without having to tell them to re-add the server?

 

Thank you!

Edited August 25, 2019 by sevealin

[Luke 42378]

Hi, how are they connecting to your web app?

[sevealin 0]

Hi, how are they connecting to your web app?

Most users are connecting through the Emby app for Android/iOS. Very few users connect through a web browser to watch on PC.

Edited August 25, 2019 by sevealin

[Luke 42378]

What kind of SSL cert do you have?

[sevealin 0]

What kind of SSL cert do you have?

 

PKCS#12 signed by Let's Encrypt. I followed most of the tutorial below except for the steps for older versions of Emby.

https://mythofechelon.co.uk/blog/2017/01/01/lets-encrypt-emby-server-and-windows

[Luke 42378]

If you set it to be required then what happens with the android mobile app?

[sevealin 0]

I think I know where you are going with this. I just checked some firewall logs (which I should've done at first) and after I set it to "required for remote connections", the logs show android client began using the https port right after I made the change automatically, even though the android client was originally setup to use the http port.

 

Sorry for the waste of time! I appreciate you taking the time to help me with this.

[Luke 42378]

Thanks for the feedback !

[eliduvid 1]

Hey!
I can see from this thread that emby can handle redirecting from HTTP to HTTPS port on it's own, but is there a way to force it to do it when TLS is handled by reverse proxy?

My setup: I have emby server in docker and a reverse proxy that exposes it on port 443 (HTTPS). Ideally I want my users to just type in our domain in their app and it just working with default 8096 port, but it still working though HTTPS. I tried HTTPS redirects in the reverse proxy, but they seam to break the apps in interesting ways. I see that the server can tell the app to go to the HTTPS port, but without configuring TLS on the emby server itself, i can only set "Secure connection mode" to "Disabled" or "Handled by reverse proxy" which both seam to do nothing (checked using tcpdump on the server). I have configures external ports in network settings of emby server.

Edited Saturday at 10:43 PM by eliduvid

[Q-Droid 1016]

You don't need to redirect anything or open/expose the HTTP port on the WAN. Set Secure Connection Mode to "Handled by reverse proxy" and make sure the Public HTTPS Port Number in Network Settings matches the public port for the reverse proxy (443?). If you've also entered the External domain in the Network Settings then the Dashboard should display the correct protocol, domain and port for the "Remote (WAN) access" URL. This is what gets advertised to apps when they connect and/or transition from LAN to WAN.

Because of how the apps work you will have to get your users accustomed to entering https and/or port numbers when they connect.

 

 

Edited Saturday at 11:54 PM by Q-Droid

[eliduvid 1]

yeah, I know I can do that, but

3 hours ago, Q-Droid said:

get your users accustomed to entering https and/or port numbers when they connect.

is exactly what I'm trying to avoid  

[Lessaj 495]

10 minutes ago, eliduvid said:

yeah, I know I can do that, but

is exactly what I'm trying to avoid  

To my knowledge most if not all modern browsers will try HTTPS (port 443) automtically. From the apps side of things, I think it also does the same thing. You should be able to just enter the domain name and leave the port field blank and it should try 443 automatically. I recommend testing on your end to verify results. Just make sure the http port isn't open/available to connect to.

Edited yesterday at 03:52 AM by Lessaj

[eliduvid 1]

@Lessaj, nice, thank you! I didn't know I could clear the port field and it'll try 80/443, but it does. At least in my setup with standard 80->443 redirect it shows the server as http://emby.example.com, but still talks to it through https, which is very much what I was trying to achieve.

That said, ideally I'd still like it to "just work" even if user forgot to clear default populated field. I understand that people needing to remember to remove a number from a field is a problem so small, it's bordering on not a problem at all, but it's so nice when tech doesn't require attention from users. 

[Q-Droid 1016]

Do you have an 80->443 redirect configured in the proxy? In the past this has caused problems for apps (not browsers) and you mentioned the same in your post. 

Where is the server shown as http://emby.example.com? The Emby server should have and display the correct WAN URL. This gets stored in client apps when they connect to make reconnection faster. It's possible that the apps now try/retry on different ports though this has also presented as taking a long time to connect on launch.

Even if users have to remove a value it should only be the first time they connect from an app. Subsequent launches would remember the server. Browsers are easy since they always want to try HTTPS and you're running the standard port for that.

 

[eliduvid 1]

41 minutes ago, Q-Droid said:

Do you have an 80->443 redirect configured in the proxy? In the past this has caused problems for apps (not browsers) and you mentioned the same in your post. 

yeah, but it seams to work fine when I'm not configuring explicit port.

42 minutes ago, Q-Droid said:

Where is the server shown as http://emby.example.com? The Emby server should have and display the correct WAN URL.

Sorry, by http://emby.example.com I meant http://emby.<my-domain>. Like the app shows that it's connected to my domain via http, although in practice it talks to it via https. It's not a problem, just mentioned it for the future generations

[Q-Droid 1016]

I knew the domain name itself was obscured, just asking where it is that you see HTTP vs HTTPS and wondering if it was on the Dashboard or somewhere else.

It's been a while since I've paid attention to how the apps behave during setup and initial connections. There's a good chance much has changed over the years.

 

[eliduvid 1]

2 minutes ago, Q-Droid said:

if it was on the Dashboard or somewhere else.

in server list

[Lessaj 495]

I'm not seeing that on my end, it's showing the last used address is the HTTPS address - but in my environment HTTP is completely blocked even in local LAN, all traffic is forced through my reverse proxy HTTPS and I probably entered the full domain when I connected to it. A test instance that I have yes does show HTTP but also ends with 8096. It could be due to that 80->443 redirect it's showing the last used address as HTTP even if the redirect happens. I do have an 80->443 redirect set up "just in case" but maybe since I explicitly entered the address it's not showing that way. Would need to do some testing.

[eliduvid 1]

so in conclusion, you guys say that 8096->443 redirect that will work for apps is basically impossible? 

[Lessaj 495]

I don't see why it wouldn't, it's the same as an 80 redirect. But it shouldn't be an issue to just blank out the field, they have to do it once...

[Q-Droid 1016]

1 hour ago, eliduvid said:

so in conclusion, you guys say that 8096->443 redirect that will work for apps is basically impossible? 

The devs would have to answer this. Apps don't necessarily follow the HTTP redirects the way browsers do. Then you have the challenge of many apps on multiple platforms. Would all of them honor the same method or only specific ones? Would each app flavor need a different way of doing it?

If you can get them to enter a URL to include https:// and clear the port then the app will try  to connect on 443. At least the Android app does this.

 

Edited 9 hours ago by Q-Droid

[eliduvid 1]

2 hours ago, Lessaj said:

it's the same as an 80 redirect

 

1 hour ago, Q-Droid said:

Apps don't necessarily follow the HTTP redirects the way browsers do.

in my testing depending on protocols, specified ports and domains I got all of those behaviors when using http redirects:

* http/https protocol error

* generic connection error after timeout

* see user list, when click on any user get something along the lines of "access key expired" 

* fully works besides the library scan button and maybe some others, which fail with some analog if 404 (that one when redirecting from one https domain to another)

 

also, I'm pretty sure that http in server list is just a harmless visual bug and the app actually tries 443 before 80, because http->https redirect is the one that I never made work no matter what. 

All tested on the same android app

Edited 8 hours ago by eliduvid

[Q-Droid 1016]

What I get from Android app and no forwarding configured:

- domain name alone, no port: only attempts to connect on port 80.

- http://domain, no port: only attempts on port 80.

- https://domain, no port: only attempts on port 443.

If I include the correct port number then it doesn't care if I add http://, https:// or use plain hostname. It still connects fine.

The info is from my firewall logs because I don't have anything listening on 80 or 443 on the WAN side. Those connections fail (DROP) and while it tries multiple times for each it doesn't change the destination port.

 

 

[eliduvid 1]

maybe they have some special casing for 80->443 redirect, idk. it interacts very weirdly with all of this 

[Lessaj 495]

Port 80 is also blocked in my local environment, but I do have the redirect set up externally so I did forget server and tried to connect with only the domain name and I saw no hit on port 80, it appears it automatically tried 443. I know I was looking at the right log to capture the port 80 attempt because I did a curl on it and saw the 301 response for the redirect. I tried again with http:// and the domain name, still no port, and it still seems like it automatically tried 443. I even tried the domain with port 80 and I don't see it hitting. It shouldn't remember anything if I've forgotten the server. Not really sure what to say about that.