SSL Enhancements

[kingy444 108]

i have just gone through the process of setting up ssl + have found a couple items i wanted to suggest for inprovements

 

• http -> https auto redirect when force https setting is enabled. if you do not manually specify https in the url connection (pc/mobile browser connection) wont be made. apps seem to make that negotiation fine, this just covers web browseds
• if a ssl password is entered incorrectly, it tells you in the error log, but i think that should maybe be something that provides a notification, along with cert expiry. both are easy to happen without a user noticing. essentially some basic ssl verification failure alerts

[Tur0k 143]

I don’t know that I would recommend opening the http port on your firewall if you have HTTPS setup and working. I would recommend:

1. an SSL loaded in Emby

2. Local and public HTTPS ports setup.

3. allow remote connections enabled in Emby

4. require https on external connections in Emby.

5. internal and public http ports configured.

6. I only allow the public HTTPS port through on the firewall.

 

I would agree on your second point.

 

Sent from my iPhone using Tapatalk

Edited January 25, 2018 by Tur0k

[kingy444 108]

I don’t know that I would recommend opening the http port on your firewall if you have HTTPS setup and working. I would recommend:

1. an SSL loaded in Emby

2. Local and public HTTPS ports setup.

3. allow remote connections enabled in Emby

4. require https on external connections in Emby.

5. internal and public http ports configured.

6. I only allow the public HTTPS port through on the firewall.

 

I would agree on your second point.

 

Sent from my iPhone using Tapatalk

 

i think you misunderstood on the first point.https 8920 works fine.

 

i dont want to allow http 8920 access, i want any attempt to connect to http on port 8920 to auto redirect to https 8920

[Luke 37116]

That's not even possible. We can't listen on both protocols using the same port. In this situation the request would just fail altogether.

[kingy444 108]

That's not even possible. We can't listen on both protocols using the same port. In this situation the request would just fail altogether.

 

Well - that answers that one. i knew i had done some redirect from http to https in the past, didnt take into account they were on different ports.

 

If we could look at the notifications on upcoming expiry, invalid pass etc that would be great

[Luke 37116]

I don't think my statement was 100% true. On some platforms it is probably possible, but I really don't think it's necessary because how would someone end up with that url in the first place? only user error i would imagine.

[Tur0k 143]

What is the root ask? Is that that you want to be able to type “mydomain.net” in the address bar instead of https://mydomain.net:8920?, and the client device or browser be automatically directed to the right place?

 

 

Sent from my iPhone using Tapatalk

Edited January 26, 2018 by Tur0k

[otispresley 81]

I am using a letsencrypt cert in Apache and reverse proxy. This allows Emby to be secured with an SSL cert, and you don't have to convert your cert and add it to Emby. It works great and allows me to add header security, resulting in an A+ on securityheaders.io. Also, this allows you to keep your cert renewed with certbot and crontab easily so you don't have to write a script to convert your cert for Emby each time it is renewed.

[kingy444 108]

I am using a letsencrypt cert in Apache and reverse proxy. This allows Emby to be secured with an SSL cert, and you don't have to convert your cert and add it to Emby. It works great and allows me to add header security, resulting in an A+ on securityheaders.io. Also, this allows you to keep your cert renewed with certbot and crontab easily so you don't have to write a script to convert your cert for Emby each time it is renewed.

 

@@otispresley what sort of extra header security do you add that emby is missing?

 

and how do the emby apps work with the reverse proxy? do you configure them all to manually point to the reverse proxy during initial setup or something?

 

edit: i just tested my site, and i got an F rating. more interested in how this reverse proxy stuff works now... is the stuff you put on the reverse proxy headers something @@Luke and co could also do to increase the security posture of emby?

Edited January 27, 2018 by kingy444

[kingy444 108]

What is the root ask? Is that that you want to be able to type “mydomain.net” in the address bar instead of https://mydomain.net:8920?, and the client device or browser be automatically directed to the right place?

 

 

Sent from my iPhone using Tapatalk

 

im actually used to typing the port manually, so domain:8096 worked fine because it was http. will just need to start typing the https aswell by the looks of it, unless i look at the reverse proxy stuff provides a different way

[Tur0k 143]

im actually used to typing the port manually, so domain:8096 worked fine because it was http. will just need to start typing the https aswell by the looks of it, unless i look at the reverse proxy stuff provides a different way

You know I thought about this some. If you are running Emby service on windows you could add the IIS feature. Then set IIS to redirect to HTTPS and port 8920 from port 80 and HTTP. Then open port 80 on your firewall and forward it to your Emby server on port 80. This would allow you to enter “http://yourdomain.com”and be redirected to “https://yourdomain.com:8920”.

 

 

Sent from my iPhone using Tapatalk

[kingy444 108]

You know I thought about this some. If you are running Emby service on windows you could add the IIS feature. Then set IIS to redirect to HTTPS and port 8920 from port 80 and HTTP. Then open port 80 on your firewall and forward it to your Emby server on port 80. This would allow you to enter “http://yourdomain.com”and be redirected to “https://yourdomain.com:8920”.

 

 

Sent from my iPhone using Tapatalk

 

Actually pondered doing this, I like the 'security through obscurity' thing. ie, port 80 is obvious, but someone has to manually check for port 8920. I might end up doing something similar to this though. going to look into reverse proxy too. thanks for the help

[otispresley 81]

@@otispresley what sort of extra header security do you add that emby is missing?

 

and how do the emby apps work with the reverse proxy? do you configure them all to manually point to the reverse proxy during initial setup or something?

 

edit: i just tested my site, and i got an F rating. more interested in how this reverse proxy stuff works now... is the stuff you put on the reverse proxy headers something @@Luke and co could also do to increase the security posture of emby?

 

Just for context, I am also running multiple other sites in Apache on the same server as different hosts on port 443 with different Virtual Host configurations in Apache2. I place my header configurations at the end of /etc/apache2/conf-available/security.conf as such so that it applies to all my sites:

Header set X-Xss-Protection "1; mode=block"
Header set X-Content-Type-Options "nosniff"
Header set Content-Security-Policy "frame-ancestors"
Header set X-Frame-Options: "sameorigin"
Header set Referrer-Policy: "same-origin"

The reverse proxy works such that you can access the Emby server on the default SSL port 443 (i.e. https://emby.example.com),or you can still do HTTP 8096 as well if you want. I let my internal network clients use HTTP 8096 and make my remote clients use 443 and only allow 80 and 443 through my firewall but forward HTTP to HTTPS on my Apache server for ease of use. I hope this helps.

Edited January 28, 2018 by otispresley

[Tur0k 143]

Actually pondered doing this, I like the 'security through obscurity' thing. ie, port 80 is obvious, but someone has to manually check for port 8920. I might end up doing something similar to this though. going to look into reverse proxy too. thanks for the help

I would agree there. I have my own public domain. I have a sub-domain that is configured as a DDNS. I run a reverse proxy here. I host a handful of internal services through it. Each service is then tied to a separate sub-domain (this is a CNAME record that references my DDNS). I then use Let’s Encrypt ssl certs for each of my subdomains. I force all external inbound traffic through to port 443. I have ACL rules configured to determine if the request is coming from the Public Internet or a local subnet. I then determine which domain is in the URL request. All inbound requests must have a valid domain request associated with them otherwise they are forwarded to a dummy backend. When the external request is external and is forwarded to the dummy backend server the source IP is added to my firewall block list for 30 days. This helps me deal with average port scans on my WANs IP block by keeping brute force attacks from getting to a logon screen, and getting me off of their watch lists.

 

 

Sent from my iPhone using Tapatalk

[jaredallard 0]

For TLS setup you should probably just put nginx in front of it.

 

Here's a really great nginx.conf example that I use for devops purposes where I work.

 

https://gist.github.com/plentz/6737338

 

To point this at emby setup a location directive:

location / {
      # Common proxy headers
      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;

      # Proxy the network to our Emby instance
      proxy_pass          http://127.0.0.1:emby_http_port;
      proxy_read_timeout  90;

      # re-write redirects to http as to https, example: /home
      proxy_redirect http:// https://;

      # Websocket Support
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
}

Be sure to set emby to bind to 127.0.0.1 so that it's not accessible from the outside (only through nginx)

 

Edit: This also enables HSTS, so fair warning, if you remove your TLS cert existing users will be unable to connect to your server until TLS is restored, but it will also force TLS on all connections.

 

You also may want to edit the 'Content-Security-Policy' add_header so that it reflects your domain

Edited January 28, 2018 by jaredallard

[jaredallard 0]

I don't think my statement was 100% true. On some platforms it is probably possible, but I really don't think it's necessary because how would someone end up with that url in the first place? only user error i would imagine.

 

HTTPS maps to :443, HTTP maps to :80. (without a port specified) The fix is just to 301 to the https URL. Of course, if you're insane, you could throw a http-proxy in front of it and listen for byte '22' (TLS handshake) and the use whatever to initiate an TLS connection, but I can't imagine why you'd *ever* need to do that.

Edited January 28, 2018 by jaredallard