> -----Original Message----- > From: Ed W [mailto:li...@wildgooses.com] > Sent: vrijdag 19 april 2013 12:35 > To: Adriaan de Jong > Cc: Gert Doering; openvpn-devel@lists.sourceforge.net > Subject: Re: [Openvpn-devel] Support for libsodium? > > On 19/04/2013 11:13, Adriaan de Jong wrote: > > > I misunderstood your wish to completely get rid of TLS. That would > require a major overhaul in the way the control channel in OpenVPN is > handled. OpenVPN is completely centered around the idea of a TLS > control channel across which data channel keys are negotiated. Although > I'd love to see that kind of flexibility in OpenVPN, the code base is > nowhere near ready for that. It's a nice challenge though :). > > > > Another, more philosophical, question is whether the product is still > OpenVPN after such a change. It's certainly not line-compatible with > OpenVPN. > > Hmm, can you give me a pointer to relevant code so that I can get my > hands dirty? >
For documentation, you can generate the doxygen documentation. It's quite extensive, and should show you how things are handled. At a very high level, OpenVPN has an external multiplexer that splits incoming packets into a control channel and data channel stream. The control channel is used to generate keys, negotiate sessions, and exchange parameters for the data channel. It has a reliability layer that ensures that packets arrive, even across a UDP connection. The data channel contains the actual network packets. For the data channel, have a look at the crypto_* files. crypto_backend.h defines the interface that is expected from a crypto library. crypto_polarssl.* implements the polar version of this. You'll need to add detection and configuration options for libsodium to configure.ac too. For the control channel, your starting point would be the ssl.h and ssl_backend.h files. I don't know how closely these match up to the cryptobox API... If we're lucky, you might be able to do something there. If not, have a look at the (external) multiplexer code, and see whether that can be refactored to your purposes. > I'm still a bit unsure what you mean by "TLS" though? To my mind it's > a protocol for negotiating parameters and implementing crypto. However, > I > *think* that what you might mean is that it's "an API which handles > client session state, timeouts and creating packets to put on the > network"? > It's used as the former in OpenVPN, as OpenVPN does packet handling, session state and timeouts itself. I have no idea how closely the whole API used in OpenVPN matches the cryptobox API, but it certainly isn't written for it. > Perhaps I need to get my hands dirty here... Sounds like we would need > to introduce an abstraction for the TLS session handling so that this > feels clean? > > Note, I have a longer term interest here in multi-homing. > That's important, as all code in OpenVPN needs to be actively maintained, and there's only a small group of developers working on the project. Hope that helps! Adriaan
