- Dillo-dev - lists.mailman3.com

Re: TLS connect error: "an EOF was observed that violates the protocol"

by Theo Buehler

On Wed, Aug 28, 2024 at 08:14:20PM +0200, a1ex(a)dismail.de wrote: > Hi, > > On Wed, 28 Aug 2024 19:12:43 +0200 > Rodrigo Arias <rodarima(a)gmail.com> wrote: > > > You may be able to get some info on where it is failing by building > > Dillo with the address sanitizer enabled: > > > > $ git clone https://github.com/dillo-browser/dillo > > $ cd dillo > > $ ./autogen.sh > > $ mkdir build > > $ cd build > > $ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g > > -fsanitize=address' $ make > > $ src/dillo https://narkive.com > > That doesn't seem to work: > > $ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g > -fsanitize=address' > checking build system type... x86_64-unknown-openbsd7.6 > [...] > configure: error: C compiler cannot create executables > See `config.log' for more details yes, asan isn't supported on openbsd. > dillo(76315) in malloc(): write to free chunk 0x1957a5e82c0[24..31]@32 > allocated at /usr/lib/libc++.so.10.0 0x8b918 (preceding chunk > 0x1957a5e82a0 allocated at /usr/local/lib/libcrypto.so.53.0 0x1a7f51) what's the output of addr2line -e /usr/lib/libc++.so.10.0 0x8b918 and addr2line -e /usr/local/lib/libcrypto.so.53.0 0x1a7f51 on your system?

Aug. 28, 2024

Re: TLS connect error: "an EOF was observed that violates the protocol"

by a1ex＠dismail.de

Hi, On Wed, 28 Aug 2024 19:12:43 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > You may be able to get some info on where it is failing by building > Dillo with the address sanitizer enabled: > > $ git clone https://github.com/dillo-browser/dillo > $ cd dillo > $ ./autogen.sh > $ mkdir build > $ cd build > $ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g > -fsanitize=address' $ make > $ src/dillo https://narkive.com That doesn't seem to work: $ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g -fsanitize=address' checking build system type... x86_64-unknown-openbsd7.6 [...] configure: error: C compiler cannot create executables See `config.log' for more details config.log: [...] configure:4670: checking whether the C compiler works configure:4692: cc -Og -g -fsanitize=address -I/usr/local/include -I/usr/X11R6/include -L/usr/local/lib -L/usr/X11R6/lib conftest.c >&5 cc: error: unsupported option '-fsanitize=address' for target 'amd64-unknown-openbsd7.6' [...] I also tried it with gcc, but also no luck: configure:4670: checking whether the C compiler works configure:4692: egcc -Og -g -fsanitize=address -I/usr/local/include -I/usr/X11R6/include -L/usr/local/lib -L/usr/X11R6/lib conftest.c >&5 ld: error: unable to find library -lasan Then I tried this: $ MALLOC_OPTIONS=D dillo result: Nav_open_url: new url='https://narkive.com' Dns_server [0]: narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 TLS connect error: "an EOF was observed that violates the protocol" Tls_close_by_key: Avoiding SSL shutdown for: https://narkive.com fd 6 is done and failed dillo(76315) in malloc(): write to free chunk 0x1957a5e82c0[24..31]@32 allocated at /usr/lib/libc++.so.10.0 0x8b918 (preceding chunk 0x1957a5e82a0 allocated at /usr/local/lib/libcrypto.so.53.0 0x1a7f51) Abort trap (core dumped) So now we have a reference to libcrypto. Here is the backtrace, also with some new info: #0 thrkill () at /tmp/-:2 No locals. #1 0xf3ab3815f99febfa in ?? () No symbol table info available. #2 0x000001956d60a5ab in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 sa = {__sigaction_u = {__sa_handler = 0x3000000010, __sa_sigaction = 0x3000000010}, sa_mask = 3661176352, sa_flags = 31051} mask = 4294967263 #3 0x000001956d5d93e4 in wrterror (d=0x195325a97a8, msg=0x1956d53c0ad "write to free chunk %p[%zu..%zu]@%zu allocated at %s (preceding chunk %p allocated at %s%s)") at /usr/src/lib/libc/stdlib/malloc.c:378 ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x794bda391f40, reg_save_area = 0x794bda391e20}} saved_errno = 35 #4 0x000001956d5df052 in print_chunk_details (pool=0x195325a97a8, p=0x1957a5e82c0, sz=32, index=<optimized out>) at /usr/src/lib/libc/stdlib/malloc.c:2433 buf1 = "/usr/lib/libc++.so.10.0 0x8b918\000\310pam\225\001\000\000\300\337Z1\225\001\000\000\310pam\225\001\000\000\000\000\000\000\000\000\000\000x\322\020\027\225\001\000\000\240\371`z\225\001\000\000\240\371`z\225\001\000\000\250\227Z2\225\001\000\000\000\000\000\000\000\000\000\000IT\327|\370V\347W0 9\332Ky\000\000\000\000\000\000\000\000\000" buf2 = "/usr/local/lib/libcrypto.so.53.0 0x1a7f51", '\000' <repeats 16 times>, "\220c=\225\001\000\000\300\364`z\225\001\000\000\b\000\000\000\000\000\000\000@h=\366\224\001\000\000\272\fе\224\351\327]\310pam\225\001\000\000\253\305Sm\225\001\000\000\270tam\225\001\0-00\000\000\000\000\000\000\000\000" msg = <optimized out> r = <optimized out> chunkinfo = 0x195576c5f88 chunknum = <optimized out> btnode = <optimized out> frame = 0 #5 0x000001956d5da1dd in validate_junk (pool=0x195325a97a8, p=0x1957a5e82c0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:777 step = <optimized out> lp = 0x1957a5e82c0 sz = <optimized out> i = 1741296686955 #6 malloc_bytes (d=0x195325a97a8, size=32) at /usr/src/lib/libc/stdlib/malloc.c:1237 bucket = <optimized out> r = <optimized out> listnum = <optimized out> bp = 0x195576c5f88 i = <optimized out> j = <optimized out> lp = <optimized out> k = <optimized out> p = 0x1957a5e82c0 r = <optimized out> #7 omalloc (pool=0x195325a97a8, sz=32, zero_fill=0) at /usr/src/lib/libc/stdlib/malloc.c:1391 caller = <error reading variable caller (Cannot access memory at address 0x0)> psz = <optimized out> p = <optimized out> #8 0x000001956d5d9689 in _libc_malloc (size=32) at /usr/src/lib/libc/stdlib/malloc.c:1545 saved_errno = 35 d = 0x195325a97a8 r = <optimized out> #9 0x000001956bbc0918 in operator new (size=32) at /usr/src/gnu/lib/libcxx/../../../gnu/llvm/libcxx/src/new.cpp:67 p = <optimized out> #10 0x00000192ef94bfb1 in lout::container::typed::HashSet<lout::object::TypedPointer<dw::core::Widget> >::HashSet(bool, int) () No symbol table info available. #11 >0x00000192ef94bec5 in >dw::core::StackingProcessingContext::StackingProcessingContext() () No symbol table info available. #12 0x00000192ef94bb13 in dw::core::GettingWidgetAtPointContext::GettingWidgetAtPointContext() () No symbol table info available. #13 0x00000192ef94a6c2 in dw::core::Layout::getWidgetAtPoint(int, int) () No symbol table info available. #14 0x00000192ef94b989 in dw::core::Layout::moveToWidgetAtPoint(int, int, dw::core::ButtonState) () No symbol table info available. #15 0x00000192ef94a4fe in dw::core::Layout::motionNotify(dw::core::View*, int, int, dw::core::ButtonState) () No symbol table info available. #16 0x00000192ef93fa0d in dw::fltk::FltkViewBase::handle(int) () No symbol table info available. #17 0x00000192ef8b792c in UI::handle(int) () No symbol table info available. #18 0x0000019517063404 in send(int, Fl_Widget*, Fl_Window*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #19 0x00000195170630da in Fl::handle_(int, Fl_Window*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #20 0x00000195170d1f7c in do_queued_events() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #21 0x00000195170d1e88 in fl_wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #22 0x0000019517061a6e in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #23 0x0000019517061c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #24 0x00000192ef8b3f95 in main () No symbol table info available. Hope this helps! Thanks, Alex

Aug. 28, 2024

Re: TLS connect error: "an EOF was observed that violates the protocol"

by Rodrigo Arias

Hi, I think there are two problems here: 1) The narkive server is sending you an EOF but not us. 2) When that happens Dillo crashes. You may be able to get some info on where it is failing by building Dillo with the address sanitizer enabled: $ git clone https://github.com/dillo-browser/dillo $ cd dillo $ ./autogen.sh $ mkdir build $ cd build $ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g -fsanitize=address' $ make $ src/dillo https://narkive.com Then send *all the lines of the output*. I may be able to emulate an EOF and crash my own Dillo just to reproduce the issue with this information. To debug the TLS traffic you may want to get a network trace with Wireshark so we can compare it. Best, Rodrigo. On Wed, Aug 28, 2024 at 05:45:37PM +0200, a1ex(a)dismail.de wrote: >Hi, > >On Wed, 28 Aug 2024 16:09:25 +0200 >Theo Buehler <tb(a)theobuehler.org> wrote: > >> > Here is the output of 'bt full': >> >> Thanks, that doesn't help us further as such. >> >> I have enabled DEBUG_PACKAGES in dillo, which unfortunately wasn't >> done before. Once the debug-dillo package is available (will be a few >> days), we might get some more insight from a backtrace with symbols... >> >> If you have a ports tree set up (with doas, etc) you can build and >> install it yourself: > >I have built the debug package as advised, here is the result: > >#0 thrkill () at /tmp/-:2 >No locals. >#1 0x4ef74ca4d7368dd1 in ?? () >No symbol table info available. >#2 0x000001049f2745ab in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 > sa = {__sigaction_u = {__sa_handler = 0x3000000010, > __sa_sigaction = 0x3000000010}, sa_mask = 90789216, sa_flags = 29661} > mask = 4294967263 >#3 0x000001049f2433e4 in wrterror (d=0x1054e1c1000, > msg=0x1049f1a7f67 "write to free mem %p[%zu..%zu]@%zu") > at /usr/src/lib/libc/stdlib/malloc.c:378 > ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x73dd05695660, > reg_save_area = 0x73dd05695560}} > saved_errno = 35 >#4 0x000001049f244206 in validate_junk (pool=0x1054e1c1000, p=0x1050ccc5980, argsz=0) > at /usr/src/lib/libc/stdlib/malloc.c:780 > step = <optimized out> > lp = 0x1050ccc5980 > sz = <optimized out> > i = <optimized out> >#5 malloc_bytes (d=0x1054e1c1000, size=32) at /usr/src/lib/libc/stdlib/malloc.c:1237 > bucket = <optimized out> > r = <optimized out> > listnum = <optimized out> > bp = 0x1050957bf18 > i = <optimized out> > j = <optimized out> > lp = <optimized out> > k = <optimized out> > p = 0x1050ccc5980 > r = <optimized out> >#6 omalloc (pool=0x1054e1c1000, sz=32, zero_fill=0) > at /usr/src/lib/libc/stdlib/malloc.c:1391 > caller = <error reading variable caller (Cannot access memory at address 0x0)> > psz = <optimized out> > p = <optimized out> >#7 0x000001049f243689 in _libc_malloc (size=32) at /usr/src/lib/libc/stdlib/malloc.c:1545 > saved_errno = 35 > d = 0x1054e1c1000 > r = <optimized out> >#8 0x000001047d040251 in XCreateRegion () from /usr/X11R6/lib/libX11.so.18.2 >No symbol table info available. >#9 0x00000104c101d2b2 in Fl_Graphics_Driver::clip_box(int, int, int, int, int&, int&, int&, int&) () from /usr/local/lib/libfltk.so.8.0 >No symbol table info available. >#10 0x00000102794e10fe in dw::fltk::FltkViewBase::draw(dw::core::Rectangle const*, dw::fltk::FltkViewBase::DrawType) () >No symbol table info available. >#11 0x00000102794e0fdd in dw::fltk::FltkViewBase::draw() () >No symbol table info available. >#12 0x00000102794e33f0 in dw::fltk::FltkViewport::draw_area(void*, int, int, int, int) () >No symbol table info available. >#13 0x00000104c1020bdc in fl_scroll(int, int, int, int, int, int, void (*)(void*, int, int, int, int), void*) () from /usr/local/lib/libfltk.so.8.0 >No symbol table info available. >#14 0x00000102794e3635 in dw::fltk::FltkViewport::draw() () >No symbol table info available. >#15 0x00000104c0fad2cb in Fl_Group::draw_children() () from /usr/local/lib/libfltk.so.8.0 >No symbol table info available. >#16 0x00000104c0fad62d in Fl_Group::update_child(Fl_Widget&) const () > from /usr/local/lib/libfltk.so.8.0 >No symbol table info available. >#17 0x00000104c0fad2cb in Fl_Group::draw_children() () from /usr/local/lib/libfltk.so.8.0 >No symbol table info available. >#18 0x00000104c0fa557f in Fl_Double_Window::flush(int) () > from /usr/local/lib/libfltk.so.8.0 >No symbol table info available. >#19 0x00000104c0f91bac in Fl::flush() () from /usr/local/lib/libfltk.so.8.0 >No symbol table info available. >#20 0x00000104c0f91a49 in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 >No symbol table info available. >#21 0x00000104c0f91c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 >No symbol table info available. >#22 0x0000010279455f95 in main () >No symbol table info available. > >That is from a 'bt full' like before. If there is something else that >needs to be done, please let me know. > >Regarding what you said before: >>> dillo(84242) in free(): write to free mem 0xb5efb754c40[24..31]@32 > >> If you manage figure out what was at 0xb5efb754c40 that would help a >> lot. > >Is there a practical way to do that? I would try, but not sure how. > >Thanks! > >-Alex >_______________________________________________ >Dillo-dev mailing list -- dillo-dev(a)mailman3.com >To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Aug. 28, 2024

Re: TLS connect error: "an EOF was observed that violates the protocol"

by a1ex＠dismail.de

Hi, On Wed, 28 Aug 2024 16:09:25 +0200 Theo Buehler <tb(a)theobuehler.org> wrote: > > Here is the output of 'bt full': > > Thanks, that doesn't help us further as such. > > I have enabled DEBUG_PACKAGES in dillo, which unfortunately wasn't > done before. Once the debug-dillo package is available (will be a few > days), we might get some more insight from a backtrace with symbols... > > If you have a ports tree set up (with doas, etc) you can build and > install it yourself: I have built the debug package as advised, here is the result: #0 thrkill () at /tmp/-:2 No locals. #1 0x4ef74ca4d7368dd1 in ?? () No symbol table info available. #2 0x000001049f2745ab in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 sa = {__sigaction_u = {__sa_handler = 0x3000000010, __sa_sigaction = 0x3000000010}, sa_mask = 90789216, sa_flags = 29661} mask = 4294967263 #3 0x000001049f2433e4 in wrterror (d=0x1054e1c1000, msg=0x1049f1a7f67 "write to free mem %p[%zu..%zu]@%zu") at /usr/src/lib/libc/stdlib/malloc.c:378 ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x73dd05695660, reg_save_area = 0x73dd05695560}} saved_errno = 35 #4 0x000001049f244206 in validate_junk (pool=0x1054e1c1000, p=0x1050ccc5980, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:780 step = <optimized out> lp = 0x1050ccc5980 sz = <optimized out> i = <optimized out> #5 malloc_bytes (d=0x1054e1c1000, size=32) at /usr/src/lib/libc/stdlib/malloc.c:1237 bucket = <optimized out> r = <optimized out> listnum = <optimized out> bp = 0x1050957bf18 i = <optimized out> j = <optimized out> lp = <optimized out> k = <optimized out> p = 0x1050ccc5980 r = <optimized out> #6 omalloc (pool=0x1054e1c1000, sz=32, zero_fill=0) at /usr/src/lib/libc/stdlib/malloc.c:1391 caller = <error reading variable caller (Cannot access memory at address 0x0)> psz = <optimized out> p = <optimized out> #7 0x000001049f243689 in _libc_malloc (size=32) at /usr/src/lib/libc/stdlib/malloc.c:1545 saved_errno = 35 d = 0x1054e1c1000 r = <optimized out> #8 0x000001047d040251 in XCreateRegion () from /usr/X11R6/lib/libX11.so.18.2 No symbol table info available. #9 0x00000104c101d2b2 in Fl_Graphics_Driver::clip_box(int, int, int, int, int&, int&, int&, int&) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #10 0x00000102794e10fe in dw::fltk::FltkViewBase::draw(dw::core::Rectangle const*, dw::fltk::FltkViewBase::DrawType) () No symbol table info available. #11 0x00000102794e0fdd in dw::fltk::FltkViewBase::draw() () No symbol table info available. #12 0x00000102794e33f0 in dw::fltk::FltkViewport::draw_area(void*, int, int, int, int) () No symbol table info available. #13 0x00000104c1020bdc in fl_scroll(int, int, int, int, int, int, void (*)(void*, int, int, int, int), void*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #14 0x00000102794e3635 in dw::fltk::FltkViewport::draw() () No symbol table info available. #15 0x00000104c0fad2cb in Fl_Group::draw_children() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #16 0x00000104c0fad62d in Fl_Group::update_child(Fl_Widget&) const () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #17 0x00000104c0fad2cb in Fl_Group::draw_children() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #18 0x00000104c0fa557f in Fl_Double_Window::flush(int) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #19 0x00000104c0f91bac in Fl::flush() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #20 0x00000104c0f91a49 in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #21 0x00000104c0f91c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #22 0x0000010279455f95 in main () No symbol table info available. That is from a 'bt full' like before. If there is something else that needs to be done, please let me know. Regarding what you said before: >> dillo(84242) in free(): write to free mem 0xb5efb754c40[24..31]@32 > If you manage figure out what was at 0xb5efb754c40 that would help a > lot. Is there a practical way to do that? I would try, but not sure how. Thanks! -Alex

Aug. 28, 2024

Re: TLS connect error: "an EOF was observed that violates the protocol"

by Theo Buehler

On Wed, Aug 28, 2024 at 03:56:55PM +0200, a1ex(a)dismail.de wrote: > On Wed, 28 Aug 2024 15:29:57 +0200 > Theo Buehler <tb(a)theobuehler.org> wrote: > > > > gdb: > > > Program received signal SIGABRT, Aborted. > > > thrkill () at /tmp/-:2 > > > 2 /tmp/-: No such file or directory. > > > in /tmp/- > > > > Please pkg_add gdb, use 'egdb dillo dillo.core and show the output of > > 'bt full', that might give a clue. > > Here is the output of 'bt full': Thanks, that doesn't help us further as such. I have enabled DEBUG_PACKAGES in dillo, which unfortunately wasn't done before. Once the debug-dillo package is available (will be a few days), we might get some more insight from a backtrace with symbols... If you have a ports tree set up (with doas, etc) you can build and install it yourself: $ cd /usr/ports/www/dillo $ grep DEBUG Makefile # ensure that your tree's up-to-date DEBUG_PACKAGES = ${BUILD_PACKAGES} $ make FETCH_PACKAGES= prepare $ make package $ make INSTALL_DEBUG_PACKAGES=yes install

Aug. 28, 2024

Re: TLS connect error: "an EOF was observed that violates the protocol"

by a1ex＠dismail.de

On Wed, 28 Aug 2024 15:29:57 +0200 Theo Buehler <tb(a)theobuehler.org> wrote: > > gdb: > > Program received signal SIGABRT, Aborted. > > thrkill () at /tmp/-:2 > > 2 /tmp/-: No such file or directory. > > in /tmp/- > > Please pkg_add gdb, use 'egdb dillo dillo.core and show the output of > 'bt full', that might give a clue. Here is the output of 'bt full': #0 thrkill () at /tmp/-:2 No locals. #1 0x93e8d49f8f1828f2 in ?? () No symbol table info available. #2 0x00000675d78d25ab in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 sa = {__sigaction_u = {__sa_handler = 0x3000000010, __sa_sigaction = 0x3000000010}, sa_mask = 2205690992, sa_flags = 29926} mask = 4294967263 #3 0x00000675d78a13e4 in wrterror (d=0x675dc6e7678, msg=0x675d7805f67 "write to free mem %p[%zu..%zu]@%zu") at /usr/src/lib/libc/stdlib/malloc.c:378 ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x74e683782d70, reg_save_area = 0x74e683782c70}} saved_errno = 35 #4 0x00000675d78a2206 in validate_junk (pool=0x675dc6e7678, p=0x675d0e8d1c0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:780 step = <optimized out> lp = 0x675d0e8d1c0 sz = <optimized out> i = <optimized out> #5 malloc_bytes (d=0x675dc6e7678, size=32) at /usr/src/lib/libc/stdlib/malloc.c:1237 bucket = <optimized out> r = <optimized out> listnum = <optimized out> bp = 0x675ba1e5f88 i = <optimized out> j = <optimized out> lp = <optimized out> k = <optimized out> p = 0x675d0e8d1c0 r = <optimized out> #6 omalloc (pool=0x675dc6e7678, sz=32, zero_fill=0) at /usr/src/lib/libc/stdlib/malloc.c:1391 caller = <error reading variable caller (Cannot access memory at address 0x0)> psz = <optimized out> p = <optimized out> #7 0x00000675d78a1689 in _libc_malloc (size=32) at /usr/src/lib/libc/stdlib/malloc.c:1545 saved_errno = 35 d = 0x675dc6e7678 r = <optimized out> #8 0x000006761b3d9918 in operator new (size=32) at /usr/src/gnu/lib/libcxx/../../../gnu/llvm/libcxx/src/new.cpp:67 p = <optimized out> #9 0x000006734c32cdd1 in ?? () No symbol table info available. #10 0x000006734c32cce5 in ?? () No symbol table info available. #11 0x000006734c32c933 in ?? () No symbol table info available. #12 0x000006734c32b4e2 in ?? () No symbol table info available. #13 0x000006734c32c7a9 in ?? () No symbol table info available. #14 0x000006734c32b31e in ?? () No symbol table info available. #15 0x000006734c32082d in ?? () No symbol table info available. #16 0x000006734c297b5c in ?? () No symbol table info available. #17 0x000006754d2f179b in fl_fix_focus() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #18 0x000006754d2f1ca7 in Fl::handle_(int, Fl_Window*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #19 0x000006754d36483b in fl_handle(_XEvent const&) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #20 0x000006754d360f40 in do_queued_events() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #21 0x000006754d360e88 in fl_wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #23 0x000006754d2f0c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #24 0x000006734c2941d5 in ?? () No symbol table info available. #25 0x000006734c2932bb in ?? () No symbol table info available. #26 0x0000000000000000 in ?? () No symbol table info available.

Aug. 28, 2024

Re: TLS connect error: "an EOF was observed that violates the protocol"

by Theo Buehler

> Nav_open_url: new url='https://narkive.com' > Dns_server [0]: narkive.com is 149.248.211.108 > Connecting to 149.248.211.108:443 > TLS connect error: "an EOF was observed that violates the protocol" > Tls_close_by_key: Avoiding SSL shutdown for: https://narkive.com > fd 9 is done and failed > dillo(84242) in free(): write to free mem 0xb5efb754c40[24..31]@32 ok, that's a use after free, perhaps triggered by the unexpected EOF... Can't repro even with vm.malloc_conf flags set. $ dillo https://narkive.com paths: Cannot open file '/home/tb/.dillo/dillorc': No such file or directory paths: Using /etc/dillo/dillorc paths: Cannot open file '/home/tb/.dillo/keysrc': No such file or directory paths: Using /etc/dillo/keysrc paths: Cannot open file '/home/tb/.dillo/domainrc': No such file or directory paths: Using /etc/dillo/domainrc Domain: Default accept. dillo_dns_init: Here we go! (threaded) TLS library: LibreSSL 3.9.0 Disabling cookies. paths: Cannot open file '/home/tb/.dillo/hsts_preload': No such file or directory paths: Cannot open file '/etc/dillo/hsts_preload': No such file or directory paths: Using internal defaults... Nav_open_url: new url='https://narkive.com' Dns_server [0]: narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 narkive.com: TLSv1.3, cipher TLS_AES_128_GCM_SHA256 sha256 2048-bit RSA: /CN=narkive.com sha256 2048-bit RSA: /C=US/O=Let's Encrypt/CN=R11 root: /C=US/O=Internet Security Research Group/CN=ISRG Root X1 NumPendingStyleSheets=1 Dns_server [0]: narkive.net is 188.114.96.12 188.114.97.12 2a06:98c1:3120::c 2a06:98c1:3121::c narkive.net: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 ecdsa-with-SHA256 256-bit EC: /CN=narkive.net ecdsa-with-SHA384 256-bit EC: /C=US/O=Google Trust Services/CN=WE1 sha256 384-bit EC: /C=US/O=Google Trust Services LLC/CN=GTS Root R4 root: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA >>>> a_Nav_repush <<<< Nav_open_url: new url='https://narkive.com' a_Nav_expect_done: repush! Dillo: normal exit! > gdb: > Program received signal SIGABRT, Aborted. > thrkill () at /tmp/-:2 > 2 /tmp/-: No such file or directory. > in /tmp/- Please pkg_add gdb, use 'egdb dillo dillo.core and show the output of 'bt full', that might give a clue. > dillo(84242) in free(): write to free mem 0xb5efb754c40[24..31]@32 If you manage figure out what was at 0xb5efb754c40 that would help a lot. > My nc output matches yours, but ftp still gets the handshake > failure. Maybe it's something network specific on my end? But like I > mentioned, an older OpenBSD system on my network with LibreSSL 3.6.0 > does not have an issue with that site. I disabled pf just in case, but > to no avail. No real idea at this point - sorry.

Aug. 28, 2024

Re: TLS connect error: "an EOF was observed that violates the protocol"

by a1ex＠dismail.de

Hi, On Wed, 28 Aug 2024 13:45:04 +0200 Theo Buehler <tb(a)theobuehler.org> wrote: > > Certainly. Ideally this should not crash Dillo, no matter how > > obscure. > > What crashes dillo? Opening https://narkive.com crashes Dillo for me, It doesn't happen on any other sites: Nav_open_url: new url='https://narkive.com' Dns_server [0]: narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 TLS connect error: "an EOF was observed that violates the protocol" Tls_close_by_key: Avoiding SSL shutdown for: https://narkive.com fd 9 is done and failed dillo(84242) in free(): write to free mem 0xb5efb754c40[24..31]@32 gdb: Program received signal SIGABRT, Aborted. thrkill () at /tmp/-:2 2 /tmp/-: No such file or directory. in /tmp/- > > I don't know why it shows that version number instead of the latest > > one, this is a fresh install of a recent snapshot. > > It's a bit unfortunate, but the development release on current openbsd > snapshots still has 3.9.0 as the version number. It's complicated... > The short story is that we can't crank to 4.0.0 because it would break > the build of some important ports (e.g., rust). Thank you for clarifying this. > > $ ftp https://narkive.com/test > > Trying 149.248.211.108... > > TLS handshake failure: handshake failed: unexpected EOF > > I don't see this: > > $ ftp https://narkive.com/test > Trying 149.248.211.108... > Requesting https://narkive.com/test > ftp: Error retrieving https://narkive.com/test: 404 Not Found > $ nc -cvz narkive.com 443 > Connection to narkive.com (149.248.211.108) 443 port [tcp/https] > succeeded! TLS handshake negotiated TLSv1.3/TLS_AES_128_GCM_SHA256 > with host narkive.com Peer name: narkive.com > Subject: /CN=narkive.com > Issuer: /C=US/O=Let's Encrypt/CN=R11 > Valid From: Fri Jul 26 06:13:58 2024 > Valid Until: Thu Oct 24 06:13:57 2024 > Cert Hash: > SHA256:456275146f4b2e65c16d2432ff87917a4501ddb41dcb158195255c5995abbbf1 > OCSP URL: http://r11.o.lencr.org > > This looks all good from here. My nc output matches yours, but ftp still gets the handshake failure. Maybe it's something network specific on my end? But like I mentioned, an older OpenBSD system on my network with LibreSSL 3.6.0 does not have an issue with that site. I disabled pf just in case, but to no avail. I'm open to any clues on how to diagnose this! Regards, Alex

Aug. 28, 2024

Re: TLS connect error: "an EOF was observed that violates the protocol"

by Theo Buehler

On Wed, Aug 28, 2024 at 01:25:21PM +0200, a1ex(a)dismail.de wrote: > Hi Rodrigo, > > On Tue, 27 Aug 2024 23:09:42 +0200 > Rodrigo Arias <rodarima(a)gmail.com> wrote: > > > >> >dillo-dev.auriga.wearlab.narkive.com:443 > > >> > > > >> >Is this site just broken/misconfigured? > > >> > > >> Cannot reproduce with LibreSSL 3.9.2 on Linux. > > >> ... > > >> Can you test with the latest LibreSSL 3.9.2? > > >> > > >> Is this it happening with the proxy enabled? Also, which user agent > > >> are you using in curl and Dillo? > > > > > >It happens with the stock user agent and no proxy, same with curl. > > >I'm running the latest snapshot of OpenBSD, which would have the > > >latest version of LibreSSL. > > > > > >I don't care about that site, my only worry is that the error can > > >crash Dillo. > > > > If it happens it is a bug on Dillo side as it is not handling all > > errors, regardless of the site. I would like to reproduce it to fix > > it. > > Certainly. Ideally this should not crash Dillo, no matter how obscure. What crashes dillo? > > >This could be an OpenBSD specific issue which wouldn't show up on > > >Linux. > > > > > It could be, but I would first reject that is not due to mismatch of > > versions. > > > > The last LibreSSL as per https://www.libressl.org/ is: > > > > > The latest stable release is 3.9.2 > > > > Which should be printed in the first lines when starting Dillo: > > > > > TLS library: LibreSSL 3.9.2 > > > > If it says 3.9.0, then Dillo is not using the last release. > > I don't know why it shows that version number instead of the latest > one, this is a fresh install of a recent snapshot. It's a bit unfortunate, but the development release on current openbsd snapshots still has 3.9.0 as the version number. It's complicated... The short story is that we can't crank to 4.0.0 because it would break the build of some important ports (e.g., rust). > Anyway, I installed 3.9.2 from source and built Dillo against that. > Now it reports the correct version, but the crash still happens the > same. > > I guess we would need to hear from some other OpenBSD users to confirm > if this a real issue, or if its something whacky on my end. > > I do have an older OpenBSD system which uses LibreSSL 3.6.0, and it does > not exhibit the problem. But on 3 newer systems here the problem occurs. > > Here is an easy way to confirm using only OpenBSD base tools: > > $ ftp https://narkive.com/test > Trying 149.248.211.108... > TLS handshake failure: handshake failed: unexpected EOF I don't see this: $ ftp https://narkive.com/test Trying 149.248.211.108... Requesting https://narkive.com/test ftp: Error retrieving https://narkive.com/test: 404 Not Found $ nc -cvz narkive.com 443 Connection to narkive.com (149.248.211.108) 443 port [tcp/https] succeeded! TLS handshake negotiated TLSv1.3/TLS_AES_128_GCM_SHA256 with host narkive.com Peer name: narkive.com Subject: /CN=narkive.com Issuer: /C=US/O=Let's Encrypt/CN=R11 Valid From: Fri Jul 26 06:13:58 2024 Valid Until: Thu Oct 24 06:13:57 2024 Cert Hash: SHA256:456275146f4b2e65c16d2432ff87917a4501ddb41dcb158195255c5995abbbf1 OCSP URL: http://r11.o.lencr.org This looks all good from here. > This doesn't happen on any other site that I have seen. > > Maybe I should report this to the OpenBSD/LibreSSL people as well, so > I'm CC'ing tb@ What is an example of a site that you can't connect to or even crashes?

Aug. 28, 2024

Re: TLS connect error: "an EOF was observed that violates the protocol"

by a1ex＠dismail.de

Hi Rodrigo, On Tue, 27 Aug 2024 23:09:42 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> >dillo-dev.auriga.wearlab.narkive.com:443 > >> > > >> >Is this site just broken/misconfigured? > >> > >> Cannot reproduce with LibreSSL 3.9.2 on Linux. > >> ... > >> Can you test with the latest LibreSSL 3.9.2? > >> > >> Is this it happening with the proxy enabled? Also, which user agent > >> are you using in curl and Dillo? > > > >It happens with the stock user agent and no proxy, same with curl. > >I'm running the latest snapshot of OpenBSD, which would have the > >latest version of LibreSSL. > > > >I don't care about that site, my only worry is that the error can > >crash Dillo. > > If it happens it is a bug on Dillo side as it is not handling all > errors, regardless of the site. I would like to reproduce it to fix > it. Certainly. Ideally this should not crash Dillo, no matter how obscure. > >This could be an OpenBSD specific issue which wouldn't show up on > >Linux. > > > It could be, but I would first reject that is not due to mismatch of > versions. > > The last LibreSSL as per https://www.libressl.org/ is: > > > The latest stable release is 3.9.2 > > Which should be printed in the first lines when starting Dillo: > > > TLS library: LibreSSL 3.9.2 > > If it says 3.9.0, then Dillo is not using the last release. I don't know why it shows that version number instead of the latest one, this is a fresh install of a recent snapshot. Anyway, I installed 3.9.2 from source and built Dillo against that. Now it reports the correct version, but the crash still happens the same. I guess we would need to hear from some other OpenBSD users to confirm if this a real issue, or if its something whacky on my end. I do have an older OpenBSD system which uses LibreSSL 3.6.0, and it does not exhibit the problem. But on 3 newer systems here the problem occurs. Here is an easy way to confirm using only OpenBSD base tools: $ ftp https://narkive.com/test Trying 149.248.211.108... TLS handshake failure: handshake failed: unexpected EOF This doesn't happen on any other site that I have seen. Maybe I should report this to the OpenBSD/LibreSSL people as well, so I'm CC'ing tb@ Regards, Alex

Aug. 28, 2024