Repository files navigation

This is a fork ofOpenSSL to enable QUIC. In additionto the website, the official source distribution is athttps://github.com/openssl/openssl. The OpenSSLREADME can be found atREADME-OpenSSL.md.

This fork adds APIs that can be used by QUIC implementations for connectionhandshakes. Quoting the IETF Working groupcharter, QUIC is a "UDP-based,stream-multiplexing, encrypted transport protocol." If you don't need QUIC, youshould use the official OpenSSL distributions.

The APIs here are used by Microsoft'sMsQuic and Google'sChromium QUIC

We are not in competition with OpenSSL project. We informed them ofour plans to fork the code before we went public. We do not speak for theOpenSSL project, and can only point to ablog post andopenssl-project emailthat provides their view of QUIC support.

As stated in their blog post, the OpenSSL team is focused on their 3.0 release(released 2021-09-07), and does not intend to add QUIC functionality to 1.1.x.There is a community need for a QUIC-capable TLS library. This fork is intendedas stopgap solution to enable higher level frameworks and runtimes to use QUICwith the proven and reliable TLS functionality from OpenSSL. This fork will bemaintained until OpenSSL officially provides reasonable support for QUICimplementations.

This fork can be considered a supported version ofOpenSSL PR 8797.We will endeavor to track OpenSSL releases within a day or so, and there is anitem 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 current plan is to append+quic. Release tags are likely to be the QUIC branch with-releaseX appended.For example, the OpenSSL tagopenssl-3.0.0 would have a branch namedopenssl-3.0.0+quic and a release tag ofopenssl-3.0.0+quic-release1.

(In other words, "What about rebasing?")

Our plan is to always rebase on top of an upstream release tag. In particular:

• The changes for QUIC will always be at the tip of the branch -- you will know whatis from the original OpenSSL and what is for QUIC.
• New versions are quickly created once upstream creates a new tag.
• The use of git commands (such as "cherry") can be used to ensure that all changeshave 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, andany changes to that can be easily identified.

Library names will be the same, but will use a different version number. The versionnumbers for the current OpenSSL libraries are1.1 (for the 1.1.0 and 1.1.1 branches)and3 (for the 3.0 branch). We will be prefixing81 (ASCII for 'Q') tothe version numbers to generate a unique version number.

• libcrypto.so.81.3 vslibcrypto.so.3
• libcrypto.so.81.1.1 vslibcrypto.so.1.1
• libssl.so.81.3 vslibssl.so.3
• libssl.so.81.1.1 vslibssl.so.1.1

The SONAME of these libraries are all different, guaranteeing the correct librarywill be used.

We currently do not have any plans to change the name, mainly because wehaven't made any changes there. If you see a need, please open an issue.

Theopenssl version command will report that it is+quic enabled.

We are not doing anything with FIPS. This is actually good news: you shouldbe able to load the OpenSSL 3.0 FIPS module into an application built againstthis fork and everything should Just Work™.

We want any code here to be acceptable to OpenSSL. This means that all contributorsmust have signed the appropriatecontributor license agreements. Wewill not ask for copies of any paperwork, you just need to tell us that you'vedone so (and we might verify with OpenSSL). We are only interested in making iteasier and better for at least the mentioned QUIC implementations to use a variantof OpenSSL. If you have a pull request that changes the TLS protocol, or addsassembly 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 extensionto OpenSSL, with the deltas being specific to QUIC.

This is a collaborative effort betweenAkamai andMicrosoft. We welcome anyone to contribute!