351

(3 replies, posted in wolfSSL)

Osiris,

I can confirm that the call to wolfSSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, 0); is the correct solution for turning on mutual auth. The call to wolfSSL_CTX_load_verify_locations is what you use to load certs with which to authenticate but does not enable mutual auth by invocation.

See section "4.8 CLIENT AUTHENTICATION" of our manual here for more info: https://www.wolfssl.com/docs/wolfssl-manual/ch4/


What is the behavior if wolfSSL_CTX_set_verify fails? Does it disconnect automatically?

The connection will not proceed and whichever side failed to authenticate will send either a reset (RST) or close notify alert.

Is wolfSSL_CTX_set_verify required on the client side for mutual authentication? (My guess is no, since it is done automatically with the one way)

No it is not required on the client side.

5)How can I use the VerifyCallback function from the wolfSSL_CTX_set_verify to see if it succeeds or fails?

// just reports the error and returns 
static int myVerifyCheck(int preverify, WOLFSSL_X509_STORE_CTX* store)
{
    (void) preverify; // unused
    printf("In verification callback, error = %d, %s\n", store->error, wolfSSL_ERR_error_string(store->error, buffer));
    return WOLFSSL_SUCCESS; // or whatever you wish to return if error is valid
}

...

// then in your application call

wolfSSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, myVerifyCheck);

6) Is there a way to output/log where the TLS handshake might fail, for example if the client trying to connect has an unknown cert? Can the VerifyCallback be possibly used for that?

Yes you can use the verify callback for that or you can turn on wolfSSL debug messages by defining DEBUG_WOLFSSL in your settings and then calling wolfSSL_Debugging_ON(); in your application.

7) How can I verify that mutual TLS authentication took place? (I think that might be taken care of by wolfSSL_CTX_set_verify if it works the way I think I does)

Again see section 4.8 of our manual, that section details how to tell the server to fail if client does not present cert for mutual auth.

Warm Regards,

Kaleb

352

(3 replies, posted in wolfCrypt)

Leroyk2,

Could you tell us a little about what you are working on and the end-goals of the project?

The output of pub is an unsigned char array iE the raw hex.
You could convert that to Big Number format with the function wolfSSL_BN_hex2bn

Warm Regards,

Kaleb

Hi kjjy7,

You would use the function:

wc_ecc_shared_secret
Parameter 1: your static private key
Parameter 2: Public key from the end entity used to generate the shared secret when combined with your private key
Parameter 3: an output buffer to store the shared secret
Parameter 4: the size of the output buffer when passed in, gets updated by calling function to indicate size of shared secret.

Example:

unsigned char* sharedOutBuf[512]; // size assumes a 256-bit curve field, adjust if using large curve field to (curve_fieldSz*2)
word32 sOutBSz = 512;


ret = wc_ecc_shared_secret(&userA_priv, &userB_pub, sharedOutBuf, &sOutBSz);

Regards,

Kaleb

Martin,

So sorry for the delay. Your colleague has been in touch with Rod Weaver and we are tracking these items now in our support domain which will guarantee faster response times!

I'll be reviewing the examples you sent over today. I have also added you to the zendesk ticket where these issues are being tracked.

Reagards,

Kaleb

Martin,

So sorry for the delay. Your colleague has been in touch with Rod Weaver and we are tracking these items now in our support domain which will guarantee faster response times!

I'll be reviewing the examples you sent over today.

Warm Regards,

Kaleb

Hi SamSam,

Thank you for using the wolfSSL forums!

2. default method wolfTLSv1_2_client_method_ex with wolfSSL_CTX_UseSupportedCurve call
examples/client/.libs/client -S HOST_NAME e -h HOST_NAME  -p 443 -d -x -C -g -i -t
client use wolfTLSv1_2_client_method_ex method and in the "Client Hello" message wolfSSL send information about following extensions:
- signature_algorithms
- elliptic_curves
- SessionTicket TLS
- server_name
- Unknown 23
Information about ec_point_formats is missed.
result: SSL handshake failed with error wolfSSL_connect error -313, revcd alert fatal error

Unless you modified the client manually this is not using TLS 1.3. This is TLS 1.2. Use argument "-v 4" to set TLS 1.3.
The -t option does NOT need ec_point format, instead this sends the "key_share" extension indicating a desire to use x25519 for key exchange.


3. method wolfSSLv23_client_method_ex
examples/client/.libs/client -S HOST_NAME  -h HOST_NAME  -p 443 -d -x -C -g -i -v d
client use wolfSSLv23_client_method_ex method and in the "Client Hello" message wolfSSL send information about following extensions:
- Unknown 43
- signature_algorithms
- elliptic_curves
- Unknown 51
- SessionTicket TLS
- server_name
Information about ec_point_formats is missed.
result: SSL handshake failed with error wolfSSL_connect error -313, revcd alert fatal error
Summary:
The wolfSSL does not send information about elliptic_curves extension when:
- method wolfSSLv23_client_method_ex
or
- wolfSSL_CTX_UseSupportedCurve was call

I'll look into this one and get back to you on what I find!

Warm Regards,

Kaleb

Hi kjjy7,

We provide an example for a psk client callback function in <wolfssl-root>/wolfssl/test.h

1115 static WC_INLINE unsigned int my_psk_client_cb(WOLFSSL* ssl, const char* hint,   
1116         char* identity, unsigned int id_max_len, unsigned char* key,             
1117         unsigned int key_max_len)                                                
1118 {                                                                                
1119     (void)ssl;                                                                   
1120     (void)hint;                                                                  
1121     (void)key_max_len;                                                           
1122                                                                                  
1123     /* see internal.h MAX_PSK_ID_LEN for PSK identity limit */                   
1124     strncpy(identity, kIdentityStr, id_max_len);                                 
1125                                                                                  
1126     if (wolfSSL_GetVersion(ssl) < WOLFSSL_TLSV1_3) {                             
1127         /* test key in hex is 0x1a2b3c4d , in decimal 439,041,101 , we're using  
1128            unsigned binary */                                                    
1129         key[0] = 0x1a;                                                           
1130         key[1] = 0x2b;                                                           
1131         key[2] = 0x3c;                                                           
1132         key[3] = 0x4d;                                                           
1133                                                                                  
1134                                                                                  
1135         return 4;   /* length of key in octets or 0 for error */                 
1136     }                                                                            
1137     else {                                                                       
1138         int i;                                                                   
1139         int b = 0x01;                                                            
1140                                                                                  
1141         for (i = 0; i < 32; i++, b += 0x22) {                                    
1142             if (b >= 0x100)                                                      
1143                 b = 0x01;                                                        
1144             key[i] = b;                                                          
1145         }                                                                        
1146                                                                                  
1147         return 32;   /* length of key in octets or 0 for error */                
1148     }                                                                            
1149 }

You would then register your callback with:

wolfSSL_CTX_set_psk_client_callback(ctx, my_psk_client_cb);

Warm Regards,

Kaleb

358

(3 replies, posted in General Inquiries)

kjjy7,

The method to use these functions would be to call the higher level API wolfSSL_connect or wolfSSL_write. We still do not know the exact reason you need to invoke the internal API's which are purposely not exposed for security reasons. Can you please share what it is you are working on that would require direct calls into the low-level internals?

Feel free to send this info to support@wolfssl.com if you are working on a proprietary solution that you prefer to not discuss on a public forum.

- Kaleb

359

(1 replies, posted in General Inquiries)

Hi kjjy7,

1. Please use the quick start guide for familiarization with configure options found here: https://www.wolfssl.com/docs/quickstart/

2. You can set in configure options with CFLAGS="-DOPTION1 -DOPTION2" etc or define in wolfssl-root/wolfssl/wolfcrypt/settings.h

3. All of our examples are written in C which can be compiled by a c++ compiler: https://github.com/wolfSSL/wolfssl-examples


Let me know if you have any other questions.

Warm Regards,

Kaleb

360

(3 replies, posted in General Inquiries)

kjjy7,

Can you tell us what it is you are working on and why you wish to invoke these API's directly rather than using wolfSSL_connect or wolfSSL_write to indirectly invoke those API's?


Warm Regards,

Kaleb

Hi kjjy7,

WOLFSSL_LOCAL is an opaque API for use by wolfSSL internals only. This means external applications linking to the library will not be able to see or invoke that API.

WOLFSSL_API means the function is available for public use by external applications.

Can you tell me what it is you are working on and why you would want to use SendClientHello directly rather than calling wolfSSL_connect?

Warm Regards,

Kaleb

MartinH,

Can you tell us a little about what it is you are working on with session resumption?

Thank you for reporting this behavior to us. Is it possible for you to send us a test application (client to resume the session) and the steps with the openssl command line utility that you use to reproduce this for testing and implementing a fix? (If possible can the openssl commands be scripted in a post shell script?)

Thanks!

Kaleb

Hi MartinH,

Can you tell us what it is you are working on?

We had made a fix last year to stop sending the session ID when session tickets were in use (change here: https://github.com/wolfSSL/wolfssl/pull/851/files) I am curious if this change is what is effecting your current use-case.

To clarify it sounds like you are trying to get the following flow of events working, please correct me if I am misunderstanding.

1) Connect to peer
2) Save session
3) Hangup
4) Load session
5) Resume session
6) Save session again
7) Hang up again
8) Load session again
9) Resume session again

Where things are going wrong for you are step 6 "Save session again" fails. Is my understanding correct?

Warm Regards,

Kaleb

Hi kjjy7,

Please check the state by defining DEBUG_WOLFSSL or configuring with --enable-debug then call

wolfSSL_Debugging_ON(); 

in your application!

Warm Regards,

- Kaleb

Hi kaolsen,

Thank you so much for contacting wolfSSL and for your questions. wolfSSL does support ECDSA and sha256.

Warm Regards,

Kaleb

366

(1 replies, posted in wolfSSL)

Hi kaolsen,

Thank you for contacting wolfSSL and for your questions!

If version 4 existed we would support it. Version 4 does not yet exist!


Warm Regards,

Kaleb

367

(3 replies, posted in wolfCrypt)

Hi Leroyk2,

Thanks for contacting wolfSSL with your questions! Could you tell us a little about what you are working on and the end-goals of the project?

We do interoperability testing with OpenSSL on a nightly basis so the short answer is yes we are confident the two can perform a TLS connection using a DH key exchange mechanism.

It appears though your work may be a little lower level, just using the crypto parts of the two libraries and not necessarily the SSL/TLS level is that correct?

Warm Regards,

Kaleb

368

(1 replies, posted in wolfCrypt)

Hi natinusala,

Thank you for contacting wolfSSL about this issue. Could you tell us a little about the work you are doing with PKCS12 objects?

Currently wolfSSL does not have an API to wrap the PKCS12 object with ASN1 formatting as we only work with the bundles internally  and do not have a need to output to a file. If this is something you would like to see added as a feature request let me know and I'll put it on our feature request list.

Thanks!

Kaleb

Hi Guassabina,

MD5 was first added to wolfSSL in 2011 and release 3.9 went out in 2016 so yes the file <wolfssl-root>/wolfcrypt/src/md5.c should exist in that version!

Warm Regards,

- Kaleb

Hi Guassabina,

MD5 was first added to wolfSSL in 2011 and release 3.9 went out in 2016 so yes the file <wolfssl-root>/wolfcrypt/src/md5.c should exist in that version!

Warm Regards,

- Kaleb

Hi Elyhance,

Apologies for the delay in getting back to you!

The error: KeyUse Digital Sig not set”(-383) means the cert being used is being used improperly. IE the Key Usage Extension is set but the cert is NOT allowed to be used as a signing authority. Could you try using a cert that is properly configured for use in validating an entity and let us know your results?

Warm Regards,

Kaleb

Hi gussabina,

Thanks for using the wolfSSL forums!

The weakness in MD5 is due to lack of collision resistance not pre-image based attacks and the speed of the algorithm (it's fast). This makes it extremely easy to generate and compare millions of hashes quickly so if you're using MD5 to hash a password it's generally bad. If however you are hashing a FILE (such as firmware) it would be computationally impractical for a malicious user to try and reproduce your firmware bit-for-bit and try to match the hash. Furthermore he would have to control your file to reproduce the hash, if he did not influence it's creation the collision attack would not work.

That being said the community does tend to encourage users to migrate away from MD5, currently preferring SHA256, SHA3, or SHA512 (or one of the truncated versions of those). Ultimately the choice is yours.


Warm Regards,

Kaleb

Hi Pilatuz,

That is an excellent question! Thank you for using the wolfSSL forums to seek an answer.

Unfortunately everyone does not follow the spec appropriately and sometimes exceptions have to be made for the rule-breakers.

You'll note in RFC 5246 https://tools.ietf.org/html/rfc5246 that server is SUPPOSED to send it's entire chain with the only exception being the root CA. It sounds like you have found a server that does not abide by the rules and leaves out another part of the chain too. (Excerpt below from the RFC):

7.4.2.  Server Certificate

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

Please let us know if you have any other questions!

- Kaleb

Hi Gussabina,

Once the connection fails you should tear down the connection. wolfSSL provides some cleanup routines for the SSL objects. After the SSL object is released you can then create a new SSL object using the WOLFSSL_CTX factory you initially setup. This should clear up any issues with leakage.

Warm Regards,

Kaleb

375

(5 replies, posted in wolfCrypt)

Hi jpa,

Thanks for the update!

- Kaleb