Re: [help needed] net/usockets - needs to link to openssl instead of libressl
On 11/25/20 2:48 PM, Theo Buehler wrote:
> 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.
>
Gotcha, that makes sense
. Thanks for glancing over :)
>> 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
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
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!!
It seems I am dumb about not knowing what I write myself...
Sorry about this :(
Fixing up the unveil is easy enough now that I know the problem.
On a side note, am curious about this not being an error during runtime.
I thought wrong read access would terminate the program :O
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?
There doesn't seem to be an immediate need but yea... I have no clue
what internal shenanigans happen in OpenSSL vs LibreSSL.
Thanks so much,
Aisha
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
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: * 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
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
On 2020/11/25 14:19, Aisha Tammy wrote: > 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? Not if it works. Since the only thing using usockets/uwebsockets in ports at the moment is purritobin it doesn't much matter anyway, but if it was more common then by switching it to linking against OpenSSL would mean that ports using usockets could not be linked to other libraries that pull in libssl/libcrypto (for example most database client libraries) as they would conflict. Switching a build to OpenSSL is really only for special cases where a port really needs something that LibreSSL doesn't/won't support and usually only desirable for 'leaf' ports. Currently only done for nrpe, nsca-ng and sslscan which have particular reasons. > There doesn't seem to be an immediate need but yea... I have no clue > what internal shenanigans happen in OpenSSL vs LibreSSL. Library users shouldn't rely on internals anyway, just use the published API. OpenSSL has some APIs that LibreSSL doesn't - if usockets starts to use one of these then either look at whether the usockets feature requiring it is necessary, maybe it can be disabled in usockets, whether it might make sense to add to libressl, or to stick with an older version of usockets.
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
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
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
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
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
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. what is the actual breakage when trying to use it with libressl?
