1What This Is 2============ 3 4This is a fork of [OpenSSL](https://www.openssl.org) to enable QUIC. In addition 5to the website, the official source distribution is at 6<https://github.com/openssl/openssl>. The OpenSSL `README` can be found at 7[README-OpenSSL.md](https://github.com/quictls/openssl/blob/openssl-3.0.2%2Bquic/README-OpenSSL.md) 8 9This fork adds APIs that can be used by QUIC implementations for connection 10handshakes. Quoting the IETF Working group 11[charter](https://datatracker.ietf.org/wg/quic/about/), QUIC is a "UDP-based, 12stream-multiplexing, encrypted transport protocol." If you don't need QUIC, you 13should use the official OpenSSL distributions. 14 15The APIs here are used by Microsoft's 16[MsQuic](https://github.com/microsoft/msquic) and Google's 17[Chromium QUIC](https://chromium.googlesource.com/chromium/src/+/master/net/quic/) 18 19We are not in competition with OpenSSL project. We informed them of 20our plans to fork the code before we went public. We do not speak for the 21OpenSSL project, and can only point to a 22[blog post](https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/) and 23[openssl-project email](https://github.com/quictls/openssl/discussions/54) 24that provides their view of QUIC support. 25 26As stated in their blog post, the OpenSSL team is focused on their 3.0 release 27(released 2021-09-07), and does not intend to add QUIC functionality to 1.1.x. 28There is a community need for a QUIC-capable TLS library. This fork is intended 29as stopgap solution to enable higher level frameworks and runtimes to use QUIC 30with the proven and reliable TLS functionality from OpenSSL. This fork will be 31maintained until OpenSSL officially provides reasonable support for QUIC 32implementations. 33 34This fork can be considered a supported version of 35[OpenSSL PR 8797](https://github.com/openssl/openssl/pull/8797). 36We will endeavor to track OpenSSL releases within a day or so, and there is an 37item below about how we'll follow their tagging. 38 39On to the questions and answers. 40 41What about branches? 42-------------------- 43 44We don't want to conflict with OpenSSL branch names. Our current plan is to append 45`+quic`. Release tags are likely to be the QUIC branch with `-releaseX` appended. 46For example, the OpenSSL tag `openssl-3.0.0` would have a branch named 47`openssl-3.0.0+quic` and a release tag of `openssl-3.0.0+quic-release1`. 48 49How are you keeping current with OpenSSL? 50----------------------------------------- 51 52(In other words, "What about rebasing?") 53 54Our plan is to always rebase on top of an upstream release tag. In particular: 55 56- The changes for QUIC will always be at the tip of the branch -- you will know what 57 is from the original OpenSSL and what is for QUIC. 58- New versions are quickly created once upstream creates a new tag. 59- The use of git commands (such as `cherry`) can be used to ensure that all changes 60 have moved forward with minimal or no changes. You will be able to see 61 "QUIC: Add X" on all branches and the commit itself will be nearly identical on 62 all branches, and any changes to that can be easily identified. 63 64What about library names? 65------------------------- 66 67Library names will be the same, but will use a different version number. The version 68numbers for the current OpenSSL libraries are `1.1` (for the 1.1.0 and 1.1.1 branches) 69and `3` (for the 3.0 branch). We will be prefixing `81` (ASCII for 'Q') to 70the version numbers to generate a unique version number. 71 72- `libcrypto.so.81.3` vs `libcrypto.so.3` 73- `libcrypto.so.81.1.1` vs `libcrypto.so.1.1` 74- `libssl.so.81.3` vs `libssl.so.3` 75- `libssl.so.81.1.1` vs `libssl.so.1.1` 76 77The SONAME of these libraries are all different, guaranteeing the correct library 78will be used. 79 80...and the executable? 81---------------------- 82 83We currently do not have any plans to change the name, mainly because we 84haven't made any changes there. If you see a need, please open an issue. 85 86The `openssl version` command will report that it is `+quic` enabled. 87 88...and FIPS? 89------------ 90 91We are not doing anything with FIPS. This is actually good news: you should 92be able to load the OpenSSL 3.0 FIPS module into an application built against 93this fork and everything should Just Work™. 94 95How can I contribute? 96--------------------- 97 98We want any code here to be acceptable to OpenSSL. This means that all contributors 99must have signed the appropriate 100[contributor license agreements](https://www.openssl.org/policies/cla.html). We 101will not ask for copies of any paperwork, you just need to tell us that you've 102done so (and we might verify with OpenSSL). We are only interested in making it 103easier and better for at least the mentioned QUIC implementations to use a variant 104of OpenSSL. If you have a pull request that changes the TLS protocol, or adds 105assembly support for a new CPU, or otherwise is not specific to enabling QUIC, 106please contribute that to OpenSSL. This fork is intended to be a clean extension 107to OpenSSL, with the deltas being specific to QUIC. 108 109Who are you? 110------------ 111 112This is a collaborative effort between [Akamai](https://www.akamai.com) and 113[Microsoft](https://www.microsoft.com). We welcome anyone to contribute! 114