Invalid Username/Password Fire Stick via SSL

[pir8radio 1292]

Hi.  I believe the apps are consistent here.  The only way we would know, when entering the address manually, to use https would be if it is specified.  Sorry for that confusion.

 

Were your other apps all on the local network where http would have worked?

 

 

I assure you that they are not consistent. I'm at a cafe right now on their network and can login via host.domain.net as below without issue on the Android app.

 

 

Are we sure its not the same issue others have been facing...  Some OS's support the 301 redirect from http to https, and some dont?  Are you usinig a 301 redirect to force people to https from http?

 

EBR I did notice the other day that    Https will not work on roku, but https will   (the cap H upsets it)  I'll try to reproduce... 

[ebr 14949]

Are we sure its not the same issue others have been facing...  Some OS's support the 301 redirect from http to https, and some dont?  Are you usinig a 301 redirect to force people to https from http?

 

That could definitely be it.  Our apps do not do anything different with this login procedure.

[mastrmind11 717]

which is why I recommended trying HSTS instead of redirecting as a test.

[Skrumpy 3]

Are we sure its not the same issue others have been facing...  Some OS's support the 301 redirect from http to https, and some dont?  Are you usinig a 301 redirect to force people to https from http?

 

EBR I did notice the other day that    Https will not work on roku, but https will   (the cap H upsets it)  I'll try to reproduce... 

 

Yes, I'm setup to do a 301 redirect. I did a check on status code, response headers, redirect location and redirect chain of a HTTP connection and it came out fine. There also aren't any issues with Qualys SSL lab tests and my server scores an A+ on overall rating.

 

server {
     listen 80;
     server_name host.domain.net;
     return 301 https://$server_name$request_uri;
    }

server {
        listen 443 ssl http2;
        server_name host.domain.net;

That could definitely be it.  Our apps do not do anything different with this login procedure.

 

The Fire Stick OS is simply a modified version of Android OS, there shouldn't be any difference in how it's handling a 301 redirect. Even the PINNED topic "HOW TO: NGINX Reverse Proxy" in Emby's General Forums suggests using a 301 http to https redirect. It is all standard protocol.

 

In searching, I haven't been able to find any other apps experiencing a similar issue on the Fire Stick, nor any SSL redirect OS issues in general (with Android or otherwise). The only Fire Stick app that comes up in doing a "Fire Stick SSL redirect" search is Emby, populating the top 2 searches. One with this thread and another thread where others have also had extensive SSL issues.

 

I'm not an expert, but I've had a few others who are review my nginx code. The author of the Organizr app even ran through it with me and helped me set it up. So I'm confident that it is setup correctly. It's really disheartening to go through the time and effort to getting fully SSL compliant to have certain users unable to access the server due to client software limitations.

Edited April 16, 2018 by Skrumpy

[Skrumpy 3]

which is why I recommended trying HSTS instead of redirecting as a test.

 

At this point it doesn't really matter. I got it working by adding https:// which hasn't been a necessary addition in any of the server connection methods I have available to me (Android app, Windows Theater, web login) either within or outside of my own network. I highly doubt Amazon would've modified something in the Android OS to make 301 redirects non-functional and even if this was the case, app developers should attempt to resolve this by making the login experience consistent from device to device.

 

The next issues on the chopping block are the Roku port and the web SSL video playback artifacts. As for the Roku, it auto-populates with 8096 and will NOT save when clearing out the port. Currently, my Roku users are simply unable to connect to my server because of this and I'm not seeing anything that I can do as a secure workaround. Leaving the port in there results in an SSL error, and changing it to anything else (including 8920) results in a connection error.

Edited April 16, 2018 by Skrumpy

[ebr 14949]

As for the Roku, it auto-populates with 8096 and will NOT save when clearing out the port.

 

I cannot reproduce this.  I just went to the manual connection screen, selected change port, blanked it out with the trash can button then filled in another port and it took that fine.

 

Can you please tell me exactly what they are doing here and also send a log from the app after doing the procedure that doesn't work?

 

It would be best to put this in a new topic in the Roku forum.

 

Thanks.

[Skrumpy 3]

I cannot reproduce this.  I just went to the manual connection screen, selected change port, blanked it out with the trash can button then filled in another port and it took that fine.

 

Can you please tell me exactly what they are doing here and also send a log from the app after doing the procedure that doesn't work?

 

It would be best to put this in a new topic in the Roku forum.

 

Thanks.

 

Yea, I'm moving discussion over there now.

[pir8radio 1292]

At this point it doesn't really matter. I got it working by adding https:// which hasn't been a necessary addition in any of the server connection methods I have available to me (Android app, Windows Theater, web login) either within or outside of my own network. I highly doubt Amazon would've modified something in the Android OS to make 301 redirects non-functional and even if this was the case, app developers should attempt to resolve this by making the login experience consistent from device to device.

 

That would further point to the 301 redirect not working any longer, i think we have only seen this on firetv and native tv apps.  This recently came up with a few users, where it worked days earlier...  I don't think anyone had gotten to the bottom of this yet.   In any case, fault of emby or the OS developers, redirects are not the ideal way to force https...    as mastrmind11 pointed out hsts is the modern way to go, and so far testing seems to show that android does obey hsts.     see this thread:  https://emby.media/community/index.php?/topic/57583-3-sony-atvs-all-exhibit-the-same-issue/   

[Skrumpy 3]

That would further point to the 301 redirect not working any longer, i think we have only seen this on firetv and native tv apps.  This recently came up with a few users, where it worked days earlier...  I don't think anyone had gotten to the bottom of this yet.   In any case, fault of emby or the OS developers, redirects are not the ideal way to force https...    as mastrmind11 pointed out hsts is the modern way to go, and so far testing seems to show that android does obey hsts.     see this thread:  https://emby.media/community/index.php?/topic/57583-3-sony-atvs-all-exhibit-the-same-issue/   

 

I'm fine with moving over to HSTS if you or mastermind11 wants to help me work it out in my nginx code.. =). I just got this setup and working flawlessly (minus the client issues with Emby) so I'm rather hesitant to change things. There aren't really any guides out there for setting it up for Emby. I'd be happy to do one if I could get some initial help.

[pir8radio 1292]

I'm fine with moving over to HSTS if you or mastermind11 wants to help me work it out in my nginx code.. =). I just got this setup and working flawlessly (minus the client issues with Emby) so I'm rather hesitant to change things. There aren't really any guides out there for setting it up for Emby. I'd be happy to do one if I could get some initial help.

 

I'm sure one of both of us would be more than happy to help!..  :-)   post your nginx config (without private info) I can also PM you my server for you to test to make sure it works as you expect before you break things...      

Edited April 16, 2018 by pir8radio

[Skrumpy 3]

I'm sure one of both of us would be more than happy to help!..  :-)   post your nginx config (without private info) I can also PM you my server for you to test to make sure it works as you expect before you break things...      

 

 

I'm fine with breaking things as long as I know they're going to be put back together and work again.. hah. Here are my configs. I have a site-confs file as my Emby server is running on a separate machine from my nginx server.

# REDIRECT HTTP TRAFFIC TO HTTPS
server {
     listen 80;
     server_name host.domain.net;
     return 301 https://$server_name$request_uri;
    }

server {
        listen 443 ssl http2;
        server_name host.domain.net;

#SSL settings
   include /config/nginx/strong-ssl.conf;

#Organizr auth
    include /config/nginx/serverauth.conf;    

location / {
#   auth_request /auth-user; #Allows only users logged into Org to access Emby
    proxy_pass http://192.168.0.3:8096; #Emby server IP:PORT
    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";
        }
}

Here is my domain file in nginx's site-confs dir

################################################################################################################
#////////////////////////////////////////////////SERVER BLOCK\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\#
################################################################################################################

# REDIRECT TRAFFIC FROM www.domain.net TO https://domain.net
server {
    listen 80;
    listen 443 ssl http2;
    server_name www.domain.net;
    return 301 https://domain.net$request_uri;
    }

# REDIRECT HTTP TRAFFIC TO https://domain.net
server {
    listen 80;
    server_name domain.net;
    return 301 https://$server_name$request_uri;
    }
    
################################################################################################################
#////////////////////////////////////////////////MAIN SERVER BLOCK\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\#
################################################################################################################

# MAIN SERVER BLOCK
    server {
        listen 443 ssl http2 default_server;
        server_name domain.net;
    
#SSL settings
    include /config/nginx/strong-ssl.conf;

#Custom error pages
    include /config/nginx/errorpages.conf;

#Organizr auth
    include /config/nginx/serverauth.conf;
    
#Block Org dashboard files
    include /config/nginx/blockdash.conf;
    
#Organizr container
    include /config/nginx/root.conf;

################################################################################################################
#////////////////////////////////////////////////SUBDIRECTORIES\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\#
################################################################################################################
    include /config/nginx/subdirs/*.conf;
    }

Here is my nginx.conf file:

user abc;
worker_processes 4;
pid /run/nginx.pid;
include /etc/nginx/modules/*.conf;

events {
    worker_connections 768;
#    multi_accept on;
    }

http {

# CACHE STATIC CONTENT
    include /config/nginx/cache.conf;

##################
# Basic Settings #
##################

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    client_max_body_size 0;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    

####################
# Logging Settings #
####################

    access_log /config/log/nginx/access.log;
    error_log /config/log/nginx/error.log;
    

#################
# Gzip Settings #
#################

    gzip on;
    gzip_disable "msie6";
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
    

###################################
# Virtual Host (ex: Emby) Configs #
###################################

    include /etc/nginx/conf.d/*.conf;
    include /config/nginx/site-confs/*;
 
      ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload;";
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    ssl_stapling on; # Requires nginx >= 1.3.7
    ssl_stapling_verify on; # Requires nginx => 1.3.7
    
}

daemon off;

As you can see, I pull in all of my other settings from separate conf files to keep it all a little cleaner.

[mastrmind11 717]

@@Skrumpy, back up your domain conf file that inludes the main server block(s) ..  and replace the 2 redirect server blocks.  So replace this:

# REDIRECT TRAFFIC FROM www.domain.net TO https://domain.net
server {
    listen 80;
    listen 443 ssl http2;
    server_name www.domain.net;
    return 301 https://domain.net$request_uri;
    }

# REDIRECT HTTP TRAFFIC TO https://domain.net
server {
    listen 80;
    server_name domain.net;
    return 301 https://$server_name$request_uri;
    }
    
################################################################################################################
#////////////////////////////////////////////////MAIN SERVER BLOCK\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\#
################################################################################################################

# MAIN SERVER BLOCK
    server {
        listen 443 ssl http2 default_server;
        server_name domain.net;

with this:

# MAIN SERVER BLOCK
    server {

listen 80; 
listen [::]:80; 
listen 443 ssl http2; 
listen [::]:443 ssl http2; 

server_name my_domain.com your.internal.ip; 

#Add HSTS Header
add_header Strict-Transport-Security "max-age=15552000; preload" always;

and leave the rest alone.  That should do it.

Edited April 17, 2018 by mastrmind11

[Skrumpy 3]

and leave the rest alone.  That should do it.

 

So it turns out I already had HSTS enabled this entire time. My domain file calls a strong-ssl.conf that had the header already included. The listen [::]:80; and listen [::]:443 ssl http2; are good additions I didn't have. Either way, I'm glad I went through everything as I spent a good portion of the rest of my day deduplicating references throughout my configs and adding some other things such as ocsp stapling.

 

In reading up, I found that ciphers can make a big difference in performance. Which ones do you guys use? Mozilla posts some good ones and I decided to go with their Modern set. It maintained my A+ at Qualys SSL Labs, but also slightly dropped my cipher strength in favor of increased key exchange. I think that makes the most sense as now there aren't any failures on handshake simulation and it should favor greater compatibility with more devices (than my old ciphers did at least). Still it would be nice to get a good all around cipher that is supported on all devices Emby is.

 

I'm very interested in knowing what other performance settings you guys utilize (gzip, worker settings, cache, ssl_session settings, etc). I'm sure there are a bunch of streaming optimizations I'm not configuring or don't have properly configured and it would be nice to have a publicly available resource for Emby users to reference. This could potentially prevent a lot of SSL related complaints here on the forums.

Edited April 17, 2018 by Skrumpy

[pir8radio 1292]

So it turns out I already had HSTS enabled this entire time. My domain file calls a strong-ssl.conf that had the header already included. The listen [::]:80; and listen [::]:443 ssl http2; are good additions I didn't have. Either way, I'm glad I went through everything as I spent a good portion of the rest of my day deduplicating references throughout my configs and adding some other things such as ocsp stapling.

 

In reading up, I found that ciphers can make a big difference in performance. Which ones do you guys use? Mozilla posts some good ones and I decided to go with their Modern set. It maintained my A+ at Qualys SSL Labs, but also slightly dropped my cipher strength in favor of increased key exchange. I think that makes the most sense as now there aren't any failures on handshake simulation and it should favor greater compatibility with more devices (than my old ciphers did at least). Still it would be nice to get a good all around cipher that is supported on all devices Emby is.

 

I'm very interested in knowing what other performance settings you guys utilize (gzip, worker settings, cache, ssl_session settings, etc). I'm sure there are a bunch of streaming optimizations I'm not configuring or don't have properly configured and it would be nice to have a publicly available resource for Emby users to reference. This could potentially prevent a lot of SSL related complaints here on the forums.

 

 

Even if you had HSTS enabled, remove the redirects, and add in the 80 and [::]80 to your other tag as he showed in his post...  Just having the redirects in the config seems to screw things up in certain circumstances.   

 

I like https://www.htbridge.com/ssl/    ssl labs will hand out A+'s pretty easily. I'm Actually surprised I received an A+ from this site myself to be honest!  This one also shows you what ciphers you use and what not, it makes it fun to trouble shoot ssl issues too!    Here is my SSL info if it helps, and here is a link to my current nginx config (stripped down for emby only) https://emby.media/community/index.php?/topic/48236-setting-up-emby-behind-a-reverse-proxy-nginx/&do=findComment&comment=457670 :

 

 

Edited April 17, 2018 by pir8radio

[Skrumpy 3]

Even if you had HSTS enabled, remove the redirects, and add in the 80 and [::]80 to your other tag as he showed in his post...  Just having the redirects in the config seems to screw things up in certain circumstances.   

 

I like https://www.htbridge.com/ssl/    ssl labs will hand out A+'s pretty easily. I'm Actually surprised I received an A+ from this site myself to be honest!  This one also shows you what ciphers you use and what not, it makes it fun to trouble shoot ssl issues too!    Here is my SSL info if it helps, and here is a link to my current nginx config (stripped down for emby only) https://emby.media/community/index.php?/topic/48236-setting-up-emby-behind-a-reverse-proxy-nginx/&do=findComment&comment=457670 :

Yea, I removed the redirects. although htbridge says that not having http to https redirection is a potential weakness.

HTTP SITE DOES NOT REDIRECT

 The HTTP version of the website does not redirect to the HTTPS version. We advise to enable redirection.

 

I did score an A+ on htbridge as well, with the only potential issues looking to be with ciphers as I am using the Mozilla ones compatible with TLS v1.2, do you really recommend supporting all of the other TLS versions? Do I need to have all of the ecliptic curves in there as well? Doesn't having all of those ciphers degrade performance as well as decrease security?

 

[pir8radio 1292]

 

Yea, I removed the redirects. although htbridge says that not having http to https redirection is a potential weakness.

 

I did score an A+ on htbridge as well, with the only potential issues looking to be with ciphers as I am using the Mozilla ones compatible with TLS v1.2, do you really recommend supporting all of the other TLS versions? Do I need to have all of the ecliptic curves in there as well? Doesn't having all of those ciphers degrade performance as well as decrease security?

 

 

Hum... Mine does not return that (redirect) error.     I was not recommending all of the TLS versions, and curves, Just showing you what I was running as an FYI..  

[Skrumpy 3]

Hum... Mine does not return that (redirect) error.     I was not recommending all of the TLS versions, and curves, Just showing you what I was running as an FYI..  

 

Hmm I'm wondering how yours doesn't have that error if you don't have any form of http to https redirection. Ok, I am new to this stuff so I was just questioning about TLS and curves out of curiosity. I get a lot of conflicted/outdated/non-applicable information on searching. I am wondering if it is best for Emby on multiple devices to just be cautious and run a more all inclusive cipher covering all TLS versions with all of the curves?

 

Edit:

 

Maybe I'm getting the error because I am running my Emby server separately from my nginx server? If I have a redirect in there do you think I'd need one in both the domain and Emby site-conf?

Edited April 18, 2018 by Skrumpy

[Luke 37183]

You may want to try that as a starting point and then work your way from there.

[pir8radio 1292]

Hmm I'm wondering how yours doesn't have that error if you don't have any form of http to https redirection. Ok, I am new to this stuff so I was just questioning about TLS and curves out of curiosity. I get a lot of conflicted/outdated/non-applicable information on searching. I am wondering if it is best for Emby on multiple devices to just be cautious and run a more all inclusive cipher covering all TLS versions with all of the curves?

 

Edit:

 

Maybe I'm getting the error because I am running my Emby server separately from my nginx server? If I have a redirect in there do you think I'd need one in both the domain and Emby site-conf?

 

sorry thought I answered the other day...    Guess i didn't hit post.   I don't think that is an issue running emby on a seperate pc from your nginx pc, that shouldn't matter.