Pre-emptively connecting clients to https

[immense]

Pre-emptively connecting clients to https

[bitbound]

Hi! Thanks for the kind words! :) I've gotten a lot of positive responses to that post, and it's been really awesome. It's also helped uncover a few bugs, which has been really helpful.

For the client install scripts, the hostname is dynamically generated when you download it. The hostname should reflect the URL that's coming from the browser. So if you're at "https://myserver.com", the script should have HTTPS in it. Same for HTTP.

Can you verify that you're browsing to https, and it's still downloading the script with http?

If so, can you try downloading the latest server files, overwriting the existing ones, and restarting the service? https://remotely.lucency.co/Downloads/linux-x64/Remotely_Server.zip

This was an issue previously that was supposed to be fixed. Also, I need to get a better release process going to track fixes and such. :)

[tedtms]

Yep! Just confirmed now, both before and after the overwrite/update. I'm browsing to the server using HTTPS but the script downloads with the hostname listed as HTTP. Overwriting with the latest server files and restarting the service did not change this.

Now, I'm browsing to the server through a reverse proxy that's handling the https. I actually removed nginx and certbot from the server running Remotely, since I have those services being handled on the reverse proxy. So, technically, HTTPS is transparent to the Remotely server.... Maybe that's why Remotely thinks it's operating in HTTP? Because the traffic it's getting from the proxy is HTTP?

[bitbound]

With the default configuration, Nginx does forward requests to .NET Core over HTTP (since encryption isn't needed to localhost). However, info regarding the original request to Nginx is forwarded over through special headers, which .NET Core reads and merges into the request.

This is what I had fixed earlier. All my tests since have shown that it's working properly.

I just deployed a fresh server at https://test.lucency.co/, and it's also working.

Since I can't replicate it, I'd need access to a server that's exhibiting the issues. Is there one I can access? You can email me details if so.

[tedtms]

What kind of access would you need? Would a copy of my nginx config be sufficient? Also, what email do you prefer?

[bitbound]

The more, the better. Ssh with sudo would be preferred. And if the web server is externally visible, that would be good. If it's a prod server that you can't give access to, you'll need to replicate it on a server that I can access. Everything works as intended with a fresh server. So it's likely a configuration issue. I don't have a lot of spare time. So having direct access is the fastest way to troubleshoot. My email is [email protected] Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: tedtms <[email protected]> Sent: Sunday, April 21, 2019 10:15:14 AM To: Jay-Rad/Remotely Cc: Jared; Assign Subject: Re: [Jay-Rad/Remotely] Pre-emptively connecting clients to https (#17) What kind of access would you need? Would a copy of my nginx config be sufficient? Also, what email do you prefer? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#17 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFAF3NBRFMUEYQEFIOGXZSTPRSOKFANCNFSM4HHIY54A>.

[tedtms]

Ok! I'll get the info for you tonight or tomorrow. Thanks again for all the time you've put into this and for your support!

[singularo]

Similar situation here as OP, posting my nginx site config in case it helps diagnose:

root@ssl-nginx:/etc/nginx# cat sites-enabled/remotely 
server {
    listen 80;
    server_name remotely.myhostname.com;
    return 301 https://$host$request_uri;
}

server {

    listen 443 ssl http2;
    server_name remotely.myhostname.com;

    ssl_certificate           /etc/nginx/my_existing.crt;
    ssl_certificate_key       /etc/nginx/my_existing.key;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    access_log            /var/log/nginx/remotely.access.log;

    location / {

      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;

      # Fix the “It appears that your reverse proxy set up is broken" error.
      proxy_pass          http://192.168.1.15:80;
      proxy_read_timeout  90;

      proxy_redirect      http://192.168.1.15:80 https://remotely.myhostname.com;
    }
}

[tedtms]

Hey singularo, issue ended up being that my nginx reverse proxy was on another machine. The latest commit includes a fix for this and an extra config parameter where the proxy IPs have to be specified. I haven't gotten the chance to test it yet but the relevant info is in the new Readme. Cheers!

[bitbound]

As @tedtms mentioned, this is hopefully addressed in the latest version.

Unfortunately, my hosting provider is experiencing a major outage today, so the server install scripts aren't working. I need to change my CI/CD to use GitHub releases instead of my server, I think.

Anyway, all configuration assumed that the Nginx server is on the same machine as the .NET Core app. To get .NET Core to accept forwarded headers from another machine, that machine's IP must be added to a KnownProxies property. It's explained here: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-2.2

I added a property in appsettings.json for this. Here's the info I originally sent to @tedtms .

Download and overwrite with the latest version again.

There's a new item in appsettings.json called KnownProxies. It's a string array. You'll need to add the Nginx machine's IP address to it. This will allow .NET Core to receive forwarded headers from external machines.

Also, I added a note about this to my readme. You can copy your appsettings.json settings to appsettings.Production.json. .NET Core will automatically use this settings instead of appsettings.json when running in Production environment. That way, you don't have to keep backing up/restoring your settings when upgrading. You just need to remember to add new properties (if any are added to the project).

Once my hosting provider fixes the servers, you should be able to install and test the updates.

[bitbound]

My hosting provider is still down. I think I'll be switching. In the meantime, I got a release out on GitHub Releases. The scripts still don't work yet since they're trying to download from my server, but at least the binaries are there to download.

https://github.com/Jay-Rad/Remotely/releases

[tedtms]

@jay-rad Updated to the build you posted to GitHub but the scripts are still downloading with HTTP instead of HTTPS. I'm assuming I'm using the right syntax for the KnownProxies configuration?

Is there any adjustment that should be made to the nginx configuration after this update to make sure that the headers are passed properly to the remotely server?

[bitbound]

I added a small change that might help. If not, there's also a note in their docs about dual-mode sockets, under the KnownProxies section. See if that applies to you. https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-2.2#forwarded-headers-middleware-options

If it's still not working, then you'll need to have Nginx forward requests to Remotely on the same box.

Unfortunately, I don't have time to develop and test for environments that I'm not actively using. I know it sucks to have a "works on my box" mentality, but I simply don't have the time.