aws-lc: do not use large buffer

test_10_08, uploading larger files for a h2 proxy, sporadically fails
with a decrpytion error on received data in AWS-LC. The frequency can
be increased by simulated network receive blocks.

Not setting a 4 * TLS record sized buffer, leaving AWS-LC at its
default buffer size seems to mitigate this problem.

Closes #18434
This commit is contained in:
Stefan Eissing 2025-08-29 17:38:45 +02:00 committed by Daniel Stenberg
parent 63b7d8b8f4
commit e65dc7fa23
No known key found for this signature in database
GPG key ID: 5CC908FDB71E12C2
3 changed files with 9 additions and 4 deletions

View file

@ -474,7 +474,7 @@ static CURLcode proxy_h2_progress_ingress(struct Curl_cfilter *cf,
Curl_bufq_len(&ctx->inbufq), result, nread);
if(result) {
if(result != CURLE_AGAIN) {
failf(data, "Failed receiving HTTP2 data");
failf(data, "Failed receiving HTTP2 proxy data");
return result;
}
break;

View file

@ -121,8 +121,14 @@
static void ossl_provider_cleanup(struct Curl_easy *data);
#endif
/*
* AWS-LC has `SSL_CTX_set_default_read_buffer_len()?` but runs into
* decryption failures with large buffers. Sporadic failures in
* test_10_08 with h2 proxy uploads, increased frequency
* with CURL_DBG_SOCK_RBLOCK=50. Looks like a bug on their part.
*/
#if OPENSSL_VERSION_NUMBER >= 0x10100000L && \
!defined(LIBRESSL_VERSION_NUMBER) && !defined(OPENSSL_IS_BORINGSSL)
!defined(LIBRESSL_VERSION_NUMBER) && !defined(HAVE_BORINGSSL_LIKE)
#define HAVE_SSL_CTX_SET_DEFAULT_READ_BUFFER_LEN 1
#endif
@ -4129,7 +4135,6 @@ CURLcode Curl_ossl_ctx_init(struct ossl_ctx *octx,
However using a large buffer (8 packets) actually decreases performance.
4 packets is better.
*/
#ifdef HAVE_SSL_CTX_SET_DEFAULT_READ_BUFFER_LEN
SSL_CTX_set_default_read_buffer_len(octx->ssl_ctx, 0x401e * 4);
#endif