You are not logged in. Please login or register.
Active topics Unanswered topics
Welcome to the wolfSSL Forums!
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
References
Stable Releases - download stable product releases.
Development Branch - latest development branch on GitHub.
wolfSSL Manual - wolfSSL (formerly CyaSSL) product manual and API reference.
Search options (Page 3 of 6)
Remove "--enable-sniffer" from your configure and this command line test should work. (Also remove "--enable-sctp", it is only needed if you are using DTLS over SCTP.) The sniffer allows you to build an application that provides packet decoding in a fashion similar to Wireshark. It only works if you are using RSA key exchange.
Can you connect to the server using the wolfSSL example client? What I usually do for interop testing is:
Shell 1:
~/Code/wolfssl$ openssl s_server -accept 11111 -cert ./certs/server-ecc.pem -key ./certs/ecc-key.pem -dtls1
Shell 2:
~/Code/wolfssl$ ./examples/client/client -u -A ./certs/ca-ecc-cert.pem -v2
The server will show "hello wolfssl!" in shell 1. If you type something and press enter that text will show up on the client in shell 2.
There is an issue with time on platforms without 64-bit values. We added the guard TIME_T_NOT_LONG to work around that. On the configure command line add CPPFLAGS=-DTIME_T_NOT_LONG or #define it in your settings file.
The testsuite.test works on your Mac (along with the other test utilities). That's good to hear. I'm using a Mac as well.
You say the testsuite.test fails on your Arm board. I looked at the log you attached and there is an failure where we generate a date, covert it to a string, and compare it to an expected value. In file tests/api.c line 10685, could you output the value of the string "date_str"?
In your first post you listed your wolfSSL configure command. Is that what you are using on the ARM board or on your Mac? Is the ARM you are using 32-bit or 64-bit?
Olle:
Which version of wolfSSL are you using? Is it v3.13.0?
Digging into your capture files a couple things catch my interest. In dump.pcap, you have two client hello messages. The second one isn't a retransmission. It is the second client hello. It should only come in response to a hello verify request from the server, which your server doesn't send, and should be longer than the initial hello. I'd like to know why the client is doing that. I'm going to look at that some more. But, I'm not quite seeing that behavior here. My second client hello comes through as expected.
In your case, the client should NOT send a second hello message as your server isn't sending the hello verify request message. The server alert is due to it receiving two separate client hello messages with separate handshake message sequence numbers, and not expecting the second one because it didn't send the hello verify request.
Do you know why the server isn't sending the hello verify request? Is that an option you disabled? I'm going to try to hack my server so it doesn't send the hello verify request message. The client should be able to handle not getting it. (The client is required to respond to the message, but the server is not required to send it.)
--John
Marco Wenzel wrote:That is right. The server calls wolfSSH_stram_send() many times in order to send a huge amount of data, but without calling wolfSSH_stream_read() in between. But the fact is, that when it calls wolfSSH_stream_read() between all these send calls, it expects some data from the client. When the client is not sending any data except the window adjustment message, wolfSSH_stream_read() does not return and any following operation is blocked.
So what do you suggest to do in this case?
Are you using blocking or non-blocking sockets?
The example echoserver is using blocking sockets. The client drives the echoserver's behavior. You should use non-blocking sockets. The call to wolfSSH_stream_read() should return a WS_WANT_READ error if there isn't data available on the socket.
As far as the DoChannelRequest() issue, I agree with you on the solution to the problem. I'm adding this to my list.
It looks like your server is sending data to the client and never stopping to receive messages from the client. You need to call wolfSSH_stream_read() once in a while as it processes the background bookkeeping messages like Channel Adjust Window.
Could you enable debugging and see if DoChannelWindowAdjust() is called? It should report what the peer wants to add back to the window, the current peerWindowSz and the updated peerWindowSz.
The logging will produce a lot of noisy output. Could you send the log to me directly?
That is already on my list of tasks for next week.
And you are using commit 87eb3ad from the GitHub repository?
Marco:
The peerWindowSz value is increased when the peer sends a Channel Window Adjust message. Which client are you using, it sounds to me like it is misbehaving.
--John
Correct, you only need the root CA. The other intermediate signers should be in the certificate chain with the peer certificate.
For OCSP stapling, the client should be getting the OCSP response record, signed by the root CA (or its delegate), during the handshake. The OCSP response should be for the server's certificate. (And the response should be the same blob of data you would get if you requested the status directly from the OCSP service listed in the peer's certificate.)
Which version of wolfSSL are you using? Have you captured the exchange with Wireshark?
You'll need to supply a custom verify callback function. The verify callback is passed the error type and it gives you a chance to force a success or failure depending. See our API manual for the functions wolfSSL_set_verify() or wolfSSL_CTX_set_verify().
Which version of wolfSSL are you using?
This was due to a misreading of RFC 6347 section 4.2.2. This has been recently fixed in our GitHub repository, commit 6d520e0.
wolfSSL as Server
What I meant is that the OpenSSL s_client processes the certificates, but doesn't fail the connect if the certificate isn't good. It is printing the result
Verify return code: 21 (unable to verify the first certificate)
but not erroring out. Our example code fails the connect() or accept().
It looks like the certificates in cert_test.h are not the same as the certificates in the certs directory. I get different behavior between using the code version of the server certificate and the one in the directory. I see errors in OpenSSL like you do when I use the array version. The file version verifies as OK. (Note, the array version of the CA certificate will verify the array version of the server certificate.)
I have logged an issue into our GitHub issue tracker for updating the certs_test.h file.
wolfSSL as Client
Do you have a Wireshark capture of this transaction? Also, which options are you configuring with? This might be related to the issue above, as well, with the incorrect certificates.
For the first case with the wolfSSL based server and OpenSSL s_client, this is exactly what I expect to happen. The OpenSSL client is telling you that it doesn't like the certificate the server gave it, but since it is a test client it continues with the connection. Note the verify errors:
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
As to the second case with the wolfSSL based client and OpenSSL s_server: According to Note 1 in our README file, "wolfSSL also no longer supports static key cipher suites with PSK, RSA, or ECDH." In your example, you are using the cipher suite AES128-SHA, which is a static RSA cipher suite. To get it to work you need to "#define WOLFSSL_STATIC_RSA" in your build.
1. It is calling AesGcmDecrypt_fips only when FIPS mode is enabled. We do not provide the implementation of any of the _fips() functions in the open source download.
2. You are encrypting 24 bytes of plaintext and storing the 24 bytes of cipher text into a 32 byte array and then are decrypting the 32 byte array. The first thing the decrypt function does is calculate and checks the authTag, which is failing with error -180.
Billy Bob:
In your callback for pcap_loop() are you accounting for the size of the ethernet header?
Our sniffer test code main function we have a variable called frame. It is normally set to 14, which is the size of the Ethernet frame header. (Or 4 if using a no-link interface.) The first thing that happens after receiving a packet from pcap_next() is the test adjusts the packet pointer past the ethernet frame header to the IP header (and adjusts the packet size accordingly) and then calls ssl_DecodePacket().
If the header isn't skipped, then the IP version number will be wrong as it is looking at part of the ethernet hardware address.
Billy Bob:
It kind of looks like the filter isn't working on the PCAP loop. Since it is working with pcap_next(). The sniffer is assuming that the data passed to it starts with the IP frame, not with any link local headers.
Can I ask about your project? How are you using the sniffer?
--John
Which CA certificate are you using for Google? Make sure in your CA bolus you have the "Equifax Secure Certificate Authority" CA certificate.
As for 4096-bit RSA certificates, since I'm assuming you are using fast math, you need to "#define FP_MAX_BITS 8192" in wolfSSL. By default, the max bits setting is good for doing 2048-bit RSA keys.
Deepti:
I see that you also sent in a message to support@wolfssl.com. My colleague is helping you via that message chain.
Commonly, when we see and error -188, it is because the correct CA certificate for the peer wasn't loaded. For example, you can't use our CA certificate that is included with USE_CERT_BUFFERS_2048 to contact Google's server. (And I've seen a couple different certificate chains from Google that required different CA certificates.)
You would need to create your own logging function. The easiest place to add this logging would be at the I/O callback. You can dump out the bytes as they are read or transmit from the socket.
You can also add the data dump for the send side in the function SendBuffered(). On the receive side, you could add the logging to the function ProcessReply() right below the statement "WOLFSSL_MSG("received record layer msg");" The input buffer would have the complete message at that point.
Posts found: 51 to 75 of 148
Generated in 0.022 seconds (90% PHP - 10% DB) with 4 queries