SSL/TSL for React Frontend and Express Backend? - node.js

I have been learning more about web development so this is likely a dumb question or I do not have the knowledge to search for the answer properly.
I am revamping my current personal website (hosted on Github pages). I am making a React frontend which will be served via Github pages and with an Express backend (likely through cyclic). I want to add SSL/TSL Encryption for encrypted communication between the frontend and backend.
To my knowledge, SSL works via the server sending it's certificate to the client. It also will send it's public key so that the client can use the key to encrypt the message, send it to the server which uses the private key to decrypt said message. To me this means that I definitely would need to get a certificate for my backend.
However, I have some knowledge into how RSA encryption works (I know this is not the same) but it seems like this means that messages from the server to the client would not be secure. Would this mean that if I needed messages to be encrypted going that way that I would need to add a certificate. I personally cannot think of an example but I am sure there might be one.
First, is my assumption correct? If this is the case, how would I do so in both the general sense and with the services I am using?
Thank you for any help and I apologize for any mistakes I made, I figured to put out my thought process.

GitHub pages will do the SSL/HTTPS for you but you as part of configuring your custom domain. See Securing your GitHub Pages site with HTTPS.
In the "Code and automation" section of the sidebar, click Pages.
Under "GitHub Pages," select Enforce HTTPS.
If you were using your own servers, most people use Nginx to terminate SSL. Node.js can do it but most often Nginx is used as a reverse-proxy and SSL termination point.

Related

WebRTC over Local Network

I'm building a React website that I want to use WebRTC to basically be able to make audio/video calls to other devices, only on my local network. Because the getUserMedia requires HTTPS, I'm running into issues whereby I basically have to bypass the SSL warnings (the "visit website anyway" buttons), which I don't want to do.
I'm using my laptop to act as the connection broker/signaling server to allow the clients to connect with each other--if I downgrade the capabilities to HTTP for text chat only, this works great--but the whole purpose is to use audio/video, so I need that SSL layer.
My question is: how do I setup the SSL layer properly so that I don't have to bypass the warnings and accept a self-signed certificate?
Strictly speaking, the self-signed certificate does work and I can do this using it, but it seems self-defeating, so it's not really the way I want to go.
Again, this is only for intranet usage, so I don't know if that makes it easier or harder, but that's my constraint.
EDIT:
The server is written in NodeJS. I've found some documentation suggesting that Node can be given additional CAs (e.g. NODE_EXTRA_CA_CERTS). Is this something that I can leverage? Would a client html page utilize this in any meaningful way?
This link seems promising: https://engineering.circle.com/https-authorized-certs-with-node-js-315e548354a2. The main thing I'm not understanding is how I would utilize that ca: fs.readFileSync('ca-crt.pem') line for a given request, as it seems like the code there is actually making the request (but one would have already been made to the server in my case, no?). https://nodejs.org/api/https.html#https_https_request_options_callback seems to indicate something similar, as well.
It is totally possible to register a domain name, and then point it at something in the Private Address Range. I do this for local development sometimes. I registered pion.io and got a wildcard cert via LetsEncrypt.
You could also use mkcert. Then either in /etc/hosts or in your router itself you can give a FQDN to your signaling/web server.
There is also the --unsafely-treat-insecure-origin-as-secure argument for Chromium, I haven't used it lately though not sure if it still works.

API authentication without SSL

I'm writing an API that will be hosted without SSL support and I need a way to authenticate the requests. Each client would have a different ID, but if requests were authorised with that, anyone with a packet sniffer could forge requests. Is it possible to make a secure system WITHOUT relying on SSL?
(Some thoughts I had included OAuth, could that be implemented?)
Many thanks
Have each client cryptographically sign its requests with a client-specific key. Verify the signature on the server.
Using cryptography pretty simple. The main challenge is setting up the clients' keys. It'll be hard to do that securely without using SSL. There's no information in the question about how you set up client IDs, so I don't know if it's secure enough to set up keys at that point as well.
It's also going to be a problem if you serve the client code without SSL.
But hey, it's just an API you're building. Maybe the code that interacts with it is served over HTTPS. Or maybe the code is stored locally on the client.
I feel like a lot of people are going to complain about this answer though.

Cross Domain communication security from APP to PHP server

I have written an app with Phonegap which can be used by multible users. The app itself have to communicate with the same server.
So there are many users connection to the same server, however there is a problem, the security between the clients and the server, is atm "plain text".
I believe its called Cross-Origin Resource Sharing (CORS).
I am not sure how to make the connection between all those clients and the server secure.
What i want to achieve is
Make the data encrypted, so that no one can easily sniff the data.
My idea so far is
Use ex. sha1/md5 or a selfwritten encryption algoritm, with some SALT added and maybe an extra key. Implement that encryption algoritm on both the clients and the server, and encrypt/decrypt on the fly.
I have already added a PHP line to get it to work, but that dosent make it secure:
header('Access-Control-Allow-Origin: *');
I would like some advise on my thoughts, would my idea work, or is something else required?
thanks in advance.
Don't reinvent the wheel :) Simply use HTTPS to encrypt all your HTTP data.

Looking for the best way to build centralized authentication for multiple websites

Long story short, i have a couple of clients who wanted to manage some stuff on their website, all websites are build with nodejs.
I'v built a small CMS for those websites.
Keep in mind that none of my websites https,
here is what i want to happen:
a client goes to my website and submits a form with his password and username
i http POST his credentials to his website
his website returns a json with OK 200 if the credentials are ok
questions:
Is this the best way to do it ?
what encryption method should i use?
No this is not the best way to do it.
You should never authenticate through http, and you should definitely not do you own encryption between the server and the clients. Please consider using SSL.
You can get a wildcard SSL certificate which supports subdomains and thus multiple websites, like:
x.example.com
y.example.com
z.example.com
This is a recurring question, and the answer will always be to use established technologies and algorithms, instead of reinventing the wheel and possibly introducing security holes of your own.
Please see this article on javascript cryptography and why not to do it.
But when you have the website wrapped in SSL you can use the approach you explained and it will then be secure.

Can I make my own secure HTTP connection to a specific server

I am thinking about writing a secure connection between a specific client and a specific server over HTTP. Of course SSL is the best and most obvious choice. But I keep thinking I could do the do the cryptography myself.
Note that this isn't about connecting any client to a specific server, but a specific client (e.g. a Java client app on my PC) to a specific server (my website hosted somewhere else). SO third-party certification doesnt seem necessary, since the server knows exactly which client to look out for and the cleint knows exactly which server to find.
If I want to upload a file from client to server. I could encrypt it manually (AES or other) and have the key hardcoded into the client app and also put in a file on the server, out of public view.
Please tell me if I'm crazy, stupid or pushing at windmills. Is my idea possible?
The short answer is, "No you can't." You can write some code that you think implements a secure connection, but actually it will be insecure. Designing and implementing a secure connection is a very skilled job; just see what a security consultant would charge you for doing that.
Since you are asking the question here, it is reasonable to assume that you are not such a person. Since you do not have the required skills and experience, anything you produce would be insecure.
Use existing standards where all the obvious errors, and a lot of the not so obvious ones, have been avoided for you.
Your idea possible, and really, if you just need to send file to specific URL, it would be easier to make a POST request with encrypted data (if URL/headers don't need to be secure for you).
Trying to roll your own replacement for SSL is a bad idea. Don't roll your own crypto. Instead, you should use SSL. It does what you need.
Given that you need to authenticate both the client and the server, you should use SSL with client certificates (as well as server certificates, which are standard).

Resources