Hi Craig,

Can you tell us a bit about your project and what you are working on? wolfSSL does not support the Heartbeat extension in either protocol (TLS nor DTLS). Can you tell us why you would need the extension and if you would like us to add it to our internal feature request list?

Feature requests are worked on when we have free engineering cycles and have no definitive timeline but can always be accelerated through customer backing if there is a high need and short timeline.

Looking forward to hearing more about your project.

Warm Regards,

K

Hi @zhq0918,

If the seg fault is not due to misconfiguration the next thing to check is dereferencing a NULL variable in any way IE let's say a malloc failed and a variable wasn't checked against NULL after the malloc but application code later uses the variable which was never allocated.

If that proves not to be the case check for variable use after a free IE a variable was malloced, used, freed, used again (after the free).

A third thing to check is reading out of bounds IE is there any application code that accesses or modifies memory outside of a variable (buffer overflow/underflow).

Last thing to check is your stack and heap inside the enclave. If the stack and heap are colliding one could be over-writing the other causing corruptions in either stack or heap which can result in a segmentation fault.

Regards,

K

zhq0918,

close is a file system api. Similar to printf or scanf those are system level api's that the enclave knows nothing about. You will need to adjust the library includes in the makefile to compensate. libraries are pulled in with the -l<libname> specifier. I highly recommend reading some of the intel forums on these questions as many have been asked and answered there.

The Intel documentation is also very helpful: https://software.intel.com/en-us/downlo … oper-guide

[EDIT 23 May 2019, see https://github.com/wolfSSL/wolfssl-examples/issues/152]

For calls to things like close and open you will need to write untrusted out calls to the system for the enclave to be able to utilize IE:

Step 1: Checkout https://github.com/wolfSSL/wolfssl-exam … _Enclave.c and see how we made functions for printf, recv, send, current_time, .... etc. The enclave can't even call "printf" because it doesn't have access to the system. It doesn't know what the stdout stream is so we have to give the enclave access to those system level functions via untrusted out calls. Write a close function in https://github.com/wolfSSL/wolfssl-exam … _Enclave.c and have it call ocall_close passing along the item to be closed.

Step 2: Prototype ocall_close so the enclave can call out to the untrusted execution space. Prototype this ocall in https://github.com/wolfSSL/wolfssl-exam … nclave.edl in the untrusted { } section.

Step 3: Write the ocall_close in the untrusted application https://github.com/wolfSSL/wolfssl-exam … ted/App.c. Have it call the system function "close" on the item to be closed.

Warm Regards,

K

@zhq0918,

Are you working on Linux or Windows?

You will need to set either OPENSSL_EXTRA or OPENSSL_ALL in your settings. If working on Linux you would do this in the sgx makefile wolfssl/IDE/LINUX-SGX/sgx_t_static.mk

Look for the line: Wolfssl_C_Extra_Flags := -DWOLFSSL_SGX and add this below that line to gain access to the X509 API's:

Wolfssl_C_Extra_Flags := -DWOLFSSL_SGX
Wolfssl_C_Extra_Flags += -DOPENSSL_EXTRA

If working on windows add in the custom user_settings.h for SGX.

Regards,

K

Hi @move,

You noted you can sniff the server hello, can you capture a wireshark trace of the connection from either the client or server side? If so you should be able to expand the Wireshark packet to see which max fragment length is negotiated.

Warm Regards,

K

Hi @kamaln16,

Yes absolutely. The developer that worked on the project chose to use the setting NO_TLS in wolfssl/IDE/MDK-ARM/MDK-ARM/wolfSSL/config-BARE-METAL.h but you can comment that setting out. It's likely the choice to use that setting was due to resource constraints on the target environment or the effort only involved making sure the crypto worked but TLS was not tested. That being said we have run TLS on many bare-metal targets to-date and there are no limitations beyond I/O and resources.

When I say I/O I mean you will need either a TCP/IP stack or some other transport medium (wolfSSL doesn't care about how it is transported, you can register custom I/O callbacks to send and receive data in any fashion, we have done TLS handshakes using Bluetooth, UART/Serial, in memory, etc.

I don't have a bare-metal example of SMTP but we do have a portable example in wolfssl-4.0.0/examples/client/client.c, just look for the function StartTLS_Init and where it is called. Basically that function just does the starttls setup commands to the endpoint and then you do a wolfSSL_connect once the init stage is done.

Warm Regards,

K

@programervn,

The use case you've just inquired about is quite complex with DTLS. Remember with UDP Datagrams all arrive on the same port on the server side unlike TLS which uses a tuple to guide traffic to a unique destination port on the server. Because of this the only way to handle many clients in parallel is do the following setup:

1) Configure the underlying I/O to be nonblocking (nonblocking sockets)
2) Implement a database or table for storing SSL object references
3) Peek at the header information in arriving datagrams and get the IP/port number of the client (will be unique based on IP/port combination). Parse your table/database, if no SSL object exists for the IP/port combination then create a new SSL object and register an entry in your table/database associating the IP/port with the ssl object reference.
4) For any IP/port combination registered with an SSL object in the lookup table/database return that SSL object for handling that datagram.
5) Make sure to clear out entries when the connection terminates.

The complexity of this setup is significant, if you have any issues and need assistance we do provide consulting services to assist with complex setups of this nature. If you need further assistance or are interested in our engineering services shoot an email to support@wolfssl.com for more help.

Warmest Regards,

K

@I_AM_MAD,

Thanks so much for the update. Let us know if you ever have any other questions, we are always happy to help in any way we can.

Regards,

KH

Hi @I_AM_MAD,

I can confirm that I have built for many embedded systems and can nearly always achieve builds in the 80 - 120K range with the same basic setup:

RSA enabled, ECC enabled, AES or 3DES, SHA256 and maybe SHA512/384 + TLS functionality. This setup will typically give me a few PFS cipher suite options. If I need additional features the library can grow a few K here or there. What I often find very interesting is the compiler differences. For example one project I was working on I had the exact same settings and source files and I built with two different compilers. The first, an ARM THUMB compiler, output a binary test application that was 80k. With the second toolchain/compiler (granted, main.c was a bit different due to different devices being targeted), I saw a 240K binary executable output. This wasn't because of anything with the library, rather it was that we just didn't have the compiler tuned right to optimize. Without changing anything in the wolfSSL library or wolfSSL settings I was able to tune the compiler rules a bit and quickly get the 240K build down to 160K. Obviously this was still double the size of what the other compiler was capable of but goes to show just how much the toolchain itself can effect the resulting binary output size.

Can you tell us what compiler you are working with and if it is setup for optimization? Can you tell us also if you are just looking at the library itself or are you looking at the executable binary size? (Executable binary is much different than a library object as the library object does not get optimized until it is linked into an executable binary).

Like Eric mentioned if you would like to discuss in more detail feel free to reach out to support@wolfssl.com.

Warm Regards,

K

Hi m0ot,

-150 = ASN_BEFORE_DATE_E meaning the certificate is issued for some date in the future. Since this is unlikely true if you look at the date range and a current clock you might check that the clock on the device is set correctly. For example if your devices internal clock is set to the year 1995 and the certificate was issued for some date in 2019 - some date in 2029 then you would see the ASN_BEFORE_DATE_E.

-162 = ASN_NO_PEM_HEADER which means you passed WOLFSSL_FILETYPE_PEM instead of WOLFSSL_FILETYPE_ASN1 for a DER formatted certificate OR the PEM certificate was missing the PEM header.

Warm Regards,

K

Thank you so much, I reached out to our document maintainer and found that the documentation has not yet been updated with the TLS1.3 API's though we do expect that to happen in the near future. Since there are not yet sections for wolfTLSv1_3_server method (and client method) we do not expect to have the v23 methods updated yet either. I have summarized your report to the document maintainer and he has noted that when the TLS1.3 update happens we also need to indicate that the v23 client and server methods support SSL 3.0 - TLS 1.3 as well.

If there is anything else we can assist with at this time let us know but be assured you can use the downgrade API's (v23 methods) and still have TLS 1.3 support with them even though the documentation is not yet updated to reflect this.

Warmest Regards,

K

Hi m0ot,

Thanks for reaching out to wolfSSL via the forums. Have you found the wolfSSL Python wrapper yet? If you use the documentation here it will help get you started with testing:

https://wolfssl.github.io/wolfssl-py/

Next you could remove the default wolfssl that comes from pip with a local copy configured for TLS1.3 support:

# Download wolfssl-4.0.0.zip from https://wolfssl.com and extract it
cd wolfssl-4.0.0
./configure --enable-all
make
<sudo> make install

Then use the api wolfSSLv23_[ client | server ]_method which is already wrapped in the python wrapper and it will use TLS1.3 by default with the option to downgrade (v23 methods support downgrading) if the peer you connect with doesn't have TLS 1.3 support.

We have not yet extended the python wrapper to include the TLS 1.3 only API's but as noted above you can access TLS 1.3 support through the downgrade option which is wrapped.

Please let us know if you have any other questions as you get started and if you need better response times please do not hesitate to reach out to us through support@wolfssl.com or via the zendesk portal at https://wolfssl.zendesk.com

Thanks for considering wolfSSL for use in your project. Can you tell us a bit more about what it is you are working on?

Warm Regards,

K