What is this "TLS Pool" system?

The TLS Pool is a central daemon running on your server system, or perhaps under your personal desktop session. It manages your TLS connections from one central place.

Programs that wish to employ TLS basically hand over a normal connection to the TLS Pool, and receive a TLS-protected connection back in exchange for it. Then they can continue to communicate without further awareness of the TLS-wrapping that has taken place.

This approach can be done at the beginning of a protocol, which is the original way TLS was used; or it can be used by any protocol implementation at the point it is processing a STARTTLS switch.

The TLS Pool is a pure TLS implementation, so it can communicate with both a TLS Pool on the remote end, or any other TLS implementation. One thing that sets TLS Pool apart however, is its wide range of implemented features, and its consistent, central control to determine which of these features are welcomed and which are not.

What makes the TLS Pool useful

Centralisation of TLS. The TLS Pool can centralise all use of TLS on a system, be it a complete server or an individual user's desktop. There are always positive and negative sides to the choice of centralising a function.

A disadvantage that immediately springs to mind is that the TLS Pool forms a single point of failure, and a single point of attack. This is true, but it hardly differs from the practice in other systems; every individual program installation makes a choice to rely on one particular TLS implementation, and this is still that program's single point of failure — and attack.

The major advantage of centralisation into a TLS Pool is simplification of maintenance. When security patches are required, they can be installed in a single place and all dependent programs are updated accordingly. Also, the extension with new security extensions that appear in Internet standards for TLS is much more straightforward in infrastructures that employ one central implementation, rather than a diversity that may in part even be wrapped up into closed-source third-party applications.

Generally, when defining a policy that sets a lower bound to online security, the diversity of TLS implementations used means that it is only possible to stick to a rather modest greatest-common-divider of TLS' security facilities; not even client-side X.509 certificates may be possible, let alone advanced features such as SRP, let alone useful infrastructural components such as our planned Kerberos integration into TLS. This is remedied by centralising TLS handling into a single, modern program.

Separation of process contexts. The big improvement made by the TLS Pool is that it isolates secret credential handling from application programs. Consider a web server; it is normally available to anyone anywhere; it usually runs the PHP scripting language which is designed with a rather different mindset than that of a security programmer; it facilitates applications which are not usually kept up to date as well as the web environment itself; and within this problematic context it loads private keys needed to encrypt sessions.

Similar problems are common on the client side. Look at the web browser, which runs rather powerful JavaScript code, often loaded from dynamic locations that include parties with a mindset that is not the end user's (namely advertisers and providers of "free" online services). This same JavaScript environment is quickly gaining access to credentials, even though better alternatives exist at the HTTP and TLS level. These alternatives however, are not part of the greatest-common-divider and are therefore not encouraged by most implementers.

Facilitation of hardware-protected keys. Using the TLS Pool, all handling of security credentials can already be taken out of the dynamic and often problematic context of an application. This means that the process that faces the external World of the Internet might be subject to a remote attacker, but the operating system still isolates the assaulated process from the TLS Pool.

In addition, the TLS Pool itself does not even handle the private and secret keys needed for its operation; it delegates that to the specialised interface known as PKCS #11. This is an API intended for use with "cryptographic tokens", which is a term covering low-cost USB-tokens that plug into a desktop to large, expensive, redundant Hardware Security Modules. Moreover, implementations of PKCS #11 in software exist, and there are proxies for addressing PKCS #11 implementations on remote machines.

The redistribution of this credential-handling responsibility hardly has an impact on performance, since the bulk of the security operations are carried out with temporary "session keys" which are available inside the TLS Pool, but which are only useful for the sessions run at that moment. The long-term secrets are needed to bootstrap these session keys, and that requires an action over PKCS #11.

How the TLS Pool is designed

The TLS Pool is a separate program, running in the background; on POSIX systems, this is generally called a "daemon" program.

To speak to the TLS Pool, software needs to send their connection to this program, and receive an encrypted connection back in exchange for it. To do this, an interface has been defined. Each individual program can access this interface and get a very straightforward implementation of TLS in return. In fact, applications that currently rely on TLS implementations may prefer to replace their code with this new approach, simply because it makes them less dependent on the quality of the TLS stack that they have selected. This should be of particular interest to closed-source third-party software providers.

A number of tasks permit generic resolutions. Some protocols simply wrap a TCP connection in TLS, and this "tunnel" style behaviour can be achieved with a generic wrapper that uses the TLS Pool. Specific applications, such as HTTPS, can be handled through a proxy for the protocol on the client side, and plugins for server programs on the other side.