You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by Kaleb J. Himes
Hi Nimesh,
To use DEBUG_WOLFSSL in the TI-RTOS project please locate the file C:\<path-to>\<wolf-root>\wolfssl\wolfcrypt\settings.h
Modify the section in settings.h that is wrapped in "#ifdef WOLFSSL_TIRTOS"
add the define
"#define DEBUG_WOLFSSL"
Regards,
Kaleb
Hi Teaspoon,
Thank you for contacting wolfSSL, I'll be looking into your report today to see what may be happening. I will be in touch if I have any questions on your report.
Best Regards,
Kaleb
Hi JHinkle,
I see you are trying to compare the various cipher suite stack/heap use in a handshake based on cipher suite selected.
Here is how I would do just that.
Step 1:
Configure wolfSSL as so:
./configure CFLAGS=-DHAVE_STACK_SIZE
Step 2:
Execute the example client and server with the -t option from two separate terminals:
./examples/client/client -t ./examples/server/server -t
Step 3:
observe output:
SERVER SIDE:
SSL version is TLSv1.2 SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 SSL curve name is SECP256R1 Client message: hello wolfssl! total Allocs = 78 total Deallocs = 78 total Bytes = 102064 peak Bytes = 44386 <--- PEAK current Bytes = 0 stack used = 34016 <--- STACKCLIENT SIDE:
SSL version is TLSv1.2 SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 SSL curve name is SECP256R1 Server response: I hear you fa shizzle! total Allocs = 83 total Deallocs = 83 total Bytes = 92666 peak Bytes = 44807 <--- PEAK current Bytes = 0 stack used = 39136 <--- STACK
Then I would start optimizing things (See configure help output).
./configure -hTo try out specific cipher suites see how we do this by referencing the file: <wolfssl-root>/tests/test.conf
EXAMPLE:
To test the Server and client w/ TLSv1.2 and DHE-RSA-CHACHA20-POLY1305 you would use these commands:
./examples/server/server -l DHE-RSA-CHACHA20-POLY1305 ./examples/client/client -l DHE-RSA-CHACHA20-POLY1305To do ECC suites you'll need to load ECC certificates like so:
./examples/server/server -l ECDHE-ECDSA-CHACHA20-POLY1305 -c ./certs/server-ecc.pem -k ./certs/ecc-key.pem ./examples/client/client -l ECDHE-ECDSA-CHACHA20-POLY1305 -A ./certs/server-ecc.pem
Hope this all helps!
(Suggestion, try running an ECC cipher suite then modify your configuration to
./configure CFLAGS="-DHAVE_STACK_SIZE -DALT_ECC_SIZE"what is the difference? Now try adding "-DECC_USER_CURVES" as well, how much difference now? This will give you an idea of just how configurable wolfSSL can be and that is not even the smallest yet. For more in-depth configurations please see our manual here: https://wolfssl.com/wolfSSL/Docs-wolfss … -toc.html)
Warm Regards,
Kaleb
Hi JHinkle,
" if I enable ECC -- server connects no problem."
It almost sounds like the client is sending ECC certificates ONLY so the server can only select an ECC cipher suite. What certificates are being loaded in the client when you attempt to force an RSA cipher suite?
Is there a way to see what version of TLS the initial handshake is?
Yes, Wireshark!
OR
wolfSSL provides a function "showPeer" which takes an "ssl" object pointer (WOLFSSL*) as input. This function is in the header <wolfssl/test.h> that will print out the Protocol version, cipher suite, and other helpful information.
Best Regards,
Kaleb
Hi Jarkko,
Great, let me know how the wolfcrypt test goes when you get a chance to run it. I look forward to hearing more about your project via email.
Warm Regards,
Kaleb
Hi Jarkko,
Most of your settings are familiar to us but one is not, could you tell us what "SEMEL_SETTINGS" is doing? That is not a define we provide and we would need to know what else it might be enabling/disabling.
Could you also provide us with some more details on your project given the commercial nature of the evaluation we will want to have a better understanding of your end goals and design to better support your efforts.
If you send an email to "support@wolfssl.com" we can better service you from a commercial standpoint as well. This will allow you to communicate to us details you may wish to remain out of scope of the public forums.
Prior to attempting a client/server handshake we always encourage users to verify the underlying crypto is working properly. There is a test application located here: <wolfssl-root>/wolfcrypt/test/test.c. Could you try building and running that application to make sure all tests pass? Our suspicion is that there may be an issue with the crypto libraries in your environment that will need to be addressed prior to performing a successful SSL/TLS connection.
Best Regards,
Kaleb
mohammad.abomokh,
No problem, always happy to help!
- Kaleb
HI mohammad.abomokh,
Have you noticed in <wolfssl-root>/wolfssl/wolfcrypt/settings.h we have an example for the arduino users who have to do something similar. We have them define TIME_OVERRIDES and then define XTIME and XGMTIME to their own custom functions.
#define TIME_OVERRIDES /* must define XTIME and XGMTIME externally */
/* then you would do something like */
#define XTIME <my custom function>
#define XGMTIME <my custom function2>Regards,
Kaleb
Hi malikfehan123,
So sorry for non-response, I was traveling overseas last week but I am back in the office now!
I scanned the domain in question and it only supports static cipher suites as you found and tried to define BUILD_TLS_DHE_RSA_WITH_AES_128_CBC_SHA it looks like you were on the right track. However instead of defining that you should instead use:
#define WOLFSSL_STATIC_RSAto enable static cipher suites.
A -188 is an ASN NO SIGNER TO CONFIRM FAILURE error. This is typically a result of attempting to do peer authentication with a certificate that was not found in the cert chain sent by the peer. Please make sure to load the correct certificate with
wolfSSL_CTX_load_verify_buffer when doing peer authentication. I browsed to the site in question and inspected the page for security details. It looks like the root CA for that domain is: "Avast trusted CA". Please place the "Avast trusted CA" in a cert buffer and load with wolfSSL_CTX_load_verify_buffer when connecting to that site.
Interesting note on: inetupload.indsci.com
If you connect to http://inetupload.indsci.com:443 (Notice HTTP and not HTTPS) you can get a download so you can completely bypass SSL/TLS altogether. If that is your domain I recommend fixing that before going live! If you correctly browse to: https://inetupload.indsci.com:443 then no download and you can view the certificate information
Setting FP_MAX_BITS >=8192 means you have an RSA certificate in your cert chain that is using a 4096-bit RSA key. The examples from TI are fine-tuned for heap/stack use. You may need to bump the size of your stack to allow for this additional RSA-key size as the defaults only use 2048 bit keys if I remember correctly.
Warm Regards,
Kaleb
Hi mehra.akshat,
Happy to hear you were able to solve the issue. I apologize I did not reply sooner as I was out of the office traveling last week. Let us know if you have any other questions, we are always happy to help in any way we can!
Thanks malikfehan123 for helping out in my absence!
Regards,
Kaleb
Hi muyouyuwan,
The error code 80 is part of the SSL/TLS Alert protocol and defined by IETF RFC 5246 section 7.2 "Alert Protocols". See RFC 5246 here: https://www.ietf.org/rfc/rfc5246.txt
80
internal_error
An internal error unrelated to the peer or the correctness of the protocol makes it impossible to continue, such as a memory allocation failure. The error is not related to protocol. This message is always fatal.Is there any way to debug the other side of the connection to see what went wrong?
Regards,
Kaleb
Hi connie.carey,
I am so sorry this went so long unanswered, we had a couple trade shows the last two months and I missed your latest response.
I noticed you said in your last you are building on a Nucleus micro and the hang was stemming from wolfSSL_CTX_load_verify_locations. Does the Nucleus device have a file system? If not you should be using:
wolfSSL_CTX_load_verify_buffer instead and your certificate should be placed in a buffer like we do in <wolfssl-root>/wolfssl/certs_test.h
Regards,
Kaleb
Hi sandeepvl,
Sorry it took me so long to get back I was traveling and out of the office last week.
Yes you are correct, the WOLFSSL_EC_KEY->internal is the ECC key structure containing public/private key parts. Passing that to wc_ecc_export_x963 will export the public key portion of the ECC key structure.
Regards,
Kaleb
Hi malikfehan123,
A -313 is an alert sent from the endpoint you are trying to connect to. If the error were a result of issues with the certificates being sent by the endpoint it would not be a -313 (alert fatal error).
What is the end-point you are attempting to connect to? What protocol are you using (TLS, DTLS, STARTTLS, ...)? What port are you trying to connect on?
It is unlikely your issue is due to certificates, at least from the client's perspective.
Regards,
Kaleb
Hi cunsuo.guo,
We were mid-port when the microchip acquisition of Atmel went through. When the acquisition happened the funding for the project was stopped so progress on the port came to a halt. It is still on our TODO list (thus the comments) but as it is no longer a funded project it has been de-escalated in priority. We plan on getting back to it, but we have no set time frame as of now. If another customer decides to fund the effort it will be escalated in priority again!
We are prepared to support any of the existing port but without an active developer working on the project we can not provide support for the TODO sections at this time.
Regards,
Kaleb
Hi Mabne,
Typically a proxy connection works like so:
Hey Bob, Hey Bob, Alice would
What time is it? like to know the time
----------------> --------------->
| | | |
Alice Proxy Bob
| | | |
<---------------- <--------------
Hey Alice, Hey Proxy, it's 5AM
Bob said it's 5AMSo Alice only ever connected with proxy server. Alice only did one handshake. The proxy then went out on it's own and connected to Bob. Alice has no control over the connection to Bob and no way to control it if she wanted to. The use of a proxy server does not complicate the problem.
What is the error you are seeing when you try to connect to the proxy server?
wolfSSL error codes can be found in <wolfssl-root>/wolfssl/error-ssl.h and <wolfssl-root>/wolfssl/wolfcrypt/error-crypt.h to further explain what the error code means once you have identified it.
Please let me know the error code so I can better understand the issue you are seeing and avoid making incorrect assumptions.
Regards,
Kaleb
Hi carramba and ken-bob,
I just sent you both individual responses in direct email. If you did not receive the AES-ONLY makefile project please let me know and I will re-send it. For any questions please email me anytime support@wolfssl.com and I'll answer any questions I can for you up to the limit of our pre-sales support!
Warm Regards,
Kaleb
Hi walter.kicinski,
Thank you for the suggestion! I have added it to my TO-DO list and will try to get that done as soon as possible!
Cheers,
Kaleb
Hi sandeepvl,
1. Can we easily port WolfSSL to bare-metal environment having no file systems, threads, sockets?
Yes wolfSSL has defines
NO_FILESYSTEM - no filesystem
SINGLE_THREADED - only one thread
WOLFSSL_USER_IO - define custom IO callbacks for any IO interface, USB, Bluetooth, WIFI, in memory, ...
2. Can we easily replace OpenSSL with WolfSSL? From the documentation I see that there is an OpenSSL compatibility layer which makes the migration from OpenSSL to WolfSSL easier. However, there a few APIs which seems missing that are used by current application - CMAC_CTX, CMAC_CTX_new, CMAC_Init, CMAC_Update, CMAC_Final, CMAC_CTX_free, RSA_PKCS1_SSLeay, RSA_padding_add_PKCS1_PSS, RSA_private_encrypt, RSA_private_decrypt, RSA_verify_PKCS1_PSS, RSA_padding_check_PKCS1_OAEP, EC_POINT_point2bn, EC_POINT_oct2point, ECDSA_verify. Can I get the equivalent functionalities working using wolfSSL?
You are correct. We have a compatibility layer that support 400+ of the most common OpenSSL API's and we are adding more all the time. (in fact there are a couple pull requests in the testing phase as we speak)
https://github.com/wolfSSL/wolfssl/pull/764
https://github.com/wolfSSL/wolfssl/pull/724
3. Does it support ECDSA signature generation in X9.62 format?
Yes wolfSSL supports ECDSA sign/verify.
Warm Regards,
Kaleb
Hi abcdefg,
We do not have an exact amount that would be needed, there are unfortunately too many variables.
We chose a size that would work for nearly every configuration. Depending on your build you may be able to reduce that significantly. I regret the best suggestion at this time would be to look at our example in <wolfssl-root>/examples/server/server.c to see how we use the WOLFSSL_TRACK_MEMORY define to check how much memory is being used. Then test out reducing the size of that buffer to fit your environment and build.
We do not have a guide for ECC on Nordic nrf52. If that is something you would like us to look into please let us know and we can put you in touch with the business manager for your region to begin coordinating that effort.
Warm Regards,
Kaleb
Hi walter.kicinski,
You can grab the not before and not after dates with these API's:
char* nBefore;
char* nAfter;
nBefore = wolfSSL_X509_notBefore(x509);
nAfter = wolfSSL_X509_notAfter(x509);
/* echo them out with: */
sz = strlen(nBefore);
for (i = 0; i < sz; i++) {
printf("%02X", nBefore[i]);
}
/* ... same for nAfter ... */The information stored at the pointer is just ASN1 formatted information. The date before and date after are setup like this:
170D3136303831313230303733375A
type - length - YY - MM - DD - HH - MM - SS - UTC
So let's break it down:
17 0D 31 36 30 38 31 31 32 30 30 37 33 37 5A
17 0D - these are the ASN1 information denoting "type" and "length" throw these away (pointer + 2)
31 36 30 38 31 31 32 30 30 37 33 37 - The leading bit here is irrelevant so only grab every other one
5A - UTC - throw awayNow if we look at the section we care about once the ASN1 portions are removed we will see it is already somewhat human-readable we just need to format it by throwing away the leading bit and seperating it into the correct categories
31 36 30 38 31 31 32 30 30 37 33 37 - The leading bit here is irrelevant so only grab every other one
1 6 0 8 1 1 2 0 0 7 3 7
Y Y M M D D H H M M S S
So the date is: 16/08/11 20:07:37 in UTC time
2016 Aug 11 at 20:07:37Hope this helps!
Regards,
Kaleb
Hi cunsuo.guo,
We retain a SCEP client implementation (no server) as a result of contract work done for a specific customer. The work was never licensed under an open source license. If this is a product you are interested in please contact us through info@wolfssl.com!
Warm Regards,
Kaleb
Hey ray,
Thanks for bringing this to our attention, to date that site is just used by us internally. I'm not sure how google managed to find it because we don't have any external links to it that I am aware of. Since it is indexing it we'll want to clean it up for SEO purposes.
Thanks again and Regards,
Kaleb
Hi abrous3d,
I don't think you are missing anything obvious, browsing to accounts.google.com in a browser takes you to where the browser decides to re-direct you. To check a specific domain directly I use openssl's s_client from the terminal so I know I'm hitting the domain i'm actually targeting. Here is the command I used:
openssl s_client -showcerts -connect accounts.google.com:443 </dev/nullThe dump I cleaned up before posting in my initial response but I only look at the subject and issuer information leading each certificate body. You know that the final issuer is the signing authority and in this case it happened to be:
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate AuthorityThen I just googled "Equifax Secure Certificate Authority Download" which brought me to the correct site for downloading the CA. (I do not use the one returned by openssl s_client because if someone were spoofing a domain the domain might return a bad cert with the same issuer credentials. I find it good practice to download directly from the source once you determine which cert it SHOULD be.)
Hope this helps.
Warm Regards,
Kaleb
Hi abrous3d,
I don't think you are missing anything obvious, browsing to accounts.google.com in a browser takes you to where the browser decides to re-direct you. To check a specific domain directly I use openssl's s_client from the terminal so I know I'm hitting the domain i'm actually targeting. Here is the command I used:
openssl s_client -showcerts -connect accounts.google.com:443 </dev/nullThe dump I cleaned up before posting in my initial response but I only look at the subject and issuer information leading each certificate body. You know that the final issuer is the signing authority and in this case it happened to be:
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate AuthorityThen I just googled "Equifax Secure Certificate Authority Download" which brought me to the correct site for downloading the CA.
Hope this helps.
Warm Regards,
Kaleb
wolfSSL - Embedded SSL Library → Posts by Kaleb J. Himes
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.039 seconds (64% PHP - 36% DB) with 5 queries