On Wed, Nov 25, 2020 at 02:19:38PM -0500, Aisha Tammy wrote: > On 11/25/20 2:01 PM, Theo Buehler wrote: > > On Wed, Nov 25, 2020 at 01:12:03PM -0500, Aisha Tammy wrote: > >> On 11/25/20 12:34 PM, Stuart Henderson wrote: > >>> On 2020/11/25 12:03, Aisha Tammy wrote: > >>>> Hi, > >>>> It has come to my attention that upstream does not support > >>>> libressl and only wants to support openssl > >>>> https://github.com/uNetworking/uWebSockets/issues/994 > >>>> > >>>> I am unsure on how to fix this port. > >>>> There is no problem right now as the only consumer www/purritobin > >>>> does not use the SSL functionality in 0.2.4 (the current version in > >>>> tree). > >>>> > >>>> The new updated version www/purritobin-0.3.1 (not yet sent the diff) > >>>> does use SSL functionality optionally during runtime, which will be > >>>> broken > >>>> if net/usockets doesn't get fixed. > >>>> > >>>> Can anyone help with fixing this linking? > >>>> > >>>> The updated version of usockets and purritobin do work correctly when > >>>> linked with OpenSSL when used on linux (tested on gentoo). > >>>> > >>>> Thanks, > >>>> Aisha > >>> "LibreSSL seems to be just like most forks are; a joke." lovely. > >> I know right :( > >>> what is the actual breakage when trying to use it with libressl? > >>> > >> > >> When doing a paste, with curl, using an SSL connection, the error is: > > > > The first thing getting in the way is unveil. You probably don't want to > > have certificate and key in the storage directory. That won't be fixed > > by a switch to OpenSSL: > > > > /* based and lit method to make sure that nothing goes wrong */ > > #if defined(__OpenBSD__) > > /* the only directory we need access to is the storage directory */ > > int unveil_err = unveil(storage_directory.c_str(), "rwxc"); > > if (unveil_err != 0) { > > err(unveil_err, "Error: could not unveil storage folder: %s", > > storage_directory.c_str()); > > } > > /* also we only need small amounts of net and socket access */ > > (void)pledge("stdio rpath wpath cpath inet unix", NULL); > > #endif > > > > The library still needs to load certificate and key correctly, which it > > doesn't (the connection errors out since libssl can't load the cert), > > but I haven't looked into why that is. > > > > https://github.com/openbsd/src/blob/master/lib/libssl/tls13_server.c#L625 > > > >> > >> * Trying 73.215.141.174:42069... > >> * Connected to epsilonknot.xyz (73.215.141.174) port 42069 (#0) > >> * ALPN, offering h2 > >> * ALPN, offering http/1.1 > >> * successfully set certificate verify locations: > >> * CAfile: /etc/ssl/certs/ca-certificates.crt > >> * CApath: /etc/ssl/certs > >> * TLSv1.3 (OUT), TLS handshake, Client hello (1): > >> * TLSv1.3 (IN), TLS handshake, Server hello (2): > >> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): > >> * TLSv1.3 (IN), TLS alert, handshake failure (552): > >> * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure > >> * Closing connection 0 > >> curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert > >> handshake failure > >> > >> Thanks a bunch, > >> Aisha > > > > OMG!!!!! YOU ARE A GENIUS! > It worked with commenting out the unveil :D :D :D > That is amazing!!
Oh, great. So I messed up my testing when it didn't load the cert for me...:) > It seems I am dumb about not knowing what I write myself... > Sorry about this :( No worries. This happens to all of us :) I ran a test instance under ktrace. ktrace -di ./purrito -l -d localhost -s /tmp/purritobin/ -k /tmp/localhost.key -c /tmp/localhost.crt -n localhost Then looking at the output of kdump showed that opening /tmp/localhost.key gave ENOENT. The reason for this was then rather obvious. > Fixing up the unveil is easy enough now that I know the problem. Indeed. > On a side note, am curious about this not being an error during runtime. > I thought wrong read access would terminate the program :O Only pledge aborts. As mentioned above, unveil gives ENOENT on access of hidden files. I'm not entirely sure why the server lib doesn't give a meaningful error, though. It should... > On a side side note: While this consumer is correctly working now, > the upstreams horrible statement still does exist... > Do we want/need to link it to OpenSSL instead? I don't think so. From a quick glance, usockets doesn't seem to do anything particularly fancy libssl-wise. We use OpenSSL in ports only if there really is no other way (missing API, or occasionally due to major breakage). This should not happen with a relatively simple webserver. > There doesn't seem to be an immediate need but yea... I have no clue > what internal shenanigans happen in OpenSSL vs LibreSSL. We strive to be a drop-in replacement as far as possible and reasonable. Things certainly are a far cry from perfect for everyone needing to deal with this. However, very commonly used things should work mostly the same way. (My work on OpenBSD has been mainly in LibreSSL in the last few years, so I'm somewhat biased). > > Thanks so much, > Aisha >
