3 ms·
> while maybe you could technically accomplish it with HTTPS, there are huge usability gains to be had in exchange for the inefficiency of duplicating some lowe
by speedplane 7y ago
> while maybe you could technically accomplish it with HTTPS, there are huge usability gains to be had in exchange for the inefficiency of duplicating some lower-level functionality
If you are not using HTTPS, you cannot just build your own "higher level" version of secure and authenticated communication. HTTPS works because trusted certificates are pre-installed on each of the machines before they start communicating. Without those pre-existing trusted certificates, no amount of encryption, signing, or hashing can guarantee secure and authenticated communication.
- deleted 7y ago[deleted]
- notduncansmith 7y agoI agree that from a practical perspective, the best way to secure one’s communications with a web server is to enable it with HTTPS. I also think though that it’s possible, for any number of reasons, that one might want signed API responses independently of that (e.g. OTA software updates). Once you get into cryptographic identity though, you’re back to CA/PKI all over again...
- speedplane 7y ago> it's s possible, for any number of reasons, that one might want signed API responses independently At it's core, HTTPS works because there is a distributed system of trust. The principle is that you don't need to directly trust the server that you're communicating with, but you trust another computer that has vouched for the one you are communicating with. If you roll your own security in any way, at some point you need to send an encryption or decryption key. Even "unhackable" encryption algorithms are worthless if your adversary knows the key. Thus, you need a way to communicate that initial key information securely. Currently, the only way to do that is by (1) manually entering the key on each server, (2) using near sci-fi technology like quantum communication, or (3) by having the keys pre-installed on every machine by the hardware manufacturer or OS provider. The option that has worked, HTTPS, uses option 3. Maybe you can roll your own encrypted communication system, but you'll either have to rely on manually entering the keys (which in turn rely on other insecure methods like email and phone), or trust the computer's manufacturer to pre-install the keys on the system your using. There really is no way to "roll your own" system securely without these steps.