Re: TLSv1.2 Distinguished Names Length 0 / how to set it
Hi Viktor,
Thanks a lot for your detailed response and the suggestion. I am going to
implement it and let you know.
I really appreciate your quick feedback on my request.
Thank you and best regards
Olivier
On Wed, Jan 19, 2022 at 5:49 PM Viktor Dukhovni
wrote:
> On Wed, Jan 19, 2022 at 05:21:27PM +0100, Olivier Germain via
> openssl-users wrote:
>
> > We have a requirement to implement the Distinguished Name in the
> response
> > received by the client. Hopefully I am ok.
>
> More accurately, you're being asked to send a suitable non-empty list of
> "Distinguished Names" in server "certificate request" extensions, when
> soliciting client certificates. This can be necessary to, e.g., solicit
> client certificates from Java applications, which select the certificate
> to use based on the names suggested by the server.
>
> > How can I set in my SSL code the value for the distinguished Name?
>
> Something along the lines of the below, which extracts the subject
> DNs from a PEM file with trusted issuer (root CA) certificates:
>
> if (CAfile) {
> STACK_OF(X509_NAME) *calist = SSL_load_client_CA_file(CAfile);
>
> if (calist != NULL)
> SSL_CTX_set_client_CA_list(ctx, calist);
> }
>
> The operator of the server should be able to configure a file of trusted
> client cert issuers separately from the default list of trusted issuers.
> This would ideally hold just one or a few CAs actually used to issue
> client certificates trusted by the server in question.
>
> Note the documented ownership transfer:
>
>SSL_CTX_set_client_CA_list() sets the list of CAs sent to the client
>when requesting a client certificate for ctx. Ownership of list is
>transferred to ctx and it should not be freed by the caller.
>
> There are other ways to construct a stack of CA X.509 names, but loading
> them from a PEM file of CA certs is typically the simplest option.
>
> --
> Viktor.
>
--
Olivier GERMAIN
TIBCO Support
TIBCO software
18, rue du 4 Septembre
75002 Paris, France
Mobile : +33 6 45 30 23 31
自动回复: Re: TLSv1.2 Distinguished Names Length 0 / how to set it
您好，您的邮件我已收到，我会尽快阅读，谢谢！
TLSv1.2 Distinguished Names Length 0 / how to set it
Good afternoon,
I am new in Openssl, SSL. So please excuse my poor knowledge.
We are using Openssl 1.0.2j as a 3rdparty in our software to establish SSL
connection. We can be a server and/or a client.
We have a requirement to implement the Distinguished Name in the response
received by the client. Hopefully I am ok.
To test the connectivity, I am using this command:
/opt/tibco/fp390hf1/3rdparty/linux/openssl/1.0.2j_x86_64/bin/openssl
s_client -connect 192.168.127.146:9443 -cert
/home/tibco/sslcerts/Certificates/client.pem -key
/home/tibco/sslcerts/Keys/client_priv.key -CAfile /home/tibco/sslcerts/CA/
trustedca.ca
In my software logs, I can see that the connection was accepted as below:
2022-01-18
11:55:58.115908|DEBUG|netmanca:5|drv|137707586761066:6|CONNECTION ACCEPTED
from address
2022-01-18
11:56:01.214486|DEBUG|netmanca:10|drv|137707586761066:6|CONNECTION RECV <1>
bytes received, data <
>
I took some tcpdump to analyze the data received from the client and
replied back to the client. I can see that the Distinguished Name has a
length of 0.
[image: image.png]
I apologize in advance for the question and the poor details. How can I set
in my SSL code the value for the distinguished Name?
Our client pointed us to the following RFC but I am not sure to
understand where to add this information in my code.
This information can be inserted during the TLS handshake, in the
"certificate request" message, in the field "DistinguishedName".
See https://tools.ietf.org/html/rfc5246#page-53 7.4.4. Certificate Request
opaque DistinguishedName<1..2^16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
Please let me know if you need further details from my side.
Thank you very much in advance for your help.
Best regards
--
Olivier GERMAIN
TIBCO Support
TIBCO software
18, rue du 4 Septembre
75002 Paris, France
Mobile : +33 6 45 30 23 31
Re: Order of providers breaks my keymgmt
On 17/01/2022 09:49, Tomas Mraz wrote:
On Mon, 2022-01-17 at 09:36 +0100, Milan Kaše wrote:
Hi,
I successfully implemented OpenSSL v3 provider which provides store
and keymgmt and I can use it to sign a cms with the following
command:
openssl cms -sign -signer myprov:cert=0014 -provider myprov -provider
default
However when I swap the order of providers (in the real world
scenario
the providers are configured through the configuration file), i.e.
openssl cms -sign -signer myprov:cert=0014 -provider default -
provider myprov
the command stops working.
I return the private key from the store through the reference:
int construct_ec_key(LOADER_CTX *myloader, OSSL_CALLBACK *object_cb,
void *object_cbarg) {
static const int object_type = OSSL_OBJECT_PKEY;
static const char data_type[] = "EC";
KEYREF ref = { 0, };
OSSL_PARAM objparams[] = {
OSSL_PARAM_int(OSSL_OBJECT_PARAM_TYPE, (int *)_type),
OSSL_PARAM_octet_string(OSSL_OBJECT_PARAM_REFERENCE, ,
sizeof(ref)),
OSSL_PARAM_utf8_string(OSSL_OBJECT_PARAM_DATA_TYPE, (char
*)data_type, COUNTOF(data_type) - 1),
OSSL_PARAM_END,
};
return object_cb(objparams, object_cbarg);
}
The try_key_ref function then tries to transform data from the store
into the EVP_PKEY. It first looks up a keymgmt that can handle the
"EC" data type. Since the default provider is the first one that can
do that it is selected. It then tries to export data from my keymgmt
and import it into the selected default keymgmt. But obviously I
can't
export the private key and the operation fails.
We need to add a fallback in the try_key_ref() to try to fetch the
keymgmt from the provider of the store if the key is unexportable.
Could you please open an issue?
When my provider is activated before the default one then everything
works because the EVP_PKEY is constructed from my keymgmt.
What am I doing wrong? Shouldn't OpenSSL first try to construct
EVP_PKEY from the provider it actually returned the data? Is there a
way to force OpenSSL to use the specified provider (some property
"provider=myprov")?
You can set a default property query in the configuration file with
"?provider=myprov" as a workaround. That way your provider will be
preferred for the operations. However it might have some unwanted and
unexpected consequences.
Please, this is clearly a bug. When the input specifies a specific
providerin the key/cert reference ("-signer myprov:cert=0014"), it
is a serious bug for the code to ignore that and query other
providers from the general priority list. Ditto when a cert storage
provider identifies a key, that provider should get first chance to
find/provide thekey.
Enjoy,
Jakob Bohm
--
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
stunnel 5.62 released
Dear Users, I have released version 5.62 of stunnel. ### Version 5.62, 2022.01.17, urgency: MEDIUM * New features - Added a bash completion script. * Bugfixes - Fixed a transfer() loop bug. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 9cf5bb949022aa66c736c1326554cca27d0641605a6370274edc4951eb5bd339 stunnel-5.62.tar.gz fbfcc5759344bcafff9ff3bc6cf56c7fb75cb1244b76d4934c5d9a3eb7eee32d stunnel-5.62-win64-installer.exe 4b52ed6e4bb8293fdefb10ee8c271400a8c1749254a11b674ff690eae00b3c5e stunnel-5.62-android.zip Best regards, Mike OpenPGP_signature Description: OpenPGP digital signature
Re: OpenSSL provider replacement for ENGINE_load_private_key
On 13 Dec 2021, at 12:15, Tomas Mraz wrote: > One option would be for a provider to provide provider-storemgmt > implementation to load a key from its special URI. You'd then use > OSSL_STORE from the application to load a private key from that special > URI. > > Another, rather simplistic, approach would be to use the > EVP_PKEY_fromdata() function. In that case you'd have to know what the > key algorithm are you using. You'd then use EVP_PKEY_CTX_new_from_name > with query properties to include "provider=your_provider" and the > params used with EVP_PKEY_fromdata() would contain just the special id > parameter that the provider would use to identify the private key from > the device. The specific example is for PKCS11. Is there a PKCS11 provider available to be used? Regards, Graham —
Re: EVP_PKEY_get_int_param is not getting degree from EC key
On 2022-01-05 09:45, Tomas Mraz wrote: ... So you're basically asking to put something like - "The parameter most probably won't fit into unsigned int." - to every such parameter documented for PKEYs? "unsigned BIGNUM" instead of "unsigned integer" would be short and much clearer in the description and naming of parameters unlikely to fit in a C int/long. Also to me "the degree of an EC curve" refers to the form of the curve equation, not the bit length of the point coordinates, for example, the P-384 curve uses a degree 3 equation, and modulo prime p and curve order n both being 384-bit bignums. What many API users probably want is a quick way to get the nominal bit length of a public key or group, as a proxy for the cryptographic strength and as a rough guide to allocating data buffers. This API should not give access to or reveal the exact group parameters or public key, that would be different (but still needed) APIs/parameters. For example, it would return 4096 for RSA4096, 384 for the NIST P-384 curve etc. Enjoy, Jakob Bohm 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: Larger RSA keys (Modulus bits > 16384)
On 26/12/2021 16:21, Grégory Widmer via openssl-users wrote: Dear OpenSSL users, I have a question about OpenSSL. Recently, I asked myself if there was a maximum bit length for the modulus of a RSA key. I tried to type : user@host:~$ openssl genrsa 32768 Warning: It is not recommended to use more than 16384 bit for RSA keys. Your key size is 32768! Larger key size may behave not as expected. Generating RSA private key, 32768 bit long modulus (2 primes) I got this warning, and I wonder why a larger key size may behave not as expected. I don't know, but maybe it is a reference to other RSA libraries not working with keys larger than 2 Kibibytes. In particular the GPG documentation warns that using larger RSA or DH keys is much less efficient in terms of security overhead that they recommend ECC instead. However only the author of that warning message can answer why they wrote it. Could anyone explain or give resources on why this doesn't work ? My guess is that, having the following : (M = message, C = Ciphered) > C = M^e ≡ n > > e = 65537 > > n = p X q If M^e is < n, we could easily compute the original message ? In general the formula is C = (M^e % n) also written as C ≡ M^e (mod n), I am not sure why you used the ≡ congruence symbol as a modulus operator (% in C, C++ etc. mod in many textbooks). Also, many systems for using RSA pad M to enough bits that M^e > n, thus ensuring that the modulo operation affects the result. In particular, both versions of PKCS#1 do that in different ways. There was an unfortunate ISO standard that forgot to do that and it was found to be insecure. For signing, the keys are swapped so S = (M^d % n) or S ≡ M^d (mod n), where d is the secret key, while the recipient checks that M ≡ S^e (mod n) or that M2 = (S^e % n) can be securely unpadded back to the actual M. Also, I want to apologize if my question is redundant, I tried to search on GitHub and through the mailing list, but there is no search feature in the mailing list. Have a nice day ! Grégory Widmer PS : This question is for knowledge purpose only, I don't use RSA keys anymore (except with GPG), I prefer ECC :) -- 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
Larger RSA keys (Modulus bits > 16384)
Dear OpenSSL users, I have a question about OpenSSL. Recently, I asked myself if there was a maximum bit length for the modulus of a RSA key. I tried to type : user@host:~$ openssl genrsa 32768 Warning: It is not recommended to use more than 16384 bit for RSA keys. Your key size is 32768! Larger key size may behave not as expected. Generating RSA private key, 32768 bit long modulus (2 primes) I got this warning, and I wonder why a larger key size may behave not as expected. Could anyone explain or give resources on why this doesn't work ? My guess is that, having the following : (M = message, C = Ciphered) If M^e is < n, we could easily compute the original message ? Also, I want to apologize if my question is redundant, I tried to search on GitHub and through the mailing list, but there is no search feature in the mailing list. Have a nice day ! Grégory Widmer PS : This question is for knowledge purpose only, I don't use RSA keys anymore (except with GPG), I prefer ECC :)
stunnel 5.61 released
Dear Users, I have released version 5.61 of stunnel. ### Version 5.61, 2021.12.22, urgency: LOW * New features sponsored by the University of Maryland - Added new "protocol = capwin" and "protocol = capwinctrl" configuration file options. * New features for the Windows platform - Added client mode allowing authenticated users to view logs, reconfigure and terminate running stunnel services. - Added support for multiple GUI and service instances distinguised by the location of stunnel.conf. - Improved log window scrolling. - Added a new 'Pause auto-scroll' GUI checkbox. - Double click on the icon tray replaced with single click. - OpenSSL DLLs updated to version 3.0.1. * Other new features - Rewritten the testing framework in python (thx to Peter Pentchev for inspiration and initial framework). - Added support for missing SSL_set_options() values. - Updated stunnel.spec to support RHEL8. * Bugfixes - Fixed OpenSSL 3.0 build. - Fixed reloading configuration with "systemctl reload stunnel.service". - Fixed incorrect messages logged for OpenSSL errors. - Fixed printing IPv6 socket option defaults on FreeBSD. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 91ea0ca6482d8f7e7d971ee64ab4f86a2817d038a372f0893e28315ef2015d7a stunnel-5.61.tar.gz 19c5ff1f4101af1e69585328303c14249db2ec9063542101ca31edb6f6cc502f stunnel-5.61-win64-installer.exe 928ec94690564498bf523228946b2cdc90c7e346d6f0baf1f71b76cbe769b96c stunnel-5.61-android.zip Best regards, Mike OpenPGP_signature Description: OpenPGP digital signature
Re: Which version to upgrade to?
On Mon, Dec 20, 2021 at 10:24:54AM +, LN via openssl-users wrote: > Hello, > I'm currently using a pre-release version of openssl 1.1.1 and want to > upgrade to a release version. > With the release of openssl 3.0 (and now 3.0.1) while 1.1.1 is still ongoing > development, do you recommed using one version over the other???Is there an > advantage to use one or the other or just a matter of choice?What is the plan > for 1.1.1 after the end of LTS period? > Are we going to have a 3.1 release soon? My advice stick with openssl 1.1.1 . Many apps still have to rewrite for openssl 3.0.X . > Sorry for the many questions! > Thank you! -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Merry Christmas 2021 and Happy New Year 2022 Beware https://mindspring.com
Which version to upgrade to?
Hello, I'm currently using a pre-release version of openssl 1.1.1 and want to upgrade to a release version. With the release of openssl 3.0 (and now 3.0.1) while 1.1.1 is still ongoing development, do you recommed using one version over the other? Is there an advantage to use one or the other or just a matter of choice?What is the plan for 1.1.1 after the end of LTS period? Are we going to have a 3.1 release soon? Sorry for the many questions! Thank you!
OpenSSL provider replacement for ENGINE_load_private_key
Hi all, The ENGINE API is deprecated in favour of the new Provider API. What is the provider equivalent function that replaces ENGINE_load_private_key()? Regards, Graham —
Question About OpenSSL 3.0, FIPS and Solaris Support
Hi, I'm hoping someone can shed some light on something that's confusing me. In the blog post about the FIPS submission<https://www.openssl.org/blog/blog/2021/09/22/OpenSSL3-fips-submission/> it states that one of the platforms that's being tested is "Oracle Solaris 11.4 on Oracle SPARC M8-1". However, on the platform policy page<https://www.openssl.org/policies/platformpolicy.html> it lists a number of Solaris platforms, all of which are currently "unadopted". How should people interpret that? That the initial release of OpenSSL 3.0 was supported on Solaris, but no releases after that are? Or something else? Thanks, David
自动回复: Re: SSL_CTX_set_tlsext_ticket_key_evp_cb
您好，您的邮件我已收到，我会尽快阅读，谢谢！
自动回复: Re: Need Replacement for Deprecated function.
您好，您的邮件我已收到，我会尽快阅读，谢谢！
自动回复: (OpenSSL bug please fix) Re: Need Replacement for Deprecated function.
您好，您的邮件我已收到，我会尽快阅读，谢谢！
Re: New Blog Post
On 2021-11-25 15:00, Matt Caswell wrote: Please see the new blog post by Tim Hudson giving an update on the OpenSSL Project. https://www.openssl.org/blog/blog/2021/11/25/openssl-update/ Followup: While the OpenSSL leadership may think they have made things easier for algorithm developers, the changes have actually removed the existing APIs for implementing new modes on top of the existing library: 1. The ability to easily provide or override new EVP algorithm implementations within "application" code has been removed with the opaqueness of the structure defining the implementation function pointers for an algorithm. 2. The interfaces to directly call primitives like the AES block function have gone, leaving only awkward workarounds based on setting specific block cipher modes and calling the entire EVP stack for each block. Other "trivial" operations on block mode states (such as saving and storing running states) have also been lost. 3. Some BigNum library features have also been lost in the opaque everything push, in particular the ability to preallocate buffers for bignums up to an application specific bit count using the BN_FLG_STATIC_DATA option. 4. Any attempt to compare the "modern" source code to the classic source code from before the influx of new developers and money is heavily frustrated by the decision to reformat all source files midway through the 1.0.x patch series. All 4 changes have greatly affected my own work to use OpenSSL in an application originally designed around another open cryptographic API. Where the application included such things as optional use of a different AES mode, and security rules for when/if to restore algorithm states in error/trial decryption scenarios. 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: Starting the QUIC Design
Please note that the embedded github links don't work for me, as all I get is an error page with a log in form. One major issue with any QUIC implementation is how closely that protocol is tied to Google and their desire to have web browsers quickly load elements from 3rd part webservers, such as Google's own tracking code. On 2021-12-03 13:04, Matt Caswell wrote: Please see my blog post on starting the QUIC design here: https://www.openssl.org/blog/blog/2021/12/03/starting-the-quic-design/ Matt 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 1.1 on OSX
Which is indeed what I do in our notarized MacOsX and iOS applications. However to do so, I have historically needed to clean up OpenSSL source code to actually behave as a proper static library where only used functions are linked in. Most notably, the source files named xxx_lib.c tend to cause the opposite behavior by bundling used and unused code into a single .o file, so I had to do thematic splitting of those source files, to not only avoid the unused functions getting linked in, but also the unused .o files referenced by those unused functions. This problem is fully cross platform, although some more detail work had to be done to ensure compatibility of certain source files with XCode bundled tool chains (In particular the optimized assembler files). On 2021-11-20 07:47, Dr Paul Dale wrote: An alternative would be to statically link libssl and libcrypto. No more dependencies. Pauli On 20/11/21 3:48 pm, Viktor Dukhovni wrote: On Sat, Nov 20, 2021 at 01:38:39PM +1100, Grahame Grieve wrote: I agree it's sure not a core openSSL issue. But surely lots of people want to use openSSL in cross platform apps and openSSL is interested in adoption issues? Most of the users here are building applications that are not notarised, and so work with the upstream builds. Anyway, it looks like I now have to figure out how to maintain a custom build of openSSL :-( It shouldn't be too difficult to execute the build, once you've figured out the actual requirements. Apparently you need to make sure that signed code has very explicit dependencies, which makes some sense, so the libraries bundled with the application need to be built in a way that can be verified along with the application. My best guess is that Apple are not specifically picking on OpenSSL here, and similar issues would arise with any other libraries you'd want to package with your application. Good luck. Feel free to share your findings. Perhaps someone will then help you find a way to improve on them, or to add a template to the build to support this going forward... 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
Blanks
Testing to see if I get a blank. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Merry Christmas 2021 and Happy New Year 2022 Beware https://mindspring.com
[no subject]
[no subject]
AW: AES-GCM decrypt with OpenSSL 1.1.1 - when to set the tag?
> I've raised a PR to correct the docs here: > > https://github.com/openssl/openssl/pull/17111 > > Hopefully that is sufficient to convince your reviewers. Thanks, Matt. That should do the trick. Regards, Andrew.
AES-GCM decrypt with OpenSSL 1.1.1 - when to set the tag?
Hi, We have an application that uses OpenSSL 1.1.1k to receive AES256-GCM encrypted messages. The streamed data starts with a 12 byte IV, then the ciphertext and ends with the 16 byte tag. Our decryption code is based directly on the sample code in the Wiki and the distribution. https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption#Authenticated_Decryption_using_GCM_mode https://github.com/openssl/openssl/blob/9b06ebb1edfddffea083ba36090af7eb7cad207b/demos/evp/aesgcm.c#L82-L115 First call EVP_DecryptInit_ex, set the IV length, provide key and IV. Some number of EVP_DecryptUpdate calls. Finally set the tag and call EVP_DecryptFinal_ex. An external code review has now pointed out to us that we should set the tag before the IV, according to OpenSSL documentation. https://www.openssl.org/docs/man1.1.1/man3/EVP_CIPHER_CTX_ctrl.html#GCM-and-OCB-Modes They must be referring to the sentence "The tag length can only be set before specifying an IV." But what exactly does this mean? EVP_CTRL_AEAD_SET_TAG sets both the tag length and the value in a single call, unlike EVP_CTRL_AEAD_SET_IVLEN which only sets the IV length. We do not have the tag value until the end of the message has been received. I guess the sample code happens to work because 16 byte is the default tag size, so it is already "set" correctly before the IV is specified. How can we convince the reviewers that this is a non-issue? Regards, Andrew.
[no subject]
自动回复: Re: OpenSSL 1.1 on OSX
您好，您的邮件我已收到，我会尽快阅读，谢谢！
自动回复: Re: OpenSSL 1.1 on OSX
您好，您的邮件我已收到，我会尽快阅读，谢谢！
自动回复: Re: “EC PUBLIC KEY”
您好，您的邮件我已收到，我会尽快阅读，谢谢！
自动回复: Re: “EC PUBLIC KEY”
您好，您的邮件我已收到，我会尽快阅读，谢谢！
自动回复: Re: X509_get_pubkey() in OpenSSL 3.0?
您好，您的邮件我已收到，我会尽快阅读，谢谢！
error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown
Hello I get my log spammed with this alert: sslize error: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown As far as I can read from the net, it is because the CA certificates on my server is not up to date. Actually there is none, as this is an embedded target, and it should ignore that kind of errors. It works with ssl, but how do I get rid of this message. What options should be set? I just opdated to libssl 1.1.1k, and is using civetweb as server. Regards Kjeld Flarup DEIF R - Platform Software
Fw: openssl s_client privatekey engine pkcs11 - no SSL_connect:SSLv3/TLS write certificate verify
- Forwarded Message - From: Zlatko Vrastic To: "openssl-users@openssl.org" Sent: Friday, October 22, 2021, 03:25:10 PM GMT+2Subject: openssl s_client privatekey engine pkcs11 - no SSL_connect:SSLv3/TLS write certificate verify When using openssl s_client .. -keyform engine -engine pkcs11 -key 0:00 there is no SSL_connect:SSLv3/TLS write certificate verify step in handshake protocol and server rejects connection. Connection is https get to get token for further communication. During this https get tls1.2 is used as protocol. Connecting to server with Windows and Visual Studio https request is good with pfx or with smart card, we get token. On Linux openssl+opensc connection with client.pem and privatekey.pem extracted from pfx certificate is ok, we get token. When we use smart card with openssl+opensc we get authorisation denied, the ssl client is not sending SSL_connect:SSLv3/TLS write certificate verify. Comparing log from ssl, the initial handshake is the same, when we send get request string, after that handshake is different. good communication when used client.pem and privatekey.pem SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully SSL_connect:SSLv3/TLS read hello request SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:SSLv3/TLS read server certificate SSL_connect:SSLv3/TLS read server key exchange SSL_connect:SSLv3/TLS read server certificate request SSL_connect:SSLv3/TLS read server done SSL_connect:SSLv3/TLS write client certificate SSL_connect:SSLv3/TLS write client key exchange SSL_connect:SSLv3/TLS write certificate verify SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS read change cipher spec SSL_connect:SSLv3/TLS read finished read R BLOCK HTTP/1.1 200 OK missing write certificate verify when using gids smartcard: -keyform engine -engine pkcs11 -key 0:00 (works the same used also: -keyform engine -engine pkcs11 -key "pkcs11:id=%00;type=private" ) SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully SSL_connect:SSLv3/TLS read hello request SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:SSLv3/TLS read server certificate SSL_connect:SSLv3/TLS read server key exchange SSL_connect:SSLv3/TLS read server certificate request SSL_connect:SSLv3/TLS read server done SSL_connect:SSLv3/TLS write client certificate SSL_connect:SSLv3/TLS write client key exchange SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS read change cipher spec SSL_connect:SSLv3/TLS read finished read R BLOCK HTTP/1.1 401 Unauthorized Do You have any suggestions on what to try? We debugged and verified that the openssl engine pkcs11 through opensc is working good. Do not know how to specify to s_client to send SSLv3/TLS write certificate verify. When this is not sent we get rejected from the server. Another issue we had was with cipher suites. Server usually works with ECDHE-RSA-AES256-GCM-SHA384. With openssl installed on linux this cipher is used for communication. With openssl installed on windows it returns 742F:error:0A080006:SSL routines:ssl_generate_param_group:EVP lib:ssl\s3_lib.c:4727: 742F:error:0A00013A:SSL routines:tls_process_ske_ecdhe:unable to find ecdh parameters:ssl\statem\statem_clnt.c:2140: this cipher suite is supprted from openssl when checked with ciphers commands. and later with New, (NONE), Cipher is (NONE) We skipped over this with -cipher AESGCM:!ECDHE-RSA-AES256-GCM-SHA384 by specifying to poenssl not to use this cipher, communication is swithed to New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256. But this problem with SSLv3/TLS write certificate verify is the same on linux and windows.
Re: Query reg. using certificates bigger than 4k for EAP-TLS
I'm also a bit confused at how this became the limiting factor for the application in question. https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert-08 has some discussion of how large certificates can cause issues for EAP (as well as some guidance to EAP deployments as to how to reduce the scale of the issues), which suggests that most of the time there is already some buffering going on at a 1-2k chunk size just based on the limits of the EAP exchange's MTU. (The parties in the exchange have to transmit one chunk at a time and get an ACK back before transmitting the next chunk, and once that handshake flight is finished the process is reversed with the other party sending a chunk at a time.) A BIO-layer buffer would be between that and the libssl handshake buffering, and as you describe, it should still get the data through, just maybe with a slight inefficiency. -Ben On Wed, Oct 20, 2021 at 02:30:19PM +0100, Matt Caswell wrote: > Your scenario is still not quite clear to me. > > It sounds like you are using a BIO_f_buffer() BIO to buffer data. This is on > the server side right? Are you encountering this problem for server writes? > Since you are talking about the certificate chain, I assume you are > referring to the server writing that chain. > > libssl itself also uses a BIO_f_buffer() internally for writes during the > handshake. It's not clear to me whether you are referring to the internal > libssl buffering BIO, or one that you have created? > > Either way, the effect of the buffering BIO during writes is that a 4k > buffer is used by default. If data is written that is less than 4k in length > then it is held in the buffer until either the BIO is "flushed" or the > buffer is filled. In the event the buffer gets filled then it is > automatically flushed, and any remaining data gets buffered. > > The only effect of changing the buffer size should be to decrease the > frequency that the buffer gets filled and automatic flushes occur. It sounds > like by trying to increase the buffer size you are seeking to avoid "parial" > writes where only part of the data is flushed and the remainder is held back > for sending later when the buffer is next filled or flushed. This should not > normally make any difference to the correct operation of the protocol > (except for efficiency) although it does depend on what happens "downstream" > of the buffering bio and how partial writes get sent to the peer. > > It sounds like things are not quite working correctly for you when "partial" > writes occur. This sounds like a potential problem in the BIO chain > downstream of libssl (i.e. in your application). > > Matt > > On 20/10/2021 12:34, Vishal Sinha wrote: > > Hi Matt > > > > The certificate is not large as such. But since it's a chain, the > > overall size crosses 4k. We used BIO_set_write_buffer_size() API to > > increase the size from 4k to 8k of the BIO buffer in SSL context. > > > > Regards > > Vishal > > > > > > On Wed, Oct 20, 2021 at 3:26 PM Vishal Sinha > <mailto:vishals1...@gmail.com>> wrote: > > > > Hi > > > > We are using openssl 1.1.1c version on our client and server. Client > > and Server are doing EAP-TLS authentication using certificates which > > are more than 4k in size (using 1 root CA and 2 intermediate CAs). > > We noticed that the server is not able to handle it gracefully due > > to insufficient buffer size during SSL handshake and hence > > authentication fails. To solve this issue, we increased the buffer > > size to 8k programmatically and authentication passed. Is there any > > other way to solve this problem? > > > > Regards > > Vishal > >
Re: Examples of adding Private Enterprise Numbers (PEN's) Extensions to CSR
On 2021-10-14 18:43, Philip Prindeville wrote: Hi, I need to generate CSR's with some Extensions included that use our PEN's as allocated by IANA. Are there any examples of this? Also, I'm looking at X509_REQ_add_extensions_nid() and it takes a STACK_OF(X509_EXTENSION) but it doesn't seem to actually iterate through the stack... Is this code even correct? What am I missing? Ditto for X509_REQ_add_extensions(). Thanks, -Philip I don't know how to do this via the API, but the source code for the command line tools may give some good clues. Here is how I would do it with the command line tools: First of all, you need to (administratively) decide how to subdivide your private OID tree belowyour enterprise ID. This would be a company internal document listing how you use the OIDsand where to put future OIDs of various kinds. Use whatever document editing system is usedfor other long term company documents. Something like: Redfish solutions has been allocated the following OID prefix via the IANA "Enterprise numbers"process: RedfishOid = 1.3.6.1.4.1.999 We subdivide this as follows: RedfishOid.1 = Redfish X.509 extensions RedfishOid.1.1 = FooBar extension, see design document RS12345 RedfishOid.1.2 = BazQux extension, see design document RS12346 RedfishOid.2 = Redfish SNMP extensions RedfishOid.2.1 = Redfish hardware-box-A SNMP extensions RedfishOid.3 = Redfish contributions to public standardisation efforts RedfishOid.4 = Redfish internal LDAP extensions used by HR Next for the OpenSSL command line tools, you need to add the individual X.509 relatedOIDs to the openssl.cnf file: In the [default] section: oid_section = new_oids In the [new_oids] section RedFishFooBar=1.3.6.1.4.1.999.1.1 RedFishBazQux=1.3.6.1.4.1.999.1.2 From there, you should be able to use the new OID names in relevant sections and options, using the generic syntax that explicitly states how each value needs to beencoded. 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
Help on mixed encrypt/decrypt data using C++/java
Hi, We encrypt data using openSSL C++ API, decrypt data using java(default security package). 99.9% of the time, it works fine, but when multi-instances of apps encrypt data at same time, java fails to decrypt . We are using version 1.1.01 (AES/CBC/PKCS5Padding) mpCtx = EVP_CIPHER_CTX_new(); EVP_CIPHER_CTX_init(mpCtx); Thanks for helping, Jason
Re: OpenSSL 3.0.0 custom entropy source
So is there no longer an API to feed entropy to the default or FIPS default RNG? Creating an entire provider just to feed input to the FIPS provider seems overkill. On 2021-09-14 01:00, Dr Paul Dale wrote: Try working from providers/implementations/rands/seed_src.c You'll need to reimplement seed_src_generate() to use your RNG. To use your custom seed source, you can either use the OpenSSL configuration file to set a "random" section that includes a "seed" setting or you can call RAND_set_seed_source_type() early in your startup sequence. Pauli On 14/9/21 8:19 am, Kory Hamzeh wrote: Hi, We are upgrading from OpenSSL 1.0.1g+OpenSSL-FIPS-2.0.5 to 3.0.0. Yes, I know, big jump. We have our own entropy source we use to seed the OpenSSL DRBG. This is a basic code snippet of how we set it up: DRBG_CTX *dctx = FIPS_get_default_drbg(); FIPS_drbg_init(dctx, NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF); FIPS_drbg_set_callbacks(dctx, rand_get_entropy, rand_free_entropy, 0, rand_get_entropy, rand_free_entropy); Error checking has been removed in the example for the sake of brevity. I am trying to figure out how to implement this with OpenSSL 3. From what I have read in the docs, I need to create a rand provider. But I still feel like I don’t understand how it all fit together. I did look at fuzz_rand.c and fake_rand.c, and if I understood everything correctly, neither of them use an external entropy/seed source. Are there better examples of what I am looking for? Thanks, Kory 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: Does the openssl support RFC5755: Group. Role. Access Identify?
Hi, there Is there a way to implement the different access identity for the different cert? For example, by setting the custom field, then the code the read it from the cert. BRs Mystic --Original-- From: "Tomas Mraz"
Does the openssl support RFC5755: Group. Role. Access Identify?
Hi. There Could you give me some help? Thanks a lot. BRs Mystic
Re: Will TLSv1.3 always send session ticket?
On Thu, Sep 16, 2021 at 12:40:55PM -0400, Viktor Dukhovni wrote: > On Thu, Sep 16, 2021 at 09:30:18AM -0700, Benjamin Kaduk via openssl-users > wrote: > > On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote: > > > > > > I don't recall whether OpenSSL makes any effort to or supports deferring > > > the transmission of session tickets until just before the first > > > application data transmission from server to client (or else perhaps > > > just before responding to a received close-notify with a reciprocal > > > close-notify) > > > > It's not the default behavior, but is supported: you can configure the > > SSL/SSL_CTX to send zero tickets by default and then manually call > > SSL_new_session_ticket(), which defers the transmission until there is > > another > > write or explicit SSL_do_handshake() call. > > So nothing built-in... What I had in mind was a built-in behaviour of > the library to delay session ticket transmission until there's a first > opportunity to send some application data, which the client application > can be reasonably expected to read at that point. While I'm not opposed to having some turnkey solution built in, I do think that the current default of sending tickets immediately after the handshake is the correct *default* behavior. That makes the new session (with ticket and resumption capability) available to clients right after the handshake, instead of needing to wait until some actual data from the server arrives. I'd be interested in hearing your thoughts about what an API/config would look like to enable the delayed-send behavior. -Ben
Re: Will TLSv1.3 always send session ticket?
On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote: > > I don't recall whether OpenSSL makes any effort to or supports deferring > the transmission of session tickets until just before the first > application data transmission from server to client (or else perhaps > just before responding to a received close-notify with a reciprocal > close-notify) It's not the default behavior, but is supported: you can configure the SSL/SSL_CTX to send zero tickets by default and then manually call SSL_new_session_ticket(), which defers the transmission until there is another write or explicit SSL_do_handshake() call. -Ben
Re: Getting SSL_SESSION remaining lifetime
On Thu, Sep 16, 2021 at 04:57:03PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 16:28:47 CEST, Benjamin Kaduk wrote: > > On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: > > > On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: > > > > > > > > I am trying to get the remaining lifetime of the ticket so that server > > > > can decide to renew ticket or not > > > > > > TLS 1.3 tickets are single use. If the ticket was used by a client, and > > > you expect it to make a connection in the future, server needs to > > > send a new > > > one. > > > > Single-use tickets are only a protocol requirement when 0-RTT data is used. > > The OpenSSL implementation even allows the libssl-internal enforcement of > > single-use to be disabled (see SSL_OP_NO_ANTI_REPLAY at > > https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html__;!!GjvTz_vk!GxR4URFTB0lwkM5nlYZdtn3DUdeaujsu1sHMYc_nRTUpkmLQP8-zz_b4HS_rcA$ > > ). > > OpenSSL as a client also has some measures to encourate single-use tickets, > > which I have a PR open to provide a knob to disable: > > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/16598__;!!GjvTz_vk!GxR4URFTB0lwkM5nlYZdtn3DUdeaujsu1sHMYc_nRTUpkmLQP8-zz_YPrcg6yw$ > > . > > They're single use not only because of replay but also because of privacy > reasons, as reuse of a ticket indicates that the same client did send it. Yes. But the protocol itself only encourages single-use for privacy reasons. The protocol does not *require* single-use in that case. -Ben
Re: Getting SSL_SESSION remaining lifetime
On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: > > > > I am trying to get the remaining lifetime of the ticket so that server > > can decide to renew ticket or not > > TLS 1.3 tickets are single use. If the ticket was used by a client, and > you expect it to make a connection in the future, server needs to send a new > one. Single-use tickets are only a protocol requirement when 0-RTT data is used. The OpenSSL implementation even allows the libssl-internal enforcement of single-use to be disabled (see SSL_OP_NO_ANTI_REPLAY at https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html). OpenSSL as a client also has some measures to encourate single-use tickets, which I have a PR open to provide a knob to disable: https://github.com/openssl/openssl/pull/16598 . -Ben
Re: Reducing the footprint of a simple application
On 2021-09-14 12:14, Dr Paul Dale wrote: > ...low security RNGs and other antifeatures. Huh Where? Why plural? The only **one** I'm aware of is the one I added to stochastically flush the property cache where it doesn't need to be cryptographically secure. Some applications need more than 256 independent random bits to satisfy their security design. Some of the newer RNGs in OpenSSL presume otherwise in their government design. 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: Reducing the footprint of a simple application
Hi fellow sufferer, I used to do a lot of manual patching of OpenSSL 1.0.x to remove the insane object interdependencies (such as objects named foolib.c being nexus points that bring in tonnes of irrelevant code because someone was too unfamiliar with basic library concepts to make an actual library instead of a monolithic file). However the rush to repeatedly rewrite and deprecate everything after the new people joined the OpenSSL project made maintaining the needed patches too time consuming. Some day, I will have to start over turning the 3.0.x code into an actual library while removing linker mishandling, low security RNGs and other antifeatures. On 2021-09-12 19:34, Reinier Torenbeek wrote: Hi, I have a simple application that uses OpenSSL 3.0.0 for AES-GCM encryption and decryption only. Looking at the size of the binary on disc, I see it's a few KBs when linking dynamically with libcrypto, and 4.8 MB when linking statically. Although I know the large footprint of OpenSSL is considered "a fact of life", this seems excessive. From experience with other crypto implementations, I know that the *actual* crypto functionality that I am using can fit in 10s of KBsand I would like to understand the reasons for OpenSSL's size better. I am on Linux, 64 bits, using gcc 9.3.0. Some analysis of the binary reveals (not surprisingly) that it contains many OpenSSL symbols that have nothing to do with the functionality that I am using. Those seem to get pulled in because objects get linked in as a whole and apparently the layout of the object contents are such that the symbols needed for my functionality are spread out over many different objects. It was my hope that I could mitigate this by compiling OpenSSL and my application with the flags -ffunction-sections, -fdata-sections, -Os and -flto and using --gc-sections and -flto when linking. (See 3.10 Options That Control Optimization <https://gcc.gnu.org/onlinedocs/gcc-9.4.0/gcc/Optimize-Options.html#Optimize-Options> of GCC's documentation). This did reduce the binary size by 2 MB, leaving me with almost 3 MB. Almost 90% of that was in the text section and a bit over 10% in the data section. I do not have sufficient experience with these options to assess how well the optimizations worked in this case, I think the resulting binary is still pretty large. I have not tried disabling any of the features when building OpenSSL. I suspect that may help a little bit because it may result in a decrease in size of (some) objects, but I have seen people reporting disappointing results of that on the web. Also, it does not seem to be a workable approach in general to have to figure out which build options to use and to have to rebuild OpenSSL for every type of application that I create. Did any people here try similar things, with better results? Does anybody have any other suggestions as to what I could try? And what is the explanation (or justification) for this excessive footprint? Thanks, Reinier 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 3.0.0 two tests fail on Solaris 10 SPARC64 ( Oracle/Fujitsu )
On Sat, Sep 11, 2021 at 10:29:07PM -0400, Dennis Clarke via openssl-users wrote: > > This is slightly better than the beta release : > > Test Summary Report > --- > 03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > 90-test_ige.t(Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > > > What can I dig into here to get more information and perhaps we solve > these two little tests fails? `make V=1 TESTS="test_internal_modes test_ige" test` -Ben
OpenSSL 3.0.0 two tests fail on Solaris 10 SPARC64 ( Oracle/Fujitsu )
This is slightly better than the beta release : Test Summary Report --- 03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 90-test_ige.t(Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 What can I dig into here to get more information and perhaps we solve these two little tests fails? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
OpenSSL 3.0.0 on Solaris SPARC64
Merely an FYI that all seems to be working well. There are a few tests that fail and they are the same ones I saw in the beta releases. I can follow up with details later but for now I am curious what the directory "lib/engines-3" is for ? I get that as an empty directory and my configuration was : ./Configure solaris64-sparcv9-cc no-asm --prefix=/opt/bw shared no-engine -DPEDANTIC So the no-engine may just mean I get an empty directory result ? beta # /opt/bw/bin/openssl version OpenSSL 3.0.0 7 sep 2021 (Library: OpenSSL 3.0.0 7 sep 2021) beta # Looks fine and with a slight adjustment to the Makefile I do not get that annoying lib/64 directory. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Congratulations! Missing 3.0.0 tag?
On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote: > But if i use > > #?0|kent:tls-openssl.git$ alias gl1 > alias gl1='git slpn -1' > #?0|kent:tls-openssl.git$ git alias|grep slpn > alias.slpn log --show-signature --patch --find-renames --stat > --no-abbrev-commit > #?0|kent:tls-openssl.git$ gl1 openssl-3.0.0 > commit 89cd17a031e022211684eb7eb41190cf1910f9fa (tag: > refs/tags/openssl-3.0.0) > ... > > i do not. Hm, maybe i need to relearn git again, looking around > i see a couple of projects for which this is true (Linux, > wireguard-tools), for others it is not (my own project, nghttp2). > Eg "alias.slo log --show-signature --oneline --graph": I think (off the top of my head, i.e., without consulting a reference) that `git log` (which your aliases end up at) will only display signatures on commits, but will not show the tag objects themselves. `git show` does display the tag object, and for openssl only the tag object is what is signed; the commits themselves are not signed. -Ben
Re: Congratulations! Missing 3.0.0 tag?
On Thu, Sep 09, 2021 at 12:15:44AM +0200, Steffen Nurpmeso wrote: > > P.S.: maybe at least release commits and tags could be signed? > And/or HTTPS access to the repository ... but then i get the gut > feeling that the answer to this will be "use github" or something. tag openssl-3.0.0 Tagger: Richard Levitte Date: Tue Sep 7 13:46:40 2021 +0200 OpenSSL 3.0.0 release tag -BEGIN PGP SIGNATURE- iFwEABECAB0WIQTEyrdJw09/TMBP2smnr5549wlFOwUCYTdRIAAKCRCnr5549wlF O7wEAJ90wRuQnQYdf7RrzD7p2tf2eZhP4QCXeXX3a1IgbIgfU7WuLZ44BbXF7w== =pGf9 -END PGP SIGNATURE- looks signed to me. -Ben
OpenSSL version 3.0.0 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL version 3.0.0 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 3.0.0 of our open source toolkit for SSL/TLS. For details of the changes, see the release notes at: https://www.openssl.org/news/openssl-3.0-notes.html Specific notes on upgrading to OpenSSL 3.0 from previous versions are available in the OpenSSL Migration Guide, here: https://www.openssl.org/docs/man3.0/man7/migration_guide.html OpenSSL 3.0.0 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.tar.gz Size: 14978663 SHA1 checksum: 3be896f1b33bc01af874ccca701a6f700af9de20 SHA256 checksum: 59eedfcb46c25214c9bd37ed6078297b4df01d012267fe9e9eee31f61bc70536 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0.tar.gz openssl sha256 openssl-3.0.0.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAmE3US4ACgkQ1enkP335 7owe+w/9FdP6I9XEuuo5O6ZOhYyzTuS8v9DGuzIzBEsBWpsA+gfOxF5Bx4WlnGAt kB+2qfNfOgt00OrSUHntgn1+ubFvN+xteaslYsF3fN9FCPX2iQzXMPVM47UqYpA5 tCm0XrJo+PAZB4mEnOH6QBXZWPTE7E84HGUNyS8LfYeEbbLKEcc/xQBPpRovL3fA 6TnMrAvypIwEqgljyNzuMq7iD5WDA0Y26JwjCCtk0vNOVkDQDooGQHMY180BLfQT Rk65hEt3/UkpLVCwCknrZsMWixXzTgcFb+403EPXMisyyQLEgxevrsGpQgINxraD 1JyRNnwJpIJuxl+j1oYjpdCbNQrQr7QKAj8pL5OGNVxXvyuZe9YyLrKmHvh09Q6M nxbJFQmCyrZQvxCya+YR2VU9KxkYiXbiX2pHl06qN8n3MOhtVaxJPKM6WUwJLlo9 qD9JmLtW4gXCH4qHcqnb8jS0Zoxja1bzWwgvQx1A9XI4s2drhRvXkQmt+lxEUdcM MiT3LrBgjfKgNa7XWmTOZxyLa74WyETVcjvI3ovJxiS4RAB7s7ssDVa8tnTUeeZG gtXSTv49+l0j+DQcz8nxQeILimOusHzE5JO3JvGQKPbSQbdUQbNrsbTEvz5mIMu9 k/VuvJd1ezjYySp9pnZ3UTxrB1RozJ97iupq8MSzwElkSfUigrg= =R5PX -END PGP SIGNATURE-
Question about constness of EVP_PKEY* arguments in public API
Hi, I have some piece of software using OpenSSL that works right now on a single thread right now. I am adding a bit more "const" in the code everywhere I can as we want to start using the same code in multithreaded environment, and potentially two threads might sign/verify/encrypt/decrypt using the same EVP_PKEY argument in multiple threads. By adding "const" I try to find what shall be protected by mutex and what shall not, in case it’s mutable. I am using the following OpenSSL API: EVP_DigestSignInit, EVP_DigestVerifyInit, EVP_PKEY_size, EVP_SealInit, EVP_OpenInit. And it seems these all take an non-const EVP_PKEY* argument. Does it mean that EVP_PKEY* have some internal state which may be updated by these API and which I should definitely not call without thread syncronization in multiple threads ? Or the API of OpenSSL just miss the "const" keyword as really the key, once read, has absolutely no state modified by these APIs ? Note: I have to support several branches of my software, the oldest branches are still using the old OpenSSL 1.0.2, other branches uses OpenSSL 1.1.1, and the latest branch uses the OpenSSL 3.0 release candidate. Cheers, Romain
Re: client authentication status
On Wed, Sep 01, 2021 at 03:36:36PM +, Zeke Evans wrote: > Hi, > > Is there any way to check the status of client authentication sent in a TLS > 1.3 handshake after SSL_connect returns? With TLS 1.2 SSL_connect seems to > always capture the status and return an error code if it failed but not TLS > 1.3. I haven't been able to find a good way to do this after SSL_connect > returns. I have to handle blocking and non-blocking sockets so calling > SSL_read or SSL_peek isn't an option since those could block. If client > authentication happened to fail then calling those methods would work because > they will return an error but if it didn't fail then they could block. Note that the server is allowed to ignore a client cert that it doesn't like, proceeding with the connection as if the client was unauthenticated. If you need a specific signal that the server believes the client successfully authenticated, that has to be at the application layer. Did you try a zero-length SSL_read()? My recollection is that that gets far enough into the library to see if there are pending alert messages to process. -Ben
openssl-1.1.1l fails to build in macOS 10.13.6 with Xcode 10.1
Building openssl-1.1.1l with Xcode 10.1 under macOS 10.13.6 fails with this error In file included from crypto/rand/rand_unix.c:38: /usr/include/CommonCrypto/CommonRandom.h:35:9: error: unknown type name 'CCCryptorStatus' typedef CCCryptorStatus CCRNGStatus; ^ crypto/rand/rand_unix.c:385:47: error: use of undeclared identifier 'kCCSuccess' if (CCRandomGenerateBytes(buf, buflen) == kCCSuccess) ^ 2 errors generated. make[1]: *** [crypto/rand/rand_unix.o] Error 1 The build succeeds and all tests pass if CommonCryptoError.h is added to the __APPLE__ includes in crypto/rand/rand_unix.c #if defined(__APPLE__) # include # include #endif Is this a safe change to make? Best regards, Scott
Re: problems with too many ssl_read and ssl_write errors
For the below symptoms, I would recommend a watching the application port with WireShark. This should show any the TLS protocol deviations and any problems in handling and establishing the TCP connections. On 2021-08-19 00:38, David Bowers via openssl-users wrote: * We have a server that has around 2025 clients connected at any instant. * Our application creates a Server /Listener socket that then is converted into a Secure socket using OpenSSL library. This is compiled and built in a Windows x64 environment. We also built the OpenSSL for the Windows. The Listener socket is created with a default backlog of 500. The Accept socket is non-blocking socket and waits for connections * Every Client makes a regular blocking connection to the Server. The Server accepts the connection after which the Client socket is converted to a secure socket using the OpenSSL Library. * The connections are coming at a rate of about 10 connections /second ? Not sure about this number. * We are able to connect to all the clients in a few minutes and it stays like that for some time. There constant exchange of messages between Server(COS) and clients without issues. * The application logic is to keep trying to connect every timeout. * After maybe a few hours/days we see the clients dropping connections. The logs indicate the SSL_Read or SSL_Write on the Server fails for a client with SSL_Error number 5 (SSL_ERROR_SYSCALL) and the equivalent Windows error of WSATimeOut. We then observe the WSAECONNRESET as the Client closed connection. We see this behavior for multiple sites. * The number of Clients disconnected starts increasing and we see the logs in the Client where the server refuses any more connections form Clients (10061- WSAECONNREFUSED) There is nothing to indicate this state in the server logs. Our theory is the backlog is filled and Server refusing further connections. * We are trying to find why we get the SSL_Read/SSL_Write Error as it a Blocking socket. We cannot use to a non-blocking socket due to platform and application limitation 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: Need some help signing a certificate request
On 21/08/2021 19:42, Michael Wojcik wrote: From: rgor...@centerprism.com Sent: Saturday, 21 August, 2021 11:26 My openssl.cnf (I have tried `\` and `\\` and `/` directory separators): Use forward slashes. Backslashes should work on Windows, but forward slashes work everywhere. I don't know that "\\" will work anywhere. \\ works only when invoking a \ expecting program from a unix-like shell that requires each \ to be escaped with a second backslash in order to pass it through. A typical example is using CygWin bash to invoke a native Win32 program. \\ where neither is an escape (so in the above shell situation) is also used in native Windows programs to access a hypothetical root that is above the real file system roots, typically the syntax is "\\machine\share\ordinary\path", where: machine is either a different computer, a "." for a special higher level local namespace or "??" for another special namespace. share is the first level below machine, in particular it is the exported name of a remote file system or object. ordinary\path is whatever else needs to be added to the path for a specific use -- 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: libcrypto.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
This is a known deficiency of how Apple rushed adding support for their M1 ARM Desktop CPU to the XCode build suite. When building a desktop macOs program file with XCode, it will implicitly try to build both an x86_64 and an arm64 variant, and will get very surprised your compiled open source library files contain only code for one of those architectures. A potential workaround is to build OpenSSL for all 3 macOs desktop architectures and combine them with the "lipo" tool to create a "fat library". The major shortcoming of this is that they use the same architecture "key" value for macOs and iOs, but require the libraries to be compiled differently (because the ABI for some system functions differ). Before the M1 merge, this would work thanks to arm64 always being iOS hardware and x86_64 always being macOs hardware. A workaround for that is to create a separate set of library files for iOS (including iOS emulator on x86-family desktops) and macOs (including x86-family and arm64 architectures), then being careful to reference the right set for each project. Unfortunately, there is no workaround to use the same set of library files for iOS on arm64 mobile hardware and iOS emulator on arm64 desktop hardware. On 2021-08-18 07:40, Stephen Dominic Liang wrote: Hi. I installed OpenSSL 1.1 (MacOS 11.3.1) using Homebrew. I added the following to my .bash_profile: export PKG_CONFIG_PATH="/opt/homebrew/opt/openssl@1.1/lib/pkgconfig" I added this to the global path file at /etc/paths: /opt/homebrew/opt/openssl@1.1/bin I've tried a number of other steps. What are some other fixes/suggestions for debugging this issue? Errors: |/Applications/CLion.app/Contents/bin/cmake/mac/bin/cmake --build /Users/stephenjje/Documents/Je/test/cmake-build-debug --target test -- -j 6 [ 2%] Linking C executable test ld: warning: ignoring file /usr/local/Cellar/openssl@1.1/1.1.1k/lib/libcrypto.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64 ld: warning: ignoring file /usr/local/Cellar/openssl@1.1/1.1.1k/lib/libssl.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64 Undefined symbols for architecture arm64: "_ERR_print_errors_fp", referenced from: _http_tcpip_inbound_initialize in http_tcpip_inbound.c.o _http_tcpip_inbound_tls_initialize in http_tcpip_inbound.c.o _http_tcpip_outbound_get_url_using_string_type_tls in http_tcpip_outbound.c.o "_OPENSSL_init_crypto", referenced from: _http_tcpip_inbound_tls_initialize in http_tcpip_inbound.c.o "_OPENSSL_init_ssl", referenced from: _http_tcpip_inbound_tls_initialize in http_tcpip_inbound.c.o "_SSL_CIPHER_get_name", referenced from: _http_tcpip_inbound_initialize in http_tcpip_inbound.c.o "_SSL_CTX_free", referenced from: _http_tcpip_inbound_initialize in http_tcpip_inbound.c.o "_SSL_CTX_new", referenced from: _http_tcpip_inbound_tls_initialize in http_tcpip_inbound.c.o _http_tcpip_outbound_get_url_using_string_type_tls in http_tcpip_outbound.c.o "_SSL_CTX_use_PrivateKey_file", referenced from: _http_tcpip_inbound_tls_initialize in http_tcpip_inbound.c.o "_SSL_CTX_use_certificate_file", referenced from: _http_tcpip_inbound_tls_initialize in http_tcpip_inbound.c.o "_SSL_accept", referenced from: _http_tcpip_inbound_initialize in http_tcpip_inbound.c.o "_SSL_connect", referenced from: _http_tcpip_outbound_get_url_using_string_type_tls in http_tcpip_outbound.c.o "_SSL_ctrl", referenced from: _http_tcpip_outbound_get_url_using_string_type_tls in http_tcpip_outbound.c.o "_SSL_free", referenced from: _http_tcpip_inbound_initialize in http_tcpip_inbound.c.o "_SSL_get_current_cipher", referenced from: _http_tcpip_inbound_initialize in http_tcpip_inbound.c.o "_SSL_get_peer_certificate", referenced from: _http_tcpip_outbound_get_url_using_string_type_tls in http_tcpip_outbound.c.o "_SSL_new", referenced from: _http_tcpip_inbound_initialize in http_tcpip_inbound.c.o _http_tcpip_outbound_get_url_using_string_type_tls in http_tcpip_outbound.c.o "_SSL_read", referenced from: _http_tcpip_inbound_parse_request in http_tcpip_inbound.c.o _http_tcpip_outbound_get_url_using_string_type_tls in http_tcpip_outbound.c.o "_SSL_set_fd", referenced from: _http_tcpip_inbound_initialize in http_tcpip_inbound.c.o _http_tcpip_outbound_get_url_using_string_type_tls in http_tcpip_outbound.c.o "_SSL_shutdown", referenced from: _http_tcpip_inbound_initialize in http_tcpip_inbound.c.o "_SSL_write", referenced from: _http_tcpip_inbound_send_response in http_tcpip_inbound.c.o _http_tcpip_outbound_request_send_type_tls in http_tcpip_outbound.c.o "_TLS_client_method", referenced from: _http_tcpip_outbound_get_url_using_string_type_tls in
Re: Crash seen in "OPENSSL_sk_pop_free" API
Viktor,
Thank you for taking a look.
We are not invoking either of the API
X509_STORE_CTX_get0_chain/X509_STORE_CTX_get1_chain
We invoke X509_verify_cert() during the certification verification and this
fails (expectedly due to the missing CA certificate), so we invoke
X509_STORE_CTX_free to clean up the "X509_STORE_CTX" context and hit this crash
(this is not seen always)
X509_STORE_new()
X509_STORE_CTX_new()
X509_STORE_set_verify_cb_func
X509_STORE_set_default_paths
X509_STORE_load_locations
X509_STORE_CTX_init
X509_STORE_CTX_set_flags
X509_verify_cert > Fails with error
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY as CA certificate is not present.
/* Cleanup. */
X509_STORE_CTX_free(pContext); >Crash seen here in
sk_X509_pop_free
360 void OPENSSL_sk_pop_free(OPENSSL_STACK *st, OPENSSL_sk_freefunc func)
361 {
362 int i;
363
364 if (st == NULL)
365 return;
366 for (i = 0; i < st->num; i++)
367 if (st->data[i] != NULL)-> Crash seen here
368 func((char *)st->data[i]);
369 OPENSSL_sk_free(st);
370 }
Thanks
Bala
On Monday, 16 August, 2021, 11:40:24 pm IST, Viktor Dukhovni
wrote:
> On 16 Aug 2021, at 5:58 am, Bala Duvvuri via openssl-users
> wrote:
>
> We are using OpenSSl version 1.1.1d in our program and crash is being seen in
> "OPENSSL_sk_pop_free" API, we invoke this API in our certificate verification
> API. Since crash is not seen always, trying to understand from OpenSSL code,
> when can this occur?
>
> Below is the bt of the crash
>
> #0 0x0f31f438 in OPENSSL_sk_pop_free (st=0x1041de20, func=0xf34d5b0
> ) at crypto/stack/stack.c:367
> #1 0x0f344c74 in sk_X509_pop_free (freefunc=, sk= out>) at include/openssl/x509.h:99
> #2 X509_STORE_CTX_cleanup (ctx=ctx@entry=0x1041ba70) at
> crypto/x509/x509_vfy.c:2454
> #3 0x0f344cf4 in X509_STORE_CTX_free (ctx=ctx@entry=0x1041ba70) at
> crypto/x509/x509_vfy.c:2281
The call in question frees the certificate chain built by X509_verify_cert().
sk_X509_pop_free(ctx->chain, X509_free);
That chain is owned by the X509_STORE_CTX. You probably made the
mistake of freeing it (or one of the certificates in question) yourself.
There are two functions for accessing the built chain:
STACK_OF(X509) *X509_STORE_CTX_get0_chain(X509_STORE_CTX *ctx)
{
return ctx->chain;
}
STACK_OF(X509) *X509_STORE_CTX_get1_chain(X509_STORE_CTX *ctx)
{
if (!ctx->chain)
return NULL;
return X509_chain_up_ref(ctx->chain);
}
If you call X509_STORE_CTX_get0_chain(3), you MUST NOT free the result.
If you call X509_STORE_CTX_get1_chain(3), you own the chain copy, and
should free the result when you no longer need it.
--
Viktor.
problems with too many ssl_read and ssl_write errors
* We have a server that has around 2025 clients connected at any instant. * Our application creates a Server /Listener socket that then is converted into a Secure socket using OpenSSL library. This is compiled and built in a Windows x64 environment. We also built the OpenSSL for the Windows. The Listener socket is created with a default backlog of 500. The Accept socket is non-blocking socket and waits for connections * Every Client makes a regular blocking connection to the Server. The Server accepts the connection after which the Client socket is converted to a secure socket using the OpenSSL Library. * The connections are coming at a rate of about 10 connections /second ? Not sure about this number. * We are able to connect to all the clients in a few minutes and it stays like that for some time. There constant exchange of messages between Server(COS) and clients without issues. * The application logic is to keep trying to connect every timeout. * After maybe a few hours/days we see the clients dropping connections. The logs indicate the SSL_Read or SSL_Write on the Server fails for a client with SSL_Error number 5 (SSL_ERROR_SYSCALL) and the equivalent Windows error of WSATimeOut. We then observe the WSAECONNRESET as the Client closed connection. We see this behavior for multiple sites. * The number of Clients disconnected starts increasing and we see the logs in the Client where the server refuses any more connections form Clients (10061- WSAECONNREFUSED) There is nothing to indicate this state in the server logs. Our theory is the backlog is filled and Server refusing further connections. * We are trying to find why we get the SSL_Read/SSL_Write Error as it a Blocking socket. We cannot use to a non-blocking socket due to platform and application limitation
RE: [EXTERNAL] Re: IMPLEMENT_ASN1_FUNCTIONS tutorial or help
> My latest attempt to code the below DER is this. It compiles, but the d2i
> segfaults on apparently the second element.
>
> Anything obviously wrong?
>
> typedef struct {
> ASN1_INTEGER *version;
> ASN1_INTEGER *serialNumber;
> X509_ALGOR *signature;
> X509_PUBKEY *key;
> } TPM_ADDTOCERT;
>
> ASN1_SEQUENCE(TPM_ADDTOCERT) = {
> ASN1_EXP_OPT(TPM_ADDTOCERT, version, ASN1_INTEGER, 0),
> ASN1_EMBED(TPM_ADDTOCERT, serialNumber, ASN1_INTEGER),
> ASN1_EMBED(TPM_ADDTOCERT, signature, X509_ALGOR),
> ASN1_SIMPLE(TPM_ADDTOCERT, key, X509_PUBKEY), }
> ASN1_SEQUENCE_END(TPM_ADDTOCERT)
>
> DECLARE_ASN1_FUNCTIONS(TPM_ADDTOCERT)
> IMPLEMENT_ASN1_FUNCTIONS(TPM_ADDTOCERT)
>
> const unsigned char *tmpptr = out.addedToCertificate.t.buffer;
> TPM_ADDTOCERT *addToCert = d2i_TPM_ADDTOCERT(NULL,
> , out.addedToCertificate.t.size);
The dump you show below is:
Attributes (set, tagged with a 0, optional)
Version
privateKeyAlgorithm
privateKey
This is a PKCS#8 packet for a key. The encapsulated data is the RSA public key
in PKCS1 format. I know OpenSSL has built-in PKCS#8 capability, though I do
note that the optional attribute set is out of sequence.
Either way, you could look at the PKCS8 source code and simply move the
attribute to the beginning and otherwise duplicate the ASN1 parts and structure
there, even if OpenSSL fails to parse this not-quite-spec packet.
References:
https://datatracker.ietf.org/doc/html/rfc8017#page-54 (PKCS#1)
https://datatracker.ietf.org/doc/html/rfc5208#page-5 (PKCS#8)
>
> On 8/16/2021 4:56 PM, Ken Goldman wrote:
> >
> > The dump looks like this:
> >
> > 0 337: SEQUENCE {
> > 4 3: . [0] {
> > 6 1: . . INTEGER 2
> > : . . }
> > 9 21: . INTEGER 00 87 12 50 78 0A C9 8B 60 DD AC FA 75 18 05 EC DC
> > 30 51 53 23
> > 32 13: . SEQUENCE {
> > 34 9: . . OBJECT IDENTIFIER sha256WithRSAEncryption (1 2 840
> > 113549 1 1 11)
> > : . . . (PKCS #1)
> > 45 0: . . NULL
> > : . . }
> > 47 290: . SEQUENCE {
> > 51 13: . . SEQUENCE {
> > 53 9: . . . OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
> > : . . . . (PKCS #1)
> > 64 0: . . . NULL
> > : . . . }
> > 66 271: . . BIT STRING, encapsulates {
> > 71 266: . . . SEQUENCE {
> > 75 257: . . . . INTEGER
> > : . . . . . 00 B0 83 4A E9 41 78 E0 6A C3 0F D6 E4 B9 7D 96
> > : . . . . . 70 74 05 00 C9 E2 2C 6C 4C 6E 16 02 40 5C 35 29
> > : . . . . . F6 EF 9F 55 3A BD 4B 74 1D 6A 21 38 20 69 C8 88
> > : . . . . . A3 6B 56 62 2A 91 02 41 58 92 97 87 19 1C AD 19
> > : . . . . . 53 56 FB 7E 9D 86 B8 4E 8D 82 6A 87 A7 93 55 8F
> > : . . . . . AB E8 89 D7 63 0B C9 02 99 D8 37 F8 FB 6B 32 98
> > : . . . . . 6A 05 3F 9E 22 B6 D3 6F BB BE 2D AC 6C 74 17 5D
> > : . . . . . 15 EE 84 E5 A4 8F 9C C3 83 CD 83 81 63 EC B5 85
> > : . . . . . 6B 1A B8 57 80 2C ED E3 A7 F2 8C F7 3F 13 D9 27
> > : . . . . . 2E 64 37 49 E6 47 8E 0A 11 64 46 72 DD F9 EB 4F
> > : . . . . . B8 13 58 0B 47 F7 72 AB 29 D6 A5 05 44 30 E7 8D
> > : . . . . . FE 86 8A E8 5F 10 91 13 04 57 47 96 A7 97 28 3C
> > : . . . . . 39 BD 23 3F C6 41 5E 45 3F A5 41 F5 BF 7D C2 7C
> > : . . . . . CC F9 97 20 3F 20 82 AF 64 8C BC 0D 99 F4 BA 10
> > : . . . . . 53 58 C5 EC 86 DE 26 ED D9 D6 F2 60 49 C9 E7 9B
> > : . . . . . 6A 64 D2 BC C5 0E B0 1D EB 45 43 89 A6 4E 64 B4
> > : . . . . . A1
> > 336 3: . . . . INTEGER 65537
> > : . . . . }
> > : . . . }
> > : . . }
> > : . }
> >
> >
> >
>
RE: [EXTERNAL] Re: IMPLEMENT_ASN1_FUNCTIONS tutorial or help
> >> Now I would like to do the other end, where I have der and I want to > >> parse back to the structure, using d2i() > >> > >> 1 - Is there a tutorial on this? > > > > Seems like you don't need one. If you got i2d working you should have d2i > already! > > > > I wasn't clear. The input and output sides are different asn.1. > > For the input side, a poster give me the structure and I only need the i2d(). > That's done - amazing. > > This worked so well that I would like to use the same pattern for the output > side, > where I need d2i(). > > I posted the DER dump below, but I don't know how to map that to the > structures that the openssl macros can consume. If you want a generalized parser, you need the schema. Yes, you could make an ASN1 structure to parse THAT input, but if you want to parse all input of that type, you need to know about optional values, arbitrary repeats, etc. The schema would specify all of that.
stunnel 60 released
Dear Users, I have released version 5.60 of stunnel. ### Version 5.60, 2021.08.16, urgency: LOW * New features - New 'sessionResume' service-level option to allow or disallow session resumption - Added support for the new SSL_set_options() values. - Download fresh ca-certs.pem for each new release. * Bugfixes - Fixed 'redirect' with 'protocol'. This combination is not supported by 'smtp', 'pop3' and 'imap' protocols. - Enforced minimum WIN32 log window size. - Fixed support for password-protected private keys with OpenSSL 3.0 (thx to Dmitry Belyavskiy). Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: c45d765b1521861fea9b03b425b9dd7d48b3055128c0aec673bba5ef9b8f787d stunnel-5.60.tar.gz 190b79cb94a4f70f362e44c32d150edf8ae660734d3fa0cbd990c3821e8f3083 stunnel-5.60-win64-installer.exe bac9bb4503cc5091d78c9deb6aa013fc07e39d67db0dfcc073b098db52f54427 stunnel-5.60-android.zip Best regards, Mike OpenPGP_signature Description: OpenPGP digital signature
Crash seen in "OPENSSL_sk_pop_free" API
Hi All,
We are using OpenSSl version 1.1.1d in our program and crash is being seen in
"OPENSSL_sk_pop_free" API, we invoke this API in our certificate verification
API. Since crash is not seen always, trying to understand from OpenSSL code,
when can this occur?
Below is the bt of the crash
#0 0x0f31f438 in OPENSSL_sk_pop_free (st=0x1041de20, func=0xf34d5b0
) at crypto/stack/stack.c:367
i = 0
#1 0x0f344c74 in sk_X509_pop_free (freefunc=, sk=) at include/openssl/x509.h:99
No locals.
#2 X509_STORE_CTX_cleanup (ctx=ctx@entry=0x1041ba70) at
crypto/x509/x509_vfy.c:2454
No locals.
#3 0x0f344cf4 in X509_STORE_CTX_free (ctx=ctx@entry=0x1041ba70) at
crypto/x509/x509_vfy.c:2281
No locals
Below is the OpenSSL code
360 void OPENSSL_sk_pop_free(OPENSSL_STACK *st, OPENSSL_sk_freefunc func)
361 {
362int i;
363
364if (st == NULL)
365return;
366for (i = 0; i < st->num; i++)
367if (st->data[i] != NULL)-> Crash seen here
368func((char *)st->data[i]);
369OPENSSL_sk_free(st);
370 }
Can someone please help to understand under what conditions this can happen?
We use the below API's during certificate verification:
X509_STORE_new()
X509_STORE_CTX_new()
X509_STORE_set_verify_cb_func
X509_STORE_set_default_paths
X509_STORE_load_locations
X509_STORE_CTX_init
X509_STORE_CTX_set_flags
X509_verify_cert
/* Cleanup. */
FREE_X509_STORE_CTX(pContext);
Thanks
Bala
Crash seen in OPENSSL_sk_pop_free
Hi All,
We are using OpenSSl version 1.1.1d in our program and crash is being seen in
"OPENSSL_sk_pop_free" API, we invoke this API in our certificate verification
API. Since crash is not seen always, trying to understand from OpenSSL code,
when can this occur?
Below is the bt of the crash
#0 0x0f31f438 in OPENSSL_sk_pop_free (st=0x1041de20, func=0xf34d5b0
) at crypto/stack/stack.c:367
i = 0
#1 0x0f344c74 in sk_X509_pop_free (freefunc=, sk=) at include/openssl/x509.h:99
No locals.
#2 X509_STORE_CTX_cleanup (ctx=ctx@entry=0x1041ba70) at
crypto/x509/x509_vfy.c:2454
No locals.
#3 0x0f344cf4 in X509_STORE_CTX_free (ctx=ctx@entry=0x1041ba70) at
crypto/x509/x509_vfy.c:2281
No locals
Below is the OpenSSL API
360 void OPENSSL_sk_pop_free(OPENSSL_STACK *st, OPENSSL_sk_freefunc func)
361 {
362 int i;
363
364 if (st == NULL)
365 return;
366 for (i = 0; i < st->num; i++)
367 if (st->data[i] != NULL)-> Crash seen here
368 func((char *)st->data[i]);
369 OPENSSL_sk_free(st);
370 }
Can someone please help to understand under what conditions this can happen?
We use the below API's during certificate verification:
X509_STORE_new()
X509_STORE_CTX_new()
X509_STORE_set_verify_cb_func
X509_STORE_set_default_paths
X509_STORE_load_locations
X509_STORE_CTX_init
X509_STORE_CTX_set_flags
X509_verify_cert
/* Cleanup. */
FREE_X509_STORE_CTX(pContext);
Thanks
Bala
Re: OpenSSL beta testing on Solaris and z/OS
On 8/12/21 10:11, Matt Caswell wrote: > > > On 12/08/2021 01:35, Dennis Clarke via openssl-users wrote: >> On 8/5/21 00:55, Dr Paul Dale wrote: >>> Dennis, >>> >>> Thanks for the information. Solaris and z/OS are not tested by the >>> project, so it's good to know they aren't too far from working out of >>> the box. >>> >>> We would definitely be interested in a pull request with your fixes at >>> some stage -- post 3.0 since it's almost certainly too late now. >>> >> >> I thought we were still in "beta" testing mode here? > > Release of 3.0 "final" is imminent. OTC met on Tuesday 10th to decide > whether to release it today (Thursday 12th) or not. Ultimately they > decided not to, but will review again next Tuesday. > Ah, well, good stuff. I will see what I can do with some strange platforms and post my results as they appear. Possibly with the odd question or two. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: OpenSSL beta testing on Solaris and z/OS
On 8/5/21 00:55, Dr Paul Dale wrote: > Dennis, > > Thanks for the information. Solaris and z/OS are not tested by the > project, so it's good to know they aren't too far from working out of > the box. > > We would definitely be interested in a pull request with your fixes at > some stage -- post 3.0 since it's almost certainly too late now. > I thought we were still in "beta" testing mode here? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Deciphering a .p7f file
On 2021-08-11 13:52, Keine Eile wrote: Hi list members, I have a .p7f in hands, which seems to be a DER encoded PKCS7 structure in some way, I can use 'openssl pkcs' to transform it in a PEM form, I also can pull a bunch of certificates out of it. But I know, there is some encrypted pay load in this file, which I can not decipher. What I have tried with openssl's rsautl and smime does not seem to work for me. May be someone of you can push me in the right direction, thanks! Try the "openssl cms" command, or its older sibling "openssl smime" . 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
buffering/blocking in chained BIOs
Hello, I am trying to implement the following chain: SSL BIO <-> cipher BIO <-> socket BIO (wrapped around a TCP socket()) There are two aspects of this setup that I can't find enough documentation on: the buffering aspect and the blocking/non-blocking aspect. buffering: When feeding data to the cipher BIO, we have to call BIO_flush() on the final chunk to let it pad it and send it off, how does this behave when I have a cipher BIO appended to an SSL BIO in a chain? I would be writing to the SSL BIO using BIO_write(). I.E. this setup would make both application and non-application data from the SSL connection to be encrypted through the cipher BIO. How would I make sure then, that the cipher BIO doesn't buffer up some critical [handshake non-application data] or some sent application data? Do I just call BIO_flush() after every BIO_write() I do to the SSL BIO? If I do that, will the added padding interfere with the SSL protocol talking to each other, since it is adding padding data? I assume the cipher BIO on the other end will be stripping that padded data off, am I right? Since the cipher BIO processes data from and to the SSL BIO this makes it even more complicated due to implicit non-application data being written/read by the SSL BIO. What happens if the cipher BIO buffers a bit of application data (because it is too few) and thus the SSL BIO on the other side assumes some error so it sends a response which is big enough to get through the cipher BIO, the SSL BIO then responds to that which makes the old buffered data go through, messing up the handshaking or whatever completely. How do you advice I should handle this? For the socket BIO wrapped around the TCP socket(), what happens if the underlying TCP socket dies or has a low throughput? Does the socket BIO buffer data fed into it until it can feed it down to the TCP socket? How much data can it buffer until it fills up? Is there some error value I can examine? Should I just give this chain up completely and use BIOs individually and setup dynamic heap buffers between them to handle any buffering behaviour? blocking: How do I determine if BIO_write()/BIO_read() on the SSL BIO are blocking here? Will any BIO down the chain block at any point? Why / Why not? Much thanks in advance.
OpenSSL beta testing on Solaris and z/OS
>From another thread : > > The OpenSSL team has wondered how many people were trying out 3.0 > during the beta period without any way of knowing for sure. > If your curious about the old legacy Solaris 10 on reasonably new Fujitsu SPARC64 then I can tell you nearly everything "just works". A few tests fail and we may as well list them : Test Summary Report --- 03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 61-test_bio_prefix.t (Wstat: 512 Tests: 4 Failed: 2) Failed tests: 1, 3 Non-zero exit status: 2 90-test_ige.t(Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=239, Tests=2815, 7127 wallclock secs (18.23 usr 2.34 sys + 6784.88 cusr 151.77 csys = 6957.22 CPU) Result: FAIL A pile of tweaks were required to get to this point and mostly trivial items such as the perl scripts and the Configuration of course. I did go with a debug build and I adjusted the CFLAGS quite a bit. When I have some data from z/OS then I will bring that also. At this time I really do understand that no one within the OpenSSL dev team has access to such machines and operating systems. Saying that they are very strict is an understatement. However code that compiles on them and passes tests is generally very highly portable and will run anywhere. Embedded devices and tight memory constraints are a separate problem. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
enable/disable algorithms at build time
I want to reduce the size of EDK2 CryptoPkg by enabling, at build time, only the OpenSSL algorithms I want supported in my code. Is this possible via a configuration mechanism? I can't find anything in documentation. Does this violate the GPL license? Thanks.Lee
OpenSSL 3.x binaries naming convention (on Windows)
[This is a partial repost from another topic] I have a question, regarding Windows binaries. (We build our own for x86/amd64 using the documented procedure, the compilers installed are Visual Studio 2019, with latest updates). I take it (might be wrong, because the build scripts are complex to me) that the naming convention of binaries for OpenSSL 3 on Windows platform is like this: libcrypto-3.dll (and libssl-3.dll) for the 32 bits (release) builds libcrypto-3-x64.dll (and libssl-3-x64.dll) for the 64 bits (release) builds Is this naming convention intended to be stable over the 3.x life? Or would it change for things like libcrypto-3.1.dll (or the like) with releases like 3.1.x? __ Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Grüßen, Olivier Mascia
Re: OpenSSL Beta 2, report of successful migration
> The OpenSSL team has wondered how many people were trying out 3.0 during the > beta period without any way of knowing for sure. That you've had what seems > like a fairly smooth transition is wonderful. It obviously solely has to do with the huge amount of quality work people contributing to OpenSSL have put into 3.0 codebase. __ Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Grüßen, Olivier Mascia
Re: OpenSSL Beta 2, report of successful migration
> Know I have to do it, but only really use low level stuff to build Json > Web Keys, and the EC keys I build for signing seen incompatible with > some servers, so really needs deeper investigation. For JWS signing in relation to Letsencrypt (my use case for this - mKey is a RSA keypair in EVP_PKEY*): EVP_PKEY_CTX* ctx = EVP_PKEY_CTX_new(mKey, nullptr); EVP_PKEY_sign_init(ctx); EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING); EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()); EVP_PKEY_sign(ctx, nullptr, ... // to check the result length EVP_PKEY_sign(ctx, signature, ... // to sign and retrieve the signature EVP_PKEY_CTX_free(ctx); Looks good in our testings (I mean it works, as much as Letsencrypt does not bite and deliver our certificates). __ Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Grüßen, Olivier Mascia
Re: OpenSSL Beta 2, report of successful migration
> Likewise, I've updated our Windows code to use 3.0 easily, been running > one public web server for three weeks. > ... > Not looked at replacing low level RSA and EC APIs yet. We forced ourselves down that path because we had an internal policy to only build OpenSSL toolkit with 'no-deprecated' at Configure step and didn't want to relax that for 3.0 :) __ Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Grüßen, Olivier Mascia
OpenSSL Beta 2, report of successful migration
Hello, Just wanted to report that our private code update to move on from OpenSSL 1.1.1 to 3.0 Beta 2 is successful. It revolved around replacing some code still using RSA_ apis directly by proper EVP_PKEY_ apis, and some other minor details. Nothing too fancy after some effort understanding the new recipes. On the side of SSL communications, we have found *nothing* to update in our code, and though deep testing is still ongoing for some days, there are apparently no side-effects. Of course our use-case exercises only a very partial set of the whole toolkit. But as people generally only report problems, I thought like reporting success, for a change. I though have a question, regarding Windows binaries. (We build our own for x86/amd64 using the documented procedure, the compilers installed are Visual Studio 2019, with latest updates). I take it (might be wrong, because the build scripts are complex to me) that the naming convention of binaries for OpenSSL 3 on Windows platform is like this: libcrypto-3.dll (and libssl-3.dll) for the 32 bits (release) builds libcrypto-3-x64.dll (and libssl-3-x64.dll) for the 64 bits (release) builds Is this naming convention intended to be stable over the 3.x life? Or would it change for things like libcrypto-3.1.dll (or the like) with releases like 3.1.x? __ Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Grüßen, Olivier Mascia
Re: Accessing bignums of a RSA key with OpenSSL 3.0?
Thanks! BIGNUM* n; BIGNUM* e; BIGNUM* d; EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_N, ); EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_E, ); EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_D, ); Now, the reverse exercise for me: to create another RSA key, solely through EVP_PKEY interfaces (knowing these n, e, d parameters), I think I should go this route: mKey = EVP_PKEY_new(); EVP_PKEY_set_type(mKey, some int type ?); EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_N, n2); EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_E, e2); EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_D, d2); But how to get the proper int type to pass to EVP_PKEY_set_type()? Thanks all for support switching to OpenSSL 3.0. __ Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Grüßen, Olivier Mascia > Le 30 juil. 2021 à 15:07, Dr Paul Dale a écrit : > > Try: include/openssl/core_names.h > The names are "n", "e" and "d" in this case. > > > Pauli > > > On 30/7/21 10:57 pm, Olivier Mascia via openssl-users wrote: >> Dear all, >> >> Testing migration to OpenSSL 3.0. >> Got to update some code building a JWK (in relation to ACME LetsEncrypt >> protocols). >> >> Having an EVP_PKEY which happens to be a RSA key, I proceeded this way >> (1.1.1) to extract the bignums needed for inclusion into the JWK: >> >> // Access the numerical components of the certificate RSA keys. >> BIGNUM* n; >> BIGNUM* e; >> BIGNUM* d; >> RSA_get0_key(cert.RSAkey(), , , ); >> >> ( my cert.RSAkey() returned RSA* from my embedded EVP_PKEY* through >> EVP_PKEY_get0_RSA() ) >> >> I understand I should now start straight from the EVP_PKEY and use : >> >> EVP_PKEY_get_bn_param(cert.key(), "name-n?", ); >> EVP_PKEY_get_bn_param(cert.key(), "name-e?", ); >> EVP_PKEY_get_bn_param(cert.key(), "name-d?", ); >> >> ( cert.key() returns EVP_KEY* ) >> >> The question is: where can I find the proper names for these bignums out of >> a RSA key? >> >> __ >> Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit >> freundlichen Grüßen, >> Olivier Mascia >> >> >
Accessing bignums of a RSA key with OpenSSL 3.0?
Dear all, Testing migration to OpenSSL 3.0. Got to update some code building a JWK (in relation to ACME LetsEncrypt protocols). Having an EVP_PKEY which happens to be a RSA key, I proceeded this way (1.1.1) to extract the bignums needed for inclusion into the JWK: // Access the numerical components of the certificate RSA keys. BIGNUM* n; BIGNUM* e; BIGNUM* d; RSA_get0_key(cert.RSAkey(), , , ); ( my cert.RSAkey() returned RSA* from my embedded EVP_PKEY* through EVP_PKEY_get0_RSA() ) I understand I should now start straight from the EVP_PKEY and use : EVP_PKEY_get_bn_param(cert.key(), "name-n?", ); EVP_PKEY_get_bn_param(cert.key(), "name-e?", ); EVP_PKEY_get_bn_param(cert.key(), "name-d?", ); ( cert.key() returns EVP_KEY* ) The question is: where can I find the proper names for these bignums out of a RSA key? __ Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit freundlichen Grüßen, Olivier Mascia
Re: Wrong signature type error trying to connect to gibs.earthdata.nasa.gov on Ubuntu 20.04
Hi Tomáš and openssl users, finally the server at gibs.earthdata.nasa.gov was upgraded in order to support SHA256 (instead of SHA1) as peer signing digest algorithm. So, it is now possible to properly connect to it on Ubuntu 20.04 without the need of lower the default SECURITY LEVEL from 2 to 1. Regards. Andrea Giudiceandrea Il 14/08/2020 08:41, Tomas Mraz ha scritto: It is not a bug in OpenSSL and it is not a misconfiguration or non-compliance on the server side either. Basically to enhance security the default seclevel on Debian and Ubuntu was raised to 2 which doesn't allow SHA1 signatures which are weak. 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. However the SHA1 signatures are regarded as seriously weakened currently, so it would be certainly a very good idea to upgrade/fix the server to support SHA2 based signatures. Tomáš Mráz
OpenSSL 3.0.0 beta1 test results on Sun/Oracle Solaris SPARC64 ( Fujitsu )
After a pile of tweaks here and there as well as EVERY perl file needed to be slightly touched I was able to get a clean compile and a reasonable result ( for a beta1 ) from the testsuite : ( SRCTOP=. \ BLDTOP=. \ PERL="/opt/bw/bin/perl" \ FIPSKEY="f4556650ac31d35461610bac4ed81b1a181b2d8a43ea2854cbae22ca74560813" \ EXE_EXT= \ /opt/bw/bin/perl ./test/run_tests.pl ) 00-prep_fipsmodule_cnf.t .. skipped: FIPS module config file only supported in a fips build Files=1, Tests=0, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.89 cusr 0.04 csys = 0.97 CPU) Result: NOTESTS 01-test_abort.t ok 01-test_fipsmodule_cnf.t ... skipped: Test only supported in a fips build 01-test_sanity.t ... ok 01-test_symbol_presence.t .. ok 01-test_test.t . ok 02-test_errstr.t ... ok 02-test_internal_context.t . ok 02-test_internal_ctype.t ... ok 02-test_internal_keymgmt.t . ok 02-test_internal_provider.t ok 02-test_lhash.t ok 02-test_ordinals.t . ok 02-test_sparse_array.t . ok 02-test_stack.t ok 03-test_exdata.t ... ok 03-test_fipsinstall.t .. skipped: Test only supported in a fips build 03-test_internal_asn1.t ok 03-test_internal_asn1_dsa.t ok 03-test_internal_bn.t .. ok 03-test_internal_chacha.t .. ok 03-test_internal_curve448.t ok 03-test_internal_ec.t .. ok 03-test_internal_ffc.t . ok 03-test_internal_mdc2.t ok ../../util/wrap.pl ../../test/modes_internal_test => 138 not ok 1 - running modes_internal_test # -- # Failed test 'running modes_internal_test' # at /opt/bw/build/openssl-3.0.0-beta1_sunos5.10_sparcv9.002/util/perl/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1.03-test_internal_modes.t ... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests 03-test_internal_namemap.t . ok 03-test_internal_poly1305.t ok 03-test_internal_rsa_sp800_56b.t ... ok 03-test_internal_siphash.t . ok 03-test_internal_sm2.t . ok 03-test_internal_sm4.t . ok 03-test_internal_ssl_cert_table.t .. ok 03-test_internal_x509.t ok 03-test_params_api.t ... ok 03-test_property.t . ok 03-test_ui.t ... ok 04-test_asn1_decode.t .. ok 04-test_asn1_encode.t .. ok 04-test_asn1_string_table.t ok 04-test_bio_callback.t . ok 04-test_bio_core.t . ok 04-test_bioprint.t . ok 04-test_conf.t . ok 04-test_encoder_decoder.t .. ok 04-test_encoder_decoder_legacy.t ... ok 04-test_err.t .. ok 04-test_hexstring.t ok 04-test_param_build.t .. ok 04-test_params.t ... ok 04-test_params_conversion.t ok 04-test_pem_read_depr.t ok 04-test_pem_reading.t .. ok 04-test_provfetch.t ok 04-test_provider.t . ok 04-test_provider_fallback.t ok 04-test_upcalls.t .. ok 05-test_bf.t ... ok 05-test_cast.t . ok 05-test_cmac.t . ok 05-test_des.t .. ok 05-test_hmac.t . ok 05-test_idea.t . ok 05-test_pbe.t .. ok 05-test_rand.t . ok 05-test_rc2.t .. ok 05-test_rc4.t .. ok 05-test_rc5.t .. skipped: rc5 is not supported by this OpenSSL build 06-test_algorithmid.t .. ok 06-test_rdrand_sanity.t ok 10-test_bn.t ... ok 10-test_exp.t .. ok 15-test_dh.t ... ok 15-test_dsa.t .. ok 15-test_dsaparam.t . ok 15-test_ec.t ... ok 15-test_ecdsa.t ok 15-test_ecparam.t .. ok 15-test_gendh.t ok 15-test_gendhparam.t ... ok 15-test_gendsa.t ... ok 15-test_genec.t ok 15-test_genrsa.t ... ok 15-test_mp_rsa.t ... ok 15-test_out_option.t ... ok 15-test_rsa.t .. ok 15-test_rsaoaep.t .. ok 15-test_rsapss.t ... ok 15-test_sha.t .. ok 20-test_app.t .. ok 20-test_cli_fips.t . skipped: Test only supported in a fips build with security checks 20-test_dgst.t . ok 20-test_dhparam.t .. ok 20-test_dhparam_check.t ok 20-test_enc.t .
Re: OpenSSL 3.0.0 beta1 link issues on Solaris 10
On 7/25/21 20:16, Dr Paul Dale wrote: > None of the core developers have access to Solaris machines, thus we > rely on the community for reports and fixes for this kind of thing. Well access can be easily arranged. > We're happy to assist and can sometimes identify and fix the problem but > we still require help testing. Not a problem. I do understand. This is not exactly a common platform anymore but the things just keep on running. And running. > This would best be raised as an issue on GitHub > [https://github.com/openssl/openssl/issues/new?assignees==issue%3A+bug+report=bug_report.md]. > This way it is tracked and resource time can be allocated to it -- > although in this case I suspect it will be the community that cracks it > for us. > It will come back to me most likely. Fine. > Since you seem to have figured out a work around, including details of > what you needed to do would be very useful. Putting them up as a pull > request would be even better. I am working my way through the process now and also making changes as I go. Nothing too involved. For the most part this feels very much like the situation with 1.1.1k and all the previous flavours. Just a few tweaks needed. ALL of the perl scripts are mildly annoying but that is also easy to fix with some sed/grep/awk foo. I have the testsuite running now. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
OpenSSL 3.0.0 beta1 with a vast number of failures
After some work to clean out previous versions of OpenSSL 1.1.1x for some x I was able to get 3.0.0 beta1 to build. However it looks like some horrific perl problem in the test harness : # -- # Failed test 'Name constraints bad othername name constraint' # at test/recipes/25-test_verify.t line 375. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Global symbol "$use_system" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$exitcode" requires explicit package name at ../../util/wrap.pl line 20. syntax error at ../../util/wrap.pl line 56, near "perlport#exit # https://perldoc.perl.org/perlvms#$? if" ../../util/wrap.pl has too many errors. ../../util/wrap.pl ../../apps/openssl verify -auth_level 1 -auth_level 0 -trusted ../../test/certs/root-cert.pem -untrusted ../../test/certs/ca-cert.pem ../../test/certs/ee-pss-sha1-cert.pem => 255 not ok 135 - Accept PSS signature using SHA1 at auth level 0 # -- # Failed test 'Accept PSS signature using SHA1 at auth level 0' # at test/recipes/25-test_verify.t line 380. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Global symbol "$use_system" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$exitcode" requires explicit package name at ../../util/wrap.pl line 20. syntax error at ../../util/wrap.pl line 56, near "perlport#exit # https://perldoc.perl.org/perlvms#$? if" ../../util/wrap.pl has too many errors. ../../util/wrap.pl ../../apps/openssl verify -auth_level 1 -trusted ../../test/certs/root-cert.pem -untrusted ../../test/certs/ca-cert.pem ../../test/certs/ee-pss-sha256-cert.pem => 255 not ok 136 - CA with PSS signature using SHA256 # -- Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Possible unintended interpolation of @cmd in string at ../../util/wrap.pl line 20. Global symbol "$use_system" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "$waitcode" requires explicit package name at ../../util/wrap.pl line 20. Global symbol "@cmd" requires explicit package name at ../../util/
OpenSSL 3.0.0 beta1 link issues on Solaris 10
I am not sure what testing is happening with old Solaris 10 but I can tell you there are still servers out there running. I had no issues with the configuration stage but, as usual, I do need to make a few tweaks to Configurations/10-main.conf. Merely to get a consistent set of CFLAGS that I use for libraries that I may want to single step through. In any case the link stage fails with a truely massive list of undefined symbols and it seems as if the previous 1.1.1k libs are being found by the build process. So I wrote a manual link script and specified the build directory for the RUNPATH and the library search path however that resulted in a pile of undefined symbols. So then I went and deleted my previous 1.1.1k libs and the openssl binary and tried the manual link once again with success. Not sure if anyone else runs into this but I would hope that the previous libs would not be located *before* the new current 3.0.0 libs that are in the build directory. Regardless I may need to simply start over as the new libssl.so.3 seems to have a "NEEDED" libcrypto.so.1.1 and that can't be right. Here is the result of perl configdata.pm --dump : alpha$ /opt/bw/bin/perl configdata.pm --dump Command line (with current working directory = .): /opt/bw/bin/perl ./Configure solaris64-sparcv9-cc no-asm --prefix=/opt/bw shared no-hw no-engine -DPEDANTIC Perl information: /opt/bw/bin/perl 5.32.0 for sun4-solaris-64-ld Enabled features: aria async autoalginit autoerrinit autoload-config bf blake2 bulk cached-fetch camellia cast chacha cmac cmp cms comp ct deprecated des dgram dh dsa dso dtls ec ec2m ecdh ecdsa err filenames gost idea legacy md4 mdc2 module multiblock nextprotoneg ocb ocsp pic pinshared poly1305 posix-io psk rc2 rc4 rdrand rfc3779 rmd160 scrypt secure-memory seed shared siphash siv sm2 sm3 sm4 sock srp srtp sse2 ssl ssl-trace 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: acvp-tests [default]OPENSSL_NO_ACVP_TESTS afalgeng[cascade]OPENSSL_NO_AFALGENG asan[default]OPENSSL_NO_ASAN asm [option] OPENSSL_NO_ASM buildtest-c++ [default] capieng [cascade]OPENSSL_NO_CAPIENG crypto-mdebug [default]OPENSSL_NO_CRYPTO_MDEBUG devcryptoeng[default]OPENSSL_NO_DEVCRYPTOENG 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 engines, crypto/engine) external-tests [default]OPENSSL_NO_EXTERNAL_TESTS fips[default] fips-securitychecks [cascade]OPENSSL_NO_FIPS_SECURITYCHECKS fuzz-afl[default]OPENSSL_NO_FUZZ_AFL fuzz-libfuzzer [default]OPENSSL_NO_FUZZ_LIBFUZZER ktls[default]OPENSSL_NO_KTLS loadereng [cascade]OPENSSL_NO_LOADERENG makedepend [unavailable] md2 [default]OPENSSL_NO_MD2 (skip crypto/md2) msan[default]OPENSSL_NO_MSAN padlockeng [cascade]OPENSSL_NO_PADLOCKENG rc5 [default]OPENSSL_NO_RC5 (skip crypto/rc5) sctp[default]OPENSSL_NO_SCTP 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 => "qc", CC => "cc", CFLAGS => "-xO0 -g -xdepend", HASHBANGPERL => "/usr/bin/env perl", RANLIB => "ranlib", RC => "windres", asm_arch => "sparcv9", bn_ops => "BN_LLONG RC4_CHAR", build_file => "Makefile", build_scheme => [ "unified", "unix" ], cflags => "-m64 -xarch=sparc -g -xO0 -Xa -errfmt=error -erroff=%none -errshort=
Dynamic CRL not working when signed by intermediate CA
Hi, Dynamic CRL not working when signed by intermediate CA when ca-file (Trusted CA certs bundle) includes only the intermediate CA that signed the CRL. Causing to this the handshake is failing, is there a way to avoid in OpenSSL 1.0.2s-fips 28 May 2019? Br, Malli
Re: query on key usage OIDs
Question was how to retrieve those lists for any given certificate,
using currently supported OpenSSL APIs.
The lists of usage bits and extusage OIDs in any given certificate
are finite, even if the list of values that could be in other
certificates is infinite.
On 2021-07-16 06:44, Kyle Hamilton wrote:
Also, OIDs for extendedKeyUsage can be defined per-application, so
there's no way to compile a full list of them.
-Kyle H
On Fri, Jul 16, 2021 at 4:23 AM Viktor Dukhovni
wrote:
On 15 Jul 2021, at 11:55 pm, SIMON BABY wrote:
I am looking for openssl APIs to get all the OIDs associated with user
certificate Key usage extension. For example my sample Key usage extension from
the certificate is below:
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
I am looking for the APIs used to get the OIDs associated with Digital
Signature and Key Encipherment from the certificate.
There are no keyUsage OIDs, the field is a bitstring:
https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
KeyUsage ::= BIT STRING {
digitalSignature(0),
nonRepudiation (1), -- recent editions of X.509 have
-- renamed this bit to
contentCommitment
keyEncipherment (2),
dataEncipherment(3),
keyAgreement(4),
keyCertSign (5),
cRLSign (6),
encipherOnly(7),
decipherOnly(8) }
There are OIDs in the extendedKeyUsage:
https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12
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
Time for OpenSSL 1.1.1l?
The cadence of 1.1.1 release is supposed to be quarterly (I seem to recall reading that somewhere, but I can't find it)? It has been almost 4 months since 1.1.1k (25-March-2021) was released. Are there any plans for 1.1.1l (ell)? -- -Todd Short // tsh...@akamai.com // “One if by land, two if by sea, three if by the Internet." signature.asc Description: Message signed with OpenPGP
Re: email notice [was: Not getting some macros for FIPS]
On 2021-06-25 22:26, Richard Levitte wrote: On Wed, 23 Jun 2021 10:51:05 +0200, Tomas Mraz wrote: On Wed, 2021-06-23 at 08:12 +, Kumar Mishra, Sanjeev wrote: Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. It's a little bit strange to send e-mails with such notices to public mailing lists where the intented recipient is _anyone_. Those notices are a bit amusing, yeah. Of course, Sanjeev can't be blamed for this, as we can probably assume that it's a corporate filter that automagically adds those. And oh boy! openssl-users having almost 3000 subscribers, that's quite a lot of people to chase down and ensure they have destroyed all copies, I tell ya! "Good luck" is probably an appropriate response ;-) Which is why I have set up dedicated e-mail identities for posting to such public lists, using a different disclaimer in the sig-block. I hope this can inspire other sysadmins to set up something similar. 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 1.1.1k: missing d2i_X509 function prototype
On 01.07.2021 08:04, Viktor Dukhovni wrote: > On Thu, Jul 01, 2021 at 12:36:10AM +, Konstantin Boyandin via openssl-users wrote: > >> OpenSSL version: 1.1.1k. >> >> I noticed that >> >> X509 *d2i_X509(X509 **px, const unsigned char **in, long len); >> >> function is no longer defined in openssl/x509.h available in 1.0.x >> versions, the only one available is now > > Actually it is still declared, via: > > DECLARE_ASN1_FUNCTIONS(X509) But I can't find the function implementation anywhere in code! After I build .dll version of OpenSSL 1.1.1k, I get a fatal error when an application tries to call d2i_X509() - it's not present in the library. What are my options in such a situation? -- Sincerely, Konstantin Boyandin
openssl 1.1.1k: missing d2i_X509 function prototype
Hello, OpenSSL version: 1.1.1k. I noticed that X509 *d2i_X509(X509 **px, const unsigned char **in, long len); function is no longer defined in openssl/x509.h available in 1.0.x versions, the only one available is now X509 *d2i_X509_AUX(X509 **a, const unsigned char **pp, long length); Do I understand correctly that I should rewrite corresponding code of my application so that it would only use d2i_X509_AUX ? Note: d2i_X509() is still mentioned in https://www.openssl.org/docs/man1.1.1/man3/d2i_X509.html -- Sincerely, Konstantin Boyandin
Hi
Re: "Expecting: ANY PRIVATE KEY"
> On 28.06.2021, at 01:02, Michel wrote: > > Hi Mariano, > > My quick answer : your key file looks like an (old ?) custom *OpenSSH* format > that *OpenSSL* cannot read natively. > You should easily find an OpenSSH command or other free tools to converts > between formats. > > Hope it helps, > > Michel. > Hello Michel! Thank you for your prompt response. I will follow your advice. I did try some OpenSSH options before (ssh-keygen -i and such) but kept getting errors. Reason why I’m so insistent is because I got locked out from my VM for some odd reason, and all contingencies do not seem to work, so I guess I would try to gain access through cloud console, and also learn from this experience. I will dig more into the OpenSSH side of things. Thanks again! --Mariano > -Message d'origine- > De : openssl-users [mailto:openssl-users-boun...@openssl.org] De la part de > Mariano Gedisman-Córdoba via openssl-users > Envoyé : lundi 28 juin 2021 00:29 > À : openssl-users@openssl.org > Objet : "Expecting: ANY PRIVATE KEY" > > Hello everyone! > I have googled this error to no avail, but all answers don’t seem to adjust > to my particular case, or maybe I’m too novice at figuring it out. > > I have this key file: > > -BEGIN OPENSSH PRIVATE KEY—— > [key here] > -END OPENSSH PRIVATE KEY—— > > I’m trying to use this key in order to log in to my Google cloud instance > through browser console, and I get the following error: > "Error: Failed to read key. The key file must be ECDSA or RSA in PEM format. " > > I googled how to achieve this, and tried the following on my local machine: > $ openssl rsa -in id_rsa.txt -out id_rsa.pem -outform PEM > > Sadly, I run into this error: > unable to load Private Key > 56081:error:0906D06C:PEM routines:PEM_read_bio:no start > line:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.60.2/src/crypto/pem/pem_lib.c:648:Expecting: > ANY PRIVATE KEY > > As I said, Google did throw some clues, but nothing conclusive. > Note: I am running OS X El Cap. > > Can anyone point out what am I doing wrong? > > Thanks a lot in advance and I wish you a really good week! >
"Expecting: ANY PRIVATE KEY"
Hello everyone! I have googled this error to no avail, but all answers don’t seem to adjust to my particular case, or maybe I’m too novice at figuring it out. I have this key file: -BEGIN OPENSSH PRIVATE KEY—— [key here] -END OPENSSH PRIVATE KEY—— I’m trying to use this key in order to log in to my Google cloud instance through browser console, and I get the following error: "Error: Failed to read key. The key file must be ECDSA or RSA in PEM format. " I googled how to achieve this, and tried the following on my local machine: $ openssl rsa -in id_rsa.txt -out id_rsa.pem -outform PEM Sadly, I run into this error: unable to load Private Key 56081:error:0906D06C:PEM routines:PEM_read_bio:no start line:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.60.2/src/crypto/pem/pem_lib.c:648:Expecting: ANY PRIVATE KEY As I said, Google did throw some clues, but nothing conclusive. Note: I am running OS X El Cap. Can anyone point out what am I doing wrong? Thanks a lot in advance and I wish you a really good week!
Re: Can OpenSSL handle multiple authentication mechanisms on the same SSL context?
On Tue, Jun 22, 2021 at 04:18:25AM +, Revestual, Raffy [AUTOSOL/PSS/MNL] wrote: > Also asked this question in stackoverflow.com > > https://urldefense.com/v3/__https://stackoverflow.com/questions/68077419/can-openssl-handle-multiple-authentication-mechanisms-on-the-same-ssl-context__;!!GjvTz_vk!DeBGhsJS1c6OIusGcUpz3NpRsG2S3kReo2omn1ch1-B6mJ1ZvmGuj5awlkmShw$ > > > We are trying to support a server that would support PSK and SRP > authentication mechanisms. However, when we run to try to run callbacks for > both on the same context, only the PSK callbacks are being detected: > > SSL_CTX_set_psk_server_callback(m_ctx, psk_out_of_bound_serv_cb); > > SSL_CTX_set_srp_username_callback(m_ctx, srp_server_param_cb); > > SRP and PSK works currently in our code if you only set one callback or the > other. I tried to register SRP first but doing this didn't change the fact > the only PSK was working. So an alternative would be to set these > individually on the SSL context. I have also confirmed that SRP and PSK > cipher suites when combined when being set is a non-issue. > > Would multiple callbacks for different mechanisms work simultaneously on the > same SSL context? The situation is somewhat different between TLS 1.3 and prior versions (e.g., TLS 1.2). Since there isn't currently a defined SRP option for TLS 1.3, I assume you are targeting TLS 1.2 I think you need to say more about your testing -- whether SRP or PSK is being attempted for TLS 1.2 is at the control of the client, as the ClientKeyExchange protocol message will have a different structure for using SRP vs using PSK. If your client is never trying SRP, then of course your SRP callback will never be called. So, how are you testing the various scenarios? -Ben
Re: 3.0 beta1 feedback about (shared) library names
On Mon, Jun 21, 2021 at 10:23:06PM -0400, Michael Richardson wrote:
>
> I downloaded and compiled opensssl 3.0.0-beta1 from git today.
> I installed into a private prefix.
>
> While my debian desktop system has:
>
> %ls -l /usr/lib/x86_64-linux-gnu/libssl*
> -rw-r--r-- 1 root root 357056 Jul 8 2020
> /usr/lib/x86_64-linux-gnu/libssl3.so
> -rw-r--r-- 1 root root 1000534 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.a
> lrwxrwxrwx 1 root root 13 Feb 16 17:08
> /usr/lib/x86_64-linux-gnu/libssl.so -> libssl.so.1.1
> -rw-r--r-- 1 root root 435704 Jul 4 2017
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> -rw-r--r-- 1 root root 431232 Dec 23 2019
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
> -rw-r--r-- 1 root root 593696 Feb 16 17:08
> /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> %ls -l /usr/lib/x86_64-linux-gnu/libcrypto*
> -rw-r--r-- 1 root root 5399144 Feb 16 17:08
> /usr/lib/x86_64-linux-gnu/libcrypto.a
> lrwxrwxrwx 1 root root 16 Feb 16 17:08
> /usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.1.1
> -rw-r--r-- 1 root root 2494464 Jul 4 2017
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> -rw-r--r-- 1 root root 2504576 Dec 23 2019
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
> -rw-r--r-- 1 root root 3031904 Feb 16 17:08
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
>
> WTF is libssl3.so? I still don't know, but:
>
> %dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so
> libnss3:amd64: /usr/lib/x86_64-linux-gnu/libssl3.so
> something up there that should be concerning, because maybe it will cause
> confusion.
NSS is the mozilla TLS stack, used by firefox/etc.
> My newly installed openssl 3 has:
>
> %ls -l /sandel/3rd/openssl3/lib
> total 16188
> drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 engines-3/
> -rw-r--r-- 1 mcr mcr 9307420 Jun 21 21:29 libcrypto.a
> lrwxrwxrwx 1 mcr mcr 14 Jun 21 21:29 libcrypto.so -> libcrypto.so.3*
> -rwxr-xr-x 1 mcr mcr 5205856 Jun 21 21:29 libcrypto.so.3*
> -rw-r--r-- 1 mcr mcr 1251782 Jun 21 21:29 libssl.a
> lrwxrwxrwx 1 mcr mcr 11 Jun 21 21:29 libssl.so -> libssl.so.3*
> -rwxr-xr-x 1 mcr mcr 794496 Jun 21 21:29 libssl.so.3*
> drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 ossl-modules/
> drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 pkgconfig/
>
> So I see that the versioned .so file will be somewhat related to the version.
> Distros will be able to ship openssl1.x and openssl3.x shared libraries at
> the same time.
>
> But, having both "libssl-dev" and "libssl3-dev" installed at the same time is
> going to be a problem.
This is typically solved at the distro layer, not by "upstream" ... often by
just saying you only get to have one installed at a time, and making you swap
back and forth.
Other times the packages will create "-multidev" libraries that install into
a subdirectory, e.g., krb5-multidev installs into /usr/lib/{triple}/mit-krb5
and there's a libkrb5-dev that makes symlinks from the parent directory.
-Ben
> I think that the differences in ABI may be significant enough that you should
> consider calling it "libssl3" and "libcrypto3". Yeah, maybe that's uncool,
> but it may be pragmatic.
>
> {ps: I am working on the ruby openssl library next to see what happens}
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works|IoT architect [
> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails
> [
>
Re: reg: question about SSL server cert verification
On 2021-06-18 17:07, Viktor Dukhovni wrote: On Fri, Jun 18, 2021 at 03:09:47PM +0200, Jakob Bohm via openssl-users wrote: Now the client simply works backwards through that list, checking if each certificate signed the next one or claims to be signed by a certificate in /etc/certs. This lookup is done based on the complete distinguished name, not just the CN part of it. At every step, the certificate may be referenced by a "key identifier" instead of the distinguished name, and some clients will compare that instead of the distinguished name. All extant (non-EOL) OpenSSL releases prioritise the local trust-store over the remotely provided CA certificate list when building the certificate chain. The remote chain is used only when no match is found in the trust store. As as a matching issuer is found in the trust store all further lookups are from the trust store only. If the local trust store contains only "root CAs", and the remote peer provides the rest of the chain, with no overlap in the subject distinguished names, the behaviour is not observably different from Jakob's description. Differences are observed once the local trust store contains some intermediate certificates or the remote chain provides a cross cert for which the local store instead contains a corresponding (same subject name and keyid) self-signed root, or the cross cert is in the local store, but the remote peer sends a root. In all such cases chain construction uses the certs from the trust store. This tends to produce less surprising (and ideally better, or at least what you implicitly asked for) results. Interesting, earlier today, I observed the confusing effect of "openssl verify" treating -trusted_first as always on while keeping document wording suggesting it is an actual option, not historical remnants of yet another feature removed by the new OpenSSL management. -- Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 This message is only for its intended recipient, delete if misaddressed. WiseMo - Remote Service Management for PCs, Phones and Embedded 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: reg: question about SSL server cert verification
On 2021-06-18 16:23, Michael Wojcik wrote: From: openssl-users On Behalf Of Jakob Bohm via openssl-users Sent: Friday, 18 June, 2021 07:10 To: openssl-users@openssl.org Subject: Re: reg: question about SSL server cert verification On 2021-06-18 06:38, sami0l via openssl-users wrote: I'm curious how exactly an SSL client verifies an SSL server's certificate which is signed by a CA. No, here is what really happens: First the owner of the server (or a program they use) find the chain of intermediary certificates which leads from their actual certificate to a commonly trusted root certificate, Lets say the chain is: RootA->CrossB->IntermediaryC->IntermediaryD->EndCertServer. This list of certificates is put in a server config file and the complete list is sent in each SSL handshake and every CMS signed message. We hope. But, of course, as Jakob says, there are many misconfigured servers. Now the client simply works backwards through that list, checking if each certificate signed the next one or claims to be signed by a certificate in /etc/certs. This lookup is done based on the complete distinguished name, not just the CN part of it. At every step, the certificate may be referenced by a "key identifier" instead of the distinguished name, and some clients will compare that instead of the distinguished name. And there are a whole bunch of other checks: signature, validity dates, key usage, basic constraints... Those checks would presumably happen after chain building, verifying that signatures, dates, key usage and other constraints are correct. Also, the correspondence between the peer identity as requested by the client, and as represented by the entity certificate, should not be done using the CN component of the Subject DN (as OP suggested), but by comparing against the Subject Alternative Name extension values. The subject CN should only be used as a last resort; some applications may refuse to allow a CN match and insist on an X.509v3 certificate with a valid SAN. (Jakob knows all this.) Actually, I have heard of nothing at all proposing the use of SANs on CA certificates or their use in chain building. Hence why I refer only to matching the complete DN and/or matching the "key identifier" field. Certificate chain validation is a very complicated topic. I put together an internal presentation with an overview of it some years back and it was a dozen or more slides, and I only touched on the major points. It's not something that can be covered thoroughly in an email discussion. However it is something that should be documented in OpenSSL documents such as the "verify(1ssl)" manpage, but somehow isn't. For example, some versions of that manpage fail to specify which name restrictions are checked, which are ignored, and which ones fail even if they shouldn't. The big complications are: Numerous. Jakob's list is a good one, but I'm sure we can come up with others. Like, say, the enormous mess which is revocation. Revocation checks would also be part of the post-chain-building checks. My advice, for someone who wants to understand the certificate-validation process in TLS, is: [Snipped: List of academic texts for those who want to implement their own X.509 code] 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: reg: question about SSL server cert verification
On 2021-06-18 06:38, sami0l via openssl-users wrote: I'm curious how exactly an SSL client verifies an SSL server's certificate which is signed by a CA. So, during the SSL handshake, when the server sends its certificate, will the SSL client first checks the `Issuer`'s `CN` field from the x509 SSL certificate that it received for example, and compares against all the `CN`s of all the certificates stored `/etc/ssl/certs` of that client and if it matches any one of them, next it checks the signature of the received certificate by parsing the public key from that CA cert located in `/etc/ssl/certs/someCA.crt` and performers the decryption and checks the signature of the received certificate and if the signature matches, the browser accepts the certificate since it just verified that it's signed by the CA which is located in `/etc/ssl/certs` and uses that cert? Is this how the SSL client verifies the certificate when it receives a server's certificate during the handshake process? If not, It'd be really helpful if someone could explain me how it's exactly done. No, here is what really happens: First the owner of the server (or a program they use) find the chain of intermediary certificates which leads from their actual certificate to a commonly trusted root certificate, Lets say the chain is: RootA->CrossB->IntermediaryC->IntermediaryD->EndCertServer. This list of certificates is put in a server config file and the complete list is sent in each SSL handshake and every CMS signed message. Now the client simply works backwards through that list, checking if each certificate signed the next one or claims to be signed by a certificate in /etc/certs. This lookup is done based on the complete distinguished name, not just the CN part of it. At every step, the certificate may be referenced by a "key identifier" instead of the distinguished name, and some clients will compare that instead of the distinguished name. The big complications are: 1. The server owner may have configured the "wrong" list and clients may or may not work around that. 2. Not all clients trust the same exact list of root CAs, hence the invention of "cross-signed roots", which are intermediary certificates with the same name and public key as a not-known-everywhere root, but signed by an already-known-everywhere root. 3. Not all clients react the same way when the server includes a cross certificate in the list. Some recognize the cross as the same as a root they trust and declare success without having to trust the (possibly old) compatibility root, others check only the compatibility root and get confused when that old root dies. 4. Some quality checkers (looking at you QualSys) object strongly to the server including the root itself in its list, because the root is supposed to be on all the clients that trust it. But experienced human client users can actually use an included root to make informed decisions about trust errors. OpenSSL documentation tends to bury its handling of all this way too deep inside the programmer documentation rather than explaining things clearly in the end user documentation. 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
reg: question about SSL server cert verification
I'm curious how exactly an SSL client verifies an SSL server's certificate which is signed by a CA. So, during the SSL handshake, when the server sends its certificate, will the SSL client first checks the `Issuer`'s `CN` field from the x509 SSL certificate that it received for example, and compares against all the `CN`s of all the certificates stored `/etc/ssl/certs` of that client and if it matches any one of them, next it checks the signature of the received certificate by parsing the public key from that CA cert located in `/etc/ssl/certs/someCA.crt` and performers the decryption and checks the signature of the received certificate and if the signature matches, the browser accepts the certificate since it just verified that it's signed by the CA which is located in `/etc/ssl/certs` and uses that cert? Is this how the SSL client verifies the certificate when it receives a server's certificate during the handshake process? If not, It'd be really helpful if someone could explain me how it's exactly done. Thanks!
Re: openssl verify question
On 2021-06-17 15:49, Viktor Dukhovni wrote: On Sat, Jun 12, 2021 at 10:20:22PM +0200, Gaardiolor wrote: When I compare those, they are exactly the same. But that's the thing, I think server.sig.decrypted should be prepended with a sha256 designator 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20, which is missing. I do see this designator with working certificates. I suspect this is the problem. Is that designator mandatory and likely the cause of my issue ? Yes, PKCS#1 signatures must have an algorithm OID prefix. Please beware that a few years ago, I found that a particular Symantec server signedlong term messages (timestamping countersignatures) without that prefix, using animplied algorithm of SHA-1. It may thus be necessary for CMS implementations to accept such signatures for that special case until they naturally expire, and maybe a few years past that. Defining a sufficiently narrow exception is left as an exercise for implementors. 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: using the DSA signature algorithm of OpenSSL
Oops, forgot to sha1; now it works. Am 14.06.21 um 11:20 schrieb Elmar Stellnberger via openssl-users: I wanna use the DSA signature algorithms of OpenSSL to verify RRSIG and DNSKEY DNSSEC resource records. This is described in RFC2536 (a very short RFC). As far as I could try it out (see my attachement) there are two ways to sign and verify with OpenSSL/DSA: via the EVP interface and via the DSA interface directly. If I try to sign with one method and verify with the other that fails. What standards do these methods conform to, what is the difference between them and what do I need for my purpose? Also I have found two different ways to create a DSA key yielding apparently different results (see the sample code). Basically for me it is about verifying signatures, not about creating such signatures. <> (pub)key: 3081F13081A906072A8648CE38040130819D024100EECFDC5C3B730FE9D0A3D25C4B8EF27A7F93D7A8A0047065DB55D881A40CC11A620D65C5BD3A720D187300B25A59E051CCB203BBE13731FC7E65B6371D1CFDD9021500B6334A5665A680A9D017C760CFDEF2FD1FECF6A90241008D7623CF35A041F469B32EDA37ECF551485154047E11FE10DA003FEAB1DF88007860C1F0AE32990B29B52EE6DB6BAFDF1A7FF9FD76CFD5B417861ABE3782F4C3034300024019A7A450C6FE998742DF5D3E0F59C2E9D7D90D6861DA6E912AEB66BCA202FFBE981A381414213BB5504B582AC27A1ACFB8B203366A076BCCF179FC471C2E4CB7 asn1 repr of pubkey is the same signed message: (method #1, DSA interface) 302C02146F4A174CF347EF3FD2796D1858CADBD4A033DA1F02147DA2FB1329E82509C699806D92BB0713272C1651 signed message: 46 Bytes signature valid signed message: (method #2, EVP interface) 302C02142F5296C21FA0956049F124A58621084ADF680BB402140BDD997234B82C901999FA096EFB697D864086BD signed message: 46 Bytes authentic (verified with the same method) invalid signature (verified with the other first method)
using the DSA signature algorithm of OpenSSL
I wanna use the DSA signature algorithms of OpenSSL to verify RRSIG
and DNSKEY DNSSEC resource records. This is described in RFC2536 (a very
short RFC).
As far as I could try it out (see my attachement) there are two ways
to sign and verify with OpenSSL/DSA: via the EVP interface and via the
DSA interface directly. If I try to sign with one method and verify with
the other that fails. What standards do these methods conform to, what
is the difference between them and what do I need for my purpose? Also I
have found two different ways to create a DSA key yielding apparently
different results (see the sample code). Basically for me it is about
verifying signatures, not about creating such signatures.
<>
(pub)key:
3081F13081A906072A8648CE38040130819D024100EECFDC5C3B730FE9D0A3D25C4B8EF27A7F93D7A8A0047065DB55D881A40CC11A620D65C5BD3A720D187300B25A59E051CCB203BBE13731FC7E65B6371D1CFDD9021500B6334A5665A680A9D017C760CFDEF2FD1FECF6A90241008D7623CF35A041F469B32EDA37ECF551485154047E11FE10DA003FEAB1DF88007860C1F0AE32990B29B52EE6DB6BAFDF1A7FF9FD76CFD5B417861ABE3782F4C3034300024019A7A450C6FE998742DF5D3E0F59C2E9D7D90D6861DA6E912AEB66BCA202FFBE981A381414213BB5504B582AC27A1ACFB8B203366A076BCCF179FC471C2E4CB7
asn1 repr of pubkey is the same
signed message: (method #1, DSA interface)
302C02146F4A174CF347EF3FD2796D1858CADBD4A033DA1F02147DA2FB1329E82509C699806D92BB0713272C1651
signed message: 46 Bytes
signature valid
signed message: (method #2, EVP interface)
302C02142F5296C21FA0956049F124A58621084ADF680BB402140BDD997234B82C901999FA096EFB697D864086BD
signed message: 46 Bytes
authentic (verified with the same method)
invalid signature (verified with the other first method)
#include
#include
#include
#include
#include
#ifndef INCL
typedef unsigned char uchar;
typedef int bool;
#define true 1
#define false 0
enum PrnHexFlags { PRNHEX_NOSEP = 1 };
void prn_as_hex(FILE *out, const char *message, const uchar *digest, int len, int flags ) { int i;
bool prnsep; prnsep=!(flags_NOSEP);
fprintf(out,message); for( i=0; i 2*223
// assert false:
//res = EVP_PKEY_get_raw_public_key(privkey,NULL,); assert(res>0);
//pbkraw = (uchar*)malloc(pbklen);
//res = EVP_PKEY_get_raw_public_key(privkey,pbkraw,); assert(res>0);
//EVP_PKEY_print_private(stdout_bio,privkey,0,NULL); // print_public does not do anything else
//EVP_PKEY_assign_RSA(pkey, rsa); PKEY := DSA-key
//dsakey = EVP_PKEY_get0_DSA(privkey);
dsakey = DSA_new();
res = DSA_generate_parameters_ex(dsakey,71,NULL,0,NULL,NULL,NULL); assert(res>0);
res = DSA_generate_key(dsakey); assert(res>0);
privkey = EVP_PKEY_new();
EVP_PKEY_assign_DSA(privkey,dsakey);
len = i2d_DSA_PUBKEY(dsakey,NULL); keyptr = asn1key = alloca(len); len = i2d_DSA_PUBKEY(dsakey,);
len_ = i2d_PUBKEY(privkey,NULL); keyptr = asn1key_ = alloca(len_); len_ = i2d_PUBKEY(privkey,);
prn_as_hex(stdout,"(pub)key: ", asn1key, len, PRNHEX_NOSEP );
if(len==len_&&!memcmp(asn1key,asn1key_,len)) printf("asn1 repr of pubkey is the same\n");
//i2d_DSAPrivateKey
//DSA_sign_setup();
DSA_sign(0, (uchar*)msg, msglen, NULL, _msglen, dsakey );
signed_msg = (uchar*)malloc(sign_msglen);
DSA_sign(0, (uchar*)msg, msglen, signed_msg, _msglen, dsakey );
prn_as_hex(stdout,"signed message: ", signed_msg, sign_msglen, PRNHEX_NOSEP );
printf("signed message: %i Bytes\n", sign_msglen);
authstatus = DSA_verify(0, (uchar*)msg, msglen, signed_msg, sign_msglen, dsakey );
if(authstatus==1) printf("signature valid\n");
else if(authstatus==0) printf("invalid signature\n");
else printf("error at signature verification\n"); // -1
//pubkey_bn = DSA_get0_pub_key(dsakey);
//bnbuf = alloca(bnbuflen=BN_num_bytes(pubkey_bn));
//BN_bn2bin(pubkey_bn,bnbuf);
//prn_as_hex(stdout," pubkey2bin: ", bnbuf,bnbuflen,PRNHEX_NOSEP);
//printf(" pubkey2bin: %i Bytes\n",bnbuflen);
signctx = EVP_MD_CTX_create();
res = EVP_DigestSignInit( signctx, NULL, EVP_sha1(), NULL, privkey ); assert(res>0);
res = EVP_DigestSignUpdate( signctx, msg, msglen ); assert(res>0);
res = EVP_DigestSignFinal( signctx, NULL, _msglen_ ); assert(res>0);
signed_msg_ = (uchar*)malloc(sign_msglen_);
res = EVP_DigestSignFinal( signctx, signed_msg_, _msglen_ );
EVP_MD_CTX_free(signctx);
prn_as_hex(stdout,"signed message: ", signed_msg_, sign_msglen_, PRNHEX_NOSEP );
printf("signed message: %li Bytes\n", sign_msglen_);
pubkey = privkey;
verifyctx = EVP_MD_CTX_create();
res = EVP_DigestVerifyInit( verifyctx, NULL, EVP_sha1(), NULL, pubkey ); assert(res>0);
res = EVP_DigestVerifyUpdate( verifyctx, msg, msglen ); assert(res>0);
authstatus = EVP_DigestVerifyFinal( verifyctx, signed_msg_, sign_msglen_ );
if (authstatus==1) printf("authentic\n");
else if(authstatus==0) printf("n
