Intermittent ssl errors without OPENSSL_ia32cap
Hello all, I have a AMD 3600x + X470D4U system where I observed intermittent ssl problems including data corruption of files when downloading thru https. For example: root@oasis:~# curl -o o https://www.google.com % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (35) error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac root@oasis:~# This was originally on unraid linux distribution but I also tried Slax live with the same results. At the end I was able to get rid of the warnings and download without data corruption by using OPENSSL_ia32cap="~0x202". Could this be a bug somewhere in openssl or my hardware is just bad? Thanks!
Minimum gcc version required for openssl 3.x?
I searched all the docs I could find but I was unable to locate any
statements regarding gcc compatibility for openssl 3.x. I'm having a
problem cross-compiling for arm using gcc-4.4.5:
rm -f libssl.so && \
ln -s libssl.so.3 libssl.so
arm-linux-gnueabi-gcc -Iinclude -fPIC -pthread -Wall -O3 -DNDEBUG
-DL_ENDIAN -DOPENSSL_NO_COMP -MMD -MF engines/capi-dso-e_capi.d.tmp -MT
engines/capi-dso-e_capi.o -c -o engines/capi-dso-e_capi.o engines/e_capi.c
/workspace/XX/perl/bin/perl ./util/mkdef.pl --ordinals util/engines.num
--name engines/capi --OS linux > engines/capi.ld
arm-linux-gnueabi-gcc -fPIC -pthread -Wall -O3 -L. -z defs -Wl,-znodelete
-shared -Wl,-Bsymbolic \
-o engines/capi.so -Wl,--version-script=engines/capi.ld \
engines/capi-dso-e_capi.o \
-lcrypto -ldl -pthread
arm-linux-gnueabi-gcc: defs: No such file or directory
gmake[5]: *** [engines/capi.so] Error 1
I found that gcc-4.9.2 works fine (odd, see below), as does the following
patch:
$ git diff Configurations/shared-info.pl
diff --git a/Configurations/shared-info.pl b/Configurations/shared-info.pl
index a673c7c..461ce3c 100644
--- a/Configurations/shared-info.pl
+++ b/Configurations/shared-info.pl
@@ -36,7 +36,7 @@ my %shared_info;
(grep /(?:^|\s)-fsanitize/,
@{$config{CFLAGS}}, @{$config{cflags}})
? ''
-: '-z defs',
+: '-Wl,-z,defs',
};
},
'bsd-gcc-shared' => sub { return $shared_info{'linux-shared'}; },
Although this works in gcc-4.9.2, it appears that the -z flag wasn't
documented until gcc-5.5. All Google hits I get for "-z defs" take me to
pages that show "-Wl,-z,defs" so it's curious that this particular option
isn't being passed with -Wl like the others. Is there a minimum supported
gcc version for openssl 3.x?
Thanks,
Tom.III
Re: Can RSA PSS-R be done simply with OpenSSL?
There is example code for doing RSA PSS with OpenSSL at https://www.idrix.fr/Root/Samples/openssl_pss_signature.c On Tue, May 12, 2020 at 11:59 AM John McCabe wrote: > Hi, > I've searched around, but found nothing that appears to help. > > I'm developing some software where I may be given a file that's been > created (signed) by using the Crypto++ library's implementation of RSA > PSS-R, with a SHA1 hash. As I understand it, the complete file contents > then effectively becomes the signature, and the receiving end needs to > recover the original file contents and verify its signature. > > Is the receiving end something I can do with OpenSSL? I have a need to use > OpenSSL features in the software I'm developing so, if possible, I'd rather > avoid having to include Crypto++ in it! > > Any pointers would be gratefully appreciated. For what it's worth, this is > something I'm fairly new to so, if what I'm asking isn't clear, or if it > sounds like I have some concepts wrong, please let me know gently ;-) > > Many thanks > John >
Can RSA PSS-R be done simply with OpenSSL?
Hi, I've searched around, but found nothing that appears to help. I'm developing some software where I may be given a file that's been created (signed) by using the Crypto++ library's implementation of RSA PSS-R, with a SHA1 hash. As I understand it, the complete file contents then effectively becomes the signature, and the receiving end needs to recover the original file contents and verify its signature. Is the receiving end something I can do with OpenSSL? I have a need to use OpenSSL features in the software I'm developing so, if possible, I'd rather avoid having to include Crypto++ in it! Any pointers would be gratefully appreciated. For what it's worth, this is something I'm fairly new to so, if what I'm asking isn't clear, or if it sounds like I have some concepts wrong, please let me know gently ;-) Many thanks John
Re: openssl 3 and deprecation
On 12/05/2020 15:35, Billy Brumley wrote: > Howdy Folks, > > I checked https://www.openssl.org/policies/releasestrat.html but did > not manage to find an answer. > > At what stages is marking a function deprecated still allowed? Only > before beta? Or at all stages? Or is it case-by-case with potential > OMC vote? Hi Billy We allow API changes until Beta 1 (but ideally we would prefer API changes to have appeared in at least one alpha). Deprecation counts as an API change. Matt
openssl 3 and deprecation
Howdy Folks, I checked https://www.openssl.org/policies/releasestrat.html but did not manage to find an answer. At what stages is marking a function deprecated still allowed? Only before beta? Or at all stages? Or is it case-by-case with potential OMC vote? Thanks BBB
Re: Which 1.1.1 config options set OPENSSL_NO_TESTS ?
On 12/05/2020 16:01, Matt Caswell wrote: On 12/05/2020 14:50, Jakob Bohm via openssl-users wrote: When running Configure in OpenSSL 1.1.1g with various options, it sometimes silently sets OPENSSL_NO_TESTS as reported by "perl configdata.pm -d" . Looking at the code here: https://github.com/openssl/openssl/blob/69296e264e58334620f541d09a4e381ee45542d4/Configure#L470-L510 It seems that "no-tests" will happen automatically if you specify "no-apps". "no-apps" will be automatically turned on by "no-autoalginit". i.e. these 3: no-tests no-apps no-autoalginit It strikes me as a bit over-zealous to disable all the tests because the apps are disabled (quite a few tests use the apps, but quite a few do not - we could at least run the ones that don't use them). Similarly, I would expect many of the apps to work fine with no-autoalginit, while the remainder could do the equivalent from the bin/openssl code without imposing it upon library users. These option cascades really ought to be documented in INSTALL, but I can see that they are not. This obviously causes "make test" to do nothing with the message "Tests are not supported with your chosen Configure options" . Unfortunately, neither the message nor "perl configdata.pm -d" gives any clue which of the used Configure options triggered this, and neither do INSTALL nor Configurations/README* nor Configurations/INTERNALS.Configure . So how should one go about finding the offending Configure options (other than endless trial and error)? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: Which 1.1.1 config options set OPENSSL_NO_TESTS ?
On 12/05/2020 14:50, Jakob Bohm via openssl-users wrote: > When running Configure in OpenSSL 1.1.1g with various options, it sometimes > silently sets OPENSSL_NO_TESTS as reported by "perl configdata.pm -d" . Looking at the code here: https://github.com/openssl/openssl/blob/69296e264e58334620f541d09a4e381ee45542d4/Configure#L470-L510 It seems that "no-tests" will happen automatically if you specify "no-apps". "no-apps" will be automatically turned on by "no-autoalginit". i.e. these 3: no-tests no-apps no-autoalginit It strikes me as a bit over-zealous to disable all the tests because the apps are disabled (quite a few tests use the apps, but quite a few do not - we could at least run the ones that don't use them). These option cascades really ought to be documented in INSTALL, but I can see that they are not. Matt > > This obviously causes "make test" to do nothing with the message "Tests are > not supported with your chosen Configure options" . > > Unfortunately, neither the message nor "perl configdata.pm -d" gives any > clue which of the used Configure options triggered this, and neither do > INSTALL nor Configurations/README* nor Configurations/INTERNALS.Configure . > > So how should one go about finding the offending Configure options (other > than endless trial and error)? > > Enjoy > > Jakob
Which 1.1.1 config options set OPENSSL_NO_TESTS ?
When running Configure in OpenSSL 1.1.1g with various options, it sometimes silently sets OPENSSL_NO_TESTS as reported by "perl configdata.pm -d" . This obviously causes "make test" to do nothing with the message "Tests are not supported with your chosen Configure options" . Unfortunately, neither the message nor "perl configdata.pm -d" gives any clue which of the used Configure options triggered this, and neither do INSTALL nor Configurations/README* nor Configurations/INTERNALS.Configure . So how should one go about finding the offending Configure options (other than endless trial and error)? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: SSL_CTX_set_ssl_version changes security level
On Mon, 2020-05-11 at 13:37 -0700, Benjamin Kaduk via openssl-users wrote: > On Tue, May 12, 2020 at 05:22:29AM +0900, NAKANO Takuho wrote: > > 2020年5月12日(火) 0:31 Benjamin Kaduk : > > > > > OS-vendor customization > > > > Thank you. That's very helpful. I get how to configure (but don't > > know why...). > > > > On CentOS 8: > > First result of SSL_CTX_get_security_level depends on > > A: /etc/pki/tls/openssl.cnf . > > > > To be more precise, set "CipherString = @SECLEVEL=5:..." > > or "CipherString = @SECLEVEL=0:..." in > > B: /etc/crypto-policies/back-ends/opensslcnf.config > > that is included by A. > > > > *BUT* second result of SSL_CTX_get_security_level depends on > > C: /etc/crypto-policies/back-ends/openssl.config > > (I assume SSL_CTX_set_ssl_version internally refer this file). > > File C has a single line beginning with: > > @SECLEVEL=2:kEECDH:.. > > If I change this level, the second result changes. > > Maybe it's on RHEL8 patch (system-cipherlist.patch). > > https://src.fedoraproject.org/rpms/openssl/blob/master/f/openssl-1.1.1-system-cipherlist.patch > suggests (the ssl.h chunk) that this patch does force the use of the > "system > profile" as the default cipher list. Yes, on Fedora/RHEL 8 you need to replace the cipher strings in both /etc/crypto-policies/back-ends/openssl.config and /etc/crypto- policies/back-ends/opensslcnf.config config files or you have to override the cipher string with a non-default one from the application. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
