CODEWITHSUNDEEP
node.js
Noah Kellem
Noah Kellem

Reputation: 55

Node.js Server Request to HTTPS Enough for Encryption?

After much googling I'm still just as lost as I was when I started. I'm trying to make a secure request from one server to another in Node.js, and I'm unsure if sending the request through https (ex: https://someapi.com) is sufficient. Both servers are owned by me. One server needs to ping the other for verification/authentication by sending an API key + secret to it. Would my request from the requesting server to the authentication server be encrypted? Or would it be vulnerable to man-in-the-middle attacks?

I'm making the request from the main/requesting server like so:

const rpn = require('request-promise-native');

const options = {
  method: 'POST',
  uri: 'https://authenticationserver.com/api/verification',
  json: {
     api_key: API_KEY_HERE,
     secret: SECRET_HERE
  }
}

rpn(options)
.then((responseData) => console.log('successful'))
.catch((err) => console.log('error'));

Upvotes: 2

Views: 1939

Answers (3)

Jake Holzinger
Jake Holzinger

Reputation: 6063

Yes, using HTTPS is sufficient for this task.

The primary purpose of a secure transport protocol (like HTTPS, SSH, WSS, etc.) is to make man-in-the-middle attacks very hard. Because of the nature of the internet you cannot control the machines that your data travels through, so it's nearly impossible to prevent a man-in-the-middle attack, unless of course you control the entire network of computers like an intranet. Knowing this some very smart people invented Public-key cryptography to combat man-in-the-middle attacks.

Public-key cryptography exploits a feature of advanced number theory where the basic idea is that is very computationally expensive to factor very large prime numbers. Using this feature it is possible to generate two very large prime numbers, then using some complex mathematics you can encrypt data with one of the prime numbers in such a way that the only way to decrypt the data is to do the mathematic operation in reverse using the other prime number. These two prime numbers are referred to as public and private keys.

When two computers establish an HTTPS connection they share their public keys and negotiate an encryption cypher. Once a cipher is determined (like AES) an additional key must be generated by one of the computers and shared with the other, this is the key that will be used to encrypt and decrypt the actual traffic. This key, however, is first encrypted using the public key of the computer that will be receiving the key. The receiving computer then decrypts the key using it's private key and the process known as "handshake" is complete.

During this handshake you'll notice that the private keys are not shared over the network, this is the key to avoiding the man-in-the-middle attack. Because the private key is not shared the man-in-the-middle does not have the ability to decrypt the cipher key and therefor are unable to decrypt the remaining traffic sent over the connection.

If you want to be as secure as possible you should generate sufficiently large public/private keys, update the keys regularly, and disallow the negotiation of insecure cipher suites. You cannot prevent a man-in-the-middle attack, you can only make it more difficult for them.

Upvotes: 2

Bradley
Bradley

Reputation: 2141

If these are cloud servers, and the communication is directly from server1 to server2, arrange the servers in the same VPN and block access from outside the VPN to the authentication server.

In AWS, you can use API Gateway to target specific routes on the authentication server allowing you to selectively expose routes for public (outside the VPN) consumption if you need that still.

Upvotes: 0

Romain V...
Romain V...

Reputation: 433

In theory, in your case, HTTPS should be enough secure.

If you want to increase security, you can play with RSA, AES to encrypt and decrypt your payload before sending it.

Upvotes: 1

Related Questions