Editing OpenSSL (section)

=== Consideration for users' requirements ===

While the [[QUIC]] transport layer was being worked on to support the third version of the [[HTTP]] protocol, it was proposed to use TLS to provide security,<ref>{{Cite web |url=https://datatracker.ietf.org/doc/draft-ietf-quic-tls/01/ |title=Using Transport Layer Security (TLS) to Secure QUIC |date=January 14, 2017 |via=IETF |last1=Thomson |first1=Martin |last2=Turner |first2=Sean |access-date=November 27, 2023 |archive-date=December 8, 2024 |archive-url=https://web.archive.org/web/20241208103639/https://datatracker.ietf.org/doc/draft-ietf-quic-tls/01/ |url-status=live}}</ref> and identified that some adaptations to TLS libraries would be needed. Such modifications were brought to BoringSSL<ref>{{Cite web|url=https://bugs.chromium.org/p/boringssl/issues/detail?id=221|title=221 - boringssl - A fork of OpenSSL that is designed to meet Google's needs - Monorail|website=bugs.chromium.org}}</ref> which was the library being primarily used by QUIC developers by then, and later ported to other libraries.<ref>{{Cite web|url=https://gitlab.com/gnutls/gnutls/-/issues/826|title=Support QUIC TLS API (#826) · Issues · gnutls / GnuTLS · GitLab|website=GitLab|date=September 4, 2019|access-date=February 25, 2023|archive-date=December 8, 2024|archive-url=https://web.archive.org/web/20241208020918/https://gitlab.com/gnutls/gnutls/-/issues/826|url-status=live}}</ref> A port of this work was quickly proposed to OpenSSL.<ref name="auto1">{{Cite web|url=https://github.com/openssl/openssl/pull/8797|title=WIP: master QUIC support by tmshort · Pull Request #8797 · openssl/openssl|website=GitHub|access-date=February 25, 2023|archive-date=January 21, 2025|archive-url=https://web.archive.org/web/20250121132358/https://github.com/openssl/openssl/pull/8797|url-status=live}}</ref> While some discussion started the same day, it quickly stalled and was first blocked on license considerations,<ref name="auto1"/> then kept on hold once these concerns were cleared. Finally 10 months later the OpenSSL Management Committee announced on a blog post<ref>{{Cite web |url=https://openssl-library.org/post/2020-02-13-quic-and-openssl/ |title=QUIC and OpenSSL |website=OpenSSL Blog |date=February 17, 2020 |access-date=2024-10-11}}</ref> that this patch set would not be adopted for 3.0 on the fear that the API would change over time. Finally more than one year after planned release of 3.0 which was still not coming, a team of volunteers from [[Akamai]] and [[Microsoft]] decided to fork the project as QuicTLS<ref>{{Cite web|url=https://twitter.com/richsalz/status/1367349918671773697|title=quictls announce on twitter}}</ref> and support these patches on top of the OpenSSL code in order to unblock QUIC development. This action was generally welcome by the community. Finally after OpenSSL 3.0 was finally released, the QUIC patch set was reconsidered and decided against,<ref>{{Cite web|url=https://www.mail-archive.com/openssl-project@openssl.org/msg02585.html|title=OMC Release Requirements|website=www.mail-archive.com|access-date=February 25, 2023|archive-date=January 21, 2025|archive-url=https://web.archive.org/web/20250121112325/https://www.mail-archive.com/openssl-project@openssl.org/msg02585.html|url-status=live}}</ref> causing tens to hundreds of reactions of disappointment among the community.<ref name="auto1"/> The pull request was closed, while users felt the need to publicly express their disappointment,<ref>{{Cite web|url=https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-will-not-provide/|title=The QUIC API OpenSSL will not provide &#124; daniel.haxx.se|date=October 25, 2021|access-date=February 25, 2023|archive-date=January 21, 2025|archive-url=https://web.archive.org/web/20250121161711/https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-will-not-provide/|url-status=live}}</ref> or beg operating system vendors to support the alternative QuicTLS fork,<ref>{{Cite web|url=https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html|title=[Pkg-openssl-devel] Any intent to maintain quictls ?|first=Willy|last=Tarreau|date=October 27, 2021|access-date=February 25, 2023|archive-date=December 7, 2024|archive-url=https://web.archive.org/web/20241207235221/https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html|url-status=live}}</ref><ref>{{Cite web|url=https://groups.google.com/g/linux.debian.bugs.dist/c/CAh0KLP5Euo?pli=1|title=Bug#1011391: openssl: please support quictls patchset|website=groups.google.com|access-date=February 25, 2023|archive-date=December 8, 2024|archive-url=https://web.archive.org/web/20241208091707/https://groups.google.com/g/linux.debian.bugs.dist/c/CAh0KLP5Euo%3Fpli=1|url-status=live}}</ref> or seek for alternative solutions.<ref name="auto2">{{Cite web|url=https://github.com/haproxy/haproxy/issues/680|title=HTTP/3 support · Issue #680 · haproxy/haproxy|website=GitHub|access-date=February 25, 2023|archive-date=December 7, 2024|archive-url=https://web.archive.org/web/20241207220516/https://github.com/haproxy/haproxy/issues/680|url-status=live}}</ref> Finally Rich Salz, co-founder of the QuicTLS fork, announced<ref name="auto2"/> his interest in seeing an Apache project forked from QuicTLS. As of 25 February 2023 there is still no QUIC-compatible long-term supported TLS library available by default in operating systems without requiring end-users to rebuild it themselves from sources.