26 Reply by Scotty2541

(6 replies, posted in wolfSSL)

embhorn wrote:

Hi Scott,

There is some logic in SP to try and determine the type sizes. They depend on the system checking the *_MAX values. Please try adding define

    #undef ULLONG_MAX
    #define ULLONG_MAX 18446744073709551615ULL

Yeah, I was thinking of doing a hack this way, but I want to fix it properly...  It works for a C file, not for a CPP file, in the same project.

I'm going down that rat-hole too... 
It's spaghetti trying to follow all the #include <limits.h> which are all over the place,
and which have #include_next <limits.h> all over the place.

Because your sp_int.h directive to #include <limits.h> is not pulling in the header that it's supposed to. It's pulling in one that is not in any -I path.

No idea how THAT is happening in the TI SYSBIOS world using the linaro compiler...  Wasted a day already trying to figure out how it's been broken.

Go to forum: wolfSSL

27 Reply by Scotty2541

(6 replies, posted in wolfSSL)

embhorn wrote:

Hi Scott,

Does the source file include `wolfssl/wolfcrypt/settings.h`?

Yes.  I've been going down these rabbit hopes for days...

Now, here's the latest:
I MODIFED your "sp_int.h" files at line 104 as follows:

#ifdef ULLONG_MAX
    #warning "It IS defined"
#else
    #warning "It IS NOT defined"
#endif


#if ULLONG_MAX == 18446744073709551615ULL
    #define SP_ULLONG_BITS    64

    #if SP_ULLONG_BITS > SP_ULONG_BITS
    ...

And guess what...?
When I compile a "C" files, I get:

C:/.../projects/WolfSSL-4-7/Wolf/wolfssl/wolfcrypt/sp_int.h:106:3: warning: #warning "It IS defined" [-Wcpp]
  #warning "It IS defined"

But when I compile a CPP file I get:

C:/.../projects/WolfSSL-4-7/Wolf/wolfssl/wolfcrypt/sp_int.h:108:3: warning: #warning "It IS NOT defined" [-Wcpp]
  #warning "It IS NOT defined"

Somehow, the GCC Linaro compiler that TI distributes with CCS is not finding the ULLONG_MAX

Both files simply use

#include <wolfssl/ssl.h>

Go to forum: wolfSSL

28 Topic by Scotty2541

(6 replies, posted in wolfSSL)

Hello.
I am using the TI CCS environment, the GCC compiler (linero) version 7.3

When compiling a "C" file, I get no errors.
When compiling a "CPP" file, I get the following:

In file included from C:/../projects/WolfSSL-4-7/Wolf/wolfssl/wolfcrypt/ecc.h:56:0,
                 from C:/../projects/WolfSSL-4-7/Wolf/wolfssl/openssl/ec.h:19,
                 from C:/../projects/WolfSSL-4-7/Wolf/wolfssl/openssl/evp.h:40,
                 from C:/../projects/WolfSSL-4-7/Wolf/wolfssl/openssl/hmac.h:28,
                 from C:/../projects/WolfSSL-4-7/Wolf/wolfssl/ssl.h:80,
                 from ../filename.cpp:22:
C:/../projects/WolfSSL-4-7/Wolf/wolfssl/wolfcrypt/sp_int.h:127:6: error: #error "Size of unsigned long long not detected"
     #error "Size of unsigned long long not detected"
      ^~~~~
C:/../projects/WolfSSL-4-7/Wolf/wolfssl/wolfcrypt/sp_int.h:236:14: error: 'sp_uint64' does not name a type; did you mean 'sp_uint32'?
     typedef  sp_uint64  sp_int_word;
              ^~~~~~~~~
              sp_uint32
C:/../projects/WolfSSL-4-7/Wolf/wolfssl/wolfcrypt/sp_int.h:237:15: error: 'sp_int64' does not name a type; did you mean 'sp_int32'?
     typedef   sp_int64  sp_int_sword;
               ^~~~~~~~
               sp_int32

Among all the other settings I have in "user_settings.h" there are these:

#define OPENSSL_EXTRA        /*   */
    #define NO_64BIT

    #define SIZEOF_LONG_LONG 8
    #define NO_ERROR_STRINGS
    #define FP_MAX_BITS 8192        /*  Increase for 4096 bit key */
    #define HAVE_ECC
    #define HAVE_ALPN
    #define USE_WOLF_STRTOK /* use with HAVE_ALPN */

If the compiler doesn't know what a type sp_int64 is, and the #define NO_64BIT doesn't solve it, what is the solution?

Go to forum: wolfSSL

29 Reply by Scotty2541

(3 replies, posted in wolfSSL)

David,
Thanks but no change.

Actually it made it worse.  See comments associated with my definitions:

//  Speed up tests
#define WOLFSSL_SP_DH
#define WOLFSSL_HAVE_SP_ECC
#define WOLFSSL_SP_4096                <--  Enabled this, but (with the ones below turned off)  still 18 seconds.
//#define WOLFSSL_HAVE_SP_RSA          <--  I enabled these, and it SLOWED to over 20 seconds.  The browser times out and actually NEVER connected
//#define WOLFSSL_HAVE_SP_DH           <--
// #define WOLFSSL_SP_ARM_THUMB_ASM    <--   the TI compiler doesn't like the inline assembler.


//  New settings, trying to get client to connect
#define    WOLFSSL_AES_256
#define RSA_LOW_MEM
#define WOLFSSL_SHA384
#define WOLFSSL_SHA512

Code size is not really an issue.

Any other ideas?

Go to forum: wolfSSL

30 Topic by Scotty2541

(3 replies, posted in wolfSSL)

Hello,
I am using version 4.7 in a TI SYSBIOS RTOS environment, running on an A8 am335x MCU.

A TCP/IP socket server is running in the device. I am connecting to it with a chrome browser.

The server in the ARM device has self signed certificates.  So naturally the browser gives a prompt and warning.

When using a 2048 bit cert key, the page appears within 1/2 second.

When using a 4096 bit key, it takes 18 seconds.  (Actually it take more because apparently, the browser is failing and reconnecting...  so it is really 38 seconds).

It is even sucking all the MCU time from the TI RTOS tasks, as nothing else runs while it is doing whatever this math is.

I have tried many of these settings in this thread, https://www.wolfssl.com/forums/post5516.html#p5516
however nothing budges.

Currently, the settings I have defined are:

#define USE_FAST_MATH
#define ALT_ECC_SIZE

#define OPENSSL_EXTRA        /*   */

//  From the "settings.h"
    #define FP_MAX_BITS 8192        /*  Increase for 4096 bit key */
    #define USE_CERT_BUFFERS_2048
    #define USE_CERT_BUFFERS_4096
    #define HAVE_ECC
    #define HAVE_ALPN
    #define USE_WOLF_STRTOK /* use with HAVE_ALPN */
    #define HAVE_TLS_EXTENSIONS
    #define HAVE_AESGCM

//  Speed up tests
#define WOLFSSL_SP_DH
#define WOLFSSL_HAVE_SP_ECC


//  New settings, trying to get client to connect
#define    WOLFSSL_AES_256
#define RSA_LOW_MEM
#define WOLFSSL_SHA384
#define WOLFSSL_SHA512

#define NO_PSK
#define HAVE_AESGCM
#define ECC_USER_CURVES
#define ECC_SHAMIR
#define WOLFSSL_RIPEMD
#define HAVE_EXTENDED_MASTER

I also have wireshark traces for both certificates (2048 = okay, 4096 = SLOW). They are zipped and attached.
(IP ...93 is the server, IP ...111 is my browser laptop connecting to it)

Any advice appreciated.

-Scott

Go to forum: wolfSSL

31 Reply by Scotty2541

(4 replies, posted in wolfSSL)

The debug log functions are defined out as nothing.  But I could add my out UART functions to them, and rebuild.

That's what I did and started digging.

But in the end, you are correct. It was the stack size. 
TI uses three different places that control different stack sizes.
Ultimately I got it working with a stack of 32K.

(It also helps to actually put an "0x" in front of them.  Otherwise it uses the decimal value, which is substantially smaller - Opps)

Working now.  Thanks for the clues.

Go to forum: wolfSSL

32 Reply by Scotty2541

(4 replies, posted in wolfSSL)

David,
Thanks.

When I looked into the header, all is has is this:

    WOLFSSL_API int wolfSSL_CTX_load_verify_buffer_ex(WOLFSSL_CTX*,
                                               const unsigned char*, long, int,
                                               int, word32);
    WOLFSSL_API int wolfSSL_CTX_load_verify_buffer(WOLFSSL_CTX*,
                                               const unsigned char*, long, int);

Not very intuitive.  Nor is it enjoyable to dig through the actual source code trying to find the actual function.

I managed to find the flag definitions from a ChangeLog post.

Solved now.

-Scott

Go to forum: wolfSSL

33 Topic by Scotty2541

(4 replies, posted in wolfSSL)

Hello,
I am trying to find doc on wolfSSL_CTX_load_verify_buffer_ex(...).

It doesn't exists ANYWHERE.  I've spend 30 minutes digging and searching, there isn't anything.

Every search takes me to stuff about version 4.2....

The prototype has TWO extra arguments compared to wolfSSL_CTX_load_verify_buffer(...)

One would think there should be only one, to handle the three option flags... But there are two.

And nothing is documented to explain anything.  It's all just Doxygen generated stuff, which should be outlawed for it's lack of usefulness.

Go to forum: wolfSSL

34 Reply by Scotty2541

(4 replies, posted in wolfSSL)

embhorn,

That didn't work...

I tried NOT loading the roots CA's (only two of them), but it still crashes.  (they actually fail anyway, due to the clock not being set...  That's another issue, how does WolfSSL get the date n the TI embedded system??)

The CA's are only connecting to a cert that is 2048 bit.

I set the 

#define RSA_LOW_MEM

  but it still crashes.

I increased the stack size from 65536 to 98304  (that 1 1/2 times 0x10000 ), but it still crashes.

It appears something is wandering off the reservation and destroying memory that doesn't belong to it.  Because the TI NDK memory is getting screwed with.

This all works fine when I client connect to IIS WITHOUT using SSL.

And our server component (not yet integrated in this test app I'm working on) supports public 4096 keys without setting the #define or increasing the stack from the 65536 we currently use.  So I think we have enough memory for these smaller Pub/Priv keys.

Go to forum: wolfSSL

35 Topic by Scotty2541

(4 replies, posted in wolfSSL)

Hello.

I am trying to get a client connection to an IIS server. It all works fine in Windows, using a typical TCP connection, linked to a WolfSSL library built with the VS solution file as is from release 4.7.0.

It refuses to work in TI RTOS ARM.  I am coding for the am335x, TI Compiler 17.3, SYSBIOS 6.46

I've been dealing with this for a week, and not getting anywhere.  I've even had to step down into the WolfSSL code trying to debug it.

After MANY REPEATED rebuilds and attempts, I have narrowed it down to enabling:

#define WOLFSSL_SHA384
#define WOLFSSL_SHA512

Simply put:  with those defined, it CRASHES in ecc.c, line 2374 in the function 

err = mp_invmod_mont_ct(z, modulus, t1, mp);

I have not dug any deeper than that into the WOLFSSL code.

Alternately, if I do NOT define those directives, it simply returns from the call to 

 result = SSL_connect(m_ssl);

with a code -308  (socket in error condition) which is the result of the server disconnecting on the first Client Hello message.

I keep dragging settings from the Windows build to the TI ARM build to see when it will start working.  All it does is crash with those settings defined.

I've tried to read the doc in order to figure out what #defines need to be defined, with no avail.  There is nothing that tells me "You must enable X if you enable "Y" or it'll crash hard.

The current setting I have defined in "user_settings.h" are:

#define OPENSSL_EXTRA        /*   */

//  From the "settings.h"
    #define FP_MAX_BITS 8192        /*  Increase for 4096 bit key */
    #define USE_CERT_BUFFERS_2048
    #define HAVE_ECC
    #define HAVE_ALPN
    #define USE_WOLF_STRTOK /* use with HAVE_ALPN */
    #define HAVE_TLS_EXTENSIONS
    #define HAVE_AESGCM

//  New settings, trying to get client to connect
#define    WOLFSSL_AES_256
//#define WOLFSSL_SHA384
//#define WOLFSSL_SHA512

#define NO_PSK
#define HAVE_AESGCM
#define ECC_USER_CURVES
#define ECC_SHAMIR
#define WOLFSSL_RIPEMD
#define HAVE_EXTENDED_MASTER

This is the crash from the ARM.  The DFSR shows an access issue, and the DFAR shows address 0

[CortxA8]  0x805dd620  R8  = 0x805d6458
R1 = 0x00000000  R9  = 0x805d6614
R2 = 0x805d661e  R10 = 0x00000e3a
R3 = 0x00000000  R11 = 0x00000000
R4 = 0x00000000  R12 = 0x00000000
R5 = 0x00000000  SP(R13) = 0x805b26e0
R6 = 0x00000001  LR(R14) = 0x804bf1ac
R7 = 0x805dd644  PC(R15) = 0x805b26e0
PSR = 0x00000001
DFSR = 0x00000005  IFSR = 0x00000000
DFAR = 0x00000000  IFAR = 0x00000000
ti.sysbios.family.arm.exc.Exception: line 205: E_dataAbort: pc = 0x805b26e0, lr = 0x804bf1ac.
xdc.runtime.Error.raise: terminating execution

Can anyone clue me in to which of these settings are required to make it simply connect to a IIS server?

-Scott

Go to forum: wolfSSL

36 Reply by Scotty2541

(4 replies, posted in wolfSSL)

Hi...

"Project" is not clear.  The library is a project.  It's your project, as I didn't write it.
My application is a project.  I assume when your instructions write "your project", it means mine.

So I copied a bunch of the setting that were in the windows user_settings.h to the one in the ARM user_settings.h, and defined WOLFSSL_USER_SETTINGS in BOTH my app, and the library.

Well, that didn't work.  It used to disconnect due to the server hanging up on the client hello...

Now it craters hard on SSL_connect(...) in the following code.

   m_socket = ConnectToHost(m_host,m_port);
    if (m_socket == (int) INVALID_SOCKET) {
        return false;
    }
    if (m_useSsl == 0) {
        return true;
    }
    m_ssl = SSL_new(m_ctx);

    UARTprintf("Setting the socket FD %x to the SSL\n", m_socket);
    result = SSL_set_fd(m_ssl,m_socket);
    if (result < 0) {
        UARTprintf("Failed to set the socket: %d\n", result);
        return false;
    }
    UARTprintf("Triggering a SSL handshake %x\n", m_socket);
    result = SSL_connect(m_ssl);
    if (result <= 0) {        //  BAD_FUNC_ARG
        UARTprintf("Failed to negotiate an SSL connection: %d\n", SSL_get_error(m_ssl,0));
        return false;
    }
    UARTprintf("Verifying the certificate\n");
    success = VerifyCertificate();

It does NOT crater, and works fine for ALL the communication when not using SSL.

Nothing I (dis) like better than stepping through other peoples code when I know nothing about it, and can't find any doc on the dozens and dozens of #defines that control how it's built...

Scott

Go to forum: wolfSSL

37 Reply by Scotty2541

(4 replies, posted in wolfSSL)

1.  One hour of writing a reply DOWN THE DRAIN, because this didn't autosave...  Here I go again. (GRRRRR)
(1.a  IT DID IT AGAIN!  Lucky for me I'm smart enough to learn NOT to trust this site...  I copied it before I hit post and lost everything. )

2.  Why is this NOT sending me notifications that a reply was posted??

3.  On to the problem,
I am using TIROTS, so I defined it in the settings.h

I am NOT using any configure build tool.  (Most nothing works right in these environments anyway, and usually requires a bloat-load of other freeware tools installed to make the scripts work).

I brought in the source, and built it in a TI CCS project.

All I need to do is provide the definitions to include the cipher suites that allow this to connect as an SSL client to a server, typically an IIS server.  It works in the Windows build, but not in the ARM TIRTOS build.

So I am fumbling around in the dark of lacking doc trying to figure out how to enable the suites.  Probably need to enable most of them to accommodate a wide variety of potential servers that will have to be connected to.

And yet...
https://www.wolfssl.com/docs/frequently … r_wolfSSL?
Tells me to put all the settings in "user_settings.h" and define WOLFSSL_USER_SETTINGS in the APPLCATION...

If I DON"T define it in the library how does it get those #defines into the lib?  They are already defined in the application, aren't they needed?
And those settings...
Are they supposed to be mimicked between "settings.h" and "user_settings.h" ?  Because they are in both...

The examples in IDE/GCC-ARM/Headers/user_settings.h have #defines that are redundant to the ones in sections of "settings.h"  (TIRTOS, FREERTOS, ARDUINO, etc...)
If I #define one of those systems in "user_settings.h" should they be removed from "settings.h"?
What if they conflict?  What if I don't want one, but it's defined in the other??

Of course... Windows build doesn't have ANYTHING from the "settings.h"  And gets everything from it's "user_settings.h".

I have already created a SSL Server in this ARM TIRTOS environment and selected the limited suites using wolfSSL_CTX_set_cipher_list(...)  and that all works fine.  But now I need a client.  And something in the ARM build isn't working.

(What fun...  retyping this all over again)

-Scott

Go to forum: wolfSSL

38 Topic by Scotty2541

(4 replies, posted in wolfSSL)

Hello,
I build WolfSSL and ran a windows client test, connected to an SSL port 443 server.  All good.

Next I try to connect to the same server, with the same source code from an ARM device running TI_RTOS.
It fails with a -308  (error state on socket)

Well, something somewhere is different between the two test apps.

I ran a WireShark on the server and can see that the server is disconnecting after the ClientHello.

I can also see that the windows build has 51 cipher suites in it's offering, which the ARM build only has 18.

How am I supposed to determine:
1. What the reason is the server is rejecting the client hello?
2. How/Where to add any needed missing cipher suites to the Wolf build?

Go to forum: wolfSSL

39 Reply by Scotty2541

(4 replies, posted in wolfSSL)

No, that just breaks more stuff...

I had to FABRICATE some of the identifiers which were needed from <sys/un.h>

Because TI NDK doesn't have a "socket" in a reasonable location ( including it generates even MORE conflicts with WOLF headers because WOLF seems to think it has to provide definitions for things that are already there)

So I also had to #define socket(a,b,c)  ( (int) NDK_socket(a,b,c) )

Go to forum: wolfSSL

40 Reply by Scotty2541

(4 replies, posted in wolfSSL)

No, I have no idea what that is.

I don't use GIT, and don't run DIFF in my Windows environment...  Please don't assume your environment is a standard, used by everyone in the world.

if "-31736   +31736"  is supposed to be a line number is src/ssl.c  then it's smack in the middle of the "SetDhInternal()" function.  And sure to break my source.  And 700 lines away from what I was referring to.

Go to forum: wolfSSL

41 Topic by Scotty2541

(4 replies, posted in wolfSSL)

Hey Kaleb, (or anyone else...)

In the TI_RTOS world, using CCS,  I am trying to load an X509 cert just to examine it.  Logically the functions are:

wolfSSL_X509_load_certificate_buffer()
wolfSSL_X509_get_subject_name()
wolfSSL_X509_NAME_get_entry()

etc...
Except these were unresolved at the linker stage.

So the next logical step was to see what needs to be defined:

#if defined(OPENSSL_EXTRA_X509_SMALL) || defined(KEEP_PEER_CERT) || \
    defined(SESSION_CERTS)

wolfSSL_X509_get_subject_name(  X509)

Okay, so I need OPENSSL_EXTRA_X509_SMALL

But

#if defined(OPENSSL_EXTRA) || defined(WOLFSSL_WPAS_SMALL) || \
    defined(KEEP_PEER_CERT) || defined(SESSION_CERTS)

WOLFSSL_X509* wolfSSL_X509_load_certificate_buffer(...)

This needs OPENSSL_EXTRA

So that looks weird...  You define OPENSSL_EXTRA_X509_SMALL to get the subject name from an X509...  But you can't load an X509 unless you define OPENSSL_EXTRA ??

But that's not what is broken...

In Wolf/src/ssl.c : Line 310087  (in version 4-7)  

/* These constant values are protocol values made by egd */
#if defined(USE_WOLFSSL_IO) && !defined(USE_WINDOWS_API)
    #define WOLFSSL_EGD_NBLOCK 0x01
    #include <sys/un.h>
#endif

Well, TI/CCS has never heard of the header file "un.h".  It's not included in any of the NDK 2-25 or 3-61.  Nor is it in any of the TI compilers, or the GNU compilers they package with CCS.

What am I supposed to do?  I can't comment it out, as there are several functions that use the sockaddr_un structure which is unheard of.  I imagine (but haven't tried) if I try to take that header from from a unix/linux environment, there will be additional conflict and missing declarations.

So as it stands now, the X509 functions can't be used in TI-RTOS because the library wants to include support for Unix local interprocess functions (which are not used in TI_RTOS)

Any suggestions?

Go to forum: wolfSSL

42 Reply by Scotty2541

(2 replies, posted in wolfSSL)

Thanks.
I will keep the #ifdef solution because we like to have all the original code packaged together.   Not delete pieces...  It makes more work to remember all those things when integrating the next update.

As to my other question:

Are those ciphers in that folder supported in another way?  Or do I have to enable one of those files (*.c or *.S) to get those ciphers built and included?

I know I can set the ciphers with:

wolfSSL_CTX_set_cipher_list(ctx, cipherList);

But what if all those ciphers are not compiled in?

I'm only learning to navigate the complexities of SSL, so I don't know.

Go to forum: wolfSSL

43 Topic by Scotty2541

(2 replies, posted in wolfSSL)

Hello,
I have built the WolfSSL as a standalone static library inside CCS, using the TI compiler.

Now I have a bunch of problems trying to do this in CCS with the GNU compiler.

I have a couple of questions regarding what I discovered at the end of this post.

In my opinion, CCS is a trainwreck, and TI is usually of little help.
A lot of this is coming from the *.S files in folder WolfSSL-4-5\Wolf\wolfcrypt\src\port   (root folder is my naming)

And it's because a couple of source files (like "armv8-curve25519.s")  have #includes in it, where most others don't

I compile armv8-curve25519.c  and get 1000's of errors. I can't even see the original command line, since it scrolls off the output so fast...

1.  It shouldn't compile anything because #ifdef WOLFSSL_ARMASM is NOT defined anywhere I can find.  But CCS has a nasty habit of dragging in stuff I don't want, hiding the way things are defined, etc...  So I had to try it another way.

Since the editor highlight is not showing me if #defines are actually defined, I did the following to one of the source files:

#ifdef WOLFSSL_ARMASM
#error  THIS IS ENABLED

This compiled...  But 

#error  THIS IS ENABLED
#ifdef WOLFSSL_ARMASM

Gave me the expected error.

So I can tell that WOLFSSL_ARMASM is NOT defined which helps give me a clue for more digging...

2. Next I discover that CCS has decided that it wants to compile the ASSEMBLER FILE armv8-curve25519.S even when I tell it not to. 
I right click on the *.c file, select 'build selected file', but it still compiles the *.S file.
I right click on the *.S file and EXCLUDE IT, but CCS still compiles the *.S file for the *.c file.

(did I say trainweck? I am being polite)

Anyway the *.S file has at the top:

#ifdef HAVE_CONFIG_H
    #include <config.h>
#endif /* HAVE_CONFIG_H */
#include <wolfssl/wolfcrypt/settings.h>

/* Generated using (from wolfssl):
 *   cd ../scripts
 *   ruby ./sha2/sha512.rb arm64 ../wolfssl/wolfcrypt/src/port/arm/armv8-sha512-asm.S
 */
#ifdef WOLFSSL_ARMASM

And the "wolfssl/wolfcrypt/settings.h" file then drags in 

#include <ti/sysbios/hal/Seconds.h>

Which then opens the floodgates for XDC and SYSBIOS header files.

The result is that it's reading all the XDC and SYSBIOS code and trying to compile it like assembler.

My solution to work around this is the move the #ifdef to the top...

#ifdef WOLFSSL_ARMASM
#ifdef HAVE_CONFIG_H
    #include <config.h>
#endif /* HAVE_CONFIG_H */
#include <wolfssl/wolfcrypt/settings.h>

Is this a viable workaround?  I don't know why this hasn't been discovered earlier, when someone wants to compile the assembler file.

I see a problem here in that I can never get those assembler files to compile as they have those #includes which breaks the build.

And the assembler files appear to be identical to the code in the C files.  So they appear to be redundant.  It that correct?

Are those ciphers in that folder supported in another way?  Or do I have to enable one of those files (*.c or *.S) to get those ciphers built and included?

Thanks in advance for any advice.

Go to forum: wolfSSL

44 Reply by Scotty2541

(10 replies, posted in wolfSSL)

Kaleb,
Thanks.  I have the server and necessary certificates already.  That is all working fine.
I can see the connection specifics in the "security" tab of Chrome or Firefox.

Just wanted to be clear on how it decided the TLS version and picking the cipher.

A client wanted to use the elliptical ciphers  (TLS_ECDHE_* ) , but neither Chrome no Firefox is showing it as being selected. 
I do have it enabled.  I suppose to verify I would need to remove all the other ones and see if it connects.

Go to forum: wolfSSL

45 Reply by Scotty2541

(10 replies, posted in wolfSSL)

Kaleb,
Thanks...

Kaleb J. Himes wrote:

Scotty2541,

The order in which they arrive does not matter. The server is configured how it is configured.

In MOST cases a server will try to pick the STRONGEST cryptographic option but some might be configured to consider run-time resource requirements or some other governing factor in the decision making process for which cipher it selects from the client offered list.

Warm Regards,

- K

In this case the server IS a WolfSSL based app...   So the server will try to negotiate that when? 
During the wolfSSL_acept() call?

   WOLFSSL*        ssl  = 0;
    WOLFSSL_CTX*    ctx    = (WOLFSSL_CTX*)sslCtx;
    int ret;
    ssl = wolfSSL_new(ctx);
    ret = wolfSSL_set_fd(ssl, socket);
    if (ret != 1)  {
        return (void *)0;
    }
    ret = wolfSSL_accept(ssl);

Or is there another call that should be made to tell it to do so?
Or is it automatic?

-Scott

Go to forum: wolfSSL

46 Reply by Scotty2541

(10 replies, posted in wolfSSL)

john wrote:

The API to look out for is wolfSSL_CTX_set_cipher_list(). You call this once on the WOLFSSL_CTX, and all WOLFSSL sessions made with that CTX will have the preset list. If you only want to use ECDSA-AES256-GCM-SHA384, call it

ret = wolfSSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-AES256-GCM-SHA384");

Only that suite will be requested by the client to the server.

I think the following defines in user_settings.h will get you TLSv1.3 with support for the above cipher suite.

#define WOLFSSL_TLS13
#define HAVE_TLS_EXTENSIONS
#define HAVE_SUPPORTED_CURVES
#define HAVE_HKDF
/* #define WC_RSA_PSS - not needed if only using ECC */
/* #define HAVE_FFDHE_2048 - not needed if only using ECC */

If TLSv1.3 is enabled, wolfSSLv23_client_method() will try to negotiate for TLSv1.3 and allow downgrades. (It looks like the manual needs an update.)

John,
Apparently the answer is 'yes'.  Feed the function 'wolfSSL_CTX_set_cipher_list(...) a list that is colon separated.
Question:
For setting up a server, and telling the API which ciphers to use...
Is this any priority?  Or does the client have total control over which one is preferred and will be used?

For example, given this list (which I read from the API), after commenting out some, does it make any difference what order they are?  (I don't even know what they all are or which are stronger...  I still need to research that)

const char cipherList[768] =
        "TLS13-AES128-GCM-SHA256:"
        "TLS13-AES256-GCM-SHA384:"
//        "DHE-RSA-AES128-SHA:"
//        "DHE-RSA-AES256-SHA:"
//        "DHE-PSK-AES256-GCM-SHA384:"
//        "DHE-PSK-AES128-GCM-SHA256:"
        "DHE-PSK-AES256-CBC-SHA384:"
        "DHE-PSK-AES128-CBC-SHA256:"
        "ECDHE-RSA-AES128-SHA:"
        "ECDHE-RSA-AES256-SHA:"
        "ECDHE-ECDSA-AES128-SHA:"
        "ECDHE-ECDSA-AES256-SHA:"
        "ECDHE-RSA-RC4-SHA:"
        "ECDHE-ECDSA-RC4-SHA:"
//        "DHE-RSA-AES128-SHA256:"
        "DHE-RSA-AES256-SHA256:"
//        "DHE-RSA-AES128-GCM-SHA256:"
        "DHE-RSA-AES256-GCM-SHA384:"
//        "ECDHE-RSA-AES128-GCM-SHA256:"
        "ECDHE-RSA-AES256-GCM-SHA384:"
        "ECDHE-ECDSA-AES128-GCM-SHA256:"
        "ECDHE-ECDSA-AES256-GCM-SHA384:"
//        "ECDHE-RSA-AES128-SHA256:"
        "ECDHE-ECDSA-AES128-SHA256:"
        "ECDHE-RSA-AES256-SHA384:"
        "ECDHE-ECDSA-AES256-SHA384:"
        "ECDHE-PSK-AES128-CBC-SHA256";

Go to forum: wolfSSL

47 Reply by Scotty2541

(10 replies, posted in wolfSSL)

John,
I examined the "wolfSSL_get_ciphers()" version of that call, and inspected the output (it doesn't describe how that data is returned in the buffer... yet something else that could be updated in the doc)

They are, in fact, a list of all those cipher names, separated by colons.

So, that "set" version of the call sets only one of them. What if I want to set about 10 or 12?
Do I feed it a list like it's partner call returns?

Go to forum: wolfSSL

48 Reply by Scotty2541

(2 replies, posted in wolfSSL)

Okay.  At line 1317 I see that is does import the TI_RTOS SysBios mutex  (not POSIX).

So I figure it is handling multi threaded cleanly in this case.

Thanks.

Go to forum: wolfSSL

49 Topic by Scotty2541

(2 replies, posted in wolfSSL)

Hello,
Yes, I know what Single Threaded is...

But what does it do in this case?  The doc says it's only used for a session cache.   Assuming the doc is still correct in this case.
Where is that mutex defined?

Reason:  I was given a tutorial (very old) that indicated it was using pthreads...   I am building for TI_RTOS (SysBios) and using tasks.
TI's SysBios tasks and mutexes are nothing like POSIX.

And we are using tasks, so it is "multi-threaded".

So if I turn on SINGLE_THREADED, what damage could it cause?  Or will it properly use atomic mutexes compatible with SysBios if I turn SINGLE_THREADED off?

Go to forum: wolfSSL

50 Reply by Scotty2541

(10 replies, posted in wolfSSL)

David,

I am not using the --{configure} options, as I am building this for AM335x (sitara).
So I have no idea how WOLFSSL_TLS13 should be enabled...  should I just define it in the user_settings.h?

As for WOLFSSL_ALLOW_TLSV10  (and WOLFSSL_ALLOW_SSLV3)...

The CCS environment has a nice highlight that shows if #defines are set... It is showing me that all the code IS ENABLED... and yet I can find nothing that indicates it is defined.

So right now, I *think*  TLS1.0 is enabled, but I have no way to prove it.
Nor do I have any indication of HOW it's being enabled, so I don't know where to go to disabled it.

(I did define NO_OLD_TLS in the user_settings.h )

Next up:  (Should I start a new question?)  How to select ciphers?
The NIST lists 34 approved ciphers.  The SSL.COM best practices it to only enable 'some' of them to minimize exposure.  How are they enabled/disabled?
For example, the first 1000 lines of "internal.h" have all of them listed...  do I just comment out the ones that I want to remove, and insure that the ones I want are enabled? 
(I want  ECDSA_WITH_AES_256_GCM_SHA384 , but I might want to remove BUILD_TLS_RSA_WITH_AES_128_CBC_SHA )

Go to forum: wolfSSL