51 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

52 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

53 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

54 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

55 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

56 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

57 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