Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: curl: (35) SSL_connect failed with error -140: ASN parsing error, invalid input #7844

Open
Zoey2936 opened this issue Aug 6, 2024 · 13 comments
Assignees
Labels

Comments

@Zoey2936
Copy link

Zoey2936 commented Aug 6, 2024

Contact Details

[email protected]

Version

v5.7.2-stable

Description

  1. Build curl using this Dockerfile: https://github.com/ZoeyVid/curl-quic/blob/latest/Dockerfile
  2. run curl https://api.telegram.org
  3. get: curl: (35) SSL_connect failed with error -140: ASN parsing error, invalid input as error
  4. rebuilt using v5.7.0 and everything works

Reproduction steps

No response

Relevant log output

No response

@embhorn
Copy link
Member

embhorn commented Aug 6, 2024

Hi @Zoey2936

Thanks for letting us know about this issue. Could you please test against the latest master and let us know if it works? I tried unsuccessfully to build your Docker file.

Thanks,
@embhorn

@embhorn embhorn assigned tmael and unassigned embhorn Aug 6, 2024
@Zoey2936
Copy link
Author

Zoey2936 commented Aug 7, 2024

you can find a curl built with master as base here: https://github.com/ZoeyVid/curl-quic/actions/runs/10287471865 (the "artifacts" Artifact), and no building with master as base still does not work

@tmael
Copy link
Contributor

tmael commented Aug 7, 2024

Thanks @Zoey2936
I was able to reproduce the issue on both the master and v5.7.2-stable.
Seems like https://github.com/wolfSSL/wolfssl/pull/7625/files might have introduced the issue.

@Zoey2936
Copy link
Author

Zoey2936 commented Aug 7, 2024

ok, until it is fixed I will use v5.7.0

@tmael
Copy link
Contributor

tmael commented Aug 7, 2024

Does the certificate have a negative or zero serial number? Those are treated as errors in wolfSSL.
You can use CFLAGS="-DWOLFSSL_NO_ASN_STRICT" as a potential solution.

@Zoey2936
Copy link
Author

Zoey2936 commented Aug 7, 2024

PC-Zoey:~# echo | openssl s_client -connect api.telegram.org:443 -servername api.telegram.org 2>/dev/null | openssl x509 -noout -serial
serial=DF94C51B5A76E3CB

not sure...

@Zoey2936
Copy link
Author

so the current solution would be CFLAGS="-DWOLFSSL_NO_ASN_STRICT"?

@realyukii
Copy link

I tried CFLAGS="-DWOLFSSL_NO_ASN_STRICT" make && sudo make install

but still encounter the same error, I don't use curl, and using wolfssl as library, the code is hosted on gitlab repository

@realyukii
Copy link

realyukii commented Oct 14, 2024

I tried a workaround mentioned by @Zoey2936
switch to commit 8970ff4 (where 5.7.0 released) and build from there:

# cleanup previous build
make clean
git ls-files -i -o --exclude-standard | xargs rm -rf
# setup, build and install
./autogen.sh
./configure --enable-sys-ca-certs
make
sudo make install

but I still got the asn parsing error message :(

is there a way to check wolfssl library version? just to make sure I've compiled and used the appropriate version

@realyukii
Copy link

realyukii commented Oct 14, 2024

Woops, I made a mistake. I didn't aware that I've installed wolfssl (implicitly) from package manager, it might be linked to the library that provided by package manager instead of newly build one

if I run gcc main.c -L ~/path/to/wolfssl/src/.libs/ -lwolfssl, will it linked with the path from -L or from default path from system /usr/lib or smth? how to make sure which one is linked?

I found ldd command is useful for this purposes:

	linux-vdso.so.1 (0x000079bf38ec6000)
	libwolfssl.so.42 => /usr/local/lib/libwolfssl.so.42 (0x000079bf38e1f000)
	libc.so.6 => /usr/lib/libc.so.6 (0x000079bf38c0f000)
	libm.so.6 => /usr/lib/libm.so.6 (0x000079bf38b20000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000079bf38ec8000)

but it seems it not linked to the path where I specify it with -L

alright, I copy the shared library to inline it with c source code, to make it using current dir like: gcc main.c -L. -lwolfssl mhmm but still linked to the system path

trying with export LD_LIBRARY_PATH=. before execute the binary, the output of LD_DEBUG=libs ./a.out:

    447974:	find library=libwolfssl.so.42 [0]; searching
    447974:	 search path=./glibc-hwcaps/x86-64-v4:./glibc-hwcaps/x86-64-v3:./glibc-hwcaps/x86-64-v2:.		(LD_LIBRARY_PATH)
    447974:	  trying file=./glibc-hwcaps/x86-64-v4/libwolfssl.so.42
    447974:	  trying file=./glibc-hwcaps/x86-64-v3/libwolfssl.so.42
    447974:	  trying file=./glibc-hwcaps/x86-64-v2/libwolfssl.so.42
    447974:	  trying file=./libwolfssl.so.42
    447974:	 search cache=/etc/ld.so.cache
    447974:	  trying file=/usr/lib/libwolfssl.so.42
    447974:	
    447974:	find library=libc.so.6 [0]; searching
    447974:	 search path=./glibc-hwcaps/x86-64-v4:./glibc-hwcaps/x86-64-v3:./glibc-hwcaps/x86-64-v2:.		(LD_LIBRARY_PATH)
    447974:	  trying file=./glibc-hwcaps/x86-64-v4/libc.so.6
    447974:	  trying file=./glibc-hwcaps/x86-64-v3/libc.so.6
    447974:	  trying file=./glibc-hwcaps/x86-64-v2/libc.so.6
    447974:	  trying file=./libc.so.6
    447974:	 search cache=/etc/ld.so.cache
    447974:	  trying file=/usr/lib/libc.so.6
    447974:	
    447974:	find library=libm.so.6 [0]; searching
    447974:	 search path=./glibc-hwcaps/x86-64-v4:./glibc-hwcaps/x86-64-v3:./glibc-hwcaps/x86-64-v2:.		(LD_LIBRARY_PATH)
    447974:	  trying file=./glibc-hwcaps/x86-64-v4/libm.so.6
    447974:	  trying file=./glibc-hwcaps/x86-64-v3/libm.so.6
    447974:	  trying file=./glibc-hwcaps/x86-64-v2/libm.so.6
    447974:	  trying file=./libm.so.6
    447974:	 search cache=/etc/ld.so.cache
    447974:	  trying file=/usr/lib/libm.so.6
    447974:	
    447974:	
    447974:	calling init: /lib64/ld-linux-x86-64.so.2
    447974:	
    447974:	
    447974:	calling init: /usr/lib/libc.so.6
    447974:	
    447974:	
    447974:	calling init: /usr/lib/libm.so.6
    447974:	
    447974:	
    447974:	calling init: /usr/lib/libwolfssl.so.42
    447974:	
    447974:	
    447974:	initialize program: ./a.out
    447974:	
    447974:	
    447974:	transferring control: ./a.out
    447974:	
    447974:	
    447974:	calling fini:  [0]
    447974:	
    447974:	
    447974:	calling fini: /usr/lib/libwolfssl.so.42 [0]
    447974:	
    447974:	
    447974:	calling fini: /usr/lib/libm.so.6 [0]
    447974:	
    447974:	
    447974:	calling fini: /usr/lib/libc.so.6 [0]
    447974:	
    447974:	
    447974:	calling fini: /lib64/ld-linux-x86-64.so.2 [0]
    447974:	
ASN parsing error, invalid input

it print trying file=./libwolfssl.so.42 but at the same time it also print calling init: /usr/lib/libwolfssl.so.42. mhmmm, so, which version is used based on the log?

same goes for gcc -Wl,-rpath . main.c -lwolfssl

@realyukii
Copy link

realyukii commented Oct 20, 2024

nevermind, using the suggestion mentioned by @Zoey2936 actually works, I just need to make sure that the appropriate compiled library is indeed loaded, and patchelf come in handy to solve this.

btw, CFLAGS="-DWOLFSSL_NO_ASN_STRICT" didn't work, I've tried it on master branch.

@FrothyB
Copy link

FrothyB commented Oct 25, 2024

I also ran into this, funnily enough also when trying to reach api.telegram.org.

Can confirm that building with -DWOLFSSL_NO_ASN_STRICT added to my cflags fixed it.

@realyukii
Copy link

realyukii commented Oct 25, 2024

I just realize patchelf command not make my program point to the *.so file in the current directory, the program still load it from the system path however it works lol (it seems I forgot that I've done make install before). on my system, the default library name linked each time compile with -lwolfssl is point to libwolfssl.so.42 thus it's an old one installed from package manager and expected to be error in this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants