Re: Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)
Hi Craig, On Wed, Dec 09, 2020 at 08:35:46PM +0900, Craig Henry wrote: > Hi, > > This is my first post to this list so please be kind! > > Environment - Linux Centos > SSL - 1.0.2k19-el7 > > Connection - CURL (via PHP) with public / private key auth + http basic auth > > We're having an issue where we are seeing intermittent behavior connecting > to a 3rd party of the key being rejected with a 8152 error - "The key does > not support the requested operation". Other times it works OK. > > We have another user who is using this 3rd party and same connection type > but not reported this issue. > > Has anyone got any clue as to what might be causing this type of > intermittent connection issue ? As was already noted, this is not an error generated by OpenSSL. More concretely, RFC 8152 is for CBOR Object Signing and Encryption (COSE), which is not really related to TLS at all. I suspect the error is not from NSS or CURL either but rather from a COSE implementation. -Ben
RE: DH_generate_key
Dear openssl team,
While migrating from 1.0.2 to 3.0, we found that
DH_generate_key() has be deprecated. And as per the man page, it is advised to
use
EVP_PKEY_derive_init<https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_derive_init.html>
&
EVP_PKEY_derive<https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_derive.html>
our application creates a new DH and using DH_generate_key() creates
pub_key/priv_key and uses it. how can we replace this exactly with EVP.
And please suggest what EVP API’s should we use to generate pub/priv keys ?
Application code
dh = DH_new();
dh->p = BN_bin2bn(modSize, octet_len, NULL);
dh->g = BN_bin2bn(H235Bits_generator, H235Bits_generator_len / 8, NULL);
if ( ! DH_generate_key(dh) )
{
return FAILURE;
}
n = (unsigned) BN_num_bytes(dh->pub_key);
BN_bn2bin(dh->pub_key, p);
n = (unsigned) BN_num_bytes(dh->priv_key);
Instead above logic can we do this ? is derive generated pub/priv keys ?
The man page in section 7 (EVP_PKEY_DH) has examples for generating using safe
primes or using probable primes. Seems better since you don’t have to use the
BN API anymore, but a little more complicated because you have to call
OSSL_PARAM_construct_xxx for parameters and assign them to an array.
From there, you can use EVP_PKEY_derive_init, EVP_PKEY_derive_set_peer, and
EVP_PKEY_derive to get your shared secret. See apps/speed.c in the OSSL3
source code for an example. Look for the text EVP_PKEY_DH
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [08 December 2020] EDIPARTYNAME NULL pointer de-reference (CVE-2020-1971) == Severity: High The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash may occur leading to a possible denial of service attack. OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes: 1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate 2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) If an attacker can control both items being compared then that attacker could trigger a crash. For example if the attacker can trick a client or server into checking a malicious certificate against a malicious CRL then this may occur. Note that some applications automatically download CRLs based on a URL embedded in a certificate. This checking happens prior to the signatures on the certificate and CRL being verified. OpenSSL's s_server, s_client and verify tools have support for the "-crl_download" option which implements automatic CRL downloading and this attack has been demonstrated to work against those tools. Note that an unrelated bug means that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence trigger this attack. All OpenSSL 1.1.1 and 1.0.2 versions are affected by this issue. Other OpenSSL releases are out of support and have not been checked. OpenSSL 1.1.1 users should upgrade to 1.1.1i. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2x. Other users should upgrade to OpenSSL 1.1.1i. This issue was reported to OpenSSL on 9th November 2020 by David Benjamin (Google). Initial analysis was performed by David Benjamin with additional analysis by Matt Caswell (OpenSSL). The fix was developed by Matt Caswell. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of this issue on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20201208.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl/PloEACgkQ2cTSbQ5g RJERNQf/d8G0r7APrOuxlwOL2j0j4JX5HZoR/ilD1eD6kSj3uZmCbl/DTZgN9uhj hMN9UTCVdF+NcWlqldwUVLLSq16/P821QLrbqKs4Q6i2NDwHIAU6VCneRZOUIOpl VOyQ+BJDavvqQ2gNziDK29sjG8JxWUqQ10fdphfrV1vS0Wd1fV1/Kk9I0ba+yv5O RiIyvbJobCEyNz52JdqbBsKjrSCtPh6qMra3IYm6EDJDnp+T8UpliB3RBIBuIPfU ALRageyqmE9+J5BFYxbd1Lx37mHXq1PZsSYd6L09Y9Wg5fJLHzWffd74SfJHwRza xZ/UTvCvkbGUbspT/U4mkuHwHzYXcg== =41vP -END PGP SIGNATURE-
OpenSSL version 1.1.1i published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.1.1i released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1i of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1i is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1i.tar.gz Size: 9808346 SHA1 checksum: eb684ba4ed31fe2c48062aead75233ecd36882a6 SHA256 checksum: e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee00d5242 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1i.tar.gz openssl sha256 openssl-1.1.1i.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl/PfcIACgkQ2cTSbQ5g RJGTdAgAg4vCZBf6Ugf0JojEHlqfxvdYTDPaz7C8vT4KFOsXW7vYr7Flc0O7rgfH hL/N25f8Ao4AlX1mtlq5whR6adf3dA3Ny3T5r8WNXy8a2GdC/AH7zSVI1+0yQ3L8 C1ohbRYUHgP9o6DjjSBylSgJzmwSK7CfBFbiq4MX/FeEqon+fy8Er5LMW7Cor2Tq 07a5532Gb67zuRPu/U5D6fFsXBDvzeDsT/c9ZMt0eImvmpU6wJNqALC+I0qI/pKY AY6FmljuYM3gr1aWbuCeyMbcGutRCFOLGrNl/VpQZFM5m7Rs6NQsQ+c3O5EICpoU NKmPlsXfAabUZpEaWKK/4mzXLgMxfw== =MgEX -END PGP SIGNATURE-
Re: Regarding #def for 'SSL_R_PEER_ERROR_NO_CIPHER' and 'SSL_R_NO_CERTIFICATE_RETURNED' in openssl3.0
On 07/12/2020 12:39, Matt Caswell wrote: On 04/12/2020 13:28, Narayana, Sunil Kumar wrote: Hi, We are trying to upgrade our application from openssl usage of 1.0.2 to openssl 3.0, during which we observe following errors. Looks like the below #def been removed from 1.1 onwards, Should application also need to take off from its usage ? or is there any alternative to be used in application ? 1.0.x -> 1.1.x is a breaking change, and so is 1.1.x to 3.0. Return codes are liable to change in these upgrades. error: 'SSL_R_PEER_ERROR_NO_CIPHER' was not declared in this scope This one was only ever used in the SSLv2 implementation. Since no one uses SSLv2 any more and it is considered highly insecure its implementation was removed some while ago. So the reason code was also deleted. So what error is returned by SSL3/TLS1.x when the client (erroneously) offers an empty cipher list? error: 'SSL_R_NO_CERTIFICATE_RETURNED' was not declared in this scope This reason code existed in 1.0.2 but was never used by anything. Matt 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
OpenSSL version 3.0.0-alpha9 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 3.0 alpha 9 released OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 9 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha9.tar.gz Size: 14058484 SHA1 checksum: 9b5faa69485659407583fd653f8064fb425fc0c4 SHA256 checksum: 5762545c972d5e48783c751d3188ac19f6f9154ee4899433ba15f01c56b3eee6 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha9.tar.gz openssl sha256 openssl-3.0.0-alpha9.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl+/wWAACgkQ2cTSbQ5g RJGGWQgAr12trYLeMYhAMzTnfQXOv+M16DrJyPZoyZyVNee3rcmOUA18Uiiji45F BlauG3D/ShIJZ4zMs/jjVRnc/MqAZBphgO4Ow0XlFl+fkqess9hk/buerNZs9lbu Xp/yRPO8d9hTB3ni1VPnaFlnRGKVZydR7p0s2b5j/ps6o0OVKwBxjFnX3Lr9loPs HkiXZMdmZp2woTJc+Ch5KCzpZcVAWs14v6ZgKsMLIxkD3iU1NjSacR4AAEdwhd4m 4X3GSOMTzHniOWEGaRKJM8nYiaKyajnq386re5wsqK1J6EqRTQ73QgXhK0Ge1lC0 Eh9Mmg/7ajFmjLThcWqJVgy2m+9/Gw== =t8pi -END PGP SIGNATURE-
TLS with Client Authentication using private key from Windows store
Hi, I am trying to use openssl to implement a client-side TLS connection with Client Authentication on Windows, using a non-exportable private key stored in the Windows Certificate Store. Currently, our code can use a private key stored in a local file, and if the key in the Windows store was exportable, I could export it and use it in the existing code. But the key is non-exportable, which is a problem. Does anyone know how to do this? So far, I have found suggestions to use the CAPI engine (eg. https://groups.google.com/g/mailing.openssl.users/c/_rdJLc7emAY?pli=1), but no examples of how to do that, and also some tickets (eg. https://github.com/openssl/openssl/issues/12859) which say that the CAPI engine does not work with TLS >= 1.2 on openssl 1.1.1, so that doesn't look like a good solution. Any help would be appreciated! Thank you, Ferenc
Re: Server application hangs on SS_read, even when client disconnects
(Top posting to match what Mr. André does): TCP without keepalive will time out the connection a few minutes after sending any data that doesn't get a response. TCP without keepalive with no outstanding send (so only a blocking recv) and nothing outstanding at the other end will probably hang almost forever as there is nothing indicating that there is actual data lost in transit. On 2020-11-13 17:13, Brice André wrote: Hello, And many thanks for the answer. "Does the server parent process close its copy of the conversation socket?" : I checked in my code, but it seems that no. Is it needed ? May it explain my problem ? " Do you have keepalives enabled?" To be honest, I did not know it was possible to not enable them. I checked with command "netstat -tnope" and it tells me that it is not enabled. I suppose that, if for some reason, the communication with the client is lost (crash of client, loss of network, etc.) and keepalive is not enabled, this may fully explain my problem ? If yes, do you have an idea of why keepalive is not enabled ? I thought that by default on linux it was ? Many thanks, Brice Le ven. 13 nov. 2020 à 15:43, Michael Wojcik mailto:michael.woj...@microfocus.com>> a écrit : > From: openssl-users mailto:openssl-users-boun...@openssl.org>> On Behalf Of Brice André > Sent: Friday, 13 November, 2020 05:06 > ... it seems that in some rare execution cases, the server performs a SSL_read, > the client disconnects in the meantime, and the server never detects the > disconnection and remains stuck in the SSL_read operation. ... > #0 0x7f836575d210 in __read_nocancel () from /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x7f8365c8ccec in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 > #2 0x7f8365c8772b in BIO_read () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 So OpenSSL is in a blocking read of the socket descriptor. > tcp 0 0 http://5.196.111.132:5413 <http://5.196.111.132:5413> http://85.27.92.8:25856 <http://85.27.92.8:25856> ESTABLISHED 19218/./MabeeServer > tcp 0 0 http://5.196.111.132:5412 <http://5.196.111.132:5412> http://85.27.92.8:26305 <http://85.27.92.8:26305> ESTABLISHED 19218/./MabeeServer > From this log, I can see that I have two established connections with remote > client machine on IP 109.133.193.70. Note that it's normal to have two connexions > because my client-server protocol relies on two distinct TCP connexions. So the client has not, in fact, disconnected. When a system closes one end of a TCP connection, the stack will send a TCP packet with either the FIN or the RST flag set. (Which one you get depends on whether the stack on the closing side was holding data for the conversation which the application hadn't read.) The sockets are still in ESTABLISHED state; therefore, no FIN or RST has been received by the local stack. There are various possibilities: - The client system has not in fact closed its end of the conversation. Sometimes this happens for reasons that aren't immediately apparent; for example, if the client forked and allowed the descriptor for the conversation socket to be inherited by the child, and the child still has it open. - The client system shut down suddenly (crashed) and so couldn't send the FIN/RST. - There was a failure in network connectivity between the two systems, and consequently the FIN/RST couldn't be received by the local system. - The connection is in a state where the peer can't send the FIN/RST, for example because the local side's receive window is zero. That shouldn't be the case, since OpenSSL is (apparently) blocked in a receive on the connection. but as I don't have the complete picture I can't rule it out. > This let me think that the connexion on which the SSL_read is listening is > definitively dead (no more TCP keepalive) "definitely dead" doesn't have any meaning in TCP. That's not one of the TCP states, or part of the other TCP or IP metadata associated with the local port (which is what matters). Do you have keepalives enabled? > and that, for a reason I do not understand, the SSL_read keeps blocked into it. The reason is simple: The connection is still established, but there's no data to receive. The question isn't why SSL_read is blocking; it's why you think the connection is gone, but the stack thinks otherwise. > Note that the normal behavior of my application is : client connects, server > daemon forks a new instance, Does the server parent process close its copy of the conversation socket? 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
RSA_METHOD.rsa_sign not called in FIPS mode
I'm using an OpenSSL engine that uses the RSA_FLAG_SIGN_VER flag and implements RSA_METHOD.rsa_sign() instead rsa_priv_enc(). This is mainly because of the requirement that it work with Windows CryptoAPI which does not support low-level RSA signing (see CAPI engine). Everything works as it should until FIPS mode is enabled. Under FIPS mode, the "non-implemented" rsa_priv_enc() is called and an error is returned. The simplified backtrace is: #0 rsa_priv_enc // non-implemented engine function #1 FIPS_rsa_sign_digest // FIPS canister #2 pkey_rsa_sign #3 EVP_SignFinal It appears that FIPS_rsa_sign_digest() never checks RSA_FLAG_SIGN_VER or calls rsa_sign() - it simply defaults to rsa_priv_enc(). I can't find any place rsa_sign is called. There are posts that specifically reference running CAPI with FIPS mode, so I don't know what I'm missing. http://openssl.6102.n7.nabble.com/FIPS-with-CAPI-Engine-td26273.html Using OpenSSL 1.0.2o and FIPS canister 2.0.2 (older but I checked the latest release and it behaves the same). Thank you. Paul
Re: How to make ocsp responder busy
On 2020-11-09 09:58, Venkata Mallikarjunarao Kosuri via openssl-users wrote: Hi We are trying to work scenario to openssl OCSP responder busy, but we are not sure how to make OCSP responder busy could please throw some pointer to work on. Ref https://www.openssl.org/docs/man1.0.2/man1/ocsp.html <https://www.openssl.org/docs/man1.0.2/man1/ocsp.html> Thanks Malli An OCSP responder is not supposed to be busy. Ever. CAs that are trusted by the big web browsers are contractually required to keep theirs available 24x7. The man page you reference doesn't contain the word "busy" 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
How to make ocsp responder busy
Hi We are trying to work scenario to openssl OCSP responder busy, but we are not sure how to make OCSP responder busy could please throw some pointer to work on. Ref https://www.openssl.org/docs/man1.0.2/man1/ocsp.html Thanks Malli
OpenSSL version 3.0.0-alpha8 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 3.0 alpha 8 released OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 8 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha8.tar.gz Size: 14011376 SHA1 checksum: a6063ebb15b4e600b60fbb50b3102c6f2e3438ff SHA256 checksum: a6c7b618a6a37cf0cebbc583b49e6d22d86e2d777e60173433eada074c32eea4 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha8.tar.gz openssl sha256 openssl-3.0.0-alpha8.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl+kBlYACgkQ2cTSbQ5g RJHOmQgAhqFZMut75DD4WChUdbwnlt+liy4SBVq+uG5zxSX8ayyiWoxkaQxMrI55 eyYWkLc05imDlM6dPgQQnBbLgDBUj6lPPN3bzAu/jPNC8Wk+9zwPdwLxKKnbMnoX gHGVFEuAJeILT6jldQwyHL1O+YV0KFANZE09jt/jBqaMtnT8pcVgxe+9txLtWVPw zLnh+t2Z9Pzhi8jz9I7LArVqgYOrnHHrFs1plzqz6YkTXCahGAoP5wtKFL1AS9eo J3EPrLNpLcYjLJWAt6kIgIP6J7pBxmqp5411b1dKAqSzNd6RTm8N11YNOP6lDCy9 28Mu393UJc5I8GvB+taGs8oMXxQCIQ== =Zocb -END PGP SIGNATURE-
How is the TLS Record Layer Version Selected?
Hello, how does openSSL determine the Record Layer Version used to initiate a ClientHello message to the server? I believe the determination is made at this level. When testing using multiple implementations (Python Requests on a Debian machine and `cURL --tlsv1.2 --tls-max 1.2` from macOS) I will seemingly at random see ClientHello messages using TLS Record Layer Version 1.0. The TLS Handshake Protocol remains correctly set at 1.2. The majority of the time the Record Layer Version is 1.2. What could be causing this change in Record Version? I realize this is a valid message format and that a well configured TLS 1.2 server will accept this. Just trying to get to the bottom of what is causing this behaviour on the client side. A post showing the Record Version and Handshake Protocol mismatch is here https://support.f5.com/csp/article/K53037818 Thomas
Fencepost errors in certificate and OCSP validity
Recently, the EJBCA developers publicly warned (via the Mozilla root store policy mailing list) other CA vendors that they had incorrectly implemented the handling of the "notAfter" X509 field, resulting in certificates that lasted 1 second longer than intended. Prompted by this warning, I checked what the OpenSSL code does, and it seems to be a bit more buggy: x509_vfy.c seems to be a bit ambivalent if certificate validity should be inclusive or exclusive of the time values in the certificate. apps.c seems to convert the validity duration in days as if the notAfter field is exclusive, but the notBefore field is inclusive. PKIX (RFC5280) says that both timestamps are inclusive, X.509 (10/2012) says nothing about this aspect of the interpretation of the validity structure. 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: CAPI engine seems to break server validation
On 2020-10-24 16:09, Brett Stahlman wrote: Jakob, I don't really understand why the engine *needs* to do PSS. Neither of the badssl certificates seem to use it for signatures. (I'm assuming the fact that a cert was signed with RSA-PSS would show up in the Windows certificate viewer...) If you could give a short summary of the problem as you understand it, perhaps it would help me narrow in on a workaround. I'd be happy with even an ugly patch at this point. Given that server verification works fine with a ca-bundle file, I wonder whether it would be possible to have the capi engine handle only the client authentication. As you understand it, would the problem breaking server verification also preclude client authentication with the capi engine? From the content of your mails, I inferred that whatever you tried to do caused OpenSSL to attempt to generate PSS signatures, but failing to pass that job to the CAPI engine. I was commenting on how that might be made to work. On Fri, Oct 23, 2020 at 11:34 AM Jakob Bohm via openssl-users mailto:openssl-users@openssl.org>> wrote: On 2020-10-23 15:45, Matt Caswell wrote: > > On 23/10/2020 14:10, Brett Stahlman wrote: >> It seems that the CAPI engine is breaking the server verification somehow. >> Note that the only reason I'm using the ca-bundle.crt is that I couldn't >> figure out how to get CAPI to load the Windows "ROOT" certificate >> store, which contains the requisite CA certs. Ideally, server >> authentication would use the CA certs in the Windows "ROOT" store, and >> client authentication would use the certs in the Windows "MY" store, but >> CAPI doesn't appear to be loading either one. > This is probably the following issue: > > https://github.com/openssl/openssl/issues/8872 > > Matt Looking at the brutal wontfixing of that bug, maybe reconsider if the existing engine interface can do PSS by simply having the CAPI/CAPIng engine export the generic PKEY type for PSS-capable RSA keys. Also, maybe use a compatible stronger CAPI "provider" (their engines) to do stronger hashes etc. 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: CAPI engine seems to break server validation
On 2020-10-23 15:45, Matt Caswell wrote: On 23/10/2020 14:10, Brett Stahlman wrote: It seems that the CAPI engine is breaking the server verification somehow. Note that the only reason I'm using the ca-bundle.crt is that I couldn't figure out how to get CAPI to load the Windows "ROOT" certificate store, which contains the requisite CA certs. Ideally, server authentication would use the CA certs in the Windows "ROOT" store, and client authentication would use the certs in the Windows "MY" store, but CAPI doesn't appear to be loading either one. This is probably the following issue: https://github.com/openssl/openssl/issues/8872 Matt Looking at the brutal wontfixing of that bug, maybe reconsider if the existing engine interface can do PSS by simply having the CAPI/CAPIng engine export the generic PKEY type for PSS-capable RSA keys. Also, maybe use a compatible stronger CAPI "provider" (their engines) to do stronger hashes etc. 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
OpenSSL support for MacOS Big Sur(Cross compilation for ARM architecture/Apple silicon)?
Hi All, As Apple is moving from Intel to ARM architecture, does OpenSSL support cross-compiling(using Xcode 12.2) on MacOS Big Sur for Apple silicon(ARM architecture)?If not, any expected date? Thanks,Vinay
OpenSSL version 3.0.0-alpha7 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 3.0 alpha 7 released OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 7 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha7.tar.gz Size: 14005200 SHA1 checksum: 1d05682f62b34038a37b196c7c43a21013f5f507 SHA256 checksum: 2884219ad2fae614c0f0d57b77af2f0720f32ffa3a569ac70bbf506bd8732298 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha7.tar.gz openssl sha256 openssl-3.0.0-alpha7.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl+IS5sACgkQ2cTSbQ5g RJGBOAgAidOQVOhw5N3tLVOD1EqNvg+0FoEugGtM0lXSBFXXbcKc12jV/e1INyw6 iaZImtypZtlrEfIYFQUkTfEzfGAYXK8E9Xx6GTIV41tacd516MWz7NtMJkZlp3Fb D2DcEutqTO3Xi3XS+pPElLxSMzuSgGt8ZqqTv7ZqgseN+1uB/tdKUPZqDO+DTSpz n/0oMnpsqJsEXqv3N5sS/2ASa9paLkLsIoChDeJzc5j41aKnMTgwAPqF2r8vLBfo k851L5S/gsMw5Y9M3ljM4IYNiU0/lneGnT//uYOnLAKY/s1I9hNcWC/Q63xrOoqT zukZ2NoqTcCYC+a0Vg3yBpjwSYuaSA== =hL/2 -END PGP SIGNATURE-
stunnel 5.57 released
Dear Users, I have released version 5.57 of stunnel. This is a security release. Make sure to upgrade if you use the "redirect" option. ### Version 5.57, 2020.10.11, urgency: HIGH * Security bugfixes - The "redirect" option was fixed to properly handle "verifyChain = yes" (thx to Rob Hoes). - OpenSSL DLLs updated to version 1.1.1h. * New features - New securityLevel configuration file option. - FIPS support for RHEL-based distributions. - Support for modern PostgreSQL clients (thx to Bram Geron). - Windows tooltip texts updated to mention "stunnel". - TLS 1.3 configuration updated for better compatibility. * Bugfixes - Fixed a transfer() loop bug. - Fixed memory leaks on configuration reloading errors. - DH/ECDH initialization restored for client sections. - Delay startup with systemd until network is online. - bin\libssp-0.dll removed when uninstalling. - A number of testing framework fixes and improvements. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: af5ab973dde11807c38735b87bdd87563a47d2fa1c72a07929fcfce80a600fe1 stunnel-5.57.tar.gz 6bcabe757e72a26463b054e7bf14d661b3a6734b4fa60dced491de170008d78c stunnel-5.57-win64-installer.exe 8bae28d1376a70df69f5d47c41ebb95443934ac6efb058aaa9ae299a391c83e0 stunnel-5.57-android.zip Best regards, Mike signature.asc Description: OpenPGP digital signature
Re: OpenSSL not accepting a certificate, whilst curl does.
tl;dr: Found an issue with update-ca-trust extract OpenSSL doing what it should, but update-ca-trust is only pushing the cert into some of the trust stores. Thanks Tomas On Tue, 29 Sep 2020 at 07:06, Tomas Mraz wrote: > > On Mon, 2020-09-28 at 22:35 +0100, John Robson via openssl-users wrote: > > Hi, > > > > I'm really struggling to get my head around a specific scenario that > > isn't behaving as I expect. Hopefully someone with more > > experience/knowledge can set me on the right path. > > > > Note - my attempts to reproduce this in a lab have been unsuccessful, > > although I don't have access to the server private key, so the > > attempts have been with a completely independent CA chain. > > > > > > I have a private CA, which has signed an intermediate certificate > > which has signed a server certificate for an internal web server > > which is used by various automated systems (all linux based). > > > > The webserver (Apache) has the server cert and key, defined and in > > use as well as the intermediate certificate defined as the chain > > certificate - this all shows as expected. > > > > I have then added the root certificate to the trusted certs for an > > automated system (populated `/etc/pki/ca-trust/source/anchors/` run > > `update-ca-trust extract`). > > > > After this curl no longer complains about the certificate from the > > web server (expected). > > However OpenSSL still does (unexpected), and I presume that for the > > same reason(s) urllib in Python also doesn't accept the certificate. > > If I manually feed `openssl verify` the certificates and chain then > > they all come back "OK". > > > > I've set up these systems a number of times with both self signed and > > CA signed certs and never seen this behaviour. > > ... > > > > OpenSSL: > > # openssl s_client -connect server.fqdn:443 > > CONNECTED(0007) > > depth=1 CN = CAINTER, O = org, C = XX > > verify error:num=2:unable to get issuer certificate > > issuer= CN = CAROOT, O = org, C = XX > > --8<-- > > Verify return code: 2 (unable to get issuer certificate) > What is the curl library linked to? Is it using OpenSSL or something > else, for example NSS, as the TLS library? What exact system are you > testing on? Running curl -v on a lab box it shows that curl is using NSS, which at least gives some reason for the different behaviour. The system is a dockerised monitoring utility (clue is in the email address) with the containers based on CentOS. > Are you sure you've put your CAROOT certificate to the system > certificate trust store? And/or is the trust store properly set up to > be loaded by OpenSSL by default? Curl complains about the certificate until I add the cert to the ca-trust, so I have a good degree of confidence that the cert has been installed into the trust store - and on all the systems I've installed thus far this has also been picked up by OpenSSL. openssl connect does negotiate a key and cipher, and there is a connection created, so I'm confident there isn't a key/cipher capability mismatch, it's just the certificate verification that is failing. Checking where OpenSSL is using for it's CA trust store: # openssl version -d OPENSSLDIR: "/etc/pki/tls" In that directory cert.pem is a symlink to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, which is subtly different from the /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt I had been searching earlier - however I still see the ROOTCA entry in the pem bundle (and they have identical timestamps, indicating that both were updated by the update-ca-trust extract command). I'm getting a closer look at those files to make sure that the cert has been correctly pushed into them. I can't imagine why it wouldn't have been, but it is the next logical thing to check. OK - The issue is that update-ca-trust extract command i was using doesn't do what I would expect from the docs (and previous experience) Even with the Root CA in the anchors directory it doesn't add it to the TLS ca store, it does add it elsewhere though. If I manually add it to the ca-bundle.trust.crt then OpenSSL does verify the cert correctly, but the cert gets pulled if I then run the update again, so that's not a good long term solution. Since I have the Root CA I can test adding it to a few different containers and see whether there is something about that cert that is causing the odd behaviour. Thanks to Tomas for reminding me there are various different cert trust stores, and for ensuring that I followed the correct path deep enough to figure out what was going on. Now to try and work out ca-certificate behaviour, Cheers, John
OpenSSL not accepting a certificate, whilst curl does.
Hi,
I'm really struggling to get my head around a specific scenario that isn't
behaving as I expect. Hopefully someone with more experience/knowledge can
set me on the right path.
Note - my attempts to reproduce this in a lab have been unsuccessful,
although I don't have access to the server private key, so the attempts
have been with a completely independent CA chain.
I have a private CA, which has signed an intermediate certificate which has
signed a server certificate for an internal web server which is used by
various automated systems (all linux based).
The webserver (Apache) has the server cert and key, defined and in use as
well as the intermediate certificate defined as the chain certificate -
this all shows as expected.
I have then added the root certificate to the trusted certs for an
automated system (populated `/etc/pki/ca-trust/source/anchors/` run
`update-ca-trust extract`).
After this curl no longer complains about the certificate from the web
server (expected).
However OpenSSL still does (unexpected), and I presume that for the same
reason(s) urllib in Python also doesn't accept the certificate.
If I manually feed `openssl verify` the certificates and chain then they
all come back "OK".
I've set up these systems a number of times with both self signed and CA
signed certs and never seen this behaviour.
I'm slightly at a loss as to what diagnostics I even need at this point...
so I've dropped a summary of relevant(?) diagnostics at this point below.
Thanks,
John
--
# Check that the root is installed into the trusted bundle:
# awk -v cmd='openssl x509 -noout -subject -serial -fingerprint; echo'
'/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-bundle.trust.crt |
grep -A1 CAROOT
subject= /CN=CAROOT/O=org/C=XX
serial=4D4C00241A7A17D0
# Check that the pem file I have is correct (serial matches above):
# openssl x509 -in CAROOT.pem -text | grep erial
Serial Number: 5569826994213492688 (0x4d4c00241a7a17d0)
# Check that the chain is contiguous:
# openssl x509 -text -noout -in CAROOT.pem | grep -A1 -e Ident -e erial
Serial Number: 5569826994213492688 (0x4d4c00241a7a17d0)
Signature Algorithm: sha256WithRSAEncryption
X509v3 Subject Key Identifier:
2A:3E:33:88:7E:19:35:7C:6E:9D:7C:63:90:80:B8:DF:96:5A:A8:9D
X509v3 Authority Key Identifier:
keyid:2A:3E:33:88:7E:19:35:7C:6E:9D:7C:63:90:80:B8:DF:96:5A:A8:9D
# openssl x509 -text -noout -in CAINTER.pem | grep -A1 -e Ident
X509v3 Subject Key Identifier:
FB:17:C5:BB:BD:AD:84:65:4F:16:A7:E8:FA:95:1D:C7:D9:29:45:6A
X509v3 Authority Key Identifier:
keyid:2A:3E:33:88:7E:19:35:7C:6E:9D:7C:63:90:80:B8:DF:96:5A:A8:9D
# openssl x509 -text -noout -in SERVER.pem | grep -A1 -e Ident
X509v3 Subject Key Identifier:
F5:26:E2:09:A4:41:EC:EE:75:E2:4E:E4:02:90:B7:CD:EB:FC:4E:EC
X509v3 Authority Key Identifier:
keyid:FB:17:C5:BB:BD:AD:84:65:4F:16:A7:E8:FA:95:1D:C7:D9:29:45:6A
To my eye those all look lined up, and the serial on the root still agrees.
CURL:
# curl https://server.fqdn
302 Found
Found
The document has moved https://server.fqdn:443/path/
">here.
OpenSSL:
# openssl s_client -connect server.fqdn:443
CONNECTED(0007)
depth=1 CN = CAINTER, O = org, C = XX
verify error:num=2:unable to get issuer certificate
issuer= CN = CAROOT, O = org, C = XX
--8<--
Verify return code: 2 (unable to get issuer certificate)
TCP vs TLS performance (2048 RSA AES)
Hi,I have just started using openssl for my project. I'm building small server application using intel QAT engine.1) I'm trying to find benchmark numbers for pure hardware based comparison between with or without QAT engine. I mmap the file which server will send (to eliminate disk performance). Any pointer where to find would be appreciated.2) I'm also trying to check if there is hardware based comparison between tcp vs tls. How much performance degradation I should expect when I start using tls instead of tcp(given it is small embedded server which is mmapping the file). I tried googling it and everywhere is mentions that there is no to very little performance effect between TCP & TLS but that is not what I see. I see performance degradation of magnitude of 10 times. I use per core measurement. For single core if TCP performance is 50K CPS per core and throughput is 10Gbps, when I modify it to use TLS 2048 RSA with AES performance foes down to ~1Gbps and 300CPS for 128K file download. I'm using home grown tcp stack and also bypassing linux kernel for networking. Thanks,Amy
Re: Are -DOPENSSLDIR -DENGINESDIR hard coded ?
> No, but show us your ./Configure line. > I regularly build into other directories. > > For instance: > ./Configure --prefix=/sandel/3rd/openssl-dtls-api linux-x86_64 > Thank you for the reply. I did go looking into the resultant Makefile and there I did see that the "--prefix=/opt/foo" is needed in order to target a new destination directory. So that problem is solved. However my compile fails *everywhere* today on a multitude of systems from Debian sid on amd64 to FreeBSD UNIX on amd64 and Debian on ppc64le and ppc64 big-endian. So I know I am doing something abundantly wrong. Dennis
crypto/threads_pthread.c:48:5: warning: implicit declaration of function ‘pthread_mutexattr_settype’
This is a strange error to get on Debian sid amd64 : /usr/bin/gcc-10 -I. -Iinclude -fPIC -pthread -std=iso9899:1999 -m64 -g -O0 -march=k8 -mtune=k8 -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -mpc80 -std=iso9899:1999 -m64 -g -O0 -march=k8 -mtune=k8 -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -mpc80 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/opt/bw/ssl\"" -DENGINESDIR="\"/opt/bw/lib/engines-1.1\"" -I/opt/bw/include -MMD -MF crypto/threads_pthread.d.tmp -MT crypto/threads_pthread.o -c -o crypto/threads_pthread.o crypto/threads_pthread.c crypto/threads_pthread.c: In function ‘CRYPTO_THREAD_lock_new’: crypto/threads_pthread.c:48:5: warning: implicit declaration of function ‘pthread_mutexattr_settype’; did you mean ‘pthread_mutexattr_destroy’? [-Wimplicit-function-declaration] 48 | pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); | ^ | pthread_mutexattr_destroy crypto/threads_pthread.c:48:38: error: ‘PTHREAD_MUTEX_RECURSIVE’ undeclared (first use in this function); did you mean ‘PTHREAD_MUTEX_RECURSIVE_NP’? 48 | pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); | ^~~ | PTHREAD_MUTEX_RECURSIVE_NP crypto/threads_pthread.c:48:38: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [Makefile:5104: crypto/threads_pthread.o] Error 1 make[1]: Leaving directory '/opt/bw/build/openssl-1.1.1h_debian_sid_5.8.0-2-amd64.004' make: *** [Makefile:174: all] Error 2 Command exited with non-zero status 2 Why should the include of pthread.h be absent here ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Are -DOPENSSLDIR -DENGINESDIR hard coded ?
I have been trying to build a debug version with no-asm into a /opt/foo directory but I always see : -DOPENSSLDIR="\"/usr/local/ssl\"" and -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" during the compile. Are these hard coded in somewhere ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
RE: ECDSA certificate question
Thanks Michael, I tried to invoke SM3 algorithm in command "openssl req -new -key eckey.pem -x509 -sm3 -nodes -days 365 -out cert.csr", unfortunately got the following error: 140320586413888:error:100C508A:elliptic curve routines:pkey_ec_ctrl:invalid digest type:crypto/ec/ec_pmeth.c:331: -Original Message- From: Michael Richardson Sent: Tuesday, September 22, 2020 4:36 PM To: Yan, Bob Cc: openssl-users@openssl.org Subject: Re: ECDSA certificate question Yan, Bob via openssl-users wrote: > Is there a way to generate a ECDSA certificate with SM2 typed public > key and ecdsa-with-SM3 as the signature algorithm in openssl 1.1.1x > version? I don't know the detail with the SM3, part, but have you seen: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-09 https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki but, 1.1.1 release notes say it supports SM3. I expect you need to tweak something when "openssl req" is run. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
ECDSA certificate question
Hello everybody, Is there a way to generate a ECDSA certificate with SM2 typed public key and ecdsa-with-SM3 as the signature algorithm in openssl 1.1.1x version? Thank you very much! Bob
OpenSSL version 1.1.1h published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.1.1h released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1h of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1h is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1h.tar.gz Size: 9810045 SHA1 checksum: 8d0d099e8973ec851368c8c775e05e1eadca1794 SHA256 checksum: 5c9ca8774bd7b03e5784f26ae9e9e6d749c9da2438545077e6b3d755a06595d9 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1h.tar.gz openssl sha256 openssl-1.1.1h.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl9p9DIACgkQ2cTSbQ5g RJG6pAf/Y6B3I9pwD6MG7lm3ywEqp2dAwYym84l39K6LrBFPOg76GmHLby92Se5/ N2S5uHPCcXrBdtHLZZTi1Tn3rwMN6EAJmedZJvMwoxeKJxNjZ2f8K8SjgUkuimSa dKbXtv92uDNRpD4X3Fv+uRatmbvygdjduwJWqgJ88ahz/IM7x1lv8E8GNnkPNBfA 9M9rDP5ThiQAetbefHBq9vb6wywwbi0FGTnXkeaYpyKDXmob0VWUdI0olMFLIUAG ZAQAD8XEPnJBVh4qCOlVy0n/5+jzcOiqcwJyORQc/U0wkV71I9XigW9H7wgg6skD iVQQe2QEODbEbtx9iMPsN4Ssmfk+VA== =OYam -END PGP SIGNATURE-
OpenSSL hard coded address 0xFB00000
Hi, We have been using a wrapper DLL on top of OpenSSL library in our product. While migrating to 1.0.2t, we are facing the initialization problem in FIPs mode. After analysis we found the following information in openssl guide.The standard OpenSSL build with the fips option will use abase address for libeay32.dll of 0xFB0 by default. This value was chosen because it isunlikely to conflict with other dynamically loaded libraries. In the event of a clash with anotherdynamically loaded library which will trigger runtime relocation of libeay32.dll, the integritycheck will fail with the error--- So, the root cause seems to be that our program is using the above mentioned address by the time initialization is called. It's happening with a web application where we are making use of JNI interface to make the relevant calls. In fact there are multiple layers here to access the openssl library calls. It's something like we are calling Library1 from web application, and library1 invokes library2 and then 3 and then openssl. Could someone help me in addressing this problem? We have no choice of rebuilding openssl library as the common wrapper (on top of it) is being used by multiple products. ThanksSai Srihari
Re: OpenSSL Security Advisory
On 2020-09-10 09:03, Tomas Mraz wrote: On Wed, 2020-09-09 at 22:26 +0200, Jakob Bohm via openssl-users wrote: Wouldn't a more reasonable response for 1.0.2 users have been to force on SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected cipher suites and telling affected people to recompile with the fix off? You seem to be mixing two different affected things. One is the static DH ciphersuites. There is no remediation for these except for not using them. Fortunately they are not really used by anyone. This can be achieved on the server side by simply not providing the DH certificate. On the client side they can be dropped from the ciphers string. This is the "deprecating affected cipher suites" change part. On the other hand the reuse of DH key for ephemeral DH can be only disabled by setting SSL_OP_SINGLE_DH_USE by the calling server application. This is the part relevant for wider audience. So yes, both issues can be remediated by application calling the OpenSSL library. On the other hand it is not always possible to change the application so we also provide fix to premium support customers in terms of changing the openssl code. The advisory didn't include this clarification, and didn't state if 1.0.2w fixes the DHE case by doing what 1.1.x does and act like SSL_OP_SINGLE_DH_USE is always set. 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: OpenSSL Security Advisory
On 2020-09-09 14:39, OpenSSL wrote: OpenSSL Security Advisory [09 September 2020] = Raccoon Attack (CVE-2020-1968) == Severity: Low The Raccoon attack exploits a flaw in the TLS specification which can lead to an attacker being able to compute the pre-master secret in connections which have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would result in the attacker being able to eavesdrop on all encrypted communications sent over that TLS connection. The attack can only be exploited if an implementation re-uses a DH secret across multiple TLS connections. Note that this issue only impacts DH ciphersuites and not ECDH ciphersuites. OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret and does not implement any "static" DH ciphersuites. OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH ciphersuite is used. These static "DH" ciphersuites are ones that start with the text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for these ciphersuites all start with "TLS_DH_" but excludes those that start with "TLS_DH_anon_". OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS connections in server processes unless the SSL_OP_SINGLE_DH_USE option was explicitly configured. Therefore all ciphersuites that use DH in servers (including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a response to CVE-2016-0701. Since the vulnerability lies in the TLS specification, fixing the affected ciphersuites is not viable. For this reason 1.0.2w moves the affected ciphersuites into the "weak-ssl-ciphers" list. Support for the "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause interoperability problems in most cases since use of these ciphersuites is rare. Support for the "weak-ssl-ciphers" can be added back by configuring OpenSSL at compile time with the "enable-weak-ssl-ciphers" option. This is not recommended. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w. If upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure that affected ciphersuites are disabled through runtime configuration. Also note that the affected ciphersuites are only available on the server side if a DH certificate has been configured. These certificates are very rarely used and for this reason this issue has been classified as LOW severity. This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and Juraj Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order to allow co-ordinated disclosure with other implementations. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of this issue on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20200909.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html Wouldn't a more reasonable response for 1.0.2 users have been to force on SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected cipher suites and telling affected people to recompile with the fix off? 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
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL Security Advisory [09 September 2020] = Raccoon Attack (CVE-2020-1968) == Severity: Low The Raccoon attack exploits a flaw in the TLS specification which can lead to an attacker being able to compute the pre-master secret in connections which have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would result in the attacker being able to eavesdrop on all encrypted communications sent over that TLS connection. The attack can only be exploited if an implementation re-uses a DH secret across multiple TLS connections. Note that this issue only impacts DH ciphersuites and not ECDH ciphersuites. OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret and does not implement any "static" DH ciphersuites. OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH ciphersuite is used. These static "DH" ciphersuites are ones that start with the text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for these ciphersuites all start with "TLS_DH_" but excludes those that start with "TLS_DH_anon_". OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS connections in server processes unless the SSL_OP_SINGLE_DH_USE option was explicitly configured. Therefore all ciphersuites that use DH in servers (including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a response to CVE-2016-0701. Since the vulnerability lies in the TLS specification, fixing the affected ciphersuites is not viable. For this reason 1.0.2w moves the affected ciphersuites into the "weak-ssl-ciphers" list. Support for the "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause interoperability problems in most cases since use of these ciphersuites is rare. Support for the "weak-ssl-ciphers" can be added back by configuring OpenSSL at compile time with the "enable-weak-ssl-ciphers" option. This is not recommended. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w. If upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure that affected ciphersuites are disabled through runtime configuration. Also note that the affected ciphersuites are only available on the server side if a DH certificate has been configured. These certificates are very rarely used and for this reason this issue has been classified as LOW severity. This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and Juraj Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order to allow co-ordinated disclosure with other implementations. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of this issue on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20200909.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl9YzBsACgkQ1enkP335 7oyIxg/9FWuca3/s/lY6g6a5VTPIekZMOLRUnDyzS3YePQu/sEd1w81mKoTqU+6F KQmliGqdRDk+KN8HDVd14kcLBukto8UKmkp9FpB5J4d2KK1I/Fg/DofJs6xUQYKb 5rHRLB3DDoyHEBzEEIjcqYTTThXW9ZSByVK9SKpC78IRM/B2dfd0+j4hIB/kDC/E G+wieFzexHQVdleVYT/VaJ6qS8AwvohBbt8h7yK0P6v/4vEm0spDbUmjWJBVUlUu QZyELjj8XZR3YFxt3axSuJg3JSGYlaMzkt2+DVq4qEzeJLIydLK9J8p6RNwPhsJk Rx0ez8P4N+5O7XmA0nHv3HyompdMgHlvykj8Ks4lNHVS02KKLi1jDtmOxl3Fm/hb ZNOmjn7lulV1342pw4rWL3Nge3x0s0Q5zgBCm1mqLzzu/V1ksx8FJwGA1w2cH280 dU9VedkC2wvFQije8pFrWH9l6N9Bh41DIEOnlBl0AL7IrbPdO6yMcD6vpR7hWjr3 fx4hNJSAGzJ3i/NXlSj4eR/47zkjfJyEc8Drc2QgewyqXFrK20X/LOj8MqJlc+ry pXZseh+XC8WaYDMV1ltrKvE2Ld9/0f3Ydc04AcDeu5SXPJG79ogzVnchZok7+XCj RT+a3/ES45+CTfL5v27t5QJxJcxg4siLVsILfi0rIUv0IYgH2fU= =U7OO -END PGP SIGNATURE-
Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option
Viktor, Thank you. Yury From: openssl-users on behalf of Viktor Dukhovni Sent: Tuesday, September 8, 2020 10:56 AM To: openssl-users@openssl.org Subject: Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option On Tue, Sep 08, 2020 at 05:39:51PM +, Yury Mazin via openssl-users wrote: > I have a question based on the response provided to me: > > My question is why following openssl commands (version 1.1.1f) return > those TLSv1.3 ciphers as offering no authentication and no encryption? It does not. You still have not understood that "-ciphers" constrains **ONLY** the TLS 1.2 (and earlier) cipher lists. When you say: ciphers ... NULL you asking for all the ciphers (TLS 1.2 and 1.3) where the TLS 1.2 ciphers are NULL. To also constrain the TLS 1.3 ciphers you MUST use the -ciphersuites ... option to list the desired TLS 1.3 ciphersuites, otherwise they remain unconstrained. -- Viktor.
Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option
Hello, I have a question based on the response provided to me: My question is why following openssl commands (version 1.1.1f) return those TLSv1.3 ciphers as offering no authentication and no encryption? C:\OpenText\iHub20.4-29324643-250C200831\ihub\modules\BIRTiHub\iHub\bin>openssl ciphers -v -s NULL TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD C:\OpenText\iHub20.4-29324643-250C200831\ihub\modules\BIRTiHub\iHub\bin>openssl ciphers -v -s eNULL TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD C:\OpenText\iHub20.4-29324643-250C200831\ihub\modules\BIRTiHub\iHub\bin>openssl ciphers -v -s aNULL TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD From: Yury Mazin Sent: Friday, September 4, 2020 12:43 PM To: openssl-users@openssl.org Subject: Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option Viktor, Thank you for clarifying it. Yury ____ From: openssl-users on behalf of Viktor Dukhovni Sent: Friday, September 4, 2020 12:10 PM To: openssl-users@openssl.org Subject: Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option On Fri, Sep 04, 2020 at 07:00:01PM +, Yury Mazin via openssl-users wrote: > Thank you Benjamin, > > According to OpenSSL , aNULL stands for no-authentication. Specifically, SSL 3.0 through TLS 1.2 ciphers in which the server and client exchange no certificates, and the TLS handshake consists largely of an unsigned anonymous ephemeral DH or ECDH key exchang. TLS 1.3 dropped support for anonymous DH and ECDH. Server certificates are *required. And the all-in-one ciphersuites of TLS <= 1.2, are replaced with separately negotiated components. As a result of which, in OpenSSL 1.1.1 and later, they are controlled via a different set of APIs and command-line options. Specifically, in your case, the "-ciphers aNULL" option only applies to TLS <= 1.2 > Does it mean that all 3 default protocols of TLS 1.3 offer no > authentication No. None of them "support no authentication" (which is not even strictly true, it is the protocol that does not support "no authentication", the TLS 1.3 ciphers are simply silent re certificate algorithm selection), but the "-cipher aNULL" is simply not used when TLS 1.3 is negotiated, so your question is makes incorrect assumptions to reach its tentative conclusions. -- Viktor.
Tunelling using OpenSSL.
Hello,Is it possible to tunnel a connection by OpenSSL? For example, use OpenSSL and a browser to encrypt browsing. Thank you.
Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option
Viktor, Thank you for clarifying it. Yury From: openssl-users on behalf of Viktor Dukhovni Sent: Friday, September 4, 2020 12:10 PM To: openssl-users@openssl.org Subject: Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option On Fri, Sep 04, 2020 at 07:00:01PM +, Yury Mazin via openssl-users wrote: > Thank you Benjamin, > > According to OpenSSL , aNULL stands for no-authentication. Specifically, SSL 3.0 through TLS 1.2 ciphers in which the server and client exchange no certificates, and the TLS handshake consists largely of an unsigned anonymous ephemeral DH or ECDH key exchang. TLS 1.3 dropped support for anonymous DH and ECDH. Server certificates are *required. And the all-in-one ciphersuites of TLS <= 1.2, are replaced with separately negotiated components. As a result of which, in OpenSSL 1.1.1 and later, they are controlled via a different set of APIs and command-line options. Specifically, in your case, the "-ciphers aNULL" option only applies to TLS <= 1.2 > Does it mean that all 3 default protocols of TLS 1.3 offer no > authentication No. None of them "support no authentication" (which is not even strictly true, it is the protocol that does not support "no authentication", the TLS 1.3 ciphers are simply silent re certificate algorithm selection), but the "-cipher aNULL" is simply not used when TLS 1.3 is negotiated, so your question is makes incorrect assumptions to reach its tentative conclusions. -- Viktor.
Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option
Thank you Benjamin, According to OpenSSL , aNULL stands for no-authentication. NULL-ciphers that you mention would be part of eNULL group, that offer no encryption. Does it mean that all 3 default protocols of TLS 1.3 offer no authentication (because they are listed under command openssl ciphers -v -s aNULL TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD Thank you, Yury From: Benjamin Kaduk Sent: Thursday, September 3, 2020 5:12 PM To: Yury Mazin Cc: openssl-users@openssl.org Subject: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option On Thu, Sep 03, 2020 at 11:45:28PM +, Yury Mazin via openssl-users wrote: > Hello, > > We have a server was originaly using OpenSSL 1.0.2h. > Server is configured to use SSL ciphers as following > ALL:!aNULL:!ADH:!EDH:!eNULL:!EXPORT > When openssl client tries to connect to this server with command > openssl s_client -connect localhost:8101-cipher aNULL > it fails, because any aNULL ciphers are not available per server > configuration. > We have now upgraded server to use OpenSSL 1.1.1f. > The current behavior is this: client can connect using the same command > openssl s_client -connect localhost:8101 -cipher aNULL > or > openssl s_client -tls1_3 -connect localhost:8101 -cipher aNULL > > while the same connect attempt using TLS1.2 protocol would still fail > > openssl s_client -tls1_2 -connect localhost:8001-cipher aNULL > > Would the fact that I can connect to the server using TLS 1.3 using the > following command (specifically, using -cipher aNULL, while server is > configured to exclude all aNULL cipher suites) considered a security > violation? > > openssl s_client -tls1_3 -connect localhost:8001 -cipher aNULL > > Also, if this a security violation, how this can be addressed in the server > configuration? > Lastly, if this is not a security violation, please explain. It is not a security violation, because you are using TLS 1.3 ciphers, and there are not any NULL-encryption TLS 1.3 ciphers. Configuration of TLS 1.3 ciphers and ciphers for previous versions of TLS are separate (since, at a protocol level, they serve different roles). See the documentation for s_client/s_server -ciphersuites for more information about TLS 1.3 ciphers. -Ben
A question about the “localhost.key” and “localhost.crt” files.
Hello, I think “localhost.crt” and “localhost.key” files using by Apache and they are mandatory for get a HTTPS certificate. Some tools like "Certbot" need them. If these files deleted then how can I regenerate them? Is below command OK? # openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/localhost.key -out /etc/ssl/certs/localhost.crt I found "/usr/libexec/httpd-ssl-gencerts" tool. Is it OK too? The "localhost" is the name of my server? If my server name in "/etc/hosts" file is "my-example.net" then these files name must be "my-example.net.key" and "my-example.net.crt" ? I'm thankful if anyone answer to my questions clearly. Thank you.
Re: Question about TLS 1.3 and openssl -cipher aNULL option
On Thu, Sep 03, 2020 at 11:45:28PM +, Yury Mazin via openssl-users wrote: > Hello, > > We have a server was originaly using OpenSSL 1.0.2h. > Server is configured to use SSL ciphers as following > ALL:!aNULL:!ADH:!EDH:!eNULL:!EXPORT > When openssl client tries to connect to this server with command > openssl s_client -connect localhost:8101-cipher aNULL > it fails, because any aNULL ciphers are not available per server > configuration. > We have now upgraded server to use OpenSSL 1.1.1f. > The current behavior is this: client can connect using the same command > openssl s_client -connect localhost:8101 -cipher aNULL > or > openssl s_client -tls1_3 -connect localhost:8101 -cipher aNULL > > while the same connect attempt using TLS1.2 protocol would still fail > > openssl s_client -tls1_2 -connect localhost:8001-cipher aNULL > > Would the fact that I can connect to the server using TLS 1.3 using the > following command (specifically, using -cipher aNULL, while server is > configured to exclude all aNULL cipher suites) considered a security > violation? > > openssl s_client -tls1_3 -connect localhost:8001 -cipher aNULL > > Also, if this a security violation, how this can be addressed in the server > configuration? > Lastly, if this is not a security violation, please explain. It is not a security violation, because you are using TLS 1.3 ciphers, and there are not any NULL-encryption TLS 1.3 ciphers. Configuration of TLS 1.3 ciphers and ciphers for previous versions of TLS are separate (since, at a protocol level, they serve different roles). See the documentation for s_client/s_server -ciphersuites for more information about TLS 1.3 ciphers. -Ben
Question about TLS 1.3 and openssl -cipher aNULL option
Hello, We have a server was originaly using OpenSSL 1.0.2h. Server is configured to use SSL ciphers as following ALL:!aNULL:!ADH:!EDH:!eNULL:!EXPORT When openssl client tries to connect to this server with command openssl s_client -connect localhost:8101-cipher aNULL it fails, because any aNULL ciphers are not available per server configuration. We have now upgraded server to use OpenSSL 1.1.1f. The current behavior is this: client can connect using the same command openssl s_client -connect localhost:8101 -cipher aNULL or openssl s_client -tls1_3 -connect localhost:8101 -cipher aNULL while the same connect attempt using TLS1.2 protocol would still fail openssl s_client -tls1_2 -connect localhost:8001-cipher aNULL Would the fact that I can connect to the server using TLS 1.3 using the following command (specifically, using -cipher aNULL, while server is configured to exclude all aNULL cipher suites) considered a security violation? openssl s_client -tls1_3 -connect localhost:8001 -cipher aNULL Also, if this a security violation, how this can be addressed in the server configuration? Lastly, if this is not a security violation, please explain. Thank you, Yury Mazin
Re: Testing
On 2020-09-03 12:25, Marc Roos wrote: Why are you defending amazon? Everyone processing significant mail and http traffic is complaining about them. They were even listed in spamhaus's top 10 abuse networks (until they started contributing to them?) Because we are sending non-spam mail from an AWS hosted server, and would be seriously inconvenienced if they got generally banned by mail recipients. And we did check that they were not in bad standing at spamhaus.org before choosing them to host that server. Some of their competitors failed those checks. 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: Testing
On 2020-09-03 09:42, Marc Roos wrote: PTR record, SPF, DKIM and DMARC are also set by spammers, and sometimes even just before a spam run. It is either choosing to do amazons work or not having any work. If more and more are blocking the amazon cloud it would make their clients leave and this finally migth have them spend more on their abuse department. For your information, AWS apparently blocks TCP port 25 unless the customer (not someone hacking an AWS instance) explicitly requests a custom PTR record using a form where the customer promises not to Spam. Custom PTR records don't look like ec2-184-72-79-140.compute-1.amazonaws.com . I am unsure how Richard's example that obviously tricked a server to send a HTTP request to the OpenSSL mail server got past the port 25 block (this appears to be a common form of server side request forgery). -Original Message- To: openssl-users@openssl.org Subject: Re: Testing On 2020-08-31 16:28, Marc Roos wrote: Why don't you block the whole compute cloud of amazon? ec2-3-21-30-127.us-east-2.compute.amazonaws.com Please note, that at least our company hosts a secondary MX in the EC2 cloud, with the option to direct my posts to the list through that server. However proper PTR record, SPF, DKIM and DMARC checks should all pass for such posts. Thus rather than blindly blacklisting the Amazon hosting service, maybe make the OpenSSL mail server check those things to catch erroneous transmissions from web servers. -Original Message----- To: openssl-users@openssl.org Subject: Testing -- -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave .html ** ** Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE- 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: Cert hot-reloading
On 2020-09-01 06:57, Viktor Dukhovni wrote: On Mon, Aug 31, 2020 at 11:00:31PM -0500, David Arnold wrote: 1. Construe symlinks to current certs in a folder (old or new / file by file) 2. Symlink that folder 3. Rename the current symlink to that new symlink atomically. This is fine, but does not provide atomicity of access across files in that directory. It just lets you prepare the new directory with non-atomic operations on the list of published files or file content. But if clients need to see consistent content across files, this does not solve the problem, a client might read one file before the symlink is updated and another file after. To get actual atomicity, the client would need to be sure to open a directory file descriptor, and then openat(2) to read each file relative to the directory in question. Most application code is not written that way, but conceivably OpenSSL could have an interface for loading a key and certchain from two (or perhaps even more for the cert chain) files relative to a given directory. I know how to do this on modern Unix systems, no idea whether something similar is possible on Windows. On NT-based window, the undocumented Zw family of file I/O syscalls would do what you call "openat()", "current dir" is in fact a directory handle plus string equivalent stored in a user mode variable in one of the core shared objects, which is why rmdir fails if it is the current directory of any process. The above is *complicated*. Requiring a single file for both key and cert is far simpler. Either PEM with key + cert or perhaps (under duress) even PKCS#12. Does it look like we are actually getting somewhere here? So far, not much, just some rough notes on the obvious obstacles. There's a lot more to do to design a usable framework for always fresh keys. Keeping it portable between Windows and Unix (assuming MacOS will be sufficiently Unix-like) and gracefully handling processes that drop privs will be challenging. Not all applications will want the same approach, so there'd need to be various knobs to set to choose one of the supported modes. Perhaps the sanest approach (but one that does nothing for legacy applications) is to provide an API that returns the *latest* SSL_CTX via some new handle that under the covers constructs a new SSL_CTX as needed. SSL_CTX *SSL_Factory_get1_CTX(SSL_CTX_FACTORY *); This would yield a reference-counted SSL_CTX that each caller must ultimately release via SSL_CTX_free() to avoid a leak. ... factory construction API calls ... ctx = SSL_Factory_get1_CTX(factory);-- ctx ref count >= 1 SSL *ssl = SSL_CTX_new(ctx);-- ctx ref count >= 2 ... SSL_free(ssl); -- ctx ref count >= 1 SSL_CTX_free(ctx); -- ctx may be freed here To address the needs of legacy clients is harder, because they expect an SSL_CTX "in hand" to be valid indefinitely, but now we want to be able age out and free old contexts, so we want some mechanism by which it becomes safe to free old contexts that we're sure no thread is still using. This is difficult to do right, because some thread may be blocked for a long time, before becoming active again and using an already known SSL_CTX pointer. It is not exactly clear how multi-threaded unmodified legacy software can be ensured crash free without memory leaks while behind the scenes we're constantly mutating the SSL_CTX. Once a pointer to an SSL_CTX has been read, it might be squirreled away in all kinds of places, and here's just no way to know that it won't be used indefinitely. 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: Cert hot-reloading
On 2020-09-01 04:26, Viktor Dukhovni wrote: On Aug 31, 2020, at 10:57 PM, Jakob Bohm via openssl-users wrote: Given the practical imposibility of managing atomic changes to a single POSIX file of variable-length data, it will often be more practical to create a complete replacement file, then replace the filename with the "mv -f" command or rename(3) function. This would obviously only work if the directory remains accessible to the application, after it drops privileges and/or enters a chroot jail, as will already be the case for hashed certificate/crl directories. There is no such "impossibility", indeed that's what the rename(2) system call is for. It atomically replaces files. Note that mv(1) can hide non-atomic copies across file-system boundaries and should be used with care. Note that rename(3) and link(2) do replace the file name, by making the replaced name point to a new inode, thus it would not work with calls thatmonitor an inode for content or statis change. There is no basic series of I/O calls that completely replace file contents inone step, in particular write(2) doesn't shorten the file if the new contentsis smaller than the old contents. And this is why I mentioned retaining an open directory handle, openat(2), ... There's room here to design a robust process, if one is willing to impose reasonable constraints on the external agents that orchestrate new cert chains. As for updating two files in a particular order, and reacting only to changes in the one that's updated second, this behaves poorly when updates are racing an application cold start. The single file approach, by being more restrictive, is in fact more robust in ways that are not easy to emulate with multiple files. What exactly is that "cold start" race you are talking about? Obviously, coding the logic to react badly to only one of two files being present would not work with rules that one of those two needs to arrive/change after the other. If someone implements a robust design with multiple files, great. I for one don't know of an in principle decent way to do that without various races, other than somewhat kludgey retry loops in the application (or library) when it finds a mismatch between the cert and the key. 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: Cert hot-reloading
On 2020-09-01 01:52, Viktor Dukhovni wrote: On Sun, Aug 30, 2020 at 07:54:34PM -0500, Kyle Hamilton wrote: I'm not sure I can follow the "in all cases it's important to keep the key and cert in the same file" argument, particularly in line with openat() usage on the cert file after privilege to open the key file has been dropped. I agree that key/cert staleness is important to address in some manner, but I don't think it's necessarily appropriate here. Well, the OP had in mind very frequent certificate chain rollover, where presumably, in at least some deployments also the key would roll over frequently along with the cert. If the form of the key/cert rollover is to place new keys and certs into files, then *atomicity* of these updates becomes important, so that applications loading a new key+chain pair see a matching key and certificate and not some cert unrelated to the key. This, e.g., Postfix now supports loading both the key and the cert directly from the same open file, reading both sequentially, without racing atomic file replacements when reopening the file separately to reach keys and certs. If we're going to automate things more, and exercise them with much higher frequency. The automation needs to be robust! Another synchronization method would be for the application to decree a specific order of changing the two files, such that triggering reload on the second file would correctly load the matching contents of the other. If a future OpenSSL version includes an option to detect such change, documentation as to which file it watches for changes would guide applications in choosing which order to specify for changing the files. Note that nothing prevents applications that have separate configuration for the key and cert locations from opening the same file twice. If they're using the normal OpenSSL PEM read key/cert routines, the key is ignored when reading certs and the certs are ignored when reading the key. Therefore, the single-file model is unconditionally superior in this context. Yes, some tools (e.g. certbot), don't yet do the right thing and atomically update a single file with both the key and the obtained certs. This problem can be solved. We're talking about new capabilities here, and don't need to adhere to outdated process models. Given the practical imposibility of managing atomic changes to a single POSIX file of variable-length data, it will often be more practical to create a complete replacement file, then replace the filename with the "mv -f" command or rename(3) function. This would obviously only work if the directory remains accessible to the application, after it drops privileges and/or enters a chroot jail, as will already be the case for hashed certificate/crl directories. 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: Testing
On 2020-08-31 16:28, Marc Roos wrote: Why don't you block the whole compute cloud of amazon? ec2-3-21-30-127.us-east-2.compute.amazonaws.com Please note, that at least our company hosts a secondary MX in the EC2 cloud, with the option to direct my posts to the list through that server. However proper PTR record, SPF, DKIM and DMARC checks should all pass for such posts. Thus rather than blindly blacklisting the Amazon hosting service, maybe make the OpenSSL mail server check those things to catch erroneous transmissions from web servers. -Original Message- To: openssl-users@openssl.org Subject: Testing -- -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE- 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: Real MTU problems with BIO pair
On Fri, Aug 21, 2020 at 05:05:51PM +0200, Detlef Vollmann wrote: > On 2020-08-20 21:44, Detlef Vollmann wrote: > > > > Is there any way to set the maximum fragment size for > > DTLS handshake with a BIO pair? > One solution is to set the MTU and the int_bio size to > exactly the same value. > Another option would be to use BIO_set_callback_ex() and send > the data to the socket after each BIO_write() into int_bio, > but the problem here is that BIO_set_data() cannot be used > as the ptr is already used for the peer address. There's always EX_DATA... -Ben
Re: OpenSSL compliance with Linux distributions
The key thing to do is to make those client applications not request the ssl23-method from OpenSSL 0.9.x . ssl23 explicitly requests this backward-compatibility feature while OpenSSL 3.x.x apparently deleted the ability to respond to this "historic" TLS hello format, which is also sent by some not-that-old web browsers. On 05/08/2020 22:19, Skip Carter wrote: Patrick, I am also supporting servers running very old Linux systems and I can tell you that YES you can upgrade from source. I have built openssl-1.1.1 from source on such systems with no problems. On Wed, 2020-08-05 at 21:49 +0200, Patrick Mooc wrote: Hello, I'm using an old version of OpenSSL (0.9.8g) on an old Linux Debian distribution (Lenny). Is it possible to upgrade OpenSSL version without upgrading Linux Debian distribution ? If yes, up to which version of OpenSSL ? Are all versions of OpenSSL compliant with all Linux Debian distribution ? Thank you in advance for your answer. Best Regards, 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: Software that uses OpenSSL
On 06/08/2020 22:17, Quanah Gibson-Mount wrote: --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). It's not an odd take. The SSLeay license explicitly bans releasing OpenSSL code under the GPL (as part of SSLeay's own copyleft provisions). GPL version 2 explicitly prohibits OS bundled GPL code from linking to OS-bundled non-GPL code, so this can be done only by violating the SSLeay license. So no OS distribution can include GPL 2 code using OpenSSL 1.x.x GPL version 2 explicitly allows independently distibuted copies of GPL 2 programs to link to any OS-bundled libs, including OS-bundled OpenSSL (this clause was intended to allow linking to stuff like the Microsoft or Sun OS libraries) Some GPL version 2 programs include an extra license permission to link against OpenSSL even when those GPL version 2 programs are bundled with the OS. Hopefully with OpenSSL 3.0 and later, this won't be as much of an issue. Does the Apache 2.0 license allow redistributing code under GPL 2 ? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> 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: Wrong signature type error trying to connect to gibs.earthdata.nasa.gov on Ubuntu 20.04
Hi Tomáš, thank you very much for the clarification. Best regards. Andrea Il 14/08/2020 08:41, Tomas Mraz ha scritto: > The server apparently doesn't support them which indicates that it is > some older implementation but that doesn't necessarily mean it is > non-compliant. It is just less capable.
Wrong signature type error trying to connect to gibs.earthdata.nasa.gov on Ubuntu 20.04
Hi all, on Ubuntu 20.04 LTS 64 bit, with OpenSSL version 1.1.1f, it is not possible to connect to a popular GIS OGC server at gibs.earthdata.nasa.gov:443 using OpenSSL or cUrl or Wget default parameters. The OpenSSL 1.1.1f package available for Ubuntu 20.04 is build with the "-DOPENSSL_TLS_SECURITY_LEVEL=2" option. The relevant errors are: "SSL routines:tls12_check_peer_sigalg:wrong signature type:../ssl/t1_lib.c:1145" and "SSL3 alert write:fatal:handshake failure". On the same machine it is possible to connect to that server using Firefox version 79.0 (the reported connection security properties are "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS 1.2") or gnutls-cli version 3.6.13 (the reported connection security properties are "(TLS1.2-X.509)-(ECDHE-SECP384R1)-(RSA-SHA1)-(AES-256-GCM)"). The connection is also possible on Ubuntu 18.04 (OpenSSL 1.1.1 without the "-DOPENSSL_TLS_SECURITY_LEVEL=2" build option). I already know the source of the issue (the server uses SHA1 as peer signing digest which is not allowed at SECURITY LEVEL = 2) and how to workaround it (setting SECLEVEL=1 as a cli option or in openssl.cnf), but I'd like to know if it is due to a misconfigured / non compliant server or to a bug in OpenSSL. In the former case, I'd like to know some technical specifications to refer to in order to submit the issue to the gibs.earthdata.nasa.gov system administrators so that they can understand the problem and configure the server correctly. Best regards. Andrea Giudiceandrea Note: see the following excerpts from the connection logs: ** $ openssl s_client -state -connect gibs.earthdata.nasa.gov:443 CONNECTED(0003) SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello depth=2 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2009 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G2 verify return:1 depth=1 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1K verify return:1 depth=0 C = US, ST = Maryland, L = Greenbelt, O = NASA (National Aeronautics and Space Administration), CN = gibs.earthdata.nasa.gov verify return:1 SSL_connect:SSLv3/TLS read server certificate SSL3 alert write:fatal:handshake failure SSL_connect:error in error 139920655459648:error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type:../ssl/t1_lib.c:1145: [...] --- No client certificate CA names sent Server Temp Key: ECDH, P-384, 384 bits --- SSL handshake has read 5443 bytes and written 322 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : Session-ID: 12B3427E761029EDED05CB26B3DD854ADE7B0D68061C2515A60A8A297AC968DB Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1597339233 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- ** ** $ openssl s_client -connect gibs.earthdata.nasa.gov:443 -cipher DEFAULT@SECLEVEL=1 CONNECTED(0003) depth=2 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2009 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G2 verify return:1 depth=1 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1K verify return:1 depth=0 C = US, ST = Maryland, L = Greenbelt, O = NASA (National Aeronautics and Space Administration), CN = gibs.earthdata.nasa.gov verify return:1 [...] --- No client certificate CA names sent Peer signing digest: SHA1 Peer signature type: RSA Server Temp Key: ECDH, P-384, 384 bits --- SSL handshake has read 5503 bytes and written 483 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: A48C668A8154E1A81137873D8D7D6CCF77B4C31729074C8C37A67B4A1CE9B155 Session-ID-ctx: Master-Key: D0147A71395D3336D998B1499630E4D4BA965F1BC9D8E526EF232A7D15ECC7989AE3A8844693D628C47B76A7BA8BFC4B PSK identity: None PSK identity hint: None SRP username: None Start Time: 1597384544 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- **
Re: NULL ciphers
On Thu, Aug 13, 2020 at 08:19:10PM +0200, Detlef Vollmann wrote: > Hello, > > with the following commands: > > openssl s_server -accept 18010 -cert srv.crt -key test.key \ > -CAfile testca.crt -debug -cipher 'NULL-SHA256' -dtls1_2 > > openssl s_client -connect localhost:18010 -cert clnt.crt \ > -key test.key -CAfile testca.crt -debug \ > -cipher 'COMPLEMENTOFALL:eNULL' -dtls1_2 > > NULL ciphers work fine with OpenSSL 1.0.2g. > > With OpenSSL 1.1.1g the handshake fails on the server side with > 140295725053248:error:14102438:SSL routines:dtls1_read_bytes:tlsv1 \ > alert internal error:../ssl/record/rec_layer_d1.c:611:SSL alert number \ > 80 > > Even on OpenSSL 1.1.1g 'openssl ciphers -v NULL' lists NULL-SHA256. > > I'm only using s_server and s_client as tests, but I have the same > problem in my application if I use > SSL_CTX_set_cipher_list(sslCtx, "NULL-SHA256"); > > What can I do to get NULL ciphers for no encryption working? -cipher 'COMPLEMENTOFALL:eNULL@SECLEVEL=0'
Re: [EXTERNAL] Re: odd error for ECDSA key in REQ.
The key itself is good. Its encoding in the CSR isn't.
Looks like the public key was X9.62 encoded in its uncompressed form (i.e.
start with a 04 octet, and then the octets composing the x and y coordinates),
and then wrapped into an ASN.1 OCTET STRING (i.e. use the 04 tag, plus a 0x41
length, and the encoded public key), and finally the BIT STRING encapsulation.
The OCTET STRING is wrong here.
Cordialement,
Erwann Abalea
Le 08/08/2020 14:24, « openssl-users au nom de Dirk-Willem van Gulik »
a écrit :
The key is generated by a lovely HSM - which is by its nature a bit of a
closed box. Whose vendor is very sure its software is right.
So this helps a lot - and helps confirm what we thought !
Thanks,
Dw
> On 8 Aug 2020, at 04:16, Frank Migge wrote:
>
> Hi Dirk-Willem,
>
> Something is wrong with your EC key. The error mentions that it can't
> get the curve points from the key data. How did you generate the key?
>
> If it helps, here is a working CSR example, using a prime256v1 key for
> comparison:
>
> -BEGIN CERTIFICATE REQUEST-
> MIIBDjCBtAIBADArMQswCQYDVQQGEwJKUDEcMBoGA1UEAwwTdGVzdCBmb3IgcHJp
> bWUyNTZ2MTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOMQV0Vep+9Xnje6bKNy
> +8blwKEscr5LoUQCuwqaUT4HyPgXFE9E0r1PiWbC6bGkS26MuguOBp52X9H9z+NS
> zM6gJzAlBgkqhkiG9w0BCQ4xGDAWMBQGA1UdEQQNMAuCCWZtNGRkLmNvbTAKBggq
> hkjOPQQDAgNJADBGAiEA5uYlfkpRsJhBk+WwippCjupEpaCNaHwNyNqbj8qrR80C
> IQDCoJtaWhFGxbaAB2+o3gm87ZHJSDSjfrD2lEhlkbEXHQ==
> -END CERTIFICATE REQUEST-
>
>
> $ openssl req -inform PEM -noout -pubkey -in test.csr
> -BEGIN PUBLIC KEY-
> MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE4xBXRV6n71eeN7pso3L7xuXAoSxy
> vkuhRAK7CppRPgfI+BcUT0TSvU+JZsLpsaRLboy6C44GnnZf0f3P41LMzg==
> -END PUBLIC KEY-
>
>
> On Fri, 2020-08-07 at 19:07 +0200, Dirk-Willem van Gulik wrote:
>> Below CSR gives me an odd error with the standard openssl REQ
>> command:
>>
>> openssl req -inform DER -noout -pubkey
>>
>> Error getting public key
>>
>> 140673482679616:error:10067066:elliptic curve
>> routines:ec_GFp_simple_oct2point:invalid
>> encoding:../crypto/ec/ecp_oct.c:312:
>> 140673482679616:error:10098010:elliptic curve
>> routines:o2i_ECPublicKey:EC lib:../crypto/ec/ec_asn1.c:1175:
>> 140673482679616:error:100D708E:elliptic curve
>> routines:eckey_pub_decode:decode error:../crypto/ec/ec_ameth.c:157:
>> 140673482679616:error:0B09407D:x509 certificate
>> routines:x509_pubkey_decode:public key decode
>> error:../crypto/x509/x_pubkey.c:125:
>>
>> Even though the ASN1 of the public key looks correct to me:
>>
>>SEQUENCE (2 elem)
>> SEQUENCE (2 elem)
>>OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62
>> public key type)
>>OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62
>> named elliptic curve)
>> BIT STRING (536 bit)
>> 01000101011110010011001110011100011010001010010110100
>> 0…
>>OCTET STRING (65 byte)
>> 0439339C68A5A333143592C0A36D053F31D3AF6ED18FB54F4747B9DFC6DB6ABC71556
>> 1…
>>
>> What would be a good way to further debug this ?
>>
>> With kind regards,
>>
>> Dw
>>
>> -BEGIN CERTIFICATE REQUEST-
>> MIIBPzCB5QIBADCBgDELMAkGA1UEAxMCQ04xCjAIBgNVBAUTATExCjAIBgNVBAYT
>> AUMxCjAIBgNVBAcTAUwxCjAIBgNVBAgTAVMxCjAIBgNVBAoTAU8xCzAJBgNVBAsT
>> Ak9VMQowCAYDVQQMEwFUMQowCAYDVQQNEwFEMRAwDgYJKoZIhvcNAQkBEwFFMFsw
>> EwYHKoZIzj0CAQYIKoZIzj0DAQcDRAAEQQQ5M5xopaMzFDWSwKNtBT8x069u0Y+1
>> T0dHud/G22q8cVVh8sVcpLUortLxxesEXCddpx/EeuxP+MN/RymHTMrjoAAwCgYI
>> KoZIzj0EAwIDSQAwRgIhAO+K+TFCdYxQg7aT+B3wIVa6CCYxM/mL4/WHSrwXujJy
>> AiEA7UsbQT/YRKaFDPn/U9jdrJaUmKsqKJvGwN7YVaMGdeo=
>> -END CERTIFICATE REQUEST-
>
>
> --
> Frank Migge
> http://fm4dd.com | pub...@frank4dd.com
>
OpenSSL version 3.0.0-alpha6 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 3.0 alpha 6 released OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 6 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha6.tar.gz Size: 13963353 SHA1 checksum: bac4e232f5238c5f267c3e108227cfadbd4b7120 SHA256 checksum: 1e8143b152f33f76530da2eaedc5d841121ff9e7247a857390cceac6503f482b The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha6.tar.gz openssl sha256 openssl-3.0.0-alpha6.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl8r/u0ACgkQ2cTSbQ5g RJFJhgf8C6Wv+1W8JolzZ2erbPSDFXTUjOJGvqnR2+73wtYMkzZKMnYTpqiW9Jrx 5V6zQ2WIYhnWZ97nSP0woo/h3tr8rQIj71Cj3TPqO11zOrXda9Op+P9ncCNNXTuz /BS4HmnicV/pmrd2JMnFmo58tka9K47DhcACMKxuWPr32F40DJcr/yjvYnlf6k7y s5EWK7tv7NLYWu+UN+JO6LpJrTFWRTajQj2OEZh3+Gm07Qv98TaXXr3QeiEpimu6 xbDi8oCcAzA+bKr1WpTCNYIU9H6QZIc0QqPjhSsS9o64RDlK7laRQ6ETMmePxDUK u812RauTlxNuJHjy34a9k38kirPHaQ== =uzj7 -END PGP SIGNATURE-
Re: 'in_addr_t' in openssl 1.1.1g ??
Ah, so it really is the "gcc" configure target (I had to look up that such a thing even existed!). Unfortunately, 'gcc' implies 32-bit, and your x86_64-fslsdk-linux suggests that you're targetting a 64-bit system. Such a mismatch of configurations could easily cause this sort of compile error due to inconsistent input to the preprocessor conditionals. Would linux-x86_64 be more appropriate for your system? -Ben On Thu, Aug 06, 2020 at 02:23:40AM +0530, prudvi raj wrote: > Another thing , 'make && make all ' is successful , but the same openssl > files when compiled during my project's compilation show this error . > PROJECT DIR << make project here compiles all files. > |- ..folder 1. > |- openssl > |-... > Btw, Project uses same CC - > "/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe-gcc" > Hope this clears some things up. > $ ./configdata.pm -d > > Command line (with current working directory = .): > > /usr/bin/perl ./Configure no-threads no-dso no-ct no-shared no-zlib > no-asm no-engine no-bf no-aria no-blake2 no-camellia no-cast no-md2 no-md4 > no-mdc2 no-ocsp no-rc2 no-rc5 no-hw-padlock no-idea no-srp gcc > --with-rand-seed=none > --cross-compile-prefix=/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe- > > Perl information: > > /usr/bin/perl > 5.10.1 for x86_64-linux-thread-multi > > Enabled features: > > async > autoalginit > autoerrinit > autoload-config > buildtest-c\+\+ > capieng > chacha > cmac > cms > comp > deprecated > des > dgram > dh > dsa > dtls > ec > ec2m > ecdh > ecdsa > err > filenames > gost > hw(-.+)? > makedepend > multiblock > nextprotoneg > pinshared > ocb > poly1305 > posix-io > psk > rc4 > rdrand > rfc3779 > rmd160 > scrypt > seed > siphash > sm2 > sm3 > sm4 > sock > srtp > sse2 > ssl > static-engine > stdio > tests > tls > ts > ui-console > whirlpool > tls1 > tls1-method > tls1_1 > tls1_1-method > tls1_2 > tls1_2-method > tls1_3 > dtls1 > dtls1-method > dtls1_2 > dtls1_2-method > > Disabled features: > > afalgeng[cascade] OPENSSL_NO_AFALGENG > aria[option] OPENSSL_NO_ARIA (skip > crypto/aria) > asan[default] OPENSSL_NO_ASAN > asm [option] OPENSSL_NO_ASM > bf [option] OPENSSL_NO_BF (skip > crypto/bf) > blake2 [option] OPENSSL_NO_BLAKE2 (skip > crypto/blake2) > camellia[option] OPENSSL_NO_CAMELLIA (skip > crypto/camellia) > cast[option] OPENSSL_NO_CAST (skip > crypto/cast) > crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG > crypto-mdebug-backtrace [default] > OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE > ct [option] OPENSSL_NO_CT (skip > crypto/ct) > devcryptoeng[default] OPENSSL_NO_DEVCRYPTOENG > dso [option] OPENSSL_NO_DSO > dynamic-engine [cascade] > ec_nistp_64_gcc_128 [default] > OPENSSL_NO_EC_NISTP_64_GCC_128 > egd [default] OPENSSL_NO_EGD > engine [option] OPENSSL_NO_ENGINE (skip > crypto/engine, engines) > external-tests [default] OPENSSL_NO_EXTERNAL_TESTS > fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER > fuzz-afl[default] OPENSSL_NO_FUZZ_AFL > heartbeats [default] OPENSSL_NO_HEARTBEATS > idea[option] OPENSSL_NO_IDEA (skip > crypto/idea) > md2 [option] OPENSSL_NO_MD2 (skip > crypto/md2) > md4 [option] OPENSSL_NO_MD4 (skip > crypto/md4) > mdc2[option] OPENSSL_NO_MDC2 (skip > crypto/mdc2) > msan[default] OPENSSL_NO_MSAN > ocsp[option] OPENSSL_NO_OCSP (skip > crypto/ocsp) > pic [no-shared-target] > rc2 [
Re: OpenSSL compliance with Linux distributions
On Wed, Aug 05, 2020 at 10:28:26PM +0200, Patrick Mooc wrote: > Thank you very much Kyle for your quick and clear answer. > > The reason why I want to upgrade OpenSSL version, is that I encounter a > problem with 1 frame exchange between client and server. > > This frame is the first packet sent from client to server (Client Hello > Packet) and the protocol used for this packet is SSLv2. > I don't understand why, because I force the use of TLSv1 (in ssl.conf file > as in application software), but only for this first exchange packet, SSLv2 > is used. All other packets are well using TLSv10 as configured. > > I have also searched for forcing the use of TLSv10 ciphers in OpenSSL > configuration and in application software, but I didn't succeed doing so. > > That's why I had in idea of upgrading OpenSSL version to avoid the use of > SSLv2 protocol. > > > Thus, if you have any idea of how to solve my problem without upgrading > OpenSSL version or Linux distribution, It would be very nice. Using an "SSLv2-compatible" ClientHello is rather distinct from actually using the SSLv2 protocol; I believe that the former is what is happening for you. IIRC sending any TLS extension with the ClientHello suppresses the use of the v2-compatible format, so you might be able to do that. (I don't remember offhand which extensions are implemented in that old of an OpenSSL version, and whether they're enabled in the default build, though.) -Ben
Re: 'in_addr_t' in openssl 1.1.1g ??
On Thu, Aug 06, 2020 at 01:51:35AM +0530, prudvi raj wrote: > Hi there, > > I got this error during compilation , in file b_addr.c : > In function 'BIO_lookup_ex': > /b_addr.c:748:9: error: unknown type name 'in_addr_t' > > I see that "in_addr_t" is defined in "netinet/in.h" & "arpa/inet.h" in > toolchain (typedef uint32_t in_addr_t;). > i have even tried to #include<> these files directly but that doesn't seem > to fix the error. Btw, these files are included already , but under > conditional #if 's. > > I am surprised why the error persists , even after directly including the > respective source file ?? > > Here's the config options i used : > ./Configure no-threads no-dso no-ct no-shared no-zlib no-asm no-engine > no-bf no-aria no-blake2 no-camellia no-cast no-md2 no-md4 no-mdc2 no-ocsp > no-rc2 no-rc5 no-hw-padlock no-idea no-srp gcc --with-rand-seed=none > > --cross-compile-prefix=/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe- > > PS : same error without any cross compile prefix , using only gcc. The `./configdata.pm -d` output might be helpful. -Ben
Re: Lack of documentation for OPENSSL_ia32cap_P
On 2020-07-26 01:56, Jan Just Keijser wrote: On 23/07/20 02:35, Jakob Bohm via openssl-users wrote: The OPENSSL_ia32cap_P variable, its bitfields and the code that sets it (in assembler) seemto have no clear documentation. Thanks, I somehow missed that document as I was grepping the code. Looking at x86_64cpuid.pl, I see jumps to ".Lintel" etc. being conditional on stuff other than the CPU being an Intel CPU, while the code in there is generally unreadable due to the backwards SCO assembler format and the lack of clear comments about register usage such as "Here, EDX holds XXX and ESI holds " or eventhe code rationale "P50 microarchitecture stepping A incorrectly implements FDIV, so clear out private bit for using that in bignum implementations" As there is an external interface for changing the variable via an environment var, the lack of documentation makes that useless except for "cargo-cult" copying of values from old mailing list posts. in the openssl 1.1.1g tree there's a file 'doc/man3/OPENSSL_ia32cap.pod' which documents it a little - not sure if that is still up-to-date though... HTH, JJK 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
Lack of documentation for OPENSSL_ia32cap_P
The OPENSSL_ia32cap_P variable, its bitfields and the code that sets it (in assembler) seemto have no clear documentation. Looking at x86_64cpuid.pl, I see jumps to ".Lintel" etc. being conditional on stuff other than the CPU being an Intel CPU, while the code in there is generally unreadable due to the backwards SCO assembler format and the lack of clear comments about register usage such as "Here, EDX holds XXX and ESI holds " or eventhe code rationale "P50 microarchitecture stepping A incorrectly implements FDIV, so clear out private bit for using that in bignum implementations" As there is an external interface for changing the variable via an environment var, the lack of documentation makes that useless except for "cargo-cult" copying of values from old mailing list posts. 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
Memory leak
No memory leakage, if I comment out all SSL related constructs from my code.
Thus, the SSL related code parts seem to be the cause of this leak.
What is the issue here?
Makefile:
CC=clang
CFLAGS=-g -Wextra -Wall -Werror -pedantic -std=c89 -lssl -fsanitize=address
-fno-omit-frame-pointer
.PHONY: clean
test: main.c
$(CC) $(CFLAGS) $^ -o $@
clean:
rm -rf test
Code:
#define _DEFAULT_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
int sfd = 0;
int ret = 0;
struct addrinfo *result = NULL;
struct addrinfo *rp = NULL;
SSL_CTX *ssl_ctx = NULL;
SSL *ssl = NULL;
/* Socket initialization and connection */
sfd = socket(AF_INET, SOCK_STREAM, 0);
assert(sfd != -1);
{
const unsigned int min_argc = 4;
assert(argc == min_argc);
}
ret = getaddrinfo(argv[1], argv[2], NULL, &result);
assert(ret != -1);
for (rp = result; rp != NULL; rp = rp->ai_next) {
if (connect(sfd, rp->ai_addr, rp->ai_addrlen) != -1)
break;
}
/* SSL initialization */
SSL_load_error_strings();
SSL_library_init();
ssl_ctx = SSL_CTX_new(SSLv23_client_method());
ssl = SSL_new(ssl_ctx);
SSL_set_fd(ssl, sfd);
ret = SSL_connect(ssl);
assert(ret != -1);
/* HTTP requests */
{
const size_t buf_sz = atoi(argv[3]);
const unsigned int max = 30;
char *buf = (char *)calloc(buf_sz + 1, sizeof(char));
strncat(buf, "GET / HTTP/1.1\r\nHost: ", max);
strncat(buf, argv[1], max);
strncat(buf, "\r\n\r\n", max);
ret = SSL_write(ssl, buf, strlen(buf) + 1);
assert(ret != -1);
free(buf);
}
{
const size_t buf_sz = atoi(argv[3]);
char *buf = (char *)calloc(buf_sz + 1, sizeof(char));
assert(buf);
ret = SSL_read(ssl, buf, buf_sz);
assert(ret != -1);
printf("%s\n", buf);
free(buf);
}
/* Clean up */
SSL_free(ssl);
close(sfd);
return 0;
}
Program output:
user@user-ubuntu:~/projects/https$ ./test finance.yahoo.com 443 1024
HTTP/1.1 200 OK
Referrer-Policy: no-referrer-when-downgrade
Strict-Transport-Security: max-age=15552000
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: sandbox allow-downloads allow-forms allow-modals
allow-same-origin allow-scripts allow-popups allow-popups-to-escape-sandbox
allow-top-navigation-by-user-activation allow-presentation;
Content-Type: text/html; charset=utf-8
Set-Cookie: B=8mraj0lfhbaol&b=3&s=r7; expires=Mon, 20-Jul-2021 14:32:53 GMT;
path=/; domain=.yahoo.com
Date: Mon, 20 Jul 2020 14:32:53 GMT
Server: ATS
Cache-Control: max-age=0, private
Expires: -1
Age: 0
Transfer-Encoding: chunked
Connection: keep-alive
Expect-CT: max-age=31536000,
report-uri="http://csp.yahoo.com/beacon/csp?src=yahoocom-expect-ct-report-only";
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
=
==28089==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1024 byte(s) in 1 object(s) allocated from:
#0 0x493aed in malloc (/home/user/projects/https/test+0x493aed)
#1 0x7f59b7cf88cd in CRYPTO_zalloc
(/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x17b8cd)
#2 0x7f59b7e7a0b2 in __libc_start_main
/build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x493aed in malloc (/home/user/projects/https/test+0x493aed)
#1 0x7f59b7f59be9 in gaih_inet
/build/glibc-YYA7BZ/glibc-2.31/posix/../sysdeps/posix/getaddrinfo.c:1058:18
#2 0x7f59b7f5bf48 in getaddrinfo
/build/glibc-YYA7BZ/glibc-2.31/posix/../sysdeps/posix/getaddrinfo.c:2256:12
#3 0x442e3a in getaddrinfo (/home/user/projects/https/test+0x442e3a)
#4 0x4c349c in main /home/user/projects/https/main.c:30:11
#5 0x7f59b7e7a0b2 in __libc_start_main
/build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
Indirect leak of 1712 byte(s) in 19 object(s) allocated from:
#0 0x493aed in malloc (/home/user/projects/https/test+0x493aed)
#1 0x7f59b7cf88cd in CRYPTO_zalloc
(/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x17b8cd)
Indirect leak of 504 byte(s) in 1 object(s) allocated from:
#0 0x493e09 in realloc (/home/user/projects/https/test+0x493e09)
#1 0x7f59b7d5b464 (/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x1de464)
Indirect leak of 504 byte(s) in 1 object(s) allocated from:
#0 0x493aed in malloc (/home/user/projects/https/test+0x493aed)
#1 0x7f59b7d5ba48 in OPENSSL_sk_dup
(/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x1dea48)
Indirect leak of 456 byte(s) in 6 object(s) allocated from:
#0 0x493aed in malloc (/home/user/projects/https/test+0x493aed)
#1 0x7f59b7f59a59 in gaih_inet
/build/glibc-YYA7BZ/glibc-2.31/posix/../sysdeps/posix/getaddrinfo.c:1058:18
#2 0x7f59b7f5bf48 in getaddrinfo
/build/glibc-YYA7BZ/glibc-2.31/posix/../sysdeps/posix/getaddrinfo.c:2256:12
#3 0x442e3a in getaddrinfo (/home/user/projects/https/test+0x442e3a)
#4 0x4c349c in main /home/user/projects/https/main.c:30:11
#5 0x7f59b7e7a0b2 in __libc_start_main
/build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
Indirect leak of
OpenSSL version 3.0.0-alpha5 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL version 3.0 alpha 5 released OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 5 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha5.tar.gz Size: 13919931 SHA1 checksum: 0e2aded2b2bd2104bcee6bfcd10132a8aec87776 SHA256 checksum: 09ad89af04cbf36dbbce1fc7063e18fcc333fcaaf3eccecf22c4a99bac83e139 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha5.tar.gz openssl sha256 openssl-3.0.0-alpha5.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEEeVOsH7w9yLOykjk+1enkP3357owFAl8QVLgUHGxldml0dGVA b3BlbnNzbC5vcmcACgkQ1enkP3357owlsxAAsESoir2B2o8zLiBgZpo24k+FGcsb zu6unJnYp0IZH+UkK+EXU4q440vpOcXaxC9zyXUKrdUp7e6iXzsVhqkTHFqkG+sE wiEjCO5VS/gPWo3Alrr1Lyzuc9EFLk5XzU0/p2MEVMwjxwHGuqshmJe5dgkv/NCa /SebPbzbKpCKnfnUhmEiiXzG8Sujit8zVl0bKSXsF0hgfm6bWzeuBUj2wqoUFmFe OlPuZ53cYYaF6Hw0XjSiW20RVJ9wD+jgJoQbos7l8QORzuOGsgxYExG0+M+0ketY W1TttXKZrPyO4qj/mdojrPOZWQQT3v5yInGI0wWLzPvXFBs4bKB088uKZQUyicd1 VJyvJBYR5K64podAoQSSjATo8zDZxts1A8JcfGKeLuIeXhhcOf+h75X0pk4+Sqaz +YQLj7lupg9Hksu8UGIcFZNc4zDvDdeFMxphAUkbnlBt7wB+sGSKMcxciYYGh7Vf 8PBTqFS3QcTe33m8KFJMNSwSNDyFILbqskltRQ4vxIquNQu3b1pgfNpKetGnQZJs hv1Ruc4o8rtkntMXx7xpY/uRnWDkdPtybZJNgUMc/iUe88p6YjXFq7q+PDtVAhYk 0EVNlU2lVjM0DZoi4aWKtqCWExJ/rFzuAeCNEXI8oFMSV3/wwE5WFv/uQC45vDuS yuGJQvyOaBjoJws= =uL/G -END PGP SIGNATURE-
Re: Compiling OpenSSL shared libraries with custom name on Unix platforms
On Tue, Jul 14, 2020 at 09:08:10PM +0200, shivaramakrishna chakravarthula wrote: > This is exactly similar to what I am looking for. I am using 1.0.2J version > and there are some changes in the next version onwards that causes problems > in SSL connections to older versions when DH key = 256 bytes are used. For > backward compatibility reasons, I need to continue supporting 256 bytes DH > keys for some more time and hence I want to stay on 1.0.2J version for now. > > Anyways, Thanks for sharing the details. Ah, thanks for the details. The change I linked to is not going to be of much use to you, since the build system got completely redone between those versions. I will note that, at least on some systems, you can use sed to change the SONAME of the compiled library before/during the installation process, which may be enough of a workaround for your purposes. -Ben
Re: Compiling OpenSSL shared libraries with custom name on Unix platforms
On Tue, Jul 14, 2020 at 04:58:38PM +0200, shivaramakrishna chakravarthula wrote: > Hi, > > I have compatibility issues for my application with new versions of OpenSSL > and I want to use the older version of OpenSSL with my application. So, I > want to link my application with an OpenSSL library built with the custom > name so that it works fine on all systems and I can be assured of using the > desired OpenSSL version. I am using RPATH to locate the libraries in > runtime and I want to make sure my libraries don't conflict with existing > libraries. How old is this "older version"? The functionality you want sounds exactly like the "variant SONAMEs introduced in commit https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb but that's only in 1.1.0g and later. -Ben
Re: Question about SSL_key_update
On Thu, Jul 09, 2020 at 06:07:41PM +, Andreas Müller wrote: > Hi, > > I "inherited" our project to support/use TLSv1.3 from a late colleague. We > have a server written in C++ (Windows, Linux) > and clients (Windows, Linux, also written in C++ and also a Java client). > With Java, we use the native SSLSocket implementation, in Windows we use > Schannel and in Linux we use OpenSSL 1.1.1g. It seems to work and even > interoperability > did not show issues on some initial testing. > > I was curious about SSL_key_update. I read that other implementations use it > automatically, but with OpenSSL I have to > do it manually. So I added a > > int rc = SSL_key_update(ssl, SSL_KEY_UPDATE_REQUESTED); > > after 1000 I/O operations and looked what happened. > > I started with the Java client and it gets wrong application data in such a > situation. > > I tested with our Windows implementation (I know it may have > interoperability issues) and here I can see the > data I get from the server side and it is the same that I see on server side > in the callback, but the Windows > DecryptMessage function fails with SEC_E_INVALID_TOKEN. (I had expected > something like SEC_I_RENEGOTIATE to > get the information to put this record into InitializeSecurityContext.) > > The Linux client also aborts the connection, but here I have not yet more > details, but either the decryption fails > or the decrypted application data is wrong. Hopefully I can dig in there > next week. > > Here is what happens on server side: > > 1. I call SSL_key_update (see above) > 2. I call SSL_write with application data > 3. The write callback is invoked with this data: >DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa > 11 2c 32 95 a9 > 4. The write callback is invoked again with application data provided to > SSL_write: >DATA: 17 03 03 00 45 12 24 e5 66 36 2f 28 ea 62 2e 17 4c 62 f0 38 07 7f > 72 70 87 25 ba 45 ff cf f7 9f 0d 7d 48 ... > > I see these data arrive at the client side (Windows): >DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa > 11 2c 32 95 a9 > but get the error described above. In Java I get wrong application data, so > it seems to decrypt this as application > data?! > > I saw an additional call to SSL_do_handshake in the apps/s_server.c and > tried this, but it did not change anything. > > Is there anything else (except calling SSL_key_update) I have to take care of? Per the documentation (https://www.openssl.org/docs/man1.1.1/man3/SSL_key_update.html) it sounds like you're doing all you need to be. (In particular, you don't need to call SSL_do_handshake().) Probably the fastest way to track down what's happening is to get a full packet capture and keylog (e.g., with s_client -keylogfile path/to/log, then point wireshark at the trace+keys. -Ben
Re: Order of protocols in MinProtocol
On 08.07.20 17:57, Matt Caswell wrote: > > > On 08/07/2020 17:48, Klaus Umbach via openssl-users wrote: > > On 08.07.20 12:21, Viktor Dukhovni wrote: > >> On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: > >> > >>> On 08/07/2020 16:28, Viktor Dukhovni wrote: > >>>>> How could I set the a System default "MinProtocol" for DTLS and TLS to > >>>>> 1.2? > >>>> > >>>> AFAIK, that's not presently possible. You can specify application > >>>> profiles, for applications that specify an application name when > >>>> initializing OpenSSL. Or use the OPENSSL_CONF environment variable to > >>>> select an alternative configuration file for DTLS applications. > >>> > >>> Arguably, that is a bug. You *should* be able to do that - perhaps based > >>> on some sensible mapping between TLS protocol versions based on whether > >>> we have a DTLS or TLS based SSL_METHOD. > > > > Should I open an issue at https://github.com/openssl/openssl/issues? > > Yes please. Done: https://github.com/openssl/openssl/issues/12394 > > > > But for my personal problem right now (openconnect uses TLS and DTLS, so > > even if it would set an application name I couldn't set a "proper" > > setting), until this bug is fixed, I use this now: > > > ># MinProtocol = TLSv1.2 > >Protocol = -TLSv1, -TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1.2 > > Looks sane - although do you also mean to disable DTLSv1? Perhaps for > safety you should also disable SSLv3 (although support for it is not > built by default anyway). Ah, thanks, I missed DTLSv1. (SSLv3 is not enabled in my build, but for safety-reasons, you are right) Thank you! - Klaus
Re: Order of protocols in MinProtocol
On 08.07.20 12:21, Viktor Dukhovni wrote: > On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: > > > On 08/07/2020 16:28, Viktor Dukhovni wrote: > > >> How could I set the a System default "MinProtocol" for DTLS and TLS to > > >> 1.2? > > > > > > AFAIK, that's not presently possible. You can specify application > > > profiles, for applications that specify an application name when > > > initializing OpenSSL. Or use the OPENSSL_CONF environment variable to > > > select an alternative configuration file for DTLS applications. > > > > Arguably, that is a bug. You *should* be able to do that - perhaps based > > on some sensible mapping between TLS protocol versions based on whether > > we have a DTLS or TLS based SSL_METHOD. Should I open an issue at https://github.com/openssl/openssl/issues? > > I agree that the situation with MinProtocol in openssl.cnf is > unfortunate. But instead of mappings, I would propose a different > solution: > > * Restrict MinProtocol/MaxProtocol to just TLS protocols, > i.e. SSL_CTX objects with a TLS-based method. > > * Introduct new controls: DTLSMinProtocolDTLS, DTLSMaxProtocol, > that are similarly restricted to SSL_CTX objects with a DTLS-based > method. > > * Since SSL_CTX_new() takes a required method argument, we are in > never in doubt as to which pair of controls to apply to a given > context. > > Thoughts? To me this sounds sane. But for my personal problem right now (openconnect uses TLS and DTLS, so even if it would set an application name I couldn't set a "proper" setting), until this bug is fixed, I use this now: # MinProtocol = TLSv1.2 Protocol = -TLSv1, -TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1.2 (with a big comment for future-me, why I did something, that i shouldn't) To my understanding, this will do exaclty what I want, up to that point in time, when there are newer versions of DTLS and/or TLS supported and I want to use them. (SSL3 is not supported in my build) Am I right? - Klaus
Order of protocols in MinProtocol
Hi, when I set "MinProtocol" to "TLSv1.2" in openssl.cnf, DTLSv1.2 doesn't work for the client (in my specific case openconnect). According to https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html, only one value is possible, so I can't set both. The usage of "Protocol", where I could use a list, is marked as deprecated. If I set it to "DTLSv1.2", openconnect works fine, but why is "TLSv1.2" higher than "DTLSv1.2" and what is the minimal version of TLS now? How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? - Klaus
Re: OpenSSL shared library in FIPS mode
Thanks Murugesh. I just wanted to add that the FOM (OpenSSL FIPS object module) is built using the instructions provided by the User Guide: ./config make make install The built fipscanister.o is integrated into the OpenSSL distribution via our own build infrastructure by mimicking the OpenSSL makefiles (including invoking fipsld to embed the signature into the library). On Tue, Jul 7, 2020 at 8:39 PM murugesh pitchaiah < murugesh.pitcha...@gmail.com> wrote: > Hi, > > Yes. You have to use openssl provided build files. > > Thanks, > Murugesh P. > > On 7/7/20, Shirisha Dasari via openssl-users > wrote: > > Hi All, > > > > We have been trying to integrate FOM 2.0.13 with OpenSSL 1.0.2u for FIPS > > compliance. Post integration, we have been able to run in FIPS mode, with > > all self-tests passing as well. However, we seem to be encountering > issues > > in creation and parsing of ECDSA keys. > > > > A little background on how we build the shared libcrypto library: > > > > TARGET: x86_64 > > BUILD HOST: x86_64 > > > > We do not use the OpenSSL Makefile to build the OpenSSL source. Our build > > infrastructure creates multiple static archives from the OpenSSL crypto > > source and finally creates a libcrypto.a from these archives as required > by > > fipsld. The fipscanister.o and libcrypto.a are archived to create the > final > > libcrypto.a and passed onto fipsld for creation of a dynamic library, > > libcrypto.so. fips_premain_dso gets built as a part of the build process > > too for generation of signature. These steps mimic the OpenSSL opensource > > Makefile. > > > > fipsld embeds the signature into the final libcrypto.so successfully and > we > > are able to get into FIPS mode successfully at run time. Self-tests pass > as > > well. > > > > Issue: > > > > While trying to use ECDSA host keys for OpenSSH, we noticed that parsing > of > > ECDSA key fails. DSA and RSA key creation and parsing do not have this > > issue. Note that the ECDSA key was generated in FIPS mode and is being > > parsed in FIPS mode itself. > > > > root@localhost:/home/admin# openssl ec -in ssh_host_key_ecdsa -text > -noout > > read EC key > > unable to load Key > > 140020611143360:error:10067066:elliptic curve > > routines:ec_GFp_simple_oct2point:invalid > > encoding:../../../../vendor/openssl-fips/crypto/ec/ecp_oct.c:370: > > 140020611143360:error:10092010:elliptic curve > routines:d2i_ECPrivateKey:EC > > lib:../../../../vendor/openssl-fips/crypto/ec/ec_asn1.c:1172: > > 140020611143360:error:100D508E:elliptic curve > > routines:ECKEY_PRIV_DECODE:decode > > error:../../../../vendor/openssl-fips/crypto/ec/ec_ameth.c:256: > > 140020611143360:error:0606F091:digital envelope > > routines:EVP_PKCS82PKEY:private key decode > > error:../../../../vendor/openssl-fips/crypto/evp/evp_pkey.c:92: > > 140020611143360:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 > > lib:../../../../vendor/openssl-fips/crypto/pem/pem_pkey.c:142: > > root@localhost:/home/admin# > > > > A portion of the sample ECDSA key generated with curve secp384r1 via > > ssh-keygen with "ssh-keygen -t ecdsa -b 384 -f ssh_host_key_ecdsa" is > > provided below: > > > > -BEGIN PRIVATE KEY- > > MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDD > > > > > > -END PRIVATE KEY- > > > > A few questions related to this: > > > > 1) Is there a specific need to build the OpenSSL source only via the > > provided Makefile? > > 2) FIPS self test for ECDSA passes but the key creation/parsing fails. > > Could this indicate that the FIPS module APIs are not getting invoked in > > the case of ECDSA? > > > > -- > > Thanks & Regards, > > Shirisha. > > > -- Thanks & Regards, Shirisha.
OpenSSL shared library in FIPS mode
Hi All, We have been trying to integrate FOM 2.0.13 with OpenSSL 1.0.2u for FIPS compliance. Post integration, we have been able to run in FIPS mode, with all self-tests passing as well. However, we seem to be encountering issues in creation and parsing of ECDSA keys. A little background on how we build the shared libcrypto library: TARGET: x86_64 BUILD HOST: x86_64 We do not use the OpenSSL Makefile to build the OpenSSL source. Our build infrastructure creates multiple static archives from the OpenSSL crypto source and finally creates a libcrypto.a from these archives as required by fipsld. The fipscanister.o and libcrypto.a are archived to create the final libcrypto.a and passed onto fipsld for creation of a dynamic library, libcrypto.so. fips_premain_dso gets built as a part of the build process too for generation of signature. These steps mimic the OpenSSL opensource Makefile. fipsld embeds the signature into the final libcrypto.so successfully and we are able to get into FIPS mode successfully at run time. Self-tests pass as well. Issue: While trying to use ECDSA host keys for OpenSSH, we noticed that parsing of ECDSA key fails. DSA and RSA key creation and parsing do not have this issue. Note that the ECDSA key was generated in FIPS mode and is being parsed in FIPS mode itself. root@localhost:/home/admin# openssl ec -in ssh_host_key_ecdsa -text -noout read EC key unable to load Key 140020611143360:error:10067066:elliptic curve routines:ec_GFp_simple_oct2point:invalid encoding:../../../../vendor/openssl-fips/crypto/ec/ecp_oct.c:370: 140020611143360:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC lib:../../../../vendor/openssl-fips/crypto/ec/ec_asn1.c:1172: 140020611143360:error:100D508E:elliptic curve routines:ECKEY_PRIV_DECODE:decode error:../../../../vendor/openssl-fips/crypto/ec/ec_ameth.c:256: 140020611143360:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private key decode error:../../../../vendor/openssl-fips/crypto/evp/evp_pkey.c:92: 140020611143360:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 lib:../../../../vendor/openssl-fips/crypto/pem/pem_pkey.c:142: root@localhost:/home/admin# A portion of the sample ECDSA key generated with curve secp384r1 via ssh-keygen with "ssh-keygen -t ecdsa -b 384 -f ssh_host_key_ecdsa" is provided below: -BEGIN PRIVATE KEY- MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDD -END PRIVATE KEY- A few questions related to this: 1) Is there a specific need to build the OpenSSL source only via the provided Makefile? 2) FIPS self test for ECDSA passes but the key creation/parsing fails. Could this indicate that the FIPS module APIs are not getting invoked in the case of ECDSA? -- Thanks & Regards, Shirisha.
Goodbye
* topic: Change some words by accepting PR#12089 * * 4 against, 3 for, no absensions I am at a loss for words. I can’t contribute to a project that feels this way. The OMC (list at [1], a picture of some of them at [2] although it includes non-OMC members) is, in my view, on the wrong side of history. I hope that in time, the four men who voted against it will develop more – what, empathy? – and that sometime in the future this PR [3], or similar, will be merged. Until then, I will do what I have to in order to insure that Akamai’s needs for FIPS are met and once 3.0 is released, I will be fully applying my modest talents elsewhere. I have closed all non-FIPS PR’s, and as soon as I see this message in my inbox, I will unsubscribe from this list. I can be reached as rsalz at akamai.com. [1] https://www.openssl.org/community/omc.html [2] https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/ [3] https://github.com/openssl/openssl/pull/12089
genrsa: unable to load provider fips
Running apps/openssl genrsa -provider fips results in the following error … genrsa: unable to load provider fips C0FDC40A0100:error::common libcrypto routines:provider_activate:init fail:crypto/provider_core.c:503: What am I missing? Thanks, Norman perl configdata.pm --dump Command line (with current working directory = .): perl ./Configure darwin64-x86_64-cc --prefix=/Downloads/ossl-3-install --openssldir=/Downloads/ossl-3-install/ssl --debug Perl information: perl 5.18.4 for darwin-thread-multi-2level Enabled features: aria asm async autoalginit autoerrinit autoload-config bf blake2 camellia capieng cast chacha cmac cmp cms comp ct deprecated des dgram dh dsa dso dtls dynamic-engine ec ec2m ecdh ecdsa engine err filenames fips gost idea legacy makedepend md4 mdc2 module multiblock nextprotoneg pinshared ocb ocsp padlockeng pic poly1305 posix-io psk rc2 rc4 rdrand rfc3779 rmd160 scrypt secure-memory seed shared siphash siv sm2 sm3 sm4 sock srp srtp sse2 ssl static-engine stdio tests threads tls ts ui-console whirlpool tls1 tls1-method tls1_1 tls1_1-method tls1_2 tls1_2-method tls1_3 dtls1 dtls1-method dtls1_2 dtls1_2-method Disabled features: afalgeng[not-linux] OPENSSL_NO_AFALGENG asan[default]OPENSSL_NO_ASAN buildtest-c++ [default] crypto-mdebug [default]OPENSSL_NO_CRYPTO_MDEBUG devcryptoeng[default]OPENSSL_NO_DEVCRYPTOENG ec_nistp_64_gcc_128 [default]OPENSSL_NO_EC_NISTP_64_GCC_128 egd [default]OPENSSL_NO_EGD external-tests [default]OPENSSL_NO_EXTERNAL_TESTS fuzz-libfuzzer [default]OPENSSL_NO_FUZZ_LIBFUZZER fuzz-afl[default]OPENSSL_NO_FUZZ_AFL ktls[default]OPENSSL_NO_KTLS md2 [default]OPENSSL_NO_MD2 (skip crypto/md2) msan[default]OPENSSL_NO_MSAN rc5 [default]OPENSSL_NO_RC5 (skip crypto/rc5) sctp[default]OPENSSL_NO_SCTP ssl-trace [default]OPENSSL_NO_SSL_TRACE trace [default]OPENSSL_NO_TRACE ubsan [default]OPENSSL_NO_UBSAN unit-test [default]OPENSSL_NO_UNIT_TEST uplink [no uplink_arch] OPENSSL_NO_UPLINK weak-ssl-ciphers[default]OPENSSL_NO_WEAK_SSL_CIPHERS zlib[default] zlib-dynamic[default] ssl3[default]OPENSSL_NO_SSL3 ssl3-method [default]OPENSSL_NO_SSL3_METHOD Config target attributes: AR => "ar", ARFLAGS => "r", CC => "cc", CFLAGS => "-g -O0 -Wall", HASHBANGPERL => "/usr/bin/env perl", RANLIB => "ranlib -c", RC => "windres", asm_arch => "x86_64", bn_ops => "SIXTY_FOUR_BIT_LONG", build_file => "Makefile", build_scheme => [ "unified", "unix" ], cflags => "-arch x86_64", cppflags => "-D_REENTRANT", defines => [ "OPENSSL_BUILDING_OPENSSL" ], disable => [ ], dso_scheme => "dlfcn", enable => [ ], includes => [ ], lflags => "-Wl,-search_paths_first", lib_cflags => "", lib_cppflags => "-DL_ENDIAN", lib_defines => [ ], module_cflags => "-fPIC", module_cxxflags => undef, module_ldflags => "-bundle", perl_platform => "Unix", perlasm_scheme => "macosx", shared_cflag => "-fPIC", shared_defines => [ ], shared_extension => ".\$(SHLIB_VERSION_NUMBER).dylib", shared_ldflag => "-dynamiclib -current_version \$(SHLIB_VERSION_NUMBER) -compatibility_version \$(SHLIB_VERSION_NUMBER)", shared_rcflag => "", shared_sonameflag => "-install_name \$(INSTALLTOP)/\$(LIBDIR)/", shared_target => "darwin-shared", sys_id => "MACOSX", thread_defines => [ ], thread_scheme => "pthreads", unistd => "", Recorded environment: AR = ARFLAGS = AS = ASFLAGS = BUILDFILE = CC = CFLAGS = CPP = CPPDEFINES = CPPFLAGS = CPPINCLUDES = CROSS_COMPILE = CXX = CXXFLAGS = HASHBANGPERL = LD =
Re: server key exchange signature behavior
You may also check out the results of the popular ssllabs.com test here: https://www.ssllabs.com/ssltest/analyze.html?d=jnior.com&hideResults=on Note however that in recent years they have become quite aggressive in labeling things as "weak" when they are simply "slightly less than the best that the latestbig-brand browsers support" with no consideration for servers that try to provide compatibility for older clients in addition to the latest hype. As for the signature on the key exchange in SSL3/TLS1.0/TLS1.1/TLS 1.2 and the final signature in TLS1.3, those are the one signature that causes the certificates to do anything meaningful, so I would expect all but the most crappy clients to check it and make a very serious error message "SOMEONE IS HACKING YOUR CONNECTION, PULL THE PLUG NOW!" or something equally serious. On 2020-06-25 19:09, Bruce Cloutier wrote: Sorry, By "If OpenSSL fails to validate this particular digital signature that would be the case." I meant to question whether or not OpenSSL is in fact doing the validation? In the case that the signature is being ignored then clients wouldn't complain. They wouldn't notice. Bruce On 6/25/20 1:04 PM, Bruce Cloutier wrote: Yeah. I doubt it is an OpenSSL issue directly as Apache might be feeding the wrong key. Just need confirmation that there isn't a default key configuration setting for OpenSSL that might be taking precedence for who knows why. I can connect successfully with the browser so I cannot rule out that my TLS implementation is faulty. However, it validates with every other site and it validates with the default install of this bitnami stack. Once we reconfigure for the new key and certificate, this signature in the server_key_exchange message fails. Nothing else seems to complain. My code does, well, because I know that I actually do verify that signature against the supplied certificate. So to everyone else it appears that we have configured the new certificates properly (manually achieved Let's Encrypt cert). If OpenSSL fails to validate this particular digital signature that would be the case. If in my TLS implementation I skip this check (actually now I just post a warning) everything negotiates and proceeds just fine. Obviously, THAT signature is there for a reason. I should expect if to validate. Just don't know what key it is using? I am not sure how to get to the Apache people or, might be, the Bitnami folks? Bruce On 6/25/20 12:07 PM, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Bruce Cloutier Sent: Thursday, June 25, 2020 10:11 Has anyone thought about this question? From your description, it sounds like an Apache issue, not an OpenSSL one. I don't know enough about Apache configuration to comment. (I've configured a few Apache instances in my day, but never had any real issues with it, so I've never done more than search the docs for what I needed and implemented it.) The site is https://jnior.com if anyone wants to hit it. For me the digital signature in the server_key_exchange does not verify. I just tried openssl s_client, and it didn't complain about anything. Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the chain. 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: Unusual certificates
On 2020-06-25 13:25, Hubert Kario wrote:
On Thursday, 25 June 2020 12:15:00 CEST, Angus Robertson - Magenta
Systems Ltd wrote:
A client is having problems reading Polish Centum issued personal
certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier,
mostly.
Using PEM_read_bio_X509 with some of these certificates says
error::lib(0):func(0):reason(0), while the X509 command line
tool says 'unable to load certificate'. Some certificates work with
both methods.
Using the asn1parse command from any version of OpenSSL says 'Error:
offset out of range', while a Javascript based web tool is able to
decode the ASN1, but is perhaps more tolerant of errors.
So it seems there is something in the creation of these certificates
that OpenSSL has never liked, but until 1.1.1 was tolerated
sufficiently to allow them to be read.
This certificate reads OK in 1.1.1 but fails asn1parse:
works just fine for me with 1.1.1g
This certificate can not be read in 1.1.1 but is OK in 1.1.0.
but this one fails parsing
Is there a more tolerant way to read ASN1 than the asn1parse command?
asn1parse expects BER encoding, that already is the most lenient, while
still standards-compliant, encoding that is supported.
Given that it errors out with
139628293990208:error:0D07209B:asn1 encoding
routines:ASN1_get_object:too long:crypto/asn1/asn1_lib.c:91:
I'm guessing a mismatch between utf-8 and string encoding that makes
the lengths inconsistent. Some tools may just ignore them, but that
doesn't
make the certificate well-formed.
I have tried examining these two certificates with Peter Gutmann's
dumpasn1.c
and a generic hex dumper.
For the second certificate, dumpasn1.c complains about a badly encoded
SET at
file offset 0x8E (after Base64 decoding):
0008E 31 19
00090 05 c1 80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c
000A0 8d 4c 0c 0c 0c 4c 0e 4c 0c
000A9 07 85 c3 4c 4e 4c 0c
My manual attempt to recover from this results in the following
further failures:
Attempt1: Straight BER/DER:
SET {
NULL-object of a very huge length: The number of bytes is
0x80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c 8d 4c
0c 0c 0c 4c 0e 4c 0c 07 85 c3 4c 4e 4c 0c 8c 8d
0c 8c cc 0c 0c 0c 16 85 c3 4c 8c 4c 0c 8c 8c cc
8c cc 0c 0c 0c 16 8c 1d 4c 42 cc 02 41 80 d5 41
01
-- ERROR: This runs beyond end-of-file
-- ERROR: This runs beyond end-of-SET (0x19 bytes)
}
Attempt2: Assume length byte for zero length NULL object omitted:
SET { NULL-object with missing length-encoding of its zero length
private-tag-1 object with indefinite length
-- ERROR: This runs beyond end-of-SET (0x19 bytes)
}
Attempt3: Treat SET as an opaque blob
SET { -- Contents ignored }
ObjectDescriptor of length 0x151CC bytes
-- ERROR: This runs beyond end-of-file
Attempt4: Treat preceding string as encoded with length 1 too small
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName -- 2.5.4.3
UTF8String 'CUZ Sigillum - QCA11'
-- WARNING: One byte beyond declared length of containing SEQUENCE
}
-- WARNING: One byte beyond declared length of containing SET
}
GraphicString '\c1\80\d5\41\18'
Application-tag-3 object of length 4 bytes: 0x15 90 55 14
PrintableString 4d 4c 8d 4c 0c 0c 0c 4c 0e 4c 0c
-- WARNING: Bad characters
ObjectDescriptor of length 0x151CC bytes
-- ERROR: This runs beyond end-of-file
-- WARNING: This runs beyond length of containing DN (0x80 bytes)
Attempt5: Treat preceding string as encoded with length 2 too small
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName -- 2.5.4.3
UTF8String 'CUZ Sigillum - QCA11\19'
-- WARNING: 2 bytes beyond declared length of containing SEQUENCE
}
-- WARNING: 2 bytes beyond declared length of containing SET
}
NULL-object of a very huge length: The number of bytes is
0x80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c 8d 4c
0c 0c 0c 4c 0e 4c 0c 07 85 c3 4c 4e 4c 0c 8c 8d
0c 8c cc 0c 0c 0c 16 85 c3 4c 8c 4c 0c 8c 8c cc
8c cc 0c 0c 0c 16 8c 1d 4c 42 cc 02 41 80 d5 41
01
-- ERROR: This runs beyond end-of-file
-- WARNING: This runs beyond length of containing DN (0x80 bytes)
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: [EXTERNAL] Re: Unusual certificates
The second certificate seems garbaged at the 4th RDN of the issuerName. The Base64 edition might have added or deleted some characters. Cordialement, Erwann Abalea Le 25/06/2020 16:00, « openssl-users au nom de Angus Robertson - Magenta Systems Ltd » a écrit : More information, the original certificates supplied by the end user had unwrapped base64 blocks, lines 2,500 long. I wrapped them for email. If I try the asn1parse command on the wrapped certificates, they now attempt to parse, the OK is fine, the bad one now gives an error message from asn1parse: Error in encoding 20236:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:crypto\asn1\asn1_lib.c:91: and error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode from PEM_read_bio_X509. The RFC says 'Parsers MAY handle other line sizes' but it would be good if OpenSSL gave a 'PEM line too long' error rather than no error. I'll change my library code to check for line ending in the base64 to give the user a polite message. Now the only problem is what is asn1 decoding unhappy with? Angus
OpenSSL version 3.0.0-alpha4 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 3.0 alpha 4 released OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 4 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha4.tar.gz Size: 13884897 SHA1 checksum: 056194ea4ec57234ce3cb16b944d99c4d2a8b650 SHA256 checksum: d930b650e0899f5baca8b80c50e7401620c129fef6c50198400999776a39bd37 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha4.tar.gz openssl sha256 openssl-3.0.0-alpha4.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl70rYcACgkQ2cTSbQ5g RJFWeAf/ZOGaHZbcAUy9Xm/R8x56qPJWD+3D8qGOgjNgKc/5r3kXII3I7NH7lc1j zFSt/FA9NhqU7dIh/8/SlyZaBbFW/XZBRiczDqRSqAkAfsxhlj5tOq8xZoXuTqlN it3DICC96jgh2xGo3LJUPgY1o0evsPLX98L/BtRZcZMcZed0ImZEEmJra3vEDr7H C+Hu4/+gNDlAISDENSDygAE8vDB5hBDmk0YCySPKZpDbWPdV2/WF8oBlgRpNBjY+ zbk/V32xZkhf/x/nhRGNs44CJI8ymsDtp6UyV2e7ZW6LZNMGX7l0M8ZuJvLTFJJM ZqQo7Xhn1EFdIRwTd+B2CvY2k73Pzw== =khAk -END PGP SIGNATURE-
Re: Monolith compile verify.c
C mandates that any “missing” initializers are as if 0/null were present.
{NULL, -1, 'Q', "unused end of list"} this is the change I’d like to offer
Turn off the warning.
Re: endless loop in probable_prime
On 2020-06-18 18:13, Salz, Rich via openssl-users wrote: BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES should also be 4. If BN_BYTES is being incorrectly set to 8 on your platform then that would explain the discrepancy. Can you check? This seems HIGHLY likely since Ronny said earlier that the same config/toolchain is used for 32bit userspace and 64bit kernel, right? Maybe the internal headers should contain lines that abort compilation if inconsistencies are found in the values provided by the (public or private) headers. For example, if BN_BYTES > sizeof(BN_ULONG), compilation should stop via an abstraction over the presence/absence of the _Static_assert, static_assert or macro emulation of same in any given compiler. /* Something like this, but via a macro abstraction: */ #if (some C++ compilers) /* Works if defined(__cplusplus) && __cplusplus >= 201103l */ /* Works for clang++ if has_feature(cxx_static_assert) */ /* Works for g++ >= 4.3.x if defined(__GXX_EXPERIMENTAL_CXX0X__) */ /* Works for MSC++ >= 16.00 */ /* Fails for g++ 4.7.x specifically */ /* Fails for some versions of Apple XCode */ static_assert( (BN_BYTES <= sizeof(BN_ULONG)), "Failed static assert: " "BN_BYTES <= sizeof(BN_ULONG)"); #elif (some C compilers) /* Works for clang with has_feature(c_static_assert) */ /* Works for gcc >= 4.6.x */ /* Fails for some versions of Apple XCode */ _Static_assert( (BN_BYTES <= sizeof(BN_ULONG)), "Failed static assert: " "BN_BYTES <= sizeof(BN_ULONG)"); #else /* Portable fallback, but some fudging may be needed for compilers * without __COUNTER__ */ /* If assertion fails, compiler will complain about invalid array size */ /* If assertion is not a const expression, compiler will complain about that */ typedef char OSSL_const_assert_##fudge##__LINE__##_##__COUNTER__[ (BN_BYTES <= sizeof(BN_ULONG)) ? 1 : -1]; #endif 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: freefunc - name clash with Python.h
On 2020-06-15 09:37, Viktor Dukhovni wrote: On Mon, Jun 15, 2020 at 06:07:20AM +, Jordan Brown wrote: Supplying names for the arguments in function prototypes makes them easier to read, but risks namespace problems. Yes, which I why, some time back, I argued unsuccessfuly that we SHOULD NOT use parameter names in public headers in OpenSSL, but sadly was not able to persuade a majority of the team. If this is ever reconsidered, my views have not changed. OpenSSL SHOULD NOT include parameter names in public headers. No sane compiler should complain about name clashes between unrelated namespaces, such as between global type names and formal parameter names in header function declarations (used exclusively for readable compiler error messages about incorrect invocations). Syntactically, the only case where there could be any overlap between those two namespaces would be if the formal parameter names were not preceded by type names, as might happen in K&R C. The warnings leading to this thread should be treated as a compiler bug, that should be easily reproduced with short standalone (1 to 3 files) test samples submitted to the relevant compiler bug tracker. 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: endless loop in probable_prime
>BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES should also be 4. If BN_BYTES is being incorrectly set to 8 on your platform then that would explain the discrepancy. Can you check? This seems HIGHLY likely since Ronny said earlier that the same config/toolchain is used for 32bit userspace and 64bit kernel, right?
Re: freefunc - name clash with Python.h
I dlon't lnow about Python's freefunc, no idea what it is, but the OpenSSL line is defining a function with a local parameter named freefunc. Those names shouldn't clash; what compiler and flags? It should be possible to rename the one in safestack.h to be "freefuncarg" or something. Can you switch the include order?
Re: Are there any flag that control client finished hash verification
On Mon, Jun 08, 2020 at 06:53:32PM +, Neil Proctor via openssl-users wrote: > Hello, > > Specific to OpenSSL v1.0.2p and TLS1.2 are there any flags or options like, > SSL_CERT_FLAG_TLS_STRICT, that set whether or not the client handshake > finished hash is verified by the server? Or is this always performed > regardless of configuration? > > During some of our testing, it seems that even if the last byte of the client > handshake finished hash gets modified, the server will still accept and > complete the handshake and the TLS connection. Full validation of the Finished is supposed to be done always. Please try to write up some discussion of your test cases; probably a github issue is best (though mail to this list is okay too). Thanks, Ben
Are there any flag that control client finished hash verification
Hello, Specific to OpenSSL v1.0.2p and TLS1.2 are there any flags or options like, SSL_CERT_FLAG_TLS_STRICT, that set whether or not the client handshake finished hash is verified by the server? Or is this always performed regardless of configuration? During some of our testing, it seems that even if the last byte of the client handshake finished hash gets modified, the server will still accept and complete the handshake and the TLS connection. Thanks
OpenSSL version 3.0.0-alpha3 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 3.0 alpha 3 released OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 3 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha3.tar.gz Size: 9622261 SHA1 checksum: 4e5856fb85b1383d309d38874795043a787891ea SHA256 checksum: 354f25ff6c7ed90271e2f0718054ecab253cc4252942aa0e89b265e2795ae040 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha3.tar.gz openssl sha256 openssl-3.0.0-alpha3.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl7Y/ZwACgkQ2cTSbQ5g RJH5+QgAi8M5sH+m8xnDTV+i9NFc9EAyzs1NMVY2B1/Yhzn+tSbKfR9tocKjFEB/ RV3cAjB1RBHtMxK9sI+O4PyE7Bkk81JB64RjAawY3Dy1kETWEJsulnzgkrpKtrM2 FbyCubL2sZgFevWVB4fDbUIr983o9Dg7idZehvq0zvVzg++bKm6edDDTaIBgisA3 gr+rA00bD++bddmqG7vm31HhN2/fYa+g719trXdfIcsyHhY+bsFtFqMOnO1D0N6f d6dWBNIP8SjuYQ8GJPdPU+Ryro8uJpIUd1DlP7xDg1y21vUoWrzIStbUTIeZh+51 0Qy2tWa52xSBgYQN3tu11MN17rLEPQ== =w062 -END PGP SIGNATURE-
Re: 3.0.0-alpha2: openssl ciphers MEDIUM empty?
On Wed, Jun 03, 2020 at 07:05:32PM +0200, Claus Assmann wrote: > Just curious: Why is the output of > openssl ciphers MEDIUM > "empty" for 3.0.0.a2? There are no ciphers available by default that are at the MEDIUM level (which, to be honest, does not make a huge amount of sense at this point anyway -- there's not a clear spot between "good" and "bad" to bucket things into). > Error in cipher list > 00:00:00:00:error:SSL routines:SSL_CTX_set_cipher_list:no cipher > match:ssl/ssl_lib.c:2705: > > Using 1.1.1 lists several, and at least > TLS_AES_128_GCM_SHA256 > is also listed by > openssl-3.0.0.a2 ciphers TLS_* are TLS 1.3 ciphers, which in the parlance of openssl configuration are known as "ciphersuites" (vs. "cipher list"), and are not affected by the "cipher list" that you provide via SSL_CTX_set_cipher_list(). My $ openssl version OpenSSL 1.1.1 11 Sep 2018 only reports the TLS 1.3 ciphersuites and some SEED ciphers for an input of MEDIUM, and IIRC the SEED ciphers have been foisted off to the legacy provider and are not available by default. > Has the "classification" of ciphers changed? > I didn't see anything obvious in CHANGES. This may just be the "legacy provider" bit -- the SEED ciphers are still listed as "MEDIUM" in the code (and there are some others that are gated behind ssl-weak-ciphers). -Ben
Re: OpenSSL in FIPS mode, does FIPS mode provide any extra set of ciphersuites?
* >FIPS ciphers are a subset of the ciphers that OpenSSL supports. * Is this true of both OpenSSL 2.0 FIPS version and OpenSSL 3.0 FIPS version. (I suppose yes). But still your confirmation will be helpful. Yes it is true for both. * Also, current version is considered outdated, even before new version is ready. This is true. But you got it for free.
Re: OpenSSL in FIPS mode, does FIPS mode provide any extra set of ciphersuites?
Are you asking about the current (outdated) 2.0 module or the 3.0 module that is still being developed? In 2.0, once you enter FIPS mode you cannot leave it. In 3.0 you can switch among FIPS and non-FIPS as you need to. See https://www.openssl.org/docs/OpenSSL300Design.html for a description of 3.0 FIPS ciphers are a subset of the ciphers that OpenSSL supports.
Re: distributed secret key
* In any case, I am unaware of any existing system which meets your requirement 3. Admittedly, I haven't specifically searched for such. CertCo (now defunct, don’t know who has the intellectual property) had a patent that did ALL of the things. RSA keygen, split the key, each key signs the data, looks like an RSA signature, then when enough have been done, combine them and it matches the original pre-split public key. That, and the followon patents, are cool. Don’t know if they’re expired or not. To answer the main question: OpenSSL doesn’t do anything remotely in this area. The closest is multi-prime RSA.
Re: How to get all certs into a .der file.
* application/pkix-pkipath * Defined in RFC4366 (section 8) and RFC6066 (section 10.1) I doubt that it is worth doing this. First, because OpenSSL doesn’t support it now, then CURL (what the original poster was talking about) can’t use it when using OpenSSL. Instead, as others have pointed out, they should use a text file that has a bunch of PEM blobs concatenated. Do we know any application that needs this?
RE: [EXTERNAL] How to get all certs into a .der file.
According to the documentation, cURL can use p12 files just fine.
curl --cert bob.p12:bobspassword --cert-type p12 https://some.secure.site
Or you can omit the password part and use -key mykey with your password in the
mykey file, in order to hide the password from PS queries.
From: openssl-users On Behalf Of paul h.
roubekas
Sent: Thursday, May 21, 2020 4:54 PM
To: openssl-users@openssl.org
Subject: [EXTERNAL] How to get all certs into a .der file.
I am a complete newbie to this list.
I wanted to search the archive but found no such page.
I have a requirement to convert all certs in a *.p12 file to a *.der file for
use in the curl command.
The first hop to a *.pem file has all the certs.
But the second hop only has one cert. The I read the docs but found nothing
that looked even close.
Hop 1
openssl pkcs12 -chain -in trust.p12 -out ww_temp.pem -password {redacted}
Hop 2
openssl x509 -outform der -in ww_temp.pem -out ww_temp.der
The Question) How do I get all the certs in the .der file?
Re: How to debug a TLSv1.3 protocol problem?
>Speaking of which, I've recently discovered (a documented interface landmine) that: status = SSL_read(ssl, ...); err = SSL_get_error(ssl, status); >is an anti-pattern, because the "correct" usage is: It's not unlike checking errno without knowing if the syscall actually failed.
OpenSSL version 3.0.0-alpha2 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 3.0 alpha 2 released OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 2 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha2.tar.gz Size: 9601205 SHA1 checksum: 9224a8957232db61b1e9cf1a80b3a19165f47236 SHA256 checksum: 9077d53d889f9708c261ee8a698df10575e2fd191de6924d89136b97dc8bc0c0 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha2.tar.gz openssl sha256 openssl-3.0.0-alpha2.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6+miwACgkQ2cTSbQ5g RJFqZggAhQGdzxbmbIa6aKeaX3sNpIYEpnu1W3htP/d2tMuqUlv31qG+IKZEnqHy kk/rhpHj9XU08MurpZ9caALayA3WNSpZXCwzpG85pgIm/KlwM2YN2CdmFCuh/G4K sMyU8UgSEcuEfF7BpYNgmfifYxDdRJjlrnrHwBPpFRJ0MdvS+8GN0a9n9b3o2eOm u2Dnub85W7NUH4St4YdKqDfxUF3rIPg+hvgOllb8JjZAqbrnCkeFek2SL9fVYJBM ORy3QODr2ahOo5sOYi61y7qe/MpcLdyjr5btm0L/xggWjBJ+EOo7m1iG2eQdzE88 AvcvALAtph/vmvfU3uPGWL7ms3z9Jg== =ixcT -END PGP SIGNATURE-
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 >
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
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 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. -Ben
Re: SSL_CTX_set_ssl_version changes security level
On Mon, May 11, 2020 at 05:01:27PM +0900, NAKANO Takuho wrote:
> Hello,
>
> I've found SSL_CTX_set_ssl_version changes security level:
>
> =
> int main(void){
> int i;
> struct ssl_ctx_st *ctx = SSL_CTX_new(SSLv23_method());
>
> printf("seclevel: %d\n", SSL_CTX_get_security_level(ctx));
> // 0--5 any
>
> i = SSL_CTX_set_ssl_version(ctx, SSLv23_client_method());
> printf("SSL_CTX_set_ssl_version result: %d\n", i);
> // i ==1; success
>
> printf("seclevel: %d\n", SSL_CTX_get_security_level(ctx));
> // result 2
>
> return 0;
> }
> =
>
> OS: CentOS 8
> OpenSSL 1.1.1c FIPS 28 May 2019
>
> Are there any reasons?
> I know SSLv23_method is deprecated. That does not matter.
Note that SSL_CTX_set_ssl_version() has to re-set the cipher list
to filter out ciphers unsupported by the new version. It uses
the default cipher list as its starting point, which I assume on
EL8 includes the security level in the cipher string.
You can set the cipher list (and security level) back to what you
want afterward, but I note that this behavior is a result of the
OS-vendor customization and not inherent to openssl.
-Ben
Re: openssl 3 alpha 1 test failures on AIX
On Wed, May 06, 2020 at 05:22:17PM -0700, Norm Green wrote: > All tests on AIX fail like this. Is this a known issue? What debugging > information is needed? Should I open an issue on github? > > Also note I had to set LD_LIBRARY_PATH to the SSL build directory to get the > tests to run at all. > > > > > > normg@sky>gmake test > make depend && make _tests > ( SRCTOP=. BLDTOP=. > PERL="/export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl" EXE_EXT= > /export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl ./test/run_tests.pl ) > 01-test_abort.t > # The results of this test will end up in test-runs/test_abort > 1..1 > Use of uninitialized value in concatenation (.) or string at > ../../util/wrap.pl line 14. > Use of uninitialized value in concatenation (.) or string at > ../../util/wrap.pl line 14. > Unmatched ) in regex; marked by <-- HERE in m/ '') <-- HERE eq '' && -d > ../../util/../engines; > = ../../util/../providers > if ( / at ../../util/wrap.pl line 14. > ../../util/wrap.pl ../../test/aborttest => 255 > ok 1 - Testing that abort is caught correctly > ok > 01-test_sanity.t ... > # The results of this test will end up in test-runs/test_sanity > 1..1 > Use of uninitialized value in concatenation (.) or string at > ../../util/wrap.pl line 14. > Use of uninitialized value in concatenation (.) or string at > ../../util/wrap.pl line 14. > Unmatched ) in regex; marked by <-- HERE in m/ '') <-- HERE eq '' && -d > ../../util/../engines; That looks like your perl is unhappy about something; do you have other versions of perl available to try? Thanks, Ben
Re: Export regulation / EAR 742.15
You might find https://github.com/openssl/openssl/issues/10923 to have some useful information. OpenSSL is publically available.
Re: liblegacy.a does not work unless compiled with -static
Hm, so DSO support is a requirement for legacy crypto now? That probably needs to be made explicit, and see if the project gets pushback.
Re: 04/26/2020 openssl smime question...
* I have seen scripts that have the openssl smime option of -inform, or -outform set to DEM. That’s an error. PEM or DER. Interesting mixup. :)
