The OpenSSL community is a diverse group, ranging from those that use applications that depend on OpenSSL (effectively end-users) to operating system distributions, application developers, embedded devices, layered security libraries, and cryptographic algorithm and protocol researchers. Each of these subsets of our community have different needs and different priorities.

In the last few years, the project has been working to address a number of major technical challenges within the code base to better support the broader requirements of the OpenSSL community. We have made the main data structures opaque (allowing for restructuring and fixing issues without application developers having to work directly with the implementation internals), we have strived to make APIs more consistent, we have improved the test coverage and the API documentation. We have addressed the architectural issues which made extensibility challenging (adding algorithms and implementations) and added a clear separation between APIs for usage and APIs for implementation.

These changes enable those community members that need to go through formal validation programs, such as FIPS, to be able to do so with a path that enables on-going updates (rather than requiring orphaned versions that cannot address vulnerabilities over time). It also enables researchers to experiment with new cryptographic algorithms, and developers and organisations to offer alternate implementations of existing algorithms. The previous approaches within OpenSSL all had challenging issues which precluded broad usage.

Traditionally, OpenSSL has operated via an entirely ad-hoc release planning process. Releases have occurred at various intervals with the collection of features being open ended and the release dates always being aspirational. This approach directly leads to the timing of releases being unpredictable (they basically are released when they are “finished”). Our community has asked us to address the issue of unpredictable release features and unpredictable release timing and we are working to address those issues. To that end our objective is to have shorter release timeframes, with releases occurring every six months. It may take us a while to get to that point.

The next major capability area we are addressing is the APIs for interacting with multiple security protocol implementations. Within OpenSSL we have traditionally had a set of protocol versions (e.g. SSL, TLS, DTLS) and interfaces for alternate protocol handling (e.g. Kernel TLS), however these interfaces have evolved relatively independently. A significant portion of our community wants to be able to produce applications which can simply select which protocols to support at runtime and have the OpenSSL codebase handle whatever is required in order to achieve that. This request also encompasses being able to add new security protocols (like QUIC) without requiring applications to perform major work. Clearly, achieving that objective is going to require substantial development work which we have decided to spread out over a number of releases in logical collections of capability. We are currently in the design phase for this work.

Ultimately, the objective is to have APIs that allow applications to support any of our existing (or future) security protocols and to select between them with minimal effort. Our current set of protocols have different requirements in a number of areas (and correspondingly additional APIs and usage models that make this challenging). Our APIs currently do not abstract the interfaces to the different security protocols in a manner that makes this straight forward. For example:

• we support a read/write interface at multiple levels (SSL_read/SSL_write/BIO_read/BIO_write);
• connection establishment and network interfacing operate in slightly different manners for TLS and DTLS;
• we allow applications to handle blocking and non-blocking I/O with different approaches;
• we do not force a specific network event handling model (event loop, select/poll, threading) on application developers.

We don’t currently offer APIs to allow handling of multiple streams. In TLS/DTLS each connection represents a single stream and each connection is treated separately by our APIs. In the context of QUIC, APIs to be able to handle a collection of streams will be necessary for many applications. With the objective of being able to select which security protocol is used, APIs that encompass that capability for all protocols will need to be added.

The majority of existing applications operate using a single connection (i.e. effectively they are single stream in nature) and this fundamental context of usage needs to remain simple. Our focus will be to enable the majority of our existing user’s applications to be able to work in a QUIC environment while expanding our APIs to enable future application usage to support the full capabilities of QUIC.

As part of our work, we will end up with interfaces that allow other QUIC implementations (outside of OpenSSL) to be able to use the TLS stack within OpenSSL – however that is not the initial focus of the work. For those working with other QUIC implementations, there are already existing patches for both OpenSSL-1.1.1 and OpenSSL-3.0 that meet their technical needs. What we have been asked for repeatedly by other QUIC implementations is for a long term supported core API for external QUIC library implementation usage in a future OpenSSL release. This will be provided as part of the work we are undertaking. Getting in place an OpenSSL QUIC implementation that can support both existing and future applications is necessary work that must be completed to ensure that the APIs we provide for external QUIC implementations are fit for purpose (both for internal OpenSSL QUIC usage and for external non-OpenSSL QUIC usage) and that they are supportable in the long term.

Ultimately our goal is to make it easy for our users to communicate securely, flexibly and performantly using whatever security protocol is most appropriate for the task at hand. We want to provide unified, consistent APIs to our users that work for all types of applications ranging from simple single stream clients up to optimised high performance servers. This will take effort to achieve but we believe that the result will be a better OpenSSL that not only meets the needs of our existing users today, but will also continue to meet the needs of the OpenSSL community for many years to come.

Our community has always been active and supportive. If you would like to support us in this journey then please get involved on github, become a personal or corporate sponsor or take out a support contract. We look forward to engaging further with our users during this process as we work out the details of what this will look like.