This is a report of things that are currently taking place in our work on
the TLS Pool. Even if changes are currently made in a development branch,
their impact is going to be major once it is checked into the mainstream
branch.
What is the TLS Pool?
The TLS Pool project is a design of a program that handles authentication and encryption of TLS. You may know TLS as SSL, or even just as the protocol that turns websites into secure sites -- even if it also protects your submission and retrieval of email, your chat and much, much more.
The idea of making a separate program (that runs in the background) for TLS is that this separates the sensitive handling of security mechanisms and keys from the applications that sometimes hold rather frivolous code -- including adverse code such as advertisements that may do anything to get an idea of who you are and what you are up to.
In addition, although we don't discuss it here, it is possible to use the TLS Pool under our SteamWorks architecture, which means it can be controlled centrally. In other words, the complexity of security settings can be turned into a service that may be organised and controlled by a knowledgable specialist party.
More than just TLS
The initial versions of the TLS Pool were full of TLS. The code and ideas of this protocol were everywhere. We restructured the code to concentrate everything TLS-specific in one module, so that future extensions could choose to use other protocols instead of TLS.
The idea behind this is that TLS itself has problems at times. Ideally, there would be alternative carriers, perhaps the OpenSSH protocol or something based on GSS-API. Being able to setup multiple such protocols in parallel and then to weed out one that is (temporarily) having problems offers great control to the security officer.
This extension may seem far-fatched, but it isn't. Not really. Most protocols start without TLS protection, and then issue a command that is often called STARTTLS to turn the connection into a TLS-protected connection. There is no reason why there could not also be commands STARTSSH and STARTGSS to do the same thing with another protocol. The only thing that would need to be done is to define such extensions, and get them implemented in software.
As far as the TLS Pool is concerned, this change can be started. Although it is not directly usable, the internal structures of TLS Pool have been adapted to be highly supportive of this change.
Separating out service knowledge
Under the TLS Pool, knowledge about TLS and its configuration is kept away from the application. This helps to simplify applications, and thus to keep them secure with less effort. Examples we've seen in adding TLS to an application ranged from hours to days of work -- because all that the application needs to do is hand off a connection and start a new TLS-wrapped connection. If it wants authentication, its only requirement is to offer and consume the established identities that the TLS Pool provides as a result of its setup work.
As a result of this, it has also been necessary to take out service knowledge; that is, how to differently treat certain security aspects of web versus that of email versus that of chat, and so on. This is now handled by simply naming the protocol in a standardised way, and let the TLS Pool derive from that how to deal with it.
Part of this handling may be configured by a (central) security officer, who may decide that some protocols deserve different treatments from others. All this refined control is available to the application if it only does what it can very easily do -- provide the name of the protocol it runs within the TLS connection.
Local Identity Selection
The local side of a TLS connection may need to prove its identity to the remote peer. It may be desirable to select the local identity in a manner that depends on the remote peer's identity. Reasons for this include privacy, and the desire to change from a personal identity to a group or role identity.
The new TLS Pool comes with an extra interface over which a user can register to be asked when identity decisions are made. Such decisions may be popped up in a manner that is standard for the operating system environment, and choices can be stored for later reuse if it turns out that the selected local identity succeeds in terms of TLS setup.
It is especially useful that this happens through a separate interface, and not as part of an application's interaction with the TLS Pool. For one, this keeps applications simpler and therefore easier to secure. Secondly, the application may contain frivolous code that should not get in the way of these privacy-sensitive choices. Thirdly, users will appreciate having one central and standardised interface for these operations that sets up the same identity for all kinds of protocols relating to the same remote peer. Finally, it is possible to construct an identity selection mechanism based on a simple menu where one sets the identity that should be used for all current actions, and that identity can be changed with a simple pull-down menu in a standard place of one's interaction with the system.
End-User Password Exchange
Even when two parties are connected, they may still have a hard time exchanging a password or other secret key. One side may generate a value and pass it on, but that does not always lead to the same security level as provided by TLS itself.
To remedy that, a standard has been created for derivation of passwords based on the complete TLS security that has been established. This standard has been implemented in the TLS Pool. This permits applications to do such things as pick a password securely while on a web page, or engaged in a chat session, and so on.
Better Anonymisation of Traffic
Before the TLS connection is setup, it exchanges credentials that may leak private information to bystandars, including rogue inspectors of traffic. There is a facility that first achieves an anonymously encrypted session, and then continue exchanging the privacy-leaking credentials under that cloak. This facility is not commonly used, but it helps because it makes it impossible to do such rogue inspection without being noticed.
The TLS Pool has been extended to consider the service that is being run over TLS, and based on that to make a choose whether anonymisation would be safe to incorporate. Doing this means that the TLS Pool can be very tight in using this anonymising precursor to the rest of the TLS exchange.
Preparation for Symmetric TLS
The TLS protocol normally needs to be quite sure which side acts as a client, and which acts as a server. Although that is reasonable for applications such as the web and email, it is not necessarily so with modern developments.
The client-server model on the Internet is progressing towards monstrous-sized server parks, which are devestating to the distributed model that makes the Internet such a powerful mechanism. We won't even begin about the potential impact that such "central" sites can have on end-user privacy. In a logical response, we see a strong movement of Internet technology towards more peer-to-peer functionality; although started off as file sharing technology, these functions are now also used for things such as chat, telephony and more.
Such a model does not have the clear separation between client and server roles. The old TLS Pool would start TLS as a client or as a server, but the new version will simply start TLS, and use a couple of flags to signal for the local and remote sides if they could be a client and/or a server. The ability to specify that either is acceptable is helpful towards the client-server model. As soon as the TLS stack supports it, the TLS Pool can start to use that and be highly beneficial for such modern directions of Internet development.
In addition to the above, the authentication model has moved along; rather than speaking in terms like client identity and server authentication, the change has been made to speak in terms of local and remote authenticated identities, and whether they are locally provided and remotely required. The result is a more evenly balanced TLS model that can still do everything the old model did.
Efficiency Updates
When initiating TLS, the TLS Pool assumes that a connection has already been setup. It is then passed this connection, and a new connection with TLS added was passed back. We changed this, and now let the application pass in a connection over which TLS should be used.
This is a minor (although incompatible) shift in how the interaction with the TLS Pool works, but it is a major benefit in terms of efficiency. Connections can now be completely handed off to the TLS Pool if the external connection can be setup. Its main benefits are less context switches (which make a processor purge its state and start from scratch).
In terms of user applications, it is now very straightforward to have a tunnel setup TLS and then disconcern themselves from the process. This means that a TLS tunnel can be highly scalable. And yes, we're including precisely such a tunnel with the TLS Pool.
Flexibility through Detachable Control
We have improved the flexibility of handling the TLS Pool from applications. One application may "detach" the control over a TLS connection and another application may pick it up. This gives application programmers greater control over the TLS Pool.
Possible extension: On-the-fly Certification
Some applications work better when a trusted component sits between a TLS end point and the general Internet. To do this, the trusted component usually terminates the TLS connection, and protects all its traffic to the end point with certificates that it generates on the fly.
This is a function that we are currently considering for inclusion into the TLS Pool. We are not yet sure if it belongs in the TLS Pool itself, or in a tunnel application running on top of it. The design of the TLS Pool however, is based on strong protection of security credentials behind a PKCS #11 interface, and that may be a good reason to add it to the TLS Pool.
I dare say, we do have something cooking...
Go Top