Hi Jim,

Yes it is very possible to run wolfSSL over the TCP layer. We provide a custom IO callback solution that allows users to plug in any send/receive functionality that is available. wolfSSL is completely agnostic to the transport layer meaning if it can read and write data you can do a TLS handshake and securely pass messages through that medium, file system, in memory buffer, over bluetooth, USB serial, traditional TCP/IP, doesn't matter.

We have several reference implementations in wolfssl-root/src/wolfio.c that you can use as a model and we have an example here: https://github.com/wolfSSL/wolfssl-exam … -callbacks that shows doing a secure connection between two apps on the same system using files as the transport layer. Hopefully those references help show how agnostic we are to the transport layer and give you confidence that you can achieve a working solution with wolfSSL using your AT send/receive commands and built in TCP stack.

Let us know if you have any other questions.

Warm Regards,

KH

Tammy,

Can you tell me what other settings you are using?

$ ./configure --enable-pkcs12 --enable-cryptonly CFLAGS=-DNO_HMAC
$ make
$ ./wolfcrypt/test/testwolfcrypt
------------------------------------------------------------------------------
 wolfSSL version 4.0.0
------------------------------------------------------------------------------
error    test passed!
MEMORY   test passed!
base64   test passed!
asn      test passed!
MD5      test passed!
SHA      test passed!
SHA-224  test passed!
SHA-256  test passed!
SHA-384  test passed!
SHA-512  test passed!
SHA-3    test passed!
Hash     test passed!
GMAC     test passed!
Chacha   test passed!
POLY1305 test passed!
ChaCha20-Poly1305 AEAD test passed!
AES      test passed!
AES192   test passed!
AES256   test passed!
AES-GCM  test passed!
RANDOM   test passed!
RSA      test passed!
DH       test passed!
ECC      test passed!
logging  test passed!
mutex    test passed!
memcb    test passed!
Test complete

**NOTE: The version says version 4.0.0 but this was tested from the github master branch at https://github.com/wolfssl/wolfssl.git, if you are working with a download from the website or specific version please let me know which one and I can test it as well.

Warm Regards,

KH

Hi Oytis,

I see, unfortunately at this time we do not have a run time option. Can you provide a brief summary of your use case and why it would be beneficial to have a run time option? I would happy to add it to our list of internal feature requests and just need something to put in the notes for why it would be useful to have an optional run-time switch as opposed to just supported/not supported build time option.

Warmest Regards,

KH

Hi Oytis,

Just disable them and they won't be broadcast for example:

./configure --disable-rsapss --disable-sha512 --disable-sha384

(sha384 is truncated sha512 so should be disabled also).

Cheers,

KH

Hi Oytis,

Thank you for your request for "A concise PK with HSM callback example". We have noted it in our feature request list and will work on it when we have free engineering cycles. There is no associated timeline with feature requests we work on for free but if you ever decide you want the example work accelerated we do provide custom engineering services, just reach out to support@wolfssl.com and let us know what you need and when you need it by and we can put you in touch with our Business Department to get the details worked out and the feature expedited.

Warm Regards,

KH

Alfred,

As Jacob noted on the other post:

By default OpenSSL uses RC2, so you have to explicitly ask it to use des3 for encryption:

Again from Jacobs reply:

That should get you a start anyway but if not let me know!

Cheers,

KH

Hi Alfred,

You can use:

wolfSSL_CTX_use_PrivateKey_[file | buffer](); // to load the private key
wolfSSL_CTX_use_certificate_[file | buffer](); // to load the certificate
wolfSSL_CTX_check_private_key(); // checks that the private key matches the public key in the cert, returns WOLFSSL_SUCCESS or WOLFSSL_FAILURE

/* Check private against public in certificate for match                         
*                                                                               
* ctx  WOLFSSL_CTX structure to check private key in                            
*                                                                               
* Returns SSL_SUCCESS on good private key and SSL_FAILURE if miss matched. */
int wolfSSL_CTX_check_private_key(const WOLFSSL_CTX* ctx);

If you have any issues let me know and I'll put together a quick example.

Warm Regards,

KH

SaravananG,

Please use:

wolfSSL_CTX_EnableOCSPStapling()
wolfSSL_UseOCSPStapling()
wolfSSL_CTX_EnableOCSP()

Warm Regards,

KH

Hi @Alfred,

Here is a quick test I ran today ( I can't find another example and we don't have an API for it unfortunately):

         char myAltNames[] = {
                                 // SEQUENCE (2 elements)
                                 0x30, 0x14,
                                 // OBJECT IDENTIFIEER: 2.5.29.17 subjectAltName
                                 // (X.509 extension)
                                 0x06, 0x03, 0x55, 0x1D, 0x11,
                                 // OCTET STRING (1 element)
                                 0x04, 0x0D, //NOTE: 0x0D = length 13, this needs updated based on string length
                                 // SEQUENCE (1 element)
                                 0x30, 0x0B,
                                 // String, value: "DNS:localhost"
                                 0x82, 0x09, 0x6C, 0x6F, 0x63, 0x61, 0x6C, 0x68,
                                 0x6F, 0x73, 0x74
                             };                                                   
         XMEMCPY(myCert->altNames, myAltNames, XSTRLEN(myAltNames));              
         myCert->altNamesSz = (int) sizeof(myAltNames);                           
     } 

Update on 7 May 2020. An example was added here: https://github.com/wolfSSL/wolfssl-exam … e86f32R144

- KH

Hi @SaravananG,

Thank you for reaching out to wolfSSL via the forums. Can you tell us a bit about your project and organization to help us understand your use-case and needs?

Yes wolfSSL implements OCSP stapling on the client side. We provide an example of using it with our examples:

$ cd wolfssl/
$ ./configure --enable-ocspstapling
$ make
$ ./examples/client/client -C -h <domain/IP of server> -p <port number> -A <The CA cert to use> -g -W 1

Where -C forcefully disables CRL if it's enabled in favor of OSCP stapling, -g says to do a HTTP GET request and -W 1 says to use OCSP stapling v1 (use -W 2 for OCSP stapling version 2)

Regards,

KH

Gilo,

Before making that logical leap I would need to see a wireshark trace to review the packets coming back from the server. That was a very odd edge case that we were never able to figure out what that plain text message use was for nor why it was sent when only DHE cipher suites were used, we had never seen anything like it before or since and it was a custom proprietary server so I suspect they had some custom setup going on.

In fact in your case I would tend to lean tword a more recent case we had come through our Zendesk domain involving TLS 1.3 in wolfSSL trying to talk to Filezilla TLS 1.3 which actually turned out to be TLS 1.3 - draft 18 in Filezilla. wolfSSL kept appace with the TLS 1.3 as it progressed and we implemented:

draft-18, draft-22, draft-23, draft-26, draft-28 and finally the final draft: RFC-8446.

Draft 18 was the most common one implemented by us, google, openssl, and several other vendors at the time and then drafts 19 - RFC-8446 came in fairly rapid succession and most other vendors didn't implement them or did only one or two others.

When using RFC-8446 TLS 1.3 to talk to draft-18 TLS 1.3 we have seen the error you're reporting because the handshake progressed differently between the two drafts. Can you check if the TLS 1.3 implementation in your version of openssl is the final draft (RFC-8446) or if it is one of the other draft versions?

Warm Regards,

K