Update:

We have run the following test from the wolfssl-3.15.5/IDE/XCODE directory to show watchOS successfully builds:

#!/bin/sh

WORKSPACE=$(eval "pwd")
PROJ=wolfssl.xcodeproj
CONFIG=Release
SCHEME=wolfssl_ios
ARCH=i386
SDK=watchsimulator5.1
CONF_BUILD_DIR=${WORKSPACE}/simulator

xcodebuild clean build -project ${PROJ} -configuration ${CONFIG} \
           -scheme ${SCHEME} -arch ${ARCH} -sdk ${SDK} \
           BITCODE_GENERATION_MODE=bitcode \
           OTHER_CFLAGS="-fembed-bitcode -O3 -fomit-frame-pointer" \
           CONFIGURATION_BUILD_DIR=${CONF_BUILD_DIR}  \
           -quiet

- K

Hi @manitou,

Could you try commenting out the define for TIME_OVERRIDES in wolfssl/wolfcrypt/settings.h under the WOLFSSL_ARDUINO section and let me know if that resolves the redefinition issue?

Warm Regards,

- K

rrsuj,

Understood, makes sense!

The reason it's easy to build a single algorithm with a subset of files is because the algorithms are largely compartmentalized with few external dependencies. As soon as you start using the SSL/TLS layer though you quickly find that there are a large number of inter-dependent parts and it's no longer easy to just pull out files here and there, it can still be done but is a much more involved effort so we provide the pre-processor macros to alleviate this effort.
I have an idea, I will walk through the process I use for determining which settings I need for a custom configuration if only concerned about available ciphers! Let's cover one of the cipher suites you noted: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Step 1
If I want a build to target that cipher only I start by configuring wolfSSL to see what is enabled

./configure && make
./examples/client/client -e
DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305-OLD:ECDHE-ECDSA-CHACHA20-POLY1305-OLD:DHE-RSA-CHACHA20-POLY1305-OLD

Running the example client with the -e option lists all available cipher suites. OK we see a bunch we don't need like CHACHA, POLY, AES128-GCM and others so let's start to narrow it down. If we open wolfssl/src/internal.c we'll find the cipher suites. Let's try to eliminate all chacha poly suites to start. So run a "search" in wolfssl/internal.c for "ECDHE-ECDSA-CHACHA20-POLY1305" and you'll see it guarded by the pre-processor macro BUILD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256. That macro is set in wolfssl/wofssl/internal.h so let's see which defines control it:

 761 #if defined(HAVE_CHACHA) && defined(HAVE_POLY1305) && !defined(NO_SHA256)        
 762     #if defined(HAVE_ECC) || defined(HAVE_CURVE25519)                            
 763         #if defined(HAVE_ECC) || (defined(HAVE_CURVE25519) && \                  
 764                                                           defined(HAVE_ED25519)) 
 765             #define BUILD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256   <--- Target we want to eliminate       
 766         #endif                                                                   
 767         #ifndef NO_RSA                                                           
 768             #define BUILD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256            
 769         #endif                                                                   
 770     #endif                                                                       
 771     #if !defined(NO_DH) && !defined(NO_RSA)                                      
 772         #define BUILD_TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256                  
 773     #endif                                                                       
 774 #endif 

We don't want to disable SHA256 with NO_SHA256 because wolfSSL uses a HASH DRBG for a random bit generator that relies on SHA256 so disabling that while using RSA and ECC is not an option.
So our other options are remove chacha or  remove poly or remove both ecc and ed25519. We don't want to remove ed25519 and ecc because we need ecc. So let's remove chacha and poly.

./configure --disable-chacha --disable-poly1305 && make
./examples/client/client -e
DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384

OK so we still see gcm, then let's remove with --disable-aesgcm

./configure --disable-chacha --disable-poly1305 --disable-aesgcm && make
./examples/client/client -e
DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384

Looking a little better so now let's remove the DHE cipher suites:

./configure --disable-chacha --disable-poly1305 --disable-aesgcm --disable-dh && make
./examples/client/client -e
ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384

OK now we just have ECDSA and RSA cipher suites left! You didn't want SHA1 cipher suites in this one so let's get rid of those:

./configure --disable-chacha --disable-poly1305 --disable-aesgcm --disable-dh --disable-sha && make
./examples/client/client -e
ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384

That looks pretty close to what you were after, you have SHA384 still enabled and we can't turn off SHA256 because of the HASH DRBG dependency. Now that we have our target build achieved let's say we want to determine the required source files for our embedded system. Check the sizes of the .o object files in wolfssl/wolfcrypt/src/.libs and wolfssl/src/.libs directories.

ls wolfcrypt/src/.libs/
total 776
drwxr-xr-x   23 kalebhimes  staff   736B Dec 11 15:11 .
drwxr-xr-x  134 kalebhimes  staff   4.2K Dec 11 15:11 ..
-rw-r--r--    1 kalebhimes  staff    15K Dec 11 15:11 src_libwolfssl_la-aes.o
-rw-r--r--    1 kalebhimes  staff    66K Dec 11 15:11 src_libwolfssl_la-asn.o
-rw-r--r--    1 kalebhimes  staff   5.1K Dec 11 15:11 src_libwolfssl_la-coding.o
-rw-r--r--    1 kalebhimes  staff   1.6K Dec 11 15:11 src_libwolfssl_la-cpuid.o
-rw-r--r--    1 kalebhimes  staff    47K Dec 11 15:11 src_libwolfssl_la-ecc.o
-rw-r--r--    1 kalebhimes  staff   8.7K Dec 11 15:11 src_libwolfssl_la-error.o
-rw-r--r--    1 kalebhimes  staff   5.4K Dec 11 15:11 src_libwolfssl_la-hash.o
-rw-r--r--    1 kalebhimes  staff   7.3K Dec 11 15:11 src_libwolfssl_la-hmac.o
-rw-r--r--    1 kalebhimes  staff   668B Dec 11 15:11 src_libwolfssl_la-logging.o
-rw-r--r--    1 kalebhimes  staff   3.9K Dec 11 15:11 src_libwolfssl_la-md5.o
-rw-r--r--    1 kalebhimes  staff   1.2K Dec 11 15:11 src_libwolfssl_la-memory.o
-rw-r--r--    1 kalebhimes  staff    12K Dec 11 15:11 src_libwolfssl_la-random.o
-rw-r--r--    1 kalebhimes  staff    15K Dec 11 15:11 src_libwolfssl_la-rsa.o
-rw-r--r--    1 kalebhimes  staff   6.6K Dec 11 15:11 src_libwolfssl_la-sha256.o
-rw-r--r--    1 kalebhimes  staff    12K Dec 11 15:11 src_libwolfssl_la-sha3.o
-rw-r--r--    1 kalebhimes  staff    12K Dec 11 15:11 src_libwolfssl_la-sha512.o
-rw-r--r--    1 kalebhimes  staff   3.5K Dec 11 15:11 src_libwolfssl_la-signature.o
-rw-r--r--    1 kalebhimes  staff    58K Dec 11 15:11 src_libwolfssl_la-tfm.o
-rw-r--r--    1 kalebhimes  staff   1.5K Dec 11 15:11 src_libwolfssl_la-wc_encrypt.o
-rw-r--r--    1 kalebhimes  staff   4.1K Dec 11 15:11 src_libwolfssl_la-wc_port.o
-rw-r--r--    1 kalebhimes  staff   1.9K Dec 11 15:11 src_libwolfssl_la-wolfmath.o

That's your crypto file subset (do the same for wolfssl/src/.libs to get the ssl/tls subset). Then use all the options that were configured and set in wolfssl/options.h by running ./configure (options.h is autogenerated on desktop systems that support autoconf) and use those on your embedded build to eliminate the unwanted features (note you'll need to remove system level settings from options.h such as HAVE___UINT128_T and WOLFSSL_X86_64_BUILD and _POSIX_THREADS (unless you have pthreads on your embedded device which is uncommon).

To further optimize the build look at the largest .o object files above and see what options are available for tuning!

Cheers,

K

Hey SamSam,

I found what is happening, the server is returning a nonce size of 8 post-handshake and wolfSSL has a limit of 4 set. I have reached out to our TLS 1.3 engineer for input on your report. Please expect an update from Sean soon.

- K

Hi rrsuj,

Can you tell us a bit about what it is you are working on and end goals for the project?

wolfSSL can be used in the fashion described (only building subsets of the library) however for such a build would take some time to put together a finite list. We can do that via our consulting if you like!

Otherwise we would recommend to just pull in all source files and control which features are compiled via the pre-processor macros. Chapter 2 of the wolfSSL manual https://www.wolfssl.com/docs/wolfssl-manual/ch2/ discusses "Removing Features" in section 2.4.1!

Warm Regards,

K

Hi SamSam,

I just reviewed dev.ssllabs.com domain, they do not support TLS v1.3 so this is an expected result. Interestingly I can even scan their own website with their own tool to show this:

https://www.ssllabs.com/ssltest/analyze … 130.202.77

Configuration

Protocols
TLS 1.3    No
TLS 1.2    Yes
TLS 1.1    Yes
TLS 1.0    Yes
SSL 3    No
SSL 2    No
For TLS 1.3 tests, we only support RFC 8446.

So they have added support to their tool for detecting TLS1.3 but their servers do not yet support TLS1.3 connections!

This is a valid and successful TLS 1.3 connection! You have sent a "HTTP GET request" with the -g option which the server processes AFTER the connection has already succeeded and it is the get request that the server doesn't like. If you visit that domain in a browser all you will see is the message "Sorry, the parameters you provided were not valid". So whatever service is running at that domain wants something specific, maybe a custom protocol, maybe a user-name and password, not sure but as for as the TLS goes it worked splendidly! (See attached wireshark). What is interesting in the wireshark is that i0.wp.com shows up as IP 192.0.77.2 which shouldn't be a DNS resolvable domain. Not sure what's there but it may not be a safe service to use for testing.

Cheers,

K

@ans,

Very minimal impact, even in https the client hello message is still going to be plain text (unencrypted) as are the first flights of any TLS handshake while the protocol is being negotiated between the two parties.

You would just store the contents of the incoming TCP data, check the content type of the packet by processing only the first 5 bytes of the TLS part of the packet (You'll have to figure out how to skip the TCP information preceding the TLS part). You can determine if the packet contains a Handshake message by checking if the first byte is integer value 22 or hex value 16 (See attached image from wireshark capture). If it's a handshake message then skip ahead to the 6th byte and check if it is integer value 1 or hex value 0x01. If so then it's a Client Hello message!. If it is a client hello then get the length from bytes 4 and 5 (base_16) and convert to integer value (143 in the screen shot) now copy everything (including the first five bytes) into a buffer. Now you have a buffer containing the Client Hello + TLS record header (the first five bytes) and can pass it to the API wolfSSL_SNI_GetFromBuffer!

This would add very little overhead to your application and isn't a hack at all. This is the same way HA Proxy does it. HA Proxy uses a function to "peek" at the incoming TLS record header to see if it is a client hello or not and ignores it if it isn't. If it is then it grabs the SNI and forwards the traffic to the correct server.

I can certainly add this as a feature request to our tracker. Feature requests are customizations a customer would like to see added but without funding to back the effort they only are worked on when we have spare time between other paid projects. Feature requests can always be accelerated if a customer has a high need and decides to fund the effort!

Warm Regards,

K

Hi @roytam,

wolfSSL has ported and maintains a version of stunnel 5.4 where we integrated support for wolfSSL. We have tried getting those changes merged but so far Stunnel has not accepted them. Could you tell us what it is you are working on and the end goals for your project?

Could you also send an email to rod@wolfssl.com and let him know you are interested in evaluating our wolfSSL ported version of Stunnel?

Warm Regards,

K

@jb3,

If it is not in your distribution it is accessible at this link: https://github.com/wolfSSL/wolfssl/blob … ewcerts.sh

- K

Hi Kirill-782,

Can you tell us about your project and what the end goals are?

This error has to do with verifying the peer. When the correct root CA is not loaded with wolfSSL_CTX_load_verify_locations then this error will be the result of peer verification. This error means there is no signer in the current wolfSSL cert store capable of validating the certificate chain that was received from the peer during the handshake.

This error means that the certificate return by the peer was NOT a certificate issued for that domain for example let's say you tried connecting to google.com but someone was sitting in-between you and the server and had a cert issued for "goggle.com" to try and trick you. goggle.com is not google.com so this error would be thrown.

Could you check that you are loading the correct certs for validating the peers you are testing against in all cases?

Regards,

K

Hi @ans,

Thanks for contacting wolfSSL with your questions. Can you tell us what it is you are working on that requires extracting the SNI from the client hello buffer manually? We are curious!

Anyway there is no pointer to a structure or anything like that, you would need to actually modify the IO Recv (EmbedRecv) functionality to store the raw bytes out to some location for later processing or process them in place in the receive callback.

What's the use case here? Could you explain more exactly what it is you're trying to do?

Warm Regards,

K