Let’s say I were to pin the CID of my front-end web app to IPFS (using a pinning service or pinning it myself) and then access the web app over the IPFS network, but then I wanted to make a POST request to my server. This POST request would happen over http and not https, making the request insecure.
IPFS doesn’t provide a HTTPS endpoint.
It provides a HTTP endpoint which you can secure yourself by putting it behind a reverse proxy.
It’s the same logic as writing a node.js website and putting it behind a reverse proxy.
Or just a static website.
Be aware though, you shouldn’t expose your API endpoint to the outside world at all (not http nor https)! Anyone knowing your endpoint can do anything the API can.
Web server Basic Authentication is not secure authentication since the passwords are transmitted in the clear without cryptographic cover. Furthermore, all information in IPFS is publicly viewable. So, if you are using a .htpasswd file, that file is publicly viewable. Thus, your passwords are both transmitted in the clear AND stored unencrypted and available for public viewing. However, if you are accessing the web page through a TLS enabled gateway, you could rely on the gateway’s TLS to provide cover.
Sadly, GNUTLS removed the ability to use a PGP key as a trust root…
If this functionality still existed and had been widely supported in web browsers, securing web traffic to IPFS would be fairly easy… just place your PGP public key in your web app structure.
What if every user had their own certificate, for example there are websites where you can authenticate and login using a ssh certificate I believe.When a new user signs up they generate a cert, maybe during the signup the transfer of data would be insecure but after… no.Thoughts?