1

(2 replies, posted in wolfSSL)

Hello volga629,

-203 IN_CORE_FIPS_E means our FIPS hash check failed.  When building wolfSSL FIPS you must update the FIPS hash after any build option/environment change, you can either run the script fips-hash.sh in the root of the wolfSSL directory or run the wolfCrypt test and copy the hash it outputs to fips_test.c.  Then rebuild and retry using wolfSSL with strongswan.

Thanks,
Kareem

2

(13 replies, posted in wolfSSL)

Hi volga629,

Yes, configure is what I would recommend to set up wolfSSL with strongswan, since you are able to use configure arguments instead of having to define every single setting.  Your setup looks correct to me.

For the Visual Studio case you will also need the IDE/WIN10 user_settings.h I linked merged with yours, and WOLFSSL_FIPS_READY  defined.

Thanks,
Kareem

3

(13 replies, posted in wolfSSL)

Hi volga629,

You can safely disregard the message in your most recent post as it is just a warning.

For the missing references you are seeing, you will need multiple defines added to your build settings for strongswan.  Since you are using FIPS ready, you will want to start with our "WIN10" Visual Studio project and define WOLFSSL_FIPS_READY in user_settings.h: https://github.com/wolfSSL/wolfssl/tree … /IDE/WIN10
Then you will want to add the following defines to fully enable strongswan support:

#define OPENSSL_ALL
#define SESSION_CERTS
#define WOLFSSL_KEY_GEN
#define WOLFSSL_CERT_GEN
#define WOLFSSL_CERT_EXT
#define HAVE_CRL
#define WOLFSSL_CERT_REQ
#define HAVE_OCSP
#define WOLFSSL_DES_ECB
#define WOLFSSL_LOG_PRINTF
#define WOLFSSL_PUBLIC_MP
#define HAVE_EX_DATA
#define WOLFSSL_DTLS

Thanks,
Kareem

4

(13 replies, posted in wolfSSL)

For Visual Studio you'll need to add the path to your wolfSSL library to your project's additional library directories and wolfssl.lib to your additional dependencies in project properties -> librarian -> general.

5

(13 replies, posted in wolfSSL)

Hello volga629,

Yes, after building wolfSSL you will want to install it with "sudo make install" so your linker can find it.  Depending on wolfSSL's install path, you may need to add the path to LD_LIBRARY_PATH as well.

Thanks,
Kareem

6

(2 replies, posted in wolfSSL)

Hello Volga,

I am seeing a recent commit for PARSE_ERROR in strongswan which should fix this, please try rebuilding with it applied and let me know if it helps: https://github.com/strongswan/strongswa … 2e31a046e1

Thanks,
Kareem

7

(1 replies, posted in wolfSSL)

Hello Isabella,

To enable a DTLS MTU you will need to define WOLFSSL_DTLS and WOLFSSL_DTLS_MTU.  These defines enable DTLS and enable setting the DTLS MTU.  We do support DTLS 1.3 as well which you can enable by defining WOLFSSL_DTLS13.

The implication is you're enabling DTLS which is different than TLS, it uses UDP vs TLS which uses TCP.  You can't set the MTU in TLS 1.3, we only support this for DTLS.

Thanks,
Kareem

8

(1 replies, posted in wolfSSL)

Hi chyuk98,

Thanks for your interest in wolfSSL.  We don't currently support BLAKE1, only BLAKE2 as you've seen.  If you'd like to have us add support for BLAKE1, please reach out to us at support [AT] wolfssl [DOT] com so we can set up a feature request.

Thanks,
Kareem

9

(3 replies, posted in wolfSSL)

I'm glad to hear you were able to get your connection working.
Check out our documentation on static memory here: https://www.wolfssl.com/docs/static-buffer-allocation/

10

(3 replies, posted in wolfSSL)

Hi Isabella,

-188/Unknown CA means you are loading the wrong CA cert for the server you are trying to connect to.  You can confirm you're loading the correct CA cert by connecting with your browser and checking the security/cert chain info there.

Note that since you are using static memory, you must pass in a buffer to functions like wolfSSL_X509_NAME_oneline.

Thanks,
Kareem

11

(1 replies, posted in wolfSSL)

Hello Happy,

After enabling CRL checking, wolfSSL will automatically check your CRL as part of the connection.
If you want to manually perform this check, you can set up a cert manager, enable CRL checking on it with wolfSSL_CertManagerEnableCRL, load your CRL with wolfSSL_CertManagerLoadCRL/wolfSSL_CertManagerLoadCRLBuffer then call wolfSSL_CertManagerCheckCRL to check the CRL: https://www.wolfssl.com/documentation/m … ercheckcrl

Thanks,
Kareem

12

(3 replies, posted in wolfSSL)

Hi MO380,

Please reach out to us at support [AT] wolfssl [DOT] com, you should be able to attach files there.  Please attach your user_settings.h/configure line in your ticket.

Thanks,
Kareem

13

(1 replies, posted in wolfSSL)

Hi Scott,

The two main sources of documentation on our build flags are section 2 of our manual and our user_settings.h examples:
https://www.wolfssl.com/documentation/m … ssor-macro
https://github.com/wolfSSL/wolfssl/tree … es/configs

PSK is enabled by default and doesn't need a flag to enable it.  If you wanted to disable it, you would define NO_PSK.
<wolfssl dir>/configure.ac is what translates our configure arguments into defines, but I would recommend consulting our documentation first.

Thanks,
Kareem

14

(3 replies, posted in wolfSSL)

Hi MO380,

-323 WANT_READ is an expected error during a connection, this just means you should call the connect/read function again until the error goes away.  The error is indicating wolfSSL needs to read additional data which hasn't come in yet.

Check out our LWIP example here: https://github.com/wolfSSL/wolfssl-exam … aster/lwip

Thanks,
Kareem

Hi Rob,

Great question.  We don't currently support this with public APIs, we can give you some guidance on how to do this with internal APIs but it will take some work.  Please contact us at support [AT] wolfssl [DOT] com for more information on this.


Thanks,
Kareem

Hi Scott,

wolfSSL_get_ciphers gets the entire cipher list compiled into the library, it is not getting the currently enabled cipher list.  To get that, you can call wolfSSL_get_cipher_list_ex(ssl, priority).  You will need to make the WOLFSSL object from the WOLFSSL_CTX after you call wolfSSL_CTX_set_cipher_list for it to reflect the cipher list you've set.

Thanks,
Kareem

Hi rvdvpdt,

Great question.  We do support parsing custom extensions with a callback function, check out our example of this here: https://github.com/wolfSSL/wolfssl-exam … callback.c

Thanks,
Kareem

Hi bp787,

To enable wolfssl_dtls_set_mtu, you will need to build with WOLFSSL_DTLS_MTU defined, or if you are using ./configure, you can use --enable-dtls-mtu.

Setting the rx buffer size doesn't apply if you are not using IO callbacks.  Please try setting the MTU and let me know if it helps.

Thanks,
Karee

We do not enable OCSP by default, you need to define HAVE_OCSP, then call wolfSSL_EnableOCSP to enable it: https://www.wolfssl.com/documentation/m … enableocsp

20

(1 replies, posted in wolfSSL)

Hi dcanthony,

How much stack are you giving wolfSSL?  A very common source of crashes/issues is insufficient stack, wolfSSL generally needs about 20-30KB of stack.  As you are on an embedded system I would also recommend defining WOLFSSL_SMALL_STACK.
You may also be running into issues with entropy from your RNG or your RNG in general.  Are you confident your RNG is functioning correctly?

You are correct that you'll usually need additional defines for your RNG, I am not seeing a seed generation function for your platform's RNG so you will need to define your own.

I recommend basing your user_settings.h off of our template here: https://github.com/wolfSSL/wolfssl/blob … template.h
You will want to define your own seed generation function with CUSTOM_RAND_GENERATE: https://github.com/wolfSSL/wolfssl/blob … ate.h#L424

Since you're able to see debug logging, if possible I would recommend upgrading to 5.7.2 and defining WOLFSSL_DEBUG_TRACE_ERROR_CODES in addition to DEBUG_WOLFSSL, this will print error and line numbers in our debug logs.  This feature was added in 5.7.2 so you would need to upgrade for it.

It looks like you have an active support contract with us, can you follow up on this by emailing us at support [AT] wolfssl [DOT] com?  Please provide debug logs and your user_settings.h as well.

Thanks,
Kareem

Hello Happy,

We do support CRLs which you can enable by building wolfSSL with --enable-crl.  To activate support at runtime, call wolfSSL_CTX_EnableCRL followed by wolfSSL_CTX_LoadCRL.  You can find documentation for these functions here: https://www.wolfssl.com/documentation/m … tx_loadcrl

Thanks,
Kareem

Hi Leonie,

Thanks for the followup.  For FFDHE 3072, try defining the CFLAG HAVE_FFDHE_3072.

What size are your DH params?  Are you confident both wolf and OpenSSL are using the same size?  For wolfSSL, you should ideally use 2048, 3072 or 4096, as our code for 1024-bit is not as accelerated.

I would recommend trying WOLFSSL_OLD_PRIME_CHECK as well and seeing if it helps.

If you continue to see the same issue, it would help if you can profile your code and see which functions are taking the most time.

Thanks,
Kareem

Hi Preethi,

Thanks for the followup, I'm glad to hear my suggestions helped.
SP math assembly will help significantly, please share your build log with errors so I can hopefully help you enable this for further speedups.  Your build settings would also be helpful.

As you having trouble attaching files here, please contact us at support [AT] wolfssl [DOT] com for further assistance.

Thanks,
Kareem

Hi Preethi,

I am not able to see your build settings, can you reattach them?

For the best speed with ECC, I would recommend using SP math with SP math assembly speedups:

#define WOLFSSL_HAVE_SP_ECC
#define WOLFSSL_SP_MATH_ALL 
#define WOLFSSL_SP_ARM_CORTEX_M_ASM

ECC_SHAMIR is also a good define for speeding up ECC operations, I would recommend consulting the ECC section of our user_settings.h template here: https://github.com/wolfSSL/wolfssl/blob … template.h

Also make sure you are using our latest wolfSSL release, 5.7.2.

What is the size of the key you are trying to verify?

Thanks,
Kareem

Hello Leonie,

Thank you for your interest in wolfSSL and your extended testing.  I would strongly recommend removing --enable-all from your configure line and replacing it with: --enable-sp --enable-sp-math --enable-sp-asm --enable-intelasm.  This will enable our fastest math library, SP math, and all of our assembly speedups.  OpenSSL uses assembly by default, so this will be a more equivalent comparison.
You can also optionally add CFLAGS='-DWOLFSSL_OLD_PRIME_CHECK' for a further speedup, but this does hurt security and isn't generally recommended.

As for session tickets, we do have an internal session cache which should be enabled by default.

Thanks,
Kareem