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 1 of 6)
There was a bug in the RSA verification in the client in v1.4.17. It was fixed for v1.4.18. Which version of wolfSSL are you using?
I haven't run through the change logs, but v1.4.18 is out. We made a few corrections in wolfSSHd. Have you tried that recently? We did make some fixes to terminal handling as a part of the release.
--John
We didn't make this a 100% drop in replacement for the other sshd. I'd love it to be, but they've had many more years to work on it than I have. That said, we didn't implement their entire configuration file yet either. While some variables were added to the configuration structure, wolfSSHd doesn't know how to parse them yet. There's also some parsing set up for some options, where they are just skipped. ListenAddress is one of those.
It is on my wish-list to add a wolfssh-keygen tool, but I haven't had the time to do it yet. The file keygen.c has some wrapper functions for the wolfCrypt RSA and ECDSA key generation functions. wolfSSH is able to load OpenSSH formatted unencrypted private keys. (We don't have Blowfish or bcrypt support in wolfCrypt yet. We've been focused on algorithms that can get FIPS validations.)
The wolfSSHd application is intended to be used as a server. The examples directory applications are the demonstrations for how one could use the library.
We typically add things on paid customer requests.
--John
This issue was fixed with PR #565, back in late August, 2023. This fix was included in the release of v1.4.15.
Which version of wolfSSH are you using? I'm going to assume v1.4.12, since that was released before your original post. I am seeing the WS_OVERFLOW_E error with that version. I'm going to check to see if we explicitly fixed it, or what.
I'm embarrassed. I apologize for forgetting about this and not following up.
I'm probably as surprised as you about epoll and wolfSSH misbehaving like that. I'm trying out your test program.
For SSH, you are doing a key exchange operation and generating a signature. Optionally the server is also doing a verify. Public key is expensive. I don't believe it is the hashing causing you trouble.
My recommendation would be to use ecdsa-sha2-nisp256. You are already using it. Do you have a lot of code space available? You could try using the SP math in your wolfCrypt.
Has anyone experienced a similar issue with the "heap" identifier in WolfSSH v1.4.13? If so, how was it resolved?
We did when we added Zephyr support. We set it to the correct value. That particular case you indicated should be ctx->heap. If you aren't using a custom heap with your own memory allocator functions, you could use NULL for the heap.
Could this error be related to specific configurations or dependencies required for integrating WolfSSH with FreeRTOS and lwIP (e.g., WolfSSL/WolfCrypt)?
It's happening in builds that aren't using the default memory allocators. For Linux/macOS/Windows, the WMALLOC() macro is ignoring the heap parameter. That's why I missed it.
Are there any particular user settings that should be verified or adjusted to resolve this issue?
No.
Would upgrading or downgrading WolfSSH potentially solve this problem, or are there known workarounds for this version?
This issue is fixed and will be available in the v1.4.15 release in the next few days.
--John
Which version of wolfSSH are you using? The current master branch in GitHub repo?
Whoops. I understand now. I haven't looked at the FAT filesystem that comes with FreeRTOS, but I'm looking now. It follows the pattern that Win32 uses for examining directories, not POSIX. You use ff_findfirst() and ff_findnext() to query the file system for entries in the directory table.
The directory functions are used to get directory listings. The functions that open files for reading or writing take the path string they are given and use that. I think SCP should work with NO_WOLFSSH_DIR. It isn't going affect SSH shells.
I have been working with a project that is using FreeRTOS and FatFS, and we are using the functions f_opendir(), f_readdir(), and f_closedir() found in the file ff.c. I believe that project is using release R0.14 of FatFS.
Setting the flag NO_WOLFSSH_DIR will disable the SFTP commands used to open directories and get listings. You should be able to get and put, but I don't think ls will work.
testwolverinebagel:
We don't have an example that uses epoll. Our example client is using select() in the function NonBlockSSH_connect(). Can you share with me the code you are using for your connect? You can send it to support@wolfssl.com if you don't want to post it here.
--John
The callback is written for the API you are using. wolfSSH doesn't care about the filesystem you are using. By default, the callback uses POSIX file I/O (fopen(), fread(), fwrite()) or the Win32 file I/O.
I don't recommend following the example server source. The echoserver is the example that works.
The WOLFSSH object isn't reusable right now. I preferred to create a new WOLFSSH for each incoming connection and free it when done. Servers tend to allow multiple clients to connect simultaneously, so the echoserver can create a new object per incoming connection.
The echoserver is calling wolfSSH_shutdown. wolfSSH_stream_exit would be closing one data channel in a session, not the whole connection.
--John
How are you configuring wolfSSH? Which version are you trying to build? The function ssh_worker() should be called by the server_worker() thread entry point.
I do not recommend doing that at all. ECC signatures use a random value and they are different every time you sign some data. It verifies after the fact. I'm assuming you are trying to do a known answer test for the ECC sign function. NIST recommends doing a sign-and-verify test.
If you really want to replace the random number generator that always returns 1, you can set the macro CUSTOM_RAND_GENERATE_BLOCK to a function that you provide that memset's the buffer with 0xFF. You can do that, but I don't recommend that at all. You don't want the code to get out and have the random number generator returning the same value constantly.
We have an abstraction layer for mutexes in wolfcrypt/src/wc_port.c. With SINGLE_THREADED this abstraction just returns success when requesting the mutex. It can be replaced with RTOS specific mechanisms and for TIRTOS we are using a semaphore.
The worst thing that'll happen is two server sessions overwriting the same entry in the session cache. (Or the ECC look up table, or the CRL and OCSP response lists, etc.) If you disable the session cache, and don't enable FP_ECC and CRL, I think you're fine with SINGLE_THREADED.
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.)
Thank you.
I don't see any reason for the server to not respond to the client in the Wireshark logs. The client sends pretty much the same hello message in both connections. As far as I can see, just the random is different, which is expected. Neither are trying to resume the session. Same cipher suites requested.
The server picked the same cipher for FireZilla as it used on the first wolfSSL connection (ECDSA-RSA-AES256-SHA384), so the request was acceptable. The server would send an alert if there wasn't a suite match.
Really, TLS is just a decorator on your application's data. We try to keep the library transport agnostic for portability because many TCP/IP library APIs are radically different than the BSD style.
Does the server report any problems in its logs?
Which version of wolfSSL are you using and how are you configuring it?
Your PCAP file isn't showing much with the passive connection. The client sends a hello message and the server is reseting both connections two minutes later-ish. Can you attach a successful handshake with your other client?
wolfSSL does not currently support RFC 7250 raw public keys.
If your server can use a self-signed certificate, you could load the server's certificate as a root CA. You can disable certificate verification in the client. It won't check the server's certificate signature, but it would still use the public key in the handshake.
You don't use wolfSSL_set_using_nonblock() with TLS sessions. It is only used in DTLS sessions. I originally named the function without the "dtls" part, and it confused some people. "Well, I set non-block and it didn't work." wolfSSL is agnostic to the behavior of the underlying TCP/IP stack, or lack of one, and how it behaves. The only exception is DTLS with non-blocking sockets. In POSIX TCP/IP stacks, the stack returns the same error code for "this socket will block" as the condition "the timeout on this socket expired".
Really, the DTLS usage in our example server and client should have a custom application level structure containing the peer's address, the socket fd, and the non-blocking setting, and that should get passed into the I/O callback function.
RFC 5746, section 3.3, describes this phantom cipher suite. It is used in conjunction with secure renegotiation.
RFC 6066, section 4, defines the Max Fragment Length extension. 2^14 is not a value allowed by the extension, as that is the default maximum size of a TLS record. You indicate that size by not using the MFL extension. If the server accepts the MFL request, it shall reply with a MFL extension of its own with the same requested size tag.
We added options 5 and 6 for our own testing. They only work when wolfSSL is on either side.
There isn't an accessor for the MFL on a session. It is normally handled automatically inside the library. Nobody has requested an accessor for the value. The client application should already know what the value is, it set the value.
Note, RFC 8449, section5, obsoletes the MFL for TLSv1.3.
Posts found: 1 to 25 of 148
Generated in 0.021 seconds (90% PHP - 10% DB) with 5 queries