1 Reply by marco

(1 replies, posted in wolfSSL)

Hello,

You can add a custom OCSP answer by specifying a custom OCSP lookup callback with `wolfSSL_CTX_SetOCSP_Cb`.
The custom callback can analyze the URL and the request and provide a custom OCSP response.
For example to provide always the same ocsp response you can use:

```
uint8_t static_ocsp_response[] = { /* OCSP response bytes */ };
int ocsp_response_cb(void* Ioctx, const char* url, int urlSz,
              unsigned char* req, int reqSize, unsigned char**resp)
{
    *resp = static_ocsp_response;
    return sizeof(static_ocsp_response);
}

```

I attached a small PoC on how to use the custom cb to provide a static ocsp response.

Regards,
Marco

Go to forum: wolfSSL

2 Reply by marco

(2 replies, posted in wolfSSL)

Hi Nicolas,

Thanks for posting on the forum.
Unfortunately, currently we don't support specifying the ResponderIDs in the Certificate Status Request extension.

The API wolfSSL_CTX_SetOCSP_OverrideURL is used to override the URL for OCSP requests locally.
So if invoked on the client side, it will only affect normal OCSP requests originating from the client.
If invoked on the server side, it will affect OCSP requests originating from the server (either to verify the client certificate and/or to staple OCSP responses for the clients).

If this feature is important to you, feel free to reach us at support@wolfssl.com.

Thanks,
Marco

Go to forum: wolfSSL

3 Reply by marco

(3 replies, posted in wolfSSL)

Hi,

Thank you for your reply. Please refer to the codebase used in this Pull Request for guidance: https://github.com/wolfSSL/wolfssl/pull/6475 (which includes some compile fixes for the reported options).

I ran a quick test with the following configuration options:


./configure --disable-all --enable-tls13 --enable-dtls13 --enable-dtls --enable-psk --disable-dh --disable-ecc --disable-rsa --enable-sp-asm --disable-sha384 --disable-sha512 --disable-sha --disable-sha224 --disable-md5 CFLAGS="-DWOLFSSL_STATIC_PSK -DMAX_PSK_ID_LEN=32 -DWOLFSSL_MAX_MTU=300"

Our memory tool indicates a peak memory usage of around 8-9 KB per connection. The settings above assume the usage of PSK with PSK_KE exchange mode, using the TLS_AES_128_GCM_SHA_256 ciphersuite, and a maximum MTU of ~300 bytes. However, please note that this is a raw number that may vary depending on your application profile and hardware target. I'm confident that if you're not using public key authentication, this number can be further reduced by tailoring it to your application profile.

Using static memory (with `--enable-staticmemory`) unfortunately increases the memory usage due to the fragmentation of a more simple allocator. However, if static memory is mandatory, the impact of fragmentation can be reduced by choosing a bucket allocation size that works better for your application. Please refer to `wolfSSL_StaticBufferSz` for further details.

If you have any additional questions, please feel free to ask.
Regards,
Marco

Go to forum: wolfSSL

4 Reply by marco

(3 replies, posted in wolfSSL)

Hi!

Are you primarily focused on minimizing code size, or is your main goal to reduce run-time memory usage per connection? In both case, what's the maximum amount of memory you can use?

Also, is there any particular reason to use wc_LoadStaticMemory? Is it possible for your target to utilize dynamic memory allocation through a malloc-like allocator?

Best regards,
Marco

Go to forum: wolfSSL

5 Reply by marco

(2 replies, posted in wolfSSL)

Hi _angelo_,

1) About TLS 1.3, is it possible to configure wolfssl to disable change_cipher_spec records ?

Sending of change_chiper_spec should be disabled by default and enabled by the preprocessor define WOLFSSL_TLS13_MIDDLEBOX_COMPAT at compile time. If you aren't using this define and you still see sending of change_cipher_spec, feel free to provide more details on your compilation configuration and I'll look at it.

2) Is it possible co configure the record data chunk size ?

Client may negotiate a maximum message size with the server using the max_fragment_length extension. Other than that wolfSSL have no other way of automatically limiting the max size of a message but it can also be done at the application layer. What's your use case?

- Marco

Go to forum: wolfSSL

6 Reply by marco

(1 replies, posted in wolfBoot)

Hi Thisora,

Thanks for your interest in wolfBoot.
Regarding the use of the linker to build the final image:

I think it's best to separate as much as possible the linking of the application, other stages of the bootloader, and wolfboot itself.
This allows better flexibility and abstractions among these different components, so I believe concatenating the components (as we do with the binassembly tool) is the most simple and effective approach.
If you really want to use the linker for this purpose you can always do that externally, without coupling these components in the normal wolfboot building process.
Do you see other strong reasons to not use concatenate the files directly with binassembly?

Besides that, please note that if you want to file a PR it shouldn't alter other targets and it should include tests.

Thanks
Marco

Go to forum: wolfBoot