Releases: arpa2/tlspool
Updates to testdata
Help to build on newer versions of dependent tools.
Version bump release
Gearing up to construct a Docker build or demonstration environment.
MXE port for Windows
Added better namedpipe support, lidentry and pinentry for Windows.
Added TLS-KDH to the TLS Pool
Finally we've incorporated the very big improvement to TLS that we wanted to offer: setting up the connection with Kerberos tickets in combination with Diffie-Hellman.
For details and background, please see Tom's master's thesis or the project website or of course our Internet Draft for which this work was based on 04, but gave us input for a soon-to-be-released 05 version.
0.19 beta1 release
With small fixes that improve the build process, especially also from a tar ball.
0.18 beta1 release
A catch-up hosting a number of small improvements.
Most notably, libtlspool can now make inquiries into a configuration file.
First beta release
The TLS Pool can demonstrate a number of useful principles:
- carefully split views on security: application, TLS, user interaction
- no longer does an application decide on what TLS can accomplish
- no longer does an application get hold of private keys, are handles to it
- applications need only know about local/remote identities, not certificates
- this dramatically simplifies the addition of security to an application
- per-remote settings of disclosure of local identities (with GUI over API)
- protection of secret keys by any PKCS #11 compliant (hardware) token
- applications cannot use PKCS #11 beyond setting up a TLS connection
- easily swappable security mechanisms
- the TLS Pool APIs are generic and can be re-implemented by others
- the TLS Pool can have backends for STARTSSH, STARTGSS on top of STARTTLS
- dynamic configuration through databases
- trust.db holds root CAs, PGP signers, pinning information
- disclose.db explains who may see what local identity
- localid.db defines credentials for local users, plus private key locations
- backend for SteamWorks Pulley can write to these databases
- TLS Pool + SteamWorks == provisioned TLS profiles
- validation expression logic
- a logic framework with the first few elementary tests included
- logic is mostly independent of authentication mechanism
- though synchronously coded for now, prepared for async operation
- support for global directory (remote LDAP) validation
- validation expressions are setup in the trust.db or localid.db
Work still planned or still in progress:
- Kerberos support; working on integration with GnuTLS-KDH, Kerberos code may actually move into GnuTLS if Nikos agrees on a more elaborate API change. With this we will have:
- a highly efficient, scalable and robust authentication mechanism
- connection with our future plans of realm crossover
- Windows porting has solved the most nettly problems, and is now in the process of catching up with recently added dependencies
- Anonymous precursors are a first phase of anonymous session setup, continued into one where the (normally public) credentials are exchanged; this work has not been finished yet
- Security Level settings default / higher / highest can be requested in the validation expression logic, but need to be specified and implemented. Probably using a framework for the estimation of key size development over time, so you can get away with saying "RSA @ 2005 >= 1024" and it will infer what that means at the time the check is being made.
Things being considered:
- Multi-user support (one daemon serving multiple individual system users)
- More validation expression predicates: OpenPGP signing, DANE, CRLs, ...
- Usability for HTTPS (outgoing as a proxy, and incoming as a web server)
Fixed compiler problems
Removed build warnings and an unexplained linker error in test/
Validation Expression Logic
TLS Pool early release
This is a developer's release holding the Windows port, but no validation code or TLS-KDH or SteamWorks integration yet.