Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reinforce the need for TLS when exposing the server to the internet #22

Open
1 task done
xadaemon opened this issue Sep 26, 2021 · 6 comments
Open
1 task done
Assignees
Labels
enhancement New feature or request

Comments

@xadaemon
Copy link
Contributor

xadaemon commented Sep 26, 2021

Contact Details

m.xavier@ieee.org

Describe your idea

Reinforce the need for TLS when exposing the server to the internet, the server is now more secure with the ephemeral tokens but the read-me still doesn't warn about the need to use a reverse proxy with TLS when exposing the server to the internet as it is still very much insecure to exchange the credentials over plain HTTP. I can help with this if you need.

Code of Conduct

  • I agree to follow Pulsar's Code of Conduct
@xadaemon xadaemon added the enhancement New feature or request label Sep 26, 2021
@BSoDium
Copy link
Owner

BSoDium commented Sep 26, 2021

You're right, this is a good suggestion, although I have no idea how to implement it. Any tips on where to start ?

@xadaemon
Copy link
Contributor Author

There are a few ways,
From easiest to implement to hardest:

Use ssh port forwarding to not expose the server at all to the public internet.

Pros:

  • Easy to set-up;
  • Most possible users of this tool likely have ssh setup already;
  • Requires no extra software;
    Cons:
  • May require extra configuration on the server's ssh service;
  • Requires to open a tunnel at the client or a jump host;
  • Requires configuring ssh access at every client or use of the jump host;

Use a reverse proxy server this however requires nginx or caddy for example and a SSL certificate, self signed or from say let's encrypt.

Pros:

  • Most versatile and flexible;
  • Requires no client configuration aside from maybe when using self signed certificates;
  • Uses a reliable implementation of TLS that's battle tested (could also be caddy here);
    Cons:
  • Requires extra software to be installed on the server;
  • Requires provisioning a certificate (caddy can help here);

These last two points can helped by caddy.

Implement TLS in the server itself this however is very easy to get wrong and needs maintenance. I have only included this for completeness you should only do this when you know what you are doing.

@xadaemon
Copy link
Contributor Author

Another pro of ssh is no need for firewall rules if a rule for ssh already exists.

@BSoDium
Copy link
Owner

BSoDium commented Sep 27, 2021

I will be looking into these options, thank you. You'll be updated when I actually start modifying the code.

@xadaemon
Copy link
Contributor Author

xadaemon commented Sep 27, 2021

I will be looking into these options, thank you. You'll be updated when I actually start modifying the code.

Unless you go the third route there should be no code changes needed. Just some Readme changes to point users in the right direction.

@BSoDium
Copy link
Owner

BSoDium commented Sep 27, 2021

Well, if you can explain the step-by-step process of setting this up on a server, then feel free to make a PR 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants