make check hangs in Running case 'TLS 1.3/key exchange groups' in 9.4.3 #752
Comments
|
You might be missing some crypto plugins. Possible that can see what problem the TLS stack has if you run this with |
|
Indeed. It seems it should have failed instead |
|
Can you find failure reason? I guess it might be pkcs11 plugin, because I make sometime tests with it. But failed to spot exact reason, internal error does not help? |
Due to how the TLS tests are structured (and in part how the test framework operates), they will hang for some TLS protocol failures. Here it seems generating the key-share extension already on the client fails. Most likely because a DH group was selected that couldn't get instantiated. This particular test goes through all DH groups announced by plugins and tries to do a key exchange with each, which will fail if none of the plugins can actually instantiate it. Looking at the tests that were successful, we see ecp256, ecp384, ecp521 and ecp224. The next DH group in that list is probably ecp192. Of the plugins you have loaded only the openssl plugin announces it (while the pkcs11 plugin theoretically supports it, DH handling via PKCS#11 is disabled by default). The problem is that plugin features, including supported DH groups, are mostly statically configured at compile-time (in the openssl plugin based on What version of OpenSSL do you use? Was it compiled in a way that disables ecp192 specifically (not sure if there is such an option, other crypto libraries have e.g. options to configure minimum bits for keys)? Or is FIPS-mode active even though the log says it isn't (maybe that reporting isn't working correctly)? (Not sure, though, if FIPS-mode would even disable it.) OpenSSL also has the concept of security levels that might affect this. But this is generally something that applies to TLS contexts, which we don't use (e.g. configurable via |
|
Also, you haven't built with |
|
I am using It seems there is also some different issue just on 32 bit systems, because only that builds have failed test during build. (That link would stay valid for ~5 days). There are also visible all configure parameters used. It is possible some weird combinations are used, I left there whatever previous maintainers enabled. FIPS mode is not be enabled on my machine. My build passed also with |
Well, if it impacts OpenSSL (or rather libcrypto), it might. What exactly does
Looks like a timeout in the NewHope tests (very well possible on a slow 32-bit machine). Probably doesn't make sense to enable that plugin (
Did you use |
|
Yes, I did a new build of RPM package, during which it happens. I made a fresh build with reconfigure, it should not be affected. It switches multiple of services, but openssl configuration should be most important. Not sure how other defaults are set during the build. |
|
Does it work if you switch to |
|
It does not seems to help, but I don't want to reboot my own system yet. It might be required for change to be properly updated. |
|
I tried rebuilding it on a fresh VM, it seems this problem is somehow specific only for my machine. Fresh F35 machine fails on different test: But reported test passes without issues. I tried to catch fatal TLS send in gdb. It is sent from this backtrace: |
Wait, even though we see a failure to use ecp192 when the test vectors are applied (which, as mentioned, you should see on your machine too), you say the TLS tests are all working if you run them individually? Even the one that uses ecp192? (You'll see the used groups in the TLS tests with Weird that MD2 fails here while it doesn't with OpenSSL 3, I guess it's completely disabled in that build, i.e.
Unfortunately, it's not really helpful, because this only shows the code path where the alert is sent, not where it was triggered (where it just causes a state change that later causes the alert to get sent). But it's pretty clear to me that it happens here strongswan/src/libtls/tls_peer.c Lines 1447 to 1452 in fe5399d this->dh is NULL due to the call at strongswan/src/libtls/tls_peer.c Line 1375 in fe5399d |
|
Tried breakpoint on that line. Only once it stops there, it seems to be ecp256. |
|
That's the first one that will be tested. You'd need to continue until the group is |
|
I see two different problem here. First is failing on ECP_192_BIT. I have issues with gdb to step it correctly. Second is wrong design of tls socket tests. I think server should be terminated in fixture, not inside the test. I think it hangs, because server is not stopped in case of failed assert. Which is kind of point of tests. It seems Changing it would require not small changes I am afraid. I can wrap make check into timeout command, ensuring it would end within minutes that or the other way. Kind of workaround, but better than nothing. |
|
OK, I see what the problem with ecp192 is. Apparently, the Fedora OpenSSL package removes support for EC curves < 224 bits with a patch. Checking for that is kinda tricky (without instantiating it), as there is nothing like wolfSSL's Regarding the stuck socket tests, shutting down the server socket in the teardown function is a good idea. But it isn't enough if the error happens on the server (not on the client as in this case). I've pushed a couple of commits to the 752-libtls-tests. |
|
Oh, if that is downstream patch on Fedora, then I will patch that skip that algorithm. It would be nice if openssl_diffie_hellman_create could report more detailed failure reason. Test might then just print warning and continue if whole algorithm is not supported. It should fail with error if algorithm key can be created but cannot be used (if that makes sense). For example FIPS mode on RHEL can change available features runtime. It does not always work to detect supported ciphers on compile time and rely they would stay available. Similar with crypto policy I have already noted. I think the server part should maybe use different 'delayed' checks, which would save place of failure into variable and abort server setup. It would check server status before client is started. If server failed to start, no client test is needed. Just would have to find way to cancel server thread on any failure occuring inside it. Not sure if fixture can reliable stop it. If server stopping were moved there, it may work both in case of success and failure. Just ensure waiting for never happening action does not start. Anyway, your change changes hang to failure, which is much better. If that is caused by downstream change in Fedora, there is no point of making configure check testing availability of it. I will just comment it out. |
|
I have dug a bit into documentation and found there exists function EC_get_builtin_curves. It can obtain list of supported variants, which differs quite a lot between Fedora and Debian. Could it be used to initialize only supported EC types in openssl_plugin.c, get_features method? It is possible to initialize features in more dynamic way? Here is snippet I used to list contents. Found very surprising difference, Debian has 82 curves, while Fedora has only 5! Could it initialize just enabled curve types during initialization and skip automagically both in tests and runtime? // gcc -Wall test.c -o test $(pkg-config --libs --cflags openssl)
#include <openssl/ec.h>
int main(int argc, char *argv[])
{
size_t i;
size_t n;
const unsigned max = 90;
EC_builtin_curve info[max];
n = EC_get_builtin_curves(info, sizeof(info)/sizeof(info[0]));
for (i=0; i<n && i<max; i++) {
printf("%02zu nid %X: %s\n", i, info[i].nid, info[i].comment);
}
if (i == max)
printf("Not all printed, returned count is %zu\n", n);
return 0;
}Used following diff to disable failing vector tests. diff --git a/src/libstrongswan/plugins/openssl/openssl_plugin.c b/src/libstrongswan/plugins/openssl/openssl_plugin.c
index 5009f4e3f..211c2b434 100644
index 5009f4e3f..211c2b434 100644
--- a/src/libstrongswan/plugins/openssl/openssl_plugin.c
+++ b/src/libstrongswan/plugins/openssl/openssl_plugin.c
@@ -528,7 +528,7 @@ METHOD(plugin_t, get_features, int,
/* hashers */
PLUGIN_REGISTER(HASHER, openssl_hasher_create),
#ifndef OPENSSL_NO_MD2
- PLUGIN_PROVIDE(HASHER, HASH_MD2),
+ //PLUGIN_PROVIDE(HASHER, HASH_MD2),
#endif
#ifndef OPENSSL_NO_MD4
PLUGIN_PROVIDE(HASHER, HASH_MD4),
@@ -639,8 +639,8 @@ METHOD(plugin_t, get_features, int,
PLUGIN_PROVIDE(DH, ECP_384_BIT),
PLUGIN_PROVIDE(DH, ECP_521_BIT),
PLUGIN_PROVIDE(DH, ECP_224_BIT),
- PLUGIN_PROVIDE(DH, ECP_192_BIT),
-#if OPENSSL_VERSION_NUMBER >= 0x10002000L
+ //PLUGIN_PROVIDE(DH, ECP_192_BIT),
+#if OPENSSL_VERSION_NUMBER >= 0x10002000L && false
PLUGIN_PROVIDE(DH, ECP_256_BP),
PLUGIN_PROVIDE(DH, ECP_384_BP),
PLUGIN_PROVIDE(DH, ECP_512_BP),
|
|
Above program reports only those curves on Rawhide: |
Yes, that's possible, but requires some refactoring. I've pushed a couple of patches to the 752-libtls-tests branch. By the way, that limitation to 5 curves is not only due to the patch (which only removes weak curves) but building in FIPS mode. I wonder if those other curves (in our case the Brainpool curves) are available in non-FIPS mode. |
|
No, they are not available in non-FIPS mode also. I tested it on my machine, which does not have FIPS mode enabled. |
|
Interesting, I wonder if that was an intentional decision or just due to how the curves are stored/provided (in particular in OpenSSL 3 where FIPS-mode is handled as separate provider). Seems weird that curves that are, other than not being FIPS-approved, considered strong are not available in non-FIPS mode. |
|
Yes, it seems to be intentional decision on Fedora and RHEL. It seems to be long standing way and I doubt it would change soon. I admit that is strange to me too. |
System (please complete the following information):
Describe the bug
make check hangs and does not continue even after timeout
To Reproduce
Steps to reproduce the behavior:
Expected behavior
It should fail or pass, not hang. When thist test case is commented out, all other are sucessful.
Logs/Backtraces
Backtrace from gdb:
Additional context
I tried to enable make check to validate build in Fedora. However only one case hangs indefinitely on my 4 cores machine. Can it be something wrong in Fedora's libraries?
Is there fix available to make it pass?
The text was updated successfully, but these errors were encountered: