Re: What's the rationale behind ssl-trace not being built by default?
> On Jun 8, 2021, at 6:48 AM, Hubert Kario wrote: > > On Monday, 7 June 2021 21:01:04 CEST, Arran Cudbard-Bell wrote: >> The tables to convert extension IDs and compression methods to humanly >> readable names are not available outside ssl/t1_trace.c. >> >> SSL_trace() itself produces reams of helpful information as handshakes >> progress, and is particularly useful for dealing with encrypted handshakes, >> where wireshark et al don't provide useful output. > > Note that many tools are able to produce a keyfile that wireshark can use > to decrypt the encrypted parts of handshake and exchanged data too. > > Look for SSLKEYLOGFILE in https://wiki.wireshark.org/TLS > > It's supported in clients like Firefox and curl, as well as in servers, > like httpd: https://github.com/apache/httpd/pull/74 That's very interesting, I'll look into providing support for keylog files in FreeRADIUS as well. PR for enabling ssl-trace by default is open here: https://github.com/openssl/openssl/pull/15665 -Arran signature.asc Description: Message signed with OpenPGP
Best practice for distributions that freeze OpenSSL versions and backports
Dear team, It would be nice if there was a user- and security-friendly best practice document for distributions (such as Linux distributions) that freeze on an OpenSSL release version (such as 1.1.1z) and then backport any important fixes. Perhaps something like the following: 1. The distributor shall seek to backport as many upstream security fixes as possible and shall sign up to receive advance confidential copies of such code changes to attempt a coordinated release at the same time as the upstream release. 1.1. The version number frozen on should be from the upstream branch with the latest upstream maintenance end date available at the time of freezing the version. 2. Any such backport-patched version (as source, library, shared library, and/or openssl binary shall be provided with a document named: README.fixes with distribution appropriate extension for such files (like .txt or .gz)) listing the following: 2.1 The version number of the most recent upstream release version considered at the time of last document update. 2.2 The version number of the upstream release version chosen as the frozen base, and the date when that choice was made. 2.3 The current differences from that most recent upstream release version, specifying any upstream security advisories and public CVEs not completely fixed, but still listing any and all non-security enhancements not included. 2.4 The current differences from the named frozen base version, with any net changes back and forth cancelled out (thus not a changelog). Any change fixing a security issue shall list the upstream security advisory and public CVE. 2.5. The distribution maintainers that did the backporting and writing of the document, and (if different) the contact point for reporting issues/bugs in the backport work. 3. The README.fixes document should, if possible, be made available to the upstream project Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, 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: Compile opensslß1.1.1k on CentOS8
On Monday, 7 June 2021 20:26:28 CEST, Lothar Belle wrote: Hi, recently I compiled openssl-1.1.1k on CentOS-8 but when I am using libcrypto.so.1.1 I get errors like: libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b Obviously RedHat added additional features into there own libraries, but using the same version/naming. See https://bugzilla.redhat.com/show_bug.cgi?id=1829790 I tried also to apply the patches, but they don‘t work with the latest source code https://git.centos.org/rpms/openssl/blob/c8/f/SOURCES/openssl-1.1.1-evp-kdf.patch The suggested solution renaming the libraries didn‘t work neither for me. But we want to use the latest version, including all security fixes, therefore I can‘t use the build-in version. Please note that packages in RHEL, and thus, later, in CentOS, include security fixes: https://access.redhat.com/security/updates/backporting even if their package version is older than the newest upstream release. But that's not the only reason why those packages have additional patches, they also have them to better integrate with the rest of the system: https://access.redhat.com/articles/3655361 or integrate with features like system-wide crypto policies: https://access.redhat.com/articles/3666211 or, as in the case of the openssl-1.1.1-evp-kdf.patch, to provide features from newer releases (like 3.0.0) in an older ABI release. So I'd strongly suggest against replacting the .so files of any low-level library, in any distribution, not just RHEL or CentOS. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
Re: What's the rationale behind ssl-trace not being built by default?
On Monday, 7 June 2021 21:01:04 CEST, Arran Cudbard-Bell wrote: The tables to convert extension IDs and compression methods to humanly readable names are not available outside ssl/t1_trace.c. SSL_trace() itself produces reams of helpful information as handshakes progress, and is particularly useful for dealing with encrypted handshakes, where wireshark et al don't provide useful output. Note that many tools are able to produce a keyfile that wireshark can use to decrypt the encrypted parts of handshake and exchanged data too. Look for SSLKEYLOGFILE in https://wiki.wireshark.org/TLS It's supported in clients like Firefox and curl, as well as in servers, like httpd: https://github.com/apache/httpd/pull/74 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
Re: Openssl FIPS 186-4 Support
To be more specific, Please help me point out the API, which supports *RSA 186-4 key generation*. Thanks, Pramod. On Tue, Jun 8, 2021 at 4:06 PM Illuri Pramod wrote: > Hello All, > > I am looking for options to support fips 186-4 in openssl 1.0.2. Oracle > FOM based out of fips object module (FOM) 2.0.13, which is available in > public domain, claims to have 186-4 support as per the documentation. > However, I didn't find the specific diff/API, which added this support. > > Ref : > https://github.com/oracle/solaris-openssl-fips > > Could someone help me point out which API or code section corresponds to > supporting fips 186-4 in the oracle FOM module ? > > > Thanks, > Pramod. >
Openssl FIPS 186-4 Support
Hello All, I am looking for options to support fips 186-4 in openssl 1.0.2. Oracle FOM based out of fips object module (FOM) 2.0.13, which is available in public domain, claims to have 186-4 support as per the documentation. However, I didn't find the specific diff/API, which added this support. Ref : https://github.com/oracle/solaris-openssl-fips Could someone help me point out which API or code section corresponds to supporting fips 186-4 in the oracle FOM module ? Thanks, Pramod.
Checking a single signature from several in S/MIME
Hello list, I'm signing a file using SMIME with 2 signers. When trying to check the signature with only one of the two signers, it fails with a "signer certificate not found". Using both signers, it succeeds. Is there a way to be able to check the signature with a single signer, not all of them? // Signing openssl smime -binary -sign -nodetach -in file -out file.signed -inkey key1.pem -signer cert1.pem -inkey key2.pem -signer cert2.pem // this command fails with signer certificate not found" openssl smime -binary -verify -nointern -noverify -certfile cert1.pem -in file.sign -out file.checked // this command succeeds and write both certificates in file.signer openssl smime -binary -verify -noverify -certfile cert1.pem -in file.sign -out file.checked -signer file.signer // This command succeeds openssl smime -binary -verify -nointern -noverify -certfile file.signer -in file.sign -out file.checked thanks in advance for any suggestion, Laurent
Re: Re: Compile opensslß1.1.1k on CentOS8
janj...@nikhef.nl said: > As you found out, it is nearly impossible to swap out the existing openssl > 1.1.1g with a "stock" openssl version, as RedHat/CentOS have applied patches > to it. My advice would be: don't even try. If you *have to* use openssl > 1.1.1k, then switch to Fedora or to Ubuntu (not the LTS releases). But keep > in mind: - debian 10 uses openssl 1.1.1d - ubuntu seems to be at openssl > 1.1.1j etc. There are two cases. One is where you want to replace the system libraries so that all the installed programs that use libssl will now use your new version. I agree doing that is crazy. That's what distros are for. But if you are working on a program and you want that one program to use a new version, that's not so hard. The trick is to install your new version of openssl in /usr/local/ (or wherever). Then you have to patch the build recipe for your program to look there. This is how you would get your program ready for 3.0.0 or get a program that needs TLS1.3 to work on a distro that is stuck in the dark ages. I use: ./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared to build and install OpenSSL, then, for waf: ctx.env.INCLUDES = ["/usr/local/ssl/include"] ctx.env.LIBPATH = ["/usr/local/ssl/lib"] I don't remember where I found that config line. -- These are my opinions. I hate spam.
Re: Compile opensslß1.1.1k on CentOS8
Hi, On 07/06/21 20:26, Lothar Belle wrote: Hi, recently I compiled openssl-1.1.1k on CentOS-8 but when I am using libcrypto.so.1.1 I get errors like: libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b Obviously RedHat added additional features into there own libraries, but using the same version/naming. See https://bugzilla.redhat.com/show_bug.cgi?id=1829790 I tried also to apply the patches, but they don‘t work with the latest source code https://git.centos.org/rpms/openssl/blob/c8/f/SOURCES/openssl-1.1.1-evp-kdf.patch The suggested solution renaming the libraries didn‘t work neither for me. But we want to use the latest version, including all security fixes, therefore I can‘t use the build-in version. Has anybody a solution for this? Is it planned to implement such features in official OpenSSL in the near future? CentOS 8(.3) uses openssl 1.1.1g *with security backports* . The whole idea of an enterprise OS like RHEL 8 is that you fix packages at certain version (e.g. kernel 4.18.0, gcc 8.3.1, openssl 1.1.1g) and that those versions will remain (mostly) constant throughout the life cycle of the OS. Redhat backports security fixes from newer releases into this 1.1.1g release, thus one can claim that "rhel8 openssl 1.1.1g" is as safe (or unsafe) as the stock version of openssl 1.1.1k. If you don't like this, then switch to a distro that does not use this "version pinning" - the downside of that will that you will be doing upgrades very frequently. As you found out, it is nearly impossible to swap out the existing openssl 1.1.1g with a "stock" openssl version, as RedHat/CentOS have applied patches to it. My advice would be: don't even try. If you *have to* use openssl 1.1.1k, then switch to Fedora or to Ubuntu (not the LTS releases). But keep in mind: - debian 10 uses openssl 1.1.1d - ubuntu seems to be at openssl 1.1.1j etc. HTH, JJK
Re: What's the rationale behind ssl-trace not being built by default?
On 08/06/2021 00:09, Arran Cudbard-Bell wrote: On Jun 7, 2021, at 4:57 PM, Matt Caswell wrote: On 07/06/2021 20:01, Arran Cudbard-Bell wrote: The tables to convert extension IDs and compression methods to humanly readable names are not available outside ssl/t1_trace.c. SSL_trace() itself produces reams of helpful information as handshakes progress, and is particularly useful for dealing with encrypted handshakes, where wireshark et al don't provide useful output. What is the rationale for ssl-trace to be disabled by default? Was it purely to keep binary sizes down, or was there a security aspect to the decision? Its a really good question and I've often wondered the same thing. The decision was made before my time. I suspect it was about keeping binary sizes down, but I can't imagine it would make that much difference. I have previously considered turning it on by default but never quite got around to it. If you don't have any objections I could submit a PR to enable it by default? I'd image that the platforms that'd care about a few extra kb are in the minority, and it makes such a huge difference having SSL_trace() when trying to debug TLS 1.3 issues. I have no objections although you'll have to be quick if you want it considered for 3.0. Since it would just be about changing the default people that care about the extra kb can still disable it. Matt
