We just released a new API version for the TLS Pool, with many
improvements. There are still things missing, but these have mostly
been designed and are in the process of being turned into code.
For an overview of the recent changes see Something's Cooking #1 or the GIT version with these changes.
Up next: Validation... finally!
It may sound silly... the TLS Pool is an architectural improvement on how we manage TLS connections such as secure websites, but the most vital part of it is still pending. This is the actual validation of the remote identity.
The reason for this is simple. We didn't want to launch a "first stab" that would do a few things right, but without proper integration with the rest of our framework. We are now ready, in terms of design, to add validation in a way that we feel to integrate properly. It should be obvious that this is a major requirement before the TLS Pool can actually be put to use.
Clever Databases
As described in the TLS Pool documentation, the TLS Pool maintains a number of databases that parameterise the TLS Pool with just what it needs to know about certificates, keys and passwords. These are the so-called credentials, and we setup a refined system to help its users control how to authenticate remotely, such as what external identity to portray; this is an important part of our policy to Bring Your Own Identity which we feel is an important step to let users control their online presence.
The databases that control TLS Pool behaviour contain the following information:
- Local identities include credentials, including references to private key material behind a protective PKCS #11 interface;
- Remote identities map remote peer identities to the local identities that we have decided to reveal to them;
- Trust details the trust anchors that we rely on;
The latter is in fact a new addition that we introduced for the validation framework.
Sources of Validation Constraints
The three databases represent different angles on the TLS process, and each of these angles could give rise to constraints to be applied to the validation of the TLS Pool:
- Some of our local identities may only be used in highly secure connections;
- Certain remote identities may only be trusted under extremely rigorous security checks, while we could be more relaxed about others;
- A particular trust anchor may only be trusted when certain added constraints are validated.
This means that the databases, in which we already tend to lookup information for the purposes of TLS connection setup, provide us with excellent places to store validation constraints. The constraints found in these three sources will be combined; each of them must independently apply.
Several of the lookups in databases actually follow a search path; that is, if an exact match is not found then a more general alternative is tried, until we hit on a match or until we cannot generalise any further. The mechanism used is that of the DoNAI Selector, because that links well with various Internet technologies, and indeed it lends itself rather well for introducing constraints; we also described a similar idea for access control before.
Expressing Validation Conditions
The expression of validation conditions is done in the form of a logical formula; ideal for both administrators and automatic processing vehicles such as the TLS Pool. The nice thing of these formulae is that they can be combined at will, without structural exceptions.
We have even designed the validation system to be, as much as possible, independent of the type of authentication system used; for instance, DNSSEC-based validation would be implemented through DANE's TLSA records for X.509 certificates, and through CERT records for OpenPGP keys. And if we ever add OpenSSH as an alternative transport to TLS, then the DNSSEC-based validation would make use of SSHFP records.
This style of validation is much more general and much more expressive than the customary choice between cipher suites, which is more technical and more zoomed-in on incidental technology. We do achieve the same effect, but at the same time we establish a mechanism that can describe alternative protection mechanisms. This is a main part of the design of the TLS Pool, to have many security mechanisms to choose from, so as to be able to switch to another game when the originally used game is over, for instance during temporarily elevated security risks.
Checks to be Built into the TLS Pool
The following is a current list of the types of elementary validations that we intend to make combineable through logic expressions in the three databases mentioned; each is represented with a single letter, where uppercase indicates a stronger check than the lowercase form:
- Trust anchorage (T, t)
- No known revocations (R, r)
- Forward secrecy (F, f)
- DNSSEC-based identity checks (D, d)
- Pinning, including TOFU-style (P, p)
- Anonymous precursor privacy (A, a)
- Online / live information checking (O, o)
- Global Directory checks (G, g)
- User-defined security levels (L, l)
- Presence of remote identity (I, i)
- Extensions / flags fit for purpose (E, e)
- Username match (U, u)
- Server-only and Client-only roles (S, s, C, c)
Each of these mechanisms gives rise to separate lookups of (online) information that leads to a positive or negative decision about the validity of the connection built up in the TLS Pool. When positive, the connection passes and may be used by the application; when negative, the connection will be reset and the application receives an error message.
Distributed Control
The requirement to specify this type of expression may feel like a burden, because it is rather technical in nature. But this is precisely the purpose, namely to control security with a fine comb. It is not our intention however, to load this burden onto every user.
We have an infrastructure prepared to setup these fine controls over security in a central place, and distribute them to users in various places. This is the SteamWorks infrastructure. This uses LDAP technology to download configuration information, and stay up to date with new settings. The resulting system is the best of all worlds, where changes in security settings pass through to end-user and server stations almost immediately, provided that they are online.
The setup of the TLS Pool around databases now pays back; external programs are permitted to modify the database, and precisely that is what we intend to do for the TLS Pool; namely, to extract data with a so-called Pulley component from the SteamWorks architecture, and to deliver the information found in these databases that steer TLS Pool behaviour.
Authentication Framework Integration for Applications
Within a connection whose transport security is protected by the TLS Pool, there usually is a desire to authenticate a remote user. Since the TLS Pool supplies authenticated identities for both the local and remote peer, and since these are subjected to validation procedures that can be flexibly controlled by professional administrators, there is no need for individual applications to concern themselves with the mundane details of authentication and security. This is a design goal of the TLS Pool, to separate the tightness of security from the frivolity of application logic.
The separation may be a new idea, but the mechanics are actually available in current-day protocols. It is very common to use SASL as an authentication mechanism inside TLS; this is in fact inefficient and less secure than it could have been, because the encryption in the TLS connection is not cryptographically bound to the authentication of SASL. It is a method for using relatively weak password-based authentication mechanisms, though.
But instead of this two-stage process, it is possible to rely on a special authentication method within SASL that is called SASL EXTERNAL. This mechanism was designed to make use of any authentication that could have been setup in an outer layer -- and our TLS Pool is a very obvious example of this mechanism. With SASL EXTERNAL, the application logic only needs to say "I would like to be jimmy@example.com today" and a simple check with the credentials provided by the external layer (in casu, the TLS Pool) will suffice to pass the request.
I dare say, we do have a thing or two cooking...
Go Top