search

apache / trafficserver

Apache Traffic Server™ is a fast, scalable and extensible HTTP/1.1 and HTTP/2 compliant caching proxy server.
https://trafficserver.apache.org/
Apache License 2.0
1.82k stars 804 forks source link

☂️ATS is incompatible with OpenSSL 3.0 #7341

Open maskit opened 3 years ago

maskit commented 3 years ago

Several functions are ~going to be~ deprecated since OpenSSL 3.0. It's still buildable by tweaking compile options but should be fixed sooner rather than later.

Last check was done with OpenSSL maser (b971d4198def0b29654e8fbf7987f7157741aed2) on Jan 5 2022.

These below may be temporal issues

maskit commented 3 years ago

We are expecting 3.0 actual to be released in Q3 of this year.

https://mta.openssl.org/pipermail/openssl-users/2021-June/013900.html

bneradt commented 2 years ago

Openssl 3.0 has been released now. @maskit : can you please update this issue with anything relevant now that it is released?

maskit commented 2 years ago

I updated the list. The biggest change since the last check is that HMAC() function (one-shot HMAC function) was un-deprecated. HMAC low level functions were kept deprecated.

Also, this is not new info though, I realized that some deprecated functions are actually faster than the current equivalent functions (see #7447). It means we should not simply replace the deprecated functions with new ones.

jeredfloyd commented 2 years ago

Fedora 36 has switched to OpenSSL 3.0.2 by default. ATS builds successfully, but the tscore HKDF tests fail.

src/tscore/HKDF_openssl.cc:extract/expand() fail with EVP_PKEY_derive() returning failure. These interfaces are deprecated in favor of the EVPKDF* interfaces, but I suspect this is an upstream bug that this simply fails.

I can build against the openssl1.1 compat packages in Fedora 36 for now so further investigation is lower on my priority list, but I welcome insight from OpenSSL experts!

jeredfloyd commented 2 years ago

RHEL 9 does not ship with OpenSSL 1.1 compatibility libraries, so I'm looking to tackle the HKDF failures. Before I dig in, has anyone here already investigated?

-------------------------------------------------------------------------------
HKDF tests
  Basic test case with SHA-256
-------------------------------------------------------------------------------
unit_tests/test_HKDF.cc:30
...............................................................................

unit_tests/test_HKDF.cc:60: FAILED:
  CHECK( hkdf.extract(prk, &prk_len, salt, sizeof(salt), ikm, sizeof(ikm)) == 1 )
with expansion:
  -6 == 1
jeredfloyd commented 2 years ago

Actual error message from OpenSSL is: 405710F3867F0000:error:1C80008B:Provider routines:HKDF_Extract:wrong output buffer size:providers/implementations/kdfs/hkdf.c:414:

I'll have time to look at this tomorrow afternoon.

jeredfloyd commented 2 years ago

This commit to OpenSSL (https://github.com/openssl/openssl/commit/5a285addbf39f91d567f95f04b2b41764127950d#diff-08361b6b082f3fc0700d4c885eb97ba8fe8c8b18df13ad1d169558313ae373e3) changed the behavior of EVP_PKEY_derive() to require the output buffer be the exact size of the output data.

The documentation (https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_derive.html) still states:

If key is not NULL then before the call the keylen parameter should contain the length of the key buffer, if the call is successful the shared secret is written to key and the amount of data written to keylen.

However the code now says:

    if (prk_len != (size_t)EVP_MD_size(evp_md)) {
        KDFerr(KDF_F_HKDF_EXTRACT, KDF_R_WRONG_OUTPUT_BUFFER_SIZE);
        return 0;
    }

I'll verify that usage of the HKDF functions still works, and patch the test to use correct buffer sizes. (And report to OpenSSL the doc inconsistency: https://github.com/openssl/openssl/issues/18517.)

bneradt commented 1 year ago

I did an attempt at updating the build_h3_tools.sh script to OpenSSL 3.x via OPENSSL_BRANCH=${OPENSSL_BRANCH:-"openssl-3.0.9+quic"} and attempted running the autests. All the tests passed except the following 6:

slice_prefetch
tls
tls_client_versions
tls_client_versions_minmax
tls_verify_override
tls_verify_override_base

Looking at the tls failure, it crashes with this backtrace:

[Jun 28 14:57:30.575] traffic_server NOTE: records parsing completed.
[Jun 28 14:57:30.575] traffic_server NOTE: /tmp/sb/tls/ts/config/records.yaml finished loading
[Jun 28 14:57:30.582] traffic_server NOTE: Traffic Server is running unprivileged, not switching to user 'nobody'
Fatal: UnixNetVConnection.cc:485: failed assertion `r != 0`
Fatal: UnixNetVConnection.cc:485: failed assertion `r != 0`
NOTE: using the environment variable TS_RUNROOT
[Jun 28 14:57:31.775] traffic_crashlo NOTE: crashlog started, target=24637, debug=false syslog=true, uid=503 euid=503
[Jun 28 14:57:31.776] traffic_crashlo NOTE: logging to 0x2dcec900
[Jun 28 14:57:31.777] traffic_crashlo ERROR: wrote crash log to /tmp/sb/tls/ts/log/crash-2023-06-28-145731.log
traffic_server: received signal 6 (Aborted)
traffic_server: received signal 6 (Aborted)
traffic_servertraffic_server - STACK TRACE: 
 - STACK TRACE: 
/tmp/sb/tls/ts/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, void*)+0xd0)[0x824e54]
/tmp/sb/tls/ts/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, void*)+0xd0)[0x824e54]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xffffa44dc790]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xffffa44dc790]
/lib64/libc.so.6(+0x8d908)[0xffffa346d908]
/lib64/libc.so.6(gsignal+0x20)[0xffffa3424980]
/lib64/libc.so.6(abort+0xf4)[0xffffa3410284]
/home/bneradt/build/trafficserver/lib/libtscore.so.10(ink_warning(char const*, ...)+0x0)[0xffffa43a9384]
/home/bneradt/build/trafficserver/lib/libtscore.so.10(ats_base64_encode(unsigned char const*, unsigned long, char*, unsigned long, unsigned long*)+0x0)[0xffffa43a33e8]
/tmp/sb/tls/ts/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, EThread*)+0x6c8)[0xce5d58]
/tmp/sb/tls/ts/bin/traffic_server(write_to_net(NetHandler*, UnixNetVConnection*, EThread*)+0x5c)[0xce5684]
/tmp/sb/tls/ts/bin/traffic_server(UnixNetVConnection::net_write_io(NetHandler*, EThread*)+0x24)[0xce77ac]
/tmp/sb/tls/ts/bin/traffic_server(NetHandler::process_ready_list()+0x170)[0xcd57b4]
/lib64/libc.so.6(+0x8d908)[0xffffa346d908]
/tmp/sb/tls/ts/bin/traffic_server(NetHandler::waitForActivity(long)+0x598)[0xcd5f10]
/tmp/sb/tls/ts/bin/traffic_server(EThread::execute_regular()+0x4d8)[0xd46e98]
/tmp/sb/tls/ts/bin/traffic_server(EThread::execute()+0x108)[0xd47040]
/tmp/sb/tls/ts/bin/traffic_server[0xd455ac]
/lib64/libc.so.6(+0x8bc74)[0xffffa346bc74]
/lib64/libc.so.6(+0xf925c)[0xffffa34d925c]
/lib64/libc.so.6(gsignal+0x20)[0xffffa3424980]
/lib64/libc.so.6(abort+0xf4)[0xffffa3410284]

The assertion is failing here: https://github.com/apache/trafficserver/blob/89f15f8d028889846c0dbaed3c22dd180ce659d9/iocore/net/UnixNetVConnection.cc#L485

bneradt commented 1 year ago

I did an attempt at updating the build_h3_tools.sh script to OpenSSL 3.x via OPENSSL_BRANCH=${OPENSSL_BRANCH:-"openssl-3.0.9+quic"} and attempted running the autests. All the tests passed except the following 6:

slice_prefetch
tls
tls_client_versions
tls_client_versions_minmax
tls_verify_override
tls_verify_override_base

Oh, I just noticed @midchildan has a PR to address some of these: https://github.com/apache/trafficserver/pull/9753

Thank you @midchildan

bneradt commented 1 year ago

This should address the last of the autests (a new test which was added since @midchildan's PR): https://github.com/apache/trafficserver/pull/9937