Re: openssl cms resign with RSA-PSS corrupts the CMS(?)
--On Saturday, February 13, 2021 11:23 PM +0200 Alon Bar-Lev wrote: I prepared a demo[1] to help people reproduce the issue, tested with openssl-1.1.1i. Maybe <https://github.com/openssl/openssl/issues/13931> ? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: no suitable signature algorithm during handshake failure
--On Friday, January 8, 2021 4:44 PM -0500 Viktor Dukhovni wrote: Hi Viktor, On Fri, Jan 08, 2021 at 12:05:26PM -0800, Quanah Gibson-Mount wrote: > https://www.spinics.net/lists/openssl-users/msg05623.html Thanks Viktor. Mainly, I wasn't sure what specific information would be necessary. Here's what wireshark shows (IP addresses obfuscated): It would be really helpful (also to you) if you install a more up-to-date version of tshark, or copy the pcap file to a machine that already has one. The version used below fails to understand many relevant modern TLS extensions/features. I've relayed this to our client. ;) ! ---> Extension: Unknown 43 -- i.e. supported_versions! Type: Unknown (0x002b)-- Almost certainly w/ TLS 1.3 Length: 9 Data (9 bytes) ! ---> Extension: Unknown 45 -- psk_key_exchange_modes Type: Unknown (0x002d)-- a TLS 1.3 feature Length: 2 Data (2 bytes) ! ---> Extension: Unknown 51 -- key_share Type: Unknown (0x0033)-- a TLS 1.3 feature I ran their pcap through my own updated version of tshark, and indeed: Extension: status_request_v2 (len=9) Type: status_request_v2 (17) Length: 9 Certificate Status List Length: 7 Certificate Status Type: OCSP Multi (2) Certificate Status Length: 4 Responder ID list Length: 0 Request Extensions Length: 0 Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Extension: supported_versions (len=9) Type: supported_versions (43) Length: 9 Supported Versions length: 8 Supported Version: TLS 1.3 (0x0304) Supported Version: TLS 1.2 (0x0303) Supported Version: TLS 1.1 (0x0302) Supported Version: TLS 1.0 (0x0301) Extension: psk_key_exchange_modes (len=2) Type: psk_key_exchange_modes (45) Length: 2 PSK Key Exchange Modes Length: 1 PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1) Extension: key_share (len=71) Type: key_share (51) Length: 71 Key Share extension Client Key Share Length: 69 Key Share Entry: Group: secp256r1, Key Exchange length: 65 Group: secp256r1 (23) Key Exchange Length: 65 Key Exchange: 04524e56171cf3e75903228cf4cc02687df2698bd43d167f… None were PSS, and RFC 8446 says: In addition, the signature algorithm MUST be compatible with the key in the sender's end-entity certificate. RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 algorithms appear in "signature_algorithms". The SHA-1 algorithm MUST NOT be used in any signatures of CertificateVerify messages. > What sort of certificate does the server have. Are there any ssl > module settings in its openssl.cnf file? The certificate does not require PSS, but TLS 1.3 does. Great, thanks so much for the help! I learned some along the way, which is always a good thing. :) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: no suitable signature algorithm during handshake failure
1.3.6.1.4.1.11129.2.4.2: --- Signature Algorithm: sha256WithRSAEncryption 5a:80:48:10:86:0d:f9:66:d3:bc:7b:35:a8:7b:20:8c:6c:c9: ca:ad:62:72:24:20:35:59:ba:aa:38:4e:c0:89:75:b9:ce:3d: b2:61:35:e9:4e:d8:bc:7b:8a:ee:23:2c:cc:ae:0a:12:2d:bc: 27:c5:f6:13:3c:5d:1a:d9:83:4c:7c:bc:4e:f7:fd:f4:cf:77: 3b:f1:be:6c:be:c0:8b:0c:4f:f2:3f:1f:c8:8d:8e:28:a2:af: 17:bf:63:c0:60:25:96:b3:65:4c:8a:7e:6a:c1:8f:bc:48:b6: e7:85:89:a5:d2:96:98:c9:62:53:fd:12:1c:37:ce:b2:de:54: 78:37:9a:a7:c3:65:1d:bd:65:bd:55:ac:72:bc:4a:43:41:ee: 37:8a:e9:13:9e:56:34:35:f1:e0:72:0d:67:1f:52:ee:81:8d: 86:d6:62:86:19:cd:5e:88:1e:7e:d0:c1:30:1b:39:bc:cf:b2: 81:f3:73:af:72:6d:8a:fb:be:5c:c2:de:10:f5:ae:10:e4:d6: 6b:cd:04:10:55:f2:81:71:a5:bb:6a:fc:b2:05:91:9a:33:2e: 74:85:e2:58:78:56:a8:76:89:d6:05:38:dc:58:25:70:e0:49: 44:b8:45:97:c5:42:c0:3c:ff:d8:a5:7d:60:b6:dd:fc:3d:69: d6:d1:31:82 Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
no suitable signature algorithm during handshake failure
Working on a migration for an application (OpenLDAP) where the old version is linked to OpenSSL 1.0.2 to where the new version is linked to OpenSSL 1.1.1h. Most client applications are working without issue. However, one Windows client application consistently fails to connect to the OpenSSL 1.1.1h linked slapd with an error of no suitable signature algorithm during the handshake. Using wireshark, we can see the following signature algorithms are offered from the client side (which uses TLSv1.2) for both the working and failing servers: 0x0403 ECDSA-SHA256 0x0503 ECDSA-SHA384 0x0603 ECDSA-SHA512 0x0401 RSA-SHA256 0x0501 RSA-SHA384 0x0601 RSA-SHA512 0x0402 DSA-SHA256 0x0203 ECDSA-SHA1 0x0201 RSA-SHA1 0x0202 DSA-SHA1 If I test connecting on the command line to the server in question, I can connect using any of RSA+SHA256, RSA+SHA384, and RSA+SHA512 from the above signature algorithms without issue, like: openssl s_client -connect -tls1_2 -sigalgs RSA+SHA256 Any suggestions as to why the windows client is unable to negotiate with a new version of OpenSSL? The error in the log is: error: 14201076:SSL routines:tls_choose_sigalg:no suitable signature algorithm. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Software that uses OpenSSL
--On Thursday, August 6, 2020 1:21 PM -0700 Dan Kegel wrote: lists 861 packages, belonging to something like 400 projects, that depend on openssl Unfortunately, due to Debian's odd take on the OpenSSL license, many projects that can use OpenSSL are compiled against alternative SSL libraries, so this can miss a lot of potential applications (OpenLDAP, for example). Hopefully with OpenSSL 3.0 and later, this won't be as much of an issue. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: empty directory in the 1.1.1 series release tags
--On Tuesday, April 21, 2020 11:25 AM -0700 Norm Green wrote: >I use the git release tags, not the tarballs. I do too, and I suspect many others do as well. The empty krb5 directory has not caused grief for me, but it would be nice if the git release tag directory structure matched the tarball. I ended up doing a git rm on the krb5 dir, and then the rest of the tags all went in fine (I was last on 1.1.1d). But I agree, overall I would expect the release tags to match the release tarballs. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: empty directory in the 1.1.1 series release tags
--On Tuesday, April 21, 2020 11:16 AM -0700 Benjamin Kaduk wrote: The 'krb5' entry in git is a submodule, used for the external tests. It's removed while preparing release tarballs, but I'm not sure what you are doing that's causing conflicts -- are you doing something that involves both tarballs and git? I use the git release tags, not the tarballs. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
empty directory in the 1.1.1 series release tags
The OpenSSL release tags contain an empty directory "krb5" that does not exist in the release tarball. This is annoying because when I go to merge release tags, I constantly get the following: CONFLICT (modify/delete): krb5 deleted in HEAD and modified in OpenSSL_1_1_1e. Version OpenSSL_1_1_1e of krb5 left in tree. Can this please be fixed? Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
RE: building openssl 1.1.1 for Solaris 10
--On Friday, April 3, 2020 6:31 PM + Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of tim.j.culh...@gmail.com Sent: Friday, April 03, 2020 10:49 Are there instructions somewhere for building and installing openssl 1.1.1 from source for Solaris 10? You mean beyond what's in INSTALL and NOTES.UNIX? What is your specific issue? They may have run into <https://github.com/openssl/openssl/issues/6333> which the OpenSSL project seems disinclined to fix. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: CVE-1999-0428
--On Tuesday, March 3, 2020 5:16 PM -0500 Chris Rhoads wrote: But I've been unable to determine with certainty how the last vulnerability on this list (CVE-1999-0428) was fixed. In my research, I've found a potential OpenSSL update in release 0.9.2b that may have addressed the vulnerability: https://seclists.org/bugtraq/1999/Mar/144. But this security alert message doesn't reference any CVE number. The above email is related to this commit in the OpenSSL source tree: b4cadc6e1343c01b06613053a90ed2ee85e65090 Since it pre-dates the CVE being filed, it has no reference to the CVE itself in the commit. Someone from the OpenSSL project would have to confirm if that is indeed the fix for the above CVE (and if so, then the CVE database needs updating). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
CVE-2019-1552 clarification
As someone who does build OpenSSL on windows, my gist is that if I use a non-default OPENSSLDIR I'm ok? Can someone confirm? Thanks! I.e., I use --openssldir=/opt/symas/ssl Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Openssl IPv6 Support
--On November 5, 2014 at 10:10:26 AM +0100 Marcus Meissner meiss...@suse.de wrote: On Wed, Nov 05, 2014 at 08:28:40AM +, Mody, Darshan (Darshan) wrote: Hi, Does Openssl support IPv6 officially?. AFAIK the libssl and libcrypto libraries do not use sockets at all, these are left to the applications/libraries using them. So openssl does neither support ipv4 nor ipv6. apparently you've never used s_client, or looked at the *ancient* bug explicitly asking that IPv6 support be added for s_client s_server in OpenSSL. It even has a patch that's been widely used for years by major linux distributions. It boggles the mind that to this day that patch has not been integrated in the 5 years since the bug was opened. See http://rt.openssl.org/Ticket/Display.html?id=2051, https://bugs.debian.org/589520 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
