Re: [chrony-dev] wolfSSL support

> There might be interest, but I'd like to get an idea on what would be the benefits, and how difficult it would be to maintain.

wolfSSL's primarily used in the embedded world, as it's much smaller than OpenSSL and similar libraries. wolfSSL also has a valid (i.e. not expired) FIPS 140-2 cert and a 140-3 cert on the way. The customer that drove this work needed wolfSSL for FIPS compliance.

> how much code it would be

Are you asking about the size of libwolfssl or how much code would be added to chrony? For the former, it really depends on how wolfSSL is configured, but like I said, generally it's much smaller than libcrypto/libssl. For the latter, somewhere in the ballpark of the line additions of the patch I sent.

> After a rebuild it looks like it would increase the size substantially, so I guess it couldn't be the default.

How are you building wolfSSL? And can you share your build size comparison? I'm decently confident I can reduce the size to an acceptable range once I've got an idea of what a "good" size is.

> My first objection to the patch would be that it duplicates the nts_ke_session code. I tried to diff the two files and it looks like most of the used GnuTLS functions have an equivalent in wolfSSL, or they could be emulated easily. If I'm missing some important detail, please let me know.

Yeah, there's surely a cleaner way to do this. Consider the patch a minimum viable solution for our customer. You're not missing any important detail, at least not that I recall (this work is several months old; my memory of the details isn't great).

> Have you considered writing a minimal library that would provide all the GnuTLS functions in order for chronyd to work on top of wolfSSL?

If I understand correctly, you're talking about a library that just maps the GnuTLS functions onto wolfSSL functions? If so, that seems less user-friendly than just letting users --enable-wolfssl/--with-wolfssl to a regular libwolfssl, rather than a shim library. GnuTLS can of course still be the default.

Typically, to create a "minimal" library, we'd just figure out what preprocessor macros and configure options to provide wolfSSL to produce the smallest lib (e.g. wolfSSL can be configured to strip out all TLS client or server code, if the application needs only one side's functionality). Then, that configure line becomes part of the documentation for building chrony with wolfSSL.

> If that is not practical and and some agreement is reached that it should be supported in the chrony code, I think the patches would need to:

> 1. define some interface for the TLS functions (tls.h)
> 2. refactor the session code to have all gnutls-specific code in a
> separate file (tls_gnutls.c)
> 3. add the wolfSSL support (tls_wolfssl.c)

> This would be similar to the hash/cmac/siv providers. I could help with 1.. and 2. We would need to be careful and make sure that there are no security issues, blocking calls, etc.

Agreed on all points.

> so working with libraries like this would be helpful on enabling the adoption of NTS.

Just a note on this: AES-SIV isn't FIPS-certifiable, to my knowledge, which may make "FIPS NTS" difficult for certain users with strict FIPS requirements. wolfCrypt (wolfSSL's crypto code) does have a FIPS-validated AES-CTR implementation, which is one of the core primitives needed by SIV.

--

Hayden

On Tue, Jul 26, 2022 at 12:35 PM Elliott, Robert (Servers) <elliott@xxxxxxx> wrote:

> -----Original Message-----
> From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
> Sent: Tuesday, July 26, 2022 10:40 AM
> To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [chrony-dev] wolfSSL support
>
> On Fri, Jul 22, 2022 at 08:53:56AM -0700, Hayden Roche wrote:
> > A while back, I did a port of chrony 4.1 to wolfSSL for crypto/NTS for
> > one of our (wolfSSL's) customers. Here's where we host the patch:
> > https://github.com/wolfSSL/osp/tree/master/chrony/4.1
> >
> > Would you be interested in having this upstream? If so, I'll clean up
> > the patch and make any changes needed to get it to play with the latest
> code.
>
> There might be interest, but I'd like to get an idea on what would be
> the benefits, how much code it would be and how difficult it would be
> to maintain.
>
> wolfSSL doesn't seem to be widely used on desktop/server systems. For
> example, it's not packaged in Fedora, so I'd need to build it myself
> for testing. On OpenWrt, which I use heavily and where I maintain the
> chrony package, the system wolfSSL doesn't seem to have all the
> options needed for chrony. After a rebuild it looks like it would
> increase the size substantially, so I guess it couldn't be the
> default.

Some embedded systems (e.g., system-on-chip based devices) need to use
FIPS 140-validated modules for crypto, and companies might standardize
on certain libraries across projects to minimize the number of
validations required, so working with libraries like this would
be helpful on enabling the adoption of NTS.

--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.