Hot questions for Using Cap'n Proto in stunnel
I would like to use Cap'n Proto RPC to communicate with a server in the cloud from a desktop box in an office. Cap'n Proto doesn't provide secure network connections through a firewall. I would prefer c++ since I have other components which require this.
I see some people have been looking at nanomsg and other transports which link directly into the application, but I was wondering whether stunnel or something similar might be satisfactory.
The stunnel application, as most know, can provide HTTPS encapsulation of TCP/IP traffic under certain conditions, as per the FAQ:
- The protocol is TCP, not UDP.
- The protocol doesn't use multiple connections, like ftp.
- The protocol doesn't depend on Out Of Band (OOB) data,
- Remote site can't use an application-specific protocol, like ssltelnet, where SSL is a negotiated option, save for those protocols already supported by the protocol argument to stunnel.
It seems like Cap'n Proto RPC might satisfy these conditions. I don't think the customer will object to installing stunnel in this case. Has anyone tried this or something similar? If so, your experiences would be appreciated. If someone knows of a faster/lighter alternative it would also be helpful.
Yes, Cap'n Proto's two-party protocol (the only one provided currently) should work great with stunnel, since it's a simple TCP-based transport. You will need to run both a stunnel client and a server, of course, but otherwise this should be straightforward to set up. You could also use SSH port forwarding or a VPN to achieve a similar result.
(Note that stunnel itself has nothing to do with HTTPS per se, but is often used to implement HTTPS because HTTP is also a simple TCP protocol and HTTPS is the same protocol except on TLS. In the Cap'n Proto case, Cap'n Proto replaces HTTP. So you're creating Cap'nProto-S, I guess.)
Another option is to implement the
kj::AsyncIoStream abstract interface directly based on a TLS library like OpenSSL, GnuTLS, etc. Cap'n Proto's RPC layer will allow you to provide an arbitrary implementation of
kj::AsyncIoStream as its transport (via interfaces in
capnp/rpc-twoparty.h). Unfortunately, many TLS libraries have pretty ugly interfaces and so this may be hard to get right. But if you do write something, please contribute it back to the project as this is something I'd like to have in the base library.
Eventually we plan to add an official crypto transport to Cap'n Proto designed to directly support multi-party introductions (something Cap'n Proto actually doesn't do yet, but which I expect will be a killer feature when it's ready). I expect this support will appear some time in 2016, but can't make any promises.