This is a fork of OpenSSL to enable QUIC. In addition to the website, the official source distribution is at https://github.com/openssl/openssl. The OpenSSL README can be found at README-OpenSSL.md.
This fork adds API that can be used by QUIC implementations for connection handshakes. Quoting the IETF Working group charter, QUIC is a "UDP-based, stream-multiplexing, encrypted transport protocol." If you don't need QUIC, you should use the official OpenSSL distributions.
The API's here are used by Microsoft's MsQuic, and Google's Chromium QUIC, and others.
We are not in competition with OpenSSL project. We informed them of our plans to fork the code before we went public. We do not speak for the OpenSSL project. They have since announced their plans to do their own QUIC implementation, now that the 3.0 release is done.
There is a community need for a QUIC capable TLS library, for both the 3.0 and 1.1 streams. This fork is intended as stopgap solution to enable higher level frameworks and runtimes to use QUIC with the proven and reliable TLS functionality from OpenSSL. This fork will be maintained until OpenSSL officially provides reasonable support for QUIC implementations.
This fork can be considered a supported version of OpenSSL PR 8797. We will endeavor to track OpenSSL releases within a day or so, and there is an item below about how we'll follow their tagging.
On to the questions and answers.
We don't want to conflict with OpenSSL branch names. Our plan is to append +quic to upstream tag names to create our branches. Release tags will be the upstream tag name with -quic1 appended (where 1 will be the incrementing release number). For example, the OpenSSL tag openssl-3.0.10 would have a branch named openssl-3.0.10+quic and a first release tag of openssl-3.0.10-quic1. Please note that this is not compatible with semantic versioning, as any version with a -value suffix is sorted before the version (i.e. openssl-3.0.10-quic1 < openssl-3.0.10). Using a + can remediate thie, but some release tools don't like the +.
(In other words, "What about rebasing?")
Our plan is to always rebase on top of an upstream release tag. In particular:
cherry) can be used to ensure that all changes have moved forward with minimal or no changes. You will be able to see "QUIC: Add X" on all branches and the commit itself will be nearly identical on all branches, and any changes to that can be easily identified.Library names will be the same, but will use a different version number. The version numbers for the current OpenSSL libraries are 1.1 (for the 1.1.0 and 1.1.1 branches) and 3 (for the 3.0 branch). We will be prefixing 81 (ASCII for 'Q') to the version numbers to generate a unique version number.
The SONAME of these libraries are all different, guaranteeing the correct library will be used.
We currently do not have any plans to change the name, mainly because we haven't made any changes there. If you see a need, please open an issue.
The openssl version command will report that it is +quic enabled.
We are not doing anything with FIPS. This is actually good news: you should be able to load the OpenSSL 3.0 FIPS module into an application built against this fork and everything should Just Workâ˘.
We want any code here to be acceptable to OpenSSL. This means that all contributors must have signed the appropriate contributor license agreements. We will not ask for copies of any paperwork, you just need to tell us that you've done so (and we might verify with OpenSSL). We are only interested in making it easier and better for at least the mentioned QUIC implementations to use a variant of OpenSSL. If you have a pull request that changes the TLS protocol, or adds assembly support for a new CPU, or otherwise is not specific to enabling QUIC, please contribute that to OpenSSL. This fork is intended to be a clean extension to OpenSSL, with the deltas being specific to QUIC.
This is a collaborative effort between Akamai and Microsoft. We welcome anyone to contribute!