Welcome to the wolfSSL Forums!

2017-02-20 10:08:58

Hi abrous3d,

The cert chain for accounts.google.com is:

 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=accounts.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2

 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

The Equifax Secure Cert Authority is the root CA you need to verify with. That cert is located here:
https://knowledge.geotrust.com/support/ … ;id=SO5761

I have successfully tested this with our example client:

kalebs-MacBook-Pro:clean-wolfssl khimes$ ./examples/client/client -h 216.58.205.205 -p 443 -A certs/Equifax_Secure_Certificate_Authority.pem -g
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSL connect ok, sending GET...
Server response: HTTP/1.0 404 Not Found
Content-Type: text/html; charset=UTF-8
Content-Length:
 1571
Date: Mon, 20 Feb 2017 17:05:32 GMT
Alt-Svc: quic=":443"; ma=2592000; v
="35,34"

<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=
viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <tit
le>Error 404 (Not Found)!!1</title>
  <style>
    *{margin:0;padding:0}html,cod
e{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}
body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > 
body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repea
t;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-
decoration:none}a img{border:0}@media screen and (max-width:772px){body{backgro
und:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//ww
w.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-re
peat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{back
ground:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x
54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/imag
es/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen 
and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/im
ages/branding/googlelogo/2x/googlelogo_color_1
50x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-
block;height:54px;width:150px}
  </style>
  <a href=//www.google.com/><span id=
logo aria-label=Google></span></a>
  <p><b>404.</b> <ins>That’s an error.</in
s>
  <p>The requested URL <code>/index.html</code> was not found on this server
.  <ins>That’s all we know.</ins>

Best Regards,

Kaleb

2017-02-20 09:10:19

Hi connie.carey,

The most common reason for undefined behavior, unexplained hangs, or crashes is usually a failure to have the same settings in the application as were used when building the wolfSSL library. If working with auto tools on a *NIX based system (mac or linux) please make sure to:

#include <wolfssl/options.h>

in the application. If building on windows please make sure to copy/paste the file <wolfssl-root>/IDE/WIN/user_settings.h into your application and:

#include "user_settings.h"

in your application.

Best,

Kaleb

2017-02-20 09:03:10

Hi omatic,

Could you send the actual configure line in addition to the output please?

2017-02-10 15:28:22

Hi cris,

The binary output of OpenSSL is called libssl. For wolfSSL it would be libwolfssl. Unfortunately we have not ported to libssh2.

Could you share some details about the project you are working on and the reason you wish to use wolfSSL over the other ssl libraries supported by libssh2?

Regards,

Kaleb

2017-02-07 10:28:36

dizgah,

No problem, we're always happy to help in any way we can.

Warm Regards,

Kaleb

2017-02-06 10:26:12

Hi dizgah,

I will email you a makefile project of the extracted portions of the wolfSSL library that will allow for an aes-only build. Could you tell us some more details about your project that it only requires aes? What are the end goals of the project and what problem are you trying to solve? We're always happy to hear about how the wolfSSL library is being used!

Warmest Regards,

Kaleb

2017-02-06 10:01:26

Hi uzairo89,

Glad to hear you have it working! For the sake of the community could you confirm if it was a define missing or was there some customization to the base server code that had to be modified and if so what change helped you to resolve the issue?

Details can be helpful to others facing the same or similar issues if you are free to post those they would be most welcome.

Warm Regards,

Kaleb

2017-02-06 09:55:55

Hi zhouhaohua,

The download from FreeRTOS has many many examples of FreeRTOSConfig.h
The directory structure is like so:

FreeRTOSv9.0.0/FreeRTOS/Demo/<project demo>/FreeRTOSConfig.h (and other project files)
OR
FreeRTOSv9.0.0/FreeRTOS-Plus/Demo/<project demo>/FreeRTOSConfig.h

For example see: FreeRTOSv9.0.0/FreeRTOS-Plus/Demo/FreeRTOS_Plus_WolfSSL_Windows_Simulator/FreeRTOSConfig.h

- Kaleb

2017-02-06 09:49:42

Hi zhanghongge,

wolfSSL actively maintains an OpenSSL compatibility layer for an easy rip-and-replace option. We support all the most common OpenSSL API calls in our compatibility layer and map the OpenSSL calls to internal wolfSSL functions. The best answer I can provide at this time is to just try it, move OpenSSL to a temporary location, put wolfSSL in it's place and change your project to use -lwolfssl instead of -lopenssl.

To get started with wolfSSL please see the following links:
https://www.wolfssl.com/wolfSSL/wolfssl-quickstart.html
https://www.wolfssl.com/wolfSSL/Docs-wo … l-toc.html

For more details on the answer to your question please see this link:
https://www.wolfssl.com/wolfSSL/wolfssl-openssl.html

Let us know if you have any further questions. We're happy to help in any way we can.

Regards,

Kaleb & the wolfSSL Team

2017-02-03 16:07:19

Hi Justin Mclean,

Apologies for the delay in getting back to you. The TIRTOS stuff to date has only been tested and build on the TIVA-C series micro controller family. I am not sure about the CC2640 but my suspicion is that it may not have hardware crypto supported?

The hw_aes.h header file is for hardware aes implementation and is included when WOLFSSL_TIRTOS is defined to speed up aes operations but that is specific to the TIVA-C series family.

If you wish to build for an alternate platform/device family there will likely be modifications necessary. You might check for HW support on your device and if it does have AES Hardware Support then include the correct header in place of hw_aes.h.

A good starting point would be to add a new section to <wolfssl-root>/wolfssl/wolfcrypt/settings.h for WOLFSSL_TIRTOS_CC, use the same settings there as in the WOLFSSL_TIRTOS section and then systematically add a similar section everywhere in the library where WOLFSSL_TIRTOS appears for WOLFSSL_TIRTOS_CC.

Could you share some more details on your project? What are your end goals, what is driving the motivation to port to CC2640?

Regards,

Kaleb

2017-02-02 13:19:19

Hi zhouhaohua,

Please uncomment the define for FREERTOS in <wolfssl-root>/wolfssl/wolfcrypt/settings.h header file when building for FREERTOS. The default settings for FREERTOS will define NO_WRITEV which will prevent the attempt to include either uio.h (standard unix/linux builds or others that implement uio.h) or WinSock2.h (for windows builds).

Best,

Kaleb

2017-02-02 13:15:36

Hi Iqsa00,

For building on Android were you aware of the wolfSSL JNI product (Java based uses Native Interface to call Native C code from wolfSSL library).

https://wolfssl.com/wolfSSL/Docs-wolfss … anual.html

All my best,

Kaleb

2017-01-31 10:03:22

Hi dbenor,

I had this question come up on another forum query recently. As a result I updated the wolfSSL API Reference document but those changes have not yet posted to the website.

The answer is NO you do not want to use the same buffer. Here is a code example of how to use wc_AesCtrEncrypt for both encryption and decryption:

Aes enc;
Aes dec;
/* initialize enc and dec with AesSetKeyDirect, using direction AES_ENCRYPTION
 * since the underlying API only calls Encrypt and by default calling encrypt on
 * a cipher results in a decryption of the cipher
 */

byte msg[AES_BLOCK_SIZE * n]; //n being a positive integer making msg some multiple of 16 bytes
// fill plain with message text
byte cipher[AES_BLOCK_SIZE * n];
byte decrypted[AES_BLOCK_SIZE * n];

wc_AesCtrEncrypt(&enc, cipher, msg, sizeof(msg)); // encrypt plain
wc_AesCtrEncrypt(&dec, decrypted, cipher, sizeof(cipher)); // decrypt cipher text

Regards,

Kaleb

2017-01-27 13:42:57

Hi Extremee,

What changes were made during "configure the library new" (re-configure)? Did you add new defines or remove defines, a combination of both?

What are your settings now?

I apologize for answering your question with questions so often but it's difficult to address what the issue might be without all the information.

- Kaleb

2017-01-27 09:34:19

Hi uzairo89,

I checked the backwards compatibility on my end and they connect fine.

SERVER:

wolfssl-3.9.8 khimes$ ./examples/server/server -u -v 3
SSL version is DTLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Client message: hello wolfssl!

CLIENT:

wolfssl-3.10.0 khimes$ ./examples/client/client -u -v 3
SSL version is DTLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Server response: I hear you fa shizzle!

What is the error you are seeing when you connect a 3.10.0 client to 3.9.8 server?

Which configuration settings are used on the server side and which are used on the client side?

When you connect the 3.9.8 client to the 3.9.8 server which cipher suite is selected for the connection? Is it possible there is some dfine in the configuration of the 3.9.8 client that is missing in the 3.10.0 client?

- Kaleb

2017-01-26 16:40:34

Hi Extremee,

I'm looking into the reasons you might be experiencing the UNKNOWN_RECORD_TYPE in header or SEQUENCE_ERROR but the wireshark is not revealing. All the header information in the capture you sent looks correct. Is there something that was stripped out when the capture was filitered? Is there some other data we're missing?

Could you provide some details on the project you are working on and the end goals?

Thanks,

Kaleb

2017-01-26 12:13:12

Hi uzairo89,

Which version of wolfSSL are you working with? wolfSSL recently added support for CubeMX HAL. If you do not have wolfSSLv3.10.0 please download it from our download page here: https://wolfssl.com/wolfSSL/download/downloadForm.php or get it from our github account https://github.com/wolfSSL/wolfssl.git

You'll find a define for WOLFSSL_STM32_CUBEMX in the STM32F2 section of <wolfssl-root>/wolfssl/wolfcrypt/settings.h
This define offloads AES, DES3, and RANDOM operations to hardware. If you wish to port additional algorithms please use the sections in <wolfssl-root>/wolfcrypt/src/aes.c surrounded by the define for WOLFSSL_STM32_CUBEMX as a reference.

Warmest Regards,

Kaleb

EDIT: See also a slightly more detailed response here: http://stackoverflow.com/questions/4187 … 9#41881639

2017-01-25 14:34:34

Hi Extremee,

Review of the wireshark shows some DTLS 1.2 client Hello packets but no other udp traffic at all.

Honestly it looks like the server just does not have DTLS enabled. Can you confirm if "WOLFSSL_DTLS" is defined in your configuration anywhere?

Did you use a datagram socket (udp) on the server?

sockfd = socket(AF_INET, SOCK_DGRAM, 0);

Could you send your configuration settings?

For a simple DTLS server example please see this project: https://github.com/wolfSSL/wolfssl-exam … ver-dtls.c

This overview may also be helpful: https://github.com/wolfSSL/wolfssl-exam … dp-dtls.md

Warm Regards,

Kaleb

2017-01-25 09:23:07

Hi ravi.kumar,

Let me break down the cipher suite to better explain why the above use-case would never be expected to work:

Part 1 of the suite:
ECDHE means that the client and server will agree on encryption keys using Ephemeral Elliptic Curve Diffie-Hellman.
Part 2 of the suite:
RSA means that the client will verify the key is valid using the RSA algorithm. (NOTICE: you're sending a cert that contains an ecc-key, not an rsa key)
Part 3 of the suite:
AES256 means that the actual encryption will be performed with the AES algorithm using a 256-bit key
Part 4 of the suite:
SHA means that the SHA algorithm will be used for securely hashing parts of the TLS messages.

Extracted certificate indicators that this would not work:

 12         Subject Public Key Info:                                                
 13             Public Key Algorithm: id-ecPublicKey  <--- NOTICE ecPublicKey indicates ECC key not RSA key                              
 14                 Public-Key: (256 bit)                                    
 15                 pub:-                                                           
 16                     04:bb:33:ac:4c:27:50:4a:c6:4a:a5:04:c3:3c:de:               
 17                     9f:36:db:72:2d:ce:94:ea:2b:fa:cb:20:09:39:2c:               
 18                     16:e8:61:02:e9:af:4d:d3:02:93:9a:31:5b:97:92:               
 19                     21:7f:f0:cf:18:da:91:11:02:34:86:e8:20:58:33:               
 20                     0b:80:34:89:d8                                              
 21                 ASN1 OID: prime256v1                                            
 22                 NIST CURVE: P-256   <--- NOTICE: ECC keys use curve id's, RSA keys do not

You are sending a certificate that contains an ecc key, NOT an RSA key. So the cipher suite you have chosen is incompatible with the certificate you selected since the client will try to verify the ECC key you are sending with RSA algorithm.

If you desire to test with either "certs/server-ecc.pem" or "certs/server-ecc-rsa.pem" please select a "ECDHE-ECDSA" cipher suite since both of those certificates contain ECC keys.

For testing with "ECDHE-RSA" please select one of the certificates from the certs directory that contains an RSA key.

Warmest Regards,

Kaleb

EDIT: I can agree in this improper use case it might be more helpful to return or set an alternate error code IE "Cert contains ECC key. Invalid key type for ECDHE-RSA suite" or something to that effect. I've made a note of it and we will review the return code location and message to see if there is something more indicative of the underlying cause of failure that might be returned instead.

2017-01-23 09:35:15

Hi Peter,

I have made a note of it and will review with the team at our next meeting. We appreciate feedback of this kind from the community and would like to extend our gratitude for taking the time to point this out.

Warmest Regards,

Kaleb

2017-01-23 09:30:15

Hi Extremee,

Here I´m not shure what you mean.

IE checking the return codes on file descriptor/socket creation, something like this:

    /* internet address family, stream based tcp, default protocol */
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    if (sockfd < 0) {
        printf("Failed to create socket. errono: %i\n", errno);
        return EXIT_FAILURE;
    }

It looks like everything is working so I will assume the answer here is also yes, you are confident the socket was created prior to calling connect on it.

DTLS uses sequence numbers during the handshake due to the following reason:

When doing a handshake using an unreliable protocol such as UDP there still needs to be a way to guarantee all the handshake packets arrive. To that extent DTLS must send a sequence number when transmitting flights of the handshake. If a flight fails to arrive at the destination that flight will be re-transmitted similar to how TCP is a guaranteed protocol (guarantees all packets arrive or if dropped will re-send until all have arrived). DTLS has to mimick this behavior for the handshake portion of a connection only. To that end it checks if a flight arrives out of order. This is what you have encountered, a flight arrived out of order or with an incorrect sequence number.

Are you implementing the client or the server side?

Which end point are you connecting to? Is it a public endpoint that I could test myself to test interop with that endpoint and the wolfSSL DTLS implementation?

If it is not possible for me to test directly, could you capture a wireshark trace of the connection attempt and send me the pcap for analysis? (If the pcap will not attach to the forum post please email directly to support@wolfssl.com with your forum user name and a link to this post to identify which post the pcap belongs to)

Warm Regards,

Kaleb

2017-01-20 15:06:03

wolfSSL 3.10.0 Now Available

Version 3.10.0 of the wolfSSL embedded SSL/TLS library is now available for download. This release contains bug fixes and new features, described below.

Intel Software Guard Extensions (SGX) support

Intel SGX is a set of instructions provided by Intel that will allow end-user applications to allocate private regions in memory. The regions are called “Enclaves”. Enclaves are secure memory regions that cannot be accessed from processes with privileges above that of the calling application. IE if a malicious user were to gain “Root” privileges on your machine and you had a process running in an Enclave, even with “sudo” or “root” permissions the attacker would be unable to gain access to your application's memory in the Enclave.

Default Configure Option Changes

SHA224(--enable-sha224) is enabled by default. This configure option was added along with support for SHA224. This feature can be disabled with (--disable-sha224). See more below in “Added SHA224 support”
scrypt (--enable-scrypt) is disabled by default. This configure option was added along with support for scrypt. See more below in “Added scrypt feature”.
DISABLE-RNG If building with wolfCrypt only option (--enable-cryptonly) and other configure options such that no cryptographic functions are configured that require a random number generator, this new configure option allows a user to disable the RNG code for reduced footprint size.

Added SHA224 support

SHA224 is a truncated version of SHA256 and computed with different initial values.

Added scrypt feature

scrypt is a password-based key derivation function (PBKDF). PBKDF functions are designed to be costly operations. Typical users need only perform the function once per operation to authenticate their password. The operation time is negligible when performed once. On the other hand, a brute-force attempt by a malicious user attempting to determine a typical user’s credentials would need to be performed millions, or billions of times. The computational cost when performing a PBKDF millions or billions of time is incredibly significant. The goal of this cost is to deter brute-force attacks.

Fix for ChaCha20-Poly1305 ECDSA certificate type request

Updated SendCertificateRequest() to add a cipher suite byte check for CHACHA_BYTE.
This fixes a bug where wolfSSL was incorrectly requesting an RSA certificate when using an ECDSA-CHACHA20 cipher suite.

Enhance PKCS#7 with ECC enveloped data and AES key wrap support

EncryptedData content type (DES, 3DES, AES-128/192/256-CBC)
EnvelopedData content type (RSA/ECC-DES/3DES/AES)
Refactor of some PKCS#7 functions to reduce function length
Addition of PKCS#7 tests for EncryptedData and EnvelopedData
This functionality was interop tested against OpenSSL 1.1.0c from both encode/decode sides.

Added support for RIOT OS

RIOT OS is a popular operating system for IoT devices. wolfSSL now offers out-of-the-box support for RIOT OS with the “Native Board” on Unix and Linux systems. To use this support please define WOLFSSL_RIOT_OS in your project or in <wolfssl-root>/wolssl/wolfcrypt/settings.h

Add support for parsing PKCS#12 files

PKCS12 files contain internal storage “containers”, called "SafeBags". Each SafeBag may be individually encrypted and signed. Specific SafeBags are set aside to store certificates, private keys and CRLs however there are additional SafeBags provided to store additional data as required by the user.

ECC performance increased with custom curves

ECC_CACHE_CURVE is a new pre-processor macro which adds internal ECC states and allows for caching portions of the ECC curve for subsequent operations. This feature is disabled by default and can be enabled at configure time with ./configure CFLAGS=”-DECC_CACHE_CURVE”. This change results in the following increases in computation time:
ECC key generation: 4.2% increase in performance
ECC key agreement: 4.0% increase in performance
ECC sign operation: 6.8% increase in performance
ECC verify operation: 5.8% increase in performance

ARMv8 expanded to AArch32 and performance increased

These changes handle higher levels of optimizations better including additions to clobber lists to keep optimizations from using registers possibly already in use. Also loads pointers to AES key and SHA256 K table into a register to prevent potential segmentation faults.

Added ANSI-X9.63-KDF support

Added support for X9.63 Key Derivation Function. Consumers of PKCS#7 EnvelopedData using ECC certs/keys will appreciate this addition.

Port to STM32 F2/F4 CubeMX

In <wolfssl-root>/wolssl/wolfcrypt/settings.h, notice in the sections for WOLFSSL_STM32F2 and WOLFSSL_STM32F4 new pre-processor checks have been added for the define WOLFSSL_STM32_CUBEMX (applies to either/or STM32F2/F4). If WOLFSSL_STM32_CUBEMX is defined, wolfSSL will provide hardware acceleration support for random number generation (RNG), AES, SHA1, DES3 and MD5. Please note this is only supported when using CubeMX Hardware Abstraction Layer (HAL). We expect this to also work on STM32(F0/F1/F3/F7/L0/L1/L4) as those platforms are all supported by CubeMX HAL however this functionality has only been tested on STM32F2 and STM32F4 therefore those are the only default available options at this time.

Port to Atmel ATECC508A board

This port comes in the form of a seperate download.
Info here: https://www.wolfssl.com/wolfSSL/wolfssl-atmel.html

Removed fPIE by default when wolfSSL library is compiled

No longer assumes position independent code by default.

Update to Python wrapper, dropping DES and adding wc_RSASetRNG

Removed support for DES and added support for RSA blinding

Added support for NXP K82 hardware acceleration

Support for the NXP LTC math core. RSA, ECC and Ed/Curve25519 hardware acceleration. Based off KSDK 2.0 and tested on the FRDM-K82F.
Updated IDE/ROWLEY-CROSSWORKS-ARM example and the new wolfssl_ltc.hzp project file was added to demonstrate K82 LTC support.
With LTC:
RSA 2048 public 12.000 milliseconds, avg over 1 iterations
RSA 2048 private 135.000 milliseconds, avg over 1 iterations
ECC 256 key generation 17.400 milliseconds, avg over 5 iterations
EC-DHE key agreement 15.200 milliseconds, avg over 5 iterations
EC-DSA sign time 20.200 milliseconds, avg over 5 iterations
EC-DSA verify time 33.000 milliseconds, avg over 5 iterations
Without LTC (software only):
RSA 2048 public 147.000 milliseconds, avg over 1 iterations
RSA 2048 private 2363.000 milliseconds, avg over 1 iterations
ECC 256 key generation 355.400 milliseconds, avg over 5 iterations
EC-DHE key agreement 352.400 milliseconds, avg over 5 iterations
EC-DSA sign time 362.400 milliseconds, avg over 5 iterations
EC-DSA verify time 703.400 milliseconds, avg over 5 iterations

Added more tests vectors to test.c with AES-CTR

Added test vectors for AES-192 and AES-256 in addition to the already existing AES-128 test vectors.

Updated DTLS for 64 bit sequence numbers

Updated to use a 64-bit sequence number in every record, of which, 48-bits are used for DTLS sequence numbers.

Updated DTLS session export version number

Due to the change of sequence numbers size (64-bit instead of 32-bit) there was a need to support older versions of wolfSSL that still use 32-bit sequence numbers when exporting sessions. This export version number update will allow newer versions of the library to be interoperable with older versions of the library that were using 32-bit sequence numbers.

Fix for memory management with TI and WOLFSSL_SMALL_STACK

Fixed a typo where DYNAMIC_TYPE_TMP_BUFFER was misspelled in pkcs7.c. Fixed call to XFREE with variable “W_K” instead of “W” in sha256.c. Addressed structure typo where “hmac” should have been “myHmac” in hmac.c

Hardening RSA CRT to be constant time

Made RSA CRT operation constant time to prevent leaking useful information to attackers capable of identifying which part of the CRT operation failed.

Fix for C# wrapper example IO hang on unexpected connection termination

There was a condition where “receive” API did not throw an exception when a connection was ungracefully terminated. To account for this wolfSSL added a call to Socket.Poll to check on termination status when no data is received.

Please contact wolfSSL at info@wolfssl.com with any questions about new features or fixes made in this release of wolfSSL.

References:

wolfSSL Embedded SSL/TLS Library: https://www.wolfssl.com/wolfSSL/Products-wolfssl.html
Download wolfSSL: https://wolfssl.com/wolfSSL/download/downloadForm.php

2017-01-20 09:31:04

Hi Peter,

That setting was a design decision made by the developer who did the port for PIC32. The developer was aware that PIC32 can work with both legacy mla, harmony, and even third-party peripherals. Because of this the decision was made to define "WOLFSSL_USER_IO" by default. The intent was to alert developers working with the port that there is a need to:

A. Determine if "send" and "recv" are available, if so then use them.
B. If not available implement custom IO callbacks based on available API.

In your case you have determined that BSD API is available which indicates that the "send" and "recv" functions should also be available. You should be safe to override that setting. If you build without that setting and find that "send" and "recv" are not available THEN you will need to implement custom IO callbacks based on what the BSD implementation is using for send/recv. No harm in trying the simplest solution first.

Regards,

Kaleb

2017-01-19 14:14:24

Hi hyongsop,

Any other suggestions? Is there a way to see the log messages generated by the Client and Server?

Yes you can configure wolfssl with the same configure options as before and add

--enable-debug

Then the JNI client will dump out a debug log to the command line console when run. Could you send that?

Also another suggestion would be, if you can capture a wireshark trace of the connection, please attach and send a pcap of that connection. If the pcap will not attach to the blog post you can email to me directly kaleb@wolfssl.com

Is this a correct client behavior? It seems the BC server is implementing a different handshake protocol than the client...

If there was no application data and the client simply started over then no this is not correct behavior. If session resumption is on and the server finished it's connection "test" and then hung up, the client might have tried to resume the session and then failed, it's difficult to speculate without a wireshark trace to confirm which case though.

Regards,

Kaleb

2017-01-19 11:15:09

Hi hyongsop,

The attachment did not make it through, could you re-send or copy into a "code" block here?

A key length of 2432 is a non-standard key length. Typically RSA keys are evenly divisible by 1024 (1024, 2048, 3072, 4096... etc). I would be curious to see it regardless.

When you tested with the wolfSSL certificates, again just to confirm, you copied our certs over to your windows machine and loaded the wolfSSL certificates into the BC server before attempting to connect the client correct?

It is possible there may be a bug in the JNI client but that is doubtful as it is widely used and well tested. Have you tested against the BC server using the client example that ships with wolfSSL?

You could test by running this command from <wolfssl-root> directory after you have configure and made our library:

./examples/client/client <same arguments as used in JNI client>

The JNI client and examples/client take the same command line arguments so you'd just need to copy/paste your certs into <wolfssl-root>/certs directory and instead of ../certs/<certname> just use ./certs/<certname>

Regards,

Kaleb

Welcome to the wolfSSL Forums!

Search options (Page 24 of 31)

Posts found: 576 to 600 of 758

576 Reply by Kaleb J. Himes 2017-02-20 10:08:58

Re: Error -188 while connecting to accounts.google.com (4 replies, posted in wolfSSL)

577 Reply by Kaleb J. Himes 2017-02-20 09:10:19

Re: problems with AlreadySigner function call (3 replies, posted in wolfSSL)

578 Reply by Kaleb J. Himes 2017-02-20 09:03:10

Re: curl using wolfssl for ARM (1 replies, posted in wolfSSL)

579 Reply by Kaleb J. Himes 2017-02-10 15:28:22

Re: use curl for sftp client (1 replies, posted in wolfSSL)

580 Reply by Kaleb J. Himes 2017-02-07 10:28:36

Re: Standalone AES library for embedded device (7 replies, posted in wolfCrypt)

581 Reply by Kaleb J. Himes 2017-02-06 10:26:12

Re: Standalone AES library for embedded device (7 replies, posted in wolfCrypt)

582 Reply by Kaleb J. Himes 2017-02-06 10:01:26

Re: [SOLVED] STM32F437 Hardware Crypto functions integration with WolfSSL (5 replies, posted in wolfSSL)

583 Reply by Kaleb J. Himes 2017-02-06 09:55:55

Re: wolfSSL with FreeRTOS Porting to NXP LPC43xx problem (6 replies, posted in wolfSSL)

584 Reply by Kaleb J. Himes 2017-02-06 09:49:42

Re: Could you tell me OpenSSL can be replaced by WolfSSL? (4 replies, posted in General Inquiries)

585 Reply by Kaleb J. Himes 2017-02-03 16:07:19

Re: Compile WolfSSL for TIROS with WOLFSSL_USER_IO (3 replies, posted in wolfSSL)

586 Reply by Kaleb J. Himes 2017-02-02 13:19:19

Re: wolfSSL with FreeRTOS Porting to NXP LPC43xx problem (6 replies, posted in wolfSSL)

587 Reply by Kaleb J. Himes 2017-02-02 13:15:36

Re: How to compile for Android? (1 replies, posted in wolfSSL)

588 Reply by Kaleb J. Himes 2017-01-31 10:03:22

Re: In-place aes CTR (1 replies, posted in wolfCrypt)

589 Reply by Kaleb J. Himes 2017-01-27 13:42:57

Re: 308 Error in wolfSSL_accept() (11 replies, posted in wolfSSL)

590 Reply by Kaleb J. Himes 2017-01-27 09:34:19

Re: [SOLVED] STM32F437 Hardware Crypto functions integration with WolfSSL (5 replies, posted in wolfSSL)

591 Reply by Kaleb J. Himes 2017-01-26 16:40:34

Re: 308 Error in wolfSSL_accept() (11 replies, posted in wolfSSL)

592 Reply by Kaleb J. Himes 2017-01-26 12:13:12

Re: [SOLVED] STM32F437 Hardware Crypto functions integration with WolfSSL (5 replies, posted in wolfSSL)

593 Reply by Kaleb J. Himes 2017-01-25 14:34:34

Re: 308 Error in wolfSSL_accept() (11 replies, posted in wolfSSL)

594 Reply by Kaleb J. Himes 2017-01-25 09:23:07

Re: Getting connectivity issue when trying SSL cipher ECDHE-RSA-AES256-SHA (4 replies, posted in wolfCrypt)

595 Reply by Kaleb J. Himes 2017-01-23 09:35:15

Re: Problem writing a correct EmbedSend and EmbedRecieve (5 replies, posted in wolfSSL)

596 Reply by Kaleb J. Himes 2017-01-23 09:30:15

Re: 308 Error in wolfSSL_accept() (11 replies, posted in wolfSSL)

597 Topic by Kaleb J. Himes 2017-01-20 15:06:03

Topic: wolfSSL 3.10.0 Now Available (0 replies, posted in Announcements)

598 Reply by Kaleb J. Himes 2017-01-20 09:31:04

Re: Problem writing a correct EmbedSend and EmbedRecieve (5 replies, posted in wolfSSL)

599 Reply by Kaleb J. Himes 2017-01-19 14:14:24

Re: Help with err = -188, ASN no signer to confirm failure (10 replies, posted in wolfSSL)

600 Reply by Kaleb J. Himes 2017-01-19 11:15:09

Re: Help with err = -188, ASN no signer to confirm failure (10 replies, posted in wolfSSL)

Posts found: 576 to 600 of 758