a_Tls_openssl_connect: Assertion `!ERR_get_error()' failed. #51
Comments
|
Could be related to this. The author talks about some possible causes and workarounds in that comment! @badsectoracula cool profile image -- classic Netscape animation! 😸 |
|
I wrote toplevel comment and made this bug report as rodarima asked :-). I placed a breakpoint in OpenSSL's |
|
@badsectoracula seems a bit of discussion on this here: nodejs/node-v0.x-archive#1719 Error queue is not drained and that thread seems to suggest draining it. 😹 As it's error queue it might be hard to locate the origin of anything in it. In the same file they drain it here |
|
Thanks for reporting it @badsectoracula
I cannot reproduce it with OpenSSL 3.2.0 or 1.1.1.w (the ones I have available in Arch Linux): Also, here my connection is not very fast so I might not be fast enough for the redirect to cause the error. I will try to link with the same version of OpenSSL in case is an issue of that specific version. |
rodarima
changed the title
|
Cannot reproduce with OpenSSL 3.1.4 either and setting the duckduckgo host to the same IP (via /etc/hosts): This could still be explained by a race between closing the connection and the new one being opened, which in my setup occurs later. I checked the code and it looks that the shutdown is not very well done, we need to do some checking before ensuring the connection is closed (at least it is recommended) and ensure there are no errors in the queue. Here is how curl closes it: https://github.com/curl/curl/blob/912d80c68019d3d9a4ceb9993a596dff8009f4d0/lib/vtls/openssl.c#L1880 |
|
Managed to reproduce a similar error after shaping the bandwidth to 10KB/s and loading a big page via TLS (it takes a bit of time): Although this is failing due to an ALERT, the same assert is triggering. |
|
Similar symptoms as https://groups.google.com/g/dillo/c/zMRHPF1Aa7o/ |
Hmm, I don't think this is possible in OpenSSL 3.1.4, the ERR_put_error function has been deprecated, and it is only defined now with a macro. I suspect that you have another OpenSSL library installed, which is the one that Dillo is using and that still provides ERR_put_error() in which you have placed your breakpoint. You can see which OpenSSL library is loaded by using: Based on openSUSE website, they include the 1.1.1w version in the openssl-1_1 package. I will try to reproduce it with 1.1.1w again, following this hypothesis. Created issue #57 to prevent this situation in the future. |
|
At least one of the problems is that SSL_shutdown() is trying to perform a write in the fd=7 to send a close notification, but the file descriptor was closed. This causes SSL_shutdown to return -1 (failure) and errno=6 (Bad file descriptor): |
You are right, i saw i had OpenSSL installed and assumed Dillo would use "the" OpenSSL. Turns out i was wrong, Dillo is linked against LibreSSL, not OpenSSL. Specifically it is linked against LibreSSL 3.7.0. It links against the So perhaps the issue happens only with LibreSSL? |
It looks like. I can reproduce it with LibreSSL (now it shows which library is in use): It seems to be caused by the attempt to shutdown the session with the file descriptor closed. In OpenSSL doesn't cause an error to be added to the queue (it just returns -1) but in LibreSSL it does. I'll test a bit more my fix and prepare a PR shortly. Also, I never tried LibreSSL, didn't expected it to just link and run. I'll also consider adding it to the supported libraries. |
Trying to open a site with https causes an assertion error to kill Dillo.
Console output from after trying to visit
lite.duckduckgo.com:Notice the tls_openssl.c:1183 part. The relevant line.
I'm using OpenSSL 3.1.4 from openSUSE. This does not happen with mbedSSL though i don't think the SSL library is the issue, the linked code seems to assume there are no OpenSSL errors before entering this function, but somewhere an error is added to OpenSSL's error queue that isn't checked.
The text was updated successfully, but these errors were encountered: