Http POST encryption

Hi, everyone.

My application should send encrypted data via POST to a PHP server.

In PHP there are two functions for dealing with rsa public and private keys:

openssl_public_encrypt: Encrypts some text with a public key generated from a private key.
openssl_private_decrypt: Decrypts the encrypted text with the private key.

I want my Ionic 2 application (Client) to encrypt in a equivalent way to what openssl_public_encrypt does, so that the server’s openssl_private_decrypt can decrypt it.

For openssl in Ionic 2 I only found JSEncrypt, which encrypts with a public key, but the result of its method in not “understood” by the PHP decryption function.

Am I doing the wrong process?
How is this kind of cryptography usually dealt with in Ionic 2?

Thanks in advance!

If you use HTTPS then all your data should be encrypted automatically and there’s no need for another layer of encryption.

1 Like

I use js-jose.

1 Like

Thanks for your reply, ihadeed.

In fact I was trying to do “the hard way” what https naturally implements.

I studied the process for using https and it seems I have to pay an anual trusted certificate. Is there a free, or at least a non-expensive way of turning the domain into https?

Thanks!

Let’s Encrypt, and you absolutely, completely, 100% do NOT want to be rolling your own homebrew version of https.

1 Like

@rapropos, Let's Encrypt worked exactly the way I needed.
Thank you very much for your help.

I followed this tutorial for installing it in my Amazon Linux EC2 server.

Hope this topic helps someone in the future.

Lets encrypt is a good option as @rapropos mentioned.

I personally use CloudFlare. Provides more security and an optional caching layer.

I respect you a lot. Are you saying letsencrypt has insufficient security? That would be a major concern for me.

Letsencrypt is fine. It does the job of providing a free secure SSL.

However, with CloudFlare you also get more features such as:

  • Firewall layer: when you setup your server with CloudFlare, you modify your domain name to redirect to their Domain Name Servers instead of yours. Which means that no one will be able to know what the real IP address of your server is. This is will protect you from targetted attacks such as DDOS.

  • Caching layer: you can add page rules (you get 3 for free) to cache certain paths of your API. This will reduce the load on your servers by providing cached content instead of fetching the content from your database every time someone makes a request. This is helpful if your data doesn’t change that often.

  • Content devliery network: since requests are made to CloudFlare and not to your server directly, the client will be talking to CloudFlare CDN and will get a response from there. This means that the client is always communicating with a close by server even if your actual server is on the other side of the world.

They have other features that you might find interesting. I’m just mentioning the features that I find very useful whenever I develop an API for my applications.

1 Like

@ihadeed and @rapropos,
the https encryption is a step I indeed needed to implement, but although the connection is now safe, the network activity and the POST’s payload are still shown in the browser.

I originally intended to encrypt the POST to prevent someone from calling the api repeatedly or with altered parameters.

Is there a default solution for this?

HTTPS protocol encrypts the packets as they travel from the client to the
server. You will always be able to see what the form is submitting through
the browser, since that data is captured before the packets start their
journey.

If you are trying to reduce the server load, then you will need a cache
layer. That can be something like CloudFlare, or your own caching system
that’s implemented in the server.

If you are using a mainstream framework to develop your API. Then there is
probably a plugin or module you can install that will do that for you. You
can also implement the caching on the HTTP server layer (nginx, apache…
Etc). Another way is to implement browser caching (via headers, web
workers… Etc).

To secure routes for form submissions from malicious attacks, you can
implement CSRF security that ensures that these requests are coming from a
legit form that you’ve designed.

An important note about CloudFlare is that their free “flexible SSL” does not provide complete end to end encryption of data in transit, it only encrypts it between CloudFlare and the user, the link between CloudFlare and your server is unencrypted. So if you need your data to be encrypted in transit, make sure to use the “full” SSL option in conjunction with your own SSL.

The flexible option on CloudFlare is pretty much a one click set up process, so I feel like this fact is often missed.

More information available here: https://www.cloudflare.com/ssl/

On a related note, I use CloudFlare extensively and it’s flippin’ awesome.

Completely bogus, https can be easily intercepted by a wifi pineapple or by any other man in the middle and reseting the connection will forces a second handshake which automatically is intercepted giving the attacker both certificates.