SSL* is filled with NULLs after quic_input_get_data is called

[seblaf1]

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)".

[seblaf1]

quic.txt

[nibanks]

cc @tmshort and @kaduk any help here would be appreciated. I'm not sure what could be going on here. There seems to be an interopt issue when talking to rustls.

[kaduk]

I'm a bit confused at how we go from processing 585 crypto byes to then attempting to process 1487 bytes; does that have an easy explanation (like, "it's just the next frame in the stream")? Just looking at the error file the most plausible guess (which is, to be clear, just a guess and not necessarily correct) is that openssl doesn't like the ASN.1 encoding of the certificate it received. Do we have a packet capture or similar diagnostics available (ideally with decrypted contents)?

[tmshort]

I'm with @kaduk here, looks to be a bad certificate/ASN.1 encoding. None of that code is touch by QUIC.

[tmshort]

Also, the "quic.txt" is output from MSQUIC, not OpenSSL/QUICTLS, so I really don't know how to interpret it.

[richsalz]

Any more activity on this? Or should we close it.