1 Reply by MichaelMann

(4 replies, posted in wolfCrypt)

chrisc wrote:

To answer your question about fastmath as the default, we do enable it as the default on Unix/Linux 64-bit platforms.

So why not Windows? wink

What's the best way to ensure preprocessors definitions are in sync (on Windows).  Have my application include user_settings.h?

Also, I did not run the test.c, but the wc_MakeCertReq isn't exactly the first API called in that function, so maybe things otherwise get initialized from previous APIs.  My app just has

InitCert
InitRsaKey
MakeCertReq

(which I presume is the minimum API necessary.  If there are more calls needed, please advise)

Go to forum: wolfCrypt

2 Reply by MichaelMann

(3 replies, posted in wolfSSL)

Issue still isn't fixed.  Grabbed the latest out of Github and can still reproduce the issue.

Looks like the issue is that idx is != 0, so whatever offset its modifying isn't the correct one.

Go to forum: wolfSSL

3 Topic by MichaelMann

(4 replies, posted in wolfCrypt)

I'm trying to create a certificate request and started with trying to copy/paste out of test.c (like the manual says).

I have the cert and key initialized with InitCert and InitRsaKey respectively.

Then I call MakeCertReq and it goes into an infinite loop.  Further investigation puts the problem in SetRsaPublicKey where mp_leading_bit is called (and never returns).  It appears the issue is that the mp_int members of the RsaKey structure aren't initialized completely if USE_FAST_MATH isn't defined. mp_leading_bit uses the whole mp_int structure to find the leading bit and InitRsaKey doesn't do that if USE_FAST_MATH isn't defined.

USE_FAST_MATH seems to be a good "default" option to have on (larger) platforms that can handle it (like Windows).  I'm using Windows (for now), so I'm surprised USE_FAST_MATH isn't on by default.  Am I missing something?  Do I have "include header" issues like https://www.wolfssl.com/forums/topic817 … hing.html?

Go to forum: wolfCrypt

4 Topic by MichaelMann

(3 replies, posted in wolfSSL)

I am writing an application that using TLS and DTLS.  I set it up to use DTLS v1.2 via wolfDTLSv1_2_client_method().  For testing purposes (in house), I created both a client and server side for the application and also tested it against the sample client and server test apps provided in WolfSSL (verifying handshake since application layer is obviously different).  All looked good.

Then I set up the client side of that application to talk to server side with a different implementation of DTLS.  Communication failed.  The reason for the communication failure was that the server side was dropping the ClientHello because it contained version 1.0 in the message.

I looked through the wolfSSL library (SendClientHello), and it initially does populate the record with the correct 1.2 version, but then has the following lines of code (within SendClientHello, internal.c):

#ifdef WOLFSSL_DTLS
        if (ssl->options.dtls) {
            DtlsRecordLayerHeader* rh = (DtlsRecordLayerHeader*)output;
            rh->pvMajor = DTLS_MAJOR;
            rh->pvMinor = DTLS_MINOR;
        }
#endif /* WOLFSSL_DTLS */

which will always hardcode the version to 1.0.

I don't see how this could be anything but a bug.  Is there something I'm not configuring correctly (build option?) so that this doesn't happen?
Should I be able to safety remove those lines of code?

Go to forum: wolfSSL

5 Reply by MichaelMann

(7 replies, posted in wolfSSL)

I think this issue can be closed.  It took me awhile to realize my mistake that I was setting my "regular" socket to non-blocking, but not the "SSL" socket.
Still need to work out some other issues, but I think that was the problem here.

Go to forum: wolfSSL

6 Reply by MichaelMann

(7 replies, posted in wolfSSL)

I've already filtered out the stream in question, otherwise I wouldn't be able to see it (my network seems to have a bunch of unnecessary traffic).  It's the MAC/IP address I want to make anonymous.
I've started to dive into the code, and it definitely appears to be a problem with SERVER_HELLO_DONE case in wolfSSL_accept.  ProcessReply() returns WANT_READ, but the "error handling" won't accept any negative values.  I'm playing with it trying to be "accepting" of WANT_READ (first allow the while loop to be infinite if WANT_READ continues, maybe move on to returning and reentering with subsequent calls to ssl_accept).  I suspect there may be a few other cases where this happens (on both ssl_accept and ssl_connect)
If I get stuck or lose confidence, I'll definitely post logs (and Wireshark traces) here.  If I completely solve the problem, I'll post a patch to GitHub for review.
The toolkit has been fairly easy to work with, I'm just not that familiar with SSL to know the code I'm looking at.

Go to forum: wolfSSL

7 Reply by MichaelMann

(7 replies, posted in wolfSSL)

The SINGLE_THREADED build option didn't seem to have much of an effect.  I still get either a WANT_READ (from a "would block" error) or SOCKET_ERROR_E error that ends up aborting the state machine.

Go to forum: wolfSSL

8 Reply by MichaelMann

(7 replies, posted in wolfSSL)

I missed the SINGLE_THREADED build option, so I will certainly try that.  You are right in that the application is attempting to run "single threaded" by polling sockets (in a single thread) rather than blocking on them (creating the need for multiple threads).
The application (for "regular" sockets) uses the usually send/recv/sendto/recvfrom WITHOUT a select() call.  I noticed in your examples that when calling ssl_accept/ssl_connect it is prefixed with a select() call.  Does ssl_accept/ssl_connect REQUIRE data to be present (thus requiring the select call)?

Go to forum: wolfSSL

9 Topic by MichaelMann

(7 replies, posted in wolfSSL)

I'm trying to add wolfSSL to an existing application that uses non-blocking sockets.  Essentially I just want to wedge SSL and DTLS communications under the current application protocol.  I've been using the client and server examples (on Windows) as "known good" for the opposing side of my testing (using client.exe for testing my "server side" and server.exe for testing my "client side").  For both my client and server sides (server side is much more inconsistent), the wolfSSL library doesn't complete the negotiation required using ssl_connect or ssl_accept.
Comparing it to the example code (which I realize is intentionally simplified), I don't having a "blocking" while loop around the ssl_connect and ssl_accept calls.  They are called as part of a state machine within my application.  If I step through the ssl_connect call in the debugger, it will usually complete the negotiation, making it seem that the issue is that the ssl_connect/accept state machines can't handle "incomplete data" during certain states.
I've turned on DEBUG_WOLFSSL and can provide logs and Wireshark traces, although I would prefer to "sanitize" the Wireshark traces if they need to be posted.

Go to forum: wolfSSL