51 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

52 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

53 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

54 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

55 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

56 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

57 Reply by Scotty2541

(5 replies, posted in wolfSSL)

Thanks John,

Nope, I don't have access to the server logs.  The 'new guy' is controlling that, and I can't get access. 
I asked, and he was just looking in the IIS logs.

I don't know anything about MS FTPS server (if it's part of IIS, how it's installed, where it's configured...) so I couldn't help him by suggesting where to look.

He finally ripped it out, and installed the FileZilla server, and now it's functioning, so we are beyond that point for now. (until a customer tries to use that server for their installation)

Also, John, I have another question posted which I haven't gotten any help with.

How to control the protocols (and along the same line, how to control the ciphers... 'best practice' is to not use all 34 of the NIST ones, but reduce them to perhaps 10 or so)

https://www.wolfssl.com/forums/topic162 … erver.html

Go to forum: wolfSSL

58 Topic by Scotty2541

(10 replies, posted in wolfSSL)

Hello,
Chapter 4 of the doc gives a selection of functions which can be used to set the cipher method on the server side.

Individually, there are SSL 3, TLS 1.0, 1.1, 1.2, 1.3,   or "wolfSSLv23_server_method()"  which says the highest up to TLS 1.2

How do a add TLS 1.3 to this, so I can pick ONLY between TLS 1.1, 1.2, 1.3 ?
(I know the SSL ones are disabled by default.  But this seems to include TLS 1.0, and does NOT include TLS 1.3)

These are structure pointers, so I can't just OR them together.

Go to forum: wolfSSL

59 Reply by Scotty2541

(5 replies, posted in wolfSSL)

Now that the server is back up, here is the same communication using FileZilla that SUCCCEEDS in connecting to the server, while the WolfSSL "client hello" is unanswered.

In my original capture, is it because the cipher is not acceptable, that the server never answers?
If so, which cipher worked in FileZilla?  And how do I enable that in WolfSSL?

I've done a lot of low level development in TCP/IP (and UDP, and ICMP), but know almost nothing about the secure layer protocol travelling on the TCP channel.

Go to forum: wolfSSL

60 Reply by Scotty2541

(5 replies, posted in wolfSSL)

John,
One reason there isn't much to show is because there isn't anything happening.
The data channel socket read times out.  Then, when the app exits, the OS naturally resets the connections.

A proper connection handshake does occur on port 990, which is the control port.  You can see that on line #4.

I am not sure why the same context can connect to the control channel on port 990, but fails on the data channel, which is the port assigned by the server.  They are both the same IIS FTP server.

(Right now, my VPN is down. I'll get a FileZilla capture when connecting this server when it's back)

Go to forum: wolfSSL

61 Topic by Scotty2541

(5 replies, posted in wolfSSL)

Hello,
I am looking for some assistance with an FTPS client app I am writing.

I am having a problem, which I cannot determine if this is a client or server issue.  But here are a few key points:

- Our test server running an MS FTPS service can be connected to with the FileZilla app. 

- When I connect with a client app I am writing, the control port connects fine and communicates,

- The handshake times out only on the passive connection handshake.
    I can see it is not the TCP/IP connect call that is timing out.
    It is in fact the handshake:  "result = wolfSSL_connect(m_dataSsl);" call that times out.

- I can use both FileZilla and the client app I'm developing to connect to a customer's server.

Therefore it would be something about this test server...  And yet, the FileZilla client app connects fine.

This also tells me it is not a firewall issue, And I have to assume it's something in the way WolfSSL lib is sending the handshake.

I have attached a WireShark log.  Lines 4 and 5 are the handshake for the control connection (port 990)
Line 37 is the client sending the hello for the passive data connection, however the server never responds.

Can anyone give me a clue to figure out why the server is happy with the handshake on the control port (port 990), but doesn't like the handshake on the passive data port (port range 20001 to 21000) ?

I have already confirmed that session resumption is disabled on our server.
Any advice is appreciated.

-Scott

Go to forum: wolfSSL

62 Topic by Scotty2541

(1 replies, posted in wolfSSL)

Hello,
I am asking if I can use the C++ or even the C# library for "session reuse".

Some background:
A customer is use SFTP, that old protocol on port 990.  I don't have any control over them, so I have to deal with it.

I already have an FTPES client in C#. I adapted it for this with little problem.  It is using the MS SslStream object.

To internal testing, until I can get to the customer server, I installed FileZilla server.

I am getting a failure "450 TLS session of data connection has not resumed or the session does not match the control connection"
(This is to prevent another attacker connecting to the data port and hijacking to connection...  I actually wonder why such a requirement is not part of FTPES as well)

I can eliminate the failure by un-checking the requirement.  But I have no control over what setting the customer is using.

(Apparently there is no way to put an image into this post... :-(  )

So, I can find zero support for "session reuse in the C# SslStream object, except that Microsoft claims it already does it.  I guess it will not reuse the session if the previous one (in this case the control port) is still open.

So, in summary, my question is:
Is there a way to tell the WolfSSL library in C++ or C# that when it opens a new connection it should reuse a session?
If so, how?

-Scott

Go to forum: wolfSSL

63 Topic by Scotty2541

(1 replies, posted in wolfSSL)

Hello all,
So, I can create a CA owned by us, effectively making us a small CA.

I would like to use it to sign a certificate.  Specifically a CSR generated by Wolf, and kept inside a device.

How would I do that in Wolf?  ...programmatically.

Use Case:
A standalone device would allow the user to download and install our private CA.

Then they would generate a new cert on the fly which would store in the device and be used to allow HTTPS connections.

A server (in the standalone device) would use the certificate and the browser would verify the signing against it's CA's.

The goal is to avoid loading all CA's to the standalone device and having a business install their official certificate and keys on the device.

I hope I understand this correctly and this makes sense.

-Scott

Go to forum: wolfSSL