3 Sony ATVs, all exhibit the same issue

[mastrmind11 717]

HSTS should force http connections to https on the clients side not the server side. So if you view a browser log you should see a 307 like this: You can add some other redirects after the fact to catch any unsupported HSTS clients, but if you watch your logs I bet you wont see any.

 

 

 

And the headers should look like this: Forcing the change to https due to HSTS, I think most apps and OS's respect the hsts vs server redirect.

 

So the ssl handshake is happening on the client side but still respecting the server side cert? How would I distinguish between https vs http requests to the server in the nginx logs... They all appear to be 200s (which makes sense based on your explanation of HSTS). Appreciate all the help.

 

Btw why did you choose HSTS over server side redirect?

 

edit:  nevermind, I just read up on the HSTS stuff.  Pretty cool, and imo this should really be the way we direct new nginx users on these boards going forward.  Thanks again for your help @@pir8radio.

 

Sent from my SM-G965U using Tapatalk

Edited March 31, 2018 by mastrmind11

[pir8radio 1292]

So the ssl handshake is happening on the client side but still respecting the server side cert? How would I distinguish between https vs http requests to the server in the nginx logs... They all appear to be 200s (which makes sense based on your explanation of HSTS). Appreciate all the help.

 

Btw why did you choose HSTS over server side redirect?

 

Sent from my SM-G965U using Tapatalk

 

"So the ssl handshake is happening on the client side but still respecting the server side cert?"

Not happening on the client side, the client is forced to re-ask for an https version during its http handshake before any info is actually exchanged. 

 

 

In the nginx logs you should see the port they used 80 or 443...    The server is feeding them the HSTS header they should never actually fulfill a get request on port 80.  So from today forward you "shouldnt" see many if any port 80 requests, but nginx still has to listen on 80 for the initial http handshake which is why its listening in the config. 

 

I originally went with HSTS because it is made to secure the connection from the get go... Helps protect from a man in the middle attack and you dont have to deal with redirects, which i was having issues with (like you).

 

Here is a view of my nginx log, in 2016 i was http only, i then enabled https later in 2016 but let the users decide to connect to https or http, later in 2016 i tried a redirect with some issues, may of 2017 i enabled hsts.

 

[mastrmind11 717]

"So the ssl handshake is happening on the client side but still respecting the server side cert?"

Not happening on the client side, the client is forced to re-ask for an https version during its http handshake before any info is actually exchanged. 

 

 

In the nginx logs you should see the port they used 80 or 443...    The server is feeding them the HSTS header they should never actually fulfill a get request on port 80.  So from today forward you "shouldnt" see many if any port 80 requests, but nginx still has to listen on 80 for the initial http handshake which is why its listening in the config. 

 

I originally went with HSTS because it is made to secure the connection from the get go... Helps protect from a man in the middle attack and you dont have to deal with redirects, which i was having issues with (like you).

 

Here is a view of my nginx log, in 2016 i was http only, i then enabled https later in 2016 but let the users decide to connect to https or http, later in 2016 i tried a redirect with some issues, may of 2017 i enabled hsts.

 

great explanation.  I owe you a beer.

[pir8radio 1292]

@@pir8radio could you see if you see any other changes that I should make?

EDIT: strong-ssl.conf is included in /etc/nginx/nginx.conf

 

Nothing jumped out at me, except your websockets config, I would let the client decide if it needs upgrade vs forcing it no matter what.   Other than that looks good, any known issues?

proxy_set_header Connection "upgrade";
to
proxy_set_header Connection $http_connection;

[Delphi 83]

I'm experiencing the same problem as the OP.

 

EDIT: the websocket setting was like that from some tutorial I found when I initially setup nginx for emby

Edited March 31, 2018 by Delphi

[pir8radio 1292]

I'm experiencing the same problem as the OP.

 

EDIT: the websocket setting was like that from some tutorial I found when I initially setup nginx for emby

 

where is your emby server block referencing the strong ssl config?

[Delphi 83]

In /etc/nginx/nginx.conf, does it need to be included again?

 

EDIT: included it before the ssl.conf... no change.

Edited March 31, 2018 by Delphi

[pir8radio 1292]

In /etc/nginx/nginx.conf, does it need to be included again?

 

EDIT: included it before the ssl.conf... no change.

 

how do you know your issue is the same as mastrmind11's?  Any nginx log info like he included?  What happens when you connect via HTTP:// what do the logs look like for that attempt?

[Delphi 83]

Logging in via http adds this line to the logs "GET /web/serviceworker.js HTTP/2.0" 304 618 "https://emby.domain.tld/web/serviceworker.js""Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"

 

Assumed same issue as nothing is added to the logs on unsuccessful attempts, Sony Android TV, Emby for AndroidTV, immediate 'Error Connecting to Server' in the app on attempt.

 

EDIT:

Connecting via connect in the app does not show my server either, but I can successfully log in to my server with connect via Chrome...

Edited March 31, 2018 by Delphi

[mastrmind11 717]

 

Logging in via http adds this line to the logs "GET /web/serviceworker.js HTTP/2.0" 304 618 "https://emby.domain.tld/web/serviceworker.js""Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"

 

Assumed same issue as nothing is added to the logs on unsuccessful attempts, Sony Android TV, Emby for AndroidTV, immediate 'Error Connecting to Server' in the app on attempt.

 

EDIT:

Connecting via connect in the app does not show my server either, but I can successfully log in to my server with connect via Chrome...

 

That's not the same issue.  Open a new topic so this doesn't confuse others that come along w/ my issue (or yours).

[Delphi 83]

I posted something semi unrelated a few weeks ago about the same problem on the same ATV at a different location.  I am completely unable to connect to my server remotely from any of these tvs, manually or using connect, via 80 or 443.  I get an immediate "connection failed" message after hitting OK.  I am able to connect to the server using every other non-TV device on the same network w/o issue.  Since I have until tomorrow morning to get this figured out or try again in a couple months, I'm hoping we can figure something out.

 

My server is behind nginx, 80 and 443 are forwarded to my local internal IP on 8096.  nginx and emby are on the same box, emby is running in a docker container in host mode. 

 

I did some digging this morning and found this in the nginx error log, which corresponds to the time I was trying to connect from the TV (sensitive stuff redacted):

2018/03/30 21:58:06 [error] 20801#20801: *84301 connect() failed (111: Connection refused) while connecting to upstream, client: client_ip, server: , request: "GET /emby/System/Info HTTP/2.0", upstream: "http://10.0.1.152:8096/emby/System/Info", host: "my_domain_name"

There are success entries in the access.log from the same timeframe when I was testing other devices on the same network.

 

Here is my nginx config:

server {

        listen 80 default_server;
        listen [::]:80 default_server;
    
        server_name my_domain.com 10.0.1.152;
        return 301 https://$server_name$request_uri;

}

server {

 # SSL configuration

 include /etc/nginx/proxy.conf;

 listen 443 ssl http2 default_server;
 listen [::]:443 ssl http2 default_server;
 include /etc/nginx/snippets/strong-ssl.conf;
 ssl_certificate /etc/letsencrypt/live/my_domin.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/my_domain.com/privkey.pem;

 # Root location
root /var/www/html;


 # Add index.php to the list if you are using PHP
 index index.html index.htm index.php index.nginx-debian.html;
 
 # Basic Auth to protect the site
# auth_basic "Restricted";
# auth_basic_user_file /etc/nginx/.htpasswd;

 # Change the client side error pages (4xx) to prevent some information disclosure
 error_page 401 403 404 /404.html;

 # First attempt to serve request as file, then as directory,
 # then fall back to displaying a 404.
 
 # Deny access to .htaccess files, if Apache's document
 # root concurs with nginx's one
 
 location ~ /\.ht {
          deny all;
 }

# Let's Encrypt Webroot plugin location -- allow access

 location ^~ /.well-known/acme-challenge/ {
          auth_basic off;
          autoindex on;
       }

# Location settings for reverse proxy; enable those you wish to use
# by removing the # from the section between the location line and the last }
#

location / { #emby at root of webserver
proxy_pass http://10.0.1.152:8096; 

        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";
        }
}

I don't understand why literally every other device I've tried work, but not these TVs.  2 TVs on this network, 1 TV on a different network, all the same brand.  Please help!

 

EDIT:  I'm not sure how those entries got into the nginx error log.  I'm trying to connect from a TV again and it's failing, but I'm not seeing any corresponding entries in the error.log.

It is literally the same error

[mastrmind11 717]

It is literally the same error

I was getting a 301 when hitting the server, you're getting a 304. Have you tried the HSTS bit mentioned above to avoid the redirect?

 

Sent from my SM-G965U using Tapatalk

[Delphi 83]

After adding the HSTS and removing the redirect is what the logs are from.

[pir8radio 1292]

After adding the HSTS and removing the redirect is what the logs are from.

You can pm me your server info we can start from square one if you want. I’ll connect and see if I can find anything wonky. Again I don’t need to log into your server just hit your login page.

[Delphi 83]

PM'd

[pir8radio 1292]

PM'd

 

HSTS is working properly on  your site, no access errors, everything loading up as expected.    app logs from your TV might help, but I don't really know much about all of the apps. 

[Delphi 83]

@@ebr any ideas on what changed that would not allow access to the server anymore from Emby for AndroidTV? or how to access the logs on a Sony Android TV?

[pir8radio 1292]

@@ebr any ideas on what changed that would not allow access to the server anymore from Emby for AndroidTV? or how to access the logs on a Sony Android TV?

 

Keep in mind, I think it may be something related to your setup, You can try my server if you want, Ill PM you my server info for you to test, report back if my server worked or not that may help ebr. 

[Delphi 83]

@@pir8radio logged into your server without a problem, @@ebr I can provide you with server details or invite you via connect for troubleshooting. This has only been happening for ~4 days, and nothing changed on my server until I started troubleshooting in this thread.

Edited April 1, 2018 by Delphi

[mastrmind11 717]

@@pir8radio logged into your server without a problem, @@ebr I can provide you with server details or invite you via connect for troubleshooting. This has only been happening for ~4 days, and nothing changed on my server until I started troubleshooting in this thread.

Backup your current config and use the one posted above. If it works, then it's your proxy that's the problem.

 

Sent from my SM-G965U using Tapatalk

[ebr 14925]

I thought this was solved with a proxy configuration change.  What are we trying to solve now?

[mastrmind11 717]

I thought this was solved with a proxy configuration change. What are we trying to solve now?

It's a proxy config issue. There's nothing wrong with the app.

 

Sent from my SM-G965U using Tapatalk

[Delphi 83]

Why is Emby for AndroidTV the only application affected by this, if it is a proxy config error?

[mastrmind11 717]

Why is Emby for AndroidTV the only application affected by this, if it is a proxy config error?

Did you try the above suggestion(s), or do you just want to debate why you think it's the app?

 

Sent from my SM-G965U using Tapatalk

[Delphi 83]

@@mastrmind11 yes i did use your proxy config, with no changes except for domain and ip info, and still cannot access my server from my Sony Bravia AndroidTV with Emby for AndroidTV, whilst I can connect on the same TV with Kodi and EmbyCon... so no it is not a simple proxy issue.

 

EDIT: Also I can connect with my phone with Emby for Android Mobile, so something is hinky with the AndroidTV app...

Edited April 2, 2018 by Delphi