3 ms·
Just use TLS. To quote a little bit more from that 'cperciva article: > If you're distributing client code which speaks to a server you operate, there is no
by lvh 9y ago
Just use TLS.
To quote a little bit more from that 'cperciva article:
> If you're distributing client code which speaks to a server you operate, there is no need to use SSL; instead, you can distribute the server's public RSA key (or its hash) along with the client code, and "bootstrap" the security process that way. I do this in FreeBSD for the FreeBSD Update and Portsnap services, and I also do this in Tarsnap. It's simple; it works; and it's secure.
I'm sure cperciva knows how to start from a hardcoded RSA key and end with a secure wire protocol. The spirit of the document is damage control: prevent less broken software. There's a hell of a lot more in TLS than an RSA key. There are a lot of ways you get from "RSA" to "wire protocol" and not a lot of them are any good.
If you control both ends and you want to be fancy, use TLS with one secure ciphersuite and a hardcoded CA, that's fine.
- marshray 9y ago> there is no need to use SSL; instead, you can distribute the server's public RSA key (or its hash) along with the client code Imagine the following scenario: All the hard negotiations are done and you're about to sign your biggest customer or even sell the entire business for big bux. This is, of course, contingent on a clean 3rd party security review. The reviewer asks: "How does the system enforce key expiration policies? How do you rotate keys? How do you revoke a key that may have been compromised or recover from known compromise? Which private keys get used on network-facing servers? In what model of HSM do you store the root key?" ... and so on.