#13 Allow VTun to Connect to Non-SSL VTun

[Anonymous]

+ *
+ * Artur R. Czechowski <arturcz@hell.pl>, 02/17/2002
+ * Add support for connectin ssl to non-ssl vtuns (sslauth option)
+ * Use /dev/random in non-ssl gen_chal (if possible)

http://canterville.mine.nu/debian/vtun/patches_for_bishop/00-sslauth.dpatch

[Nobody/Anonymous]

[Andrey Mazo]

I've rebased the patch against (latest as of now) version 3.0.3.
It compiles for me, but it's not tested yet.

[Bishop]

In light of papers by folks who compile vtun without ssl support as a means of showing how insecure vtun is compared to their own offering, this kind of patch is highly-sensitive.

The general stance on VTun compiled with no security support is that it's not supported, not built by default, not recommended, not compatible with regular builds and not discussed. It's the only way to help ensure we stay above the rumour mill, IMHO.

Please consider:
- change the logic to --disable-ssl vs --enable-ssl
- make the default with SSL enabled and required
- require the user to specifically disable SSL
- include a logged warning that encryption is disabled
- include a statement about the risks of building with no encryption support in code, documentation, man pages, and READMEs, with mention that such builds are not supported.

Those suggestions are off the top of my head, however, and I'm open to others.

[Andrey Mazo]

Thank you for your quick reply and suggestions!

In contrast to the general stance, I have a need for a tunneling solution with as few external dependencies as possible and I prefer simplicity (and speed) over security.
While building vtun for a restricted embedded environment and thus dropping openssl as an external dependency, I want a non-ssl vtun to be interoperable with ssl vtun, which, in turn, runs on a regular machine and thus have openssl available.
So I'm kind of upset with your statement, that non-ssl vtun should not be supported and not be compatible with ssl vtun.

As far as I understand, your suggestions just deserve a separate patch (and maybe a separate ticket) and only partially relate to the sslauth patch itself.
The sslauth patch adds sslauth option that allows ssl vtuns talk to non-ssl vtuns.
Your suggestions touch defaults in configure.in, defaults in source code (in case sslauth is not set in config file), some user-oriented warnings and documentation.
I believe, your suggestions just should be done as a separate changeset on top of the sslauth patch, but, please, correct me if I'm wrong.

I'll try to take a look at your suggestions and prepare a patch for them as they all seems to be doable in my spare time.