Hi, I was running some tests from ssllabs.com and ran into a segfault. I used the "CurveBall" manual test link from this page: https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html Which points to: https://www.ssllabs.com:10446/ Nav_open_url: new url='https://www.ssllabs.com:10446/' Connecting to 69.67.183.100:10446 www.ssllabs.com:10446: TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384 ecdsa-with-SHA256 384-bit EC: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs CurveBall Leaf/CN=www.ssllabs.com ecdsa-with-SHA256 Program received signal SIGSEGV, Segmentation fault. _lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 793 return pkey->type; (gdb) bt #0 _lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 #1 0x000001f9ee7da2b0 in Tls_check_cert_strength (ssl=<optimized out>, srv=<optimized out>, choice=0x6faff21f66f8) at tls_openssl.c:526 #2 0x000001f9ee7d8fd3 in Tls_examine_certificate (ssl=0x1fca8ddac80, srv=0x1fc1b4056a0) at tls_openssl.c:865 #3 Tls_connect (fd=7, connkey=4) at tls_openssl.c:1208 #4 0x000001fce9a7a7f0 in fl_wait(double) () from /usr/local/lib/libfltk.so.9.0 #5 0x000001fce9a0777f in Fl::wait(double) () from /usr/local/lib/libfltk.so.9.0 #6 0x000001fce9a079a1 in Fl::wait() () from /usr/local/lib/libfltk.so.9.0 #7 0x000001f9ee77e774 in main (argc=1, argv=0x6faff21f6a48) at dillo.cc:621 When I try to open it with curl, this is the result: curl: (35) TLS connect error: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib This is on OpenBSD, using LibreSSL. I did a curl test on a Linux box and didn't get that error, so it may be LibreSSL specific. Happy to do further testing if you have any ideas. Regards, Alex
Hi, On Thu, Jan 15, 2026 at 09:44:50PM +0000, a1ex@dismail.de wrote:
Hi,
I was running some tests from ssllabs.com and ran into a segfault.
I used the "CurveBall" manual test link from this page: https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html
Which points to: https://www.ssllabs.com:10446/
Nav_open_url: new url='https://www.ssllabs.com:10446/' Connecting to 69.67.183.100:10446 www.ssllabs.com:10446: TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384 ecdsa-with-SHA256 384-bit EC: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs CurveBall Leaf/CN=www.ssllabs.com ecdsa-with-SHA256 Program received signal SIGSEGV, Segmentation fault. _lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 793 return pkey->type; (gdb) bt #0 _lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 #1 0x000001f9ee7da2b0 in Tls_check_cert_strength (ssl=<optimized out>, srv=<optimized out>, choice=0x6faff21f66f8) at tls_openssl.c:526 #2 0x000001f9ee7d8fd3 in Tls_examine_certificate (ssl=0x1fca8ddac80, srv=0x1fc1b4056a0) at tls_openssl.c:865 #3 Tls_connect (fd=7, connkey=4) at tls_openssl.c:1208 #4 0x000001fce9a7a7f0 in fl_wait(double) () from /usr/local/lib/libfltk.so.9.0 #5 0x000001fce9a0777f in Fl::wait(double) () from /usr/local/lib/libfltk.so.9.0 #6 0x000001fce9a079a1 in Fl::wait() () from /usr/local/lib/libfltk.so.9.0 #7 0x000001f9ee77e774 in main (argc=1, argv=0x6faff21f6a48) at dillo.cc:621
When I try to open it with curl, this is the result: curl: (35) TLS connect error: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib
This is on OpenBSD, using LibreSSL.
I did a curl test on a Linux box and didn't get that error, so it may be LibreSSL specific.
Thanks, I can reproduce it on Linux with LibreSSL 4.2.1 and ASan enabled: ==1123582==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f31c4d0b3a4 bp 0x7ffc3dc12070 sp 0x7ffc3dc10eb8 T0) ==1123582==The signal is caused by a READ memory access. ==1123582==Hint: address points to the zero page. #0 0x7f31c4d0b3a4 in EVP_PKEY_id (/usr/lib/libressl/libcrypto.so.57+0xae3a4) (BuildId: 15f17022dc7dbd5298bf906f2ef4e53d12c52015) #1 0x55c7110c71cf in Tls_check_cert_strength ../../../src/IO/tls_openssl.c:525 #2 0x55c7110c87d1 in Tls_examine_certificate ../../../src/IO/tls_openssl.c:864 #3 0x55c7110ca507 in Tls_connect ../../../src/IO/tls_openssl.c:1207 #4 0x55c7110ca6e0 in Tls_connect_cb ../../../src/IO/tls_openssl.c:1239 #5 0x7f31c4ab06ec in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa66ec) (BuildId: 35d154011fe6e73efbad51f873a8c4e488e91451) #6 0x7f31c4a4e0fd in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x440fd) (BuildId: 35d154011fe6e73efbad51f873a8c4e488e91451) #7 0x7f31c4a4e232 in Fl::wait() (/usr/lib/libfltk.so.1.3+0x44232) (BuildId: 35d154011fe6e73efbad51f873a8c4e488e91451) #8 0x55c710fd9009 in main ../../src/dillo.cc:621 #9 0x7f31c4227634 (/usr/lib/libc.so.6+0x27634) (BuildId: 2f722da304c0a508c891285e6840199c35019c8d) #10 0x7f31c42276e8 in __libc_start_main (/usr/lib/libc.so.6+0x276e8) (BuildId: 2f722da304c0a508c891285e6840199c35019c8d) #11 0x55c710fd5f74 in _start (/home/ram/dev/dillo/git/build-asan/src/dillo+0x12f74) (BuildId: 850e3f88a121a05841fca5389243b0482d69b6b0) This patch should get rid of the segfault, but I need to take a closer look and see if we are handling it well for LibreSSL, as they expose headers from version 2 from OpenSSL. ---8<--- diff --git a/src/IO/tls_openssl.c b/src/IO/tls_openssl.c index 3345a0dc..d1df2315 100644 --- a/src/IO/tls_openssl.c +++ b/src/IO/tls_openssl.c @@ -471,14 +471,12 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) char buf[buflen]; int rc, i, n = sk_X509_num(sk); X509 *cert = NULL; - EVP_PKEY *public_key; int key_type, key_bits; const char *type_str; BIO *b; for (i = 0; i < n; i++) { cert = sk_X509_value(sk, i); - public_key = X509_get_pubkey(cert); /* We are trying to find a way to get the hash function used * with a certificate. This way, which is not very pleasant, puts @@ -521,6 +519,10 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) if (print_chain) MSG("%s ", buf); + EVP_PKEY *public_key = X509_get_pubkey(cert); + if (public_key == NULL) + continue; + #if OPENSSL_VERSION_NUMBER < 0x30000000L key_type = EVP_PKEY_type(EVP_PKEY_id(public_key)); #else ---8<--- Best, Rodrigo.
Hi Rodrigo, Rodrigo Arias <rodarima@gmail.com> wrote:
This patch should get rid of the segfault, but I need to take a closer look and see if we are handling it well for LibreSSL, as they expose headers from version 2 from OpenSSL.
---8<--- diff --git a/src/IO/tls_openssl.c b/src/IO/tls_openssl.c index 3345a0dc..d1df2315 100644 --- a/src/IO/tls_openssl.c +++ b/src/IO/tls_openssl.c @@ -471,14 +471,12 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) char buf[buflen]; int rc, i, n = sk_X509_num(sk); X509 *cert = NULL; - EVP_PKEY *public_key; int key_type, key_bits; const char *type_str; BIO *b;
for (i = 0; i < n; i++) { cert = sk_X509_value(sk, i); - public_key = X509_get_pubkey(cert);
/* We are trying to find a way to get the hash function used * with a certificate. This way, which is not very pleasant, puts @@ -521,6 +519,10 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) if (print_chain) MSG("%s ", buf);
+ EVP_PKEY *public_key = X509_get_pubkey(cert); + if (public_key == NULL) + continue; + #if OPENSSL_VERSION_NUMBER < 0x30000000L key_type = EVP_PKEY_type(EVP_PKEY_id(public_key)); #else ---8<---
Thanks! Now the segfault is gone: Nav_open_url: new url='https://www.ssllabs.com:10446/' Dns_server [0]: www.ssllabs.com is 69.67.183.100 Connecting to 69.67.183.100:10446 www.ssllabs.com:10446: TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384 ecdsa-with-SHA256 384-bit EC: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs CurveBall Leaf/CN=www.ssllabs.com ecdsa-with-SHA256 root: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs/CN=SSLLabs CurveBall CA SSL_read() failed: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib SSL_read() failed: error:10FFF07F:elliptic curve routines:CRYPTO_internal:pkparameters2group failure SSL_read() failed: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib SSL_read() failed: error:10FFF08E:elliptic curve routines:CRYPTO_internal:decode error SSL_read() failed: error:0BFFF07D:x509 certificate routines:CRYPTO_internal:public key decode error Tls_close_by_key: Avoiding SSL shutdown for: https://www.ssllabs.com:10446/ Premature close for https://www.ssllabs.com:10446/ Regards, Alex
participants (2)
-
a1ex@dismail.de -
Rodrigo Arias