-
Notifications
You must be signed in to change notification settings - Fork 2
Design Decisions
On this wiki page we should list out the design decisions that are being taken for the development of vtls and mark them as they are finalized by consensus. If the discussion for any particular item becomes too long, we can migrate it to its own Wiki page.
libvtls will be a shared-object library that applications can dynamically link to.
Daniel: but that really doesn't exclude that users should be able to build it statically, or even embed the complete source into other projects - even if discouraged.
This should be one of the lesser contested decisions. An MIT or a BSD license should the ideal choice.
Daniel: being based on libcurl's code, it is MIT licensed already and it would be quirky and tiresome to try to change it. I suggest we stick to that license.
This is currently being debated on the vtls mailing list. While it is true that supporting server-side TLS APIs will be extremely difficult, even some rudimentary support might be useful to a variety of application developers. Current consensus seems to be at, "it would be a good feature to have in the future, but client-side support only for now"
vtls under libcurl currently supports 11 TLS libraries:
- axTLS
- DarwinSSL (also known as SecureTransport)
- CyaSSL (soon to be known as WolfSSL)
- GSKit
- GnuTLS
- NSS
- OpenSSL
- BoringSSL (an OpenSSL fork maintained by Google)
- libressl (an OpenSSL fork maintained by the OpenBSD team)
- PolarSSL
- schannel
Supporting more libraries will remain the goal of vtls. However, for now vtls will support only the above listed TLS libraries until such a time as there is a stable release of vtls with complete client-side support for the above libraries. Supporting additional TLS libraries should only be done later.
The exposed interface will The interface being currently used by vtls in libcurl is considered to be a good starting point. However, soon enough, that interface will start falling short of the requirements and will have to be extended / amended.
However, most have voiced their opinions that they would prefer to develop an interface that is simple to use rather than flexible. The whole idea of vtls is to abstract the hide the idiosyncrasies of the different TLS libraries from application authors. Tim Ruehsen provided the following, very simple API which would be enough for most use cases:
ssl_global_init(global settings)
session = ssl_open(session config)
ssl_write(session)
ssl_read(session)
...
ssl_close(session)
ssl_global_deinit()
Should vtls require an open network socket or shoudl it handle all of that internally based on IP/Hostname? vtls should remain just that, A virtual TLS Library and should not handle network operations at all. It should provide an interface for only those functionalities which actual TLS libraries provide.
While this question was raised by dkg, there's been no discussion about it at all. vtls should provide a sane set of defaults that works across all the major TLS libraries. Employing best practices for security based code should no longer be the onus of each application developer. vtls should provide those by default. What exactly are sane defaults and best practices? We need to come up with a list for that; but dkg provided the following reading material:
How portable should vtls be?
vtls should aim for supporting POSIX systems with the exception of Windows, since a native Windows library already exists within vtls.
Apart from that, the code should be strongly C89 compatible. There are still lots of compilers and architectures that do not support C99 properly. We want vtls to run on such machines and hence stick to C89 only.
- Should it be possible to build a package against vtls, and then at run-time have it adopt a different TLS implementation?*
This topic is currently still being discussed on the mailing list with little available information. Distro maintainers want Build-Time selection. It would be easier for the vtls developers to maintain a build-time selection too. But this removes some amount of freedom from the users.
vtls will currently focus purely on a good and easy to use C API. Others are free to work with vtls and develop language bindings as they wish