quictls / openssl Goto Github PK

Please note that this is NOT a demand for a new version or a complaint about this project's efforts. It is only a discussion.

Some time ago, I saw the 3.1.3 announce on the openssl mailing list. Usually this project publishes an update within a few days of announcement by the openssl project. I didn't see one here, and basically forgot about it until now.

Then I saw the 3.2 alpha announcement, and thought for sure a 3.1.3 release of quictls would have happened by now, but it's still not here.

So I went looking at the openssl changelog ... and found that 3.1.3 mentioned one change ... which appears to only apply to Windows.

Maybe the Windows issue is not something this project really cares about. Which is a little odd given that the main README says quictls is an effort driven by Akamai and Microsoft. Can someone shed some light on this? I'm thinking because I use quictls on Linux that 3.1.3 would not offer me any benefit compared to 3.1.2.

https://github.com/quictls/openssl/blob/OpenSSL_1_1_1n%2Bquic/.gitmodules

Please modify the boringssl 's url，Thanks！

Ex：https://github.com/google/boringssl.git

The problem that I’m seeing is that every QUIC connection is using far more memory than seemingly necessary. I narrowed a bunch of this down to this code in SSL_provide_quic_data:

    if (sc->quic_buf == NULL) {
        BUF_MEM *buf;
        if ((buf = BUF_MEM_new()) == NULL) {
            ERR_raise(ERR_LIB_SSL, ERR_R_INTERNAL_ERROR);
            return 0;
        }
        if (!BUF_MEM_grow(buf, SSL3_RT_MAX_PLAIN_LENGTH)) {
            ERR_raise(ERR_LIB_SSL, ERR_R_INTERNAL_ERROR);
            BUF_MEM_free(buf);
            return 0;
        }
        sc->quic_buf = buf;
        /* We preallocated storage, but there's still no *data*. */
        sc->quic_buf->length = 0;
        buf = NULL;
    }

Specifically, this code is preallocating a buffer to accumulate potentially fragmented TLS packets from QUIC packets, in order to parse the TLS packets. It’s passing a size of SSL3_RT_MAX_PLAIN_LENGTH, which is 16k, and for reasons that I don’t understand, the BUF code scales this by 4/3, causing an allocation of over 21k. In the cases I’m testing (DoQ and DoH), even if I send a large number of DNS queries over a QUIC connection, TLS data is only written into the buffer during the initial handshake, and it’s only a few hundred bytes. That means that most of the 21k allocated ends up unused for the lifetime of the connection.

To reduce this, I made a local change to comment out the preallocation. It seemed to work, although I suspect that it potentially isn’t safe if the buffer is reallocated. It looks like the code previously attached the TLS data directly onto the QUIC_DATA structures (changed in 075ede1), and that was removed because it was involved incomplete QUIC_DATA objects.

The older code, which would use far less memory, didn’t look all that complicated, but could potentially be simplified by storing the partial buffer on the connection, instead of on an incomplete QUIC_DATA.

I don’t think there’s anything specific to my use case that’s causing this, but am also not sure if the memory usage is an issue for anyone else. If it’s not, I’ll stick with a local workaround, but it might be good if it were improved for everyone.

It looks like quictls server accepts non-empty legacy_session_id in ClientHello.
Meanwhile, https://tools.ietf.org/html/draft-ietf-quic-tls-34#section-8.4 says that:

A server SHOULD treat the receipt of a
TLS ClientHello with a non-empty legacy_session_id field as a
connection error of type PROTOCOL_VIOLATION.

Here is how boringssl handle this:
https://github.com/google/boringssl/blob/7a1986c463548627b83ed58d9f9db65bddbce6a5/ssl/tls13_server.cc#L198

The minimal CI build fails for openssl-3.0.0-alpha12+quic branch

Thanks to @tatsuhiro-t much of the 0-RTT work is done. All that is left (I think) is around NST management (on both client and server side). Luckily it seems much (if not all?) of the work is already done in some shape or another and might just need to be cleaned up and moved to this fork. I will try to enumerate what I believe is still needed here:

Client Side

• The client needs an explicit indication somehow when a ticket has been received and is ready to be consumed.
• Received tickets on the client need to be retrieved in a serialized byte form that can be passed up the stack (in a platform agnostic way) to the app, so that it may then use it for a future QUIC connection.

It seems openssl#5932 does the serialization already, but just needs to be merged here.

Server Side

• The server needs explicit control over when/if to send an NST.
• The server needs to be able to encode custom data in the NST.
• The server needs to know when an NST is received from the client and extract the custom data from it.

Apparently openssl#11416 achieved some of this but it doesn't quite work for QUIC.

hi. i want to use quick in haproxy .
i want to know is this issue still exists in version 3.x or not ? (please see image below)
should i use version 3.x or 1.1.1 as mentioned in haproxy blog ?

https://www.haproxy.com/blog/how-to-enable-quic-load-balancing-on-haproxy#how-to-enable-quic-in-haproxy

Promoting my comment at #8 (comment) to a more discoverable issue:
When we successfully return from the handshake as a client, we have to check if the early-data state was in SSL_EARLY_DATA_CONNECTING and set it to a new value to indicate that we can no longer send early data (since we got handshake data from the server and should send with 1-RTT keys). The current code sets SSL_EARLY_DATA_WRITE_RETRY, but IMO SSL_EARLY_DATA_FINISHED_WRITING is more appropriate; ossl_statem_check_finish_init() would translate the former into the latter eventually anyway, IIUC.

The tag OpenSSL_1_1_1u-quic1 points to commit 70c2912, like tag OpenSSL_1_1_1u, when it should point to commit 636c615.

Hi!

At Node.js we monitor the GitHub release tags and https://github.com/quictls/openssl/releases/tag/openssl-3.0.10-quic1 is showing OpenSSL 3.1.2 quic Release 1. Is it just a mistype when tagging the release on GitHub or 3.0.10+quic wasn't released at all?

Recently there are several vulnerabilities reported about openSSL (GHSA-w2w6-xp88-5cvw, GHSA-77f3-6546-6rj7, GHSA-pxvj-4wx4-gv6w), these vulnerabilities are fixed in openSSL 3.0.9, will Node.js consider its openSSL to this version? Thanks.

Wrong README.md file (taken from upstream openssl project). Looks like missing README-OpenSSL.md in openssl-3.0.10+quic branch.

In SSL_set_quic_early_data_enabled() we apply a few consistency checks before allowing a state of SSL_EARLY_DATA_CONNECTING to be set. One such check involves inspecting the value of ssl->session->ext.max_early_data and treating a value of 0 as disabling early data. However, per RFC 9001 the max_early_data_size parameter must be exactly 0xffffffff in order to enable 0-RTT for QUIC. AFAICT we should use the more-strict check in this case.

I don't know if this is a bug or not, so I am starting with the question issue type.

I am building and installing the 3.0.x version of this openssl to use with the development version of haproxy. I install it into /opt/qucitls.

On x86_64, the library files go into a "lib64" subdirectory. But on aarch64, also a 64-bit architecture, the library files go into a "lib" subdirectory.

This discrepancy means that my build script for haproxy must detect whether or not /opt/quictls/lib64 exists and adjust the build to the correct directory -- the script I had working on x86_64 systems did not work as-is on my raspberry pi.

Is the behavior I am seeing correct?

What is the plan for releasing some of the newer OpenSSL releases, such as 3.0.11?

They have done some security releases and it would be good to stay up to date with these.

https://github.com/openssl/openssl/releases

Would you like me to try and put together a PR with such an upgrade or something?

I add riscv target to openssl/openssl_1_1_1: openssl#14724
I want to add openssl-riscv into nodejs
So how to add this patch into quictls/openssl ?

In #8 we gained early data support for the 1.1.1 branch, but the relevant APIs/commits do not appear to be on the openssl-3.0.0-beta1+quic branch.

There's no release for 3.0.14 in this repository. There is a 3.0.14+quic tag in the repository, but that seems incomplete:

1. SHLIB_VER in VERSION.dat is the openssl upstream 3, not 81.3
2. Missing include/openssl/quic.h in make install

The FreeBSD ports that I maintain, have all the CVE's of 3.0.13 and 3.1.5 backported.

Can you please create releases for 3.0.14 and 3.1.6? People using the ports get pestered by Vulnerability Management teams or tooling that they have vulnerable versions.

Thanks! Bernard.

Contents of https://github.com/quictls/openssl/archive/refs/tags/openssl-3.0.0.tar.gz are completely identical to https://www.openssl.org/source/openssl-3.0.0.tar.gz
Are you fooling us?

I add LoongArch target to openssl/openssl [3.0]: openssl#18807
I want to add openssl-loongarch64 into nodejs
So how to add this patch into quictls/openssl ?

Cheers~

Tests fail when configured for no-quic. Presumably some OPENSSL_NO_QUIC guards are missing. This might be related to #2

./config no-quic
make -sj
make test

Hi, BoringSSL QUIC API supports ssl_quic_method_st with set_read_secret and set_write_secret method, I wonder if quictls/openssl supports the latest ssl_quic_method_st with set_read_secret and set_write_secret? Or only support set_encryption_secrets method?

I am trying to compile quic library with openssl-3.0.1+quic, but maker show lots error info, like:

1. error: unknown type name ‘EVP_AEAD_CTX’
2. openssl/aead.h: No such file or directory
3. implicit declaration of function ‘EVP_aead_aes_128_gcm’

These structures/apis about AEAD were used by quiche, could you tell me how can I compile quiche or lsquic with openssl-3.0.1+quic but not with boringssl? Thanks~

It appears that node.js uses the GitHub releases list when searching for what version to update to, and quictls has tagged 3.0.9, but not "released" it. (perhaps I'm missing some critical information as to why that is, but I'll take a stab in the dark and ask here :-) )

Is it possible, or is there something blocking making the openssl-3.0.9-quic1 tag an official release?

Thanks for the effort to keep this library updated with upstream 🙏

We probably wanted to make the tag openssl-3.1.5+quic

I suspect this problem is actually in either openssl or perl, but I only have a pipeline set up for quictls, so I am coming here first to discuss it.

If I run my script to build and install quictls in a terminal window where I ssh to the host, everything is fine.

If it runs under a gitlab CI/CD pipeline using gitlab-runner registered as a 'shell' runner then I get a bunch of lines about an uninitialized value in a module that is part of perl-base.

This is the script:

https://gitlab.elyograg.org/world/haproxy-scripts/-/raw/main/new-quic

This is the error it generates:

As text, that message is:

Use of uninitialized value in join or string at /usr/lib/x86_64-linux-gnu/perl-base/re.pm line 47.

The script checks out whichever branch is the current default. Right now that is openssl-3.0.7+quic .

Looking at the perl module where the message is logged, I suspect that the gitlab-runner shell is missing all termcap info either because it's gitlab-runner or because it's using sudo without a tty.

Is there any way to either provide perl with the info it is missing, or to disable the warning/error in my build script?

The gitlab server is Ubuntu 22.04 x86_64. The runner is on an ubuntu 22.04 VM hosted by separate hardware in libvirtd/qemu.

The CI/CD pipeline tests some scripts that I wrote to build/install quictls and then use that to build/install haproxy with QUIC/H3 support.

./auto/configure: error: invalid option "--with-http_v3_module"

BoringSSL SSL_provide_quic_data accepts 0 length data, on the other hand, quictls does not.

Documentation here appears now wrong:

https://quictls.github.io/

"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 tag openssl-3.0.0-alpha12 would have a branch named openssl-3.0.0-alpha12+quic and a release tag of openssl-3.0.0-alpha12+quic-release1"

But today in practice release tags seems to be suffixed "openssl-<opensslversion>+quicX"

In addition, do you plan to tag the 1.1.1u soon? Branch seems created and code merged but there is still no tags available.

I was informed about the excessive locking problems in openssl 3.x on the haproxy mailing list. All indications are that the openssl project is ignoring the problem. The info I have available says that openssl 3.x is many times slower under heavy load than 1.1.x because of the excessive locking.

This project had a +quic+locks variant for 3.1.0, but at this time I do not see such a variant for 3.1.2. I made an attempt at testing for a performance difference between 1.1.x+quic, 3.0.x+quic, and 3.1.0+quic+locks. I did not see any real difference, so I suspect my testing methodology was not correct.

What can you tell me about the current state of fixing locking issues in either this repo or the upstream openssl repo?

My installs of haproxy do not see enough traffic for the locking to present a problem, but it interests me. I don't have an understanding of the code involved.

Hi,

I found that tag OpenSSL_1_1_1w-quic1 was missing. Most probably it should be the latest commit on OpenSSL_1_1_1w+quic branch, i.e. 612d8e4.
Could you please make a tag for 1.1.1v based quic if it is ready ?

Thanks in advance.
Kazuhiko

for node.js update

this impacts anybody who wants to build from released artifacts instead of GitHub - like package maintainers.
Consider this fragment

version=2.1.7
curl -O https://github.com/microsoft/msquic/archive/refs/tags/v${version}.tar.gz
tar xfz /v${version}.tar.gz
cd msquic-${version}
...

it works fine for other packet but not for quilts

version=openssl-3.0.7+quic1
https://github.com/quictls/openssl/archive/refs/tags/${version}.tar.gz
tar xfz /v${version}.tar.gz
cd openssl-${version} -> fails

if you look at the content,

tar ftz openssl-3.0.7+quic1.tar.gz
openssl-openssl-3.0.7-quic1/
openssl-openssl-3.0.7-quic1/ACKNOWLEDGEMENTS.md
openssl-openssl-3.0.7-quic1/AUTHORS.md
openssl-openssl-3.0.7-quic1/CHANGES.md
...

Because the branch name has special character the files inside are renamed to avoid it. It does not matter for git as the name never appears on file system .

This obviously can be workaround but it would be really nice if artifacts released from here follow standard convention.

Since we will not change past tags, I suggest to use -quic1 suffix instead of +quic1.

cc: @nibanks @ManickaP

Environment:

• Client is using MsQuic (built on commit b568ff3eebf6736ec779c9742190c150c7afa8ef, "Fix SAL"). On windows 11 latest build.
• Server is using Quinn 0.9.3, on the same windows host.

Chosen ALPN is "http/0.9".

Client setups its credentials like so:

• CredentialConfig.Reserved = nullptr;
• CredentialConfig.Type = QUIC_CREDENTIAL_TYPE_NONE;
• CredentialConfig.Flags = QUIC_CREDENTIAL_FLAG_CLIENT | QUIC_CREDENTIAL_FLAG_SET_ALLOWED_CIPHER_SUITES | QUIC_CREDENTIAL_FLAG_NO_CERTIFICATE_VALIDATION;
• CredentialConfig.AllowedCipherSuites = QUIC_ALLOWED_CIPHER_SUITE_AES_256_GCM_SHA384 | QUIC_ALLOWED_CIPHER_SUITE_AES_128_GCM_SHA256;

Server setups it's crypto server config like so:
let mut crypto = rustls::ServerConfig::builder()
.with_safe_default_cipher_suites()
.with_safe_default_kx_groups()
.with_protocol_versions(&[&rustls::version::TLS13])
.unwrap()
.with_no_client_auth()
.with_single_cert(vec![cert], key)
.expect("invalid crypto config");

crypto.max_early_data_size = u32::MAX;
crypto.alpn_protocols = vec![String::from("http/0.9").into_bytes()];

What happens:

1. Connection attempt is sent to the localhost server.
2. Server decides upon TLS13_AES_256_GCM_SHA384 suite.
3. Server chooses protocol "http/0.9".
4. Server sends it's certificate crypto data to the client.
5. Client receives the 585 crypto bytes.
6. Client calls SSL_provide_quic_data from MsQuic's tls_openssl.c after logging "Processing 1487 bytes". No errors are thrown.
7. Before attempting to call SSL_do_handshake, every single quic buffer or related data is either NULLs or 0s in the SSL pointer.
8. Error 0 is later returned in statem_quic.c::quic_get_message(...) after attempting to get the SSL->quic_input_data_head (which is NULL).
9. Client logs "TLS handshake error: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag, file:dules\openssl\crypto\asn1\tasn_dec.c" and "ERROR, 42, Received alert from TLS." and the connection is shutdown by transport with status BAD_CERTIFICATE.
10. Client closes connection, failing to validate server.
11. Server logs "ECN not acknowledged by peer" and "discarding unexpected Initial packet (1220 bytes)".

Hello,

I'm trying to compile Openssl-3.0.5+Quic for Windows x64 using the instructions in NOTES-WINDOWS.md and when I run nmake I get this:

crypto\aes\libcrypto-shlib-aes_cfb.obj : fatal error LNK1112: module machine type 'x86' conflicts with target machine type 'x64'
Could Not Find D:\Temp\openssl-openssl-3.0.5-quic\libcrypto-81_3-x64.*

Any idea what's going on?

Thank you.

Unfortunately many of the function names we've chosen to use are going to get repurposed by the OpenSSL quic support. That's very unfortunate because 3.2 supposedly solves many of the locking issues and boosts performance (there are other longstanding performance issues to solve).

I see some pretty unattractive options ahead:
1: Backport much of this work onto 3.1
2: Add patches removing upstream QUIC support first
3: Stay on 3.1 or 3.0 and ignore the other changes.

Hi

I added an AUR package which uses this repository as source and it should refer to git tags only instead of branches to get the correct version. However the two latest versions don't have any tag. :-)

Best regards
Atle

OpenSSL 3.1.3 is out, fixing the no-autoload-config option ¹ and also
CVE-2023-4807 ².

Is there a plan for a quictls 3.1.3 release?

I want to use openssl replace boringssl in the chromium.

Are there plans to add ECH support to this fork?

When building 1.1.1l+quic:

./config no-quic
make -sj4
make tests

A number of tests are failing. They don't fail when compiled with QUIC.

The link to quictls.github.io/openssl on the project page is resulting in a 404 (resource hot found) HTTP status error. Just letting you guys know

Is version 3.1.1 coming anytime soon? :)

Hello,

It looks like SSL_clear doesn't reset any QUIC-specific members (like the quic_read_level / quic_write_level). This means that it is currently impossible to re-use the same SSL object to re-establish another connection.

I guess we should reset the following members:

• quic_read_level to ssl_encryption_inititial
• quic_write_level to ssl_encryption_inititial
• quic_latest_level_received to ssl_encryption_inititial
• quic_buf to an empty buffer
• quic_input_data_head to NULL
• quic_input_data_tail to NULL
• quic_next_record_start to 0

Am I missing anything?

Hello, maintainers of the quictls/openssl project,

I have a question regarding the naming convention used for the release files in the quictls/openssl project.

Currently, the names of the release files are somewhat confusing, such as openssl-openssl-3.0.8-quic1.tar.gz. I would like to suggest a more simplified naming convention, similar to what OpenSSL uses for their releases, like openssl-3.1.0.tar.gz.

Would it be possible to change the format to something like quictls-3.0.8.tar.gz? This would make it easier for users who want to automate processes related to the project, as the current naming convention can be cumbersome to work with.

Please let me know your thoughts on this matter, as I believe it would be beneficial to the users of the quictls/openssl project.

Thank you for your time and consideration.

It looks like SSL_process_quic_post_handshake only processes a single session ticket in a single call as demonstrated in a test code.
On the other hand, BoringSSL counterpart processes multiple session tickets in a single call.

We might be able to call SSL_process_quic_post_handshake multiple times, but there is an issue: we do not know how many times we should call it. This is because it returns 1 when no data to read is left.

I think it would be very useful if SSL_process_quic_post_handshake can process multiple session tickets just like BoringSSL.

the external link library boringssl is missing and cannot be opened.

It seems SSL_new_session_ticket needs some updated to make it work with QUIC. It should allow QUIC servers to manually trigger a new session ticket to be sent.

Between 9398922 and 32be828, the man/man3/SSL_CTX_set_quic_method.3.gz manpage went missing from make install.
Browsed a bit through the commits but couldn't find out how this was in alpha12 but is no longer in alpha13