1 Reply by jacob.andersen

(6 replies, posted in wolfSSL)

Thanks Anthony, seems I had a problem on my side (duh). I got it to work fine with two separate context objects after some semi-related changes!

Go to forum: wolfSSL

2 Reply by jacob.andersen

(6 replies, posted in wolfSSL)

"Is there any reason both the server and client would need to share the same context and ssl structs?"

The device runs a custom RTOS (not Linux), and all TCP/IP communication is run in a single task. Like I said, my first approach was to create two separate WOLFSSL_CTX objects in the same task context and I experienced problems, but of course that could be my own fault. I'm just wondering if this is a correct way to do it, so that I don't run too far down a blind alley.

I don't see any example of doing this in the example code or documentation, which makes me nervous.

Go to forum: wolfSSL

3 Reply by jacob.andersen

(6 replies, posted in wolfSSL)

[Edit: Using wolfSSL 5.7.0]

I can add that I just tried using a single context created thus:

  WOLFSSL_METHOD *method = wolfTLSv1_3_method();
  if ((tcp_tlsCTX = wolfSSL_CTX_new(method)) == NULL)
[...]

Examining the contents of the tcp_tlsCTX object I can see that tcp_tlsCTX->method->side == 3 (either side) just before I do

  WOLFSSL *ssl = wolfSSL_new(tcp_tlsCTX);
  ret = wolfSSL_accept_TLSv13(ssl);

But wolfSSL_accept_TLSv13() does not seem to have this piece of code that wolfSSL_accept() does:

    #if defined(OPENSSL_EXTRA) || defined(WOLFSSL_EITHER_SIDE)
        if (ssl->options.side == WOLFSSL_NEITHER_END) {
            WOLFSSL_MSG("Setting WOLFSSL_SSL to be server side");
            ssl->error = InitSSL_Side(ssl, WOLFSSL_SERVER_END);
            if (ssl->error != WOLFSSL_SUCCESS) {
                WOLFSSL_ERROR(ssl->error);
                return WOLFSSL_FATAL_ERROR;
            }
            ssl->error = 0; /* expected to be zero here */
        }
    #endif /* OPENSSL_EXTRA || WOLFSSL_EITHER_SIDE */

Thus I promptly get an -344 wrong side error from wolfSSL_accept_TLSv13(). I cannot seem to find anything in the documentation about this, is it by design or a bug?

Go to forum: wolfSSL

4 Topic by jacob.andersen

(6 replies, posted in wolfSSL)

Hi, I have a use case where a device needs to simultaneously support both incoming and outgoing TCP connections, for different protocols, all encrypted by TLS. I.e., it needs to act as both a TLS server and client at the same time. I saw the discussion in https://www.wolfssl.com/forums/topic152 … ient.html, i.e use WOLFSSL_EITHER_SIDE and to create a generic context , but "the context role (client or server) is determined on the first connect" makes me believe that this is not sufficient for me.

I need to be able to set up a TLS server using accept() for a couple of protocols and handle incoming connections, and unrelated to this, act as a TLS client and initiate outgoing connect()s for another couple of protocols.

I have successfully implemented the client side, but now I'm not sure how to proceed. I have tried fooling around with creating both a server- and a client context for parallel use, but so far have not managed to make it work. The provided examples all seem to be either clients or servers only.

Is this use case supported by wolfSSL? If so you have any hints on how to make it work?

Go to forum: wolfSSL

5 Topic by jacob.andersen

(1 replies, posted in wolfSSL)

Hi,

I'm currently experimenting with integrating wolfSSL on an embedded device. The MCU has a smaller amount of SRAM built-in, and access to a much larger amount of SDRAM. Access to the external SDRAM is through an external bus which, aside from being twice as slow, is more vulnerable from a security standpoint.

I'm using the XMALLOC_OVERRIDE flag to use my own memory pool.

I will not be able to put all RAM allocated by wolfSSL into SRAM, but I could put things there selectively, based on the usage hint provided in XMALLOC. Is there a guideline or some hints for which types (e.g. DYNAMIC_TYPE_KEY) that are to be considered the most sensitive?

Additionally, is there a guideline for which memory types have the most performance impact in the above scenario, in a "typical" TLS (using either ECC or RSA) client scenario?

Go to forum: wolfSSL