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 hstr
Pages 1
I just found that this trade-off seems to be intended. In the wolfSSL manual there is an option "CURVED25519_SMALL" described that reduces the code size a lot but also decreases the performance very much.
However my question about how to implement custom cipher suites remains.
Hi Jacob,
thank you for the fast answer. I am still a bit sceptical about the performance of ed25519 since it would be over ten times faster than RSA/secp256r1. Even the paper does not mention an enhancement of this magnitude.
How complex would it be to change the code such that it is able to use ed25519/curve25519 for the handshake? This is actually a more general question, how can a custom cipher suite be implemented that uses algorithms which are not included by default?
EDIT:
The code size of a .elf file with ed25519 usage is much bigger than the code size with secp256r1 usage (around 75 kB difference). It seems like there is a trade-off between speed and size.
Regards,
hstr
Hi,
currently I am playing around with the ECC support of wolfSSL. I figured out that the curves secp256r1, curve25519 and ed25519 are implemented. But the usage of them are a bit confusing to me, so I got some questions about these curves.
- In the benchmark (https://github.com/wolfSSL/wolfssl/blob … enchmark.c) there seems to be no measurement for the sign and verify performance of curve25519. Is this intended? (Since there are sign/verify measurements for ecc (which I assume to be secp256r1) and ed25519)
- When I run the benchmark I get strange results regarding to ed25519. RSA needs 582 ms to sign and 20 ms to verify, ecdsa (secp256r1 ?) needs 178 ms to sign and 344 ms to verify, and now comes ed 25519 with very different results: 8 ms to sign and 20 ms to verify. Something seems to be wrong here, do you have any idea?
- Is there an option to run the TLS handshake with curve25519 and ed25519? I already think about problems with the certificates, since the included certs only support secp256r1. Are there any other issues with these new curves?
Thanks you,
hstr
Ok, I just fixed the problem, it works now with ECDHE-ECDSA-AES128-GCM-SHA256 and no filesystem.
For people who got the same problem, at first you need to add the following in the certs_test.h file:
/* ./certs/server-ecc.der */
static const unsigned char server_ecc_der[] =
{
0x30, 0x82, 0x03, 0x0F, 0x30, 0x82, 0x02, 0xB5, 0xA0, 0x03, 0x02, 0x01, 0x02, 0x02, 0x09, 0x00,
0xB2, 0x37, 0x31, 0x16, 0xF6, 0x5A, 0x0A, 0x06, 0x30, 0x0A, 0x06, 0x08, 0x2A, 0x86, 0x48, 0xCE,
0x3D, 0x04, 0x03, 0x02, 0x30, 0x81, 0x8F, 0x31, 0x0B, 0x30, 0x09, 0x06, 0x03, 0x55, 0x04, 0x06,
0x13, 0x02, 0x55, 0x53, 0x31, 0x13, 0x30, 0x11, 0x06, 0x03, 0x55, 0x04, 0x08, 0x0C, 0x0A, 0x57,
0x61, 0x73, 0x68, 0x69, 0x6E, 0x67, 0x74, 0x6F, 0x6E, 0x31, 0x10, 0x30, 0x0E, 0x06, 0x03, 0x55,
0x04, 0x07, 0x0C, 0x07, 0x53, 0x65, 0x61, 0x74, 0x74, 0x6C, 0x65, 0x31, 0x10, 0x30, 0x0E, 0x06,
0x03, 0x55, 0x04, 0x0A, 0x0C, 0x07, 0x45, 0x6C, 0x69, 0x70, 0x74, 0x69, 0x63, 0x31, 0x0C, 0x30,
0x0A, 0x06, 0x03, 0x55, 0x04, 0x0B, 0x0C, 0x03, 0x45, 0x43, 0x43, 0x31, 0x18, 0x30, 0x16, 0x06,
0x03, 0x55, 0x04, 0x03, 0x0C, 0x0F, 0x77, 0x77, 0x77, 0x2E, 0x77, 0x6F, 0x6C, 0x66, 0x73, 0x73,
0x6C, 0x2E, 0x63, 0x6F, 0x6D, 0x31, 0x1F, 0x30, 0x1D, 0x06, 0x09, 0x2A, 0x86, 0x48, 0x86, 0xF7,
0x0D, 0x01, 0x09, 0x01, 0x16, 0x10, 0x69, 0x6E, 0x66, 0x6F, 0x40, 0x77, 0x6F, 0x6C, 0x66, 0x73,
0x73, 0x6C, 0x2E, 0x63, 0x6F, 0x6D, 0x30, 0x1E, 0x17, 0x0D, 0x31, 0x35, 0x30, 0x35, 0x30, 0x37,
0x31, 0x38, 0x32, 0x31, 0x30, 0x31, 0x5A, 0x17, 0x0D, 0x31, 0x38, 0x30, 0x31, 0x33, 0x31, 0x31,
0x38, 0x32, 0x31, 0x30, 0x31, 0x5A, 0x30, 0x81, 0x8F, 0x31, 0x0B, 0x30, 0x09, 0x06, 0x03, 0x55,
0x04, 0x06, 0x13, 0x02, 0x55, 0x53, 0x31, 0x13, 0x30, 0x11, 0x06, 0x03, 0x55, 0x04, 0x08, 0x0C,
0x0A, 0x57, 0x61, 0x73, 0x68, 0x69, 0x6E, 0x67, 0x74, 0x6F, 0x6E, 0x31, 0x10, 0x30, 0x0E, 0x06,
0x03, 0x55, 0x04, 0x07, 0x0C, 0x07, 0x53, 0x65, 0x61, 0x74, 0x74, 0x6C, 0x65, 0x31, 0x10, 0x30,
0x0E, 0x06, 0x03, 0x55, 0x04, 0x0A, 0x0C, 0x07, 0x45, 0x6C, 0x69, 0x70, 0x74, 0x69, 0x63, 0x31,
0x0C, 0x30, 0x0A, 0x06, 0x03, 0x55, 0x04, 0x0B, 0x0C, 0x03, 0x45, 0x43, 0x43, 0x31, 0x18, 0x30,
0x16, 0x06, 0x03, 0x55, 0x04, 0x03, 0x0C, 0x0F, 0x77, 0x77, 0x77, 0x2E, 0x77, 0x6F, 0x6C, 0x66,
0x73, 0x73, 0x6C, 0x2E, 0x63, 0x6F, 0x6D, 0x31, 0x1F, 0x30, 0x1D, 0x06, 0x09, 0x2A, 0x86, 0x48,
0x86, 0xF7, 0x0D, 0x01, 0x09, 0x01, 0x16, 0x10, 0x69, 0x6E, 0x66, 0x6F, 0x40, 0x77, 0x6F, 0x6C,
0x66, 0x73, 0x73, 0x6C, 0x2E, 0x63, 0x6F, 0x6D, 0x30, 0x59, 0x30, 0x13, 0x06, 0x07, 0x2A, 0x86,
0x48, 0xCE, 0x3D, 0x02, 0x01, 0x06, 0x08, 0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x03, 0x01, 0x07, 0x03,
0x42, 0x00, 0x04, 0xBB, 0x33, 0xAC, 0x4C, 0x27, 0x50, 0x4A, 0xC6, 0x4A, 0xA5, 0x04, 0xC3, 0x3C,
0xDE, 0x9F, 0x36, 0xDB, 0x72, 0x2D, 0xCE, 0x94, 0xEA, 0x2B, 0xFA, 0xCB, 0x20, 0x09, 0x39, 0x2C,
0x16, 0xE8, 0x61, 0x02, 0xE9, 0xAF, 0x4D, 0xD3, 0x02, 0x93, 0x9A, 0x31, 0x5B, 0x97, 0x92, 0x21,
0x7F, 0xF0, 0xCF, 0x18, 0xDA, 0x91, 0x11, 0x02, 0x34, 0x86, 0xE8, 0x20, 0x58, 0x33, 0x0B, 0x80,
0x34, 0x89, 0xD8, 0xA3, 0x81, 0xF7, 0x30, 0x81, 0xF4, 0x30, 0x1D, 0x06, 0x03, 0x55, 0x1D, 0x0E,
0x04, 0x16, 0x04, 0x14, 0x5D, 0x5D, 0x26, 0xEF, 0xAC, 0x7E, 0x36, 0xF9, 0x9B, 0x76, 0x15, 0x2B,
0x4A, 0x25, 0x02, 0x23, 0xEF, 0xB2, 0x89, 0x30, 0x30, 0x81, 0xC4, 0x06, 0x03, 0x55, 0x1D, 0x23,
0x04, 0x81, 0xBC, 0x30, 0x81, 0xB9, 0x80, 0x14, 0x5D, 0x5D, 0x26, 0xEF, 0xAC, 0x7E, 0x36, 0xF9,
0x9B, 0x76, 0x15, 0x2B, 0x4A, 0x25, 0x02, 0x23, 0xEF, 0xB2, 0x89, 0x30, 0xA1, 0x81, 0x95, 0xA4,
0x81, 0x92, 0x30, 0x81, 0x8F, 0x31, 0x0B, 0x30, 0x09, 0x06, 0x03, 0x55, 0x04, 0x06, 0x13, 0x02,
0x55, 0x53, 0x31, 0x13, 0x30, 0x11, 0x06, 0x03, 0x55, 0x04, 0x08, 0x0C, 0x0A, 0x57, 0x61, 0x73,
0x68, 0x69, 0x6E, 0x67, 0x74, 0x6F, 0x6E, 0x31, 0x10, 0x30, 0x0E, 0x06, 0x03, 0x55, 0x04, 0x07,
0x0C, 0x07, 0x53, 0x65, 0x61, 0x74, 0x74, 0x6C, 0x65, 0x31, 0x10, 0x30, 0x0E, 0x06, 0x03, 0x55,
0x04, 0x0A, 0x0C, 0x07, 0x45, 0x6C, 0x69, 0x70, 0x74, 0x69, 0x63, 0x31, 0x0C, 0x30, 0x0A, 0x06,
0x03, 0x55, 0x04, 0x0B, 0x0C, 0x03, 0x45, 0x43, 0x43, 0x31, 0x18, 0x30, 0x16, 0x06, 0x03, 0x55,
0x04, 0x03, 0x0C, 0x0F, 0x77, 0x77, 0x77, 0x2E, 0x77, 0x6F, 0x6C, 0x66, 0x73, 0x73, 0x6C, 0x2E,
0x63, 0x6F, 0x6D, 0x31, 0x1F, 0x30, 0x1D, 0x06, 0x09, 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x01,
0x09, 0x01, 0x16, 0x10, 0x69, 0x6E, 0x66, 0x6F, 0x40, 0x77, 0x6F, 0x6C, 0x66, 0x73, 0x73, 0x6C,
0x2E, 0x63, 0x6F, 0x6D, 0x82, 0x09, 0x00, 0xB2, 0x37, 0x31, 0x16, 0xF6, 0x5A, 0x0A, 0x06, 0x30,
0x0C, 0x06, 0x03, 0x55, 0x1D, 0x13, 0x04, 0x05, 0x30, 0x03, 0x01, 0x01, 0xFF, 0x30, 0x0A, 0x06,
0x08, 0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x04, 0x03, 0x02, 0x03, 0x48, 0x00, 0x30, 0x45, 0x02, 0x20,
0x35, 0x25, 0x33, 0xEA, 0x7C, 0x3B, 0xE2, 0x2E, 0xED, 0xE4, 0x2E, 0x9A, 0x91, 0xF1, 0xC3, 0x86,
0xFF, 0xA7, 0x27, 0x35, 0xA9, 0xF6, 0x29, 0xD6, 0xF8, 0xD5, 0x9A, 0x0B, 0x35, 0xF1, 0x21, 0xC7,
0x02, 0x21, 0x00, 0xBC, 0x79, 0xF7, 0xFD, 0x66, 0xD4, 0xD3, 0x46, 0x61, 0xE4, 0x19, 0xE5, 0xF7,
0x74, 0x03, 0x83, 0x27, 0xF8, 0x26, 0xC0, 0x86, 0x15, 0xA9, 0xE2, 0x10, 0xE3, 0xAD, 0x6B, 0xB9,
0x1C, 0x1D, 0xEB
};
static const int sizeof_server_ecc_der = sizeof(server_ecc_der);
/* ./certs/ecc-key.der */
static const unsigned char ecc_key_der[] =
{
0x30, 0x77, 0x02, 0x01, 0x01, 0x04, 0x20, 0x45, 0xB6, 0x69, 0x02, 0x73, 0x9C, 0x6C, 0x85, 0xA1,
0x38, 0x5B, 0x72, 0xE8, 0xE8, 0xC7, 0xAC, 0xC4, 0x03, 0x8D, 0x53, 0x35, 0x04, 0xFA, 0x6C, 0x28,
0xDC, 0x34, 0x8D, 0xE1, 0xA8, 0x09, 0x8C, 0xA0, 0x0A, 0x06, 0x08, 0x2A, 0x86, 0x48, 0xCE, 0x3D,
0x03, 0x01, 0x07, 0xA1, 0x44, 0x03, 0x42, 0x00, 0x04, 0xBB, 0x33, 0xAC, 0x4C, 0x27, 0x50, 0x4A,
0xC6, 0x4A, 0xA5, 0x04, 0xC3, 0x3C, 0xDE, 0x9F, 0x36, 0xDB, 0x72, 0x2D, 0xCE, 0x94, 0xEA, 0x2B,
0xFA, 0xCB, 0x20, 0x09, 0x39, 0x2C, 0x16, 0xE8, 0x61, 0x02, 0xE9, 0xAF, 0x4D, 0xD3, 0x02, 0x93,
0x9A, 0x31, 0x5B, 0x97, 0x92, 0x21, 0x7F, 0xF0, 0xCF, 0x18, 0xDA, 0x91, 0x11, 0x02, 0x34, 0x86,
0xE8, 0x20, 0x58, 0x33, 0x0B, 0x80, 0x34, 0x89, 0xD8
};
static const int sizeof_ecc_key_der = sizeof(ecc_key_der);Now the client needs to be changed like this:
wolfSSL_CTX_load_verify_buffer(ctx, server_ecc_der, sizeof_server_ecc_der, SSL_FILETYPE_ASN1)And the server like this:
wolfSSL_CTX_use_certificate_buffer(ctx, server_ecc_der, sizeof_server_ecc_der, SSL_FILETYPE_ASN1)
wolfSSL_CTX_use_PrivateKey_buffer(ctx, ecc_key_der, sizeof_ecc_key_der, SSL_FILETYPE_ASN1)Without having a ECDSA certificate set at the server there will be a -501 error.
And another thing I'd like to add, the conversion of .pem certificate to a byte array as in certs_test.h works as follows:
Convert the .pem file to .der by using openssl (https://www.openssl.org/docs/manmaster/apps/x509.html) and then convert the .der file to a byte array, this can be achieved by reusing the code from mkyong (https://www.mkyong.com/java/how-to-conv … x-in-java/).
One last point: I figured out that the connection also works without having HAVE_TLS_EXTENSIONS and HAVE_SUPPORTED_CURVES.
Hi David,
thank you very much for the fast reply and the file update.
I have added HAVE_TLS_EXTENSIONS and HAVE_SUPPORTED_CURVES to the client and the server. Unfortunately the error is still -501.
About the byte arrays I am note quite sure which one should be used for what purpose. In the server-tls-ecdhe.c example the file server-ecc.pem is used as certificate and the file ecc-key.pem is used as private key. In the client-tls-ecdhe.c example the file server-ecc.pem is used as CA certificate. However the file server-ecc.pem is not included in your byte arrays (I assume that ecc-key.pem equals ecc-key.der, which is included in your byte array).
Finally I think the lack of the ECC certificate might be the overall problem, since I just enabled the debug flag and got the message "Not ECDSA cert signature".
EDIT:
Could you please tell me how to convert a .pem/.der file to a byte array as used in certs_test? So I can do that on my own and don't have to bother you.
Best regards
hstr
Hello,
currently I am compiling my TLS client (wolfssl-3.9.6) with
#define WOLFSSL_LWIP
#define SIZEOF_LONG 4
#define SIZEOF_LONG_LONG 8
#define NO_WRITEV
#define NO_FILESYSTEM
#define USE_CERT_BUFFERS_1024
#define SINGLE_THREADED
#define CHAR_BIT 8
#define TFM_NO_ASM
#define USER_TIME
#define USER_TICKS
#define USE_FAST_MATH
#define NO_DEV_RANDOM
#define NO_WOLFSSL_SERVER
#define NO_OLD_TLS
#define NO_DES3
#define NO_ERROR_STRINGS
#define NO_MD4
#define NO_PSK
#define NO_RC4
#define NO_RABBIT
#define HAVE_ECC
#define HAVE_AESGCM
#define BUILD_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256and my TLS server (wolfssl-3.9.6) with
#define WOLFSSL_LWIP
#define SIZEOF_LONG 4
#define SIZEOF_LONG_LONG 8
#define NO_WRITEV
#define NO_FILESYSTEM
#define USE_CERT_BUFFERS_1024
#define SINGLE_THREADED
#define CHAR_BIT 8
#define TFM_NO_ASM
#define USER_TIME
#define USER_TICKS
#define NO_DEV_RANDOM
#define NO_WOLFSSL_CLIENT
#define NO_OLD_TLS
#define NO_DES3
#define NO_ERROR_STRINGS
#define NO_MD4
#define NO_PSK
#define NO_RC4
#define NO_RABBIT
#define HAVE_ECC
#define HAVE_AESGCM
#define BUILD_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256After the start the client is trying to connect to the server with "wolfSSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-AES128-GCM-SHA256");". However I get an error at the server side stating error = -501, which means that the cipher suite can't be matched and there is no response from the server to the Client Hello message.
Strangely the connection works perfectly fine when "ECDHE-RSA-AES128-GCM-SHA256" is used at the client and both are compiled with "BUILD_TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256". So my guess is that there are some issues with the ECDSA algorithm.
Could you please provide me some help with this issue?
EDIT:
I just saw that there is no ecc key and ecc cert in the certs_test.h file, so this could also be problematic later on. However I can just disable the verification at the client for testing purposes. But currently I am still stuck at the Client Hello. (Maybe ecc stuff could also be added in certs_test.h for future wolfSSL versions so it also works on boards without file system)
Best regards
hstr
Hi,
thanks for the hint with the anonymous cipher. I compiled both, client and server with "HAVE_ANON", "BUILD_TLS_DH_anon_WITH_AES_128_CBC_SHA" and the command "wolfSSL_CTX_allow_anon_cipher(ctx);".
But when I connect to the server with "wolfSSL_CTX_set_cipher_list(ctx, "ADH-AES128-SHA");" set at the client, the client sends a "client hello" message but the server then runs into a error: "-501" - "can't match cipher suite".
Are there any other steps that need to be done to communicate via the anonymous cipher?
Thank you for the answer. I performed some benchmarks now and compared the performance to send and receive:
Benchmark:
AES256: 1.7 MByte/s
AES512: 1.7 MByte/s
SHA: 4.0 MByte/s
SHA256: 2.3 MByte/s
AES GCM: 0.6 MByte/s
Send and Receive:
AES GCM: 4.4 Mbit/s
AES256 + SHA256: 5.2 Mbit/s
AES128 + SHA: 6.5 Mbit/s
No Enc + SHA: 13 Mbit/s
AES GCM seems to be ok, 4.4 Mbit/s is a bit less than 0.6*8 = 4.8 Mbit/s but there is overhead by the TLS stack.
AES256 + SHA256 is already a bit strange because 5.2 Mbit/s is much less than 1.7*8 = 13.6 Mbit/s and 2.3*8 = 18.4 Mbit/s, or is this normal because both algorithms have to be applied?
No Enc + SHA is now really weird since 13 Mbit/s is very far from the benchmark result of 4*8 = 32 Mbit/s.
Are the results reasonable? Do I miss something important?
I also checked the pure TCP performance (no wolfSSL) of my TLS stack and it was able to do 37 Mbit/s (no processing, just raw send and receive). I guess the processing also takes time and therefore decreases the performance.
Hi,
recently I did some first performance measurements with two boards, one is running the wolfSSL Client and the other one is running the wolfSSL Server.
The following options that are important for the measurements are set:
#define SIZEOF_LONG 4
#define SIZEOF_LONG_LONG 8
#define NO_FILESYSTEM
#define USE_CERT_BUFFERS_2048
#define SINGLE_THREADED
#define CHAR_BIT 8
#define TFM_NO_ASM
#define USE_FAST_MATH
#define HAVE_AESGCM
#define BUILD_TLS_RSA_WITH_AES_128_GCM_SHA256
So a connection between the boards is established with RSA and AES128 in GCM.
In the first test, the client is sending to the server at maximum speed:
static char data[1452];
while(1)
{
wolfSSL_send(ssl, data, sizeof(data), 0);
}The resulting speed (measured with wireshark) is at 4,4 Mbit/s. The result seems to be quite reasonable, since there is no
hardware acceleration. (is it really, what do you think? I am using a TriCore with 300 MHz)
But now there appears to be a problem when I let the server send to the client. The client connects to the server and then the server sends to the client at maximum speed, using the same code as above.
The resulting speed is now much lower, at around 120 kbit/s.
Can someone please help by telling me what might be the cause of this difference. Actually I expected that the speed in both directions should be pretty much the same.
Best regards,
hstr
Hi,
is there a way to disable encryption and authentication?
I'd like to measure the performance without both and only found the option to disable encryption (NULL cipher suites).
Best regards
hstr
I've made some progress with the client:
The "-342" error was caused by a lack of memory, I increased the available memory and the error was gone.
But after this a new error appeared: error -401 - "DH Key too small", this could be fixed by creating a new dh param with openssl and adding it to the server: "-dhparam dh1024.pem". (By default the server used a 512 bit param).
That wasn't the last step either because the client now got stuck at the "FIRST_REPLY_FOURTH" state. I could not really figure out why this happened.
Finally I disabled the verification with "wolfSSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0);" and the client could connected to the openssl server and sent a test message.
First of all thank you for the response.
To the wolfSSL server, why do you expect this to happen? I passed the openssl client the ca cert, so it should be able to verify the certificate of the server (server cert). Also the manual verification with the "verify" command of openssl works. (see my initial post)
To the wolfSSL client, I included the "#define WOLFSSL_STATIC_RSA" into my build but unfortunately this did not fix the error, the ssl structure still contains "-342" in the error field.
Hi,
I've encountered some problems with the verification of the included certificate. The verification does not work for me with the wolfSSL client and server.
Here is the interesting code of the server that I use:
if (wolfSSL_CTX_use_certificate_buffer(ctx, server_cert_der_2048, sizeof_server_cert_der_2048, SSL_FILETYPE_ASN1) != SSL_SUCCESS)
{
TerminateTask();
}
if (wolfSSL_CTX_use_PrivateKey_buffer(ctx, server_key_der_2048, sizeof_server_key_der_2048, SSL_FILETYPE_ASN1) != SSL_SUCCESS)
{
TerminateTask();
}If I connect to the server the following openssl messages appear:
OpenSSL> s_client -CAfile C:\certs\ca-cert.pem -state -tls1 -connect 192.168.0.21:7000
Loading 'screen' into random state - done
CONNECTED(000000E4)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 /C=US/ST=Montana/L=Bozeman/O=wolfSSL/OU=Support/CN=ww.wolfssl.com/emailAddress=info@wolfssl.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=Montana/L=Bozeman/O=wolfSSL/OU=Support/CN=ww.wolfssl.com/emailAddress=info@wolfssl.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=Montana/L=Bozeman/O=wolfSSL/OU=Support/CN=ww.wolfssl.com/emailAddress=info@wolfssl.com
verify error:num=21:unable to verify the first certificate
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
Certificate chain
0 s:/C=US/ST=Montana/L=Bozeman/O=wolfSSL/OU=Support/CN=ww.wolfssl.com/emailAddress=info@wolfssl.com
i:/C=US/ST=Montana/L=Bozeman/O=Sawtooth/OU=Consulting/CN=ww.wolfssl.com/emailAddress=info@wolfssl.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE1DCCA7ygAwIBAgIBATANBgkqhkiG9w0BAQsFADCBlDELMAkGA1UEBhMCVVMx
EDAOBgNVBAgMB01vbnRhbmExEDAOBgNVBAcMB0JvemVtYW4xETAPBgNVBAoMCFNh
d3Rvb3RoMRMwEQYDVQQLDApDb25zdWx0aW5nMRgwFgYDVQQDDA93d3cud29sZnNz
bC5jb20xHzAdBgkqhkiG9w0BCQEWEGluZm9Ad29sZnNzbC5jb20wHhcNMTUxMTIz
MTI0OTM3WhcNMTgwODE5MTI0OTM3WjCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgM
B01vbnRhbmExEDAOBgNVBAcMB0JvemVtYW4xEDAOBgNVBAoMB3dvbGZTU0wxEDAO
BgNVBAsMB1N1cHBvcnQxGDAWBgNVBAMMD3d3dy53b2xmc3NsLmNvbTEfMB0GCSqG
SIb3DQEJARYQaW5mb0B3b2xmc3NsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAMCVCOFXQfJxbbfSRUEnAWXGRa7yvCQwuJXOL07W9hyIvHyf+6hn
f/5cnFF194rKB+c1L4/hvXvAL3yrZKgX/Mpde7rgIeVyLm8uhtiVc9qsG1O5Xz/X
GQ0lT+FjY1GLC2Q/rUO4pRxcNLOuAKBjxfZ/C1loeHOmjBipAm2vwxkBLrgQ48bM
QLRpo0YzaYduxLsXpvPo3a1zvHsvIbX9ZlEMvVSz4W1fHLwjc9EJA4kU0hC5ZMMq
0KGWSrzh1Bpbx6DAwWN4D0Q3MDKWgDIjlaF3uhPSl3PiXSXJag3DOWCktLBpQkIJ
6dgIvDMgs1gip6rrxOHmYYPF0pbf2dBPrdcCAwEAAaOCATEwggEtMB0GA1UdDgQW
BBSzETLJkpiE4sn40DtuA0LKHw6OPDCByQYDVR0jBIHBMIG+gBQnjmcRdMMmHT/t
M2OzpNgdMOXo1aGBmqSBlzCBlDELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB01vbnRh
bmExEDAOBgNVBAcMB0JvemVtYW4xETAPBgNVBAoMCFNhd3Rvb3RoMRMwEQYDVQQL
DApDb25zdWx0aW5nMRgwFgYDVQQDDA93d3cud29sZnNzbC5jb20xHzAdBgkqhkiG
9w0BCQEWEGluZm9Ad29sZnNzbC5jb22CCQCmZjhJRZvcgTAMBgNVHRMEBTADAQH/
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL2xvY2FsaG9zdDoy
MjIyMjANBgkqhkiG9w0BAQsFAAOCAQEAcRePb33WEQF5rOnC+3FpawxkkcEyi5xi
crViu/jPbCff8GTWSlVPf0qLe4BbPKAxsCWSAgKcmaWODGHvtB4BLhzpnFkt724D
TfFZ5V9pZlwK5s32dCCGTPaPIoZofv5nPz0ZuGHvxaVYqCrO0yynG93IWcfnz0JC
26/+FYLJ5VP6tDdVZ0cP5ySIFKNsvl9yBV9WM6p/rC4Qkrei+cFiDDsMaZpxFRG8
N7+OIxTCsQ3fiUUe3xTolTWIJ6ir3XwjP7v+Tg7qpu71d/uquCgz+WGw0nlGpLqg
kMjnlo8n6R7QkkO7hMfzKAxBqnc5ZaoNArDgTbEXQcnw1EeH+w/wQA==
-----END CERTIFICATE-----
subject=/C=US/ST=Montana/L=Bozeman/O=wolfSSL/OU=Support/CN=www.wolfssl.com/emailAddress=info@wolfssl.com
issuer=/C=US/ST=Montana/L=Bozeman/O=Sawtooth/OU=Consulting/CN=www.wolfssl.com/emailAddress=info@wolfssl.com
---
No client certificate CA names sent
---
SSL handshake has read 1402 bytes and written 414 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
Session-ID: 641F42F3F2E0E2D976EF5B1A157CCEE96B9A3C6419D042FD1445B06BBD0EBE7B
Session-ID-ctx:
Master-Key: 9621E893DD2D92BD6172548E234A6BCA1287C8AF4AAB053CFAA813F90664AE4F3B227FD622B1D482399B830774B8CE49
Key-Arg : None
Start Time: 1463118929
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
---After this messages the connection works, that means I can send and receive messages through it. It seems like openssl does not abort when the certificate could not be verified. Anyway I wonder why the verification does not work. A strange thing that I noticed is also the fact that the following command works: "OpenSSL> verify -CAfile C:\certs\ca-cert.pem C:\certs\server-cert.pem", the result is "C:\certs\ca-cert.pem: OK".
A similar behavior appears at the client, here is the interesting part of the clients code:
if (wolfSSL_CTX_load_verify_buffer(ctx, ca_cert_der_2048, sizeof_ca_cert_der_2048, SSL_FILETYPE_ASN1) != SSL_SUCCESS)
{
TerminateTask();
}When the client now connects to the openssl server the following messages appear:
OpenSSL> s_server -key C:\certs\server-key.pem -cert C:\certs\server-cert.pem -state -tls1 -accept 4444
Loading 'screen' into random state - done
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
bad gethostbyaddr
SSL_accept:before/accept initialization
SSL_accept:SSLv3 read client hello A
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write key exchange A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL3 alert read:fatal:bad certificate
SSL_accept:failed in SSLv3 read client certificate A
ERROR
2040:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:./ssl/s3_pkt.c:1053:SSL alert number 42
shutting down SSL
CONNECTION CLOSEDWhen debugging the client, the WOLFSSL* ssl structure contains the error field with the value "-342" - "can't decode peer key";
All the certificates were copied from "wolfssl-3.9.0\certs". I also assumed that .der and .pem files with the same name are the same cert/key just in another format. (I had to write "ww." instead of "www." in the code above because otherwise I could not submit the thread - too many links)
Any help would be appreciated, thanks.
Hi Chris,
thanks for the reply, meanwhile I managed to find the problem that caused the error.
Somehow wolfSSL_get_error only returned 0 for me, which was not possible so I decided to
debug the ssl object and saw that the error value was at -501.
That meant that the cipher suites did not match, after adding some additional suites it finally worked.
Hi,
currently I am trying to port wolfSSL to a setup consisting of ERIKA Enterprise (OSEK RTOS) and a LwIP stack.
The following settings are selected:
#define WOLFSSL_LWIP
#define SIZEOF_LONG 4
#define SIZEOF_LONG_LONG 8#define NO_WRITEV
#define NO_FILESYSTEM
#define SINGLE_THREADED
#define CHAR_BIT 8
#define TFM_NO_ASM
#define USER_TIME
//Defined in asn.c#define USE_FAST_MATH
//No realloc usage#define XMALLOC_USER
//Definition with lwip malloc:
#define XMALLOC(s, h, type) mem_malloc(s)
#define XFREE(p, h, type) mem_free(p)#define NO_DEV_RANDOM
The compilation and also the initialization work fine:
if(wolfSSL_Init() != SSL_SUCCESS)
{
TerminateTask();
}
WOLFSSL_CTX* ctx;if ( (ctx = wolfSSL_CTX_new(wolfTLSv1_server_method())) == NULL)
{
TerminateTask();
}if (wolfSSL_CTX_use_certificate_buffer(ctx, server_cert_der_2048, sizeof_server_cert_der_2048, SSL_FILETYPE_ASN1) != SSL_SUCCESS)
{
TerminateTask();
}if (wolfSSL_CTX_use_PrivateKey_buffer(ctx, server_key_der_2048, sizeof_server_key_der_2048, SSL_FILETYPE_ASN1) != SSL_SUCCESS)
{
TerminateTask();
}lSocket = lwip_socket(AF_INET, SOCK_STREAM, 0);
if (lSocket < 0) return;memset((char *)&sLocalAddr, 0, sizeof(sLocalAddr));
sLocalAddr.sin_family = AF_INET;
sLocalAddr.sin_len = sizeof(sLocalAddr);
sLocalAddr.sin_addr.s_addr = inet_addr(SENDER_IP_ADDR);
sLocalAddr.sin_port = htons(SENDER_PORT_NUM);if (lwip_bind(lSocket, (struct sockaddr *)&sLocalAddr, sizeof(sLocalAddr)) < 0) {
lwip_close(lSocket);
TerminateTask();
}if ( lwip_listen(lSocket, 5) != 0 ){
lwip_close(lSocket);
TerminateTask();
}
But when a client now connects to the TCP socket (openssl with "s_client -connect ip:port") there is an error at "wolfSSL_write", here is the code for the connection:
clientfd = lwip_accept(lSocket, (struct sockaddr*)&client_addr, (socklen_t)&addrlen);
if (clientfd>0)
{
WOLFSSL* ssl;if ( (ssl = wolfSSL_new(ctx)) == NULL)
{
TerminateTask();
}wolfSSL_set_fd(ssl, clientfd);
char data_buffer[80];
strcpy(data_buffer,"Hello World\n");
wolfSSL_write(ssl, data_buffer, sizeof("Hello World"));error = wolfSSL_get_error(ssl, 0);
wolfSSL_free(ssl);
lwip_close(clientfd);
}wolfSSL_CTX_free(ctx);
wolfSSL_Cleanup();
lwip_close(lSocket);TerminateTask();
Openssl returns the following error code: 10054.
Debuging "wolfSSL_write" results in the following trace:
wolfSSL_write -> SendData -> wolfSSL_negotiate -> wolfSSL_accept: ACCEPT_BEGIN and then ACCEPT_FINISHED_DONE which returns a SSL_FATAL_ERROR
One thing that I just observed with Wireshark is that there is a "Client Hello" sent to the server.
Openssl Log:
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
write:errno=10054
Hopefully someone can help me with that problem, thank you.
Pages 1
wolfSSL - Embedded SSL Library → Posts by hstr
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.020 seconds (96% PHP - 4% DB) with 4 queries