Hi m_u_h,

To force a failed FIPS POST state, build wolfSSL with HAVE_FORCE_FIPS_FAILURE defined, then at runtime, call wolfCrypt_SetStatus_fips(DRBG_CONT_FIPS_E).

Thanks,
Kareem

Hi singhshikha,

We do rely on some system calls such as closesocket, htons etc.  Please confirm you are linking in your standard library.  If so, you will need to provide wolfSSL with your OS' equivalent to these functions.  We check if our function aliases such as CloseSocket have been defined, which allows you to override them by defining them in your user_settings.h:

#define CloseSocket(s) YourCloseSocketFn(s)
#define XHTONS(a) YourHtoNsFn((a))
#define XINET_PTON(a,b,c)   YourInet_PtonFn((a),(b),(c))
#define DTLS_RECVFROM_FUNCTION YourRecvFromFn
#define DTLS_SENDTO_FUNCTION YourSendToFn

If you don't have any of these functions, you'll need to define a wrapper function instead which provides equivalent functionality.
setsockopt, getpeername and getsockopt are currently called directly in our code and can't be overridden.
WSAGetLastError is coming from USE_WINDOWS_API, don't define this if you don't have Windows API support.

If you continue to run into issues, please reach out to us at support AT wolfssl DOT com with your user_settings.h.  It would also be helpful to know what kind of system calls your OS has available.

I recommend upgrading to our latest release 5.6.0 when feasible for the best support and performance.

Thanks,
Kareem

Hello avlec,

Yes, this is expected.  As part of certificate validation, we ensure that the current system time falls between the notBefore and notAfter dates from the certificate.  To perform this check, the system time must be set correctly before running wolfSSL.
We get the current system time using gmtime_s, gmtime_r or gmtime, depending on which is available on the system.  It's possible that glibc supports a gmtime call which musl does not, which is causing the behavior difference you are seeing.
You can run strace on your application to confirm which time call we are using, and whether it is returning a valid date.

Thanks,
Kareem

Hi Tom,

Version error/-326 means the client and server were unable to match TLS versions.
Most likely, your server needs a TLS version you are not building with.  By default, we only enable TLS 1.2 and 1.1.
I would start with TLS 1.3, which you can enable by defining WOLFSSL_TLS13 HAVE_TLS_EXTENSIONS and HAVE_SUPPORTED_CURVES in your user_settings.h.
If instead you need TLS 1.0, you can define WOLFSSL_ALLOW_TLSV10 to enable this.

If you still have issues, please confirm how you are setting up your wolfSSL context, for example ctx = wolfSSL_CTX_new(wolfSSLv23_client_method()).  Try using wolfSSLv23_client_method() if you aren't already, as this allows us to select the TLS version at connect time.

Thanks,
Kareem

Hi,

Please enable wolfSSL debug logging by defining CONFIG_WOLFSSL_DEBUG/DEBUG_WOLFSSL and attach a debug log here.
Please also attach the cert you are trying to register.
If this is sensitive information, please contact us at support [AT] wolfssl [dot] com.

Hi ajmal,

Yes, that is certainly a valid approach.  But of course, you should not need any workarounds ideally.
Can you please confirm which wolfSSL version you're on, and what toolchain you're using?  This will assist us in fixing this upstream.

Thanks,
Kareem

Hello Scott,

We provide SNMP support via a net-SNMP patch: https://github.com/wolfSSL/osp/blob/mas … .9.1.patch
You will find instructions on how to use the patch at the top of the patch file, in the comment block.
You will need a utility like "patch" or "git apply" to apply the patch file.

Thanks,
Kareem

Hi mamonetti,

Thanks for sharing and for your patience.

Your wolfSSL build settings look good to me.  The problem is Harmony is shipping an outdated wolfSSL release.  I do recognize the wolfSSL_read issue you are seeing, it should be fixed by this PR: https://github.com/wolfSSL/wolfssl/pull/4203  However, rather than cherry-picking it, I would strongly recommend you upgrade to our latest release, 5.5.3, for the best security and functionality.  You can find our latest release in our Github repo: https://github.com/wolfSSL/wolfssl/releases

You will need to register the appropriate CA certificates on startup for our verification to succeed, please retry after adding your CA certificates.

Yes, you can toggle our CA checking at runtime using wolfSSL_set_verify.  Set the second parameter to SSL_VERIFY_PEER to enable validation, SSL_VERIFY_NONE to disable it.  We strongly recommend against using SSL_VERIFY_NONE in production, as it removes a lot of the benefit of SSL.  You can find more information on wolfSSL_set_verify here: https://www.wolfssl.com/documentation/m … set_verify

Please let me know if you have any further questions.

Thanks,
Kareem

Hi Frederik,

When using a post-quantum algorithm, only the client needs to do keygen, as opposed to both sides for typical algorithms.  This explicit call helps us enforce this, and prevent doing keygen on the server-side.
In addition, having keygen in its own call allows us to speed up connection time by doing more work during initialization.
Since some post-quantum algorithms such as Kyber have multiple levels, our current approach also lets us prevent generating and sending excess keys for all levels, when only one level was requested.

Thanks,
Kareem

Hi Frederik,

This is indeed expected behavior, as we do not generate an ephemeral key until you call wolfSSL_UseKeyShare.

May I ask what project you are using our post-quantum support for?  Are you working on a personal or commercial project?  Feel free to contact us at support [AT] wolfssl [DOT] com if these details are sensitive.

Thanks,
Kareem

Hi m_u_h,

You can call wolfCrypt_GetStatus_fips to get the current FIPS POST status, if it returns 0, POST was successful, non-zero means there was an error.
Yes, you can call wolfCrypt_IntegrityTest_fips to manually trigger a POST.

Thanks,
Kareem