I’m building an application (both client and sever sides) that may need to send and receive data over the network. The messages will be short, and probably mostly binary. I need the connection to be secure even on public networks.
I’m not looking to reinvent the wheel, so I’d love if the protocol would handle all session-management overhead itself (handshake, dealing with dropped packets, sending back ACK responses, etc.). It will also be nice if it’d be naturally supported in Windows, Linux and OS X (by the .net framework, and the *NIX kernels).
So far, I’ve considered several options:
- HTTPS – has good support for all of the above, except for the overhead. If the message is short, all the HTTP headers are just redundant. Natively supported.
- IPSEC – is supported natively, but forcing me to handle the session myself.
- Google’s Protocol Buffers over HTTPS – the best option for now, but requires some implementation effort.
I’m new to the world of network programming, so any advice or tip would be greatly appreciated.
I think you’ll first have to decide at what level you want to work. IPSEC as a protocol works at about the same level as IP; basically, you’ll have to do everything yourself. HTTPS is a significantly higher-level protocol.
HTTP/HTTPS is universally supported, (with a little bit of work) will work through proxies etc. HTTPS gives you privacy and optionally authentication of the endpoints, at little extra cost. The operating system might even already provide a key store which you can use.
You can also open a socket and simply push encrypted data back and forth; think telnet or SSH (although SSH is fairly heavyweight during the protocol negotiation phase). Encryption libraries are available in or for most frameworks, but you have to be careful with key management and exchange. If you can live with using pre-shared keys, though, this is not necessarily a problem at all, really; otherwise, X509 certificates might be a workable approach that is readily supported on many platforms.