From janjust at nikhef.nl Wed Apr 1 07:45:45 2020 From: janjust at nikhef.nl (Jan Just Keijser) Date: Wed, 1 Apr 2020 09:45:45 +0200 Subject: Program works with older libssl, but not with newer In-Reply-To: <20200331174209.GA41308@straasha.imrryr.org> References: <24780758.vnQNS8qAr1@superstar> <20200331095800.GZ41308@straasha.imrryr.org> <32365563.SdEH99cIJO@superstar> <20200331174209.GA41308@straasha.imrryr.org> Message-ID: <53946e30-cf3d-1287-03c1-4378ed005372@nikhef.nl> Hi, On 31/03/20 19:42, Viktor Dukhovni wrote: > On Tue, Mar 31, 2020 at 04:51:32PM +0200, Christoph Pleger wrote: > >>>> I have here a self-written server program and the corresponding >>>> self-written client program. These run well together with libssl 1.1.0l, >>>> but with libssl 1.1.1d, the same programs give errors SSL_ERROR_SYSCALL >>>> in SSL_read(), no matter if I recompile the programs and then run them, >>>> or just replace libssl with the newer version. >>> OpenSSL 1.1.1 supports TLS 1.3, which OpenSSL 1.1.0 did not. >>> >>>> So, I want to ask if there are any known incompabilities in the libssl >>>> versions that require me to change the code of the programs, or if there >>>> is >>>> any known bug in libssl1.1.1d that may cause the mentioned errors. >>> Use of TLS 1.3 changes the communication patterns of the TLS protocol in >>> some non-trivial ways, and, if your application were fragile, it might >>> have gotten by with TLS 1.2, but the latent bugs could show up with TLS >>> 1.3. >> Now, I replaced TLS_server_method() and TLS_client_method() with >> TLSv1_2_server_method() and TLSv1_2_client_method() respectively, and the same >> error occurs. > Well, in that case, you need to provide more detail. Does the handshake > complete? If not, at what stage does it fail? > > A PCAP file may be needed. And you need to explain what operation > fails with SSL_ERROR_SYSCALL, and do an "strace" or equivalent to > understand what the relevant socket read calls returned. > on a related note: I am experiencing similar problems with my ppp EAP-TLS patch ; I now that EAP-TLS + TLSv1.3 is experimental but I do notice that the entire handshake seems to differ for TLSv1.3 versus TLSv1.2 ; as a workaround I am adding ? SSL_CTX_set_max_proto_version(ctx, TLS1_2_VERSION); to my code to avoid a TLSv1.3 handshake. I am not sure yet why and where it is failing, but it seems the client is not sending its certificate chain to the server.? I am positive it is a programming error on my side but I will say that this problem is particularly hard to track down. JM2CW, JJK / Jan Just Keijser From romain.geissler at amadeus.com Wed Apr 1 09:34:53 2020 From: romain.geissler at amadeus.com (Romain GEISSLER) Date: Wed, 1 Apr 2020 09:34:53 +0000 Subject: TLS 1.3 migration: SSL_set_cipher_list vs SSL_set_ciphersuites and "aliases" of families of cipher like TLSv1.3 Message-ID: Hi, We are using OpenSSL 1.1.1 for quite some time, and we have been able to migrate over time to the different version of SSL/TLS, up to TLS 1.2 with success. Now we wish to prepare the migration to TLS 1.3. The people used to configure our SSL connection tries to set the cipher list as they did before with TLS 1.2, with a value like: TLSv1.3:!aNULL:!eNULL However of course it failed. We saw that starting with TLS 1.3, we shall now try to use SSL_set_ciphersuites (and its variant with _CTX) rather than SSL_set_cipher_list, and the code has been done already for that. However I would like to know a few things and get your opinion on a proposal. Currently, setting the empty string is the same as setting the default value (which is returned from OSSL_default_ciphersuites(), and which is currently more or less hardcoded to "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"). I expect that actually this default might evolve over time if we find that a given cipher is actually weak and shall not be used anymore. I also expect that one day we will have some TLS 1.4, or 2.0, or any new revision. So - Do you think any use for supporting some kind of alias for families of cipher in SSL_set_ciphersuites, like for example "TLSv1.3" would be an alias for "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" right now, and the actual alias definition might evolve over time with new OpenSSL releases - Does SSL_set_ciphersuites support currently the notation "!CIPHER" to prevent a cipher from being used ? My whole goal is that from configuration point of view, it looks quite like our current TLS <= 1.2 configuration, and our operator would simply configure "TLSv1.3" so that they use 1.3 explicitly, and later we will tell them to use "TLSv1.4" the day that specification exists and is implemented. What do you think ? PS: my knowledge about OpenSSL and the actual difference between 1.2 and 1.3 which mandated this change of API (cipher_list vs ciphersuite) is very weak. So sorry if my question looks wrong. I just see that from a user point of view without knowing the details, its a bit different to configure now, and I wish it would be as easy as "TLSv1.3". Cheers, Romain From matt at openssl.org Wed Apr 1 11:14:42 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 1 Apr 2020 12:14:42 +0100 Subject: TLS 1.3 migration: SSL_set_cipher_list vs SSL_set_ciphersuites and "aliases" of families of cipher like TLSv1.3 In-Reply-To: References: Message-ID: On 01/04/2020 10:34, Romain GEISSLER via openssl-users wrote: > Hi, > > We are using OpenSSL 1.1.1 for quite some time, and we have been able to migrate over time to the different version of SSL/TLS, up to TLS 1.2 with success. > > Now we wish to prepare the migration to TLS 1.3. The people used to configure our SSL connection tries to set the cipher list as they did before with TLS 1.2, with a value like: TLSv1.3:!aNULL:!eNULL > > However of course it failed. We saw that starting with TLS 1.3, we shall now try to use SSL_set_ciphersuites (and its variant with _CTX) rather than SSL_set_cipher_list, and the code has been done already for that. However I would like to know a few things and get your opinion on a proposal. Currently, setting the empty string is the same as setting the default value (which is returned from OSSL_default_ciphersuites(), and which is currently more or less hardcoded to "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"). I expect that actually this default might evolve over time if we find that a given cipher is actually weak and shall not be used anymore. I also expect that one day we will have some TLS 1.4, or 2.0, or any new revision. So > - Do you think any use for supporting some kind of alias for families of cipher in SSL_set_ciphersuites, like for example "TLSv1.3" would be an alias for "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" right now, and the actual alias definition might evolve over time with new OpenSSL releases > - Does SSL_set_ciphersuites support currently the notation "!CIPHER" to prevent a cipher from being used ? At the moment there is a very limited set of ciphersuites that can be configured for TLSv1.3 (5 in total) compared to TLSv1.2 (142 in total) and below. This is partly because TLSv1.3 is new and we expect more ciphersuites to be defined, but also partly because a TLSv1.3 is so much simpler than a TLSv1.2 ciphersuite. A TLSv1.2 ciphersuite combines the symmetric cipher, with the key exchange algorithm, the authentication algorithm and the hash. In TLSv1.3 we just have the symmetric cipher and hash. Because there are so many combinations in TLSv1.2 this multiplies up to mean that many more ciphersuites are required. Right now the TLSv1.3 ciphersuite list is just a simple colon separated list of ciphersuite names. You can't do things like "!CIPHER". Given the very much reduced set of TLSv1.3 ciphersuites it is not yet clear whether a more expressive language to specify them is appropriate or necessary. Perhaps this might be needed in the future but right at the moment it looks like overkill. Matt > > My whole goal is that from configuration point of view, it looks quite like our current TLS <= 1.2 configuration, and our operator would simply configure "TLSv1.3" so that they use 1.3 explicitly, and later we will tell them to use "TLSv1.4" the day that specification exists and is implemented. > > What do you think ? > > PS: my knowledge about OpenSSL and the actual difference between 1.2 and 1.3 which mandated this change of API (cipher_list vs ciphersuite) is very weak. So sorry if my question looks wrong. I just see that from a user point of view without knowing the details, its a bit different to configure now, and I wish it would be as easy as "TLSv1.3". > > Cheers, > Romain > From rsalz at akamai.com Wed Apr 1 13:19:09 2020 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 1 Apr 2020 13:19:09 +0000 Subject: TLS 1.3 migration: SSL_set_cipher_list vs SSL_set_ciphersuites and "aliases" of families of cipher like TLSv1.3 In-Reply-To: References: Message-ID: > - Do you think any use for supporting some kind of alias for families of cipher in SSL_set_ciphersuites, like for example "TLSv1.3" Suppose someone finds out that chacha/poly is insecure and the IETF issues a new RFC that says "TLS 1.3 MUST NOT use" that cipher. Should the openssl alias change? It can be wordy, but explicitly listing ciphers and not using aliases (HIGH EXPORT etc) is really better. As for ease of use, just don't allow the ciphers to be configured. From romain.geissler at amadeus.com Wed Apr 1 13:32:53 2020 From: romain.geissler at amadeus.com (Romain GEISSLER) Date: Wed, 1 Apr 2020 13:32:53 +0000 Subject: TLS 1.3 migration: SSL_set_cipher_list vs SSL_set_ciphersuites and "aliases" of families of cipher like TLSv1.3 In-Reply-To: References: Message-ID: > Le 1 avr. 2020 ? 15:19, Salz, Rich a ?crit : > >> - Do you think any use for supporting some kind of alias for families of cipher in SSL_set_ciphersuites, like for example "TLSv1.3" > > Suppose someone finds out that chacha/poly is insecure and the IETF issues a new RFC that says "TLS 1.3 MUST NOT use" that cipher. Should the openssl alias change? > > It can be wordy, but explicitly listing ciphers and not using aliases (HIGH EXPORT etc) is really better. > > As for ease of use, just don't allow the ciphers to be configured. > Hi, Well, as a user of openssl, in the same scenario, I would draw the exact opposite conclusion ;) Let me elaborate. We as users don?t really know well how secure is a cipher, and we don?t really OpenSSL nor IETF discussions about these details. I am not saying they don?t matter, of course not, but as users, we are not expert of this, and we don?t follow it. However, what we do is follow regularly releases of OpenSSL: when a new stable release is out, we quickly migrate to it. As a user, I would see an added value to define aliases, because I definitely don?t want to hardcode in our config that we explicitly allow the usage of ciper X, Y or Z, as this config might "rot" over time and not follow state of the art config. However I do want to express the fact that I either allow any default ciphers (ie some kind of default config that would be based on OSSL_default_ciphersuites), or that I explicitly want to support the TLS 1.3-compliant ciphers but not the TLS 1.4 ones (if one day 1.4 is out, and for some reason, they can?t use the same set of default ciphers). This way we users express high level needs (ie famillies of ciphers), and you OpenSSL developer ensure the details of it, and make the alias content evolve over time if one day a cipher is found to be weak. So yes to answer your question, the openssl alias name should stay the same, but its actual meaning (ie ciper suite list) should evolve over time. This is one opinion, from user perspective. At least this is the vision we were used to with cipher lists for TLS <= 1.2, in which we definitely didn?t want to explicitly hardcode a list of ciphers about which we honestly have no idea of their cryptographic security, alias "TLSv1.2" was convenient. Cheers, Romain From ncsuandrew12 at gmail.com Wed Apr 1 16:34:53 2020 From: ncsuandrew12 at gmail.com (Andrew Felsher) Date: Wed, 1 Apr 2020 12:34:53 -0400 Subject: Using EVP_PKEY with EVP_EncryptInit_ex Message-ID: Hi, I'm trying to do what I assumed would be a very common and typical use of OpenSSL. I'm just encrypting and decrypting some data (in code; not from command line). EVP_EncryptInit_ex (and decrypt, update, and final variants) are the standard way to do this. However, the init functions take a char buffer. All the examples I can find use hard-coded char buffer keys. But obviously I'm not going to be hard-coding my keys. I'm generating them through a couple different means, but ultimately I have EVP_PKEYs (in my case, containing RSA private keys). And there doesn't seem to be a straightforward way to go from EVP_PKEYs to a form consumable by the EVP init functions. EVP_PKEY_get_raw_private_key looks like it would be perfect, but it was introduced in 1.1.1 and I'm limited to 1.1.0. This seems like it would be a very common use case, yet I can't seem to find any examples or documentation anywhere. Am I doing something wrong or making some really off-base assumptions? Thanks for any help, pointers, or guidance, Andrew F -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Wed Apr 1 16:42:45 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 1 Apr 2020 19:42:45 +0300 Subject: Using EVP_PKEY with EVP_EncryptInit_ex In-Reply-To: References: Message-ID: Dear Andrew, You should take a look at CMS implementation as a model. For example, you can generate a symmetric key for content encryption and algorithm-specific way to pass the symmetric key to the recipient using EVP_PKEY_encrypt. On Wed, Apr 1, 2020 at 7:35 PM Andrew Felsher wrote: > Hi, > > I'm trying to do what I assumed would be a very common and typical use of > OpenSSL. I'm just encrypting and decrypting some data (in code; not from > command line). EVP_EncryptInit_ex (and decrypt, update, and final variants) > are the standard way to do this. > > However, the init functions take a char buffer. All the examples I can > find use hard-coded char buffer keys. But obviously I'm not going to be > hard-coding my keys. I'm generating them through a couple different means, > but ultimately I have EVP_PKEYs (in my case, containing RSA private keys). > And there doesn't seem to be a straightforward way to go from EVP_PKEYs to > a form consumable by the EVP init functions. > > EVP_PKEY_get_raw_private_key looks like it would be perfect, but it was > introduced in 1.1.1 and I'm limited to 1.1.0. > > This seems like it would be a very common use case, yet I can't seem to > find any examples or documentation anywhere. > > Am I doing something wrong or making some really off-base assumptions? > > Thanks for any help, pointers, or guidance, > Andrew F > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Apr 1 16:53:03 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 1 Apr 2020 17:53:03 +0100 Subject: Using EVP_PKEY with EVP_EncryptInit_ex In-Reply-To: References: Message-ID: <59432822-2e14-733a-c6a3-dfa77fe2ea91@openssl.org> On 01/04/2020 17:34, Andrew Felsher wrote: > Hi, > > I'm trying to do what I assumed would be a very common and typical use > of?OpenSSL. I'm just encrypting and decrypting some data (in code; not > from command line). EVP_EncryptInit_ex (and decrypt, update, and final > variants) are the standard way to do this. > > However, the init functions take a char buffer. All the examples I can > find use hard-coded char buffer keys. But obviously I'm not going to be > hard-coding my keys. I'm generating them through a couple different > means, but ultimately I have EVP_PKEYs (in my case, containing?RSA > private keys). And there doesn't seem to be a straightforward way to go > from EVP_PKEYs to a form consumable by the EVP init functions. > > EVP_PKEY_get_raw_private_key looks like it would be perfect, but it was > introduced in 1.1.1 and I'm limited to 1.1.0. > > This seems like it would be a very common use case, yet I can't seem to > find any examples or documentation anywhere. > > Am I doing something wrong or making some really off-base assumptions? EVP_EncryptInit_ex does *symmetric* encryption, i.e. both sides of the communication share the same private key. An RSA key in an EVP_PKEY does *asymmetric* encryption. Typically anyone can encrypt using the public RSA key, but only the owner of the private RSA key can decrypt. Asymmetric encryption using RSA is limited because it can only encrypt a very small amount of data. It is also very slow compared to symmetric encryption. Therefore, typically, if you want to encrypt data via an RSA key you generate a random symmetric key and encrypt that using your RSA key. Then you encrypt the data using the randomly generated symmetric key. OpenSSL has a built in high level API for doing this combined operation. To encrypt you can use the EVP_Seal*() functions. To decrypt use the EVP_Open*() functions. See: https://www.openssl.org/docs/man1.1.1/man3/EVP_SealInit.html https://www.openssl.org/docs/man1.1.1/man3/EVP_OpenInit.html It is also possible to encrypt directly in RSA using EVP_PKEY_encrypt(): https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_encrypt.html Matt From ncsuandrew12 at gmail.com Wed Apr 1 17:01:22 2020 From: ncsuandrew12 at gmail.com (Andrew Felsher) Date: Wed, 1 Apr 2020 13:01:22 -0400 Subject: Using EVP_PKEY with EVP_EncryptInit_ex In-Reply-To: <59432822-2e14-733a-c6a3-dfa77fe2ea91@openssl.org> References: <59432822-2e14-733a-c6a3-dfa77fe2ea91@openssl.org> Message-ID: I'm aware of the symmetric/asymmetric differences. But the EVP_Enrypt... API takes the key as a bunch of bytes. It shouldn't care whether it's an RSA key or not, correct? (Though perhaps it would truncate to, in my case, the first 128 bits since I'm using AES-128-XTS.) But assuming that I can't somehow use the RSA private key's bits as my symmetric key, how should I generate a key without requiring user interaction? Simply calling RAND_bytes? -Andrew On Wed, Apr 1, 2020 at 12:53 PM Matt Caswell wrote: > > > On 01/04/2020 17:34, Andrew Felsher wrote: > > Hi, > > > > I'm trying to do what I assumed would be a very common and typical use > > of OpenSSL. I'm just encrypting and decrypting some data (in code; not > > from command line). EVP_EncryptInit_ex (and decrypt, update, and final > > variants) are the standard way to do this. > > > > However, the init functions take a char buffer. All the examples I can > > find use hard-coded char buffer keys. But obviously I'm not going to be > > hard-coding my keys. I'm generating them through a couple different > > means, but ultimately I have EVP_PKEYs (in my case, containing RSA > > private keys). And there doesn't seem to be a straightforward way to go > > from EVP_PKEYs to a form consumable by the EVP init functions. > > > > EVP_PKEY_get_raw_private_key looks like it would be perfect, but it was > > introduced in 1.1.1 and I'm limited to 1.1.0. > > > > This seems like it would be a very common use case, yet I can't seem to > > find any examples or documentation anywhere. > > > > Am I doing something wrong or making some really off-base assumptions? > > EVP_EncryptInit_ex does *symmetric* encryption, i.e. both sides of the > communication share the same private key. An RSA key in an EVP_PKEY does > *asymmetric* encryption. Typically anyone can encrypt using the public > RSA key, but only the owner of the private RSA key can decrypt. > > Asymmetric encryption using RSA is limited because it can only encrypt a > very small amount of data. It is also very slow compared to symmetric > encryption. Therefore, typically, if you want to encrypt data via an RSA > key you generate a random symmetric key and encrypt that using your RSA > key. Then you encrypt the data using the randomly generated symmetric key. > > OpenSSL has a built in high level API for doing this combined operation. > To encrypt you can use the EVP_Seal*() functions. To decrypt use the > EVP_Open*() functions. See: > > https://www.openssl.org/docs/man1.1.1/man3/EVP_SealInit.html > https://www.openssl.org/docs/man1.1.1/man3/EVP_OpenInit.html > > It is also possible to encrypt directly in RSA using EVP_PKEY_encrypt(): > > https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_encrypt.html > > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Apr 2 08:53:25 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 2 Apr 2020 09:53:25 +0100 Subject: Using EVP_PKEY with EVP_EncryptInit_ex In-Reply-To: References: <59432822-2e14-733a-c6a3-dfa77fe2ea91@openssl.org> Message-ID: On 01/04/2020 18:01, Andrew Felsher wrote: > I'm aware of the symmetric/asymmetric differences. But the EVP_Enrypt... > API takes the key as a bunch of bytes. It shouldn't care whether it's an > RSA key or not, correct? (Though perhaps it would truncate to, in my > case, the first 128 bits since I'm using AES-128-XTS.) No - you must not do that. On a side note XTS is a funny mode - it requires a double length key. So AES-128-XTS requires you to supply a 256 bit key. See the description of XTS on this page: https://www.openssl.org/docs/man1.1.1/man3/EVP_aes_128_xts.html On a 2nd side note - XTS has another quirk that you should be aware of. It does not support streaming. That is you should only call EVP_EncryptUpdate() once per EVP_EncryptInit_ex() call. The "IV" in the EVP_EncryptInit_ex() parameter list is actually the XTS "tweak". > > But assuming that I can't somehow use the RSA private key's?bits as my > symmetric key, how should I generate a key without requiring user > interaction? Simply calling RAND_bytes? Preferrably symmetric keys are generated via RAND_priv_bytes() - but RAND_bytes() would also work. It's not clear from your description though how you intend to use the RSA key in this case. Perhaps just to encrypt the symmetric key you generated above? Matt > > -Andrew > > On Wed, Apr 1, 2020 at 12:53 PM Matt Caswell > wrote: > > > > On 01/04/2020 17:34, Andrew Felsher wrote: > > Hi, > > > > I'm trying to do what I assumed would be a very common and typical use > > of?OpenSSL. I'm just encrypting and decrypting some data (in code; not > > from command line). EVP_EncryptInit_ex (and decrypt, update, and final > > variants) are the standard way to do this. > > > > However, the init functions take a char buffer. All the examples I can > > find use hard-coded char buffer keys. But obviously I'm not going > to be > > hard-coding my keys. I'm generating them through a couple different > > means, but ultimately I have EVP_PKEYs (in my case, containing?RSA > > private keys). And there doesn't seem to be a straightforward way > to go > > from EVP_PKEYs to a form consumable by the EVP init functions. > > > > EVP_PKEY_get_raw_private_key looks like it would be perfect, but > it was > > introduced in 1.1.1 and I'm limited to 1.1.0. > > > > This seems like it would be a very common use case, yet I can't > seem to > > find any examples or documentation anywhere. > > > > Am I doing something wrong or making some really off-base assumptions? > > EVP_EncryptInit_ex does *symmetric* encryption, i.e. both sides of the > communication share the same private key. An RSA key in an EVP_PKEY does > *asymmetric* encryption. Typically anyone can encrypt using the public > RSA key, but only the owner of the private RSA key can decrypt. > > Asymmetric encryption using RSA is limited because it can only encrypt a > very small amount of data. It is also very slow compared to symmetric > encryption. Therefore, typically, if you want to encrypt data via an RSA > key you generate a random symmetric key and encrypt that using your RSA > key. Then you encrypt the data using the randomly generated > symmetric key. > > OpenSSL has a built in high level API for doing this combined operation. > To encrypt you can use the EVP_Seal*() functions. To decrypt use the > EVP_Open*() functions. See: > > https://www.openssl.org/docs/man1.1.1/man3/EVP_SealInit.html > https://www.openssl.org/docs/man1.1.1/man3/EVP_OpenInit.html > > It is also possible to encrypt directly in RSA using EVP_PKEY_encrypt(): > > https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_encrypt.html > > > Matt > From michel.sales at free.fr Thu Apr 2 14:58:07 2020 From: michel.sales at free.fr (Michel) Date: Thu, 2 Apr 2020 16:58:07 +0200 Subject: Peer certificate verification in verify_callback In-Reply-To: <20200330211903.GU41308@straasha.imrryr.org> References: <20200330181723.GR41308@straasha.imrryr.org> <20200330211903.GU41308@straasha.imrryr.org> Message-ID: <000d01d608ff$1fa75130$5ef5f390$@sales@free.fr> Hi Viktor, Could you please elaborate on "...although doing the latter potentially gives you the opportunity to decorate them with auxiliary trust EKUs." Does it mean "EKUs" "out of" the certificate ? Is it just about using X509_STORE_set_trust() and the like as mentioned in X509_STORE_add_cert man page or something else ? Regards, Michel -----Message d'origine----- De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Viktor Dukhovni Envoy??: lundi 30 mars 2020 23:19 ??: openssl-users at openssl.org Objet?: Re: Peer certificate verification in verify_callback [...] > I set up an X509_STORE object and then cycle through all of the > certificate files in /etc/ssl/certs/, open them, and call > PEM_read_X509() to get an X509 (certificate) object and then call > X509_STORE_add_cert(x509_stor, certificate) to read the certificates > into my trusted store, X509_store object. It would be far simpler to concatenate them into a single CAfile, or use "c_rehash" to create the symlinks need to make the directory into a workable CApath. You should not have to manually load them into your own store, although doing the latter potentially gives you the opportunity to decorate them with auxiliary trust EKUs. > If the user of this CTX is acting as a client and the server presents > a certificate chain, and my trusted store has the root, the connection > will work, as the chain is verified and trusted. [...] -- Viktor. From ihaoht at 163.com Thu Apr 2 16:29:08 2020 From: ihaoht at 163.com (ihaoht) Date: Fri, 3 Apr 2020 00:29:08 +0800 (CST) Subject: how to generate the SHA512.s and SHA256.s on Linux? Message-ID: <597d2180.c7f4.1713bb98d07.Coremail.ihaoht@163.com> I need two fuctions: sha512_block_data_order and sha256_block_data_order. how can I get it. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.sales at free.fr Thu Apr 2 16:47:27 2020 From: michel.sales at free.fr (Michel) Date: Thu, 2 Apr 2020 18:47:27 +0200 Subject: TLS 1.3 migration: how to get current SSL session authentication In-Reply-To: References: Message-ID: <001101d6090e$655e9da0$301bd8e0$@sales@free.fr> Hi, By the way : It was possible to get the authentication from a TLS1.2 ciphersuite Using SSL_CIPHER_get_auth_nid(). With a TLS1.3 SSL_CIPHER, the result is logically 'any'. So my question is : Is there any other [new ?] API to get the effective authentication mode from the current SSL session (RSA, PSK, ...) ? Or do we need to rely on a [/PSK like] callback ? Regards, Michel. -----Message d'origine----- [...] A TLSv1.2 ciphersuite combines the symmetric cipher, with the key exchange algorithm, the authentication algorithm and the hash. In TLSv1.3 we just have the symmetric cipher and hash. [...] From balazs.horvath.email at gmail.com Fri Apr 3 13:31:35 2020 From: balazs.horvath.email at gmail.com (=?UTF-8?B?QmFsw6F6cyBIb3J2w6F0aA==?=) Date: Fri, 3 Apr 2020 15:31:35 +0200 Subject: New inlcudes needed for OpenSSL V1.1.1 sockets In-Reply-To: References: Message-ID: I made some investigations in our toolchain and code according to Your answers. I have found out, that the OpenSSL 1.0.2p was patched on some places in our system, e.g. the definitions for socket usage in e_os.h. I have also checked our toolchain, and compile results: I am sure, that we don't use the headers with 1.0.2p. Somehow our changes and configuration does not need the headers for th 1.0.2p. We work now on two ways to solve our problem. One is to leave the 1.1.1d unchanged, and try to make own headers from the Linux headers. The other is to take the patches from 1.0.2p, and try out if they work for the 1.1.1d Probably a mix of both will be the working solution. > > The programmer, who changed the code, probably had an idea about that. > Which programmer who changed which code? I have seen, that there are new source files in the new version, like s_socket.c, and that header files are greatly modified. I also found following in the release notes: Rewrite of BIO networking library. The BIO library lacked consistent support of IPv6, and adding it required some more extensive modifications. This introduces the BIO_ADDR and BIO_ADDRINFO types, which hold all types of addresses and chains of address information. It also introduces a new API, with functions like BIO_socket, BIO_connect, BIO_listen, BIO_lookup and a rewrite of BIO_accept. The source/sink BIOs BIO_s_connect, BIO_s_accept and BIO_s_datagram have been adapted accordingly. *Richard Levitte* Because of these, I had the assumption, that the sockets implementation was refactored, and needs now new headers. As You both wrote, I was wrong with the headers. Thanks for Your help! Best regards, Balazs Michael Wojcik ezt ?rta (id?pont: 2020. m?rc. 31., K, 15:26): > > From: openssl-users on behalf of > Bal?zs Horv?th > > Sent: Tuesday, March 31, 2020 04:56 > > > Our problem is, that the OpenSSL V1.1.1d needs includes, that are > nonexistent for MIPS in our > > development system. > > You mean "that don't exist for the OS we're running on MIPS". Headers > belong to the toolchain and OS, not to the processor family. If you were > targeting Linux on MIPS rather than some other OS (which you haven't named, > so if there's anyone on the list who has also used it, you haven't given > them enough information to help), you would have all of those headers. > > In short, your problem *has nothing to do with MIPS*. It has to do with > your target OS. > > > These headers were not needed for 1.0.2. > > Ah, but they were, as Pauli pointed out in another email. On POSIX and > POSIX-like platforms, OpenSSL has always used the sockets API, and those > are headers typically required for sockets on POSIX. There was some other > difference about how you were building 1.0.2. > > > My question is not a 100% OpenSSL question. But I think, as OpenSSL is > widely used on > > non-Linux/Windows/? systems, the question is legitime to ask, what to > use on special > > systems? > > The headers used to build OpenSSL on a given platform are whatever the > Configure process enables. If your target OS has a Configure target, then > that's what you have to configure OpenSSL's build process for, *before* > trying to build it. If your target OS does not have a target in the stock > OpenSSL Configure script, then you're targeting an unsupported platform, > and it's up to you to port OpenSSL to it; that includes figuring out what > headers are needed. > > > Or why are these headers needed now? > > You haven't configured the OpenSSL build for the correct target. > > > The programmer, who changed the code, probably had an idea about that. > > Which programmer who changed which code? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfulger at gmx.com Fri Apr 3 14:14:37 2020 From: dfulger at gmx.com (Dan Fulger) Date: Fri, 3 Apr 2020 16:14:37 +0200 Subject: An idiosyncratic port of OpenSSL 1.1.1f to OS/400 ILE Message-ID: The previously sent patch for 1.1.1e works for 1.1.1f as well. From tim.j.culhane at gmail.com Fri Apr 3 16:49:29 2020 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Fri, 3 Apr 2020 17:49:29 +0100 Subject: building openssl 1.1.1 for Solaris 10 Message-ID: <006101d609d7$d8686ff0$89394fd0$@gmail.com> Hi, Are there instructions somewhere for building and installing openssl 1.1.1 from source for Solaris 10? Many thanks, Tim From Michael.Wojcik at microfocus.com Fri Apr 3 17:31:24 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 3 Apr 2020 17:31:24 +0000 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: <006101d609d7$d8686ff0$89394fd0$@gmail.com> References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > tim.j.culhane at gmail.com > Sent: Friday, April 03, 2020 10:49 > > Are there instructions somewhere for building and installing openssl 1.1.1 > from source for Solaris 10? You mean beyond what's in INSTALL and NOTES.UNIX? What is your specific issue? -- Michael Wojcik Distinguished Engineer, Micro Focus From quanah at symas.com Fri Apr 3 18:05:41 2020 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 03 Apr 2020 11:05:41 -0700 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> Message-ID: --On Friday, April 3, 2020 6:31 PM +0000 Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of tim.j.culhane at gmail.com >> Sent: Friday, April 03, 2020 10:49 >> >> Are there instructions somewhere for building and installing openssl >> 1.1.1 from source for Solaris 10? > > You mean beyond what's in INSTALL and NOTES.UNIX? What is your specific > issue? They may have run into which the OpenSSL project seems disinclined to fix. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From Michael.Wojcik at microfocus.com Fri Apr 3 18:49:28 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 3 Apr 2020 18:49:28 +0000 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> Message-ID: > From: Quanah Gibson-Mount [mailto:quanah at symas.com] > Sent: Friday, April 03, 2020 12:06 > > --On Friday, April 3, 2020 6:31 PM +0000 Michael Wojcik > wrote: > > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > >> Of tim.j.culhane at gmail.com > >> Sent: Friday, April 03, 2020 10:49 > >> > >> Are there instructions somewhere for building and installing openssl > >> 1.1.1 from source for Solaris 10? > > > > You mean beyond what's in INSTALL and NOTES.UNIX? What is your specific > > issue? > > They may have run into > which the OpenSSL project seems disinclined to fix. Perhaps, but we have no way of knowing that. That's why specific questions are important. -- Michael Wojcik Distinguished Engineer, Micro Focus From tim.j.culhane at gmail.com Fri Apr 3 21:20:36 2020 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Fri, 3 Apr 2020 22:20:36 +0100 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> Message-ID: <006a01d609fd$b9441130$2bcc3390$@gmail.com> No, not run into that issue. Just wondering if there is a man page or similar on openssl.org which describes the steps. Tim -----Original Message----- From: openssl-users On Behalf Of Michael Wojcik Sent: Friday 3 April 2020 19:49 To: openssl-users at openssl.org Subject: RE: building openssl 1.1.1 for Solaris 10 > From: Quanah Gibson-Mount [mailto:quanah at symas.com] > Sent: Friday, April 03, 2020 12:06 > > --On Friday, April 3, 2020 6:31 PM +0000 Michael Wojcik > wrote: > > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > >> Behalf Of tim.j.culhane at gmail.com > >> Sent: Friday, April 03, 2020 10:49 > >> > >> Are there instructions somewhere for building and installing > >> openssl > >> 1.1.1 from source for Solaris 10? > > > > You mean beyond what's in INSTALL and NOTES.UNIX? What is your > > specific issue? > > They may have run into > > which the OpenSSL project seems disinclined to fix. Perhaps, but we have no way of knowing that. That's why specific questions are important. -- Michael Wojcik Distinguished Engineer, Micro Focus From Michael.Wojcik at microfocus.com Fri Apr 3 22:17:16 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 3 Apr 2020 22:17:16 +0000 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: <006a01d609fd$b9441130$2bcc3390$@gmail.com> References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> <006a01d609fd$b9441130$2bcc3390$@gmail.com> Message-ID: > From: tim.j.culhane at gmail.com [mailto:tim.j.culhane at gmail.com] > Sent: Friday, April 03, 2020 15:21 > > Just wondering if there is a man page or similar on openssl.org which > describes the steps. As I noted before, INSTALL and NOTES.TXT. Those are in the root of the OpenSSL source distribution. -- Michael Wojcik Distinguished Engineer, Micro Focus From tim.j.culhane at gmail.com Mon Apr 6 12:35:08 2020 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Mon, 6 Apr 2020 13:35:08 +0100 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> <006a01d609fd$b9441130$2bcc3390$@gmail.com> Message-ID: <005d01d60c0f$d0059d80$7010d880$@gmail.com> Hi, Ok, attempting to build openssl 1.1.1e now. As prompted by the config script I'm running Configure as follows: ./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.1.1 --openssldir=/opt/openssl/1.1.1 That completes successfully. However, when I then run gmake I see warnings like the below: cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs How can I configure the makefiles so they use '-m64'. I tried passing '-m64' as an argument to the Configure script but that didn't make any difference. Regards, Tim -----Original Message----- From: openssl-users On Behalf Of Michael Wojcik Sent: Friday 3 April 2020 23:17 To: openssl-users at openssl.org Subject: RE: building openssl 1.1.1 for Solaris 10 > From: tim.j.culhane at gmail.com [mailto:tim.j.culhane at gmail.com] > Sent: Friday, April 03, 2020 15:21 > > Just wondering if there is a man page or similar on openssl.org > which describes the steps. As I noted before, INSTALL and NOTES.TXT. Those are in the root of the OpenSSL source distribution. -- Michael Wojcik Distinguished Engineer, Micro Focus From Michael.Wojcik at microfocus.com Mon Apr 6 14:31:15 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 6 Apr 2020 14:31:15 +0000 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: <005d01d60c0f$d0059d80$7010d880$@gmail.com> References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> <006a01d609fd$b9441130$2bcc3390$@gmail.com> <005d01d60c0f$d0059d80$7010d880$@gmail.com> Message-ID: > From: tim.j.culhane at gmail.com [mailto:tim.j.culhane at gmail.com] > Sent: Monday, April 06, 2020 06:35 > To: Michael Wojcik; openssl-users at openssl.org > Subject: RE: building openssl 1.1.1 for Solaris 10 > > Ok, attempting to build openssl 1.1.1e now. > > As prompted by the config script I'm running Configure as follows: > > ./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.1.1 > --openssldir=/opt/openssl/1.1.1 > > That completes successfully. However, when I then run gmake I see warnings > like the below: > > > cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs > > How can I configure the makefiles so they use '-m64'. As far as I know you can't, except by editing Configurations/10-main.conf (one of the inputs to the Configure script). The -xarch=... flags are hard-coded there. Personally I wouldn't worry about it. -xarch is deprecated, but it still works. (And -m64 is not, as I understand it, exactly equivalent to -xarch anyway. I'm a bit suspicious of that warning from cc; I'd think you'd want -mcpu=... as well as -m64. But I haven't looked at the Sun C compiler options for some years.) What version of the C compiler are you using? Note these comments in 10-main.conf: # SC4.0 doesn't pass 'make test', upgrade to SC5.0 or SC4.2. # SC4.2 is ok, better than gcc even on bn as long as you tell it -xarch=v8 # SC5.0 note: Compiler common patch 107357-01 or later is required! Some people prefer to use gcc on Solaris for this reason. -- Michael Wojcik Distinguished Engineer, Micro Focus From tim.j.culhane at gmail.com Mon Apr 6 15:14:38 2020 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Mon, 6 Apr 2020 16:14:38 +0100 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> <006a01d609fd$b9441130$2bcc3390$@gmail.com> <005d01d60c0f$d0059d80$7010d880$@gmail.com> Message-ID: <006801d60c26$17d2cd70$47786850$@gmail.com> Hi, I'm using gcc 4.9.2 So, should I just ignore that warning and let the gmake continue? Tim -----Original Message----- From: openssl-users On Behalf Of Michael Wojcik Sent: Monday 6 April 2020 15:31 To: openssl-users at openssl.org Subject: RE: building openssl 1.1.1 for Solaris 10 > From: tim.j.culhane at gmail.com [mailto:tim.j.culhane at gmail.com] > Sent: Monday, April 06, 2020 06:35 > To: Michael Wojcik; openssl-users at openssl.org > Subject: RE: building openssl 1.1.1 for Solaris 10 > > Ok, attempting to build openssl 1.1.1e now. > > As prompted by the config script I'm running Configure as follows: > > ./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.1.1 > --openssldir=/opt/openssl/1.1.1 > > That completes successfully. However, when I then run gmake I see > warnings like the below: > > > cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit > programs > > How can I configure the makefiles so they use '-m64'. As far as I know you can't, except by editing Configurations/10-main.conf (one of the inputs to the Configure script). The -xarch=... flags are hard-coded there. Personally I wouldn't worry about it. -xarch is deprecated, but it still works. (And -m64 is not, as I understand it, exactly equivalent to -xarch anyway. I'm a bit suspicious of that warning from cc; I'd think you'd want -mcpu=... as well as -m64. But I haven't looked at the Sun C compiler options for some years.) What version of the C compiler are you using? Note these comments in 10-main.conf: # SC4.0 doesn't pass 'make test', upgrade to SC5.0 or SC4.2. # SC4.2 is ok, better than gcc even on bn as long as you tell it -xarch=v8 # SC5.0 note: Compiler common patch 107357-01 or later is required! Some people prefer to use gcc on Solaris for this reason. -- Michael Wojcik Distinguished Engineer, Micro Focus From Michael.Wojcik at microfocus.com Mon Apr 6 15:58:08 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 6 Apr 2020 15:58:08 +0000 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: <006801d60c26$17d2cd70$47786850$@gmail.com> References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> <006a01d609fd$b9441130$2bcc3390$@gmail.com> <005d01d60c0f$d0059d80$7010d880$@gmail.com> <006801d60c26$17d2cd70$47786850$@gmail.com> Message-ID: > From: tim.j.culhane at gmail.com [mailto:tim.j.culhane at gmail.com] > Sent: Monday, April 06, 2020 09:15 > > I'm using gcc 4.9.2 > > > So, should I just ignore that warning and let the gmake continue? Yes, that's what I would recommend. If it bugs you, you could always experiment with changing it, and if you find a version that works better you could submit a PR to the OpenSSL team; but everyone else seems to have decided to live with the warnings. -- Michael Wojcik Distinguished Engineer, Micro Focus From richard.simard at groupesti.com Mon Apr 6 17:43:39 2020 From: richard.simard at groupesti.com (Richard Simard) Date: Mon, 6 Apr 2020 17:43:39 +0000 Subject: Help with certificatePolicies section Message-ID: Hi! Anybody can help me whit this error? Error Loading extension section server_cert 140091048477824:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=email_in_dn 140091048477824:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=rand_serial 140091048477824:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:../crypto/asn1/a_object.c:73: 140091048477824:error:2208306E:X509 V3 routines:policy_section:invalid object identifier:../crypto/x509v3/v3_cpols.c:183:section:Cert_policy_server,name:policyIdentifier,value:GroupeSTIAssurance, GroupeSTIDevice 140091048477824:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:../crypto/x509v3/v3_conf.c:47:name=certificatePolicies, value=ia5org,1.3.6.1.4.1.51063, at Cert_policy_server [ openssl_init ] oid_section = oids_section [ server_cert ] basicConstraints = CA:FALSE nsCertType = server subjectKeyIdentifier = hash authorityKeyIdentifier = keyid, issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth certificatePolicies = ia5org, @Cert_policy_server crlDistributionPoints = crl_section [ Cert_policy_server ] policyIdentifier = GroupeSTIAssurance, GroupeSTIDevice CPS.1 = http://cps.groupesti.com [ crl_section ] fullname = URI:http://pki.groupesti.com/ca.crl CRLissuer = dirName:issuer_section reasons = keyCompromise, CACompromise authorityKeyIdentifier = keyid:always [ oids_section ] GroupeSTIAssurance = 1.3.6.1.4.1.51063.0.1 GroupeSTIUser = 1.3.6.1.4.1.51063.0.1.0 GroupeSTIDevice = 1.3.6.1.4.1.51063.0.1.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ossl at mts.cz Mon Apr 6 20:42:27 2020 From: ossl at mts.cz (Libor Chocholaty) Date: Mon, 06 Apr 2020 22:42:27 +0200 Subject: Help with certificatePolicies section In-Reply-To: References: Message-ID: Hi, could you share commands that led to this error? It looks to me referenced non existent section in config file like as param "-extensions" option. Regards, Libor On 2020-04-06 19:43, Richard Simard wrote: > Hi! > > Anybody can help me whit this error? > > Error Loading extension section server_cert > > 140091048477824:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=email_in_dn > > 140091048477824:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=rand_serial > > 140091048477824:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:../crypto/asn1/a_object.c:73: > > 140091048477824:error:2208306E:X509 V3 routines:policy_section:invalid object identifier:../crypto/x509v3/v3_cpols.c:183:section:Cert_policy_server,name:policyIdentifier,value:GroupeSTIAssurance, GroupeSTIDevice > > 140091048477824:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:../crypto/x509v3/v3_conf.c:47:name=certificatePolicies, value=ia5org,1.3.6.1.4.1.51063, at Cert_policy_server > > [ openssl_init ] > > oid_section = oids_section > > [ server_cert ] > > basicConstraints = CA:FALSE > > nsCertType = server > > subjectKeyIdentifier = hash > > authorityKeyIdentifier = keyid, issuer:always > > keyUsage = critical, digitalSignature, keyEncipherment > > extendedKeyUsage = serverAuth > > certificatePolicies = ia5org, @Cert_policy_server > > crlDistributionPoints = crl_section > > [ Cert_policy_server ] > > policyIdentifier = GroupeSTIAssurance, GroupeSTIDevice > > CPS.1 = http://cps.groupesti.com > > [ crl_section ] > > fullname = URI:http://pki.groupesti.com/ca.crl > > CRLissuer = dirName:issuer_section > > reasons = keyCompromise, CACompromise > > authorityKeyIdentifier = keyid:always > > [ oids_section ] > > GroupeSTIAssurance = 1.3.6.1.4.1.51063.0.1 > > GroupeSTIUser = 1.3.6.1.4.1.51063.0.1.0 > > GroupeSTIDevice = 1.3.6.1.4.1.51063.0.1.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at spatiallabs.com Tue Apr 7 02:16:23 2020 From: jason at spatiallabs.com (Jason Proctor) Date: Mon, 6 Apr 2020 19:16:23 -0700 Subject: OpenSSL vs SPKI Message-ID: Distinguished crypto community, I have the requirement to import RSA keypairs generated by the Amazon Key Management System into my environment. These keypairs arrive in the de facto standard of SPKI for the public component and PKCS8 for the private component. I have no problem with the PKCS8 encoded private keys, they seem fine when imported using d2i_PKCS8_PRIV_KEY_INFO_bio(). However, I'm having issues importing the SPKI encoded public keys. My Java test program imports them fine. The Js Web Crypto API is happy with them. Online ASN.1 parsers are fine with them. The OpenSSL command line tool can dump their contents, no problem. However, the d2i_NETSCAPE_SPKI() function errors out trying to deal with them. Back in the day I had a hack to import SPKI encoded public keys, as I knew their structure. I would just set the modulus and exponent directly using BN_bin2bn(). However these days it seems that the RSA structure is opaque, and so I can't do that either. (I mean fair enough, it's a hack.) Question -- is there a supported way of importing SPKI encoded public keys into the OpenSSL world? thanks so much for any help with this, Jason at Spatial EAY/OpenSSL user since 1995 From bill.c.roberts at gmail.com Tue Apr 7 04:44:27 2020 From: bill.c.roberts at gmail.com (William Roberts) Date: Mon, 6 Apr 2020 23:44:27 -0500 Subject: OpenSSL vs SPKI In-Reply-To: References: Message-ID: On Mon, Apr 6, 2020, 9:16 PM Jason Proctor wrote: > Distinguished crypto community, > > I have the requirement to import RSA keypairs generated by the Amazon > Key Management System into my environment. These keypairs arrive in > the de facto standard of SPKI for the public component and PKCS8 for > the private component. > > I have no problem with the PKCS8 encoded private keys, they seem fine > when imported using d2i_PKCS8_PRIV_KEY_INFO_bio(). > > However, I'm having issues importing the SPKI encoded public keys. My > Java test program imports them fine. The Js Web Crypto API is happy > with them. Online ASN.1 parsers are fine with them. The OpenSSL > command line tool can dump their contents, no problem. However, the > d2i_NETSCAPE_SPKI() function errors out trying to deal with them. > > Back in the day I had a hack to import SPKI encoded public keys, as I > knew their structure. I would just set the modulus and exponent > directly using BN_bin2bn(). However these days it seems that the RSA > structure is opaque, and so I can't do that either. (I mean fair > enough, it's a hack.) > There's setter functions now. See: https://www.openssl.org/docs/man1.1.0/man3/RSA_set0_key.html So I have no idea about the spki function, but if you have the rsa private key can't you get the public key from it? I would just look at what API the rsa command line tool is using. I would imagine there is a high level API for this. > > Question -- is there a supported way of importing SPKI encoded public > keys into the OpenSSL world? > > thanks so much for any help with this, > Jason at Spatial > EAY/OpenSSL user since 1995 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at spatiallabs.com Tue Apr 7 04:59:35 2020 From: jason at spatiallabs.com (Jason Proctor) Date: Mon, 6 Apr 2020 21:59:35 -0700 Subject: OpenSSL vs SPKI In-Reply-To: References: Message-ID: On Mon, Apr 6, 2020 at 9:44 PM William Roberts wrote: > > > There's setter functions now. See: > https://www.openssl.org/docs/man1.1.0/man3/RSA_set0_key.html Thanks, yes it does look like that replaces direct access to "n" and "e". It's a hack, but it might work for the moment. Ideally though I wouldn't be reliant on offsets into the binary SPKI structure :-) any help with SPKI welcome! J From bill.c.roberts at gmail.com Tue Apr 7 05:03:25 2020 From: bill.c.roberts at gmail.com (William Roberts) Date: Tue, 7 Apr 2020 00:03:25 -0500 Subject: OpenSSL vs SPKI In-Reply-To: References: Message-ID: On Mon, Apr 6, 2020, 11:59 PM Jason Proctor wrote: > On Mon, Apr 6, 2020 at 9:44 PM William Roberts > wrote: > > > > > > There's setter functions now. See: > > https://www.openssl.org/docs/man1.1.0/man3/RSA_set0_key.html > > Thanks, yes it does look like that replaces direct access to "n" and > "e". It's a hack, but it might work for the moment. > > Ideally though I wouldn't be reliant on offsets into the binary SPKI > structure :-) > I don't think I would consider it a hack necessarily. I work on the TPM stack and have to convert TPM structures to RSA public key structures for ooenssl to utilize, and we use this routine along the way. I would imagine theirs a higher level public from private routine you can call. I would dissect what: openssl rsa -in mykey.pem -pubout > mykey.pub Is doing > > any help with SPKI welcome! > J > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Apr 7 06:03:07 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 7 Apr 2020 02:03:07 -0400 Subject: OpenSSL vs SPKI In-Reply-To: References: Message-ID: <20200407060307.GC41308@straasha.imrryr.org> On Mon, Apr 06, 2020 at 07:16:23PM -0700, Jason Proctor wrote: > However, the d2i_NETSCAPE_SPKI() function errors out trying to deal > with them. That's not the droid you're looking for. > Question -- is there a supported way of importing SPKI encoded public > keys into the OpenSSL world? Yes. That'd be d2i_PUBKEY(3): https://www.openssl.org/docs/man1.1.1/man3/d2i_PUBKEY.html For example: https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L398-L404 -- Viktor. From tim.j.culhane at gmail.com Tue Apr 7 07:25:10 2020 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Tue, 7 Apr 2020 08:25:10 +0100 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> <006a01d609fd$b9441130$2bcc3390$@gmail.com> <005d01d60c0f$d0059d80$7010d880$@gmail.com> <006801d60c26$17d2cd70$47786850$@gmail.com> Message-ID: <001401d60cad$ace3bcd0$06ab3670$@gmail.com> Hi again, I ran the gmake and it fails with the below ld errors. Is this the known issue mentioned previously with building openssl on Sparc or is it caused by something else? Thanks, Tim ${LDCMD:-cc} -xarch=v9 -xstrconst -Xa -xO5 -xdepend -m64 -L. -mt \ -o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/pass wd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/ rsautl.o apps/s_client.o apps/s_server.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/storeutl.o apps/ts.o apps/veri fy.o apps/version.o apps/x509.o \ apps/libapps.a -lssl -lcrypto -lsocket -lnsl -ldl -lpthread cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBE2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBKDF2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol SCRYPT_PARAMS_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBEPARAM_it: relocation bound to a symbol with STV_PROTECTED visibility Undefined first referenced symbol in file clock_gettime ./libcrypto.so ld: fatal: symbol referencing errors. No output written to apps/openssl gmake[1]: *** [Makefile:2228: apps/openssl] Error 2 -----Original Message----- From: openssl-users On Behalf Of Michael Wojcik Sent: Monday 6 April 2020 16:58 To: openssl-users at openssl.org Subject: RE: building openssl 1.1.1 for Solaris 10 > From: tim.j.culhane at gmail.com [mailto:tim.j.culhane at gmail.com] > Sent: Monday, April 06, 2020 09:15 > > I'm using gcc 4.9.2 > > > So, should I just ignore that warning and let the gmake continue? Yes, that's what I would recommend. If it bugs you, you could always experiment with changing it, and if you find a version that works better you could submit a PR to the OpenSSL team; but everyone else seems to have decided to live with the warnings. -- Michael Wojcik Distinguished Engineer, Micro Focus From ca+ssl-users at esmtp.org Tue Apr 7 11:12:53 2020 From: ca+ssl-users at esmtp.org (Claus Assmann) Date: Tue, 7 Apr 2020 13:12:53 +0200 Subject: quote arguments in macros? Message-ID: <20200407111253.GA41489@kiel.esmtp.org> I just got a compiler warning while modifying some code: SSL_set_tlsext_host_name(ssl, sni) -> #define IS_EMPTY(s) (NULL == (s) || '\0' == *(s)) SSL_set_tlsext_host_name(ssl, !IS_EMPTY(sni) ? sni : other) warning: cast to 'char *' from smaller integer type 'int' 'SSL_set_tlsext_host_name' SSL_ctrl(s,SSL_CTRL_SET_TLSEXT_HOSTNAME,TLSEXT_NAMETYPE_host_name,(char *)name) ^^^^ Shouldn't the arguments in those macros be quoted, e.g., SSL_ctrl((s),SSL_CTRL_SET_TLSEXT_HOSTNAME,TLSEXT_NAMETYPE_host_name,(char *)(name)) ? From Michael.Wojcik at microfocus.com Tue Apr 7 13:48:19 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 7 Apr 2020 13:48:19 +0000 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: <001401d60cad$ace3bcd0$06ab3670$@gmail.com> References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> <006a01d609fd$b9441130$2bcc3390$@gmail.com> <005d01d60c0f$d0059d80$7010d880$@gmail.com> <006801d60c26$17d2cd70$47786850$@gmail.com> <001401d60cad$ace3bcd0$06ab3670$@gmail.com> Message-ID: > From: tim.j.culhane at gmail.com [mailto:tim.j.culhane at gmail.com] > Sent: Tuesday, April 07, 2020 01:25 > > I ran the gmake and it fails with the below ld errors. > > Is this the known issue mentioned previously with building openssl on Sparc > or is it caused by something else? > > ... > > Undefined first referenced > symbol in file > clock_gettime ./libcrypto.so It appears that's a known issue with building OpenSSL 1.1.1 on Solaris 10. (I think we haven't run into this in my team because we're now on Solaris 11, but I haven't investigated.) Quanah Gibson-Mount mentioned this in a reply to your first post in this thread: > They may have run into > which the OpenSSL project seems disinclined to fix. If you look at that issue, you'll see people have posted workarounds. I believe it's just a matter of linking with an additional library. -- Michael Wojcik Distinguished Engineer, Micro Focus From matt at openssl.org Tue Apr 7 14:14:38 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 7 Apr 2020 15:14:38 +0100 Subject: quote arguments in macros? In-Reply-To: <20200407111253.GA41489@kiel.esmtp.org> References: <20200407111253.GA41489@kiel.esmtp.org> Message-ID: Yes - they should. Fixup PR welcome. Matt On 07/04/2020 12:12, Claus Assmann wrote: > I just got a compiler warning while modifying some code: > > SSL_set_tlsext_host_name(ssl, sni) > -> > > #define IS_EMPTY(s) (NULL == (s) || '\0' == *(s)) > SSL_set_tlsext_host_name(ssl, !IS_EMPTY(sni) ? sni : other) > > warning: cast to 'char *' from smaller integer type 'int' > > 'SSL_set_tlsext_host_name' > SSL_ctrl(s,SSL_CTRL_SET_TLSEXT_HOSTNAME,TLSEXT_NAMETYPE_host_name,(char *)name) > ^^^^ > > Shouldn't the arguments in those macros be quoted, e.g., > SSL_ctrl((s),SSL_CTRL_SET_TLSEXT_HOSTNAME,TLSEXT_NAMETYPE_host_name,(char *)(name)) > ? > From Michael.Wojcik at microfocus.com Tue Apr 7 14:29:27 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 7 Apr 2020 14:29:27 +0000 Subject: quote arguments in macros? In-Reply-To: <20200407111253.GA41489@kiel.esmtp.org> References: <20200407111253.GA41489@kiel.esmtp.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Claus Assmann > Sent: Tuesday, April 07, 2020 05:13 > > I just got a compiler warning while modifying some code: > > SSL_set_tlsext_host_name(ssl, sni) > -> > > #define IS_EMPTY(s) (NULL == (s) || '\0' == *(s)) > SSL_set_tlsext_host_name(ssl, !IS_EMPTY(sni) ? sni : other) > > warning: cast to 'char *' from smaller integer type 'int' > > 'SSL_set_tlsext_host_name' > SSL_ctrl(s,SSL_CTRL_SET_TLSEXT_HOSTNAME,TLSEXT_NAMETYPE_host_name,(char > *)name) > > ^^^^ > > Shouldn't the arguments in those macros be quoted, e.g., > SSL_ctrl((s),SSL_CTRL_SET_TLSEXT_HOSTNAME,TLSEXT_NAMETYPE_host_name,(char > *)(name)) > ? That's parenthesized, not quoted. Arguably they should be; that's common C practice, for precisely this reason: macro expansion of arguments that are more-complex expressions than simple identifiers may cause issues due to precedence and association. In this particular case, I don't think that cast should be there at all in the macro definition. What if the actual argument for name is not compatible with char*? In that case the macro hides an error. And since the final formal parameter to SSL_ctrl is actually void*, that cast isn't doing anything useful. Also, ideally, the final formal parameter would be const char*, but that would require a new API because SSL_ctrl overloads the semantics of its final parameter for both set and get operations. (This is an unfortunate old UNIX convention - see e.g. fcntl and ioctl - which predates the introduction of the const type-qualifier to the C language and const-correctness.) But in either case, the fact is that some of the macro definitions that use SSL_ctrl parenthesize their formal parameters, and some don't. (Typically the ones in ssl.h do, for example, and those in tls1.h don't.) And some have infelicitous casts applied to those parameters, while others don't. (And some are violations of the C standard; for example, it's not guaranteed that function pointers have a representation that's compatible with void*, as e.g. SSL_set_tlsext_debug_callback assumes.) If someone wants that changed, they'd probably have to open an issue, create a patch, submit a PR, and then be prepared to defend the change. My guess is that this would not be high on the OpenSSL team's priority list. In the meantime, an easy workaround is to parenthesize it yourself in the macro invoocation. Or avoid using complex expressions as actual parameters to the function calls. -- Michael Wojcik Distinguished Engineer, Micro Focus From richard.simard at groupesti.com Tue Apr 7 15:57:23 2020 From: richard.simard at groupesti.com (Richard Simard) Date: Tue, 7 Apr 2020 15:57:23 +0000 Subject: Help with certificatePolicies section In-Reply-To: References: Message-ID: Libor Chocholaty openssl ca -config etc/intermediate.cnf -extensions server_cert -days 1825 -notext -md sha256 -in intermediate/csr/test.groupesti.com.csr -out intermediate/certs/test.groupesti.com.crt Using configuration from etc/intermediate.cnf Enter pass phrase for /CA/intermediate/private/intermediate.key: ************ Error Loading extension section server_cert 140542588306560:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=email_in_dn 140542588306560:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=rand_serial 140542588306560:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:../crypto/asn1/a_object.c:73: 140542588306560:error:2208306E:X509 V3 routines:policy_section:invalid object identifier:../crypto/x509v3/v3_cpols.c:183:section:Cert_policy_server,name:policyIdentifier,value:GroupeSTIAssurance, GroupeSTIDevice 140542588306560:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:../crypto/x509v3/v3_conf.c:47:name=certificatePolicies, value=ia5org, @Cert_policy_server Intermediate.cnf [ openssl_init ] oid_section = oids_section [ ca ] default_ca = CA_default [ CA_default ] dir = /CA/intermediate certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand private_key = $dir/private/intermediate.key certificate = $dir/certs/intermediate.crt crlnumber = $dir/crlnumber crl = $dir/crl/intermediate.crl crl_extensions = crl_ext default_crl_days = 30 default_md = sha256 name_opt = ca_default cert_opt = ca_default default_days = 375 preserve = no policy = policy_loose [ policy_strict ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy_loose ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] default_bits = 2048 distinguished_name = req_distinguished_name utf8 = yes string_mask = utf8only name_opt = multiline, -esc_msb, utf8 default_md = sha256 x509_extensions = v3_ca [ req_distinguished_name ] countryName = "1. Nom du pays (2 lettres) (Ex, CA) " countryName_max = 2 countryName_default = CA stateOrProvinceName = "2. Nom de l'?tat ou de la province (Ex, Qu?bec) " stateOrProvinceName_default = Qu?bec localityName = "3. Nom de localit? (Ex, Saguenay) " localityName_default = Saguenay organizationName = "4. Nom de l'organisation (Ex, Groupe Solutions TI) " organizationName_default = Groupe Solutions TI Inc. organizationalUnitName = "5. Nom de l'unit? organisationnelle (Ex, Service web) " organizationalUnitName_default = commonName = "6. Nom de la personne (Ex, Jean Tremblay) " commonName_max = 64 commonName_default = emailAddress = "7. Adresse courriel (Ex, vous at domain.com " emailAddress_max = 64 emailAddress_default = [ issuer_section ] O = Groupe Solutions TI Inc. CN = Groupe Solutions TI Inc. - Autorit? TLS V3 Principal C = CA ST = Qu?bec L = Saguenay streetAddress = 3-4109, Saint-Alexandre postalCode = G8A 2H1 emailAddress = support at groupesti.com telephoneNumber = +1 (418) 695-9007 [ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ v3_intermediate_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ usr_cert ] basicConstraints = CA:FALSE nsCertType = client, email subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, emailProtection SMIME-CAPS = ASN1:SEQUENCE:smime_seq crlDistributionPoints = crl_section [ Policy_usr_cert ] policyIdentifier = GroupeSTIAssurance, GroupeSTIUser CPS = http://cps.groupesti.com [ server_cert ] basicConstraints = CA:FALSE nsCertType = server subjectKeyIdentifier = hash authorityKeyIdentifier = keyid, issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth certificatePolicies = ia5org, @Cert_policy_server crlDistributionPoints = crl_section [ Cert_policy_server ] policyIdentifier = GroupeSTIAssurance, GroupeSTIDevice CPS.1 = http://cps.groupesti.com [ crl_ext ] authorityKeyIdentifier = keyid:always [ crl_section ] fullname = URI:http://pki.groupesti.com/ca.crl CRLissuer = dirName:issuer_section reasons = keyCompromise, CACompromise authorityKeyIdentifier = keyid:always [ ocsp ] basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid, issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning [ smime_seq ] SMIMECapability.0 = SEQWRAP, OID:sha1 SMIMECapability.1 = SEQWRAP, OID:sha256 SMIMECapability.2 = SEQWRAP, OID:sha1WithRSA SMIMECapability.3 = SEQWRAP, OID:aes-256-ecb SMIMECapability.4 = SEQWRAP, OID:aes-256-cbc SMIMECapability.5 = SEQWRAP, OID:aes-256-ofb SMIMECapability.6 = SEQWRAP, OID:aes-128-ecb SMIMECapability.7 = SEQWRAP, OID:aes-128-cbc SMIMECapability.8 = SEQWRAP, OID:aes-128-ecb SMIMECapability.9 = SEQUENCE:rsa_enc [ oids_section ] GroupeSTIAssurance = 1.3.6.1.4.1.51063.0.1 GroupeSTIUser = 1.3.6.1.4.1.51063.0.1.0 GroupeSTIDevice = 1.3.6.1.4.1.51063.0.1.1 GroupeSTIAssuranceEV = 1.3.6.1.4.1.51063.0.1.2 De : openssl-users De la part de Libor Chocholaty Envoy? : 6 avril 2020 16:42 ? : openssl-users at openssl.org Objet : Re: Help with certificatePolicies section Hi, could you share commands that led to this error? It looks to me referenced non existent section in config file like as param "-extensions" option. Regards, Libor On 2020-04-06 19:43, Richard Simard wrote: Hi! Anybody can help me whit this error? Error Loading extension section server_cert 140091048477824:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=email_in_dn 140091048477824:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=rand_serial 140091048477824:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:../crypto/asn1/a_object.c:73: 140091048477824:error:2208306E:X509 V3 routines:policy_section:invalid object identifier:../crypto/x509v3/v3_cpols.c:183:section:Cert_policy_server,name:policyIdentifier,value:GroupeSTIAssurance, GroupeSTIDevice 140091048477824:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:../crypto/x509v3/v3_conf.c:47:name=certificatePolicies, value=ia5org,1.3.6.1.4.1.51063, at Cert_policy_server [ openssl_init ] oid_section = oids_section [ server_cert ] basicConstraints = CA:FALSE nsCertType = server subjectKeyIdentifier = hash authorityKeyIdentifier = keyid, issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth certificatePolicies = ia5org, @Cert_policy_server crlDistributionPoints = crl_section [ Cert_policy_server ] policyIdentifier = GroupeSTIAssurance, GroupeSTIDevice CPS.1 = http://cps.groupesti.com [ crl_section ] fullname = URI:http://pki.groupesti.com/ca.crl CRLissuer = dirName:issuer_section reasons = keyCompromise, CACompromise authorityKeyIdentifier = keyid:always [ oids_section ] GroupeSTIAssurance = 1.3.6.1.4.1.51063.0.1 GroupeSTIUser = 1.3.6.1.4.1.51063.0.1.0 GroupeSTIDevice = 1.3.6.1.4.1.51063.0.1.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at spatiallabs.com Tue Apr 7 16:36:10 2020 From: jason at spatiallabs.com (Jason Proctor) Date: Tue, 7 Apr 2020 09:36:10 -0700 Subject: OpenSSL vs SPKI In-Reply-To: <20200407060307.GC41308@straasha.imrryr.org> References: <20200407060307.GC41308@straasha.imrryr.org> Message-ID: On Mon, Apr 6, 2020 at 11:03 PM Viktor Dukhovni wrote: > > > Question -- is there a supported way of importing SPKI encoded public > > keys into the OpenSSL world? > > Yes. That'd be d2i_PUBKEY(3): > > https://www.openssl.org/docs/man1.1.1/man3/d2i_PUBKEY.html > Perfect! Thanks so much. From jason at spatiallabs.com Tue Apr 7 17:00:05 2020 From: jason at spatiallabs.com (Jason Proctor) Date: Tue, 7 Apr 2020 10:00:05 -0700 Subject: OpenSSL vs SPKI In-Reply-To: References: Message-ID: On Mon, Apr 6, 2020 at 10:03 PM William Roberts wrote: > > > > I don't think I would consider it a hack necessarily. I work on the TPM stack and have to convert TPM structures to RSA public key structures for ooenssl to utilize, and we use this routine along the way. I would imagine theirs a higher level public from private routine you can call. I would dissect what: > > openssl rsa -in mykey.pem -pubout > mykey.pub > > Is doing Thanks for the help. Turns out, d2i_PUBKEY() does exactly the thing. The advantage over picking BIGNUMs out of the SPKI bundle is that the code doesn't need to know the key size. From jason at spatiallabs.com Tue Apr 7 18:07:11 2020 From: jason at spatiallabs.com (Jason Proctor) Date: Tue, 7 Apr 2020 11:07:11 -0700 Subject: tbslen parameter in EVP_PKEY_sign() and EVP_PKEY_verify() Message-ID: Esteemed cryptologists, Question regarding the "tbslen" parameter to the sign and verify functions. The documentation says -- "The verified data (i.e. the data believed originally signed) is specified using the tbs and tbslen parameters." Which might indicate that tbslen is the length of the payload. However I found that I had to set this to the length of the *signature* to get these calls to work. The sign() operation fails at rsa_pmeth.c line 134, and the debugger does indeed tell me that it's expecting 32 there, rather than the payload length which is 1024. Is this correct? Anything I'm missing, here? thanks for any clarity here Jason at Spatial From aerowolf at gmail.com Tue Apr 7 18:17:48 2020 From: aerowolf at gmail.com (Kyle Hamilton) Date: Tue, 7 Apr 2020 13:17:48 -0500 Subject: tbslen parameter in EVP_PKEY_sign() and EVP_PKEY_verify() In-Reply-To: References: Message-ID: 32 bytes means you're signing using RSA-WITH-SHA-256, yes? tbs is the digest value you calculated, tbslen is the size in bytes of the digest. -Kyle H On Tue, Apr 7, 2020 at 1:07 PM Jason Proctor wrote: > > Esteemed cryptologists, > > Question regarding the "tbslen" parameter to the sign and verify > functions. The documentation says -- > > "The verified data (i.e. the data believed originally signed) is > specified using the tbs and tbslen parameters." > > Which might indicate that tbslen is the length of the payload. However > I found that I had to set this to the length of the *signature* to get > these calls to work. The sign() operation fails at rsa_pmeth.c line > 134, and the debugger does indeed tell me that it's expecting 32 > there, rather than the payload length which is 1024. > > Is this correct? Anything I'm missing, here? > > thanks for any clarity here > Jason at Spatial From jason at spatiallabs.com Tue Apr 7 18:39:26 2020 From: jason at spatiallabs.com (Jason Proctor) Date: Tue, 7 Apr 2020 11:39:26 -0700 Subject: tbslen parameter in EVP_PKEY_sign() and EVP_PKEY_verify() In-Reply-To: References: Message-ID: Yes (duh) of course. The actual sign and verify functions don't know anything about the original payload. They only care about the thing being signed. Thanks for the help! On Tue, Apr 7, 2020 at 11:18 AM Kyle Hamilton wrote: > > 32 bytes means you're signing using RSA-WITH-SHA-256, yes? > > tbs is the digest value you calculated, tbslen is the size in bytes of > the digest. > > -Kyle H > > On Tue, Apr 7, 2020 at 1:07 PM Jason Proctor wrote: > > > > Esteemed cryptologists, > > > > Question regarding the "tbslen" parameter to the sign and verify > > functions. The documentation says -- > > > > "The verified data (i.e. the data believed originally signed) is > > specified using the tbs and tbslen parameters." > > > > Which might indicate that tbslen is the length of the payload. However > > I found that I had to set this to the length of the *signature* to get > > these calls to work. The sign() operation fails at rsa_pmeth.c line > > 134, and the debugger does indeed tell me that it's expecting 32 > > there, rather than the payload length which is 1024. > > > > Is this correct? Anything I'm missing, here? > > > > thanks for any clarity here > > Jason at Spatial From dcoombs at carillon.ca Tue Apr 7 18:43:07 2020 From: dcoombs at carillon.ca (Dave Coombs) Date: Tue, 7 Apr 2020 14:43:07 -0400 Subject: Help with certificatePolicies section In-Reply-To: References: Message-ID: <4DF0D38D-B75D-45EE-B53D-F90134751D9C@carillon.ca> Hi, I could be wrong, but I think the problem may be that [Cert_policy_server] has a policyIdentifier with two values. Try something like: [server_cert] certificatePolicies = ia5org, @Cert_policy_server, @Cert_other_policy_server [Cert_policy_server] policyIdentifier = GroupeSTIAssurance CPS.1 = http://cps.groupesti.com [Cert_other_policy_server] policyIdentifier = GroupeSTIDevice Good luck, -Dave > On Apr 7, 2020, at 11:57, Richard Simard wrote: > > Libor Chocholaty > > openssl ca -config etc/intermediate.cnf -extensions server_cert -days 1825 -notext -md sha256 -in intermediate/csr/test.groupesti.com.csr -out intermediate/certs/test.groupesti.com.crt > > Using configuration from etc/intermediate.cnf > Enter pass phrase for /CA/intermediate/private/intermediate.key: ************ > > Error Loading extension section server_cert > 140542588306560:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=email_in_dn > 140542588306560:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=rand_serial > 140542588306560:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:../crypto/asn1/a_object.c:73: > 140542588306560:error:2208306E:X509 V3 routines:policy_section:invalid object identifier:../crypto/x509v3/v3_cpols.c:183:section:Cert_policy_server,name:policyIdentifier,value:GroupeSTIAssurance, GroupeSTIDevice > 140542588306560:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:../crypto/x509v3/v3_conf.c:47:name=certificatePolicies, value=ia5org, @Cert_policy_server > > Intermediate.cnf > > [ openssl_init ] > oid_section = oids_section > > [ ca ] > default_ca = CA_default > > [ CA_default ] > dir = /CA/intermediate > certs = $dir/certs > crl_dir = $dir/crl > new_certs_dir = $dir/newcerts > database = $dir/index.txt > serial = $dir/serial > RANDFILE = $dir/private/.rand > private_key = $dir/private/intermediate.key > certificate = $dir/certs/intermediate.crt > crlnumber = $dir/crlnumber > crl = $dir/crl/intermediate.crl > crl_extensions = crl_ext > default_crl_days = 30 > default_md = sha256 > name_opt = ca_default > cert_opt = ca_default > default_days = 375 > preserve = no > policy = policy_loose > > [ policy_strict ] > countryName = match > stateOrProvinceName = match > organizationName = match > organizationalUnitName = optional > commonName = supplied > emailAddress = optional > > [ policy_loose ] > countryName = optional > stateOrProvinceName = optional > localityName = optional > organizationName = optional > organizationalUnitName = optional > commonName = supplied > emailAddress = optional > > [ req ] > default_bits = 2048 > distinguished_name = req_distinguished_name > utf8 = yes > string_mask = utf8only > name_opt = multiline, -esc_msb, utf8 > default_md = sha256 > x509_extensions = v3_ca > > [ req_distinguished_name ] > countryName = "1. Nom du pays (2 lettres) (Ex, CA) " > countryName_max = 2 > countryName_default = CA > stateOrProvinceName = "2. Nom de l'?tat ou de la province (Ex, Qu?bec) " > stateOrProvinceName_default = Qu?bec > localityName = "3. Nom de localit? (Ex, Saguenay) " > localityName_default = Saguenay > organizationName = "4. Nom de l'organisation (Ex, Groupe Solutions TI) " > organizationName_default = Groupe Solutions TI Inc. > organizationalUnitName = "5. Nom de l'unit? organisationnelle (Ex, Service web) " > organizationalUnitName_default = > commonName = "6. Nom de la personne (Ex, Jean Tremblay) " > commonName_max = 64 > commonName_default = > emailAddress = "7. Adresse courriel (Ex, vous at domain.com " > emailAddress_max = 64 > emailAddress_default = > > [ issuer_section ] > O = Groupe Solutions TI Inc. > CN = Groupe Solutions TI Inc. - Autorit? TLS V3 Principal > C = CA > ST = Qu?bec > L = Saguenay > streetAddress = 3-4109, Saint-Alexandre > postalCode = G8A 2H1 > emailAddress = support at groupesti.com > telephoneNumber = +1 (418) 695-9007 > > [ v3_ca ] > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid:always,issuer > basicConstraints = critical, CA:true > keyUsage = critical, digitalSignature, cRLSign, keyCertSign > > [ v3_intermediate_ca ] > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid:always,issuer > basicConstraints = critical, CA:true, pathlen:0 > keyUsage = critical, digitalSignature, cRLSign, keyCertSign > > [ usr_cert ] > basicConstraints = CA:FALSE > nsCertType = client, email > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid,issuer > keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment > extendedKeyUsage = clientAuth, emailProtection > SMIME-CAPS = ASN1:SEQUENCE:smime_seq > crlDistributionPoints = crl_section > > [ Policy_usr_cert ] > policyIdentifier = GroupeSTIAssurance, GroupeSTIUser > CPS = http://cps.groupesti.com > > [ server_cert ] > basicConstraints = CA:FALSE > nsCertType = server > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid, issuer:always > keyUsage = critical, digitalSignature, keyEncipherment > extendedKeyUsage = serverAuth > certificatePolicies = ia5org, @Cert_policy_server > crlDistributionPoints = crl_section > > [ Cert_policy_server ] > policyIdentifier = GroupeSTIAssurance, GroupeSTIDevice > CPS.1 = http://cps.groupesti.com > > [ crl_ext ] > authorityKeyIdentifier = keyid:always > > [ crl_section ] > fullname = URI:http://pki.groupesti.com/ca.crl > CRLissuer = dirName:issuer_section > reasons = keyCompromise, CACompromise > authorityKeyIdentifier = keyid:always > > [ ocsp ] > basicConstraints = CA:FALSE > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid, issuer > keyUsage = critical, digitalSignature > extendedKeyUsage = critical, OCSPSigning > > [ smime_seq ] > SMIMECapability.0 = SEQWRAP, OID:sha1 > SMIMECapability.1 = SEQWRAP, OID:sha256 > SMIMECapability.2 = SEQWRAP, OID:sha1WithRSA > SMIMECapability.3 = SEQWRAP, OID:aes-256-ecb > SMIMECapability.4 = SEQWRAP, OID:aes-256-cbc > SMIMECapability.5 = SEQWRAP, OID:aes-256-ofb > SMIMECapability.6 = SEQWRAP, OID:aes-128-ecb > SMIMECapability.7 = SEQWRAP, OID:aes-128-cbc > SMIMECapability.8 = SEQWRAP, OID:aes-128-ecb > SMIMECapability.9 = SEQUENCE:rsa_enc > > [ oids_section ] > GroupeSTIAssurance = 1.3.6.1.4.1.51063.0.1 > GroupeSTIUser = 1.3.6.1.4.1.51063.0.1.0 > GroupeSTIDevice = 1.3.6.1.4.1.51063.0.1.1 > GroupeSTIAssuranceEV = 1.3.6.1.4.1.51063.0.1.2 > > De : openssl-users De la part de Libor Chocholaty > Envoy? : 6 avril 2020 16:42 > ? : openssl-users at openssl.org > Objet : Re: Help with certificatePolicies section > > Hi, > > could you share commands that led to this error? > > It looks to me referenced non existent section in config file like as param "-extensions" option. > > Regards, > Libor > > > > On 2020-04-06 19:43, Richard Simard wrote: > > Hi! > Anybody can help me whit this error? > > Error Loading extension section server_cert > 140091048477824:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=email_in_dn > 140091048477824:error:0E06D06C:configuration file routines:NCONF_get_string:no value:../crypto/conf/conf_lib.c:273:group=CA_default name=rand_serial > 140091048477824:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:../crypto/asn1/a_object.c:73: > 140091048477824:error:2208306E:X509 V3 routines:policy_section:invalid object identifier:../crypto/x509v3/v3_cpols.c:183:section:Cert_policy_server,name:policyIdentifier,value:GroupeSTIAssurance, GroupeSTIDevice > 140091048477824:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:../crypto/x509v3/v3_conf.c:47:name=certificatePolicies, value=ia5org,1.3.6.1.4.1.51063, at Cert_policy_server > > [ openssl_init ] > oid_section = oids_section > > [ server_cert ] > basicConstraints = CA:FALSE > nsCertType = server > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid, issuer:always > keyUsage = critical, digitalSignature, keyEncipherment > extendedKeyUsage = serverAuth > certificatePolicies = ia5org, @Cert_policy_server > crlDistributionPoints = crl_section > > [ Cert_policy_server ] > policyIdentifier = GroupeSTIAssurance, GroupeSTIDevice > CPS.1 = http://cps.groupesti.com > > [ crl_section ] > fullname = URI:http://pki.groupesti.com/ca.crl > CRLissuer = dirName:issuer_section > reasons = keyCompromise, CACompromise > authorityKeyIdentifier = keyid:always > > [ oids_section ] > GroupeSTIAssurance = 1.3.6.1.4.1.51063.0.1 > GroupeSTIUser = 1.3.6.1.4.1.51063.0.1.0 > GroupeSTIDevice = 1.3.6.1.4.1.51063.0.1.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 9617 bytes Desc: not available URL: From openssl-users at dukhovni.org Tue Apr 7 19:09:57 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 7 Apr 2020 15:09:57 -0400 Subject: OpenSSL vs SPKI In-Reply-To: References: Message-ID: <20200407190957.GE41308@straasha.imrryr.org> On Tue, Apr 07, 2020 at 10:00:05AM -0700, Jason Proctor wrote: > Turns out, d2i_PUBKEY() does exactly the thing. > The advantage over picking BIGNUMs out of the SPKI bundle is that the > code doesn't need to know the key size. It is also algorithm independent. Works not only with RSA, but also with DSA (deprecated), ECDSA, EdDSA, and any future public key types. -- Viktor. From armen.babikyan at gmail.com Tue Apr 7 21:18:52 2020 From: armen.babikyan at gmail.com (Armen Babikyan) Date: Tue, 7 Apr 2020 14:18:52 -0700 Subject: Replacing SECLEVEL with AUTHSECLEVEL and TLSSECLEVEL Message-ID: Hello, I was wondering if there was any effort to make progress in separating the SECLEVEL directive into AUTHSECLEVEL and TLSSECLEVEL as described in $openssl/ssl/ssl_cert.c's ssl_verify_cert_chain() function. I found a post from 2016 on this mailing list about this: https://mta.openssl.org/pipermail/openssl-users/2016-May/003768.html I have a use case where I need to enable Mutual TLS authentication for hardware clients that have immutable manufacturer-signed certificates. Some of those certificates are signed with MD5, but I don't know which ones beforehand, and I'd rather not have SECLEVEL=0 compromise the allowable ciphers in the TLS connection. [re MD5 insecurity in auth: I already have application-layer authentication (e.g. HTTPS Bearer auth), and I'm not looking to replace that with Mutual TLS - I do need to opportunistically gather other information from the client certs though.] In the meantime, if my only option is to use SECLEVEL=0, I think I'd need to do some application-layer enforcement of TLS parameters. I suppose I could enforce ciphers by using SSL_get_cipher_name(). Are there other parameters that you recommend I enforce at the application layer? Is it possible to reach parity with "SECLEVEL=1" behavior this way? Are there any other downsides or issues to be aware of with this approach? Many thanks! Armen -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at omp.co.nz Tue Apr 7 23:25:28 2020 From: martin at omp.co.nz (Martin Searancke) Date: Wed, 8 Apr 2020 11:25:28 +1200 Subject: BIO_set_conn_hostname & BIO_get_ssl not found in libssl-1_1.dll Message-ID: I am trying to implement DTLS with PSK security in Delphi using the OpenSSL library. The C++ examples I am basing this on call "BIO_set_conn_hostname" and "BIO_get_ssl" but these functions do not appear to be in "libssl-1_1.dll". The OpenSSL documentation suggests that these functions should be in version 1.1 but I have interrogated the DLL and they are not there - where should I find them? Here are the 2 examples I am trying to base my code on: https://chris-wood.github.io/2016/05/06/OpenSSL-DTLS.html https://bitbucket.org/tiebingzhang/tls-psk-server-client-example/src/783092f802383421cfa1088b0e7b804b39d3cf7c/psk_client.c?at=default Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Apr 8 01:02:53 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 7 Apr 2020 21:02:53 -0400 Subject: BIO_set_conn_hostname & BIO_get_ssl not found in libssl-1_1.dll In-Reply-To: References: Message-ID: <20200408010253.GL41308@straasha.imrryr.org> On Wed, Apr 08, 2020 at 11:25:28AM +1200, Martin Searancke wrote: > The C++ examples I am basing this on call "BIO_set_conn_hostname" and > "BIO_get_ssl" but these functions do not appear to be in "libssl-1_1.dll". Both of these are C macros: /usr/include/openssl/bio.h:# define BIO_set_conn_hostname(b,name) BIO_ctrl(...) /usr/include/openssl/bio.h:# define BIO_get_ssl(b,sslp) BIO_ctrl(...) > The OpenSSL documentation suggests that these functions should be in > version 1.1 but I have interrogated the DLL and they are not there - where > should I find them? In the header file. -- Viktor. From doctor at doctor.nl2k.ab.ca Wed Apr 8 06:46:27 2020 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 8 Apr 2020 00:46:27 -0600 Subject: openssl-1.1.1-stable-SNAP-20200408 Message-ID: <20200408064627.GA42422@doctor.nl2k.ab.ca> Error occured while compiling in FreeBsd 12 root at gallifrey:/usr/source/openssl-1.1.1-stable-SNAP-20200408 # make make depend && make _all /usr/local/bin/clang10 -I. -Iinclude -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/ssl\"" -DENGINESDIR="\"/usr//lib/engines-1.1\"" -D_THREAD_SAFE -D_REENTRANT -DZLIB -DZLIB_SHARED -DNDEBUG -MMD -MF crypto/rand/drbg_ctr.d.tmp -MT crypto/rand/drbg_ctr.o -c -o crypto/rand/drbg_ctr.o crypto/rand/drbg_ctr.c crypto/rand/drbg_ctr.c:25:5: error: use of undeclared identifier 'u32' u32 n = 16, c = 1; ^ crypto/rand/drbg_ctr.c:28:11: error: use of undeclared identifier 'n' --n; ^ crypto/rand/drbg_ctr.c:29:9: error: use of undeclared identifier 'c' c += p[n]; ^ crypto/rand/drbg_ctr.c:29:16: error: use of undeclared identifier 'n' c += p[n]; ^ crypto/rand/drbg_ctr.c:30:11: error: use of undeclared identifier 'n' p[n] = (u8)c; ^ crypto/rand/drbg_ctr.c:30:17: error: use of undeclared identifier 'u8' p[n] = (u8)c; ^ crypto/rand/drbg_ctr.c:31:9: error: use of undeclared identifier 'c' c >>= 8; ^ crypto/rand/drbg_ctr.c:32:14: error: use of undeclared identifier 'n' } while (n); ^ 8 errors generated. *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.1.1-stable-SNAP-20200408 *** Error code 1 Stop. Please fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Those who cannot win on facts rely upon slander. -unknown From matt at openssl.org Wed Apr 8 08:26:31 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Apr 2020 09:26:31 +0100 Subject: openssl-1.1.1-stable-SNAP-20200408 In-Reply-To: <20200408064627.GA42422@doctor.nl2k.ab.ca> References: <20200408064627.GA42422@doctor.nl2k.ab.ca> Message-ID: <13c4b5e6-cdd5-d726-401b-6419004fa15f@openssl.org> The fix is already going through review here: https://github.com/openssl/openssl/pull/11489 It will probably be tomorrow before it gets merged. Matt On 08/04/2020 07:46, The Doctor wrote: > Error occured while compiling > > in FreeBsd 12 > > root at gallifrey:/usr/source/openssl-1.1.1-stable-SNAP-20200408 # make > make depend && make _all > /usr/local/bin/clang10 -I. -Iinclude -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/ssl\"" -DENGINESDIR="\"/usr//lib/engines-1.1\"" -D_THREAD_SAFE -D_REENTRANT -DZLIB -DZLIB_SHARED -DNDEBUG -MMD -MF crypto/rand/drbg_ctr.d.tmp -MT crypto/rand/drbg_ctr.o -c -o crypto/rand/drbg_ctr.o crypto/rand/drbg_ctr.c > crypto/rand/drbg_ctr.c:25:5: error: use of undeclared identifier 'u32' > u32 n = 16, c = 1; > ^ > crypto/rand/drbg_ctr.c:28:11: error: use of undeclared identifier 'n' > --n; > ^ > crypto/rand/drbg_ctr.c:29:9: error: use of undeclared identifier 'c' > c += p[n]; > ^ > crypto/rand/drbg_ctr.c:29:16: error: use of undeclared identifier 'n' > c += p[n]; > ^ > crypto/rand/drbg_ctr.c:30:11: error: use of undeclared identifier 'n' > p[n] = (u8)c; > ^ > crypto/rand/drbg_ctr.c:30:17: error: use of undeclared identifier 'u8' > p[n] = (u8)c; > ^ > crypto/rand/drbg_ctr.c:31:9: error: use of undeclared identifier 'c' > c >>= 8; > ^ > crypto/rand/drbg_ctr.c:32:14: error: use of undeclared identifier 'n' > } while (n); > ^ > 8 errors generated. > *** Error code 1 > > Stop. > make[1]: stopped in /usr/source/openssl-1.1.1-stable-SNAP-20200408 > *** Error code 1 > > Stop. > > Please fix. > From blumf at blueyonder.co.uk Wed Apr 8 10:47:19 2020 From: blumf at blueyonder.co.uk (Scott Morgan) Date: Wed, 8 Apr 2020 11:47:19 +0100 Subject: BIO_do_accept Issue Message-ID: Run into an odd issue. Consider the following program, based on the documentation[0], using OpenSSL 1.1.1f ==BEGIN== #include #include #include int main(int argc, char** argv) { BIO *abio; int res; abio = BIO_new_accept("4444"); res = BIO_do_accept(abio); printf("First BIO_do_accept returned : %d\n", res); if(res <= 0) { printf("Should have errored here!\n"); ERR_print_errors_fp(stderr); return 1; } if(res != 1) { printf("This is an error, just not correctly returned!\n"); ERR_print_errors_fp(stderr); } res = BIO_do_accept(abio); printf("Second BIO_do_accept returned : %d\n", res); if(res <= 0) { printf("Now we get an error!\n"); ERR_print_errors_fp(stderr); return 2; } return 0; } ==END== It compiles and runs fine, but if there is another app using the port, the first call to BIO_do_accept returns odd values that don't match the docs. C:\openssl_test>main.exe First BIO_do_accept returned : 356 This is an error, just not correctly returned! OPENSSL_Uplink(78C93330,08): no OPENSSL_Applink C:\openssl_test>main.exe First BIO_do_accept returned : 356 This is an error, just not correctly returned! OPENSSL_Uplink(79313330,08): no OPENSSL_Applink C:\openssl_test>main.exe First BIO_do_accept returned : 384 This is an error, just not correctly returned! OPENSSL_Uplink(79313330,08): no OPENSSL_Applink The docs say BIO_do_accept should return 0 or -1 on error. It seems a simple fix is just to check the return == 1, but why the odd and inconsistent return values? Scott [0] https://www.openssl.org/docs/man1.1.1/man3/BIO_do_accept.html From rpb5bnc at gmail.com Wed Apr 8 16:11:47 2020 From: rpb5bnc at gmail.com (Pete) Date: Wed, 8 Apr 2020 12:11:47 -0400 Subject: Additional FOM 3.0 question Message-ID: <9081ef5b-cf96-a192-fd3b-7daca3ec67ea@gmail.com> Hello, I know you guys are right now working hard to deliver the first alpha drop very soon, and that this first drop may include the initial functionality of the new FIPS support.? We know that the intention is to obtain one last 140-2 validation for the new 3.0 FOM, and it sounds like it's still going to be possible for downstream groups to leverage the the small number of OE validations so long as we follow the proper build process.? This is all really good to hear.? By any chance has there been any discussion yet regarding what will and will not be in the new 3.0 FOM?? If I recall correctly, the content list for the now defunct 1.1.1 based FOM was very long and complete.? Our team is in the planning stages for migrating to 3.0.0.? Knowing that the window for -2 validations is currently 9/22/2021 also plays into our planning effort.? If we need to develop a supplemental, or ancillary, FOM provider for 3.0 to include content that we need that did not make into the core 3.0 FOM we, too, would like to get one last -2 validation in. Again, I know you are focusing right now on this big first release, so even just a date for date for when a rough list could be available would help us in planning.? Something to put on a slide that says when we might know if we have additional work to do and what it might be. Thanks again very much for all you're doing, Pete From matt at openssl.org Wed Apr 8 16:34:51 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Apr 2020 17:34:51 +0100 Subject: Additional FOM 3.0 question In-Reply-To: <9081ef5b-cf96-a192-fd3b-7daca3ec67ea@gmail.com> References: <9081ef5b-cf96-a192-fd3b-7daca3ec67ea@gmail.com> Message-ID: On 08/04/2020 17:11, Pete wrote: > By any chance has there been any discussion yet regarding what will and > will not be in the new 3.0 FOM?? If I recall correctly, the content list > for the now defunct 1.1.1 based FOM was very long and complete.? Our > team is in the planning stages for migrating to 3.0.0.? Knowing that the > window for -2 validations is currently 9/22/2021 also plays into our > planning effort.? If we need to develop a supplemental, or ancillary, > FOM provider for 3.0 to include content that we need that did not make > into the core 3.0 FOM we, too, would like to get one last -2 validation in. By "the content list" I assume you mean the list of algorithms that we plan to validate. If you take a look at Appendix 3 of our original design doc you can see the planned list: https://www.openssl.org/docs/OpenSSL300Design.html Matt From rpb5bnc at gmail.com Wed Apr 8 16:41:09 2020 From: rpb5bnc at gmail.com (Pete) Date: Wed, 8 Apr 2020 12:41:09 -0400 Subject: Additional FOM 3.0 question In-Reply-To: References: <9081ef5b-cf96-a192-fd3b-7daca3ec67ea@gmail.com> Message-ID: Excellent.? That's exactly what I was looking for.? Sorry for missing that down at the bottom. Thanks again, Pete On 4/8/20 12:34 PM, Matt Caswell wrote: > > On 08/04/2020 17:11, Pete wrote: >> By any chance has there been any discussion yet regarding what will and >> will not be in the new 3.0 FOM?? If I recall correctly, the content list >> for the now defunct 1.1.1 based FOM was very long and complete.? Our >> team is in the planning stages for migrating to 3.0.0.? Knowing that the >> window for -2 validations is currently 9/22/2021 also plays into our >> planning effort.? If we need to develop a supplemental, or ancillary, >> FOM provider for 3.0 to include content that we need that did not make >> into the core 3.0 FOM we, too, would like to get one last -2 validation in. > By "the content list" I assume you mean the list of algorithms that we > plan to validate. If you take a look at Appendix 3 of our original > design doc you can see the planned list: > > https://www.openssl.org/docs/OpenSSL300Design.html > > Matt From openssl-users at dukhovni.org Wed Apr 8 17:06:22 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 Apr 2020 13:06:22 -0400 Subject: BIO_do_accept Issue In-Reply-To: References: Message-ID: <20200408170622.GS41308@straasha.imrryr.org> On Wed, Apr 08, 2020 at 11:47:19AM +0100, Scott Morgan via openssl-users wrote: > Run into an odd issue. > > Consider the following program, based on the documentation[0], using > OpenSSL 1.1.1f > > abio = BIO_new_accept("4444"); > res = BIO_do_accept(abio); It seems to me that since commit 417be660e1c BIO_do_accept() has incomplete error handling, "ret" isn't assigned when bind() or listen() fail: acpt_state(), crypto/bio//bss_acpt.c: line 241: case ACPT_S_LISTEN: { if (!BIO_listen(c->accept_sock, BIO_ADDRINFO_address(c->addr_iter), c->bind_mode)) { BIO_closesocket(c->accept_sock); goto exit_loop; } } ... exit_loop: if (bio != NULL) BIO_free(bio); else if (s >= 0) BIO_closesocket(s); end: return ret; So the function returns the wrong value of ret, in your case the the socket descriptor created in an earlier case in the loop. The fix is presumably to set ret to either -1 or 0, whichever is appropriate here. -- Viktor. From wieland at purdue.edu Wed Apr 8 18:13:31 2020 From: wieland at purdue.edu (Jeff Wieland) Date: Wed, 8 Apr 2020 14:13:31 -0400 Subject: building openssl 1.1.1 for Solaris 10 In-Reply-To: <92ba92c108b849cf92d2e5a82d4af959@DM5PR22MB1690.namprd22.prod.outlook.com> References: <006101d609d7$d8686ff0$89394fd0$@gmail.com> <006a01d609fd$b9441130$2bcc3390$@gmail.com> <005d01d60c0f$d0059d80$7010d880$@gmail.com> <006801d60c26$17d2cd70$47786850$@gmail.com> <001401d60cad$ace3bcd0$06ab3670$@gmail.com> <92ba92c108b849cf92d2e5a82d4af959@DM5PR22MB1690.namprd22.prod.outlook.com> Message-ID: <099e4043-9a50-f7ff-fb8d-e6e782e15eb9@purdue.edu> Michael Wojcik wrote: >> From: tim.j.culhane at gmail.com [mailto:tim.j.culhane at gmail.com] >> Sent: Tuesday, April 07, 2020 01:25 >> >> I ran the gmake and it fails with the below ld errors. >> >> Is this the known issue mentioned previously with building openssl on Sparc >> or is it caused by something else? >> >> ... >> >> Undefined first referenced >> symbol in file >> clock_gettime ./libcrypto.so > It appears that's a known issue with building OpenSSL 1.1.1 on Solaris 10. (I think we haven't run into this in my team because we're now on Solaris 11, but I haven't investigated.) > > Quanah Gibson-Mount mentioned this in a reply to your first post in this thread: > >> They may have run into >> which the OpenSSL project seems disinclined to fix. > If you look at that issue, you'll see people have posted workarounds. I believe it's just a matter of linking with an additional library. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > On Solaris 10, you need to link with -lrt to pick up the clock_gettime functions.? If you do something like "export LDFLAGS='-lrt'" before you invoke Configure, it should work. -- Jeff Wieland, UNIX/Network Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms From doctor at doctor.nl2k.ab.ca Thu Apr 9 06:45:24 2020 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Thu, 9 Apr 2020 00:45:24 -0600 Subject: openssl-1.1.1-stable-SNAP-20200408 In-Reply-To: <13c4b5e6-cdd5-d726-401b-6419004fa15f@openssl.org> References: <20200408064627.GA42422@doctor.nl2k.ab.ca> <13c4b5e6-cdd5-d726-401b-6419004fa15f@openssl.org> Message-ID: <20200409064524.GA69193@doctor.nl2k.ab.ca> On Wed, Apr 08, 2020 at 09:26:31AM +0100, Matt Caswell wrote: > The fix is already going through review here: > > https://github.com/openssl/openssl/pull/11489 > > It will probably be tomorrow before it gets merged. > > Matt > Still saw the problem in openssl-1.1.1-stable-SNAP-20200409 . > > On 08/04/2020 07:46, The Doctor wrote: > > Error occured while compiling > > > > in FreeBsd 12 > > > > root at gallifrey:/usr/source/openssl-1.1.1-stable-SNAP-20200408 # make > > make depend && make _all > > /usr/local/bin/clang10 -I. -Iinclude -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/ssl\"" -DENGINESDIR="\"/usr//lib/engines-1.1\"" -D_THREAD_SAFE -D_REENTRANT -DZLIB -DZLIB_SHARED -DNDEBUG -MMD -MF crypto/rand/drbg_ctr.d.tmp -MT crypto/rand/drbg_ctr.o -c -o crypto/rand/drbg_ctr.o crypto/rand/drbg_ctr.c > > crypto/rand/drbg_ctr.c:25:5: error: use of undeclared identifier 'u32' > > u32 n = 16, c = 1; > > ^ > > crypto/rand/drbg_ctr.c:28:11: error: use of undeclared identifier 'n' > > --n; > > ^ > > crypto/rand/drbg_ctr.c:29:9: error: use of undeclared identifier 'c' > > c += p[n]; > > ^ > > crypto/rand/drbg_ctr.c:29:16: error: use of undeclared identifier 'n' > > c += p[n]; > > ^ > > crypto/rand/drbg_ctr.c:30:11: error: use of undeclared identifier 'n' > > p[n] = (u8)c; > > ^ > > crypto/rand/drbg_ctr.c:30:17: error: use of undeclared identifier 'u8' > > p[n] = (u8)c; > > ^ > > crypto/rand/drbg_ctr.c:31:9: error: use of undeclared identifier 'c' > > c >>= 8; > > ^ > > crypto/rand/drbg_ctr.c:32:14: error: use of undeclared identifier 'n' > > } while (n); > > ^ > > 8 errors generated. > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/source/openssl-1.1.1-stable-SNAP-20200408 > > *** Error code 1 > > > > Stop. > > > > Please fix. > > -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Those who cannot win on facts rely upon slander. -unknown From matt at openssl.org Thu Apr 9 10:27:48 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 9 Apr 2020 11:27:48 +0100 Subject: openssl-1.1.1-stable-SNAP-20200408 In-Reply-To: <20200409064524.GA69193@doctor.nl2k.ab.ca> References: <20200408064627.GA42422@doctor.nl2k.ab.ca> <13c4b5e6-cdd5-d726-401b-6419004fa15f@openssl.org> <20200409064524.GA69193@doctor.nl2k.ab.ca> Message-ID: On 09/04/2020 07:45, The Doctor wrote: > On Wed, Apr 08, 2020 at 09:26:31AM +0100, Matt Caswell wrote: >> The fix is already going through review here: >> >> https://github.com/openssl/openssl/pull/11489 >> >> It will probably be tomorrow before it gets merged. >> >> Matt >> > > Still saw the problem in openssl-1.1.1-stable-SNAP-20200409 . The fix was merged earlier today. Matt > >> >> On 08/04/2020 07:46, The Doctor wrote: >>> Error occured while compiling >>> >>> in FreeBsd 12 >>> >>> root at gallifrey:/usr/source/openssl-1.1.1-stable-SNAP-20200408 # make >>> make depend && make _all >>> /usr/local/bin/clang10 -I. -Iinclude -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/ssl\"" -DENGINESDIR="\"/usr//lib/engines-1.1\"" -D_THREAD_SAFE -D_REENTRANT -DZLIB -DZLIB_SHARED -DNDEBUG -MMD -MF crypto/rand/drbg_ctr.d.tmp -MT crypto/rand/drbg_ctr.o -c -o crypto/rand/drbg_ctr.o crypto/rand/drbg_ctr.c >>> crypto/rand/drbg_ctr.c:25:5: error: use of undeclared identifier 'u32' >>> u32 n = 16, c = 1; >>> ^ >>> crypto/rand/drbg_ctr.c:28:11: error: use of undeclared identifier 'n' >>> --n; >>> ^ >>> crypto/rand/drbg_ctr.c:29:9: error: use of undeclared identifier 'c' >>> c += p[n]; >>> ^ >>> crypto/rand/drbg_ctr.c:29:16: error: use of undeclared identifier 'n' >>> c += p[n]; >>> ^ >>> crypto/rand/drbg_ctr.c:30:11: error: use of undeclared identifier 'n' >>> p[n] = (u8)c; >>> ^ >>> crypto/rand/drbg_ctr.c:30:17: error: use of undeclared identifier 'u8' >>> p[n] = (u8)c; >>> ^ >>> crypto/rand/drbg_ctr.c:31:9: error: use of undeclared identifier 'c' >>> c >>= 8; >>> ^ >>> crypto/rand/drbg_ctr.c:32:14: error: use of undeclared identifier 'n' >>> } while (n); >>> ^ >>> 8 errors generated. >>> *** Error code 1 >>> >>> Stop. >>> make[1]: stopped in /usr/source/openssl-1.1.1-stable-SNAP-20200408 >>> *** Error code 1 >>> >>> Stop. >>> >>> Please fix. >>> > From blumf at blueyonder.co.uk Thu Apr 9 10:42:11 2020 From: blumf at blueyonder.co.uk (Scott Morgan) Date: Thu, 9 Apr 2020 11:42:11 +0100 Subject: BIO_do_accept Issue In-Reply-To: <20200408170622.GS41308@straasha.imrryr.org> References: <20200408170622.GS41308@straasha.imrryr.org> Message-ID: <5159422e-9849-44d5-81d7-97e2593ecd9c@blueyonder.co.uk> On 08/04/2020 18:06, Viktor Dukhovni wrote: > On Wed, Apr 08, 2020 at 11:47:19AM +0100, Scott Morgan via openssl-users wrote: > >> Run into an odd issue. >> >> Consider the following program, based on the documentation[0], using >> OpenSSL 1.1.1f >> >> abio = BIO_new_accept("4444"); >> res = BIO_do_accept(abio); > > It seems to me that since commit 417be660e1c BIO_do_accept() has > incomplete error handling, "ret" isn't assigned when bind() or listen() > fail: > ...... > > So the function returns the wrong value of ret, in your case the the > socket descriptor created in an earlier case in the loop. The fix is > presumably to set ret to either -1 or 0, whichever is appropriate here. > That makes sense. Just checked github, and there is a ticket listing that problem, #7717 Scott From doctor at doctor.nl2k.ab.ca Thu Apr 9 10:44:44 2020 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Thu, 9 Apr 2020 04:44:44 -0600 Subject: openssl-1.1.1-stable-SNAP-20200408 In-Reply-To: References: <20200408064627.GA42422@doctor.nl2k.ab.ca> <13c4b5e6-cdd5-d726-401b-6419004fa15f@openssl.org> <20200409064524.GA69193@doctor.nl2k.ab.ca> Message-ID: <20200409104444.GA26379@doctor.nl2k.ab.ca> On Thu, Apr 09, 2020 at 11:27:48AM +0100, Matt Caswell wrote: > > > On 09/04/2020 07:45, The Doctor wrote: > > On Wed, Apr 08, 2020 at 09:26:31AM +0100, Matt Caswell wrote: > >> The fix is already going through review here: > >> > >> https://github.com/openssl/openssl/pull/11489 > >> > >> It will probably be tomorrow before it gets merged. > >> > >> Matt > >> > > > > Still saw the problem in openssl-1.1.1-stable-SNAP-20200409 . > > The fix was merged earlier today. > > Matt > I will check in tomorrow. > > > >> > >> On 08/04/2020 07:46, The Doctor wrote: > >>> Error occured while compiling > >>> > >>> in FreeBsd 12 > >>> > >>> root at gallifrey:/usr/source/openssl-1.1.1-stable-SNAP-20200408 # make > >>> make depend && make _all > >>> /usr/local/bin/clang10 -I. -Iinclude -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/ssl\"" -DENGINESDIR="\"/usr//lib/engines-1.1\"" -D_THREAD_SAFE -D_REENTRANT -DZLIB -DZLIB_SHARED -DNDEBUG -MMD -MF crypto/rand/drbg_ctr.d.tmp -MT crypto/rand/drbg_ctr.o -c -o crypto/rand/drbg_ctr.o crypto/rand/drbg_ctr.c > >>> crypto/rand/drbg_ctr.c:25:5: error: use of undeclared identifier 'u32' > >>> u32 n = 16, c = 1; > >>> ^ > >>> crypto/rand/drbg_ctr.c:28:11: error: use of undeclared identifier 'n' > >>> --n; > >>> ^ > >>> crypto/rand/drbg_ctr.c:29:9: error: use of undeclared identifier 'c' > >>> c += p[n]; > >>> ^ > >>> crypto/rand/drbg_ctr.c:29:16: error: use of undeclared identifier 'n' > >>> c += p[n]; > >>> ^ > >>> crypto/rand/drbg_ctr.c:30:11: error: use of undeclared identifier 'n' > >>> p[n] = (u8)c; > >>> ^ > >>> crypto/rand/drbg_ctr.c:30:17: error: use of undeclared identifier 'u8' > >>> p[n] = (u8)c; > >>> ^ > >>> crypto/rand/drbg_ctr.c:31:9: error: use of undeclared identifier 'c' > >>> c >>= 8; > >>> ^ > >>> crypto/rand/drbg_ctr.c:32:14: error: use of undeclared identifier 'n' > >>> } while (n); > >>> ^ > >>> 8 errors generated. > >>> *** Error code 1 > >>> > >>> Stop. > >>> make[1]: stopped in /usr/source/openssl-1.1.1-stable-SNAP-20200408 > >>> *** Error code 1 > >>> > >>> Stop. > >>> > >>> Please fix. > >>> > > -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Those who cannot win on facts rely upon slander. -unknown From dirkx at webweaving.org Thu Apr 9 10:44:24 2020 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Thu, 9 Apr 2020 12:44:24 +0200 Subject: Non-padding & EVP Message-ID: I am trying to implement a bit of Rust / Zenroom (the context is performance testing on very small devices for DP-3T privacy preserving content tracking[3]): Rust (i is 0 .. 10) let mut iv = [0u8; 16]; iv[12..16].copy_from_slice(&i.to_be_bytes()); let mut block = GenericArray::clone_from_slice(& iv); cipher.encrypt_block(&mut block); Zen (i is 0 .. 10): PRF = SHA256:hmac(ACK.secret_day_key, BROADCAST_KEY) PRG = AES.ctr(PRF, OCTET.from_number(0), OCTET.from_number(i)) Using native OpenSSL its EVP interface for the AES 128 bit CTR mode. I've disabled padding and am passing it 128 bit blocks. But what I get back from EVP_EncryptFinal() is an 'extra' block at the end: uint8_t aes_key[16], iv[16], plain[16]; bzero(iv, 16); *(uint32_t*)(iv+12) = htonl(i); // big endian or network order. EVP_EncryptInit(ctx, cipher, aes_key, iv); EVP_CIPHER_CTX_set_padding(ctx, 0); int len = 0, len2 = 0; EVP_EncryptUpdate(ctx, outptr, &len, plain, 16); assert(len <= 16); // ok = len is sizeof(plain) == 16 EVP_EncryptFinal(ctx, outptr + len, &len2); assert(len + len2 != 16); // actual result is len2 = 16 (expected 0) and 32 byts in total. Last 16 bytes of outptr are 0. Why is that ? Or how should this be done correctly ? With kind regards, Dw. 0: full code at:https://gist.github.com/dirkx/53143596fa935b6de96e6521d82797b6 1: man page bit: EVP_CIPHER_CTX_set_padding() enables or disables padding. By default encryption operations are padded using standard block padding and the padding is checked and removed when decrypting. If the pad parameter is zero then no padding is performed, the total amount of data encrypted or decrypted must then be a multiple of the block size or an error will occur. 3: https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf From kevin.lengauer at adnovum.ch Thu Apr 9 15:19:25 2020 From: kevin.lengauer at adnovum.ch (K Lengauer) Date: Thu, 9 Apr 2020 08:19:25 -0700 (MST) Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> <1583335623698-0.post@n7.nabble.com> <36E03C4F-7A66-407B-A154-2E02F2C03021@akamai.com> <1583771390427-0.post@n7.nabble.com> Message-ID: <1586445565652-0.post@n7.nabble.com> First of all, thanks Michael Wojcik for your answer regarding the datasets. I was able to get it working. In the meantime I got the whole build done and am working on my tests. One thing that I noticed recently is a wrong certificate X509 name output that happens because of the following code section in "x509_obj.c": #ifdef CHARSET_EBCDIC if (type == V_ASN1_GENERALSTRING || type == V_ASN1_VISIBLESTRING || type == V_ASN1_PRINTABLESTRING || type == V_ASN1_TELETEXSTRING || type == V_ASN1_IA5STRING) { if (num > (int)sizeof(ebcdic_buf)) num = sizeof(ebcdic_buf); ascii2ebcdic(ebcdic_buf, q, num); q = ebcdic_buf; } #endif On zOS during my tests the input type I have is "V_ASN1_UTF8STRING" for my certificates. Thus, the ascii2ebcdic conversion never happens but in the following lines on code which are executed the causes an issue as ASCII instead of EBCDIC chars are treated with "os_toascii". #ifndef CHARSET_EBCDIC if ((q[j] < ' ') || (q[j] > '~')) l2 += 3; #else if ((os_toascii[q[j]] < os_toascii[' ']) || (os_toascii[q[j]] > os_toascii['~'])) l2 += 3; #endif This finally leads to weird behavior with the comparison to ' ' (space) and '~' and causes the output to be hex chars due to the following code section in "x509_obj.c": n = os_toascii[q[j]]; if ((n < os_toascii[' ']) || (n > os_toascii['~'])) { *(p++) = '\\'; *(p++) = 'x'; *(p++) = hex[(n >> 4) & 0x0f]; *(p++) = hex[n & 0x0f]; } else *(p++) = q[j]; Now, I am aware that there are several EBCDIC issues as OpenSSL is to my knowledge not currently tested for zOS (see also: https://github.com/openssl/openssl/issues/4154). If I add "type == V_ASN1_UTF8STRING" to the list of allowed types I was able to generate a human readable output. #ifdef CHARSET_EBCDIC if (type == V_ASN1_GENERALSTRING || type == V_ASN1_VISIBLESTRING || type == V_ASN1_PRINTABLESTRING || type == V_ASN1_TELETEXSTRING || type == V_ASN1_UTF8STRING || type == V_ASN1_IA5STRING) { if (num > (int)sizeof(ebcdic_buf)) num = sizeof(ebcdic_buf); ascii2ebcdic(ebcdic_buf, q, num); q = ebcdic_buf; } #endif However, I wanted to ask for any concerns and other inputs here. Am I missing anything major here? As UTF8 is a superset of ASCII there might be other issues with this change that I have overlooked so far. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From openssl-users at dukhovni.org Thu Apr 9 18:23:19 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Apr 2020 14:23:19 -0400 Subject: BIO_do_accept Issue In-Reply-To: <5159422e-9849-44d5-81d7-97e2593ecd9c@blueyonder.co.uk> References: <20200408170622.GS41308@straasha.imrryr.org> <5159422e-9849-44d5-81d7-97e2593ecd9c@blueyonder.co.uk> Message-ID: <20200409182319.GT41308@straasha.imrryr.org> On Thu, Apr 09, 2020 at 11:42:11AM +0100, Scott Morgan via openssl-users wrote: > > It seems to me that since commit 417be660e1c BIO_do_accept() has > > incomplete error handling, "ret" isn't assigned when bind() or listen() > > fail: > > > ...... > > > > So the function returns the wrong value of ret, in your case the the > > socket descriptor created in an earlier case in the loop. The fix is > > presumably to set ret to either -1 or 0, whichever is appropriate here. > > > > That makes sense. Just checked github, and there is a ticket listing > that problem, #7717 Thanks for finding that, and posting the PR. The fix will surely be included when 1.1.1g is released. -- Viktor. From kevin.lengauer at adnovum.ch Tue Apr 14 08:00:40 2020 From: kevin.lengauer at adnovum.ch (K Lengauer) Date: Tue, 14 Apr 2020 01:00:40 -0700 (MST) Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <1586445565652-0.post@n7.nabble.com> References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> <1583335623698-0.post@n7.nabble.com> <36E03C4F-7A66-407B-A154-2E02F2C03021@akamai.com> <1583771390427-0.post@n7.nabble.com> <1586445565652-0.post@n7.nabble.com> Message-ID: <1586851240203-0.post@n7.nabble.com> Dear all, I want to add another issue that occurred to me and would appreciate some input from others using zOS OpenSSL. Calls like "ossl_isascii(c)" such as is done in "a_print.c" in method "int ASN1_PRINTABLE_type(const unsigned char *s, int len)" lead to wrong behavior for me on zOS if the input is ASCII (already). "ossl_isascii" leads to a call to "ossl_ctype_check" with the ASCII mask 'CTYPE_MASK_ascii'. However, the issue now occurs in there because inside "ossl_ctype_check" the function "ossl_toascii" is called. int ossl_ctype_check(int c, unsigned int mask) { const int max = sizeof(ctype_char_map) / sizeof(*ctype_char_map); const int a = ossl_toascii(c); return a >= 0 && a < max && (ctype_char_map[a] & mask) != 0; } "ossl_toascii" does convert the input to ASCII unless it is outside the range checked via: if (c < -128 || c > 256 || c == EOF) So a wrong conversion occurs when the input is ASCII as int/decimal values usually range from32-126, so they are not caught in any way by "ossl_toascii". When checking if the input is ASCII which it is (expected output '1' == true, is ASCII): the input ASCII chars are converted AGAIN to ASCII leading to a wrong/weird output and we get a wrong '0' output afterwards in "ossl_ctype_check" as 'a' is not ASCII anymore. There would have to be an input check like such that the conversion does not take place if the input is already in ASCII. But I don't know if this is possible easily. Also the EBCDIC space with integer value '64' would be troublesome... Did I miss something crucial or did I make a mistake? If so, please let me know. My next steps will be to try to refactor the "ossl_ctype_check" to not use "ossl_toascii" directly but to have some check beforehand. I am not sure if this will work everywhere and also the 'exceptions' such as EBCDIC space and so on need to be caught correctly. If somebody has already fixed this issue or has other ideas they are most welcome. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From stm at pdflib.com Tue Apr 14 08:14:33 2020 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Tue, 14 Apr 2020 10:14:33 +0200 Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <1586851240203-0.post@n7.nabble.com> References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> <1583335623698-0.post@n7.nabble.com> <36E03C4F-7A66-407B-A154-2E02F2C03021@akamai.com> <1583771390427-0.post@n7.nabble.com> <1586445565652-0.post@n7.nabble.com> <1586851240203-0.post@n7.nabble.com> Message-ID: Hello Kevin, Am 14.04.20 um 10:00 schrieb K Lengauer: > Dear all, > > I want to add another issue that occurred to me and would appreciate some > input from others using zOS OpenSSL. > > Calls like "ossl_isascii(c)" such as is done in "a_print.c" in method "int > ASN1_PRINTABLE_type(const unsigned char *s, int len)" lead to wrong behavior > for me on zOS if the input is ASCII (already). I think your observation is correct. There are multiple places in the code where the ossl_... character classification macros are applied to codes that are ASCII. I documented a similar problem in the following issue on GitHub: https://github.com/openssl/openssl/issues/11385 > "ossl_isascii" leads to a call to "ossl_ctype_check" with the ASCII mask > 'CTYPE_MASK_ascii'. However, the issue now occurs in there because inside > "ossl_ctype_check" the function "ossl_toascii" is called. > > int ossl_ctype_check(int c, unsigned int mask) > { > const int max = sizeof(ctype_char_map) / sizeof(*ctype_char_map); > const int a = ossl_toascii(c); > > return a >= 0 && a < max && (ctype_char_map[a] & mask) != 0; > } > > "ossl_toascii" does convert the input to ASCII unless it is outside the > range checked via: > > if (c < -128 || c > 256 || c == EOF) > > So a wrong conversion occurs when the input is ASCII as int/decimal values > usually range from32-126, so they are not caught in any way by > "ossl_toascii". When checking if the input is ASCII which it is (expected > output '1' == true, is ASCII): the input ASCII chars are converted AGAIN to > ASCII leading to a wrong/weird output and we get a wrong '0' output > afterwards in "ossl_ctype_check" as 'a' is not ASCII anymore. > > There would have to be an input check like such that the conversion does not > take place if the input is already in ASCII. But I don't know if this is > possible easily. Also the EBCDIC space with integer value '64' would be > troublesome... > > Did I miss something crucial or did I make a mistake? If so, please let me > know. > > My next steps will be to try to refactor the "ossl_ctype_check" to not use > "ossl_toascii" directly but to have some check beforehand. I am not sure if > this will work everywhere and also the 'exceptions' such as EBCDIC space and > so on need to be caught correctly. If somebody has already fixed this issue > or has other ideas they are most welcome. > > > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > -- Stephan From kevin.lengauer at adnovum.ch Tue Apr 14 12:57:12 2020 From: kevin.lengauer at adnovum.ch (K Lengauer) Date: Tue, 14 Apr 2020 05:57:12 -0700 (MST) Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: References: <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> <1583335623698-0.post@n7.nabble.com> <36E03C4F-7A66-407B-A154-2E02F2C03021@akamai.com> <1583771390427-0.post@n7.nabble.com> <1586445565652-0.post@n7.nabble.com> <1586851240203-0.post@n7.nabble.com> Message-ID: <1586869032133-0.post@n7.nabble.com> Hi Stephan, Thank you for your quick response and also the link to your github issue. I must have brushed over it when searching for similar issues, apologies. Anyway, this seems to further confirm the issue(s) at hand... Did you have any success or have you made any attempts at fixing this so far? I think we can not simply change the usage of "ossl_isacii" but also need to adjust "ossl_ctype_check" for the -DCHARSET_EBCDIC case because whenever the input is ASCII it will fail. This will be the case for all the functions that expect ASCII input and use "ossl_ctype_check" for sure but might occur for many more. I am still trying to get some own ASCII check to work to ensure "ossl_toascii" is only run when the input is not already ASCII. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From matt at openssl.org Tue Apr 14 13:23:40 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Apr 2020 14:23:40 +0100 Subject: Forthcoming OpenSSL Release Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1g. This release will be made available on Tuesday 21st April 2020 between 1300-1700 UTC. OpenSSL 1.1.g is a security-fix release. The highest severity issue fixed in this release is HIGH: https://www.openssl.org/policies/secpolicy.html#high Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6VuVwACgkQ2cTSbQ5g RJEGGwgAnvbo6LVTEz8PdAOoKPgHiz1ObbB8M/fNANk1Oog1w6CF7a8JPEuB/LlQ ZS0/31x+69xE+GzD4kPBglG6IVnt7F1mlXSc1YEh5c5zs2T5w5Gak5AIzJNZqEFK EmplFS8eZCpKJZc+0YKgMisF4Q+VbRjI+KVtYQKBn3sHRNH04z4Ti6jlS14R4pQd PCB4ftXS/LnISkrxL1uVf1seY+5SpmQjk3FR8ZgrR3vuYAyLcD7aeQNKf+unsS4W u8VnDmqONHa2JfHjsr5PezLZfWa3YTvK352gamyq5sn6y2ciTcI+fABeSD4OYjvQ I6t4kQrzfCdMrBNY8G2D5NYOi5cOKQ== =5CII -----END PGP SIGNATURE----- From sri.deep07 at gmail.com Wed Apr 15 00:00:45 2020 From: sri.deep07 at gmail.com (Anand Sridharan) Date: Tue, 14 Apr 2020 17:00:45 -0700 Subject: TLS handshake failures Message-ID: Hi , we are trying to add tls support to socks proxy with Curl as part of that we are trying to complete initial TLS handshake. we are trying to run openssl s_server on loopback interface to verify changes we tried two methods both are resulting in fatal error alert from server. Method 1 - use existing api's used for http proxy but remove any conditions specific for HTTPS proxy.(wireshark: lo_sslversion.pcap) - SSL upgrade of existing socket using curl API?s curl_ssl_connect_nonblocking and curl_ssl_init_proxy for TLS handshake - Fatal alert: protocol version Method 2- use new SSL context init and add certificates/key manually, do simple ssl_connect on sockfd (wireshark: inverse_server_client_l0.pcap) - SSL_set_fd(ssl, sockfd) and SSL_connect(ssl) are used. - Fatal alert illegal parameter. Commands used: server: openssl s_server --accept 1080 -cert certificate1.pem -key key1.pem client: curl -v -g -k --proxy socks5://127.0.0.1:1080 https://www.google.com could you please help understand this error? -- thanks, Anand.S -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lo_sslversion.pcap Type: application/octet-stream Size: 8673 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inverse_server_client_l0.pcap Type: application/octet-stream Size: 9825 bytes Desc: not available URL: From stm at pdflib.com Wed Apr 15 06:50:48 2020 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Wed, 15 Apr 2020 08:50:48 +0200 Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <1586869032133-0.post@n7.nabble.com> References: <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> <1583335623698-0.post@n7.nabble.com> <36E03C4F-7A66-407B-A154-2E02F2C03021@akamai.com> <1583771390427-0.post@n7.nabble.com> <1586445565652-0.post@n7.nabble.com> <1586851240203-0.post@n7.nabble.com> <1586869032133-0.post@n7.nabble.com> Message-ID: <607094c9-3e79-3fc6-c76b-c1e4af3587be@pdflib.com> Am 14.04.20 um 14:57 schrieb K Lengauer: > Hi Stephan, > > Thank you for your quick response and also the link to your github issue. I > must have brushed over it when searching for similar issues, apologies. > Anyway, this seems to further confirm the issue(s) at hand... > Did you have any success or have you made any attempts at fixing this so > far? I needed a quick solution so I fixed this locally by adding some macros that operate directly on ASCII codes. > I think we can not simply change the usage of "ossl_isacii" but also need to > adjust "ossl_ctype_check" for the -DCHARSET_EBCDIC case because whenever the > input is ASCII it will fail. This will be the case for all the functions > that expect ASCII input and use "ossl_ctype_check" for sure but might occur > for many more. > I am still trying to get some own ASCII check to work to ensure > "ossl_toascii" is only run when the input is not already ASCII. My feeling is that a separate set of macros is needed that expect ASCII input independently from whether -DCHARSET_EBCDIC is set or not. -- Stephan From dfulger at gmx.com Wed Apr 15 07:38:33 2020 From: dfulger at gmx.com (Dan Fulger) Date: Wed, 15 Apr 2020 09:38:33 +0200 Subject: Problems porting Openssl 1.1.1d to zos. Message-ID: Yes, I encountered the same problem in my OS/400 port of OpenSSL 1.1.1. From junaid.mukhtar at gmail.com Wed Apr 15 15:57:49 2020 From: junaid.mukhtar at gmail.com (Junaid Mukhtar) Date: Wed, 15 Apr 2020 16:57:49 +0100 Subject: TLSv1 on CentOS-8 Message-ID: Hi Team I am trying to enable TLSv1 on CentOS-8. We don't have the ability to upgrade the server unfortunately so we need to enable TLSv1 with weak-ciphers on OpenSSL. I have tried to build the OpenSSL version manually using switches "./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl shared enable-weak-ssl-ciphers enable-deprecated enable-rc4 enable-tls1 zlib" which ran successfully [root at 2cb6477375aa openssl-OpenSSL_1_1_1c]# openssl version OpenSSL 1.1.1c 28 May 2019 But i am still not able to run the "openssl s_client -connect " command without specifying -tls1 in it. Build accepts the weak-ciphers but not the tls1 version. Can someone please help me with this? -------- Regards, Junaid -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Wed Apr 15 16:03:10 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 15 Apr 2020 18:03:10 +0200 Subject: TLSv1 on CentOS-8 In-Reply-To: References: Message-ID: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> On Wed, 2020-04-15 at 16:57 +0100, Junaid Mukhtar wrote: > Hi Team > > I am trying to enable TLSv1 on CentOS-8. We don't have the ability to > upgrade the server unfortunately so we need to enable TLSv1 with > weak-ciphers on OpenSSL. > > I have tried to build the OpenSSL version manually using switches > "./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl > shared enable-weak-ssl-ciphers enable-deprecated enable-rc4 enable- > tls1 zlib" which ran successfully > > [root at 2cb6477375aa openssl-OpenSSL_1_1_1c]# openssl version > OpenSSL 1.1.1c 28 May 2019 > > > But i am still not able to run the "openssl s_client -connect " > command without specifying -tls1 in it. Build accepts the weak- > ciphers but not the tls1 version. > > Can someone please help me with this? You should not need to recompile openssl or anything. Just run: update-crypto-policies --set LEGACY and restart the service that is supposed to be providing the TLS1 server or reboot the machine. The LEGACY crypto policy purpose is exactly for re-enabling some of the not-up-to-date protocols and crypto algorithms. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From junaid.mukhtar at gmail.com Wed Apr 15 16:13:16 2020 From: junaid.mukhtar at gmail.com (Junaid Mukhtar) Date: Wed, 15 Apr 2020 17:13:16 +0100 Subject: TLSv1 on CentOS-8 In-Reply-To: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> Message-ID: Thanks a lot; It really helped -------- Regards, Junaid On Wed, Apr 15, 2020 at 5:04 PM Tomas Mraz wrote: > On Wed, 2020-04-15 at 16:57 +0100, Junaid Mukhtar wrote: > > Hi Team > > > > I am trying to enable TLSv1 on CentOS-8. We don't have the ability to > > upgrade the server unfortunately so we need to enable TLSv1 with > > weak-ciphers on OpenSSL. > > > > I have tried to build the OpenSSL version manually using switches > > "./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl > > shared enable-weak-ssl-ciphers enable-deprecated enable-rc4 enable- > > tls1 zlib" which ran successfully > > > > [root at 2cb6477375aa openssl-OpenSSL_1_1_1c]# openssl version > > OpenSSL 1.1.1c 28 May 2019 > > > > > > But i am still not able to run the "openssl s_client -connect " > > command without specifying -tls1 in it. Build accepts the weak- > > ciphers but not the tls1 version. > > > > Can someone please help me with this? > > You should not need to recompile openssl or anything. > > Just run: > > update-crypto-policies --set LEGACY > > and restart the service that is supposed to be providing the TLS1 > server or reboot the machine. > > The LEGACY crypto policy purpose is exactly for re-enabling some of the > not-up-to-date protocols and crypto algorithms. > > -- > Tom?? Mr?z > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon.murphy1996 at protonmail.com Wed Apr 15 23:12:42 2020 From: brandon.murphy1996 at protonmail.com (brandon.murphy1996) Date: Wed, 15 Apr 2020 23:12:42 +0000 Subject: Add user-defined argument in TLS 1.3 External PSK callback Message-ID: <66H30-5KuS9OAqRCTrTTtEI2O1PQQeqAX_lPA0PKJWsOr7ZpVSSDdq9jjUEPOKsiplmee4oWDkpq9mvH6yshrVRc9pnqNqbiBZknUMHS6HI=@protonmail.com> Hi, For my project, I need to perform a external PSK mode TLS 1.3 handshake. As per the documentation, I am setting up a callback on client my SSL object using the following: SSL_set_psk_use_session_callback(ssl, psk_use_session_cb_func) and the callback's formal arguments are: typedef int (*SSL_psk_use_session_cb_func)(SSL *ssl, const EVP_MD *md, const unsigned char **id, size_t *idlen, SSL_SESSION **sess); Currently, the psk_use_session_cb_func() contains a hardcoded PSK and identity value. However, I want to send an extra argument (preferably a custom struct) to this callback that will contain the pre-shared key and identity (ideally read from a config file). Is there any way this can be achieved? PS: I also need to do it on the server using the find_session callback. Thanks, Brandon From matt at openssl.org Thu Apr 16 08:34:54 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 16 Apr 2020 09:34:54 +0100 Subject: Add user-defined argument in TLS 1.3 External PSK callback In-Reply-To: <66H30-5KuS9OAqRCTrTTtEI2O1PQQeqAX_lPA0PKJWsOr7ZpVSSDdq9jjUEPOKsiplmee4oWDkpq9mvH6yshrVRc9pnqNqbiBZknUMHS6HI=@protonmail.com> References: <66H30-5KuS9OAqRCTrTTtEI2O1PQQeqAX_lPA0PKJWsOr7ZpVSSDdq9jjUEPOKsiplmee4oWDkpq9mvH6yshrVRc9pnqNqbiBZknUMHS6HI=@protonmail.com> Message-ID: On 16/04/2020 00:12, brandon.murphy1996 via openssl-users wrote: > Currently, the psk_use_session_cb_func() contains a hardcoded PSK and > identity value. However, I want to send an extra argument (preferably > a custom struct) to this callback that will contain the pre-shared > key and identity (ideally read from a config file). Is there any way > this can be achieved? You could store "ex_data" on the SSL object using SSL_set_ex_data(): https://www.openssl.org/docs/man1.1.1/man3/SSL_set_ex_data.html Matt From root at c-works.net Thu Apr 16 13:42:59 2020 From: root at c-works.net (Harald Koch) Date: Thu, 16 Apr 2020 15:42:59 +0200 Subject: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new Message-ID: <2C849599-67EB-4F41-9B43-98E9C50E59BD@c-works.net> Hello list, I have a TLS server which is started on demand in a multithreaded (pthread) application. The TLS server is one thread which is being started and stopped. At first start, the TLS server initialized with SSL_CTX_new with TLS_server_method works as expected, after cleaning up, eliminating the thread and starting it again at a later time in the same process, SSL_CTX_new returns NULL. I?ve been digging deeper into the initialization code, and found out that in crypto/threads_pthread.c, function CRYPTO_THREAD_set_local the call to pthread_setspecific returns a value != 0 (in my case: 22). The error queue of openSSL stays empty. The same code works with openSSL 1.1.0 in all versions. Some posts googled state that before usage, be sure to run OPENSSL_init_ssl (which I do, even if not required to my analysis since it?s already called in one of the called functions deeper in the library). Am I missing something in a multithreaded environment? Regards, Harald From matt at openssl.org Thu Apr 16 14:29:40 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 16 Apr 2020 15:29:40 +0100 Subject: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new In-Reply-To: <2C849599-67EB-4F41-9B43-98E9C50E59BD@c-works.net> References: <2C849599-67EB-4F41-9B43-98E9C50E59BD@c-works.net> Message-ID: On 16/04/2020 14:42, Harald Koch wrote: > Hello list, > > I have a TLS server which is started on demand in a multithreaded (pthread) application. The TLS server is one thread which is being started and stopped. At first start, the TLS server initialized with SSL_CTX_new with TLS_server_method works as expected, after cleaning up, eliminating the thread and starting it again at a later time in the same process, SSL_CTX_new returns NULL. I?ve been digging deeper into the initialization code, and found out that in crypto/threads_pthread.c, function What does your clean up code look like? Are you taking specific steps to cleanup OpenSSL and if so what are they? Matt CRYPTO_THREAD_set_local the call to pthread_setspecific returns a value != 0 (in my case: 22). The error queue of openSSL stays empty. The same code works with openSSL 1.1.0 in all versions. > Some posts googled state that before usage, be sure to run OPENSSL_init_ssl (which I do, even if not required to my analysis since it?s already called in one of the called functions deeper in the library). > Am I missing something in a multithreaded environment? > > Regards, > Harald > From tim.j.culhane at gmail.com Thu Apr 16 14:35:50 2020 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Thu, 16 Apr 2020 15:35:50 +0100 Subject: building a PIC enabled version of openssl 1.0.2k on Sparc 10 Message-ID: <003601d613fc$5491b590$fdb520b0$@gmail.com> Hi, I'm building a PIC enabled shared library in my server which links against openssl 1.0.2k libssl.a library on Sparc 10. When compiling I see the below errors. I originally built the 1.0.2k version of openssl with the following configure arguments: ./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.0.2k --openssldir=/opt/openssl/1.0.2k -lrt -m64 Do I need to pass in the -fPIC flag as well, and if so how do I do that. I appended it to the end of the configure line I show above but there was no sign of PIC in any of the top level makefiles produced. Thanks, Tim gcc -shared -static-libgcc -m64 -o libsncrssl1.0-openssl1.0.x.so .objects/sha1_pic.o .objects/sha256_pic.o .objects/tls_openssl_pic.o .objects/olog_signature_pic.o .objects/utils_pic.o .objects/rsa_sha_pic.o .objects/rsa_sha1_pic.o .objects/rsa_sha256_pic.o .objects/ed25519_sha256_pic.o -L/opt/openssl/1.0.2k/lib -lssl -lcrypto ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_M44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_L44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .text (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_M44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .text (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_L44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .text (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_M44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_L44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_M44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_L44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_M44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_L44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_M44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_L44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_M44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_L44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_M44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_L44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_H44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_M44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object ld: fatal: relocation error: R_SPARC_L44: file /opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section): relocations based on the ABS44 coding model can not be used in building a shared object From root at c-works.net Thu Apr 16 14:38:52 2020 From: root at c-works.net (Harald Koch) Date: Thu, 16 Apr 2020 16:38:52 +0200 Subject: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new In-Reply-To: References: <2C849599-67EB-4F41-9B43-98E9C50E59BD@c-works.net> Message-ID: <3155835F-B25B-40AE-8BB8-D4D33D269324@c-works.net> Hi Matt, > Am 16.04.2020 um 16:29 schrieb Matt Caswell : > On 16/04/2020 14:42, Harald Koch wrote: >> Hello list, >> >> I have a TLS server which is started on demand in a multithreaded (pthread) application. The TLS server is one thread which is being started and stopped. At first start, the TLS server initialized with SSL_CTX_new with TLS_server_method works as expected, after cleaning up, eliminating the thread and starting it again at a later time in the same process, SSL_CTX_new returns NULL. I?ve been digging deeper into the initialization code, and found out that in crypto/threads_pthread.c, function > What does your clean up code look like? Are you taking specific steps to > cleanup OpenSSL and if so what are they? I?m checking if my actually used SSL and CTX are up, and if so, cleanup them before thread killing: if(ssl != NULL) { // assigned by SSL_new before SSL_free(ssl); ssl = NULL; } /* Free the SSL_CTX structure */ if(ctx != NULL) { // assigned by SSL_CTX_new before SSL_CTX_free(ctx); ctx = NULL; } No other openSSL specific cleanup functions are called. The functions documented in https://wiki.openssl.org/index.php/Library_Initialization#Cleanup are not called. > CRYPTO_THREAD_set_local the call to pthread_setspecific returns a value > != 0 (in my case: 22). The error queue of openSSL stays empty. The same > code works with openSSL 1.1.0 in all versions. >> Some posts googled state that before usage, be sure to run OPENSSL_init_ssl (which I do, even if not required to my analysis since it?s already called in one of the called functions deeper in the library). >> Am I missing something in a multithreaded environment? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Thu Apr 16 15:07:22 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 16 Apr 2020 17:07:22 +0200 Subject: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new In-Reply-To: <2C849599-67EB-4F41-9B43-98E9C50E59BD@c-works.net> References: <2C849599-67EB-4F41-9B43-98E9C50E59BD@c-works.net> Message-ID: <12a8e5fc70486d0a80b05ad780e279d42c982415.camel@redhat.com> On Thu, 2020-04-16 at 15:42 +0200, Harald Koch wrote: > Hello list, > > I have a TLS server which is started on demand in a multithreaded > (pthread) application. The TLS server is one thread which is being > started and stopped. At first start, the TLS server initialized with > SSL_CTX_new with TLS_server_method works as expected, after cleaning > up, eliminating the thread and starting it again at a later time in > the same process, SSL_CTX_new returns NULL. I?ve been digging deeper > into the initialization code, and found out that in > crypto/threads_pthread.c, function CRYPTO_THREAD_set_local the call > to pthread_setspecific returns a value != 0 (in my case: 22). The > error queue of openSSL stays empty. The same code works with openSSL > 1.1.0 in all versions. > Some posts googled state that before usage, be sure to run > OPENSSL_init_ssl (which I do, even if not required to my analysis > since it?s already called in one of the called functions deeper in > the library). > Am I missing something in a multithreaded environment? Is this pure old 1.1.1 version or a current release from the 1.1.1 branch (i.e. 1.1.1f)? Do you call the OPENSSL_init_ssl from the main thread or from the TLS server thread? -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From root at c-works.net Thu Apr 16 15:32:19 2020 From: root at c-works.net (Harald Koch) Date: Thu, 16 Apr 2020 17:32:19 +0200 Subject: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new In-Reply-To: <12a8e5fc70486d0a80b05ad780e279d42c982415.camel@redhat.com> References: <2C849599-67EB-4F41-9B43-98E9C50E59BD@c-works.net> <12a8e5fc70486d0a80b05ad780e279d42c982415.camel@redhat.com> Message-ID: <6EAC7CE7-581B-4E7C-B03E-3BA4D9AF5E05@c-works.net> > Am 16.04.2020 um 17:07 schrieb Tomas Mraz : > > On Thu, 2020-04-16 at 15:42 +0200, Harald Koch wrote: >> Hello list, >> >> I have a TLS server which is started on demand in a multithreaded >> (pthread) application. The TLS server is one thread which is being >> started and stopped. At first start, the TLS server initialized with >> SSL_CTX_new with TLS_server_method works as expected, after cleaning >> up, eliminating the thread and starting it again at a later time in >> the same process, SSL_CTX_new returns NULL. I?ve been digging deeper >> into the initialization code, and found out that in >> crypto/threads_pthread.c, function CRYPTO_THREAD_set_local the call >> to pthread_setspecific returns a value != 0 (in my case: 22). The >> error queue of openSSL stays empty. The same code works with openSSL >> 1.1.0 in all versions. >> Some posts googled state that before usage, be sure to run >> OPENSSL_init_ssl (which I do, even if not required to my analysis >> since it?s already called in one of the called functions deeper in >> the library). >> Am I missing something in a multithreaded environment? > > Is this pure old 1.1.1 version or a current release from the 1.1.1 > branch (i.e. 1.1.1f)? It?s 1.1.1f, also tested 1.1.1c. In 1.1.0t it works. I can test against other versions if you want to. As a speciality, I compile openSSL with gzip support (?./config enable-zlib ...?, for support of compressed SMIME contents in other application). > Do you call the OPENSSL_init_ssl from the main thread or from the TLS > server thread? I call it from the TLS server thread (created by pthread_create): if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL)) return; I tried to do it only once (instead of every started thread): no difference. In addition, I load random data via /dev/urandom (also tested only once or every time the server thread starts): RAND_load_file("/dev/urandom", 256); From tmraz at redhat.com Thu Apr 16 15:54:13 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 16 Apr 2020 17:54:13 +0200 Subject: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new In-Reply-To: <6EAC7CE7-581B-4E7C-B03E-3BA4D9AF5E05@c-works.net> References: <2C849599-67EB-4F41-9B43-98E9C50E59BD@c-works.net> <12a8e5fc70486d0a80b05ad780e279d42c982415.camel@redhat.com> <6EAC7CE7-581B-4E7C-B03E-3BA4D9AF5E05@c-works.net> Message-ID: On Thu, 2020-04-16 at 17:32 +0200, Harald Koch wrote: > > Am 16.04.2020 um 17:07 schrieb Tomas Mraz : > > > > On Thu, 2020-04-16 at 15:42 +0200, Harald Koch wrote: > > > Hello list, > > > > > > I have a TLS server which is started on demand in a multithreaded > > > (pthread) application. The TLS server is one thread which is > > > being > > > started and stopped. At first start, the TLS server initialized > > > with > > > SSL_CTX_new with TLS_server_method works as expected, after > > > cleaning > > > up, eliminating the thread and starting it again at a later time > > > in > > > the same process, SSL_CTX_new returns NULL. I?ve been digging > > > deeper > > > into the initialization code, and found out that in > > > crypto/threads_pthread.c, function CRYPTO_THREAD_set_local the > > > call > > > to pthread_setspecific returns a value != 0 (in my case: 22). The This is EINVAL - meaning most probably that the pthread_setspecific() is called on uninitialized key. > > > error queue of openSSL stays empty. The same code works with > > > openSSL > > > 1.1.0 in all versions. > > > Some posts googled state that before usage, be sure to run > > > OPENSSL_init_ssl (which I do, even if not required to my analysis > > > since it?s already called in one of the called functions deeper > > > in > > > the library). > > > Am I missing something in a multithreaded environment? > > > > Is this pure old 1.1.1 version or a current release from the 1.1.1 > > branch (i.e. 1.1.1f)? > It?s 1.1.1f, also tested 1.1.1c. In 1.1.0t it works. I can test > against other versions if you want to. As a speciality, I compile > openSSL with gzip support (?./config enable-zlib ...?, for support of > compressed SMIME contents in other application). > > > Do you call the OPENSSL_init_ssl from the main thread or from the > > TLS > > server thread? > > I call it from the TLS server thread (created by pthread_create): > > if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL)) > return; > I tried to do it only once (instead of every started thread): no > difference. I do not see how this error could really happen unless OPENSSL_cleanup() is called. Could you try to set a breakpoint on that function and see if it is somehow called inadvertently? > In addition, I load random data via /dev/urandom (also tested only > once or every time the server thread starts): > RAND_load_file("/dev/urandom", 256); That call should not be necessary. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From Michael.Wojcik at microfocus.com Thu Apr 16 17:16:04 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 16 Apr 2020 17:16:04 +0000 Subject: building a PIC enabled version of openssl 1.0.2k on Sparc 10 In-Reply-To: <003601d613fc$5491b590$fdb520b0$@gmail.com> References: <003601d613fc$5491b590$fdb520b0$@gmail.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > tim.j.culhane at gmail.com > Sent: Thursday, April 16, 2020 08:36 > > I'm building a PIC enabled shared library in my server which links against > openssl 1.0.2k libssl.a library on Sparc 10. > > When compiling I see the below errors. > > I originally built the 1.0.2k version of openssl with the following > configure arguments: > > ./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.0.2k > --openssldir=/opt/openssl/1.0.2k -lrt -m64 > > Do I need to pass in the -fPIC flag as well, and if so how do I do that. I believe you do, though our use case is different - we build OpenSSL as a PIC archive library, which we then linked into a shared object. If you're building OpenSSL as a shared object (well, a pair of shared objects, for libcrypto and libssl), then you may be able to do that with the appropriate Configure options. My teams have switched to 1.1.1, so I don't have a 1.0.2 build handy to check. > I appended it to the end of the configure line I show above but there > was no sign of PIC in any of the top level makefiles produced. For 1.0.2, we edited the Configure file. We kept a log of the purposes of our changes, and looked at the Configure diffs for each new 1.0.2 release so we could port the relevant changes back to our Configure. We haven't had to do that with 1.1.1; its Configure is more flexible. -- Michael Wojcik Distinguished Engineer, Micro Focus From root at c-works.net Thu Apr 16 19:41:23 2020 From: root at c-works.net (Harald Koch) Date: Thu, 16 Apr 2020 21:41:23 +0200 Subject: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new In-Reply-To: References: <2C849599-67EB-4F41-9B43-98E9C50E59BD@c-works.net> <12a8e5fc70486d0a80b05ad780e279d42c982415.camel@redhat.com> <6EAC7CE7-581B-4E7C-B03E-3BA4D9AF5E05@c-works.net> Message-ID: Am 16.04.2020 um 17:54 schrieb Tomas Mraz : > > error queue of openSSL stays empty. The same code works with >> openSSL with gzip support (?./config enable-zlib ...?, for support of >> compressed SMIME contents in other application). >> Do you call the OPENSSL_init_ssl from the main thread or from the >>> TLS >>> server thread? >> I call it from the TLS server thread (created by pthread_create): >> >> if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL)) >> return; >> I tried to do it only once (instead of every started thread): no >> difference. > I do not see how this error could really happen unless > OPENSSL_cleanup() is called. > > Could you try to set a breakpoint on that function and see if it is > somehow called inadvertently? gdb is actually unavailable, so I added a big ?printf? at the beginning of crypto/init.c, recompiled (even without zlib support as I?ve seen there?s much functionality in there), function OPENSSL_cleanup: it?s not called. I?m very sure OPENSSL_cleanup is not called. > In addition, I load random data via /dev/urandom (also tested only >> once or every time the server thread starts): >> RAND_load_file("/dev/urandom", 256); > That call should not be necessary. I removed it just in case it may have an influence. No better result. :( I have a workaround and possibly it?s the solution, I would like to have your valuable statement here: you asked where I call OPENSSL_init_ssl: it?s done in the thread for TLS server. When I initialize it earlier in the main thread, the subsequent generated (second) thread works as expected! Is this spooky or expected behaviour? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Thu Apr 16 20:17:36 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 16 Apr 2020 13:17:36 -0700 Subject: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new In-Reply-To: References: <2C849599-67EB-4F41-9B43-98E9C50E59BD@c-works.net> <12a8e5fc70486d0a80b05ad780e279d42c982415.camel@redhat.com> <6EAC7CE7-581B-4E7C-B03E-3BA4D9AF5E05@c-works.net> Message-ID: <20200416201735.GT3811@akamai.com> On Thu, Apr 16, 2020 at 09:41:23PM +0200, Harald Koch wrote: > Am 16.04.2020 um 17:54 schrieb Tomas Mraz : > > > > error queue of openSSL stays empty. The same code works with > >> openSSL with gzip support (?./config enable-zlib ...?, for support of > >> compressed SMIME contents in other application). > >> Do you call the OPENSSL_init_ssl from the main thread or from the > >>> TLS > >>> server thread? > >> I call it from the TLS server thread (created by pthread_create): > >> > >> if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL)) > >> return; > >> I tried to do it only once (instead of every started thread): no > >> difference. > > I do not see how this error could really happen unless > > OPENSSL_cleanup() is called. > > > > Could you try to set a breakpoint on that function and see if it is > > somehow called inadvertently? > gdb is actually unavailable, so I added a big ?printf? at the beginning of crypto/init.c, recompiled (even without zlib support as I?ve seen there?s much functionality in there), function OPENSSL_cleanup: it?s not called. I?m very sure OPENSSL_cleanup is not called. > > > In addition, I load random data via /dev/urandom (also tested only > >> once or every time the server thread starts): > >> RAND_load_file("/dev/urandom", 256); > > That call should not be necessary. > I removed it just in case it may have an influence. No better result. :( > > > I have a workaround and possibly it?s the solution, I would like to have your valuable statement here: you asked where I call OPENSSL_init_ssl: it?s done in the thread for TLS server. When I initialize it earlier in the main thread, the subsequent generated (second) thread works as expected! Is this spooky or expected behaviour? Just to check: what OS is this on? -Ben From root at c-works.net Thu Apr 16 20:26:50 2020 From: root at c-works.net (Harald Koch) Date: Thu, 16 Apr 2020 22:26:50 +0200 Subject: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new In-Reply-To: <20200416201735.GT3811@akamai.com> References: <2C849599-67EB-4F41-9B43-98E9C50E59BD@c-works.net> <12a8e5fc70486d0a80b05ad780e279d42c982415.camel@redhat.com> <6EAC7CE7-581B-4E7C-B03E-3BA4D9AF5E05@c-works.net> <20200416201735.GT3811@akamai.com> Message-ID: <8B57F7C2-D78F-43E2-8FF1-B267E07F74B7@c-works.net> > Am 16.04.2020 um 22:17 schrieb Benjamin Kaduk : > > On Thu, Apr 16, 2020 at 09:41:23PM +0200, Harald Koch wrote: >> Am 16.04.2020 um 17:54 schrieb Tomas Mraz : >>> >>> error queue of openSSL stays empty. The same code works with >>>> openSSL with gzip support (?./config enable-zlib ...?, for support of >>>> compressed SMIME contents in other application). >>>> Do you call the OPENSSL_init_ssl from the main thread or from the >>>>> TLS >>>>> server thread? >>>> I call it from the TLS server thread (created by pthread_create): >>>> >>>> if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL)) >>>> return; >>>> I tried to do it only once (instead of every started thread): no >>>> difference. >>> I do not see how this error could really happen unless >>> OPENSSL_cleanup() is called. >>> >>> Could you try to set a breakpoint on that function and see if it is >>> somehow called inadvertently? >> gdb is actually unavailable, so I added a big ?printf? at the beginning of crypto/init.c, recompiled (even without zlib support as I?ve seen there?s much functionality in there), function OPENSSL_cleanup: it?s not called. I?m very sure OPENSSL_cleanup is not called. >> >>> In addition, I load random data via /dev/urandom (also tested only >>>> once or every time the server thread starts): >>>> RAND_load_file("/dev/urandom", 256); >>> That call should not be necessary. >> I removed it just in case it may have an influence. No better result. :( >> >> >> I have a workaround and possibly it?s the solution, I would like to have your valuable statement here: you asked where I call OPENSSL_init_ssl: it?s done in the thread for TLS server. When I initialize it earlier in the main thread, the subsequent generated (second) thread works as expected! Is this spooky or expected behaviour? > > Just to check: what OS is this on? Linux x86-64. Every Debian from 7 to 10 tested. From birdnofoots at gmail.com Fri Apr 17 05:52:06 2020 From: birdnofoots at gmail.com (Justin Chen) Date: Fri, 17 Apr 2020 13:52:06 +0800 Subject: Updated openssl 1.1.1f installation problem: Parse errors: No plan found in TAP output Message-ID: <68572F2D-012E-45D5-8EB7-2443F60C764A@gmail.com> Is there anyone meets the same Failure like me? Pls help me. The installation steps list below. [birdnofoots at trojan openssl-1.1.1f]$ cat /proc/version Linux version 4.14.129-bbrplus (root at vultr.guest ) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)) #1 SMP Tue Jun 25 12:23:41 UTC 2019 [birdnofoots at trojan openssl-1.1.1f]$ openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 [birdnofoots at trojan openssl-1.1.1f]$ perl --version This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi (with 39 registered patches, see perl -V for more detail) Copyright 1987-2012, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/ , the Perl Home Page. [birdnofoots at trojan openssl-1.1.1f]$ ls ACKNOWLEDGEMENTS AUTHORS config Configurations crypto engines FAQ INSTALL ms NOTES.DJGPP NOTES.VMS README ssl util apps build.info config.com Configure demos e_os.h fuzz LICENSE NEWS NOTES.PERL NOTES.WIN README.ENGINE test VMS appveyor.yml CHANGES configdata.pm CONTRIBUTING doc external include Makefile NOTES.ANDROID NOTES.UNIX os-dep README.FIPS tools [birdnofoots at trojan openssl-1.1.1f]$ sudo ./config Operating system: x86_64-whatever-linux2 Configuring OpenSSL version 1.1.1f (0x1010106fL) for linux-x86_64 Using os-specific seed configuration Creating configdata.pm Creating Makefile ********************************************************************** *** *** *** OpenSSL has been successfully configured *** *** *** *** If you encounter a problem while building, please open an *** *** issue on GitHub > *** *** and include the output from the following command: *** *** *** *** perl configdata.pm --dump *** *** *** *** (If you are new to OpenSSL, you might want to consult the *** *** 'Troubleshooting' section in the INSTALL file first) *** *** *** ********************************************************************** [birdnofoots at trojan openssl-1.1.1f]$ sudo make test /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \ "-oMakefile" include/crypto/bn_conf.h.in > include/crypto/bn_conf.h /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \ "-oMakefile" include/crypto/dso_conf.h.in > include/crypto/dso_conf.h /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \ "-oMakefile" include/openssl/opensslconf.h.in > include/openssl/opensslconf.h make depend && make _tests make[1]: Entering directory `/home/birdnofoots/openssl-1.1.1f' make[1]: Leaving directory `/home/birdnofoots/openssl-1.1.1f' make[1]: Entering directory `/home/birdnofoots/openssl-1.1.1f' /usr/bin/perl apps/progs.pl apps/openssl > apps/progs.h ?. ?. ./test/recipes/90-test_sysdefault.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_threads.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_time_offset.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_tls13ccs.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_tls13encryption.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_tls13secrets.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_v3name.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/95-test_external_boringssl.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/95-test_external_krb5.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/95-test_external_pyca.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/99-test_ecstress.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/99-test_fuzz.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output Files=155, Tests=0, 8 wallclock secs ( 2.33 usr 0.93 sys + 2.73 cusr 1.63 csys = 7.62 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make[1]: Leaving directory `/home/birdnofoots/openssl-1.1.1f' make: *** [tests] Error 2 Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From birdnofoots at gmail.com Fri Apr 17 05:52:45 2020 From: birdnofoots at gmail.com (Justin Chen) Date: Fri, 17 Apr 2020 13:52:45 +0800 Subject: Updated openssl 1.1.1f installation problem: Parse errors: No plan found in TAP output Message-ID: Is there anyone meets the same Failure like me? Pls help me. The installation steps list below. [birdnofoots at trojan openssl-1.1.1f]$ cat /proc/version Linux version 4.14.129-bbrplus (root at vultr.guest ) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)) #1 SMP Tue Jun 25 12:23:41 UTC 2019 [birdnofoots at trojan openssl-1.1.1f]$ openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 [birdnofoots at trojan openssl-1.1.1f]$ perl --version This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi (with 39 registered patches, see perl -V for more detail) Copyright 1987-2012, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/ , the Perl Home Page. [birdnofoots at trojan openssl-1.1.1f]$ ls ACKNOWLEDGEMENTS AUTHORS config Configurations crypto engines FAQ INSTALL ms NOTES.DJGPP NOTES.VMS README ssl util apps build.info config.com Configure demos e_os.h fuzz LICENSE NEWS NOTES.PERL NOTES.WIN README.ENGINE test VMS appveyor.yml CHANGES configdata.pm CONTRIBUTING doc external include Makefile NOTES.ANDROID NOTES.UNIX os-dep README.FIPS tools [birdnofoots at trojan openssl-1.1.1f]$ sudo ./config Operating system: x86_64-whatever-linux2 Configuring OpenSSL version 1.1.1f (0x1010106fL) for linux-x86_64 Using os-specific seed configuration Creating configdata.pm Creating Makefile ********************************************************************** *** *** *** OpenSSL has been successfully configured *** *** *** *** If you encounter a problem while building, please open an *** *** issue on GitHub > *** *** and include the output from the following command: *** *** *** *** perl configdata.pm --dump *** *** *** *** (If you are new to OpenSSL, you might want to consult the *** *** 'Troubleshooting' section in the INSTALL file first) *** *** *** ********************************************************************** [birdnofoots at trojan openssl-1.1.1f]$ sudo make test /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \ "-oMakefile" include/crypto/bn_conf.h.in > include/crypto/bn_conf.h /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \ "-oMakefile" include/crypto/dso_conf.h.in > include/crypto/dso_conf.h /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \ "-oMakefile" include/openssl/opensslconf.h.in > include/openssl/opensslconf.h make depend && make _tests make[1]: Entering directory `/home/birdnofoots/openssl-1.1.1f' make[1]: Leaving directory `/home/birdnofoots/openssl-1.1.1f' make[1]: Entering directory `/home/birdnofoots/openssl-1.1.1f' /usr/bin/perl apps/progs.pl apps/openssl > apps/progs.h ?. ?. ./test/recipes/90-test_sysdefault.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_threads.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_time_offset.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_tls13ccs.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_tls13encryption.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_tls13secrets.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/90-test_v3name.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/95-test_external_boringssl.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/95-test_external_krb5.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/95-test_external_pyca.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/99-test_ecstress.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output ../test/recipes/99-test_fuzz.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output Files=155, Tests=0, 8 wallclock secs ( 2.33 usr 0.93 sys + 2.73 cusr 1.63 csys = 7.62 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make[1]: Leaving directory `/home/birdnofoots/openssl-1.1.1f' make: *** [tests] Error 2 Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From junaid.mukhtar at gmail.com Fri Apr 17 14:39:31 2020 From: junaid.mukhtar at gmail.com (Junaid Mukhtar) Date: Fri, 17 Apr 2020 15:39:31 +0100 Subject: TLSv1 on CentOS-8 In-Reply-To: References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> Message-ID: Hi Tomas Is it possible to enable legacy protocols/ciphers but disable only one. In particular we want RC4-SHA to be disable -------- Regards, Junaid On Wed, Apr 15, 2020 at 5:13 PM Junaid Mukhtar wrote: > Thanks a lot; It really helped > > -------- > Regards, > Junaid > > > On Wed, Apr 15, 2020 at 5:04 PM Tomas Mraz wrote: > >> On Wed, 2020-04-15 at 16:57 +0100, Junaid Mukhtar wrote: >> > Hi Team >> > >> > I am trying to enable TLSv1 on CentOS-8. We don't have the ability to >> > upgrade the server unfortunately so we need to enable TLSv1 with >> > weak-ciphers on OpenSSL. >> > >> > I have tried to build the OpenSSL version manually using switches >> > "./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl >> > shared enable-weak-ssl-ciphers enable-deprecated enable-rc4 enable- >> > tls1 zlib" which ran successfully >> > >> > [root at 2cb6477375aa openssl-OpenSSL_1_1_1c]# openssl version >> > OpenSSL 1.1.1c 28 May 2019 >> > >> > >> > But i am still not able to run the "openssl s_client -connect " >> > command without specifying -tls1 in it. Build accepts the weak- >> > ciphers but not the tls1 version. >> > >> > Can someone please help me with this? >> >> You should not need to recompile openssl or anything. >> >> Just run: >> >> update-crypto-policies --set LEGACY >> >> and restart the service that is supposed to be providing the TLS1 >> server or reboot the machine. >> >> The LEGACY crypto policy purpose is exactly for re-enabling some of the >> not-up-to-date protocols and crypto algorithms. >> >> -- >> Tom?? Mr?z >> No matter how far down the wrong road you've gone, turn back. >> Turkish proverb >> [You'll know whether the road is wrong if you carefully listen to your >> conscience.] >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Fri Apr 17 15:17:47 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 17 Apr 2020 17:17:47 +0200 Subject: TLSv1 on CentOS-8 In-Reply-To: References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> Message-ID: <5d0125b4e2b625ecf5de73ff7f676b3cab4b9d8b.camel@redhat.com> It will be possible via Custom crypto policies in 8.2 release. It can be solved only in a hackish way on 8.1. You can manually edit /etc/crypto-policies/back-ends/openssl*.config files however that will not survive further runs of update-crypto- policies or package updates. Or you could modify the /etc/pki/tls/openssl.cnf: Find the .include /etc/crypto-policies/back-ends/opensslcnf.config line in it and insert something like: CipherString = @SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!DES:!RC2:!RC4:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 after that include line. This will override the policy. However then it will be overridden even after you switch the system to another mode or if you update the system and new policy (with adjustments and fixes) is provided in the updated packages. Regards, Tomas On Fri, 2020-04-17 at 15:39 +0100, Junaid Mukhtar wrote: > Hi Tomas > > Is it possible to enable legacy protocols/ciphers but disable only > one. In particular we want RC4-SHA to be disable > > -------- > Regards, > Junaid > > > On Wed, Apr 15, 2020 at 5:13 PM Junaid Mukhtar < > junaid.mukhtar at gmail.com> wrote: > > Thanks a lot; It really helped > > > > -------- > > Regards, > > Junaid > > > > > > On Wed, Apr 15, 2020 at 5:04 PM Tomas Mraz > > wrote: > > > On Wed, 2020-04-15 at 16:57 +0100, Junaid Mukhtar wrote: > > > > Hi Team > > > > > > > > I am trying to enable TLSv1 on CentOS-8. We don't have the > > > ability to > > > > upgrade the server unfortunately so we need to enable TLSv1 > > > with > > > > weak-ciphers on OpenSSL. > > > > > > > > I have tried to build the OpenSSL version manually using > > > switches > > > > "./config --prefix=/usr/local/openssl -- > > > openssldir=/usr/local/openssl > > > > shared enable-weak-ssl-ciphers enable-deprecated enable-rc4 > > > enable- > > > > tls1 zlib" which ran successfully > > > > > > > > [root at 2cb6477375aa openssl-OpenSSL_1_1_1c]# openssl version > > > > OpenSSL 1.1.1c 28 May 2019 > > > > > > > > > > > > But i am still not able to run the "openssl s_client -connect " > > > > command without specifying -tls1 in it. Build accepts the weak- > > > > ciphers but not the tls1 version. > > > > > > > > Can someone please help me with this? > > > > > > You should not need to recompile openssl or anything. > > > > > > Just run: > > > > > > update-crypto-policies --set LEGACY > > > > > > and restart the service that is supposed to be providing the TLS1 > > > server or reboot the machine. > > > > > > The LEGACY crypto policy purpose is exactly for re-enabling some > > > of the > > > not-up-to-date protocols and crypto algorithms. > > > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From aerowolf at gmail.com Fri Apr 17 15:55:55 2020 From: aerowolf at gmail.com (Kyle Hamilton) Date: Fri, 17 Apr 2020 10:55:55 -0500 Subject: TLSv1 on CentOS-8 In-Reply-To: References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> Message-ID: Note: This is better asked on the CentOS support forums, since it asks about changes that CentOS made to OpenSSL. This is an unsupported configuration, and will be overwritten if you audit or reinstall the crypto-policies package. Also, I haven't looked to see where /etc/crypto-policies/back-ends/opensslcnf.config versus /etc/crypto-policies/back-ends/openssl.config are used. Since you're modifying the LEGACY policy (and the files in /etc/crypto-policies/back-ends/ are all symlinks, and I don't want to give information that would modify any security level without regard for knowing what security level is currenty in place): You want to modify the /usr/share/crypto-policies/LEGACY/openssl.txt file to append ":!RC4" to it. You should also modify /usr/share/crypto-policies/LEGACY/opensslcnf.txt to append ":!RC4" to the CipherString line, and ":!RC4-SHA" to the Ciphersuites line. There are additional files in there that refer to other services and crypto libraries, that you may wish to change as well. The OpenSSL support lists don't have any information about them. -Kyle H On Fri, Apr 17, 2020, 09:40 Junaid Mukhtar wrote: > Hi Tomas > > Is it possible to enable legacy protocols/ciphers but disable only one. In > particular we want RC4-SHA to be disable > > -------- > Regards, > Junaid > > > On Wed, Apr 15, 2020 at 5:13 PM Junaid Mukhtar > wrote: > >> Thanks a lot; It really helped >> >> -------- >> Regards, >> Junaid >> >> >> On Wed, Apr 15, 2020 at 5:04 PM Tomas Mraz wrote: >> >>> On Wed, 2020-04-15 at 16:57 +0100, Junaid Mukhtar wrote: >>> > Hi Team >>> > >>> > I am trying to enable TLSv1 on CentOS-8. We don't have the ability to >>> > upgrade the server unfortunately so we need to enable TLSv1 with >>> > weak-ciphers on OpenSSL. >>> > >>> > I have tried to build the OpenSSL version manually using switches >>> > "./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl >>> > shared enable-weak-ssl-ciphers enable-deprecated enable-rc4 enable- >>> > tls1 zlib" which ran successfully >>> > >>> > [root at 2cb6477375aa openssl-OpenSSL_1_1_1c]# openssl version >>> > OpenSSL 1.1.1c 28 May 2019 >>> > >>> > >>> > But i am still not able to run the "openssl s_client -connect " >>> > command without specifying -tls1 in it. Build accepts the weak- >>> > ciphers but not the tls1 version. >>> > >>> > Can someone please help me with this? >>> >>> You should not need to recompile openssl or anything. >>> >>> Just run: >>> >>> update-crypto-policies --set LEGACY >>> >>> and restart the service that is supposed to be providing the TLS1 >>> server or reboot the machine. >>> >>> The LEGACY crypto policy purpose is exactly for re-enabling some of the >>> not-up-to-date protocols and crypto algorithms. >>> >>> -- >>> Tom?? Mr?z >>> No matter how far down the wrong road you've gone, turn back. >>> Turkish proverb >>> [You'll know whether the road is wrong if you carefully listen to your >>> conscience.] >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Apr 17 17:03:18 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 17 Apr 2020 13:03:18 -0400 Subject: TLSv1 on CentOS-8 In-Reply-To: <5d0125b4e2b625ecf5de73ff7f676b3cab4b9d8b.camel@redhat.com> References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> <5d0125b4e2b625ecf5de73ff7f676b3cab4b9d8b.camel@redhat.com> Message-ID: <20200417170318.GC41308@straasha.imrryr.org> On Fri, Apr 17, 2020 at 05:17:47PM +0200, Tomas Mraz wrote: > Or you could modify the /etc/pki/tls/openssl.cnf: > Find the .include /etc/crypto-policies/back-ends/opensslcnf.config > line in it and insert something like: > > CipherString = @SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!DES:!RC2:!RC4:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 How did this particular contraption become a recommended cipherlist? What's wrong with "DEFAULT"? In OpenSSL 1.1.1 it already excludes RC4 (if RC4 is at all enabled at compile time): $ openssl ciphers -v 'COMPLEMENTOFDEFAULT+RC4' ECDHE-ECDSA-RC4-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDHE-RSA-RC4-SHA TLSv1 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 I find too many people cargo-culting poorly thought cipher lists from some random HOWTO. Over optimising your cipherlist is subject to rapid bitrot, resist the temptation... -- Viktor. From junaid.mukhtar at gmail.com Fri Apr 17 17:06:56 2020 From: junaid.mukhtar at gmail.com (Junaid Mukhtar) Date: Fri, 17 Apr 2020 18:06:56 +0100 Subject: TLSv1 on CentOS-8 In-Reply-To: <20200417170318.GC41308@straasha.imrryr.org> References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> <5d0125b4e2b625ecf5de73ff7f676b3cab4b9d8b.camel@redhat.com> <20200417170318.GC41308@straasha.imrryr.org> Message-ID: Hi, we have a requirement to enable tlsv1 for an edge case. When we enable that via Tomas recommendation it enables rc4 cipher. We want to disable rc4 but keep tlsv1 and that's why the ask for the process Thanks, On Fri, 17 Apr 2020 at 18:04, Viktor Dukhovni wrote: > On Fri, Apr 17, 2020 at 05:17:47PM +0200, Tomas Mraz wrote: > > > Or you could modify the /etc/pki/tls/openssl.cnf: > > Find the .include /etc/crypto-policies/back-ends/opensslcnf.config > > line in it and insert something like: > > > > CipherString = > @SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!DES:!RC2:!RC4:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 > > How did this particular contraption become a recommended cipherlist? > What's wrong with "DEFAULT"? In OpenSSL 1.1.1 it already excludes > RC4 (if RC4 is at all enabled at compile time): > > $ openssl ciphers -v 'COMPLEMENTOFDEFAULT+RC4' > ECDHE-ECDSA-RC4-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=RC4(128) > Mac=SHA1 > ECDHE-RSA-RC4-SHA TLSv1 Kx=ECDH Au=RSA Enc=RC4(128) > Mac=SHA1 > RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) > Mac=SHA1 > > I find too many people cargo-culting poorly thought cipher lists from > some random HOWTO. Over optimising your cipherlist is subject to > rapid bitrot, resist the temptation... > > -- > Viktor. > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Apr 17 17:17:25 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 17 Apr 2020 13:17:25 -0400 Subject: TLSv1 on CentOS-8 In-Reply-To: References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> <5d0125b4e2b625ecf5de73ff7f676b3cab4b9d8b.camel@redhat.com> <20200417170318.GC41308@straasha.imrryr.org> Message-ID: <20200417171725.GD41308@straasha.imrryr.org> On Fri, Apr 17, 2020 at 06:06:56PM +0100, Junaid Mukhtar wrote: > Hi, we have a requirement to enable tlsv1 for an edge case. When we enable > that via Tomas recommendation it enables rc4 cipher. Yes, but in OpenSSL 1.1.1, it is not clear why enabling the protocol has any impact on the cipher selection. These are separate concernts in the underlying OpenSSL library. The "DEFAULT" cipherlist does not include RC4. If the CentOS policies for enabling TLS 1.0 also have the side effect of enabling weak ciphers, set the cipherlist back to "DEFAULT", which for TLS 1.0 includes only: $ openssl ciphers -s -tls1 -v DEFAULT ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 -- Viktor. From tmraz at redhat.com Fri Apr 17 17:22:13 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 17 Apr 2020 19:22:13 +0200 Subject: TLSv1 on CentOS-8 In-Reply-To: <20200417170318.GC41308@straasha.imrryr.org> References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> <5d0125b4e2b625ecf5de73ff7f676b3cab4b9d8b.camel@redhat.com> <20200417170318.GC41308@straasha.imrryr.org> Message-ID: On Fri, 2020-04-17 at 13:03 -0400, Viktor Dukhovni wrote: > On Fri, Apr 17, 2020 at 05:17:47PM +0200, Tomas Mraz wrote: > > > Or you could modify the /etc/pki/tls/openssl.cnf: > > Find the .include /etc/crypto-policies/back-ends/opensslcnf.config > > line in it and insert something like: > > > > CipherString = > > @SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!DES:!RC2:!RC4: > > !IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 > > How did this particular contraption become a recommended cipherlist? To explain - this is basically autogenerated value from the crypto policy definiton of the LEGACY crypto policy with just added the !RC4. > What's wrong with "DEFAULT"? In OpenSSL 1.1.1 it already excludes > RC4 (if RC4 is at all enabled at compile time): Nothing wrong with DEFAULT. For manual configuration. This is however something that is autogenerated. > $ openssl ciphers -v 'COMPLEMENTOFDEFAULT+RC4' > ECDHE-ECDSA-RC4-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=RC4(128) > Mac=SHA1 > ECDHE-RSA-RC4-SHA TLSv1 > Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 > RC4-SHA SSLv3 > Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 > > I find too many people cargo-culting poorly thought cipher lists from > some random HOWTO. Over optimising your cipherlist is subject to > rapid bitrot, resist the temptation... Yeah, I should have probably suggested just: CipherString = DEFAULT There is not much point in being as close to the autogenerated policy as possible for this particular user's use-case. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From skappen at mvista.com Sat Apr 18 23:50:14 2020 From: skappen at mvista.com (Sam Kappen) Date: Sun, 19 Apr 2020 05:20:14 +0530 Subject: Removing tls1 support in Openssl 1.0.2o Message-ID: Hi We are using a poky with branch "rocko" based build system. Looking for disabling sslv3 tlsv1 on openssl.(Openssl 1.0.2o) I am seeing SSLv3 support in Openssl 1.0.2o is disabled by default. This patch is already part of our build system. https://patchwork.openembedded.org/patch/88921/ For disabling tls1 tried with EXTRA_OECONF = " -no-ssl3 -no-tls1" but seems like all of the tls1, tls1_1, tls1_2 are disabled. Request your help in disabling the protocol tls1 in openssl. Regards, Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at foocrypt.net Sun Apr 19 06:10:33 2020 From: openssl at foocrypt.net (FooCrypt) Date: Sun, 19 Apr 2020 16:10:33 +1000 Subject: Removing tls1 support in Openssl 1.0.2o In-Reply-To: References: Message-ID: Hi Sam Did you try : openssl-1.0.2u.tar.gz : Configuring for Usage: Configure [no- ...] [enable- ...] [experimental- ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [sctp] [386] [--prefix=DIR] [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags] pick os/compiler from: BC-32 BS2000-OSD BSD-generic32 BSD-generic64 BSD-ia64 BSD-sparc64 BSD-sparcv8 BSD-x86 BSD-x86-elf BSD-x86_64 Cygwin Cygwin-x86_64 DJGPP MPE/iX-gcc OS2-EMX OS390-Unix QNX6 QNX6-i386 ReliantUNIX SINIX SINIX-N UWIN VC-CE VC-WIN32 VC-WIN64A VC-WIN64I aix-cc aix-gcc aix3-cc aix64-cc aix64-gcc android android-armv7 android-mips android-x86 android64-aarch64 aux3-gcc beos-x86-bone beos-x86-r5 bsdi-elf-gcc cc cray-j90 cray-t3e darwin-i386-cc darwin-ppc-cc darwin64-ppc-cc darwin64-x86_64-cc dgux-R3-gcc dgux-R4-gcc dgux-R4-x86-gcc dist gcc hpux-cc hpux-gcc hpux-ia64-cc hpux-ia64-gcc hpux-parisc-cc hpux-parisc-cc-o4 hpux-parisc-gcc hpux-parisc1_1-cc hpux-parisc1_1-gcc hpux-parisc2-cc hpux-parisc2-gcc hpux64-ia64-cc hpux64-ia64-gcc hpux64-parisc2-cc hpux64-parisc2-gcc hurd-x86 iphoneos-cross irix-cc irix-gcc irix-mips3-cc irix-mips3-gcc irix64-mips4-cc irix64-mips4-gcc linux-aarch64 linux-alpha+bwx-ccc linux-alpha+bwx-gcc linux-alpha-ccc linux-alpha-gcc linux-aout linux-armv4 linux-elf linux-generic32 linux-generic64 linux-ia32-icc linux-ia64 linux-ia64-icc linux-mips32 linux-mips64 linux-ppc linux-ppc64 linux-ppc64le linux-sparcv8 linux-sparcv9 linux-x32 linux-x86_64 linux-x86_64-clang linux-x86_64-icc linux32-s390x linux64-mips64 linux64-s390x linux64-sparcv9 mingw mingw64 ncr-scde netware-clib netware-clib-bsdsock netware-clib-bsdsock-gcc netware-clib-gcc netware-libc netware-libc-bsdsock netware-libc-bsdsock-gcc netware-libc-gcc newsos4-gcc nextstep nextstep3.3 osf1-alpha-cc osf1-alpha-gcc purify qnx4 rhapsody-ppc-cc sco5-cc sco5-gcc solaris-sparcv7-cc solaris-sparcv7-gcc solaris-sparcv8-cc solaris-sparcv8-gcc solaris-sparcv9-cc solaris-sparcv9-gcc solaris-x86-cc solaris-x86-gcc solaris64-sparcv9-cc solaris64-sparcv9-gcc solaris64-x86_64-cc solaris64-x86_64-gcc sunos-gcc tandem-c89 tru64-alpha-cc uClinux-dist uClinux-dist64 ultrix-cc ultrix-gcc unixware-2.0 unixware-2.1 unixware-7 unixware-7-gcc vos-gcc vxworks-mips vxworks-ppc405 vxworks-ppc60x vxworks-ppc750 vxworks-ppc750-debug vxworks-ppc860 vxworks-ppcgen vxworks-simlinux debug debug-BSD-x86-elf debug-VC-WIN32 debug-VC-WIN64A debug-VC-WIN64I debug-ben debug-ben-darwin64 debug-ben-debug debug-ben-debug-64 debug-ben-debug-64-clang debug-ben-macos debug-ben-macos-gcc46 debug-ben-no-opt debug-ben-openbsd debug-ben-openbsd-debug debug-ben-strict debug-bodo debug-darwin-i386-cc debug-darwin-ppc-cc debug-darwin64-x86_64-cc debug-geoff32 debug-geoff64 debug-levitte-linux-elf debug-levitte-linux-elf-extreme debug-levitte-linux-noasm debug-levitte-linux-noasm-extreme debug-linux-elf debug-linux-elf-noefence debug-linux-generic32 debug-linux-generic64 debug-linux-ia32-aes debug-linux-pentium debug-linux-ppro debug-linux-x86_64 debug-linux-x86_64-clang debug-rse debug-solaris-sparcv8-cc debug-solaris-sparcv8-gcc debug-solaris-sparcv9-cc debug-solaris-sparcv9-gcc debug-steve-opt debug-steve32 debug-steve64 debug-vos-gcc ie: ./Configure [ os/compiler from above ] no-ssl no-tls no-dtls no-ssl3-method no-tls1-method no-tls1_1-method no-tls1_2-method no-dtls1-method no-dtls1_2-method no-nextprotoneg no-comp > On 19 Apr 2020, at 09:50, Sam Kappen wrote: > > Hi > > We are using a poky with branch "rocko" based build system. > Looking for disabling sslv3 tlsv1 on openssl.(Openssl 1.0.2o) > > I am seeing SSLv3 support in Openssl 1.0.2o is disabled by default. > This patch is already part of our build system. > https://patchwork.openembedded.org/patch/88921/ > > For disabling tls1 tried with EXTRA_OECONF = " -no-ssl3 -no-tls1" but > seems like all of the tls1, tls1_1, tls1_2 are disabled. > > Request your help in disabling the protocol tls1 in openssl. > > Regards, > Sam -- Regards, Mark A. Lane ? Mark A. Lane 1980 - 2020, All Rights Reserved. ? FooCrypt 1980 - 2020, All Rights Reserved. ? FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2020, All Rights Reserved. ? Cryptopocalypse 1980 - 2020, All Rights Reserved. From mahendra.sp at gmail.com Mon Apr 20 11:32:50 2020 From: mahendra.sp at gmail.com (Mahendra SP) Date: Mon, 20 Apr 2020 17:02:50 +0530 Subject: ENGINE_load_private_key does not get invoked Message-ID: Hi All, While writing the engine implementation for private key encryption and decryption, I need to get the private key from external source. ENGINE_set_load_privkey_function(e, load_tpm_private_key) Above API is success. RSA structure is as below. RSA_METHOD my_rsa_struct = { "MY RSA method", NULL, NULL, MyRSAPrivEnc, MyRSAPrivDec, NULL, NULL, NULL, NULL, 0, NULL, NULL, NULL, NULL }; However, the routine load_tpm_private_key does not get invoked during private key encryption and decryption. Private key encryption and decryption gets routed to the above overloaded routines namely " MyRSAPrivEnc " and " MyRSAPrivDec". But load_tpm_private_key never gets invoked. Is there a flag to force the same ? I have tried it using openssl 1.0.2 version. All other engine calls work as expected, but not this one. I have also tried to debug in ENGINE_load_private_key in eng_pkey.c file. I dont see this function getting invoked. In this function, the private key callback set above gets invoked. Please suggest if I am missing something here. Thanks Mahendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon.murphy1996 at protonmail.com Mon Apr 20 11:59:17 2020 From: brandon.murphy1996 at protonmail.com (brandon.murphy1996) Date: Mon, 20 Apr 2020 11:59:17 +0000 Subject: TLS 1.3 PSK succeeds even if then pre-shared key is wrong Message-ID: Hi, I have been trying to perform/debug external PSK based handshake in TLS 1.3 for one of my projects. My team has implemented the "find_session_cb" as : static int psk_find_session_cb(SSL *ssl, const unsigned char *identity, size_t identity_len, SSL_SESSION **sess){ SSL_SESSION *tmpsess = NULL; unsigned char *key; long key_len; const SSL_CIPHER *cipher = NULL; static char *psk_identity = "Client_identity"; const char *psk_key = "0533c95c9ecc310ee07cb70a316c45448487c1f70bbea99fe6616f3348305677"; //temperory fixed psk const unsigned char tls13_aes128gcmsha256_id[] = { 0x13, 0x01 }; if (strlen(psk_identity) != identity_len) { wpa_printf(MSG_DEBUG, "PSK Identity length does not match."); return 0; } if(memcmp(psk_identity, identity, identity_len) != 0) { wpa_printf(MSG_DEBUG, "PSK Identity memory copy failed."); return 0; } key = OPENSSL_hexstr2buf(psk_key, &key_len); if (key == NULL) { wpa_printf(MSG_ERROR, "Could not convert PSK key '%s' to buffer\n", psk_key); return 0; } cipher = SSL_CIPHER_find(ssl, tls13_aes128gcmsha256_id); if (cipher == NULL) { wpa_printf(MSG_DEBUG, "Error finding suitable ciphersuite\n"); OPENSSL_free(key); return 0; } tmpsess = SSL_SESSION_new(); if (tmpsess == NULL || !SSL_SESSION_set1_master_key(tmpsess, key, key_len) || !SSL_SESSION_set_cipher(tmpsess, cipher) || !SSL_SESSION_set_protocol_version(tmpsess, SSL_version(ssl))) { OPENSSL_free(key); return 0; } OPENSSL_free(key); *sess = tmpsess; wpa_printf(MSG_DEBUG, "Using external PSK."); return 1; } and attached the callback to the SSL object using "SSL_set_psk_find_session_callback()" method. From my client, we are sending creating and sending a session using "SSL_set_psk_use_session_callback(sssl, use_session_cb)". >From what I noticed, the handshake completes successfully, regardless of the value of "psk_key" (as long as PSK length is even). However, if the identity value is mismatched between psk_find_session_cb and use_session_cb, the handshake fails with the message: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:internal error OpenSSL: openssl_handshake - SSL_connect error:141F906E:SSL routines:tls_parse_ctos_psk:bad extension I am not sure what am I missing here Thanks Bran From matt at openssl.org Mon Apr 20 14:35:58 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 20 Apr 2020 15:35:58 +0100 Subject: TLS 1.3 PSK succeeds even if then pre-shared key is wrong In-Reply-To: References: Message-ID: <46513ead-d5fb-f410-c1d5-dc02275193b0@openssl.org> On 20/04/2020 12:59, brandon.murphy1996 via openssl-users wrote: > From what I noticed, the handshake completes successfully, regardless > of the value of "psk_key" (as long as PSK length is even). However, > if the identity value is mismatched between psk_find_session_cb and > use_session_cb, the handshake fails with the message: It's not clear from your question what you expected to happen. The length of the PSK key doesn't actually matter from a TLS perspective (obviously in practice it is best if the length is consistent with the ciphersuite key length). Or did you mean that that the value doesn't matter - even if it is mismatched with the client's value? That would be unexpected (and probably indicates you are not actually using the PSK at all and doing a full handshake). Matt From beldmit at gmail.com Mon Apr 20 15:13:14 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 20 Apr 2020 18:13:14 +0300 Subject: ENGINE_load_private_key does not get invoked In-Reply-To: References: Message-ID: Dear Mahendra, Take a look at the load_key function in the apps/apps.c as a referent example. On Mon, Apr 20, 2020 at 2:34 PM Mahendra SP wrote: > Hi All, > > While writing the engine implementation for private key encryption and > decryption, I need to get the private key from external source. > ENGINE_set_load_privkey_function(e, load_tpm_private_key) > Above API is success. > > RSA structure is as below. > RSA_METHOD my_rsa_struct = > { > "MY RSA method", > NULL, > NULL, > MyRSAPrivEnc, > MyRSAPrivDec, > NULL, > NULL, > NULL, > NULL, > 0, > NULL, > NULL, > NULL, > NULL > }; > > However, the routine load_tpm_private_key does not get invoked during > private key encryption and decryption. > Private key encryption and decryption gets routed to the above overloaded > routines namely " MyRSAPrivEnc " and " MyRSAPrivDec". But > load_tpm_private_key never gets invoked. > > Is there a flag to force the same ? I have tried it using openssl 1.0.2 > version. All other engine calls work as expected, but not this one. > > I have also tried to debug in ENGINE_load_private_key in eng_pkey.c file. > I dont see this function getting invoked. In this function, the private key > callback set above gets invoked. > > Please suggest if I am missing something here. > > Thanks > Mahendra > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon.murphy1996 at protonmail.com Mon Apr 20 15:42:02 2020 From: brandon.murphy1996 at protonmail.com (brandon.murphy1996) Date: Mon, 20 Apr 2020 15:42:02 +0000 Subject: TLS 1.3 PSK succeeds even if the pre-shared key is wrong Message-ID: <6rMORshexyOC6vUB-02eLf9PkYk912vsyEIeLWtJcnYb2VVP2P3NMDsDwRqiY9z7_aFUiuPexzoNVUGizgMR_0_cy13ZeIah-LeIEjpPoVI=@protonmail.com> Hi Matt Thanks for the reply. Yes! the handshake completes even when the PSK does not match between the ones provided in Client and Server. However, if there is a mismatch in the provided identity inside the callbacks, I see the above-mentioned error(the bad extension one). Unless I am missing something, if the code was not trying to perform a PSK verification, I would have received a complete handshake even if there was identity value mismatch between find_session_cb and use_session_cb. Moreover, I am using SSL_CTX_set_verify() with option SSL_VERIFY_PEER. Also, I am not providing the client Hello with any certificates. So I see no reason for handshake to complete without verification. Thanks Bran ??????? Original Message ??????? On Monday, April 20, 2020 5:35 PM, Matt Caswell wrote: > On 20/04/2020 12:59, brandon.murphy1996 via openssl-users wrote: > > > From what I noticed, the handshake completes successfully, regardless > > of the value of "psk_key" (as long as PSK length is even). However, > > if the identity value is mismatched between psk_find_session_cb and > > use_session_cb, the handshake fails with the message: > > It's not clear from your question what you expected to happen. The > length of the PSK key doesn't actually matter from a TLS perspective > (obviously in practice it is best if the length is consistent with the > ciphersuite key length). > > Or did you mean that that the value doesn't matter - even if it is > mismatched with the client's value? That would be unexpected (and > probably indicates you are not actually using the PSK at all and doing a > full handshake). > > Matt From mahendra.sp at gmail.com Mon Apr 20 16:26:24 2020 From: mahendra.sp at gmail.com (Mahendra SP) Date: Mon, 20 Apr 2020 21:56:24 +0530 Subject: ENGINE_load_private_key does not get invoked In-Reply-To: References: Message-ID: Hi Dmitry Belyavsky, Thank you for the inputs. If I understand correctly, the reference indicates loading the private key to engine instance. My requirement is to call the ENGINE_set_load_privkey_function so that the callback gets called before each RSA private key operation. Reason being, application can use either key with TPM or keys in software. So I need to load the correct key before each operation gets invoked.I was looking at ENGINE_set_load_privkey_function to set the callback.Is this understanding correct ? Please suggest. Thanks Mahendra On Mon, Apr 20, 2020 at 8:43 PM Dmitry Belyavsky wrote: > Dear Mahendra, > > Take a look at the load_key function in the apps/apps.c as a referent > example. > > On Mon, Apr 20, 2020 at 2:34 PM Mahendra SP wrote: > >> Hi All, >> >> While writing the engine implementation for private key encryption and >> decryption, I need to get the private key from external source. >> ENGINE_set_load_privkey_function(e, load_tpm_private_key) >> Above API is success. >> >> RSA structure is as below. >> RSA_METHOD my_rsa_struct = >> { >> "MY RSA method", >> NULL, >> NULL, >> MyRSAPrivEnc, >> MyRSAPrivDec, >> NULL, >> NULL, >> NULL, >> NULL, >> 0, >> NULL, >> NULL, >> NULL, >> NULL >> }; >> >> However, the routine load_tpm_private_key does not get invoked during >> private key encryption and decryption. >> Private key encryption and decryption gets routed to the above overloaded >> routines namely " MyRSAPrivEnc " and " MyRSAPrivDec". But >> load_tpm_private_key never gets invoked. >> >> Is there a flag to force the same ? I have tried it using openssl 1.0.2 >> version. All other engine calls work as expected, but not this one. >> >> I have also tried to debug in ENGINE_load_private_key in eng_pkey.c file. >> I dont see this function getting invoked. In this function, the private key >> callback set above gets invoked. >> >> Please suggest if I am missing something here. >> >> Thanks >> Mahendra >> > > > -- > SY, Dmitry Belyavsky > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Mon Apr 20 16:33:17 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 20 Apr 2020 19:33:17 +0300 Subject: ENGINE_load_private_key does not get invoked In-Reply-To: References: Message-ID: Dear Mahendra, On Mon, Apr 20, 2020 at 7:27 PM Mahendra SP wrote: > Hi Dmitry Belyavsky, > > Thank you for the inputs. If I understand correctly, the > reference indicates loading the private key to engine instance. > > My requirement is to call the ENGINE_set_load_privkey_function so that > the callback gets called before each RSA private key operation. > Reason being, application can use either key with TPM or keys in software. > So I need to load the correct key before each operation gets invoked.I was > looking at > ENGINE_set_load_privkey_function to set the callback.Is this > understanding correct ? > You specify the engine-specific function via ENGINE_set_load_privkey_function. After that, you can load your key using ENGINE_load_private_key - if you pass the reference to your engine to it, the function set via ENGINE_set_load_privkey_function will be used. > Please suggest. > > Thanks > Mahendra > > > > On Mon, Apr 20, 2020 at 8:43 PM Dmitry Belyavsky > wrote: > >> Dear Mahendra, >> >> Take a look at the load_key function in the apps/apps.c as a referent >> example. >> >> On Mon, Apr 20, 2020 at 2:34 PM Mahendra SP >> wrote: >> >>> Hi All, >>> >>> While writing the engine implementation for private key encryption and >>> decryption, I need to get the private key from external source. >>> ENGINE_set_load_privkey_function(e, load_tpm_private_key) >>> Above API is success. >>> >>> RSA structure is as below. >>> RSA_METHOD my_rsa_struct = >>> { >>> "MY RSA method", >>> NULL, >>> NULL, >>> MyRSAPrivEnc, >>> MyRSAPrivDec, >>> NULL, >>> NULL, >>> NULL, >>> NULL, >>> 0, >>> NULL, >>> NULL, >>> NULL, >>> NULL >>> }; >>> >>> However, the routine load_tpm_private_key does not get invoked during >>> private key encryption and decryption. >>> Private key encryption and decryption gets routed to the above >>> overloaded routines namely " MyRSAPrivEnc " and " MyRSAPrivDec". But >>> load_tpm_private_key never gets invoked. >>> >>> Is there a flag to force the same ? I have tried it using openssl 1.0.2 >>> version. All other engine calls work as expected, but not this one. >>> >>> I have also tried to debug in ENGINE_load_private_key in eng_pkey.c >>> file. I dont see this function getting invoked. In this function, the >>> private key callback set above gets invoked. >>> >>> Please suggest if I am missing something here. >>> >>> Thanks >>> Mahendra >>> >> >> >> -- >> SY, Dmitry Belyavsky >> > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Apr 20 16:38:16 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 20 Apr 2020 17:38:16 +0100 Subject: TLS 1.3 PSK succeeds even if the pre-shared key is wrong In-Reply-To: <6rMORshexyOC6vUB-02eLf9PkYk912vsyEIeLWtJcnYb2VVP2P3NMDsDwRqiY9z7_aFUiuPexzoNVUGizgMR_0_cy13ZeIah-LeIEjpPoVI=@protonmail.com> References: <6rMORshexyOC6vUB-02eLf9PkYk912vsyEIeLWtJcnYb2VVP2P3NMDsDwRqiY9z7_aFUiuPexzoNVUGizgMR_0_cy13ZeIah-LeIEjpPoVI=@protonmail.com> Message-ID: Resend...this time including openssl-users, accidentally omitted from my last reply... On 20/04/2020 16:42, brandon.murphy1996 via openssl-users wrote: > Hi Matt > > Thanks for the reply. > > Yes! the handshake completes even when the PSK does not match between the ones provided in Client and Server. However, if there is a mismatch in the provided identity inside the callbacks, I see the above-mentioned error(the bad extension one). > > Unless I am missing something, if the code was not trying to perform a PSK verification, I would have received a complete handshake even if there was identity value mismatch between find_session_cb and use_session_cb. > > Moreover, I am using SSL_CTX_set_verify() with option SSL_VERIFY_PEER. Also, I am not providing the client Hello with any certificates. So I see no reason for handshake to complete without verification. > > Thanks > Bran Hmm. That's very strange behaviour. OpenSSL's s_server implementation of the find_session_cb is virtually identical to the one you posted (with a few minor differences). Presumably that's what you based the code on. We can test out the effect of mismatched PSKs using that callback as follows. First a matching PSK: $ openssl s_server -psk 012345 -nocert $ openssl s_client -psk 012345 With the above I get a successful connection. With a mismatched PSK, using TLSv1.3: $ openssl s_server -psk 012345 -nocert $ openssl s_client -psk 0123 With that on the server side I get a "binder does not verify" error: 139656179684608:error:141FA0FD:SSL routines:tls_psk_do_binder:binder does not verify:ssl/statem/extensions.c:1616: And on the client I get an illegal parameter alert: 140393338672384:error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter:ssl/record/rec_layer_s3.c:1543:SSL alert number 47 With a mismatched PSK, using TLSv1.2: $ openssl s_server -psk 012345 -nocert -no_tls1_3 $ openssl s_client -psk 0123 On the server I get decryption failed or bad record mac: 140522123650304:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:ssl/record/ssl3_record.c:676: And on the client I get a bad record mac alert: 140668428645632:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:ssl/record/rec_layer_s3.c:1543:SSL alert number 20 You might want to experiment with pointing the client you are using at s_server, and also with s_client pointing at your server, and try out those options to see if you can isolate the problem. Matt > > > ??????? Original Message ??????? > On Monday, April 20, 2020 5:35 PM, Matt Caswell wrote: > >> On 20/04/2020 12:59, brandon.murphy1996 via openssl-users wrote: >> >>> From what I noticed, the handshake completes successfully, regardless >>> of the value of "psk_key" (as long as PSK length is even). However, >>> if the identity value is mismatched between psk_find_session_cb and >>> use_session_cb, the handshake fails with the message: >> >> It's not clear from your question what you expected to happen. The >> length of the PSK key doesn't actually matter from a TLS perspective >> (obviously in practice it is best if the length is consistent with the >> ciphersuite key length). >> >> Or did you mean that that the value doesn't matter - even if it is >> mismatched with the client's value? That would be unexpected (and >> probably indicates you are not actually using the PSK at all and doing a >> full handshake). >> >> Matt > > From mahendra.sp at gmail.com Mon Apr 20 16:56:24 2020 From: mahendra.sp at gmail.com (Mahendra SP) Date: Mon, 20 Apr 2020 22:26:24 +0530 Subject: ENGINE_load_private_key does not get invoked In-Reply-To: References: Message-ID: Hi Dmitry Belyavsky, Thank you..To give more info, I am looking at something similar the engine in e_4758cca.c in engines folder where ENGINE_set_load_privkey_function is called. My understanding was, once the callback is set, it automatically gets called during RSA operations. As demostrated in e_4758cca.c, ex data can be added and during private key operations, same can be access to decide the operation. Is this not correct ? >From your above inputs, looks like ENGINE_set_load_privkey_function needs to be called to invoke the callback. e_4758cca.c shows that in callback, RSA can be modified to add the ex data so that same can be accessed during RSA private key operations. To confirm, once the callback is registered using ENGINE_set_load_privkey_function, callback gets called by openssl before every private key operation. Is this correct ? Thanks Mahendra On Mon, Apr 20, 2020 at 10:03 PM Dmitry Belyavsky wrote: > Dear Mahendra, > > On Mon, Apr 20, 2020 at 7:27 PM Mahendra SP wrote: > >> Hi Dmitry Belyavsky, >> >> Thank you for the inputs. If I understand correctly, the >> reference indicates loading the private key to engine instance. >> >> My requirement is to call the ENGINE_set_load_privkey_function so that >> the callback gets called before each RSA private key operation. >> Reason being, application can use either key with TPM or keys in >> software. So I need to load the correct key before each operation gets >> invoked.I was looking at >> ENGINE_set_load_privkey_function to set the callback.Is this >> understanding correct ? >> > > You specify the engine-specific function via > ENGINE_set_load_privkey_function. > > After that, you can load your key using ENGINE_load_private_key - > if you pass the reference to your engine to it, the function set via > ENGINE_set_load_privkey_function will be used. > > >> Please suggest. >> >> Thanks >> Mahendra >> >> >> >> On Mon, Apr 20, 2020 at 8:43 PM Dmitry Belyavsky >> wrote: >> >>> Dear Mahendra, >>> >>> Take a look at the load_key function in the apps/apps.c as a referent >>> example. >>> >>> On Mon, Apr 20, 2020 at 2:34 PM Mahendra SP >>> wrote: >>> >>>> Hi All, >>>> >>>> While writing the engine implementation for private key encryption and >>>> decryption, I need to get the private key from external source. >>>> ENGINE_set_load_privkey_function(e, load_tpm_private_key) >>>> Above API is success. >>>> >>>> RSA structure is as below. >>>> RSA_METHOD my_rsa_struct = >>>> { >>>> "MY RSA method", >>>> NULL, >>>> NULL, >>>> MyRSAPrivEnc, >>>> MyRSAPrivDec, >>>> NULL, >>>> NULL, >>>> NULL, >>>> NULL, >>>> 0, >>>> NULL, >>>> NULL, >>>> NULL, >>>> NULL >>>> }; >>>> >>>> However, the routine load_tpm_private_key does not get invoked during >>>> private key encryption and decryption. >>>> Private key encryption and decryption gets routed to the above >>>> overloaded routines namely " MyRSAPrivEnc " and " MyRSAPrivDec". But >>>> load_tpm_private_key never gets invoked. >>>> >>>> Is there a flag to force the same ? I have tried it using openssl >>>> 1.0.2 version. All other engine calls work as expected, but not this one. >>>> >>>> I have also tried to debug in ENGINE_load_private_key in eng_pkey.c >>>> file. I dont see this function getting invoked. In this function, the >>>> private key callback set above gets invoked. >>>> >>>> Please suggest if I am missing something here. >>>> >>>> Thanks >>>> Mahendra >>>> >>> >>> >>> -- >>> SY, Dmitry Belyavsky >>> >> > > -- > SY, Dmitry Belyavsky > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Mon Apr 20 17:00:19 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 20 Apr 2020 20:00:19 +0300 Subject: ENGINE_load_private_key does not get invoked In-Reply-To: References: Message-ID: Dear Mahendra, On Mon, Apr 20, 2020 at 7:57 PM Mahendra SP wrote: > Hi Dmitry Belyavsky, > > Thank you..To give more info, I am looking at something similar the engine > in e_4758cca.c in engines folder where ENGINE_set_load_privkey_function > is called. > My understanding was, once the callback is set, it automatically gets > called during RSA operations. As demostrated in e_4758cca.c, ex data can be > added and during private key operations, same can be access to decide the > operation. Is this not correct ? > From your above inputs, looks like ENGINE_set_load_privkey_function needs > to be called to invoke the callback. > > e_4758cca.c shows that in callback, RSA can be modified to add the ex > data so that same can be accessed during RSA private key operations. > To confirm, once the callback is registered using > ENGINE_set_load_privkey_function, callback gets called by openssl before > every private key operation. Is this correct ? > If I understand you correctly, yes. > > Thanks > Mahendra > > > On Mon, Apr 20, 2020 at 10:03 PM Dmitry Belyavsky > wrote: > >> Dear Mahendra, >> >> On Mon, Apr 20, 2020 at 7:27 PM Mahendra SP >> wrote: >> >>> Hi Dmitry Belyavsky, >>> >>> Thank you for the inputs. If I understand correctly, the >>> reference indicates loading the private key to engine instance. >>> >>> My requirement is to call the ENGINE_set_load_privkey_function so that >>> the callback gets called before each RSA private key operation. >>> Reason being, application can use either key with TPM or keys in >>> software. So I need to load the correct key before each operation gets >>> invoked.I was looking at >>> ENGINE_set_load_privkey_function to set the callback.Is this >>> understanding correct ? >>> >> >> You specify the engine-specific function via >> ENGINE_set_load_privkey_function. >> >> After that, you can load your key using ENGINE_load_private_key - >> if you pass the reference to your engine to it, the function set via >> ENGINE_set_load_privkey_function will be used. >> >> >>> Please suggest. >>> >>> Thanks >>> Mahendra >>> >>> >>> >>> On Mon, Apr 20, 2020 at 8:43 PM Dmitry Belyavsky >>> wrote: >>> >>>> Dear Mahendra, >>>> >>>> Take a look at the load_key function in the apps/apps.c as a referent >>>> example. >>>> >>>> On Mon, Apr 20, 2020 at 2:34 PM Mahendra SP >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> While writing the engine implementation for private key encryption and >>>>> decryption, I need to get the private key from external source. >>>>> ENGINE_set_load_privkey_function(e, load_tpm_private_key) >>>>> Above API is success. >>>>> >>>>> RSA structure is as below. >>>>> RSA_METHOD my_rsa_struct = >>>>> { >>>>> "MY RSA method", >>>>> NULL, >>>>> NULL, >>>>> MyRSAPrivEnc, >>>>> MyRSAPrivDec, >>>>> NULL, >>>>> NULL, >>>>> NULL, >>>>> NULL, >>>>> 0, >>>>> NULL, >>>>> NULL, >>>>> NULL, >>>>> NULL >>>>> }; >>>>> >>>>> However, the routine load_tpm_private_key does not get invoked during >>>>> private key encryption and decryption. >>>>> Private key encryption and decryption gets routed to the above >>>>> overloaded routines namely " MyRSAPrivEnc " and " MyRSAPrivDec". But >>>>> load_tpm_private_key never gets invoked. >>>>> >>>>> Is there a flag to force the same ? I have tried it using openssl >>>>> 1.0.2 version. All other engine calls work as expected, but not this one. >>>>> >>>>> I have also tried to debug in ENGINE_load_private_key in eng_pkey.c >>>>> file. I dont see this function getting invoked. In this function, the >>>>> private key callback set above gets invoked. >>>>> >>>>> Please suggest if I am missing something here. >>>>> >>>>> Thanks >>>>> Mahendra >>>>> >>>> >>>> >>>> -- >>>> SY, Dmitry Belyavsky >>>> >>> >> >> -- >> SY, Dmitry Belyavsky >> > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From yangbolinzju at gmail.com Tue Apr 21 09:48:19 2020 From: yangbolinzju at gmail.com (yang berlin) Date: Tue, 21 Apr 2020 17:48:19 +0800 Subject: questions on using ed25519 Message-ID: Hello, I am a beginner on openssl, and I want to use the ed25519 in openssl. The problem I met is: I can use "speed ed25519" to test the speed of ed25519, but when I use "dgst -ed25519", it tells me that "dgst: Unrecognized flag Ed25519". So could you please help me to learn how to use ed25519 correctly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.j.culhane at gmail.com Tue Apr 21 11:01:52 2020 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Tue, 21 Apr 2020 12:01:52 +0100 Subject: building a PIC enabled version of openssl 1.0.2k on Sparc 10 In-Reply-To: References: <003601d613fc$5491b590$fdb520b0$@gmail.com> Message-ID: <001001d617cc$45a24d00$d0e6e700$@gmail.com> Hi, Just to say that you can get the -Fpic flag by using the 'shared' argument to the Configure script. The following works for me: ./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.1.1 --openssldir=/opt/openssl/1.1.1 -lrt -m64 shared zlib Regards, Tim -----Original Message----- From: openssl-users On Behalf Of Michael Wojcik Sent: Thursday 16 April 2020 18:16 To: openssl-users at openssl.org Subject: RE: building a PIC enabled version of openssl 1.0.2k on Sparc 10 > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of tim.j.culhane at gmail.com > Sent: Thursday, April 16, 2020 08:36 > > I'm building a PIC enabled shared library in my server which links > against openssl 1.0.2k libssl.a library on Sparc 10. > > When compiling I see the below errors. > > I originally built the 1.0.2k version of openssl with the following > configure arguments: > > ./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.0.2k > --openssldir=/opt/openssl/1.0.2k -lrt -m64 > > Do I need to pass in the -fPIC flag as well, and if so how do I do that. I believe you do, though our use case is different - we build OpenSSL as a PIC archive library, which we then linked into a shared object. If you're building OpenSSL as a shared object (well, a pair of shared objects, for libcrypto and libssl), then you may be able to do that with the appropriate Configure options. My teams have switched to 1.1.1, so I don't have a 1.0.2 build handy to check. > I appended it to the end of the configure line I show above but > there was no sign of PIC in any of the top level makefiles produced. For 1.0.2, we edited the Configure file. We kept a log of the purposes of our changes, and looked at the Configure diffs for each new 1.0.2 release so we could port the relevant changes back to our Configure. We haven't had to do that with 1.1.1; its Configure is more flexible. -- Michael Wojcik Distinguished Engineer, Micro Focus From abaci.mjm at gmail.com Tue Apr 21 13:08:58 2020 From: abaci.mjm at gmail.com (Michael Mueller) Date: Tue, 21 Apr 2020 09:08:58 -0400 Subject: CMS in openssl Message-ID: Greetings esteemed openssl users, We've implemented what I gather can be called a CMS on Linux and Windows using openssl evp functions. We need to expand this CMS to other systems, on which we have not been able to build openssl. These other systems have a vendor supplied security application. This application supports PKCS7. We are being asked if our evp CMS is interoperable with PKCS7. If it is possible and more information is required to answer this question, I'll provide such information. If not, advice on how to present that argument to management would be appreciated. Thank you for your assistance Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Tue Apr 21 13:16:08 2020 From: openssl at openssl.org (OpenSSL) Date: Tue, 21 Apr 2020 13:16:08 +0000 Subject: OpenSSL version 1.1.1g published Message-ID: <20200421131608.GA27174@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1g released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1g of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1g is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1g.tar.gz Size: 9801502 SHA1 checksum: b213a293f2127ec3e323fb3cfc0c9807664fd997 SHA256 checksum: ddb04774f1e32f0c49751e21b67216ac87852ceb056b75209af2443400636d46 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1g.tar.gz openssl sha256 openssl-1.1.1g.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6e5ZUACgkQ2cTSbQ5g RJFGnQf8D8U0193cmqitZZ4L63ncx8aWPMdXMookxywTnhCHm7qyNGa0a41J0iZw pRebjlrjo1rEOMFo9rNmvtoBBUs/cFD8ARsItK3Kh2ms0z4MJV4F07XJHwNkd0Wf n18+oUS6Fj7Z8TgdA+UwBFuN248kqELDp8DYntLCzyEvkweU80JIRWhC+XawjcbA W/zlD6oVfNsgYP38hSCQg14B+/djMTVYqtDSOBm3B+J7zRndYoTvsankWlsMmDD5 Tb6lOQ8IBEsgnlriOH936eKhlJ5UeTr2hPONnzDJ/cIUWn1RwX9yPGOoaf74IoHc Hg/T6vP+pD3G3mDOS51Qm87A5+nDaQ== =eNCz -----END PGP SIGNATURE----- From openssl at openssl.org Tue Apr 21 13:25:24 2020 From: openssl at openssl.org (OpenSSL) Date: Tue, 21 Apr 2020 13:25:24 +0000 Subject: OpenSSL Security Advisory Message-ID: <20200421132524.GA5046@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [21 April 2020] ========================================= Segmentation fault in SSL_check_chain (CVE-2020-1967) ===================================================== Severity: High Server or client applications that call the SSL_check_chain() function during or after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a result of incorrect handling of the "signature_algorithms_cert" TLS extension. The crash occurs if an invalid or unrecognised signature algorithm is received from the peer. This could be exploited by a malicious peer in a Denial of Service attack. OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This issue did not affect OpenSSL versions prior to 1.1.1d. Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April 2020. It was found using the new static analysis pass being implemented in GCC, - -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin Kaduk. Note ===== This issue did not affect OpenSSL 1.0.2 however these versions are out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html This issue did not affect OpenSSL 1.1.0 however these versions are out of support and no longer receiving updates. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20200421.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6e8uwACgkQ2cTSbQ5g RJHHRgf+J8iVBuK6EoOvf9xm9geiDgYVFse9ckMXH92gdGbwsW4uhTNk9fCyNC+t vsf6YGT6nKJarB5+N+LC4QB7VLo/DjlYcN9zP3mubV0eEyKHSoW6tDOWPpJ0gsbt 2Z9iTA4GnofvhBcWLiPGgv4IUHknsOaPkRmEppSF0fDTSKuYOerfNRh9jTKHulis Ph6dCOXE3kb5HfMwVj3UN2sP92XTig4FzpIQaZ1/2jKZaRXtzJD7pvu1fDCTkUGl aeta5jHNypYyRKJLuJ1+1DiBtbWTFAWMUCHlkg/kgdU4hIl/lo3vgAyFs/9mQxZQ vj2rIjoJHRj0EXqXhHoABqBHedilJQ== =AXyP -----END PGP SIGNATURE----- From junaid.mukhtar at gmail.com Tue Apr 21 15:06:04 2020 From: junaid.mukhtar at gmail.com (Junaid Mukhtar) Date: Tue, 21 Apr 2020 16:06:04 +0100 Subject: TLSv1 on CentOS-8 In-Reply-To: References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> <5d0125b4e2b625ecf5de73ff7f676b3cab4b9d8b.camel@redhat.com> <20200417170318.GC41308@straasha.imrryr.org> Message-ID: Hi Tomas/Team I have managed to block the RC4 and enable tlsv1 as per our requirements. We have a requirement to match cipher list on the internal server to match the native browser cipher list as shown by the https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html I have tried setting up different combinations on the CipherString but none helped. Do you have any suggestions as to how to do achieve this? -------- Regards, Junaid On Fri, Apr 17, 2020 at 6:22 PM Tomas Mraz wrote: > On Fri, 2020-04-17 at 13:03 -0400, Viktor Dukhovni wrote: > > On Fri, Apr 17, 2020 at 05:17:47PM +0200, Tomas Mraz wrote: > > > > > Or you could modify the /etc/pki/tls/openssl.cnf: > > > Find the .include /etc/crypto-policies/back-ends/opensslcnf.config > > > line in it and insert something like: > > > > > > CipherString = > > > @SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!DES:!RC2:!RC4: > > > !IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 > > > > How did this particular contraption become a recommended cipherlist? > > To explain - this is basically autogenerated value from the crypto > policy definiton of the LEGACY crypto policy with just added the !RC4. > > > > What's wrong with "DEFAULT"? In OpenSSL 1.1.1 it already excludes > > RC4 (if RC4 is at all enabled at compile time): > > Nothing wrong with DEFAULT. For manual configuration. This is however > something that is autogenerated. > > > $ openssl ciphers -v 'COMPLEMENTOFDEFAULT+RC4' > > ECDHE-ECDSA-RC4-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=RC4(128) > > Mac=SHA1 > > ECDHE-RSA-RC4-SHA TLSv1 > > Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 > > RC4-SHA SSLv3 > > Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 > > > > I find too many people cargo-culting poorly thought cipher lists from > > some random HOWTO. Over optimising your cipherlist is subject to > > rapid bitrot, resist the temptation... > > Yeah, I should have probably suggested just: CipherString = DEFAULT > > There is not much point in being as close to the autogenerated policy > as possible for this particular user's use-case. > > -- > Tom?? Mr?z > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaci.mjm at gmail.com Tue Apr 21 15:18:02 2020 From: abaci.mjm at gmail.com (Michael Mueller) Date: Tue, 21 Apr 2020 11:18:02 -0400 Subject: secure_getenv Message-ID: anybody else compiling apps against openssl 1.1.1g in Linux and getting link errors for secure_getenv? ../../../../OPENSSL/bin/SUSE-Linux/libcrypto.a(getenv.o): In function `ossl_safe_getenv': getenv.c:(.text+0x1): undefined reference to `secure_getenv secure_getenv() is a GNU extension Mike From abaci.mjm at gmail.com Tue Apr 21 15:42:34 2020 From: abaci.mjm at gmail.com (Michael Mueller) Date: Tue, 21 Apr 2020 11:42:34 -0400 Subject: secure_getenv In-Reply-To: References: Message-ID: IGNORE cockpit error I failed to compile openssl on the lowest revision release that we support. The error occurred when I tried to build our app on the low rev system with openssl 1.1.1g that was built on a higher revision linux system. TIL secure_getenv() On Tue, Apr 21, 2020 at 11:18 AM Michael Mueller wrote: > > anybody else compiling apps against openssl 1.1.1g in Linux and > getting link errors for secure_getenv? > > ../../../../OPENSSL/bin/SUSE-Linux/libcrypto.a(getenv.o): In function > `ossl_safe_getenv': getenv.c:(.text+0x1): undefined reference to > `secure_getenv > > secure_getenv() is a GNU extension > > Mike From quanah at symas.com Tue Apr 21 17:08:39 2020 From: quanah at symas.com (Quanah Gibson-Mount) Date: Tue, 21 Apr 2020 10:08:39 -0700 Subject: empty directory in the 1.1.1 series release tags Message-ID: <08DF2FEBB606C30ECC9D4335@[192.168.1.144]> The OpenSSL release tags contain an empty directory "krb5" that does not exist in the release tarball. This is annoying because when I go to merge release tags, I constantly get the following: CONFLICT (modify/delete): krb5 deleted in HEAD and modified in OpenSSL_1_1_1e. Version OpenSSL_1_1_1e of krb5 left in tree. Can this please be fixed? Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From bkaduk at akamai.com Tue Apr 21 17:16:09 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 21 Apr 2020 10:16:09 -0700 Subject: empty directory in the 1.1.1 series release tags In-Reply-To: <08DF2FEBB606C30ECC9D4335@[192.168.1.144]> References: <08DF2FEBB606C30ECC9D4335@[192.168.1.144]> Message-ID: <20200421171609.GX3811@akamai.com> On Tue, Apr 21, 2020 at 10:08:39AM -0700, Quanah Gibson-Mount wrote: > The OpenSSL release tags contain an empty directory "krb5" that does not > exist in the release tarball. This is annoying because when I go to merge > release tags, I constantly get the following: > > CONFLICT (modify/delete): krb5 deleted in HEAD and modified in > OpenSSL_1_1_1e. Version OpenSSL_1_1_1e of krb5 left in tree. > > Can this please be fixed? The 'krb5' entry in git is a submodule, used for the external tests. It's removed while preparing release tarballs, but I'm not sure what you are doing that's causing conflicts -- are you doing something that involves both tarballs and git? -Ben From quanah at symas.com Tue Apr 21 17:19:28 2020 From: quanah at symas.com (Quanah Gibson-Mount) Date: Tue, 21 Apr 2020 10:19:28 -0700 Subject: empty directory in the 1.1.1 series release tags In-Reply-To: <20200421171609.GX3811@akamai.com> References: <08DF2FEBB606C30ECC9D4335@[192.168.1.144]> <20200421171609.GX3811@akamai.com> Message-ID: --On Tuesday, April 21, 2020 11:16 AM -0700 Benjamin Kaduk wrote: > The 'krb5' entry in git is a submodule, used for the external tests. > It's removed while preparing release tarballs, but I'm not sure what > you are doing that's causing conflicts -- are you doing something that > involves both tarballs and git? I use the git release tags, not the tarballs. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From ca+ssl-users at esmtp.org Tue Apr 21 17:22:38 2020 From: ca+ssl-users at esmtp.org (Claus Assmann) Date: Tue, 21 Apr 2020 19:22:38 +0200 Subject: opensssl 1.1.1g test failure(s) Message-ID: <20200421172238.GA58719@kiel.esmtp.org> Note sure whether this is already known (a search didn't bring up anything meaningful): ../test/recipes/80-test_ssl_old.t .................. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/6 subtests Test Summary Report ------------------- ../test/recipes/80-test_ssl_old.t (Wstat: 256 Tests: 6 Failed: 1) Failed test: 2 ^ Is that supposed to be the number of failed tests? If so, I don't see the 2nd test failure (and it should probably be "Failed test(s):"?) Files=155, Tests=1256, 298 wallclock secs ( 0.32 usr 2.07 sys + 126.58 cusr 156.65 csys = 285.62 CPU) Result: FAIL OS Version: OpenBSD 6.5 amd64 From bkaduk at akamai.com Tue Apr 21 17:24:06 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 21 Apr 2020 10:24:06 -0700 Subject: empty directory in the 1.1.1 series release tags In-Reply-To: References: <08DF2FEBB606C30ECC9D4335@[192.168.1.144]> <20200421171609.GX3811@akamai.com> Message-ID: <20200421172405.GY3811@akamai.com> On Tue, Apr 21, 2020 at 10:19:28AM -0700, Quanah Gibson-Mount wrote: > --On Tuesday, April 21, 2020 11:16 AM -0700 Benjamin Kaduk > wrote: > > > The 'krb5' entry in git is a submodule, used for the external tests. > > It's removed while preparing release tarballs, but I'm not sure what > > you are doing that's causing conflicts -- are you doing something that > > involves both tarballs and git? > > I use the git release tags, not the tarballs. Can't you just leave the empty directory in your local branch and not have a conflict, then? -Ben From norm.green at gemtalksystems.com Tue Apr 21 17:25:22 2020 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 21 Apr 2020 10:25:22 -0700 Subject: empty directory in the 1.1.1 series release tags In-Reply-To: References: <08DF2FEBB606C30ECC9D4335@[192.168.1.144]> <20200421171609.GX3811@akamai.com> Message-ID: <5f27d983-07f8-3be6-a911-11cbe9eaa3ed@gemtalksystems.com> >I use the git release tags, not the tarballs. I do too, and I suspect many others do as well. The empty krb5 directory has not caused grief for me, but it would be nice if the git release tag directory structure matched the tarball. Norm Green On 4/21/2020 10:19 AM, Quanah Gibson-Mount wrote: > --On Tuesday, April 21, 2020 11:16 AM -0700 Benjamin Kaduk > wrote: > >> The 'krb5' entry in git is a submodule, used for the external tests. >> It's removed while preparing release tarballs, but I'm not sure what >> you are doing that's causing conflicts -- are you doing something that >> involves both tarballs and git? > > I use the git release tags, not the tarballs. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > From bkaduk at akamai.com Tue Apr 21 17:27:09 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 21 Apr 2020 10:27:09 -0700 Subject: opensssl 1.1.1g test failure(s) In-Reply-To: <20200421172238.GA58719@kiel.esmtp.org> References: <20200421172238.GA58719@kiel.esmtp.org> Message-ID: <20200421172709.GZ3811@akamai.com> On Tue, Apr 21, 2020 at 07:22:38PM +0200, Claus Assmann wrote: > Note sure whether this is already known (a search didn't bring up > anything meaningful): > > ../test/recipes/80-test_ssl_old.t .................. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/6 subtests > Test Summary Report > ------------------- > ../test/recipes/80-test_ssl_old.t (Wstat: 256 Tests: 6 Failed: 1) ^^^^^^^^^ this is the number of failed tests > Failed test: 2 > ^ Is that supposed to be the number of failed tests? No, that's the index of the failing test(s). (I always have to check whether it's 0-indexed or 1-indexed, though.) > If so, I don't see the 2nd test failure > (and it should probably be "Failed test(s):"?) > > Files=155, Tests=1256, 298 wallclock secs ( 0.32 usr 2.07 sys + 126.58 cusr 156.65 csys = 285.62 CPU) > Result: FAIL Please run again with `make V=1 TESTS=test_ssl_old test` and post the relevant parts of the output? Thanks, Ben From ca+ssl-users at esmtp.org Tue Apr 21 17:34:06 2020 From: ca+ssl-users at esmtp.org (Claus Assmann) Date: Tue, 21 Apr 2020 19:34:06 +0200 Subject: opensssl 1.1.1g test failure(s) In-Reply-To: <20200421172709.GZ3811@akamai.com> References: <20200421172238.GA58719@kiel.esmtp.org> <20200421172709.GZ3811@akamai.com> Message-ID: <20200421173406.GA4489@kiel.esmtp.org> On Tue, Apr 21, 2020, Benjamin Kaduk via openssl-users wrote: > On Tue, Apr 21, 2020 at 07:22:38PM +0200, Claus Assmann wrote: > > ../test/recipes/80-test_ssl_old.t .................. > > Dubious, test returned 1 (wstat 256, 0x100) > Please run again with `make V=1 TESTS=test_ssl_old test` and post the relevant parts of the output? Thanks for the reply, below is the output, It seems it only fails because the host doesn't support IPv6? make depend && make _tests ( cd test; mkdir -p test-runs; SRCTOP=../. BLDTOP=../. RESULT_D=test-runs PERL="/usr/bin/perl" EXE_EXT= OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` OPENSSL_DEBUG_MEMORY=on /usr/bin/perl .././test/run_tests.pl test_ssl_old ) ../test/recipes/80-test_ssl_old.t .. 1..6 # Subtest: test_ss 1..17 Generating a RSA private key ......+++++ ..................................................................................................+++++ writing new private key to 'keyCA.ss' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:AU Organization Name (eg, company) []:Dodgy Brothers Common Name (eg, YOUR name) []:Dodgy CA ../../util/shlib_wrap.sh ../../apps/openssl req -config ../CAss.cnf -out reqCA.ss -keyout keyCA.ss -new => 0 ok 1 - make cert request Signature ok subject=C = AU, O = Dodgy Brothers, CN = Dodgy CA Getting Private key ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -CAcreateserial -in reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile ../CAss.cnf -extensions v3_ca > err.ss => 0 ok 2 - convert request into self-signed cert Getting request Private Key Generating certificate request ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -in certCA.ss -x509toreq -signkey keyCA.ss -out req2CA.ss > err.ss => 0 ok 3 - convert cert into a cert request verify OK ../../util/shlib_wrap.sh ../../apps/openssl req -config ../../apps/openssl.cnf -verify -in reqCA.ss -noout => 0 ok 4 - verify request 1 verify OK ../../util/shlib_wrap.sh ../../apps/openssl req -config ../../apps/openssl.cnf -verify -in req2CA.ss -noout => 0 ok 5 - verify request 2 certCA.ss: OK ../../util/shlib_wrap.sh ../../apps/openssl verify -CAfile certCA.ss certCA.ss => 0 ok 6 - verify signature Generating a RSA private key .........................+++++ .........+++++ writing new private key to 'keyU.ss' ----- ../../util/shlib_wrap.sh ../../apps/openssl req -config ../Uss.cnf -out reqU.ss -keyout keyU.ss -new > err.ss => 0 ok 7 - make a user cert request Signature ok subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2 Getting CA Private Key ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -CAcreateserial -in reqU.ss -days 30 -req -out certU.ss -CA certCA.ss -CAkey keyCA.ss -CAserial certCA.srl -extfile ../Uss.cnf -extensions v3_ee > err.ss => 0 certU.ss: OK ../../util/shlib_wrap.sh ../../apps/openssl verify -CAfile certCA.ss certU.ss => 0 ok 8 - sign user cert request # subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2 # issuer=C = AU, O = Dodgy Brothers, CN = Dodgy CA # notBefore=Apr 21 17:30:29 2020 GMT # notAfter=May 21 17:30:29 2020 GMT ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -subject -issuer -startdate -enddate -noout -in certU.ss => 0 ok 9 - Certificate details # Subtest: DSA certificate creation 1..5 Generating DSA key, 1024 bits ../../util/shlib_wrap.sh ../../apps/openssl gendsa -out keyD.ss ../../apps/dsa1024.pem > err.ss => 0 ok 1 - make a DSA key ../../util/shlib_wrap.sh ../../apps/openssl req -new -config ../Uss.cnf -out reqD.ss -key keyD.ss > err.ss => 0 ok 2 - make a DSA user cert request Signature ok subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = DSA Certificate Getting CA Private Key ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -CAcreateserial -in reqD.ss -days 30 -req -out certD.ss -CA certCA.ss -CAkey keyCA.ss -CAserial certCA.srl -extfile ../Uss.cnf -extensions v3_ee_dsa > err.ss => 0 ok 3 - sign DSA user cert request certD.ss: OK ../../util/shlib_wrap.sh ../../apps/openssl verify -CAfile certCA.ss certD.ss => 0 ok 4 - verify DSA user cert # subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = DSA Certificate # issuer=C = AU, O = Dodgy Brothers, CN = Dodgy CA # notBefore=Apr 21 17:30:29 2020 GMT # notAfter=May 21 17:30:29 2020 GMT ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -subject -issuer -startdate -enddate -noout -in certD.ss => 0 ok 5 - DSA Certificate details ok 10 - DSA certificate creation # Subtest: ECDSA/ECDH certificate creation 1..5 ../../util/shlib_wrap.sh ../../apps/openssl ecparam -name P-256 -out ecp.ss => 0 ok 1 - make EC parameters Generating an EC private key writing new private key to 'keyE.ss' ----- ../../util/shlib_wrap.sh ../../apps/openssl req -config ../Uss.cnf -out reqE.ss -keyout keyE.ss -newkey 'ec:ecp.ss' > err.ss => 0 ok 2 - make a ECDSA/ECDH user cert request Signature ok subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = ECDSA Certificate Getting CA Private Key ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -CAcreateserial -in reqE.ss -days 30 -req -out certE.ss -CA certCA.ss -CAkey keyCA.ss -CAserial certCA.srl -extfile ../Uss.cnf -extensions v3_ee_ec > err.ss => 0 ok 3 - sign ECDSA/ECDH user cert request certE.ss: OK ../../util/shlib_wrap.sh ../../apps/openssl verify -CAfile certCA.ss certE.ss => 0 ok 4 - verify ECDSA/ECDH user cert # subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = ECDSA Certificate # issuer=C = AU, O = Dodgy Brothers, CN = Dodgy CA # notBefore=Apr 21 17:30:30 2020 GMT # notAfter=May 21 17:30:30 2020 GMT ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -subject -issuer -startdate -enddate -noout -in certE.ss => 0 ok 5 - ECDSA Certificate details ok 11 - ECDSA/ECDH certificate creation Generating a RSA private key .................................+++++ .................................+++++ writing new private key to 'keyP1.ss' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:AU Organization Name (eg, company) []:Dodgy Brothers Common Name (eg, YOUR name) []:Brother 1 Common Name (eg, YOUR name) []:Brother 2 Common Name (eg, YOUR name) []:Proxy 1 ../../util/shlib_wrap.sh ../../apps/openssl req -config ../P1ss.cnf -out reqP1.ss -keyout keyP1.ss -new > err.ss => 0 ok 12 - make a proxy cert request Signature ok subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2, CN = Proxy 1 Getting CA Private Key ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -CAcreateserial -in reqP1.ss -days 30 -req -out certP1.ss -CA certU.ss -CAkey keyU.ss -extfile ../P1ss.cnf -extensions v3_proxy > err.ss => 0 ok 13 - sign proxy with user cert C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2, CN = Proxy 1 error 40 at 0 depth lookup: proxy certificates not allowed, please set the appropriate flag error certP1.ss: verification failed ../../util/shlib_wrap.sh ../../apps/openssl verify -CAfile certCA.ss -untrusted tmp_intP1.ss certP1.ss => 2 # subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2, CN = Proxy 1 # issuer=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2 # notBefore=Apr 21 17:30:30 2020 GMT # notAfter=May 21 17:30:30 2020 GMT ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -subject -issuer -startdate -enddate -noout -in certP1.ss => 0 ok 14 - Certificate details Generating a RSA private key ...........+++++ .........................................................................................................................................................................................................+++++ writing new private key to 'keyP2.ss' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:AU Organization Name (eg, company) []:Dodgy Brothers Common Name (eg, YOUR name) []:Brother 1 Common Name (eg, YOUR name) []:Brother 2 Common Name (eg, YOUR name) []:Proxy 1 Common Name (eg, YOUR name) []:Proxy 2 ../../util/shlib_wrap.sh ../../apps/openssl req -config ../P2ss.cnf -out reqP2.ss -keyout keyP2.ss -new > err.ss => 0 ok 15 - make another proxy cert request Signature ok subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2, CN = Proxy 1, CN = Proxy 2 Getting CA Private Key ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -CAcreateserial -in reqP2.ss -days 30 -req -out certP2.ss -CA certP1.ss -CAkey keyP1.ss -extfile ../P2ss.cnf -extensions v3_proxy > err.ss => 0 ok 16 - sign second proxy cert request with the first proxy cert C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2, CN = Proxy 1, CN = Proxy 2 error 40 at 0 depth lookup: proxy certificates not allowed, please set the appropriate flag error certP2.ss: verification failed ../../util/shlib_wrap.sh ../../apps/openssl verify -CAfile certCA.ss -untrusted tmp_intP2.ss certP2.ss => 2 # subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2, CN = Proxy 1, CN = Proxy 2 # issuer=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2, CN = Proxy 1 # notBefore=Apr 21 17:30:31 2020 GMT # notAfter=May 21 17:30:31 2020 GMT ../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -subject -issuer -startdate -enddate -noout -in certP2.ss => 0 ok 17 - Certificate details ok 1 - test_ss # test_ssl -- key U ../../util/shlib_wrap.sh ../../apps/openssl x509 -in certU.ss -text -noout => 0 # Subtest: standard SSL tests 1..13 ok 1 # skip SSLv3 is not supported by this OpenSSL build ok 2 # skip SSLv3 is not supported by this OpenSSL build ok 3 # skip SSLv3 is not supported by this OpenSSL build ok 4 # skip SSLv3 is not supported by this OpenSSL build Doing handshakes=1 bytes=256 TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair => 0 ok 5 - test sslv2/sslv3 via BIO pair Doing handshakes=1 bytes=256 TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -no_dhe -no_ecdhe => 0 ok 6 - test sslv2/sslv3 w/o (EC)DHE via BIO pair Doing handshakes=1 bytes=256 DONE via BIO pair: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -dhe1024dsa -v => 0 ok 7 - test sslv2/sslv3 with 1024bit DHE via BIO pair server authentication Doing handshakes=1 bytes=256 depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -server_auth -CAfile certCA.ss => 0 ok 8 - test sslv2/sslv3 with server authentication client authentication Doing handshakes=1 bytes=256 depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -client_auth -CAfile certCA.ss => 0 ok 9 - test sslv2/sslv3 with client authentication via BIO pair client authentication server authentication Doing handshakes=1 bytes=256 depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -server_auth -client_auth -CAfile certCA.ss => 0 ok 10 - test sslv2/sslv3 with both client and server authentication via BIO pair client authentication server authentication Doing handshakes=1 bytes=256 In app_verify_callback, allowing cert. Arg is: Test Callback Argument Finished printing do we have a context? 0x0x1c4fed3a200 a cert? 0x0x1c54fc5ce00 cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 In app_verify_callback, allowing cert. Arg is: Test Callback Argument Finished printing do we have a context? 0x0x1c5562e8c00 a cert? 0x0x1c4fed3de00 cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -server_auth -client_auth -app_verify -CAfile certCA.ss => 0 ok 11 - test sslv2/sslv3 with both client and server authentication via BIO pair and app verify Doing handshakes=1 bytes=256 TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -ipv4 => 0 ok 12 - test TLS via IPv4 0:error:0200E016:system library:setsockopt:Invalid argument:crypto/bio/b_sock2.c:255: 0:error:2008B088:BIO routines:BIO_listen:listen v6 only:crypto/bio/b_sock2.c:256: Doing handshakes=1 bytes=256 TLSv1.3, cipher (NONE) (NONE) ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -ipv6 => 1 not ok 13 - test TLS via IPv6 # Failed test 'test TLS via IPv6' # at ../test/recipes/80-test_ssl_old.t line 390. # Looks like you failed 1 test of 13. not ok 2 - standard SSL tests # Failed test 'standard SSL tests' # at /home/ca/pd/security/openssl-1.1.1g/test/../util/perl/OpenSSL/Test.pm line 1212. # Subtest: Testing ciphersuites ../../util/shlib_wrap.sh ../../apps/openssl ciphers -s -tls1_3 'ALL:-PSK:-SRP' => 0 ../../util/shlib_wrap.sh ../../apps/openssl ciphers -s -tls1_2 'ALL:-PSK:-SRP' => 0 ../../util/shlib_wrap.sh ../../apps/openssl ciphers -s -tls1 'ALL:-PSK:-SRP' => 0 1..102 ok 1 - Getting ciphers for -tls1_3 ok 2 - Getting ciphers for -tls1_2 ok 3 - Getting ciphers for -tls1 # Testing ciphersuites for -tls1 Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-ECDSA-AES256-SHA, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES256-SHA -ciphersuites '' -tls1 => 0 ok 4 - Testing ECDHE-ECDSA-AES256-SHA Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-RSA-AES256-SHA -ciphersuites '' -tls1 => 0 ok 5 - Testing ECDHE-RSA-AES256-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 DHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 1024 bits DH, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES256-SHA -ciphersuites '' -tls1 => 0 ok 6 - Testing DHE-RSA-AES256-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 DHE-DSS-AES256-SHA, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-AES256-SHA -ciphersuites '' -tls1 => 0 ok 7 - Testing DHE-DSS-AES256-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 DHE-RSA-CAMELLIA256-SHA, 2048 bits RSA, temp key: 1024 bits DH, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-CAMELLIA256-SHA -ciphersuites '' -tls1 => 0 ok 8 - Testing DHE-RSA-CAMELLIA256-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 DHE-DSS-CAMELLIA256-SHA, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-CAMELLIA256-SHA -ciphersuites '' -tls1 => 0 ok 9 - Testing DHE-DSS-CAMELLIA256-SHA Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-ECDSA-AES128-SHA, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES128-SHA -ciphersuites '' -tls1 => 0 ok 10 - Testing ECDHE-ECDSA-AES128-SHA Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-RSA-AES128-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-RSA-AES128-SHA -ciphersuites '' -tls1 => 0 ok 11 - Testing ECDHE-RSA-AES128-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 DHE-RSA-AES128-SHA, 2048 bits RSA, temp key: 1024 bits DH, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES128-SHA -ciphersuites '' -tls1 => 0 ok 12 - Testing DHE-RSA-AES128-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 DHE-DSS-AES128-SHA, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-AES128-SHA -ciphersuites '' -tls1 => 0 ok 13 - Testing DHE-DSS-AES128-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 DHE-RSA-SEED-SHA, 2048 bits RSA, temp key: 1024 bits DH, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-SEED-SHA -ciphersuites '' -tls1 => 0 ok 14 - Testing DHE-RSA-SEED-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 DHE-DSS-SEED-SHA, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-SEED-SHA -ciphersuites '' -tls1 => 0 ok 15 - Testing DHE-DSS-SEED-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 DHE-RSA-CAMELLIA128-SHA, 2048 bits RSA, temp key: 1024 bits DH, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-CAMELLIA128-SHA -ciphersuites '' -tls1 => 0 ok 16 - Testing DHE-RSA-CAMELLIA128-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 DHE-DSS-CAMELLIA128-SHA, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-CAMELLIA128-SHA -ciphersuites '' -tls1 => 0 ok 17 - Testing DHE-DSS-CAMELLIA128-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 AES256-SHA, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES256-SHA -ciphersuites '' -tls1 => 0 ok 18 - Testing AES256-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 CAMELLIA256-SHA, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher CAMELLIA256-SHA -ciphersuites '' -tls1 => 0 ok 19 - Testing CAMELLIA256-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 AES128-SHA, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES128-SHA -ciphersuites '' -tls1 => 0 ok 20 - Testing AES128-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 SEED-SHA, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher SEED-SHA -ciphersuites '' -tls1 => 0 ok 21 - Testing SEED-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 CAMELLIA128-SHA, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher CAMELLIA128-SHA -ciphersuites '' -tls1 => 0 ok 22 - Testing CAMELLIA128-SHA Doing handshakes=1 bytes=256 TLSv1, cipher SSLv3 IDEA-CBC-SHA, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher IDEA-CBC-SHA -ciphersuites '' -tls1 => 0 ok 23 - Testing IDEA-CBC-SHA 0:error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small:ssl/s3_lib.c:3782: 0:error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small:ssl/s3_lib.c:3782: ERROR in SERVER 0:error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl/statem/statem_srvr.c:2284: Doing handshakes=1 bytes=256 TLSv1, cipher (NONE) (NONE) ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cipher EDH -c_cipher 'EDH:@SECLEVEL=1' -dhe512 -tls1 => 1 ok 24 - testing connection with weak DH, expecting failure # Testing ciphersuites for -tls1_2 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES256-GCM-SHA384 -ciphersuites '' -tls1_2 => 0 ok 25 - Testing ECDHE-ECDSA-AES256-GCM-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-RSA-AES256-GCM-SHA384 -ciphersuites '' -tls1_2 => 0 ok 26 - Testing ECDHE-RSA-AES256-GCM-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-DSS-AES256-GCM-SHA384, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-AES256-GCM-SHA384 -ciphersuites '' -tls1_2 => 0 ok 27 - Testing DHE-DSS-AES256-GCM-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES256-GCM-SHA384 -ciphersuites '' -tls1_2 => 0 ok 28 - Testing DHE-RSA-AES256-GCM-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-CHACHA20-POLY1305, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-CHACHA20-POLY1305 -ciphersuites '' -tls1_2 => 0 ok 29 - Testing ECDHE-ECDSA-CHACHA20-POLY1305 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-RSA-CHACHA20-POLY1305 -ciphersuites '' -tls1_2 => 0 ok 30 - Testing ECDHE-RSA-CHACHA20-POLY1305 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-CHACHA20-POLY1305, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-CHACHA20-POLY1305 -ciphersuites '' -tls1_2 => 0 ok 31 - Testing DHE-RSA-CHACHA20-POLY1305 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-CCM8, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES256-CCM8 -ciphersuites '' -tls1_2 => 0 ok 32 - Testing ECDHE-ECDSA-AES256-CCM8 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-CCM, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES256-CCM -ciphersuites '' -tls1_2 => 0 ok 33 - Testing ECDHE-ECDSA-AES256-CCM Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-CCM8, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES256-CCM8 -ciphersuites '' -tls1_2 => 0 ok 34 - Testing DHE-RSA-AES256-CCM8 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-CCM, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES256-CCM -ciphersuites '' -tls1_2 => 0 ok 35 - Testing DHE-RSA-AES256-CCM Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-ARIA256-GCM-SHA384, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-ARIA256-GCM-SHA384 -ciphersuites '' -tls1_2 => 0 ok 36 - Testing ECDHE-ECDSA-ARIA256-GCM-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ARIA256-GCM-SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ARIA256-GCM-SHA384 -ciphersuites '' -tls1_2 => 0 ok 37 - Testing ECDHE-ARIA256-GCM-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-DSS-ARIA256-GCM-SHA384, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-ARIA256-GCM-SHA384 -ciphersuites '' -tls1_2 => 0 ok 38 - Testing DHE-DSS-ARIA256-GCM-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-ARIA256-GCM-SHA384, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-ARIA256-GCM-SHA384 -ciphersuites '' -tls1_2 => 0 ok 39 - Testing DHE-RSA-ARIA256-GCM-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -ciphersuites '' -tls1_2 => 0 ok 40 - Testing ECDHE-ECDSA-AES128-GCM-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-RSA-AES128-GCM-SHA256 -ciphersuites '' -tls1_2 => 0 ok 41 - Testing ECDHE-RSA-AES128-GCM-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-DSS-AES128-GCM-SHA256, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-AES128-GCM-SHA256 -ciphersuites '' -tls1_2 => 0 ok 42 - Testing DHE-DSS-AES128-GCM-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-AES128-GCM-SHA256, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES128-GCM-SHA256 -ciphersuites '' -tls1_2 => 0 ok 43 - Testing DHE-RSA-AES128-GCM-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES128-CCM8, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES128-CCM8 -ciphersuites '' -tls1_2 => 0 ok 44 - Testing ECDHE-ECDSA-AES128-CCM8 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES128-CCM, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES128-CCM -ciphersuites '' -tls1_2 => 0 ok 45 - Testing ECDHE-ECDSA-AES128-CCM Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-AES128-CCM8, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES128-CCM8 -ciphersuites '' -tls1_2 => 0 ok 46 - Testing DHE-RSA-AES128-CCM8 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-AES128-CCM, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES128-CCM -ciphersuites '' -tls1_2 => 0 ok 47 - Testing DHE-RSA-AES128-CCM Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-ARIA128-GCM-SHA256, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-ARIA128-GCM-SHA256 -ciphersuites '' -tls1_2 => 0 ok 48 - Testing ECDHE-ECDSA-ARIA128-GCM-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ARIA128-GCM-SHA256, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ARIA128-GCM-SHA256 -ciphersuites '' -tls1_2 => 0 ok 49 - Testing ECDHE-ARIA128-GCM-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-DSS-ARIA128-GCM-SHA256, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-ARIA128-GCM-SHA256 -ciphersuites '' -tls1_2 => 0 ok 50 - Testing DHE-DSS-ARIA128-GCM-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-ARIA128-GCM-SHA256, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-ARIA128-GCM-SHA256 -ciphersuites '' -tls1_2 => 0 ok 51 - Testing DHE-RSA-ARIA128-GCM-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-SHA384, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES256-SHA384 -ciphersuites '' -tls1_2 => 0 ok 52 - Testing ECDHE-ECDSA-AES256-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-RSA-AES256-SHA384 -ciphersuites '' -tls1_2 => 0 ok 53 - Testing ECDHE-RSA-AES256-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-SHA256, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES256-SHA256 -ciphersuites '' -tls1_2 => 0 ok 54 - Testing DHE-RSA-AES256-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-DSS-AES256-SHA256, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-AES256-SHA256 -ciphersuites '' -tls1_2 => 0 ok 55 - Testing DHE-DSS-AES256-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-CAMELLIA256-SHA384, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-CAMELLIA256-SHA384 -ciphersuites '' -tls1_2 => 0 ok 56 - Testing ECDHE-ECDSA-CAMELLIA256-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-RSA-CAMELLIA256-SHA384, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-RSA-CAMELLIA256-SHA384 -ciphersuites '' -tls1_2 => 0 ok 57 - Testing ECDHE-RSA-CAMELLIA256-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-CAMELLIA256-SHA256, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-CAMELLIA256-SHA256 -ciphersuites '' -tls1_2 => 0 ok 58 - Testing DHE-RSA-CAMELLIA256-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-DSS-CAMELLIA256-SHA256, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-CAMELLIA256-SHA256 -ciphersuites '' -tls1_2 => 0 ok 59 - Testing DHE-DSS-CAMELLIA256-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES128-SHA256, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES128-SHA256 -ciphersuites '' -tls1_2 => 0 ok 60 - Testing ECDHE-ECDSA-AES128-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES128-SHA256, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-RSA-AES128-SHA256 -ciphersuites '' -tls1_2 => 0 ok 61 - Testing ECDHE-RSA-AES128-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-AES128-SHA256, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES128-SHA256 -ciphersuites '' -tls1_2 => 0 ok 62 - Testing DHE-RSA-AES128-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-DSS-AES128-SHA256, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-AES128-SHA256 -ciphersuites '' -tls1_2 => 0 ok 63 - Testing DHE-DSS-AES128-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-CAMELLIA128-SHA256, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-CAMELLIA128-SHA256 -ciphersuites '' -tls1_2 => 0 ok 64 - Testing ECDHE-ECDSA-CAMELLIA128-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ECDHE-RSA-CAMELLIA128-SHA256, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-RSA-CAMELLIA128-SHA256 -ciphersuites '' -tls1_2 => 0 ok 65 - Testing ECDHE-RSA-CAMELLIA128-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-RSA-CAMELLIA128-SHA256, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-CAMELLIA128-SHA256 -ciphersuites '' -tls1_2 => 0 ok 66 - Testing DHE-RSA-CAMELLIA128-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 DHE-DSS-CAMELLIA128-SHA256, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-CAMELLIA128-SHA256 -ciphersuites '' -tls1_2 => 0 ok 67 - Testing DHE-DSS-CAMELLIA128-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.0 ECDHE-ECDSA-AES256-SHA, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES256-SHA -ciphersuites '' -tls1_2 => 0 ok 68 - Testing ECDHE-ECDSA-AES256-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-RSA-AES256-SHA -ciphersuites '' -tls1_2 => 0 ok 69 - Testing ECDHE-RSA-AES256-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 DHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES256-SHA -ciphersuites '' -tls1_2 => 0 ok 70 - Testing DHE-RSA-AES256-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 DHE-DSS-AES256-SHA, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-AES256-SHA -ciphersuites '' -tls1_2 => 0 ok 71 - Testing DHE-DSS-AES256-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 DHE-RSA-CAMELLIA256-SHA, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-CAMELLIA256-SHA -ciphersuites '' -tls1_2 => 0 ok 72 - Testing DHE-RSA-CAMELLIA256-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 DHE-DSS-CAMELLIA256-SHA, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-CAMELLIA256-SHA -ciphersuites '' -tls1_2 => 0 ok 73 - Testing DHE-DSS-CAMELLIA256-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.0 ECDHE-ECDSA-AES128-SHA, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-ECDSA-AES128-SHA -ciphersuites '' -tls1_2 => 0 ok 74 - Testing ECDHE-ECDSA-AES128-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.0 ECDHE-RSA-AES128-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ECDHE-RSA-AES128-SHA -ciphersuites '' -tls1_2 => 0 ok 75 - Testing ECDHE-RSA-AES128-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 DHE-RSA-AES128-SHA, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-AES128-SHA -ciphersuites '' -tls1_2 => 0 ok 76 - Testing DHE-RSA-AES128-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 DHE-DSS-AES128-SHA, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-AES128-SHA -ciphersuites '' -tls1_2 => 0 ok 77 - Testing DHE-DSS-AES128-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 DHE-RSA-SEED-SHA, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-SEED-SHA -ciphersuites '' -tls1_2 => 0 ok 78 - Testing DHE-RSA-SEED-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 DHE-DSS-SEED-SHA, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-SEED-SHA -ciphersuites '' -tls1_2 => 0 ok 79 - Testing DHE-DSS-SEED-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 DHE-RSA-CAMELLIA128-SHA, 2048 bits RSA, temp key: 1024 bits DH, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-RSA-CAMELLIA128-SHA -ciphersuites '' -tls1_2 => 0 ok 80 - Testing DHE-RSA-CAMELLIA128-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 DHE-DSS-CAMELLIA128-SHA, 1024 bits DSA, temp key: 1024 bits DH, digest=SHA224 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher DHE-DSS-CAMELLIA128-SHA -ciphersuites '' -tls1_2 => 0 ok 81 - Testing DHE-DSS-CAMELLIA128-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 AES256-GCM-SHA384, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES256-GCM-SHA384 -ciphersuites '' -tls1_2 => 0 ok 82 - Testing AES256-GCM-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 AES256-CCM8, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES256-CCM8 -ciphersuites '' -tls1_2 => 0 ok 83 - Testing AES256-CCM8 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 AES256-CCM, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES256-CCM -ciphersuites '' -tls1_2 => 0 ok 84 - Testing AES256-CCM Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ARIA256-GCM-SHA384, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ARIA256-GCM-SHA384 -ciphersuites '' -tls1_2 => 0 ok 85 - Testing ARIA256-GCM-SHA384 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 AES128-GCM-SHA256, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES128-GCM-SHA256 -ciphersuites '' -tls1_2 => 0 ok 86 - Testing AES128-GCM-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 AES128-CCM8, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES128-CCM8 -ciphersuites '' -tls1_2 => 0 ok 87 - Testing AES128-CCM8 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 AES128-CCM, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES128-CCM -ciphersuites '' -tls1_2 => 0 ok 88 - Testing AES128-CCM Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 ARIA128-GCM-SHA256, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher ARIA128-GCM-SHA256 -ciphersuites '' -tls1_2 => 0 ok 89 - Testing ARIA128-GCM-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 AES256-SHA256, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES256-SHA256 -ciphersuites '' -tls1_2 => 0 ok 90 - Testing AES256-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 CAMELLIA256-SHA256, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher CAMELLIA256-SHA256 -ciphersuites '' -tls1_2 => 0 ok 91 - Testing CAMELLIA256-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 AES128-SHA256, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES128-SHA256 -ciphersuites '' -tls1_2 => 0 ok 92 - Testing AES128-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher TLSv1.2 CAMELLIA128-SHA256, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher CAMELLIA128-SHA256 -ciphersuites '' -tls1_2 => 0 ok 93 - Testing CAMELLIA128-SHA256 Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 AES256-SHA, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES256-SHA -ciphersuites '' -tls1_2 => 0 ok 94 - Testing AES256-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 CAMELLIA256-SHA, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher CAMELLIA256-SHA -ciphersuites '' -tls1_2 => 0 ok 95 - Testing CAMELLIA256-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 AES128-SHA, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher AES128-SHA -ciphersuites '' -tls1_2 => 0 ok 96 - Testing AES128-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 SEED-SHA, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher SEED-SHA -ciphersuites '' -tls1_2 => 0 ok 97 - Testing SEED-SHA Doing handshakes=1 bytes=256 TLSv1.2, cipher SSLv3 CAMELLIA128-SHA, 2048 bits RSA ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher CAMELLIA128-SHA -ciphersuites '' -tls1_2 => 0 ok 98 - Testing CAMELLIA128-SHA 0:error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small:ssl/s3_lib.c:3782: 0:error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small:ssl/s3_lib.c:3782: ERROR in SERVER 0:error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl/statem/statem_srvr.c:2284: Doing handshakes=1 bytes=256 TLSv1.2, cipher (NONE) (NONE) ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cipher EDH -c_cipher 'EDH:@SECLEVEL=1' -dhe512 -tls1_2 => 1 ok 99 - testing connection with weak DH, expecting failure # Testing ciphersuites for -tls1_3 Doing handshakes=1 bytes=256 TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher '' -ciphersuites TLS_AES_256_GCM_SHA384 => 0 ok 100 - Testing Doing handshakes=1 bytes=256 TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher '' -ciphersuites TLS_CHACHA20_POLY1305_SHA256 => 0 ok 101 - Testing Doing handshakes=1 bytes=256 TLSv1.3, cipher TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bits EC (P-256), temp key: 253 bits X25519, digest=SHA256 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cert certD.ss -s_key keyD.ss -s_cert certE.ss -s_key keyE.ss -cipher '' -ciphersuites TLS_AES_128_GCM_SHA256 => 0 ok 102 - Testing ok 3 - Testing ciphersuites # Subtest: RSA/(EC)DHE/PSK tests 1..5 Doing handshakes=10 bytes=256 DONE via BIO pair: TLSv1, cipher SSLv3 ADH-AES256-SHA, temp key: 1024 bits DH DONE via BIO pair: TLSv1, cipher SSLv3 ADH-AES256-SHA, temp key: 1024 bits DH DONE via BIO pair: TLSv1, cipher SSLv3 ADH-AES256-SHA, temp key: 1024 bits DH DONE via BIO pair: TLSv1, cipher SSLv3 ADH-AES256-SHA, temp key: 1024 bits DH DONE via BIO pair: TLSv1, cipher SSLv3 ADH-AES256-SHA, temp key: 1024 bits DH DONE via BIO pair: TLSv1, cipher SSLv3 ADH-AES256-SHA, temp key: 1024 bits DH DONE via BIO pair: TLSv1, cipher SSLv3 ADH-AES256-SHA, temp key: 1024 bits DH DONE via BIO pair: TLSv1, cipher SSLv3 ADH-AES256-SHA, temp key: 1024 bits DH DONE via BIO pair: TLSv1, cipher SSLv3 ADH-AES256-SHA, temp key: 1024 bits DH DONE via BIO pair: TLSv1, cipher SSLv3 ADH-AES256-SHA, temp key: 1024 bits DH Approximate total server time: 0.01 s Approximate total client time: 0.02 s ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -v -bio_pair -tls1 -cipher ADH -dhe1024dsa -num 10 -f -time => 0 ok 1 - test tlsv1 with 1024bit anonymous DH, multiple handshakes Doing handshakes=10 bytes=256 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 Approximate total server time: 0.04 s Approximate total client time: 0.01 s ../../util/shlib_wrap.sh ../ssltest_old -v -bio_pair -tls1 -s_cert ../../apps/server2.pem -no_dhe -no_ecdhe -num 10 -f -time => 0 ok 2 - test tlsv1 with 1024bit RSA, no (EC)DHE, multiple handshakes Doing handshakes=10 bytes=256 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 DONE via BIO pair: TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 Approximate total server time: 0.03 s Approximate total client time: 0.02 s ../../util/shlib_wrap.sh ../ssltest_old -v -bio_pair -tls1 -s_cert ../../apps/server2.pem -dhe1024dsa -num 10 -f -time => 0 ok 3 - test tlsv1 with 1024bit RSA, 1024bit DHE, multiple handshakes Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-PSK-AES256-CBC-SHA384, temp key: 253 bits X25519 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -tls1 -cipher PSK -psk abc123 => 0 ok 4 - test tls1 with PSK Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-PSK-AES256-CBC-SHA384, temp key: 253 bits X25519 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -tls1 -cipher PSK -psk abc123 => 0 ok 5 - test tls1 with PSK via BIO pair ok 4 - RSA/(EC)DHE/PSK tests # Subtest: Custom Extension tests 1..1 Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -tls1 -custom_ext => 0 ok 1 - test tls1 with custom extensions ok 5 - Custom Extension tests # Subtest: Serverinfo tests 1..5 # echo test tls1 with serverinfo Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -tls1 -serverinfo_file ../serverinfo.pem => 0 ok 1 Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -tls1 -serverinfo_file ../serverinfo.pem -serverinfo_sct => 0 ok 2 Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -tls1 -serverinfo_file ../serverinfo.pem -serverinfo_tack => 0 ok 3 Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -tls1 -serverinfo_file ../serverinfo.pem -serverinfo_sct -serverinfo_tack => 0 ok 4 Doing handshakes=1 bytes=256 TLSv1, cipher TLSv1.0 ECDHE-RSA-AES256-SHA, 2048 bits RSA, temp key: 253 bits X25519, digest=MD5-SHA1 ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -bio_pair -tls1 -custom_ext -serverinfo_file ../serverinfo.pem -serverinfo_sct -serverinfo_tack => 0 ok 5 ok 6 - Serverinfo tests # Looks like you failed 1 test of 6. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/6 subtests Test Summary Report ------------------- ../test/recipes/80-test_ssl_old.t (Wstat: 256 Tests: 6 Failed: 1) Failed test: 2 Non-zero exit status: 1 Files=1, Tests=6, 12 wallclock secs ( 0.04 usr 0.06 sys + 1.77 cusr 9.78 csys = 11.65 CPU) Result: FAIL *** Error 1 in . (Makefile:217 '_tests') *** Error 1 in /home/ca/pd/security/openssl-1.1.1g (Makefile:205 'tests') From openssl-users at dukhovni.org Tue Apr 21 17:34:30 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 21 Apr 2020 13:34:30 -0400 Subject: questions on using ed25519 In-Reply-To: References: Message-ID: <20200421173430.GG41308@straasha.imrryr.org> On Tue, Apr 21, 2020 at 05:48:19PM +0800, yang berlin wrote: > I want to use ed25519 in openssl. Why? What actual real-world purpose do you have for ed25519? > The problem I met is: I can use "speed ed25519" to test the speed of > ed25519, but when I use "dgst -ed25519", it tells me that "dgst: > Unrecognized flag Ed25519". That's because "ed25519" is not a digest algorithm, it is a public key algorithm. You can use it to sign messages, but not to compute message digests. > So could you please help me to learn how to use ed25519 correctly? That question has no answer. Whether a use of "ed25519" is correct or incorrect depends on the security protocol in which it is to be used, and whether that protocol is appropriate to security requirements of the application using it. If you're just playing with ed25519, you can generate ed25519 keys with: $ openssl genpkey -algorithm ed25519 -out privkey.pem You can extract just the public key via: $ openssl pkey -in privkey.pem -pubout -out pubkey.pem You can generate an ed25519 self-signed public key certificate with: $ openssl req -key privkey.pem -new \ -x509 -subj "/CN=$(uname -n)" -days 36500 -out pubcert.pem You can use the key and certificate with s_client, and s_server via the "-key" and "-cert" arguments. You can also sign and/or encrypt messages with ed25519 using cms(1), but you may not be ready to dive into cms. Low-level public and private key operations are possible via pkeyutl(1). While the dgst(1) command supports signing message digests with various public key signature algorithms, ed25519 is not one of these: -sign filename Digitally sign the digest using the private key in "filename". Note this option does not support Ed25519 or Ed448 private keys. Use the pkeyutl command instead for this. See the pkeyutl(1) manpage. Don't assume that some use of encryption implies any gain in security. It could be mere security theatre. For actual security you need to apply a robust protocol that matches the application's security requirements. -- Viktor. From quanah at symas.com Tue Apr 21 17:55:41 2020 From: quanah at symas.com (Quanah Gibson-Mount) Date: Tue, 21 Apr 2020 10:55:41 -0700 Subject: empty directory in the 1.1.1 series release tags In-Reply-To: <5f27d983-07f8-3be6-a911-11cbe9eaa3ed@gemtalksystems.com> References: <08DF2FEBB606C30ECC9D4335@[192.168.1.144]> <20200421171609.GX3811@akamai.com> <5f27d983-07f8-3be6-a911-11cbe9eaa3ed@gemtalksystems.com> Message-ID: --On Tuesday, April 21, 2020 11:25 AM -0700 Norm Green wrote: > >I use the git release tags, not the tarballs. > > I do too, and I suspect many others do as well. > The empty krb5 directory has not caused grief for me, but it would be > nice if the git release tag directory structure matched the tarball. I ended up doing a git rm on the krb5 dir, and then the rest of the tags all went in fine (I was last on 1.1.1d). But I agree, overall I would expect the release tags to match the release tarballs. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From levitte at openssl.org Tue Apr 21 18:17:21 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 21 Apr 2020 20:17:21 +0200 Subject: empty directory in the 1.1.1 series release tags In-Reply-To: References: <08DF2FEBB606C30ECC9D4335@[192.168.1.144]> <20200421171609.GX3811@akamai.com> <5f27d983-07f8-3be6-a911-11cbe9eaa3ed@gemtalksystems.com> Message-ID: <87lfmoema6.wl-levitte@openssl.org> On Tue, 21 Apr 2020 19:55:41 +0200, Quanah Gibson-Mount wrote: > --On Tuesday, April 21, 2020 11:25 AM -0700 Norm Green > wrote: > > > >I use the git release tags, not the tarballs. > > > > I do too, and I suspect many others do as well. > > The empty krb5 directory has not caused grief for me, but it would be > > nice if the git release tag directory structure matched the tarball. > > I ended up doing a git rm on the krb5 dir, and then the rest of the > tags all went in fine (I was last on 1.1.1d). But I agree, overall I > would expect the release tags to match the release tarballs. To be a bit blunt, that's simply not reasonable. There are a number of files and directories, not the least diverse git related files, that are never going to make it into the tarball. Have a look at .gitattributes, you have a number of patterns there with the attribute 'export-ignore'. Those are files that don't make it into the tarball. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From jb-openssl at wisemo.com Tue Apr 21 19:29:58 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 21 Apr 2020 21:29:58 +0200 Subject: TLSv1 on CentOS-8 In-Reply-To: References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> <5d0125b4e2b625ecf5de73ff7f676b3cab4b9d8b.camel@redhat.com> <20200417170318.GC41308@straasha.imrryr.org> Message-ID: <6410386f-91ad-cd4c-3bb9-e2c1b50120d4@wisemo.com> That link shows whatever anyone's browser is configured to handle when clicking the link. The important thing is which browsers you need to support, like the ones on https://www.ssllabs.com/ssltest/clients.html Beware that the list I just linked is woefully incomplete for those of us who actively target "any browser" support, especially when including old stuff like Windows Mobile 5 and Windows XP. On 21/04/2020 17:06, Junaid Mukhtar wrote: > Hi Tomas/Team > > I have managed to block the RC4 and enable tlsv1 as per our requirements. > > We have a requirement to match cipher list on the internal server to > match the native browser cipher list as shown by the > https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html > > I have tried setting up different combinations on the CipherString but > none helped. Do you have any suggestions as to how to do achieve this? > > > On Fri, Apr 17, 2020 at 6:22 PM Tomas Mraz > wrote: > > On Fri, 2020-04-17 at 13:03 -0400, Viktor Dukhovni wrote: > > On Fri, Apr 17, 2020 at 05:17:47PM +0200, Tomas Mraz wrote: > > > > > Or you could modify the /etc/pki/tls/openssl.cnf: > > > Find the .include /etc/crypto-policies/back-ends/opensslcnf.config > > > line in it and insert something like: > > > > > > CipherString = > > > > @SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!DES:!RC2:!RC4: > > > !IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 > > > > How did this particular contraption become a recommended cipherlist? > > To explain - this is basically autogenerated value from the crypto > policy definiton of the LEGACY crypto policy with just added the > !RC4. > > > > What's wrong with "DEFAULT"?? In OpenSSL 1.1.1 it already excludes > > RC4 (if RC4 is at all enabled at compile time): > > Nothing wrong with DEFAULT. For manual configuration. This is however > something that is autogenerated. > > >? ? ?$ openssl ciphers -v 'COMPLEMENTOFDEFAULT+RC4' > >? ? ?ECDHE-ECDSA-RC4-SHA? ? ?TLSv1 Kx=ECDH? ? ?Au=ECDSA Enc=RC4(128) > > Mac=SHA1 > >? ? ?ECDHE-RSA-RC4-SHA? ? ? ?TLSv1 > > Kx=ECDH? ? ?Au=RSA? Enc=RC4(128)? Mac=SHA1 > >? ? ?RC4-SHA? ? ? ? ? ? ? ? ?SSLv3 > > Kx=RSA? ? ? Au=RSA? Enc=RC4(128)? Mac=SHA1 > > > > I find too many people cargo-culting poorly thought cipher lists > from > > some random HOWTO.? Over optimising your cipherlist is subject to > > rapid bitrot, resist the temptation... > > Yeah, I should have probably suggested just: CipherString = DEFAULT > > There is not much point in being as close to the autogenerated policy > as possible for this particular user's use-case. > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From vieuxtech at gmail.com Tue Apr 21 19:46:43 2020 From: vieuxtech at gmail.com (Sam Roberts) Date: Tue, 21 Apr 2020 12:46:43 -0700 Subject: OpenSSL Security Advisory In-Reply-To: <20200421132524.GA5046@openssl.org> References: <20200421132524.GA5046@openssl.org> Message-ID: The announcement claims that this affects SSL_check_chain(). Is that an exhaustive list? If an application does NOT call that function, does this mean the vulnerability is not exploitable? I ask because the the fixed function tls1_check_sig_alg is called by tls1_check_chain, and that is called directly by SSL_check_chain, but it is also called by tls1_set_cert_validity, and that is called from inside the tls state machine, but with different parameters, so its a bit hard to see if it is affected or not. Thanks, Sam On Tue, Apr 21, 2020 at 6:26 AM OpenSSL wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > OpenSSL Security Advisory [21 April 2020] > ========================================= > > Segmentation fault in SSL_check_chain (CVE-2020-1967) > ===================================================== > > Severity: High > > Server or client applications that call the SSL_check_chain() function during or > after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a > result of incorrect handling of the "signature_algorithms_cert" TLS extension. > The crash occurs if an invalid or unrecognised signature algorithm is received > from the peer. This could be exploited by a malicious peer in a Denial of > Service attack. > > OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This > issue did not affect OpenSSL versions prior to 1.1.1d. > > Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g > > This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April > 2020. It was found using the new static analysis pass being implemented in GCC, > - -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin > Kaduk. > > Note > ===== > > This issue did not affect OpenSSL 1.0.2 however these versions are out of > support and no longer receiving public updates. Extended support is available > for premium support customers: https://www.openssl.org/support/contracts.html > > This issue did not affect OpenSSL 1.1.0 however these versions are out of > support and no longer receiving updates. > > Users of these versions should upgrade to OpenSSL 1.1.1. > > References > ========== > > URL for this Security Advisory: > https://www.openssl.org/news/secadv/20200421.txt > > Note: the online version of the advisory may be updated with additional details > over time. > > For details of OpenSSL severity classifications please see: > https://www.openssl.org/policies/secpolicy.html > -----BEGIN PGP SIGNATURE----- > > iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6e8uwACgkQ2cTSbQ5g > RJHHRgf+J8iVBuK6EoOvf9xm9geiDgYVFse9ckMXH92gdGbwsW4uhTNk9fCyNC+t > vsf6YGT6nKJarB5+N+LC4QB7VLo/DjlYcN9zP3mubV0eEyKHSoW6tDOWPpJ0gsbt > 2Z9iTA4GnofvhBcWLiPGgv4IUHknsOaPkRmEppSF0fDTSKuYOerfNRh9jTKHulis > Ph6dCOXE3kb5HfMwVj3UN2sP92XTig4FzpIQaZ1/2jKZaRXtzJD7pvu1fDCTkUGl > aeta5jHNypYyRKJLuJ1+1DiBtbWTFAWMUCHlkg/kgdU4hIl/lo3vgAyFs/9mQxZQ > vj2rIjoJHRj0EXqXhHoABqBHedilJQ== > =AXyP > -----END PGP SIGNATURE----- From bkaduk at akamai.com Tue Apr 21 19:48:47 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 21 Apr 2020 12:48:47 -0700 Subject: OpenSSL Security Advisory In-Reply-To: References: <20200421132524.GA5046@openssl.org> Message-ID: <20200421194846.GA3811@akamai.com> On Tue, Apr 21, 2020 at 12:46:43PM -0700, Sam Roberts wrote: > The announcement claims that this affects SSL_check_chain(). > > Is that an exhaustive list? If an application does NOT call that > function, does this mean the vulnerability is not exploitable? That is correct (speaking only in terms of public APIs). > I ask because the the fixed function tls1_check_sig_alg is called by > tls1_check_chain, and that is called directly by SSL_check_chain, but > it is also called by tls1_set_cert_validity, and that is called from > inside the tls state machine, but with different parameters, so its a > bit hard to see if it is affected or not. As you note, the valid call chains are a bit convoluted, but the relevant codepath is only exercised for TLS 1.3 and SSL_check_chain(). -Ben From jb-openssl at wisemo.com Tue Apr 21 19:54:39 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 21 Apr 2020 21:54:39 +0200 Subject: opensssl 1.1.1g test failure(s) In-Reply-To: <20200421173406.GA4489@kiel.esmtp.org> References: <20200421172238.GA58719@kiel.esmtp.org> <20200421172709.GZ3811@akamai.com> <20200421173406.GA4489@kiel.esmtp.org> Message-ID: <4257993d-e040-8ff5-cc1e-bf47fc44b676@wisemo.com> Summary: The OpenSSL 1.1.1g test suite contains at least two bugs: TestBug#1: Test suite fails if local network has no IPv6, error message (non- ? verbose) doesn't say that's the issue.? [ Testing IPv6 makes sense, rejecting ? regression tests on inadequate machines is important to avoid silent failures, ? but not telling testers that a test precondition failed or which ones is bad. ? ] TestBug#2: Test suite uses ambiguous wording to report the index of failed test. ? Should have said "Failed test indexes:? 2" or "Failed test: #2" (latter ? needs to repeat "#" for each index listed) On 21/04/2020 19:34, Claus Assmann wrote: > On Tue, Apr 21, 2020, Benjamin Kaduk via openssl-users wrote: >> On Tue, Apr 21, 2020 at 07:22:38PM +0200, Claus Assmann wrote: >>> ../test/recipes/80-test_ssl_old.t .................. >>> Dubious, test returned 1 (wstat 256, 0x100) >> Please run again with `make V=1 TESTS=test_ssl_old test` and post the relevant parts of the output? > Thanks for the reply, below is the output, It seems it only fails > because the host doesn't support IPv6? > > make depend && make _tests > ( cd test; mkdir -p test-runs; SRCTOP=../. BLDTOP=../. RESULT_D=test-runs PERL="/usr/bin/perl" EXE_EXT= OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` OPENSSL_DEBUG_MEMORY=on /usr/bin/perl .././test/run_tests.pl test_ssl_old ) > ../test/recipes/80-test_ssl_old.t .. > 1..6 > # Subtest: test_ss > 1..17 ... > 0:error:0200E016:system library:setsockopt:Invalid argument:crypto/bio/b_sock2.c:255: > 0:error:2008B088:BIO routines:BIO_listen:listen v6 only:crypto/bio/b_sock2.c:256: > Doing handshakes=1 bytes=256 > TLSv1.3, cipher (NONE) (NONE) > ../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -ipv6 => 1 > not ok 13 - test TLS via IPv6 > # Failed test 'test TLS via IPv6' > # at ../test/recipes/80-test_ssl_old.t line 390. > # Looks like you failed 1 test of 13. > not ok 2 - standard SSL tests > # Failed test 'standard SSL tests' > # at /home/ca/pd/security/openssl-1.1.1g/test/../util/perl/OpenSSL/Test.pm line 1212. ... > # Looks like you failed 1 test of 6. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/6 subtests > > Test Summary Report > ------------------- > ../test/recipes/80-test_ssl_old.t (Wstat: 256 Tests: 6 Failed: 1) > Failed test: 2 > Non-zero exit status: 1 > Files=1, Tests=6, 12 wallclock secs ( 0.04 usr 0.06 sys + 1.77 cusr 9.78 csys = 11.65 CPU) > Result: FAIL > *** Error 1 in . (Makefile:217 '_tests') > *** Error 1 in /home/ca/pd/security/openssl-1.1.1g (Makefile:205 'tests') Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From markwhozer at gmail.com Tue Apr 21 19:57:02 2020 From: markwhozer at gmail.com (Mark Windshield) Date: Tue, 21 Apr 2020 21:57:02 +0200 Subject: How to disable renegation before compiling openssl Message-ID: Hello, I was wondering what I'd have to change in the openssl code/config before compiling to have renegation disabled by default, so it won't send the Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) when using curl. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Tue Apr 21 20:06:39 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 21 Apr 2020 13:06:39 -0700 Subject: How to disable renegation before compiling openssl In-Reply-To: References: Message-ID: <20200421200638.GB3811@akamai.com> On Tue, Apr 21, 2020 at 09:57:02PM +0200, Mark Windshield wrote: > Hello, > > I was wondering what I'd have to change in the openssl code/config before > compiling to have renegation disabled by default, so it won't send the > Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) when using curl. This description does not really make it clear whether you just want to prevent renegotiation or specifically need this SCSV value to not be included in the ClientHello -- the semantics of TLS_EMPTY_RENEGOTIATION_INFO_SCSV is "if renegotiation occurs, the client supports the 'secure' variant", but is otherwise orthogonal to whether renegotiation itself actually occurs. -Ben From openssl-users at dukhovni.org Tue Apr 21 20:09:28 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 21 Apr 2020 16:09:28 -0400 Subject: TLSv1 on CentOS-8 In-Reply-To: References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> <5d0125b4e2b625ecf5de73ff7f676b3cab4b9d8b.camel@redhat.com> <20200417170318.GC41308@straasha.imrryr.org> Message-ID: <20200421200928.GH41308@straasha.imrryr.org> On Tue, Apr 21, 2020 at 04:06:04PM +0100, Junaid Mukhtar wrote: > I have managed to block the RC4 and enable tlsv1 as per our requirements. > > We have a requirement to match cipher list on the internal server to match > the native browser cipher list as shown by the > https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html That requirement is likely ill-considered and unwise. You end up freezing in a stale list that was somebody's idea of best practice at a point in time, often for a specific use-case that may not be yours, and sometimes without understanding what they're doing. > I have tried setting up different combinations on the CipherString but none > helped. Do you have any suggestions as to how to do achieve this? Instead, configure a broadly interoperable list of ciphers that are known to be safe enough. The 'DEFAULT' list is a good starting point, and you can subtract a few types of ciphers from that as needed. On my FreeBSD 12 system, which has OpenSSL 1.1.1, I get: $ openssl ciphers -v -s -tls1_2 DEFAULT ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 from which you could perhaps remove the kRSA ciphers, if insisting on forward-secrecy does not break some important-enough pool of clients. DEFAULT:!kRSA Otherwise, I don't see anything on that list I'd be inclined to remove. For a more advance "performance-optimized" list where AES128 is preferred over CHACHA20 and AES256, you could go with: AES128:CHACHA20:AES256:-ALL:ALL:!COMPLEMENTOFDEFAULT:!kRSA The idea is to resist the temptation to explicitly order a specific list of individual ciphers, and instead take the DEFAULT list, and lightly prune it and/or rearrange it to optimize for some particular features. -- Viktor. From matt at openssl.org Tue Apr 21 21:37:24 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Apr 2020 22:37:24 +0100 Subject: OpenSSL Security Advisory In-Reply-To: References: <20200421132524.GA5046@openssl.org> Message-ID: <81b6d599-ec74-c258-59a7-1c26b1bc1b30@openssl.org> On 21/04/2020 20:46, Sam Roberts wrote: > The announcement claims that this affects SSL_check_chain(). > > Is that an exhaustive list? If an application does NOT call that > function, does this mean the vulnerability is not exploitable? As Ben says - this is correct. > > I ask because the the fixed function tls1_check_sig_alg is called by > tls1_check_chain, and that is called directly by SSL_check_chain, but > it is also called by tls1_set_cert_validity, and that is called from You will note that tls1_check_sig_alg is only affected if we go down the TLSv1.3 codepath. However tls1_set_cert_validity() only has one caller and it looks like this: if (SSL_IS_TLS13(s)) { ... } else { tls1_set_cert_validity(s); ssl_set_masks(s); } So it is only ever called in a non-TLSv1.3 handshake. Matt > inside the tls state machine, but with different parameters, so its a > bit hard to see if it is affected or not. > > Thanks, > Sam > > On Tue, Apr 21, 2020 at 6:26 AM OpenSSL wrote: >> > OpenSSL Security Advisory [21 April 2020] > ========================================= > > Segmentation fault in SSL_check_chain (CVE-2020-1967) > ===================================================== > > Severity: High > > Server or client applications that call the SSL_check_chain() function during or > after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a > result of incorrect handling of the "signature_algorithms_cert" TLS extension. > The crash occurs if an invalid or unrecognised signature algorithm is received > from the peer. This could be exploited by a malicious peer in a Denial of > Service attack. > > OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This > issue did not affect OpenSSL versions prior to 1.1.1d. > > Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g > > This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April > 2020. It was found using the new static analysis pass being implemented in GCC, > -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin > Kaduk. > > Note > ===== > > This issue did not affect OpenSSL 1.0.2 however these versions are out of > support and no longer receiving public updates. Extended support is available > for premium support customers: https://www.openssl.org/support/contracts.html > > This issue did not affect OpenSSL 1.1.0 however these versions are out of > support and no longer receiving updates. > > Users of these versions should upgrade to OpenSSL 1.1.1. > > References > ========== > > URL for this Security Advisory: > https://www.openssl.org/news/secadv/20200421.txt > > Note: the online version of the advisory may be updated with additional details > over time. > > For details of OpenSSL severity classifications please see: > https://www.openssl.org/policies/secpolicy.html > From matt at openssl.org Tue Apr 21 21:49:25 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Apr 2020 22:49:25 +0100 Subject: opensssl 1.1.1g test failure(s) In-Reply-To: <20200421173406.GA4489@kiel.esmtp.org> References: <20200421172238.GA58719@kiel.esmtp.org> <20200421172709.GZ3811@akamai.com> <20200421173406.GA4489@kiel.esmtp.org> Message-ID: On 21/04/2020 18:34, Claus Assmann wrote: > Thanks for the reply, below is the output, It seems it only fails > because the host doesn't support IPv6? Yes - it does seem to be an IPv6 problem. I don't recall any recent changes in this area. Were you successfully able to run the tests with previous versions of OpenSSL? Looks like the failing call is here: if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, (const void *)&on, sizeof(on)) != 0) { To which we get an errno indicating "Invalid argument". So it looks like your host has the relevant IPV6 macros defined (otherwise we would have got a compilation failure) - but doesn't understand them when used. If you're not using IPv6 on that host and this is the only test failure then it can probably be safely ignored. Matt From kurt at roeckx.be Tue Apr 21 22:25:28 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 22 Apr 2020 00:25:28 +0200 Subject: opensssl 1.1.1g test failure(s) In-Reply-To: References: <20200421172238.GA58719@kiel.esmtp.org> <20200421172709.GZ3811@akamai.com> <20200421173406.GA4489@kiel.esmtp.org> Message-ID: <20200421222528.GA50084@roeckx.be> On Tue, Apr 21, 2020 at 10:49:25PM +0100, Matt Caswell wrote: > > Looks like the failing call is here: > > if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, > (const void *)&on, sizeof(on)) != 0) { > > To which we get an errno indicating "Invalid argument". So it looks like > your host has the relevant IPV6 macros defined (otherwise we would have > got a compilation failure) - but doesn't understand them when used. OpenBSD is really weird in this regard. They always use the behavior of IPV6_V6ONLY set to on. But if you actually try to set it on, they return an error. They should instead return an error when you try to set it off. Kurt From michael.tuexen at lurchi.franken.de Tue Apr 21 22:45:50 2020 From: michael.tuexen at lurchi.franken.de (Michael Tuexen) Date: Wed, 22 Apr 2020 00:45:50 +0200 Subject: opensssl 1.1.1g test failure(s) In-Reply-To: References: <20200421172238.GA58719@kiel.esmtp.org> <20200421172709.GZ3811@akamai.com> <20200421173406.GA4489@kiel.esmtp.org> Message-ID: > On 21. Apr 2020, at 23:49, Matt Caswell wrote: > > > > On 21/04/2020 18:34, Claus Assmann wrote: >> Thanks for the reply, below is the output, It seems it only fails >> because the host doesn't support IPv6? > > Yes - it does seem to be an IPv6 problem. I don't recall any recent > changes in this area. Were you successfully able to run the tests with > previous versions of OpenSSL? > > Looks like the failing call is here: > > if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, > (const void *)&on, sizeof(on)) != 0) { Can you provide a pointer to the code? Best regards Michael > > To which we get an errno indicating "Invalid argument". So it looks like > your host has the relevant IPV6 macros defined (otherwise we would have > got a compilation failure) - but doesn't understand them when used. > > If you're not using IPv6 on that host and this is the only test failure > then it can probably be safely ignored. > > Matt From dclarke at blastwave.org Tue Apr 21 22:59:17 2020 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 21 Apr 2020 18:59:17 -0400 Subject: opensssl 1.1.1g test failure(s) In-Reply-To: References: <20200421172238.GA58719@kiel.esmtp.org> <20200421172709.GZ3811@akamai.com> <20200421173406.GA4489@kiel.esmtp.org> Message-ID: On 2020-04-21 18:45, Michael Tuexen wrote: >> On 21. Apr 2020, at 23:49, Matt Caswell wrote: >> >> >> >> On 21/04/2020 18:34, Claus Assmann wrote: >>> Thanks for the reply, below is the output, It seems it only fails >>> because the host doesn't support IPv6? >> >> Yes - it does seem to be an IPv6 problem. I don't recall any recent >> changes in this area. Were you successfully able to run the tests with >> previous versions of OpenSSL? >> >> Looks like the failing call is here: >> >> if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, >> (const void *)&on, sizeof(on)) != 0) { > Can you provide a pointer to the code? > > Best regards > Michael >> >> To which we get an errno indicating "Invalid argument". So it looks like >> your host has the relevant IPV6 macros defined (otherwise we would have >> got a compilation failure) - but doesn't understand them when used. >> >> If you're not using IPv6 on that host and this is the only test failure >> then it can probably be safely ignored. >> >> Matt Not sure what the complaints are however here on the most strict POSIX risc environment with a really strict compiler : . . . All tests successful. Files=155, Tests=1460, 1378 wallclock secs (10.52 usr 1.12 sys + 1251.44 cusr 53.76 csys = 1316.84 CPU) Result: PASS gmake[1]: Leaving directory '/usr/local/build/openssl-1.1.1g_SunOS5.10_sparc64vii+.001' alpha$ alpha$ alpha$ uname -a SunOS alpha 5.10 Generic_150400-65 sun4u sparc SUNW,SPARC-Enterprise alpha$ alpha$ psrinfo -pv The physical processor has 2 virtual processors (2 3) SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz) alpha$ alpha$ cc -V cc: Studio 12.6 Sun C 5.15 SunOS_sparc 2017/05/30 alpha$ alpha$ -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From markwhozer at gmail.com Tue Apr 21 23:26:53 2020 From: markwhozer at gmail.com (Mark Windshield) Date: Wed, 22 Apr 2020 01:26:53 +0200 Subject: How to disable renegation before compiling openssl In-Reply-To: <20200421200638.GB3811@akamai.com> References: <20200421200638.GB3811@akamai.com> Message-ID: Thanks for you reply Ben! Sorry for being unclear, the goal would be to just not send the SCSV value in the ClientHello. -Mark Am Di., 21. Apr. 2020 um 22:06 Uhr schrieb Benjamin Kaduk : > On Tue, Apr 21, 2020 at 09:57:02PM +0200, Mark Windshield wrote: > > Hello, > > > > I was wondering what I'd have to change in the openssl code/config before > > compiling to have renegation disabled by default, so it won't send the > > Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) when using curl. > > This description does not really make it clear whether you just want to > prevent > renegotiation or specifically need this SCSV value to not be included in > the > ClientHello -- the semantics of TLS_EMPTY_RENEGOTIATION_INFO_SCSV is "if > renegotiation occurs, the client supports the 'secure' variant", but is > otherwise orthogonal to whether renegotiation itself actually occurs. > > -Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vieuxtech at gmail.com Tue Apr 21 23:37:11 2020 From: vieuxtech at gmail.com (Sam Roberts) Date: Tue, 21 Apr 2020 16:37:11 -0700 Subject: OpenSSL Security Advisory In-Reply-To: <81b6d599-ec74-c258-59a7-1c26b1bc1b30@openssl.org> References: <20200421132524.GA5046@openssl.org> <81b6d599-ec74-c258-59a7-1c26b1bc1b30@openssl.org> Message-ID: That makes sense, thank you all. From rsalz at akamai.com Wed Apr 22 00:33:19 2020 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 22 Apr 2020 00:33:19 +0000 Subject: How to disable renegation before compiling openssl In-Reply-To: References: <20200421200638.GB3811@akamai.com> Message-ID: <2C3FBE1D-EAC9-48EF-BC0E-4AA2437DD4F8@akamai.com> * Sorry for being unclear, the goal would be to just not send the SCSV value in the ClientHello. Why? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Wed Apr 22 01:46:08 2020 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 21 Apr 2020 21:46:08 -0400 Subject: CMS in openssl In-Reply-To: References: Message-ID: <17401.1587519968@localhost> Michael Mueller wrote: > We've implemented what I gather can be called a CMS on Linux and Windows > using openssl evp functions. I'm not sure why you say it this way. OpenSSL includes CMS (RFC3369) support, but I think not until 1.1.0. Did you implement RFC3369, or something else? You don't say if this is email or something else. > We need to expand this CMS to other systems, on which we have not been able > to build openssl. These other systems have a vendor supplied security > application. This application supports PKCS7. > We are being asked if our evp CMS is interoperable with PKCS7. CMS (RFC3369/2630) is an upward revision to PKCS7 (RFC2315) 1.5. CMS can read PKCS7 messages, but converse is not true. I think it is possible to configure the CMS routines to produce PKCS7 messages, but I didn't do this in my RFC8366 support. I just forklift upgraded to CMS. > If it is possible and more information is required to answer this question, > I'll provide such information. > If not, advice on how to present that argument to management would be > appreciated. You will understand them, but they won't understand you. You may be able to configure your end to generate PKCS7 easily, and it may have little effect. This might degenerate until just using PKCS7 everywhere. The major difference is the eContentType that is lacking in PKCS7. And algorithms: I think that there are few modern algorithms defined for PKCS7. You could easily run in PKCS7 mode until you receive a CMS message from the peer, and then upgrade to CMS. But this winds up in a bid-down attack if both parties run this algorithm, so you'd want to insert some extension that said: "I can do CMS" into your PKCS7 messages. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From jb-openssl at wisemo.com Wed Apr 22 02:26:18 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 Apr 2020 04:26:18 +0200 Subject: CMS in openssl In-Reply-To: <17401.1587519968@localhost> References: <17401.1587519968@localhost> Message-ID: <74687e6a-abe5-94ff-70c4-a87c9e0d8347@wisemo.com> A few corrections: OpenSSL included CMS (RFC3369) support since 1.0.0 (see the CHANGES file), though for a long time, there was an arbitrary disconnect between functions named CMS and functions named PKCS#7 even though it should have been a continuum. The PKCS#7 and CMS standards equally and fully support any non-interactive algorithm that has been assigned an OID, from RSA+MD2+DES to HSS/LSS+STREEBOG+CAMELIA, no artifical version dependencies like in the OpenSSL interpretation of TLS. On 2020-04-22 03:46, Michael Richardson wrote: > Michael Mueller wrote: > > We've implemented what I gather can be called a CMS on Linux and Windows > > using openssl evp functions. > > I'm not sure why you say it this way. > OpenSSL includes CMS (RFC3369) support, but I think not until 1.1.0. > Did you implement RFC3369, or something else? > > You don't say if this is email or something else. > > > We need to expand this CMS to other systems, on which we have not been able > > to build openssl. These other systems have a vendor supplied security > > application. This application supports PKCS7. > > > We are being asked if our evp CMS is interoperable with PKCS7. > > CMS (RFC3369/2630) is an upward revision to PKCS7 (RFC2315) 1.5. > CMS can read PKCS7 messages, but converse is not true. > > I think it is possible to configure the CMS routines to produce PKCS7 > messages, but I didn't do this in my RFC8366 support. I just forklift > upgraded to CMS. > > > If it is possible and more information is required to answer this question, > > I'll provide such information. > > > If not, advice on how to present that argument to management would be > > appreciated. > > You will understand them, but they won't understand you. > > You may be able to configure your end to generate PKCS7 easily, and it may > have little effect. This might degenerate until just using PKCS7 everywhere. > > The major difference is the eContentType that is lacking in PKCS7. > And algorithms: I think that there are few modern algorithms defined for PKCS7. > > You could easily run in PKCS7 mode until you receive a CMS message from the > peer, and then upgrade to CMS. But this winds up in a bid-down attack if > both parties run this algorithm, so you'd want to insert some extension that > said: "I can do CMS" into your PKCS7 messages. > > 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 From yangbolinzju at gmail.com Wed Apr 22 03:46:16 2020 From: yangbolinzju at gmail.com (yang berlin) Date: Wed, 22 Apr 2020 11:46:16 +0800 Subject: questions on using ed25519 In-Reply-To: <20200421173430.GG41308@straasha.imrryr.org> References: <20200421173430.GG41308@straasha.imrryr.org> Message-ID: Wow, thanks for the detailed reply! Actually I am a master student and my teacher wants me to figure out the use of ed25519. So I went to see openssl. I thought ed25519 can sign messages so I tried the dgst command. Now I know that I was wrong. Anyway, thank you again! Viktor Dukhovni ?2020?4?22??? ??1:35??? > On Tue, Apr 21, 2020 at 05:48:19PM +0800, yang berlin wrote: > > > I want to use ed25519 in openssl. > > Why? What actual real-world purpose do you have for ed25519? > > > The problem I met is: I can use "speed ed25519" to test the speed of > > ed25519, but when I use "dgst -ed25519", it tells me that "dgst: > > Unrecognized flag Ed25519". > > That's because "ed25519" is not a digest algorithm, it is a public key > algorithm. You can use it to sign messages, but not to compute message > digests. > > > So could you please help me to learn how to use ed25519 correctly? > > That question has no answer. Whether a use of "ed25519" is correct or > incorrect depends on the security protocol in which it is to be used, > and whether that protocol is appropriate to security requirements of > the application using it. > > If you're just playing with ed25519, you can generate ed25519 keys with: > > $ openssl genpkey -algorithm ed25519 -out privkey.pem > > You can extract just the public key via: > > $ openssl pkey -in privkey.pem -pubout -out pubkey.pem > > You can generate an ed25519 self-signed public key certificate with: > > $ openssl req -key privkey.pem -new \ > -x509 -subj "/CN=$(uname -n)" -days 36500 -out pubcert.pem > > You can use the key and certificate with s_client, and s_server > via the "-key" and "-cert" arguments. > > You can also sign and/or encrypt messages with ed25519 using cms(1), > but you may not be ready to dive into cms. > > Low-level public and private key operations are possible via pkeyutl(1). > > While the dgst(1) command supports signing message digests with various > public key signature algorithms, ed25519 is not one of these: > > -sign filename > Digitally sign the digest using the private key in "filename". > Note > this option does not support Ed25519 or Ed448 private keys. Use > the > pkeyutl command instead for this. > > See the pkeyutl(1) manpage. > > Don't assume that some use of encryption implies any gain in security. > It could be mere security theatre. For actual security you need to > apply a robust protocol that matches the application's security > requirements. > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Apr 22 05:01:43 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 22 Apr 2020 01:01:43 -0400 Subject: questions on using ed25519 In-Reply-To: References: <20200421173430.GG41308@straasha.imrryr.org> Message-ID: <20200422050143.GJ41308@straasha.imrryr.org> On Wed, Apr 22, 2020 at 11:46:16AM +0800, yang berlin wrote: > Wow, thanks for the detailed reply! > Actually I am a master student and my teacher wants me to figure out the > use of ed25519. So I went to see openssl. > I thought ed25519 can sign messages so I tried the dgst command. Now I know > that I was wrong. Well, actually it *does* sign messages, but not via "openssl dgst", because typically ed25519 is used to sign short messages without first running them through a digest function. This makes it resistant to hash function collion attacks. There is actually more than one flavour of the ed25519 signature algorithm, see RFC8032: https://tools.ietf.org/html/rfc8032#section-4 https://tools.ietf.org/html/rfc8032#section-5 You can use "pkeyutl" to directly sign (short messages) with (pure) ed25519, or, for longer messages, you can use the "prehash" variant which signs a SHA2-512 hash. -- Viktor. From dfulger at gmx.com Wed Apr 22 08:10:52 2020 From: dfulger at gmx.com (Dan Fulger) Date: Wed, 22 Apr 2020 10:10:52 +0200 Subject: An idiosyncratic port of OpenSSL 1.1.1g to OS/400 ILE Message-ID: An HTML attachment was scrubbed... URL: From yangbolinzju at gmail.com Wed Apr 22 08:22:13 2020 From: yangbolinzju at gmail.com (yang berlin) Date: Wed, 22 Apr 2020 16:22:13 +0800 Subject: questions on using ed25519 In-Reply-To: <20200421173430.GG41308@straasha.imrryr.org> References: <20200421173430.GG41308@straasha.imrryr.org> Message-ID: Hello, I checked the pkeyutl manpage, but it says that -The Ed25519 and Ed448 signature algorithms are not supported by this utility. They accept non-hashed input, but this utility can only be used to sign hashed input. So what command should I use to simply sign or encrypt a message with ed25519 or x25519? I also checked the cms manpage, if I use this command the result will be in MIME format. Besides, I used the speed command and it will test the sign and verify the speed of ed25519, I just want to know what command will do this sign and verify operation. Viktor Dukhovni ?2020?4?22??? ??1:35??? > On Tue, Apr 21, 2020 at 05:48:19PM +0800, yang berlin wrote: > > > I want to use ed25519 in openssl. > > Why? What actual real-world purpose do you have for ed25519? > > > The problem I met is: I can use "speed ed25519" to test the speed of > > ed25519, but when I use "dgst -ed25519", it tells me that "dgst: > > Unrecognized flag Ed25519". > > That's because "ed25519" is not a digest algorithm, it is a public key > algorithm. You can use it to sign messages, but not to compute message > digests. > > > So could you please help me to learn how to use ed25519 correctly? > > That question has no answer. Whether a use of "ed25519" is correct or > incorrect depends on the security protocol in which it is to be used, > and whether that protocol is appropriate to security requirements of > the application using it. > > If you're just playing with ed25519, you can generate ed25519 keys with: > > $ openssl genpkey -algorithm ed25519 -out privkey.pem > > You can extract just the public key via: > > $ openssl pkey -in privkey.pem -pubout -out pubkey.pem > > You can generate an ed25519 self-signed public key certificate with: > > $ openssl req -key privkey.pem -new \ > -x509 -subj "/CN=$(uname -n)" -days 36500 -out pubcert.pem > > You can use the key and certificate with s_client, and s_server > via the "-key" and "-cert" arguments. > > You can also sign and/or encrypt messages with ed25519 using cms(1), > but you may not be ready to dive into cms. > > Low-level public and private key operations are possible via pkeyutl(1). > > While the dgst(1) command supports signing message digests with various > public key signature algorithms, ed25519 is not one of these: > > -sign filename > Digitally sign the digest using the private key in "filename". > Note > this option does not support Ed25519 or Ed448 private keys. Use > the > pkeyutl command instead for this. > > See the pkeyutl(1) manpage. > > Don't assume that some use of encryption implies any gain in security. > It could be mere security theatre. For actual security you need to > apply a robust protocol that matches the application's security > requirements. > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Apr 22 08:38:22 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 22 Apr 2020 09:38:22 +0100 Subject: opensssl 1.1.1g test failure(s) In-Reply-To: References: <20200421172238.GA58719@kiel.esmtp.org> <20200421172709.GZ3811@akamai.com> <20200421173406.GA4489@kiel.esmtp.org> Message-ID: <9408961c-4564-b2b0-6fd9-2b682527200a@openssl.org> On 21/04/2020 23:45, Michael Tuexen wrote: >> Looks like the failing call is here: >> >> if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, >> (const void *)&on, sizeof(on)) != 0) { > Can you provide a pointer to the code? Yes, its here: https://github.com/openssl/openssl/blob/fa555aa8970260c3e198d91709b2d4b3e40f8fa8/crypto/bio/b_sock2.c#L267-L282 Matt From ca+ssl-users at esmtp.org Wed Apr 22 08:42:23 2020 From: ca+ssl-users at esmtp.org (Claus Assmann) Date: Wed, 22 Apr 2020 10:42:23 +0200 Subject: opensssl 1.1.1g test failure(s) In-Reply-To: References: <20200421172238.GA58719@kiel.esmtp.org> <20200421172709.GZ3811@akamai.com> <20200421173406.GA4489@kiel.esmtp.org> Message-ID: <20200422084223.GA40572@kiel.esmtp.org> On Tue, Apr 21, 2020, Matt Caswell wrote: > changes in this area. Were you successfully able to run the tests with > previous versions of OpenSSL? It's the first time I compiled 1.1.1 on that host. Just to check I tried 1.1.1d and it shows the same problem, so it's not a regression. From michael.tuexen at lurchi.franken.de Wed Apr 22 09:02:47 2020 From: michael.tuexen at lurchi.franken.de (Michael Tuexen) Date: Wed, 22 Apr 2020 11:02:47 +0200 Subject: opensssl 1.1.1g test failure(s) In-Reply-To: <9408961c-4564-b2b0-6fd9-2b682527200a@openssl.org> References: <20200421172238.GA58719@kiel.esmtp.org> <20200421172709.GZ3811@akamai.com> <20200421173406.GA4489@kiel.esmtp.org> <9408961c-4564-b2b0-6fd9-2b682527200a@openssl.org> Message-ID: <9D29B2F0-397A-47E8-93A7-7F62A11453DA@lurchi.franken.de> > On 22. Apr 2020, at 10:38, Matt Caswell wrote: > > > > On 21/04/2020 23:45, Michael Tuexen wrote: >>> Looks like the failing call is here: >>> >>> if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, >>> (const void *)&on, sizeof(on)) != 0) { >> Can you provide a pointer to the code? > > Yes, its here: > > https://github.com/openssl/openssl/blob/fa555aa8970260c3e198d91709b2d4b3e40f8fa8/crypto/bio/b_sock2.c#L267-L282 OK. Thanks. Could it be that on == 0, when you do the setsockopt() call? Disabling IPV6_V6ONLY seems not to be supported on OpenBSD: From sys/netinet6/ip6_output.c: case IPV6_V6ONLY: /* * make setsockopt(IPV6_V6ONLY) * available only prior to bind(2). * see ipng mailing list, Jun 22 2001. */ if (inp->inp_lport || !IN6_IS_ADDR_UNSPECIFIED(&inp->inp_laddr6)) { error = EINVAL; break; } /* No support for IPv4-mapped addresses. */ if (!optval) error = EINVAL; else error = 0; break; I don't see a bug in OpenBSD here, or a strange behaviour. OpenBSD just does not support mapped addresses. Best regards Michael > > Matt From nic.tuv at gmail.com Wed Apr 22 11:27:03 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 22 Apr 2020 13:27:03 +0200 Subject: questions on using ed25519 In-Reply-To: References: <20200421173430.GG41308@straasha.imrryr.org> Message-ID: Unfortunately at the moment the command line utilities do not support generating Ed25519 or Ed448 signatures for files. The reason is that in OpenSSL at the moment we only support pureEd25519, which does not prehash the "message" to be signed, as Viktor mentioned before. With other prehashed signature algorithms, signing a file is technically signing the output of some hashing function over that file, and all the common hashing functions support hashing arbitrary big data streams one chunk at a time until the full stream is consumed. With pureEd25519, which requires the full message for the sign operation, this operation becomes more complicated as one need to buffer the whole file in memory for the duration of the operation: in absence of memory mapped files (which are not supported equally on all the platforms on which OpenSSL runs, this means that to sign e.g. a 4GB file you need to allocate a 4GB buffer in memory to load the contents of the file to be signed. Even then, if we didn't have the portability issue of memory mapped files, supporting non-prehashed signature/verification algorithms would basically require a new dedicated tool as the current ones are strongly dependent on the assumption that signatures are computed on short hashes and that handling files can and should be done in chunks, before running the signature/verification algorithm. As a result of these consideration the current support for Ed25519 (/Ed448) in OpenSSL is mostly dedicated to support the development of protocols using it for relatively short messages. If you have a strong need to sign and distribute file signatures using Ed25519 keys, nothing prevents you from writing an application using the `EVP_DigestSign()` function to sign/verify an arbitrary length message stored in a buffer (possibly using memory mapped files if the platforms you want to target all support this feature to avoid unnecessary memory consumption). As usual, pull requests are warmly welcome! So if you wanted to add support for this scenario within the openssl built-in commandline tools in `apps/` (either as a new tool or as an optional mode of operation for an existing one) it would be an interesting contribution! As a personal suggestion, though, due to the portability problems and the controversial issue of how to handle arbitrary length files without memory mapping support for files, I would suggest opening first an issue on GitHub about it, signalling your will to contribute towards its resolution, so that solutions to these controversial problems can be discussed before committing to major development efforts. Hope this helps, Nicola Tuveri On Wed, 22 Apr 2020 at 10:22, yang berlin wrote: > Hello, I checked the pkeyutl manpage, but it says that > -The Ed25519 and Ed448 signature algorithms are not supported by this > utility. They accept non-hashed input, but this utility can only be used to > sign hashed input. > So what command should I use to simply sign or encrypt a message with > ed25519 or x25519? I also checked the cms manpage, if I use this command > the result will be in MIME format. > Besides, I used the speed command and it will test the sign and verify the > speed of ed25519, I just want to know what command will do this sign and > verify operation. > > Viktor Dukhovni ?2020?4?22??? ??1:35??? > >> On Tue, Apr 21, 2020 at 05:48:19PM +0800, yang berlin wrote: >> >> > I want to use ed25519 in openssl. >> >> Why? What actual real-world purpose do you have for ed25519? >> >> > The problem I met is: I can use "speed ed25519" to test the speed of >> > ed25519, but when I use "dgst -ed25519", it tells me that "dgst: >> > Unrecognized flag Ed25519". >> >> That's because "ed25519" is not a digest algorithm, it is a public key >> algorithm. You can use it to sign messages, but not to compute message >> digests. >> >> > So could you please help me to learn how to use ed25519 correctly? >> >> That question has no answer. Whether a use of "ed25519" is correct or >> incorrect depends on the security protocol in which it is to be used, >> and whether that protocol is appropriate to security requirements of >> the application using it. >> >> If you're just playing with ed25519, you can generate ed25519 keys with: >> >> $ openssl genpkey -algorithm ed25519 -out privkey.pem >> >> You can extract just the public key via: >> >> $ openssl pkey -in privkey.pem -pubout -out pubkey.pem >> >> You can generate an ed25519 self-signed public key certificate with: >> >> $ openssl req -key privkey.pem -new \ >> -x509 -subj "/CN=$(uname -n)" -days 36500 -out pubcert.pem >> >> You can use the key and certificate with s_client, and s_server >> via the "-key" and "-cert" arguments. >> >> You can also sign and/or encrypt messages with ed25519 using cms(1), >> but you may not be ready to dive into cms. >> >> Low-level public and private key operations are possible via pkeyutl(1). >> >> While the dgst(1) command supports signing message digests with various >> public key signature algorithms, ed25519 is not one of these: >> >> -sign filename >> Digitally sign the digest using the private key in "filename". >> Note >> this option does not support Ed25519 or Ed448 private keys. >> Use the >> pkeyutl command instead for this. >> >> See the pkeyutl(1) manpage. >> >> Don't assume that some use of encryption implies any gain in security. >> It could be mere security theatre. For actual security you need to >> apply a robust protocol that matches the application's security >> requirements. >> >> -- >> Viktor. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Wed Apr 22 13:22:58 2020 From: hkario at redhat.com (Hubert Kario) Date: Wed, 22 Apr 2020 15:22:58 +0200 Subject: TLSv1 on CentOS-8 In-Reply-To: <6410386f-91ad-cd4c-3bb9-e2c1b50120d4@wisemo.com> References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> <5d0125b4e2b625ecf5de73ff7f676b3cab4b9d8b.camel@redhat.com> <20200417170318.GC41308@straasha.imrryr.org> <6410386f-91ad-cd4c-3bb9-e2c1b50120d4@wisemo.com> Message-ID: <77b8d512-90c1-415c-b689-d62280c8c859@redhat.com> On Tuesday, 21 April 2020 21:29:58 CEST, Jakob Bohm via openssl-users wrote: > That link shows whatever anyone's browser is configured to > handle when clicking > the link. > > The important thing is which browsers you need to support, like the ones on > https://www.ssllabs.com/ssltest/clients.html > > Beware that the list I just linked is woefully incomplete for > those of us who > actively target "any browser" support, especially when including old stuff > like Windows Mobile 5 and Windows XP. what good is supporting connections from Windows XP when no browser that can run on it will be able to display the web page? > On 21/04/2020 17:06, Junaid Mukhtar wrote: >> Hi Tomas/Team >> >> I have managed to block the RC4 and enable tlsv1 as per our requirements. >> >> We have a requirement to match cipher list on the internal >> server to match the native browser cipher list as shown by the >> https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html >> >> I have tried setting up different combinations on the >> CipherString but none helped. Do you have any suggestions as to >> how to do achieve this? >> >> >> On Fri, Apr 17, 2020 at 6:22 PM Tomas Mraz > > wrote: ... > > Enjoy > > Jakob -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic From abaci.mjm at gmail.com Wed Apr 22 14:06:55 2020 From: abaci.mjm at gmail.com (Michael Mueller) Date: Wed, 22 Apr 2020 10:06:55 -0400 Subject: CMS in openssl In-Reply-To: <17401.1587519968@localhost> References: <17401.1587519968@localhost> Message-ID: On Tue, Apr 21, 2020, 9:46 PM Michael Richardson wrote: > > Michael Mueller wrote: > > We've implemented what I gather can be called a CMS on Linux and > Windows > > using openssl evp functions. > > I'm not sure why you say it this way. > OpenSSL includes CMS (RFC3369) support, but I think not until 1.1.0. > Did you implement RFC3369, or something else? > > You don't say if this is email or something else. > My bad. I thought CMS could be used as a generic reference to packaging encrypted messages. We are not implementing CMS as specified by IETF. We used the openssl evp functions to quickly improve the security of an existing proprietary data exchange system. Now we are being asked if our evp based solution can interoperate with a system that may support PKCS7. The thought is PKCS7 would be used to envelope data in a manner similar to how the evp functions operate. The request came up because the word "envelope" is used to describe evp and PKCS7 functionality. I suspect that evp functions are not compatible with PKCS7, but I don't know how to easily confirm this. I also suspect it will be difficult to explain why they are incompatible. If evp and PKCS7 are incompatible, we might be asked if we can use PKCS7 enveloping instead of evp. Any insights, thoughts, advice, code to read, etc would be appreciated. > > We need to expand this CMS to other systems, on which we have not > been able > > to build openssl. These other systems have a vendor supplied security > > application. This application supports PKCS7. > > > We are being asked if our evp CMS is interoperable with PKCS7. > > CMS (RFC3369/2630) is an upward revision to PKCS7 (RFC2315) 1.5. > CMS can read PKCS7 messages, but converse is not true. > > I think it is possible to configure the CMS routines to produce PKCS7 > messages, but I didn't do this in my RFC8366 support. I just forklift > upgraded to CMS. > > > If it is possible and more information is required to answer this > question, > > I'll provide such information. > > > If not, advice on how to present that argument to management would be > > appreciated. > > You will understand them, but they won't understand you. > > You may be able to configure your end to generate PKCS7 easily, and it may > have little effect. This might degenerate until just using PKCS7 > everywhere. > > The major difference is the eContentType that is lacking in PKCS7. > And algorithms: I think that there are few modern algorithms defined for > PKCS7. > > You could easily run in PKCS7 mode until you receive a CMS message from the > peer, and then upgrade to CMS. But this winds up in a bid-down attack if > both parties run this algorithm, so you'd want to insert some extension > that > said: "I can do CMS" into your PKCS7 messages. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Apr 22 14:40:31 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 Apr 2020 16:40:31 +0200 Subject: TLSv1 on CentOS-8 In-Reply-To: <77b8d512-90c1-415c-b689-d62280c8c859@redhat.com> References: <5d0fe257042a29e1327b3d1f9168942d67cc8735.camel@redhat.com> <5d0125b4e2b625ecf5de73ff7f676b3cab4b9d8b.camel@redhat.com> <20200417170318.GC41308@straasha.imrryr.org> <6410386f-91ad-cd4c-3bb9-e2c1b50120d4@wisemo.com> <77b8d512-90c1-415c-b689-d62280c8c859@redhat.com> Message-ID: On 2020-04-22 15:22, Hubert Kario wrote: > On Tuesday, 21 April 2020 21:29:58 CEST, Jakob Bohm via openssl-users > wrote: >> That link shows whatever anyone's browser is configured to handle >> when clicking >> the link. >> >> The important thing is which browsers you need to support, like the >> ones on >> https://www.ssllabs.com/ssltest/clients.html >> >> Beware that the list I just linked is woefully incomplete for those >> of us who >> actively target "any browser" support, especially when including old >> stuff >> like Windows Mobile 5 and Windows XP. > > what good is supporting connections from Windows XP when no browser > that can > run on it will be able to display the web page? > Making the web page itself compatible is another part of that task. For backward browser compatibility, some pages will have a higher priority. Did you by chance encounter a technical issue on our web pages?? If so, please report to me, webmaster or support. 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 From Joerg.Hessdoerfer at sea-gmbh.com Wed Apr 22 16:21:43 2020 From: Joerg.Hessdoerfer at sea-gmbh.com (=?UTF-8?B?SsO2cmcgSGXDn2TDtnJmZXI=?=) Date: Wed, 22 Apr 2020 18:21:43 +0200 Subject: Generating and checking SM2 signatures Message-ID: <92d52bbe-62b9-1228-9c9c-0ae41049f4f5@sea-gmbh.com> Hello, I'm tasked to implement certain cryptographic functions (chiefly signature creation/validation) using the SM2 algorithm for a communication testing application. My problem is that the standard which I need to follow (which is, unfortunately, not a public standard) states that the signature needs to be generated over H(data input) || H(some ID) , so I cannot use the EVP-Method as I understand it from https://www.openssl.org/docs/manmaster/man7/SM2.html (here, H is the SM3 hash function). This would be possible to achieve by generating the digest and then using the (albeit deprecated) function ECDSA_do_sign for ECDSA but I don't know how to do it for SM2. Is there any way to do this with openssl? Any help or pointer is very much appreciated! Thank you, ??? J?rg -- J?rg He?d?rfer S.E.A. Datentechnik GmbH M?lheimer Stra?e 7 53840 Troisdorf Tel.: +49 2241 12737-19 Fax.: +49 2241 12737-14 E-Mail: Joerg.Hessdoerfer at sea-gmbh.com Web : http://www.sea-gmbh.com Informationen nach 37aHGB, 35a GmbH-Gesetz: S.E.A. Science& Engineering Applications Datentechnik GmbH Sitz der Gesellschaft K?ln Handelsregister K?ln HRB 27016 Gesch?ftsf?hrer: Dr. Gerd Schmitz, Wolfram Koerver From openssl-users at dukhovni.org Wed Apr 22 17:12:05 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 22 Apr 2020 13:12:05 -0400 Subject: questions on using ed25519 In-Reply-To: References: <20200421173430.GG41308@straasha.imrryr.org> Message-ID: <20200422171205.GK41308@straasha.imrryr.org> On Wed, Apr 22, 2020 at 01:27:03PM +0200, Nicola Tuveri wrote: > Unfortunately at the moment the command line utilities do not support > generating Ed25519 or Ed448 signatures for files. > > The reason is that in OpenSSL at the moment we only support pureEd25519, > which does not prehash the "message" to be signed, as Viktor mentioned > before. Which means no support in dgst(1), but that manpage suggests pkeyutl(1), which e.g. for RSA supports signing raw (unhashed input), but sadly the EVP_PKEY_METHOD for ed25519 has a NULL sign() member, instead, somewhat ironically, it has a digestsign() method. This is presumably to distinguish between the pure and prehash variants. Therefore, presently pkeyutl(1) indeed appears to not implement signing and verifying with ed25519, this looks doable with modest effort. -- Viktor. From mcr at sandelman.ca Wed Apr 22 18:56:12 2020 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 22 Apr 2020 14:56:12 -0400 Subject: CMS in openssl In-Reply-To: References: <17401.1587519968@localhost> Message-ID: <2912.1587581772@localhost> Michael Mueller wrote: >> Michael Mueller wrote: >> > We've implemented what I gather can be called a CMS on Linux and >> Windows >> > using openssl evp functions. >> >> I'm not sure why you say it this way. >> OpenSSL includes CMS (RFC3369) support, but I think not until 1.1.0. >> Did you implement RFC3369, or something else? >> >> You don't say if this is email or something else. >> > My bad. I thought CMS could be used as a generic reference to packaging > encrypted messages. > We are not implementing CMS as specified by IETF. > We used the openssl evp functions to quickly improve the security of an > existing proprietary data exchange system. > Now we are being asked if our evp based solution can interoperate with a > system that may support PKCS7. The thought is PKCS7 would be used to > envelope data in a manner similar to how the evp functions operate. I don't think you will find any compatibility. You can use the PKCS7 functions to process that kind of data. Or future proof and use CMS functions to read, and figure out how you will write/send messages. > I suspect that evp functions are not compatible with PKCS7, but I don't > know how to easily confirm this. I also suspect it will be difficult to > explain why they are incompatible. > If evp and PKCS7 are incompatible, we might be asked if we can use PKCS7 > enveloping instead of evp. > Any insights, thoughts, advice, code to read, etc would be appreciated. I think you should consider if you want to move to PKCS7. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From nic.tuv at gmail.com Wed Apr 22 20:35:46 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 22 Apr 2020 22:35:46 +0200 Subject: questions on using ed25519 In-Reply-To: <20200422171205.GK41308@straasha.imrryr.org> References: <20200421173430.GG41308@straasha.imrryr.org> <20200422171205.GK41308@straasha.imrryr.org> Message-ID: I have to correct myself, in `master` (and very soon in the 3.0.0 alpha1 release) `pkeyutl` already has support for sign/verify files with Ed25519 keys. ``` ? /tmp/test25519/ ### Ensure OpenSSL dev build is in use for this shell ? /tmp/test25519/ which openssl ; openssl version /opt/openssl-master/bin/openssl OpenSSL 3.0.0-dev xx XXX xxxx (Library: OpenSSL 3.0.0-dev xx XXX xxxx) ? /tmp/test25519/ ### Generate Ed25519 private key ? /tmp/test25519/ openssl genpkey -algorithm Ed25519 -out priv.pem ? /tmp/test25519/ ### Extract pub key from private key ? /tmp/test25519/ openssl pkey -in priv.pem -pubout -out pub.pem ? /tmp/test25519/ ### ? /tmp/test25519/ ### Up to this point all the commands were compatible ? /tmp/test25519/ ### with OpenSSL 1.1.1 releases, the next one is the ? /tmp/test25519/ ### one that requires OpenSSL 3.0.0-dev as `pkeyutl` ? /tmp/test25519/ ### now has support for `-rawin` which is required ? /tmp/test25519/ ### for signing/veryfing files with Ed25519 keys. ? /tmp/test25519/ ### ? /tmp/test25519/ ### Generate a signature `sig.dat` for the file ? /tmp/test25519/ ### `/bin/ls` using `priv.key` private Ed25519 key; ? /tmp/test25519/ openssl pkeyutl -sign -inkey priv.pem -out sig.dat \ -rawin -in /bin/ls ? /tmp/test25519/ ### Verify the file `/bin/ls` against a signature ? /tmp/test25519/ ### `sig.dat` under the public Ed25519 key `pub.pem`. ? /tmp/test25519/ ### Success is expected. ? /tmp/test25519/ openssl pkeyutl -verify -pubin -inkey pub.pem \ -rawin -in /bin/ls -sigfile sig.dat Signature Verified Successfully ? /tmp/test25519/ ### Verify the file `/bin/echo` against a signature ? /tmp/test25519/ ### `sig.dat` under the public Ed25519 key `pub.pem`. ? /tmp/test25519/ ### Failure is expected. ? /tmp/test25519/ openssl pkeyutl -verify -pubin -inkey pub.pem \ -rawin -in /bin/echo -sigfile sig.dat Signature Verification Failure ``` On Wed, Apr 22, 2020, 19:12 Viktor Dukhovni wrote: > On Wed, Apr 22, 2020 at 01:27:03PM +0200, Nicola Tuveri wrote: > > > Unfortunately at the moment the command line utilities do not support > > generating Ed25519 or Ed448 signatures for files. > > > > The reason is that in OpenSSL at the moment we only support pureEd25519, > > which does not prehash the "message" to be signed, as Viktor mentioned > > before. > > Which means no support in dgst(1), but that manpage suggests pkeyutl(1), > which e.g. for RSA supports signing raw (unhashed input), but sadly the > EVP_PKEY_METHOD for ed25519 has a NULL sign() member, instead, somewhat > ironically, it has a digestsign() method. This is presumably to > distinguish between the pure and prehash variants. Therefore, presently > pkeyutl(1) indeed appears to not implement signing and verifying with > ed25519, this looks doable with modest effort. > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaci.mjm at gmail.com Wed Apr 22 21:54:15 2020 From: abaci.mjm at gmail.com (Michael Mueller) Date: Wed, 22 Apr 2020 17:54:15 -0400 Subject: CMS in openssl In-Reply-To: <2912.1587581772@localhost> References: <17401.1587519968@localhost> <2912.1587581772@localhost> Message-ID: On Wed, Apr 22, 2020, 2:56 PM Michael Richardson wrote: > > Michael Mueller wrote: > >> Michael Mueller wrote: > >> > We've implemented what I gather can be called a CMS on Linux and > >> Windows > >> > using openssl evp functions. > >> > >> I'm not sure why you say it this way. > >> OpenSSL includes CMS (RFC3369) support, but I think not until 1.1.0. > >> Did you implement RFC3369, or something else? > >> > >> You don't say if this is email or something else. > >> > > > My bad. I thought CMS could be used as a generic reference to > packaging > > encrypted messages. > > > We are not implementing CMS as specified by IETF. > > > We used the openssl evp functions to quickly improve the security of > an > > existing proprietary data exchange system. > > > Now we are being asked if our evp based solution can interoperate > with a > > system that may support PKCS7. The thought is PKCS7 would be used to > > envelope data in a manner similar to how the evp functions operate. > > I don't think you will find any compatibility. > > You can use the PKCS7 functions to process that kind of data. > Or future proof and use CMS functions to read, and figure out how you will > write/send messages > Today we learned that we have PKCS7 1.5 & 1.6 and RFC 3852 are available on the "older" system. Also was guided to CMS specs, and the CMS tools and functions in openssl. We'll experiment with the openssl cms functions on linux and the older system independently. If that works, we'll try interworking linux with the older system. If that works, we'll toggle from evp to cms if the older system is involved. Thank you all for your help. > > I suspect that evp functions are not compatible with PKCS7, but I > don't > > know how to easily confirm this. I also suspect it will be difficult > to > > explain why they are incompatible. > > > If evp and PKCS7 are incompatible, we might be asked if we can use > PKCS7 > > enveloping instead of evp. > > > Any insights, thoughts, advice, code to read, etc would be > appreciated. > > I think you should consider if you want to move to PKCS7. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbrumley at gmail.com Thu Apr 23 02:36:17 2020 From: bbrumley at gmail.com (Billy Brumley) Date: Thu, 23 Apr 2020 05:36:17 +0300 Subject: Generating and checking SM2 signatures In-Reply-To: <92d52bbe-62b9-1228-9c9c-0ae41049f4f5@sea-gmbh.com> References: <92d52bbe-62b9-1228-9c9c-0ae41049f4f5@sea-gmbh.com> Message-ID: > I'm tasked to implement certain cryptographic functions (chiefly > signature creation/validation) using the SM2 algorithm for a > communication testing application. My problem is that the standard which > I need to follow (which is, unfortunately, not a public standard) states > that the signature needs to be generated over H(data input) || H(some > ID) , so I cannot use the EVP-Method as I understand it from > https://www.openssl.org/docs/manmaster/man7/SM2.html (here, H is the SM3 > hash function). This would be possible to achieve by generating the > digest and then using the (albeit deprecated) function ECDSA_do_sign for > ECDSA but I don't know how to do it for SM2. It seems like you're trying to roll your own SM2 -- don't do that ;) > Is there any way to do this with openssl? Any help or pointer is very > much appreciated! I ... think it is possible directly with EVP and control strings. Step through openssl pkeyutl -inkey private.key -in /some/file -rawin -sign -pkeyopt sm2_id:foobar in a debugger and that should get you on the right path. BBB From matt at openssl.org Thu Apr 23 08:41:00 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Apr 2020 09:41:00 +0100 Subject: Generating and checking SM2 signatures In-Reply-To: References: <92d52bbe-62b9-1228-9c9c-0ae41049f4f5@sea-gmbh.com> Message-ID: <33b14926-07b4-4335-acfb-e2932a27416f@openssl.org> On 23/04/2020 03:36, Billy Brumley wrote: >> I'm tasked to implement certain cryptographic functions (chiefly >> signature creation/validation) using the SM2 algorithm for a >> communication testing application. My problem is that the standard which >> I need to follow (which is, unfortunately, not a public standard) states >> that the signature needs to be generated over H(data input) || H(some >> ID) , so I cannot use the EVP-Method as I understand it from >> https://www.openssl.org/docs/manmaster/man7/SM2.html (here, H is the SM3 >> hash function). This would be possible to achieve by generating the >> digest and then using the (albeit deprecated) function ECDSA_do_sign for >> ECDSA but I don't know how to do it for SM2. > > It seems like you're trying to roll your own SM2 -- don't do that ;) Agreed - I echo Billy's concern! > >> Is there any way to do this with openssl? Any help or pointer is very >> much appreciated! > > I ... think it is possible directly with EVP and control strings. Step through > > openssl pkeyutl -inkey private.key -in /some/file -rawin -sign > -pkeyopt sm2_id:foobar > > in a debugger and that should get you on the right path. Unfortunately, the SM2 id does something different to this I think. I'm not an SM2 expert but I believe that does: H( H(stuff || id || other_stuff) || M ) You should be able to use the EVP_PKEY_sign_init()/EVP_PKEY_sign() functions to sign pre-digested input. https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_sign.html Matt From matt at openssl.org Thu Apr 23 09:02:16 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Apr 2020 10:02:16 +0100 Subject: questions on using ed25519 In-Reply-To: <20200422171205.GK41308@straasha.imrryr.org> References: <20200421173430.GG41308@straasha.imrryr.org> <20200422171205.GK41308@straasha.imrryr.org> Message-ID: <89a956f2-a27d-a961-09be-05fb42afd7b6@openssl.org> On 22/04/2020 18:12, Viktor Dukhovni wrote: > sadly the > EVP_PKEY_METHOD for ed25519 has a NULL sign() member, instead, somewhat > ironically, it has a digestsign() method. This is presumably to > distinguish between the pure and prehash variants. Therefore, presently > pkeyutl(1) indeed appears to not implement signing and verifying with > ed25519, this looks doable with modest effort. I'm fairly sure it used to have a "sign" function during the dev phase - but it was taken out. I forget the reasoning. Matt From nic.tuv at gmail.com Thu Apr 23 09:23:35 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Thu, 23 Apr 2020 11:23:35 +0200 Subject: questions on using ed25519 In-Reply-To: <89a956f2-a27d-a961-09be-05fb42afd7b6@openssl.org> References: <20200421173430.GG41308@straasha.imrryr.org> <20200422171205.GK41308@straasha.imrryr.org> <89a956f2-a27d-a961-09be-05fb42afd7b6@openssl.org> Message-ID: On Thu, 23 Apr 2020 at 11:02, Matt Caswell wrote: > > > On 22/04/2020 18:12, Viktor Dukhovni wrote: > > sadly the > > EVP_PKEY_METHOD for ed25519 has a NULL sign() member, instead, somewhat > > ironically, it has a digestsign() method. This is presumably to > > distinguish between the pure and prehash variants. Therefore, presently > > pkeyutl(1) indeed appears to not implement signing and verifying with > > ed25519, this looks doable with modest effort. > > > I'm fairly sure it used to have a "sign" function during the dev phase - > but it was taken out. I forget the reasoning. > Yes, that change was intentional, the reasoning is detailed in the discussion in: https://github.com/openssl/openssl/pull/6284 Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: From ylavic.dev at gmail.com Thu Apr 23 13:57:04 2020 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Thu, 23 Apr 2020 15:57:04 +0200 Subject: Have new release published in /source/old directory too? Message-ID: Hi team, For each new release, it seems that the tarball is published in the "/source" directory (website) while the previous one is moved to "/source/old/". Would it be possible that all releases land in "/source/old", including the new one when published? After all anything is more or less old, as soon as it's born ;) That could help download scripts in the meantime for upgrade validation (at the application level), where the n-1 version is still in use. Thanks, Yann. From openssl at openssl.org Thu Apr 23 14:29:36 2020 From: openssl at openssl.org (OpenSSL) Date: Thu, 23 Apr 2020 14:29:36 +0000 Subject: OpenSSL version 3.0.0-alpha1 published Message-ID: <20200423142936.GA24450@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 1 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 1 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha1.tar.gz Size: 9530120 SHA1 checksum: 4db145d3d9c9d7bfaa7b2a1fe1670f7a3781bb06 SHA256 checksum: 9d5be9122194ad1d649254de5e72afd329252f134791389d0cef627b18ed9a57 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha1.tar.gz openssl sha256 openssl-3.0.0-alpha1.tar.gz Please download and check this $LABEL release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6hpQcACgkQ2cTSbQ5g RJHvtggAp7XIxm/00amD4TijQhJqMmGsj0RXqwAeSd0gWDQCf78GX4zMIW/tTgvk I3Mb67DsOR5gdPZN5TigyqRaXSIAzfb8ZT4Gs9lo/j8RUi5AmzT2RYexbRv6bF6E cQ0OabM3rk4qi4njTi/YD9YihO6/pv7tWZkkfPsN547bfm7p7fwCrEHw02En5IW8 hyFhkpKfA3c8MEa96yLwjhkYRTAzUmxus/mNID+Ja3/VTCmHjd1c57SHFPq9noll Wqzhs3jEhluZKHpwmSSA0KQh1ph0kh6fnKLEn3Oge5dYV3P+JrFCRfDEMsI1Nb/F hIr11rxXNxtBRKUSlOUyJATZn0sV6g== =uRpM -----END PGP SIGNATURE----- From Matthias.St.Pierre at ncp-e.com Thu Apr 23 15:12:26 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 23 Apr 2020 15:12:26 +0000 Subject: Have new release published in /source/old directory too? In-Reply-To: References: Message-ID: <0ef8bfbba81c4814824682f88074c9f2@Ex13.ncp.local> > For each new release, it seems that the tarball is published in the > "/source" directory (website) while the previous one is moved to > "/source/old/". > > Would it be possible that all releases land in "/source/old", > including the new one when published? After all anything is more or > less old, as soon as it's born ;) Normally, you should be able to access older releases without changing the URL, (even after they were moved) because there is an URL rewrite rule which handles this. For an example, 1.1.1a is available at the same location as 1.1.1g: ~/tmp$ curl -JOL https://www.openssl.org/source/openssl-1.1.1g.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9571k 100 9571k 0 0 1992k 0 0:00:04 0:00:04 --:--:-- 1992k ~/tmp$ curl -JOL https://www.openssl.org/source/openssl-1.1.1a.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 8154k 100 8154k 0 0 4962k 0 0:00:01 0:00:01 --:--:-- 4960k Concidentally, a few days ago the rewrite rule was broken, but that has been fixed. (see https://github.com/openssl/openssl/issues/11521#issuecomment-612483438 and ff.) HTH, Matthias From ylavic.dev at gmail.com Thu Apr 23 15:22:56 2020 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Thu, 23 Apr 2020 17:22:56 +0200 Subject: Have new release published in /source/old directory too? In-Reply-To: <0ef8bfbba81c4814824682f88074c9f2@Ex13.ncp.local> References: <0ef8bfbba81c4814824682f88074c9f2@Ex13.ncp.local> Message-ID: On Thu, Apr 23, 2020 at 5:12 PM Dr. Matthias St. Pierre wrote: > > > For each new release, it seems that the tarball is published in the > > "/source" directory (website) while the previous one is moved to > > "/source/old/". > > > > Would it be possible that all releases land in "/source/old", > > including the new one when published? After all anything is more or > > less old, as soon as it's born ;) > > > Normally, you should be able to access older releases without changing the URL, > (even after they were moved) because there is an URL rewrite rule which handles this. > > For an example, 1.1.1a is available at the same location as 1.1.1g: > > ~/tmp$ curl -JOL https://www.openssl.org/source/openssl-1.1.1g.tar.gz > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 9571k 100 9571k 0 0 1992k 0 0:00:04 0:00:04 --:--:-- 1992k > > ~/tmp$ curl -JOL https://www.openssl.org/source/openssl-1.1.1a.tar.gz > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 8154k 100 8154k 0 0 4962k 0 0:00:01 0:00:01 --:--:-- 4960k > > Concidentally, a few days ago the rewrite rule was broken, but that has been fixed. > (see https://github.com/openssl/openssl/issues/11521#issuecomment-612483438 and ff.) OK, that explains. Actually I had the issue from 1.1.1e to 1.1.1f and changed the script. Looking again at the changes now they look.. ugly, so I thought I'd ask. All I need is a persistent URL base, so thanks! Regards, Yann. From vieuxtech at gmail.com Thu Apr 23 17:01:02 2020 From: vieuxtech at gmail.com (Sam Roberts) Date: Thu, 23 Apr 2020 10:01:02 -0700 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> Message-ID: Resending to -users. On Thu, Apr 23, 2020 at 9:58 AM Sam Roberts wrote: > > Seems to be something wrong with the way config is generating the > version strings: > gcc -Icrypto -I. -Iinclude -Iproviders/common/include > -Iproviders/implementations/include -Icrypto/include -DAES_ASM > -DBSAES_ASM -DCMLL_ASM -DECP_NISTZ256_ASM -DGHASH_ASM -DKECCAK1600_ASM > -DMD5_ASM -DOPENSSL_BN_ASM_GF2m -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 > -DPOLY1305_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM > -DWHIRLPOOL_ASM -DX25519_ASM -fPIC -pthread -m64 -Wa,--noexecstack > -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_BUILDING_OPENSSL > -DOPENSSL_PIC -DOPENSSLDIR="\"/usr/local/ssl\"" > -DENGINESDIR="\"/usr/local/lib/engines-3\"" > -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG -MMD -MF > crypto/libcrypto-lib-cversion.d.tmp -MT > crypto/libcrypto-lib-cversion.o -c -o crypto/libcrypto-lib-cversion.o > crypto/cversion.c > In file included from include/openssl/macros.h:11, > from include/openssl/opensslconf.h:14, > from include/openssl/macros.h:10, > from include/openssl/crypto.h:15, > from include/internal/cryptlib.h:23, > from crypto/cversion.c:10: > crypto/cversion.c: In function 'OpenSSL_version': > include/openssl/opensslv.h:91:54: error: expected ';' before numeric constant > 91 | # define OPENSSL_VERSION_TEXT "OpenSSL 3.0.0-alpha1 "23 Apr 2020"" > | ^~ > crypto/cversion.c:50:16: note: in expansion of macro 'OPENSSL_VERSION_TEXT' > 50 | return OPENSSL_VERSION_TEXT; > | ^~~~~~~~~~~~~~~~~~~~ > make[1]: *** [Makefile:15616: crypto/libcrypto-lib-cversion.o] Error 1 > make[1]: Leaving directory '/home/sam/s/openssl-3.0.0-alpha1' > make: *** [Makefile:3009: build_sw] Error 2 > > > I'm on Linux, just did a `./config; make`. > > Its fairly obvious what the string should have been, I edited and am > continuing with the build. > > > On Thu, Apr 23, 2020 at 7:29 AM OpenSSL wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > > > OpenSSL version 3.0 alpha 1 released > > ==================================== > > > > OpenSSL - The Open Source toolkit for SSL/TLS > > https://www.openssl.org/ > > > > OpenSSL 3.0 is currently in alpha. > > > > OpenSSL 3.0 alpha 1 has now been made available. > > > > Note: This OpenSSL pre-release has been provided for testing ONLY. > > It should NOT be used for security critical purposes. > > > > Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well > > as known issues are available on the OpenSSL Wiki, here: > > > > https://wiki.openssl.org/index.php/OpenSSL_3.0 > > > > The alpha release is available for download via HTTPS and FTP from the > > following master locations (you can find the various FTP mirrors under > > https://www.openssl.org/source/mirror.html): > > > > * https://www.openssl.org/source/ > > * ftp://ftp.openssl.org/source/ > > > > The distribution file name is: > > > > o openssl-3.0.0-alpha1.tar.gz > > Size: 9530120 > > SHA1 checksum: 4db145d3d9c9d7bfaa7b2a1fe1670f7a3781bb06 > > SHA256 checksum: 9d5be9122194ad1d649254de5e72afd329252f134791389d0cef627b18ed9a57 > > > > The checksums were calculated using the following commands: > > > > openssl sha1 openssl-3.0.0-alpha1.tar.gz > > openssl sha256 openssl-3.0.0-alpha1.tar.gz > > > > Please download and check this $LABEL release as soon as possible. > > To report a bug, open an issue on GitHub: > > > > https://github.com/openssl/openssl/issues > > > > Please check the release notes and mailing lists to avoid duplicate > > reports of known issues. (Of course, the source is also available > > on GitHub.) > > > > Yours, > > > > The OpenSSL Project Team. > > > > -----BEGIN PGP SIGNATURE----- > > > > iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6hpQcACgkQ2cTSbQ5g > > RJHvtggAp7XIxm/00amD4TijQhJqMmGsj0RXqwAeSd0gWDQCf78GX4zMIW/tTgvk > > I3Mb67DsOR5gdPZN5TigyqRaXSIAzfb8ZT4Gs9lo/j8RUi5AmzT2RYexbRv6bF6E > > cQ0OabM3rk4qi4njTi/YD9YihO6/pv7tWZkkfPsN547bfm7p7fwCrEHw02En5IW8 > > hyFhkpKfA3c8MEa96yLwjhkYRTAzUmxus/mNID+Ja3/VTCmHjd1c57SHFPq9noll > > Wqzhs3jEhluZKHpwmSSA0KQh1ph0kh6fnKLEn3Oge5dYV3P+JrFCRfDEMsI1Nb/F > > hIr11rxXNxtBRKUSlOUyJATZn0sV6g== > > =uRpM > > -----END PGP SIGNATURE----- From matt at openssl.org Thu Apr 23 17:10:18 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Apr 2020 18:10:18 +0100 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> Message-ID: <5ebc99d8-2260-c5a6-ef76-eb91fd5c10d0@openssl.org> On 23/04/2020 18:01, Sam Roberts wrote: > Resending to -users. > > On Thu, Apr 23, 2020 at 9:58 AM Sam Roberts wrote: >> >> Seems to be something wrong with the way config is generating the >> version strings: >> gcc -Icrypto -I. -Iinclude -Iproviders/common/include >> -Iproviders/implementations/include -Icrypto/include -DAES_ASM >> -DBSAES_ASM -DCMLL_ASM -DECP_NISTZ256_ASM -DGHASH_ASM -DKECCAK1600_ASM >> -DMD5_ASM -DOPENSSL_BN_ASM_GF2m -DOPENSSL_BN_ASM_MONT >> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 >> -DPOLY1305_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM >> -DWHIRLPOOL_ASM -DX25519_ASM -fPIC -pthread -m64 -Wa,--noexecstack >> -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_BUILDING_OPENSSL >> -DOPENSSL_PIC -DOPENSSLDIR="\"/usr/local/ssl\"" >> -DENGINESDIR="\"/usr/local/lib/engines-3\"" >> -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG -MMD -MF >> crypto/libcrypto-lib-cversion.d.tmp -MT >> crypto/libcrypto-lib-cversion.o -c -o crypto/libcrypto-lib-cversion.o >> crypto/cversion.c >> In file included from include/openssl/macros.h:11, >> from include/openssl/opensslconf.h:14, >> from include/openssl/macros.h:10, >> from include/openssl/crypto.h:15, >> from include/internal/cryptlib.h:23, >> from crypto/cversion.c:10: >> crypto/cversion.c: In function 'OpenSSL_version': >> include/openssl/opensslv.h:91:54: error: expected ';' before numeric constant >> 91 | # define OPENSSL_VERSION_TEXT "OpenSSL 3.0.0-alpha1 "23 Apr 2020"" >> | ^~ >> crypto/cversion.c:50:16: note: in expansion of macro 'OPENSSL_VERSION_TEXT' >> 50 | return OPENSSL_VERSION_TEXT; >> | ^~~~~~~~~~~~~~~~~~~~ >> make[1]: *** [Makefile:15616: crypto/libcrypto-lib-cversion.o] Error 1 >> make[1]: Leaving directory '/home/sam/s/openssl-3.0.0-alpha1' >> make: *** [Makefile:3009: build_sw] Error 2 >> >> >> I'm on Linux, just did a `./config; make`. >> >> Its fairly obvious what the string should have been, I edited and am >> continuing with the build. Yes - very annoying. The release scripts added the date in a commit and broke the build - then they added another commit to remove it again ready for the next release - and everything works again. So from git's point of view it worked before and it worked after...just not in the actual release!!! The workaround is straightforward (remove the quotes from the RELEASE_DATE line in the VERSION file). I've added some notes to the 3.0 release notes on the wiki about it. Matt >> >> >> On Thu, Apr 23, 2020 at 7:29 AM OpenSSL wrote: >>> > > OpenSSL version 3.0 alpha 1 released > ==================================== > > OpenSSL - The Open Source toolkit for SSL/TLS > https://www.openssl.org/ > > OpenSSL 3.0 is currently in alpha. > > OpenSSL 3.0 alpha 1 has now been made available. > > Note: This OpenSSL pre-release has been provided for testing ONLY. > It should NOT be used for security critical purposes. > > Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well > as known issues are available on the OpenSSL Wiki, here: > > https://wiki.openssl.org/index.php/OpenSSL_3.0 > > The alpha release is available for download via HTTPS and FTP from the > following master locations (you can find the various FTP mirrors under > https://www.openssl.org/source/mirror.html): > > * https://www.openssl.org/source/ > * ftp://ftp.openssl.org/source/ > > The distribution file name is: > > o openssl-3.0.0-alpha1.tar.gz > Size: 9530120 > SHA1 checksum: 4db145d3d9c9d7bfaa7b2a1fe1670f7a3781bb06 > SHA256 checksum: 9d5be9122194ad1d649254de5e72afd329252f134791389d0cef627b18ed9a57 > > The checksums were calculated using the following commands: > > openssl sha1 openssl-3.0.0-alpha1.tar.gz > openssl sha256 openssl-3.0.0-alpha1.tar.gz > > Please download and check this $LABEL release as soon as possible. > To report a bug, open an issue on GitHub: > > https://github.com/openssl/openssl/issues > > Please check the release notes and mailing lists to avoid duplicate > reports of known issues. (Of course, the source is also available > on GitHub.) > > Yours, > > The OpenSSL Project Team. > > From openssl-users at dukhovni.org Thu Apr 23 17:32:53 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 23 Apr 2020 13:32:53 -0400 Subject: questions on using ed25519 In-Reply-To: References: <20200421173430.GG41308@straasha.imrryr.org> <20200422171205.GK41308@straasha.imrryr.org> <89a956f2-a27d-a961-09be-05fb42afd7b6@openssl.org> Message-ID: <20200423173253.GM41308@straasha.imrryr.org> On Thu, Apr 23, 2020 at 11:23:35AM +0200, Nicola Tuveri wrote: > > On 22/04/2020 18:12, Viktor Dukhovni wrote: > > > sadly the > > > EVP_PKEY_METHOD for ed25519 has a NULL sign() member, instead, somewhat > > > ironically, it has a digestsign() method. This is presumably to > > > distinguish between the pure and prehash variants. Therefore, presently > > > pkeyutl(1) indeed appears to not implement signing and verifying with > > > ed25519, this looks doable with modest effort. > > > > I'm fairly sure it used to have a "sign" function during the dev phase - > > but it was taken out. I forget the reasoning. > > Yes, that change was intentional, the reasoning is detailed in the > discussion in: https://github.com/openssl/openssl/pull/6284 This did leave us with a documentation bug, the dgst(1) manpage suggests using pkeyutl(1) for ed25519 and ed448, but the latter does not work. The dgst(1) manpage probably needs a tweak to remove the misleading redirect. Or else backport the pkeyutl(1) support from 3.0, but we're not supposed to add features in 1.1.1x patch releases, and there are no plans for a 1.1.2. -- Viktor. From openssl-users at dukhovni.org Thu Apr 23 19:58:10 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 23 Apr 2020 15:58:10 -0400 Subject: [openssl-security] FreeBSD Port: security/openssl In-Reply-To: <5109a977-6e2e-c7f6-1ad3-c2f97f8497bb@aventia.pw> References: <5109a977-6e2e-c7f6-1ad3-c2f97f8497bb@aventia.pw> Message-ID: <20200423195810.GN41308@straasha.imrryr.org> > https://bugs.php.net/bug.php?id=79513 [ This is not an OpenSSL security issue, please move this discussion to the openssl-users list. Moved "openssl-security" to Bcc. ] On Thu, Apr 23, 2020 at 03:24:15PM +0200, Jason de Cordoba wrote: > Starting php_fpm. > Segmentation fault (core dumped) Can you post the output of $ readelf -d /usr/local/bin/php $ ldd /usr/local/bin/php > # gdb /usr/local/bin/php php.core > Program terminated with signal 11, Segmentation fault. > Reading symbols from /usr/local/lib/libssl.so.11...done. > Loaded symbols for /usr/local/lib/libssl.so.11 > Reading symbols from /usr/local/lib/libcrypto.so.11...done. > Loaded symbols for /usr/local/lib/libcrypto.so.11 Seems to be using OpenSSL from ports, and not from base. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x00000008049a8482 in OPENSSL_LH_doall_arg () from > /usr/local/lib/libcrypto.so.11 Is this the entire stack trace? Can you post the output of the gdb "bt" (a.k.a. "where") command? -- Viktor. From vieuxtech at gmail.com Thu Apr 23 23:05:52 2020 From: vieuxtech at gmail.com (Sam Roberts) Date: Thu, 23 Apr 2020 16:05:52 -0700 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <5ebc99d8-2260-c5a6-ef76-eb91fd5c10d0@openssl.org> References: <20200423142936.GA24450@openssl.org> <5ebc99d8-2260-c5a6-ef76-eb91fd5c10d0@openssl.org> Message-ID: Fwiw, took a quick run at building and testing Node.js against the 3.x beta. It was API compatible enough to build. The DH_, ECDH_, HMAC_, etc. deprecations make sense, will look at those. My assumption is that EVP versions of these exist in openssl 1.1.1, and that if we switch our openssl 1.1.1 code to using the EVP APIs, that that cod will then work unchanged when we update to openssl 3.x? ERR_func_error_string, what is its replacement? I didn't see it mentioned in the wiki, but its marked deprecated. Tests didn't go so well. Minor changes in error strings are to be expected, but more than that changed. I haven't looked at these yet other than scan the output, we might be relying on internals, but just for anyone curious, here's the test output: https://gist.github.com/sam-github/5a3b3775029efb3d31109d7e6e390f85 From tmraz at redhat.com Fri Apr 24 07:38:38 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 24 Apr 2020 09:38:38 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> <5ebc99d8-2260-c5a6-ef76-eb91fd5c10d0@openssl.org> Message-ID: <9edd48add6e0c68639311bf0c5fded05f035b779.camel@redhat.com> On Thu, 2020-04-23 at 16:05 -0700, Sam Roberts wrote: > Fwiw, took a quick run at building and testing Node.js against the > 3.x beta. > > It was API compatible enough to build. The DH_, ECDH_, HMAC_, etc. > deprecations make sense, will look at those. > > My assumption is that EVP versions of these exist in openssl 1.1.1, > and that if we switch our openssl 1.1.1 code to using the EVP APIs, > that that cod will then work unchanged when we update to openssl 3.x? > > ERR_func_error_string, what is its replacement? I didn't see it > mentioned in the wiki, but its marked deprecated. There is no replacement. The function code part of the error code is always set to zero. I've now mentioned it in the Wiki page. https://wiki.openssl.org/index.php/OpenSSL_3.0#Other_notable_deprecations_and_changes -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From matt at openssl.org Fri Apr 24 08:05:52 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 24 Apr 2020 09:05:52 +0100 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> <5ebc99d8-2260-c5a6-ef76-eb91fd5c10d0@openssl.org> Message-ID: On 24/04/2020 00:05, Sam Roberts wrote: > Fwiw, took a quick run at building and testing Node.js against the 3.x beta. > > It was API compatible enough to build. Good to hear! > The DH_, ECDH_, HMAC_, etc. > deprecations make sense, will look at those. > > My assumption is that EVP versions of these exist in openssl 1.1.1, > and that if we switch our openssl 1.1.1 code to using the EVP APIs, > that that cod will then work unchanged when we update to openssl 3.x? Yes. For DH_ and ECDH_ use EVP_PKEY_derive*: https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_derive.html HMAC_ is a bit more complicated. The preferred way of doing this is to use the EVP_MAC_* API. https://www.openssl.org/docs/manmaster/man3/EVP_MAC.html However this API is newly added in 3.0. You can calculate an HMAC via EVP in 1.1.1 (and this way still works in 3.0), but frankly the old way of doing things is a bit of hack. It does work though. There is an example on the wiki: https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying > > ERR_func_error_string, what is its replacement? I didn't see it > mentioned in the wiki, but its marked deprecated. > > Tests didn't go so well. Minor changes in error strings are to be > expected, but more than that changed. > > I haven't looked at these yet other than scan the output, we might be > relying on internals, but just for anyone curious, here's the test > output: Relying on internals would explain it. Or its also entirely possible that we accidentally broke something. I look forward to seeing the results of your investigations. > > https://gist.github.com/sam-github/5a3b3775029efb3d31109d7e6e390f85 > Scanning the output I notice a couple of things. There's a number of these: ERR_OSSL_DH_MODULUS_TOO_SMALL There is this in the CHANGES.md file which might explain it: * Enforce a minimum DH modulus size of 512 bits. This one is interesting: ERR_OSSL_EVP_FETCH_FAILED This means that the algorithm you are trying to use isn't available in the loaded providers. Since you should be getting the default provider loaded automatically it could be because some legacy algorithms were moved to the legacy provider (MD2, MD4, MDC2, RMD160, CAST5, BF (Blowfish), IDEA, SEED, RC2, RC4, RC5 and DES (but not 3DES)). If you're using something from that list then that would explain it. Matt From ylavic.dev at gmail.com Fri Apr 24 11:26:05 2020 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Fri, 24 Apr 2020 13:26:05 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200423142936.GA24450@openssl.org> References: <20200423142936.GA24450@openssl.org> Message-ID: Hi team, I gave 3.0.0-alpha1 a try with Apache httpd. tl;dr it works with minimal changes, congrats! The changes needed on httpd side: - SSL_CTX_load_verify_locations() and X509_STORE_load_locations() Replaced by {SSL_CTX,X590_STORE}_load_verify_file() + {SSL_CTX,X590_STORE}_load_verify_{dir,path}(). I.e. open coding. - DH_bits(dh) (used for logging only in httpd) Replaced by BN_num_bits(DH_get0_p(dh)). Not sure this one should be deprecated, it seems to be used in several places in openssl codebase still, no replacement? - SSL_CTX_set_tlsext_ticket_key_cb() Replaced by SSL_CTX_set_tlsext_ticket_key_evp_cb() because of HMAC_Init_ex(). With a bit of #ifdef-ery (for compatibility), the openssl-3 version uses EVP_MAC_CTX_set_params() for HMAC, per man page. - ERR_peek_error_line_data() => ERR_peek_error_data() Easy one. - Custom input BIO_METHOD (using httpd filters' stack) asserted its _ctrl() was never called, so far.. The new BIO_eof() calls in codebase, notably from ssl3_read_n(), breaks this assertion. Handling the case for BIO_CTRL_EOF made it, dunno if others may be bitten by that. And that's all, no intensive testing done yet, but at least the (automatic) tests framework passes locally, nice work! Thanks, Yann. From Joerg.Hessdoerfer at sea-gmbh.com Fri Apr 24 11:53:14 2020 From: Joerg.Hessdoerfer at sea-gmbh.com (=?UTF-8?B?SsO2cmcgSGXDn2TDtnJmZXI=?=) Date: Fri, 24 Apr 2020 13:53:14 +0200 Subject: Generating and checking SM2 signatures In-Reply-To: References: <92d52bbe-62b9-1228-9c9c-0ae41049f4f5@sea-gmbh.com> Message-ID: Hello Billy, On 23.04.2020 04:36, Billy Brumley wrote: >> I'm tasked to implement certain cryptographic functions (chiefly >> signature creation/validation) using the SM2 algorithm for a >> communication testing application. My problem is that the standard which >> I need to follow (which is, unfortunately, not a public standard) states >> that the signature needs to be generated over H(data input) || H(some >> ID) , so I cannot use the EVP-Method as I understand it from >> https://www.openssl.org/docs/manmaster/man7/SM2.html (here, H is the SM3 >> hash function). This would be possible to achieve by generating the >> digest and then using the (albeit deprecated) function ECDSA_do_sign for >> ECDSA but I don't know how to do it for SM2. > It seems like you're trying to roll your own SM2 -- don't do that ;) No, actually I don't. But tell that the standards groups ;-) >> Is there any way to do this with openssl? Any help or pointer is very >> much appreciated! > I ... think it is possible directly with EVP and control strings. Step through > > openssl pkeyutl -inkey private.key -in /some/file -rawin -sign > -pkeyopt sm2_id:foobar > > in a debugger and that should get you on the right path. > > BBB thanks for the pointer! This got me started in the right direction. I did not use the debugger, but the source code of pkeyutil instead ;-) I can now (I hope) generate signatures without using the built-in digest hash first, by simply calling EVP_DigestSignInit(mctx, NULL, NULL, NULL, pkey) instead of EVP_DigestSignInit(mctx, NULL, EVP_sm3(), NULL, pkey) Thank you again and stay well, ??? J?rg -- J?rg He?d?rfer S.E.A. Datentechnik GmbH M?lheimer Stra?e 7 53840 Troisdorf Tel.: +49 2241 12737-19 Fax.: +49 2241 12737-14 E-Mail: Joerg.Hessdoerfer at sea-gmbh.com Web : http://www.sea-gmbh.com Informationen nach 37aHGB, 35a GmbH-Gesetz: S.E.A. Science& Engineering Applications Datentechnik GmbH Sitz der Gesellschaft K?ln Handelsregister K?ln HRB 27016 Gesch?ftsf?hrer: Dr. Gerd Schmitz, Wolfram Koerver From ylavic.dev at gmail.com Fri Apr 24 12:15:00 2020 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Fri, 24 Apr 2020 14:15:00 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> Message-ID: On Fri, Apr 24, 2020 at 1:26 PM Yann Ylavic wrote: > > - Custom input BIO_METHOD (using httpd filters' stack) asserted its > _ctrl() was never called, so far.. > The new BIO_eof() calls in codebase, notably from ssl3_read_n(), > breaks this assertion. > Handling the case for BIO_CTRL_EOF made it, dunno if others may be > bitten by that. BTW, what is a BIO supposed to do on BIO_CTRL_EOF request when there is no pending data, some kind of speculative read to check whether the connection is still up or returning zero lazily is fine? Regards, Yann. From matt at openssl.org Fri Apr 24 12:15:21 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 24 Apr 2020 13:15:21 +0100 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> Message-ID: <2abd85b3-4480-8c99-e1ba-c2a773a39a8a@openssl.org> On 24/04/2020 12:26, Yann Ylavic wrote: > Hi team, > > I gave 3.0.0-alpha1 a try with Apache httpd. > tl;dr it works with minimal changes, congrats! That's great to hear. Thanks for the feedback Yann! Matt From matt at openssl.org Fri Apr 24 12:20:31 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 24 Apr 2020 13:20:31 +0100 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> Message-ID: <71cf31b3-fcee-deae-0a5e-4a5979c2a10f@openssl.org> On 24/04/2020 13:15, Yann Ylavic wrote: > On Fri, Apr 24, 2020 at 1:26 PM Yann Ylavic wrote: >> >> - Custom input BIO_METHOD (using httpd filters' stack) asserted its >> _ctrl() was never called, so far.. >> The new BIO_eof() calls in codebase, notably from ssl3_read_n(), >> breaks this assertion. >> Handling the case for BIO_CTRL_EOF made it, dunno if others may be >> bitten by that. > > BTW, what is a BIO supposed to do on BIO_CTRL_EOF request when there > is no pending data, some kind of speculative read to check whether the > connection is still up or returning zero lazily is fine? I'd say returning 0 lazily is fine. Matt From nic.tuv at gmail.com Fri Apr 24 15:16:57 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Fri, 24 Apr 2020 17:16:57 +0200 Subject: questions on using ed25519 In-Reply-To: <20200423173253.GM41308@straasha.imrryr.org> References: <20200421173430.GG41308@straasha.imrryr.org> <20200422171205.GK41308@straasha.imrryr.org> <89a956f2-a27d-a961-09be-05fb42afd7b6@openssl.org> <20200423173253.GM41308@straasha.imrryr.org> Message-ID: That's right! Thanks Viktor for pointing that out!! I just opened an issue to track this: https://github.com/openssl/openssl/issues/11633 We warmly welcome contributions from everyone and this could be a good first issue to work on: Yang (as the person that started this thread and noticed the issue first) or anyone else from the community, are you willing to get your hands dirty and help out the project? Nicola On Thu, 23 Apr 2020 at 19:33, Viktor Dukhovni wrote: > On Thu, Apr 23, 2020 at 11:23:35AM +0200, Nicola Tuveri wrote: > > > > On 22/04/2020 18:12, Viktor Dukhovni wrote: > > > > sadly the > > > > EVP_PKEY_METHOD for ed25519 has a NULL sign() member, instead, > somewhat > > > > ironically, it has a digestsign() method. This is presumably to > > > > distinguish between the pure and prehash variants. Therefore, > presently > > > > pkeyutl(1) indeed appears to not implement signing and verifying with > > > > ed25519, this looks doable with modest effort. > > > > > > I'm fairly sure it used to have a "sign" function during the dev phase > - > > > but it was taken out. I forget the reasoning. > > > > Yes, that change was intentional, the reasoning is detailed in the > > discussion in: https://github.com/openssl/openssl/pull/6284 > > This did leave us with a documentation bug, the dgst(1) manpage suggests > using pkeyutl(1) for ed25519 and ed448, but the latter does not work. > > The dgst(1) manpage probably needs a tweak to remove the misleading > redirect. Or else backport the pkeyutl(1) support from 3.0, but we're > not supposed to add features in 1.1.1x patch releases, and there are no > plans for a 1.1.2. > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Apr 24 15:12:14 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 24 Apr 2020 17:12:14 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200423142936.GA24450@openssl.org> References: <20200423142936.GA24450@openssl.org> Message-ID: <20200424151214.I3RW8%steffen@sdaoden.eu> Hello! OpenSSL wrote in <20200423142936.GA24450 at openssl.org>: | OpenSSL version 3.0 alpha 1 released That surely is "a great step" for you who work with that code! Congratulations. I get compile errors, maybe some config flags are not honoured correctly yet? So i am using a local git clone checkout at [852c2ed260], configured via #?0|kent:openssl$ ./config \ --prefix=/home/steffen/usr-kent-linux-x86_64/opt/.ossl-3.0 \ zlib-dynamic no-hw shared no-deprecated no-async no-tests \ -Wl,-rpath,'$(LIBRPATH)' Operating system: x86_64-whatever-linux2 ***** Deprecated options: no-hw Configuring OpenSSL version 3.0.0-alpha2-dev for target linux-x86_64 Using os-specific seed configuration Creating configdata.pm Running configdata.pm Creating Makefile ********************************************************************** *** *** *** OpenSSL has been successfully configured *** *** *** *** If you encounter a problem while building, please open an *** *** issue on GitHub *** I cannot open a github issue, i have no github account, and if i were from Cuba, Iran or several different other states that my parents had chosen etc etc etc. Etc. (I had an account ten years or so ago, and wanted to pay for the service with cash, with they did not want. Only credit cards. So i left.) *** and include the output from the following command: *** *** *** *** perl configdata.pm --dump *** *** *** *** (If you are new to OpenSSL, you might want to consult the *** *** 'Troubleshooting' section in the INSTALL file first) *** This is INSTALL.md now. *** *** ********************************************************************** The "first" failure happens here, i wonder whether that shouldn't be covered by "no-tests"? Can't locate Test/Builder/TodoDiag.pm in @INC (you may need to install the Test::Builder::TodoDiag module) (@INC contains: /tmp/openssl/util/perl . providers/common/der /home/steffen/src/symobj.git/lib /usr/lib/p erl5/site_perl/5.28/linux-thread-multi /usr/lib/perl5/site_perl/5.28 /usr/lib/perl5/5.28/linux-thread-multi /usr/lib/perl5/5.28 /tmp/openssl/external/perl/Text-Template-1.56/lib) at /usr/lib/perl5/5.28/Test/Build er.pm line 38. BEGIN failed--compilation aborted at /usr/lib/perl5/5.28/Test/Builder.pm line 38. Compilation failed in require at /usr/lib/perl5/5.28/Test/Builder/Module.pm line 5. BEGIN failed--compilation aborted at /usr/lib/perl5/5.28/Test/Builder/Module.pm line 5. Compilation failed in require at /usr/lib/perl5/5.28/Test/More.pm line 22. BEGIN failed--compilation aborted at /usr/lib/perl5/5.28/Test/More.pm line 22. Compilation failed in require at /tmp/openssl/util/perl/OpenSSL/OID.pm line 309. BEGIN failed--compilation aborted at /tmp/openssl/util/perl/OpenSSL/OID.pm line 309. Compilation failed in require at providers/common/der/oids_to_c.pm line 16. BEGIN failed--compilation aborted at providers/common/der/oids_to_c.pm line 16. Compilation failed in require. BEGIN failed--compilation aborted. Can't locate Test/Builder/TodoDiag.pm in @INC (you may need to install the Test::Builder::TodoDiag module) (@INC contains: /tmp/openssl/util/perl . providers/common/der /home/steffen/src/symobj.git/lib /usr/lib/p erl5/site_perl/5.28/linux-thread-multi /usr/lib/perl5/site_perl/5.28 /usr/lib/perl5/5.28/linux-thread-multi /usr/lib/perl5/5.28 /tmp/openssl/external/perl/Text-Template-1.56/lib) at /usr/lib/perl5/5.28/Test/Build er.pm line 38. BEGIN failed--compilation aborted at /usr/lib/perl5/5.28/Test/Builder.pm line 38. Compilation failed in require at /usr/lib/perl5/5.28/Test/Builder/Module.pm line 5. BEGIN failed--compilation aborted at /usr/lib/perl5/5.28/Test/Builder/Module.pm line 5. Compilation failed in require at /usr/lib/perl5/5.28/Test/More.pm line 22. BEGIN failed--compilation aborted at /usr/lib/perl5/5.28/Test/More.pm line 22. Compilation failed in require at /tmp/openssl/util/perl/OpenSSL/OID.pm line 309. BEGIN failed--compilation aborted at /tmp/openssl/util/perl/OpenSSL/OID.pm line 309. Compilation failed in require at providers/common/der/oids_to_c.pm line 16. BEGIN failed--compilation aborted at providers/common/der/oids_to_c.pm line 16. Compilation failed in require. BEGIN failed--compilation aborted. make[1]: *** [Makefile:20051: providers/common/include/prov/der_ec.h] Error 2 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [Makefile:20039: providers/common/include/prov/der_dsa.h] Error 2 make[1]: Leaving directory '/tmp/openssl' make: *** [Makefile:2801: build_sw] Error 2 So if i blindly hit "make" again i then get gcc -Iproviders/common/include/prov -I. -Icrypto -Iinclude -Iproviders/implementations/include -Iproviders/common/include -DAES_ASM -DBSAES_ASM -DECP_NISTZ256_ASM -DGHASH_ASM -DKECCAK1600_ASM -DMD5_ASM -DOPENSSL_BN_ASM_GF2m -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DX25519_ASM -fPIC -pthread -m64 -Wa,--noexecstack -O1 -g -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/home/steffen/usr-kent-linux-x86_64/opt/.ossl-3.0/ssl\"" -DENGINESDIR="\"/home/steffen/usr-kent-linux-x86_64/opt/.ossl-3.0/lib/engines-3\"" -DMODULESDIR="\"/home/steffen/usr-kent-linux-x86_64/opt/.ossl-3.0/lib/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL -DZLIB -DZLIB_SHARED -DNDEBUG -MMD -MF providers/implementations/signature/libimplementations-lib-dsa.d.tmp -MT providers/implementations/signature/libimplementations-lib-dsa.o -c -o providers/implementations/signature/libimplementations-lib-dsa.o providers/implementations/signature/dsa.c providers/implementations/signature/dsa.c: In function 'dsa_setup_md': providers/implementations/signature/dsa.c:152:9: error: unknown type name 'WPACKET' WPACKET pkt; ^~~~~~~ providers/implementations/signature/dsa.c:170:13: warning: implicit declaration of function 'WPACKET_init_der' [-Wimplicit-function-declaration] if (WPACKET_init_der(&pkt, ctx->aid_buf, sizeof(ctx->aid_buf)) ^~~~~~~~~~~~~~~~ providers/implementations/signature/dsa.c:171:16: warning: implicit declaration of function 'DER_w_algorithmIdentifier_DSA_with'; did you mean 'dsa_algorithmidentifier_encoding'? [-Wimplicit-function-declaration] && DER_w_algorithmIdentifier_DSA_with(&pkt, -1, ctx->dsa, md_nid) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ dsa_algorithmidentifier_encoding providers/implementations/signature/dsa.c:172:16: warning: implicit declaration of function 'WPACKET_finish' [-Wimplicit-function-declaration] && WPACKET_finish(&pkt)) { ^~~~~~~~~~~~~~ providers/implementations/signature/dsa.c:173:13: warning: implicit declaration of function 'WPACKET_get_total_written' [-Wimplicit-function-declaration] WPACKET_get_total_written(&pkt, &ctx->aid_len); ^~~~~~~~~~~~~~~~~~~~~~~~~ providers/implementations/signature/dsa.c:174:24: warning: implicit declaration of function 'WPACKET_get_curr' [-Wimplicit-function-declaration] ctx->aid = WPACKET_get_curr(&pkt); ^~~~~~~~~~~~~~~~ providers/implementations/signature/dsa.c:174:22: warning: assignment to 'unsigned char *' from 'int' makes pointer from integer without a cast [-Wint-conversion] ctx->aid = WPACKET_get_curr(&pkt); ^ providers/implementations/signature/dsa.c:176:9: warning: implicit declaration of function 'WPACKET_cleanup'; did you mean 'EVP_PBE_cleanup'? [-Wimplicit-function-declaration] WPACKET_cleanup(&pkt); ^~~~~~~~~~~~~~~ EVP_PBE_cleanup make[1]: *** [Makefile:20928: providers/implementations/signature/libimplementations-lib-dsa.o] Error 1 make[1]: Leaving directory '/tmp/openssl' make: *** [Makefile:2801: build_sw] Error 2 I have to go now, maybe this all goes away if i get myself the Test::Builder::TodoDiag perl module? Ciao and Good luck! from Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From doctor at doctor.nl2k.ab.ca Fri Apr 24 15:51:48 2020 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 24 Apr 2020 09:51:48 -0600 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200424151214.I3RW8%steffen@sdaoden.eu> References: <20200423142936.GA24450@openssl.org> <20200424151214.I3RW8%steffen@sdaoden.eu> Message-ID: <20200424155148.GA35632@doctor.nl2k.ab.ca> All right, I am test 3.0 alpha 2 using sshd and squid n FreeBSD 12.1 I will also test on httpd , php 74 et al. so far openssh 8.2p1 and openssl 2.0 is working. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Joy is not in things; it is in us. -Richard Wagner From vieuxtech at gmail.com Fri Apr 24 15:55:21 2020 From: vieuxtech at gmail.com (Sam Roberts) Date: Fri, 24 Apr 2020 08:55:21 -0700 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> <5ebc99d8-2260-c5a6-ef76-eb91fd5c10d0@openssl.org> Message-ID: On Fri, Apr 24, 2020 at 1:05 AM Matt Caswell wrote: > This one is interesting: > > ERR_OSSL_EVP_FETCH_FAILED > > > This means that the algorithm you are trying to use isn't available in > the loaded providers. Since you should be getting the default provider > loaded automatically it could be because some legacy algorithms were > moved to the legacy provider (MD2, MD4, MDC2, RMD160, CAST5, BF > (Blowfish), IDEA, SEED, RC2, RC4, RC5 and DES (but not 3DES)). If you're > using something from that list then that would explain it. Can we add the legacy provider, via configuration, or via code? From nic.tuv at gmail.com Fri Apr 24 16:07:37 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Fri, 24 Apr 2020 18:07:37 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> <5ebc99d8-2260-c5a6-ef76-eb91fd5c10d0@openssl.org> Message-ID: At https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers there was already an example of how to do this programmatically, and a link to the manpage for the config file syntax. I just added also a minimal config file example to load both the default and the legacy provider in the default library context. Cheers, Nicola On Fri, 24 Apr 2020 at 17:56, Sam Roberts wrote: > On Fri, Apr 24, 2020 at 1:05 AM Matt Caswell wrote: > > This one is interesting: > > > > ERR_OSSL_EVP_FETCH_FAILED > > > > > > This means that the algorithm you are trying to use isn't available in > > the loaded providers. Since you should be getting the default provider > > loaded automatically it could be because some legacy algorithms were > > moved to the legacy provider (MD2, MD4, MDC2, RMD160, CAST5, BF > > (Blowfish), IDEA, SEED, RC2, RC4, RC5 and DES (but not 3DES)). If you're > > using something from that list then that would explain it. > > Can we add the legacy provider, via configuration, or via code? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ylavic.dev at gmail.com Fri Apr 24 16:12:06 2020 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Fri, 24 Apr 2020 18:12:06 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200424155148.GA35632@doctor.nl2k.ab.ca> References: <20200423142936.GA24450@openssl.org> <20200424151214.I3RW8%steffen@sdaoden.eu> <20200424155148.GA35632@doctor.nl2k.ab.ca> Message-ID: On Fri, Apr 24, 2020 at 5:50 PM The Doctor wrote: > > I will also test on httpd , php 74 et al. This commit might help if you want to test httpd trunk/master: https://github.com/apache/httpd/commit/316aea784d9423688ea38943d95d1d2b614fc921 Regards, Yann. From ca+ssl-users at esmtp.org Fri Apr 24 16:38:03 2020 From: ca+ssl-users at esmtp.org (Claus Assmann) Date: Fri, 24 Apr 2020 18:38:03 +0200 Subject: 3.0.0-alpha1 compile error: minor problem Message-ID: <20200424163803.GA7346@kiel.esmtp.org> It seems something went wrong when include/openssl/opensslv.h was generated? cc -Icrypto -I. -Iinclude -Iproviders/common/include -Iproviders/implementations/include -Icrypto/include -DAES_ASM -DBSAES_ASM -DCMLL_ASM -DECP_NISTZ256_ASM -DGHASH_ASM -DKECCAK1600_ASM -DMD5_ASM -DOPENSSL_BN_ASM_GF2m -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DPOLY1305_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DSTATIC_LEGACY -DVPAES_ASM -DWHIRLPOOL_ASM -DX25519_ASM -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DL_ENDIAN -DOPENSSL_BUILDING_OPENSSL -DOPENSSL_PIC -DOPENSSLDIR="\"/home/ca/OpenBSD/openssl-3.0.0-alpha1\"" -DENGINESDIR="\"/home/ca/OpenBSD/openssl-3.0.0-alpha1/lib/engines-3\"" -DMODULESDIR="\"/home/ca/OpenBSD/openssl-3.0.0-alpha1/lib/ossl-modules\"" -D_THREAD_SAFE -D_REENTRANT -DNDEBUG -MMD -MF crypto/libcrypto-lib-cversion.d.tmp -MT crypto/libcrypto-lib-cversion.o -c -o crypto/libcrypto-lib-cversion.o crypto/cversion.c crypto/cversion.c:50:16: error: expected ';' after return statement return OPENSSL_VERSION_TEXT; ^ include/openssl/opensslv.h:91:54: note: expanded from macro 'OPENSSL_VERSION_TEXT' # define OPENSSL_VERSION_TEXT "OpenSSL 3.0.0-alpha1 "23 Apr 2020"" ^ OS: OpenBSD 6.6 Maybe it's specific to my setup? From matt at openssl.org Fri Apr 24 16:48:37 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 24 Apr 2020 17:48:37 +0100 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200424151214.I3RW8%steffen@sdaoden.eu> References: <20200423142936.GA24450@openssl.org> <20200424151214.I3RW8%steffen@sdaoden.eu> Message-ID: <94a03020-9f9e-cf31-c3e7-88fa4579b434@openssl.org> On 24/04/2020 16:12, Steffen Nurpmeso wrote: make: *** [Makefile:2801: build_sw] Error 2 > > I have to go now, maybe this all goes away if i get myself the > Test::Builder::TodoDiag perl module? I doubt it. This isn't code in the tests. Try adding this line with the other includes at at the top of the providers/implementations/signature/dsa.c file: #include "internal/packet.h" I don't see it listed there already...I wonder why no one has got this compilation error before now? Matt From doctor at doctor.nl2k.ab.ca Fri Apr 24 16:53:27 2020 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 24 Apr 2020 10:53:27 -0600 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200424155148.GA35632@doctor.nl2k.ab.ca> References: <20200423142936.GA24450@openssl.org> <20200424151214.I3RW8%steffen@sdaoden.eu> <20200424155148.GA35632@doctor.nl2k.ab.ca> Message-ID: <20200424165327.GA91887@doctor.nl2k.ab.ca> On Fri, Apr 24, 2020 at 09:51:48AM -0600, The Doctor wrote: > All right, I am test 3.0 alpha 2 using sshd and squid n FreeBSD 12.1 > I will also test on httpd , php 74 et al. > > so far openssh 8.2p1 and openssl 2.0 is working. > And squid 5.0.2 > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! > https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism > Joy is not in things; it is in us. -Richard Wagner -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Joy is not in things; it is in us. -Richard Wagner From matt at openssl.org Fri Apr 24 16:56:18 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 24 Apr 2020 17:56:18 +0100 Subject: 3.0.0-alpha1 compile error: minor problem In-Reply-To: <20200424163803.GA7346@kiel.esmtp.org> References: <20200424163803.GA7346@kiel.esmtp.org> Message-ID: <4c2e4a25-8644-0daf-3d6e-1739bff49a3d@openssl.org> On 24/04/2020 17:38, Claus Assmann wrote: > It seems something went wrong when include/openssl/opensslv.h > was generated? > > cc -Icrypto -I. -Iinclude -Iproviders/common/include -Iproviders/implementations/include -Icrypto/include -DAES_ASM -DBSAES_ASM -DCMLL_ASM -DECP_NISTZ256_ASM -DGHASH_ASM -DKECCAK1600_ASM -DMD5_ASM -DOPENSSL_BN_ASM_GF2m -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DPOLY1305_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DSTATIC_LEGACY -DVPAES_ASM -DWHIRLPOOL_ASM -DX25519_ASM -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DL_ENDIAN -DOPENSSL_BUILDING_OPENSSL -DOPENSSL_PIC -DOPENSSLDIR="\"/home/ca/OpenBSD/openssl-3.0.0-alpha1\"" -DENGINESDIR="\"/home/ca/OpenBSD/openssl-3.0.0-alpha1/lib/engines-3\"" -DMODULESDIR="\"/home/ca/OpenBSD/openssl-3.0.0-alpha1/lib/ossl-modules\"" -D_THREAD_SAFE -D_REENTRANT -DNDEBUG -MMD -MF crypto/libcrypto-lib-cversion.d.tmp -MT crypto/libcrypto-lib-cversion.o -c -o crypto/libcrypto-lib-cversion.o crypto/cversion.c > crypto/cversion.c:50:16: error: expected ';' after return statement > return OPENSSL_VERSION_TEXT; > ^ > include/openssl/opensslv.h:91:54: note: expanded from macro 'OPENSSL_VERSION_TEXT' > # define OPENSSL_VERSION_TEXT "OpenSSL 3.0.0-alpha1 "23 Apr 2020"" > ^ Known issue. Please check the release notes on the wiki for the workaround (section 2). https://wiki.openssl.org/index.php/OpenSSL_3.0#Installation_and_Compilation_of_OpenSSL_3.0 Matt From sfhacker at hotmail.com Fri Apr 24 20:31:43 2020 From: sfhacker at hotmail.com (Sergio NNX) Date: Fri, 24 Apr 2020 20:31:43 +0000 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200423142936.GA24450@openssl.org> References: <20200423142936.GA24450@openssl.org> Message-ID: * Windows 10 x64 * GCC 8.3.0 x86_64 $ openssl version -a OpenSSL 3.0.0-alpha1 "23 Apr 2020" (Library: OpenSSL 3.0.0-alpha1 "23 Apr 2020") built on: Fri Apr 24 18:14:53 2020 UTC platform: mingw64 options: bn(64,64) compiler: /mingw/bin/gcc.exe -m64 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_WIN32_IE=0x0501 -D__PTW32_STATIC_LIB -D__PTW32_CLEANUP_C -m64 -O2 -pipe -mms-bitfields -fno-builtin -march=core2 -mtune=core2 -DL_ENDIAN -DOPENSSL_BUILDING_OPENSSL -DOPENSSL_PIC -DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -D_MT -DZLIB -DNDEBUG -I/mingw/x86_64-pc-mingw32/include -I/mingw/x86_64-pc-mingw32/include/directx -I/mingw/include OPENSSLDIR: "C:/OpenSSL" ENGINESDIR: "C:/MinGW/lib/engines-3" MODULESDIR: "C:/MinGW/lib/ossl-modules" Seeding source: os-specific CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x29c67af Some issued found: on.obj crypto/cversion.c In file included from include/openssl/macros.h:11, from include/openssl/opensslconf.h:14, from include/openssl/macros.h:10, from include/openssl/crypto.h:15, from include/internal/cryptlib.h:23, from crypto/cversion.c:10: crypto/cversion.c: In function 'OpenSSL_version': include/openssl/opensslv.h:91:54: error: expected ';' before numeric constant # define OPENSSL_VERSION_TEXT "OpenSSL 3.0.0-alpha1 "23 Apr 2020"" ^~ crypto/cversion.c:50:16: note: in expansion of macro 'OPENSSL_VERSION_TEXT' return OPENSSL_VERSION_TEXT; ^~~~~~~~~~~~~~~~~~~~ make[1]: *** [crypto/libcrypto-lib-cversion.obj] Error 1 make[1]: Leaving directory `/src/openssl-3.0.0-alpha1' make: *** [build_sw] Error 2 ________________________________ From: openssl-users on behalf of OpenSSL Sent: Friday, 24 April 2020 12:29 AM To: openssl-project at openssl.org ; OpenSSL User Support ML ; OpenSSL Announce ML Subject: OpenSSL version 3.0.0-alpha1 published -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 1 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 1 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha1.tar.gz Size: 9530120 SHA1 checksum: 4db145d3d9c9d7bfaa7b2a1fe1670f7a3781bb06 SHA256 checksum: 9d5be9122194ad1d649254de5e72afd329252f134791389d0cef627b18ed9a57 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha1.tar.gz openssl sha256 openssl-3.0.0-alpha1.tar.gz Please download and check this $LABEL release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6hpQcACgkQ2cTSbQ5g RJHvtggAp7XIxm/00amD4TijQhJqMmGsj0RXqwAeSd0gWDQCf78GX4zMIW/tTgvk I3Mb67DsOR5gdPZN5TigyqRaXSIAzfb8ZT4Gs9lo/j8RUi5AmzT2RYexbRv6bF6E cQ0OabM3rk4qi4njTi/YD9YihO6/pv7tWZkkfPsN547bfm7p7fwCrEHw02En5IW8 hyFhkpKfA3c8MEa96yLwjhkYRTAzUmxus/mNID+Ja3/VTCmHjd1c57SHFPq9noll Wqzhs3jEhluZKHpwmSSA0KQh1ph0kh6fnKLEn3Oge5dYV3P+JrFCRfDEMsI1Nb/F hIr11rxXNxtBRKUSlOUyJATZn0sV6g== =uRpM -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Apr 24 21:06:14 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 24 Apr 2020 23:06:14 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <94a03020-9f9e-cf31-c3e7-88fa4579b434@openssl.org> References: <20200423142936.GA24450@openssl.org> <20200424151214.I3RW8%steffen@sdaoden.eu> <94a03020-9f9e-cf31-c3e7-88fa4579b434@openssl.org> Message-ID: <20200424210614.--OiB%steffen@sdaoden.eu> Hello and Good Evening! Matt Caswell wrote in <94a03020-9f9e-cf31-c3e7-88fa4579b434 at openssl.org>: |On 24/04/2020 16:12, Steffen Nurpmeso wrote: |make: *** [Makefile:2801: build_sw] Error 2 |> |> I have to go now, maybe this all goes away if i get myself the |> Test::Builder::TodoDiag perl module? | |I doubt it. This isn't code in the tests. Ok, i have updated to git master as of ~30 minutes ago and searched the net for that perl module, it is part of Test-Simple-1.302175 which i extracted into external/perl, then i did "echo Test-Simple-1.302175/lib >> MODULES.txt", updated my openssl-blade: make rule to --prefix=$(MYPREFIX) \ zlib-dynamic shared no-deprecated threads no-tests no-async -Wl,-rpath,'$(LIBRPATH)' and with this compilation succeeds! It is _incredibly_ fast! Wow! Well, i do not know. I am on CRUX-Linux version 3.5, which is less than a year old. Crucial packages like libc and perl (and i think these are all) are not updated in between releases, the kernel is up to you, the rest is rolling. |Try adding this line with the other includes at at the top of the |providers/implementations/signature/dsa.c file: | |#include "internal/packet.h" | |I don't see it listed there already...I wonder why no one has got this |compilation error before now? I tried that first, but it was a dead-end. Thanks, ciao, and good luck! from Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Sat Apr 25 21:06:13 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 25 Apr 2020 23:06:13 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200424210614.--OiB%steffen@sdaoden.eu> References: <20200424210614.--OiB%steffen@sdaoden.eu> Message-ID: <20200425210613.ScjXN%steffen@sdaoden.eu> Hello once more. OpenSSL wrote in <20200423142936.GA24450 at openssl.org>: | OpenSSL version 3.0 alpha 1 released I do not understand one thing at the moment. If i use no-deprecated then the stack handling is not available: /* * If we're building OpenSSL, or we have no-deprecated configured, * then we don't define the inline functions (see |SKM_DEFINE_STACK_OF|, * above), we just declare the stack datatypes. Otherwise, for compatibility * and to not remove the API's, we define the functions. We have the * trailing semicolon so that uses of this never need it. */ #if defined(OPENSSL_BUILDING_OPENSSL) || defined(OPENSSL_NO_DEPRECATED_3_0) # define DEFINE_OR_DECLARE_STACK_OF(s) STACK_OF(s); This of course results in all the stack things not being available, for example /.../xtls.c:1444:20: warning: implicit declaration of function 'sk_X509_num'; did you mean 'X509_new'? [-Wimplicit-function-declaration] for (i = 0; i < sk_X509_num(certs); ++i) { How can i access stacks without those accessors? Is this documented somewhere, i stopped searching for answers anywhere else, which is why i write this. Ciao and thank you, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rsalz at akamai.com Sat Apr 25 21:14:04 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 25 Apr 2020 21:14:04 +0000 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200425210613.ScjXN%steffen@sdaoden.eu> References: <20200424210614.--OiB%steffen@sdaoden.eu> <20200425210613.ScjXN%steffen@sdaoden.eu> Message-ID: > I do not understand one thing at the moment. If i use no-deprecated then the stack handling is not available: If you use no-deprecated you have to use DEFINE_STACK_OF in exactly one file. And use DECLARE_STACK in your common header file. Let me know if this works, or not, for you. From steffen at sdaoden.eu Sat Apr 25 21:15:43 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 25 Apr 2020 23:15:43 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200425210613.ScjXN%steffen@sdaoden.eu> References: <20200424210614.--OiB%steffen@sdaoden.eu> <20200425210613.ScjXN%steffen@sdaoden.eu> Message-ID: <20200425211543.AglEA%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20200425210613.ScjXN%steffen at sdaoden.eu>: |Hello once more. | |OpenSSL wrote in |<20200423142936.GA24450 at openssl.org>: || OpenSSL version 3.0 alpha 1 released | |I do not understand one thing at the moment. If i use |no-deprecated then the stack handling is not available: | | /* | * If we're building OpenSSL, or we have no-deprecated configured, | * then we don't define the inline functions (see |SKM_DEFINE_STACK_OF|, | * above), we just declare the stack datatypes. Otherwise, for compatibil\ | ity | * and to not remove the API's, we define the functions. We have the | * trailing semicolon so that uses of this never need it. | */ | #if defined(OPENSSL_BUILDING_OPENSSL) || defined(OPENSSL_NO_DEPRECATED_3\ | _0) | # define DEFINE_OR_DECLARE_STACK_OF(s) STACK_OF(s); | |This of course results in all the stack things not being |available, for example | | /.../xtls.c:1444:20: warning: implicit declaration of function 'sk_X509_\ | num'; did you mean 'X509_new'? [-Wimplicit-function-declaration] | for (i = 0; i < sk_X509_num(certs); ++i) { | |How can i access stacks without those accessors? |Is this documented somewhere, i stopped searching for answers |anywhere else, which is why i write this. Hihihi, after sending this mail i thought i go git, and indeed i found commit 852c2ed260 Author: Rich Salz AuthorDate: 2019-12-19 17:30:24 -0500 Commit: Tomas Mraz CommitDate: 2020-04-24 16:42:46 +0200 In OpenSSL builds, declare STACK for datatypes ... So i try that now. Ciao from Germany, a nice Sunday, and Good luck! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From kurt at roeckx.be Sat Apr 25 22:00:21 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 26 Apr 2020 00:00:21 +0200 Subject: opensssl 1.1.1g test failure(s) In-Reply-To: <9D29B2F0-397A-47E8-93A7-7F62A11453DA@lurchi.franken.de> References: <20200421172238.GA58719@kiel.esmtp.org> <20200421172709.GZ3811@akamai.com> <20200421173406.GA4489@kiel.esmtp.org> <9408961c-4564-b2b0-6fd9-2b682527200a@openssl.org> <9D29B2F0-397A-47E8-93A7-7F62A11453DA@lurchi.franken.de> Message-ID: <20200425220021.GA402559@roeckx.be> On Wed, Apr 22, 2020 at 11:02:47AM +0200, Michael Tuexen wrote: > > On 22. Apr 2020, at 10:38, Matt Caswell wrote: > > > > > > > > On 21/04/2020 23:45, Michael Tuexen wrote: > >>> Looks like the failing call is here: > >>> > >>> if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, > >>> (const void *)&on, sizeof(on)) != 0) { > >> Can you provide a pointer to the code? > > > > Yes, its here: > > > > https://github.com/openssl/openssl/blob/fa555aa8970260c3e198d91709b2d4b3e40f8fa8/crypto/bio/b_sock2.c#L267-L282 > OK. Thanks. > > Could it be that on == 0, when you do the setsockopt() call? Disabling IPV6_V6ONLY seems not to be supported > on OpenBSD: Yes: if (BIO_ADDR_family(addr) == AF_INET6) { /* * Note: Windows default of IPV6_V6ONLY is ON, and Linux is OFF. * Therefore we always have to use setsockopt here. */ on = options & BIO_SOCK_V6_ONLY ? 1 : 0; if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, (const void *)&on, sizeof(on)) != 0) { So something is calling BIO_listen without setting BIO_SOCK_V6_ONLY in options. All calling functions really should set BIO_SOCK_V6_ONLY if they actually support multiple sockets, and they should. Kurt From steffen at sdaoden.eu Sat Apr 25 22:05:55 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sun, 26 Apr 2020 00:05:55 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200424210614.--OiB%steffen@sdaoden.eu> <20200425210613.ScjXN%steffen@sdaoden.eu> Message-ID: <20200425220555.Q1z6H%steffen@sdaoden.eu> Hello Rich Salz, Salz, Rich wrote in : |> I do not understand one thing at the moment. If i use | no-deprecated then the stack handling is not available: | |If you use no-deprecated you have to use DEFINE_STACK_OF in exactly \ |one file. And use DECLARE_STACK in your common header file. |Let me know if this works, or not, for you. Yep, it works fine, it is only necessary in xtls.c. Yes, nice, why not reduce compile time and save prescious compiler memory by getting rid of all-inline one-liners. Sorry for coming over sarcastic, i am listening to "This monkeys gone to heaven" from The Pixies (from the 80s), it seemed due :-)) Can we expect that the oddity that Yann Ylavic reported ({SSL_CTX,X590_STORE}_load_verify_{dir,path}(), wrong glob:) stays as such? (I turned to Landslide of Fleetwood Mac..) Ciao, a nice Sunday, (and Good luck!), --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From kurt at roeckx.be Sat Apr 25 22:15:13 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 26 Apr 2020 00:15:13 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> Message-ID: <20200425221513.GB402559@roeckx.be> On Fri, Apr 24, 2020 at 01:26:05PM +0200, Yann Ylavic wrote: > > - DH_bits(dh) (used for logging only in httpd) > Replaced by BN_num_bits(DH_get0_p(dh)). > Not sure this one should be deprecated, it seems to be used in several > places in openssl codebase still, no replacement? I think the replacement is using the EVP_PKEY API and then use EVP_PKEY_bits() Kurt From rsalz at akamai.com Sat Apr 25 22:24:13 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 25 Apr 2020 22:24:13 +0000 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200425220555.Q1z6H%steffen@sdaoden.eu> References: <20200424210614.--OiB%steffen@sdaoden.eu> <20200425210613.ScjXN%steffen@sdaoden.eu> <20200425220555.Q1z6H%steffen@sdaoden.eu> Message-ID: <05C099A8-261F-43DF-A59A-97CCF030F0B4@akamai.com> > Yes, nice, why not reduce compile time and save prescious compiler memory by getting rid of all-inline one-liners. And link-time collapsing the identical code. I think this is an issue on some Solaris, for example. > Sorry for coming over sarcastic, i am listening to "This monkeys gone to heaven" from The Pixies (from the 80s), it seemed due :-)) Henh. I can give a boatload of Boston bands. Sometimes while working on OpenSSL I think of https://www.youtube.com/watch?v=F6z0Cv4PYvs ( From steffen at sdaoden.eu Sun Apr 26 00:18:07 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sun, 26 Apr 2020 02:18:07 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <05C099A8-261F-43DF-A59A-97CCF030F0B4@akamai.com> References: <20200424210614.--OiB%steffen@sdaoden.eu> <20200425210613.ScjXN%steffen@sdaoden.eu> <20200425220555.Q1z6H%steffen@sdaoden.eu> <05C099A8-261F-43DF-A59A-97CCF030F0B4@akamai.com> Message-ID: <20200426001807.gpmx1%steffen@sdaoden.eu> Salz, Rich wrote in <05C099A8-261F-43DF-A59A-97CCF030F0B4 at akamai.com>: |> Yes, nice, why not reduce compile time and save prescious compiler | memory by getting rid of all-inline one-liners. | |And link-time collapsing the identical code. I think this is an issue \ |on some Solaris, for example. | |> Sorry for coming | over sarcastic, i am listening to "This monkeys gone to heaven" | from The Pixies (from the 80s), it seemed due :-)) | |Henh. I can give a boatload of Boston bands. Sometimes while working \ |on OpenSSL I think of https://www.youtube.com/watch?v=F6z0Cv4PYvs ( Nice. Yes. I am hatching a bit on the story behind that.. But then again, the Killing Joke went on stage again after meeting on the funeral of one of their members, so something's about it. My interpretation. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tincanteksup at gmail.com Sun Apr 26 00:31:30 2020 From: tincanteksup at gmail.com (tincanteksup) Date: Sun, 26 Apr 2020 01:31:30 +0100 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <05C099A8-261F-43DF-A59A-97CCF030F0B4@akamai.com> References: <20200424210614.--OiB%steffen@sdaoden.eu> <20200425210613.ScjXN%steffen@sdaoden.eu> <20200425220555.Q1z6H%steffen@sdaoden.eu> <05C099A8-261F-43DF-A59A-97CCF030F0B4@akamai.com> Message-ID: <99b569c8-95c8-507f-251c-ccf20684c98f@gmail.com> I would normally refrain but ... On 25/04/2020 23:24, Salz, Rich via openssl-users wrote: >> Yes, nice, why not reduce compile time and save prescious compiler > memory by getting rid of all-inline one-liners. > > And link-time collapsing the identical code. I think this is an issue on some Solaris, for example. > >> Sorry for coming > over sarcastic, i am listening to "This monkeys gone to heaven" > from The Pixies (from the 80s), it seemed due :-)) > > Henh. I can give a boatload of Boston bands. Sometimes while working on OpenSSL I think of https://www.youtube.com/watch?v=F6z0Cv4PYvs ( > > https://www.youtube.com/watch?v=PDhiUh82dOo From yangbolinzju at gmail.com Sun Apr 26 02:01:22 2020 From: yangbolinzju at gmail.com (yang berlin) Date: Sun, 26 Apr 2020 10:01:22 +0800 Subject: questions on using ed25519 In-Reply-To: References: <20200421173430.GG41308@straasha.imrryr.org> <20200422171205.GK41308@straasha.imrryr.org> <89a956f2-a27d-a961-09be-05fb42afd7b6@openssl.org> <20200423173253.GM41308@straasha.imrryr.org> Message-ID: Sure, I can help. It's my pleasure to help with the project. Since you have opened an issue. Then what should I do? Nicola Tuveri ?2020?4?24??? ??11:17??? > That's right! Thanks Viktor for pointing that out!! > > I just opened an issue to track this: > https://github.com/openssl/openssl/issues/11633 > > We warmly welcome contributions from everyone and this could be a good > first issue to work on: Yang (as the person that started this thread and > noticed the issue first) or anyone else from the community, are you willing > to get your hands dirty and help out the project? > > > Nicola > > > On Thu, 23 Apr 2020 at 19:33, Viktor Dukhovni > wrote: > >> On Thu, Apr 23, 2020 at 11:23:35AM +0200, Nicola Tuveri wrote: >> >> > > On 22/04/2020 18:12, Viktor Dukhovni wrote: >> > > > sadly the >> > > > EVP_PKEY_METHOD for ed25519 has a NULL sign() member, instead, >> somewhat >> > > > ironically, it has a digestsign() method. This is presumably to >> > > > distinguish between the pure and prehash variants. Therefore, >> presently >> > > > pkeyutl(1) indeed appears to not implement signing and verifying >> with >> > > > ed25519, this looks doable with modest effort. >> > > >> > > I'm fairly sure it used to have a "sign" function during the dev >> phase - >> > > but it was taken out. I forget the reasoning. >> > >> > Yes, that change was intentional, the reasoning is detailed in the >> > discussion in: https://github.com/openssl/openssl/pull/6284 >> >> This did leave us with a documentation bug, the dgst(1) manpage suggests >> using pkeyutl(1) for ed25519 and ed448, but the latter does not work. >> >> The dgst(1) manpage probably needs a tweak to remove the misleading >> redirect. Or else backport the pkeyutl(1) support from 3.0, but we're >> not supposed to add features in 1.1.1x patch releases, and there are no >> plans for a 1.1.2. >> >> -- >> Viktor. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Sun Apr 26 07:36:26 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Sun, 26 Apr 2020 09:36:26 +0200 Subject: questions on using ed25519 In-Reply-To: References: <20200421173430.GG41308@straasha.imrryr.org> <20200422171205.GK41308@straasha.imrryr.org> <89a956f2-a27d-a961-09be-05fb42afd7b6@openssl.org> <20200423173253.GM41308@straasha.imrryr.org> Message-ID: The change in itself is quite trivial, just editing the dgst manpage to remove the reference to pkeyutl. The issue has more instructions and the idea was to use it as a way to let a new developer familiarize with OpenSSL contributing guidelines and process. Another user already started working on it, though! If anyone is interested we have more "good first issue" items on github that we considered a good starting point for users from the community that are willing to start contributing to the project by coding or working on the documentation. Nicola On Sun, Apr 26, 2020, 04:01 yang berlin wrote: > Sure, I can help. > It's my pleasure to help with the project. > Since you have opened an issue. Then what should I do? > > > Nicola Tuveri ?2020?4?24??? ??11:17??? > >> That's right! Thanks Viktor for pointing that out!! >> >> I just opened an issue to track this: >> https://github.com/openssl/openssl/issues/11633 >> >> We warmly welcome contributions from everyone and this could be a good >> first issue to work on: Yang (as the person that started this thread and >> noticed the issue first) or anyone else from the community, are you willing >> to get your hands dirty and help out the project? >> >> >> Nicola >> >> >> On Thu, 23 Apr 2020 at 19:33, Viktor Dukhovni >> wrote: >> >>> On Thu, Apr 23, 2020 at 11:23:35AM +0200, Nicola Tuveri wrote: >>> >>> > > On 22/04/2020 18:12, Viktor Dukhovni wrote: >>> > > > sadly the >>> > > > EVP_PKEY_METHOD for ed25519 has a NULL sign() member, instead, >>> somewhat >>> > > > ironically, it has a digestsign() method. This is presumably to >>> > > > distinguish between the pure and prehash variants. Therefore, >>> presently >>> > > > pkeyutl(1) indeed appears to not implement signing and verifying >>> with >>> > > > ed25519, this looks doable with modest effort. >>> > > >>> > > I'm fairly sure it used to have a "sign" function during the dev >>> phase - >>> > > but it was taken out. I forget the reasoning. >>> > >>> > Yes, that change was intentional, the reasoning is detailed in the >>> > discussion in: https://github.com/openssl/openssl/pull/6284 >>> >>> This did leave us with a documentation bug, the dgst(1) manpage suggests >>> using pkeyutl(1) for ed25519 and ed448, but the latter does not work. >>> >>> The dgst(1) manpage probably needs a tweak to remove the misleading >>> redirect. Or else backport the pkeyutl(1) support from 3.0, but we're >>> not supposed to add features in 1.1.1x patch releases, and there are no >>> plans for a 1.1.2. >>> >>> -- >>> Viktor. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ylavic.dev at gmail.com Sun Apr 26 09:35:14 2020 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Sun, 26 Apr 2020 11:35:14 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200425221513.GB402559@roeckx.be> References: <20200423142936.GA24450@openssl.org> <20200425221513.GB402559@roeckx.be> Message-ID: On Sun, Apr 26, 2020 at 12:15 AM Kurt Roeckx wrote: > > On Fri, Apr 24, 2020 at 01:26:05PM +0200, Yann Ylavic wrote: > > > > - DH_bits(dh) (used for logging only in httpd) > > Replaced by BN_num_bits(DH_get0_p(dh)). > > Not sure this one should be deprecated, it seems to be used in several > > places in openssl codebase still, no replacement? > > I think the replacement is using the EVP_PKEY API and then use > EVP_PKEY_bits() Sure, but if all you have is a DH object (say obtained by DH_get_2048_256() or PEM_read_bio_DHparams()), the EVP_PKEY API does not help. It seems a bit odd to me that DH_bits() or DH_security_bits() are deprecated, but not DH_get0_*() or DH_get_length() for instance. Regards, Yann. From michael at stroeder.com Sun Apr 26 16:41:28 2020 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sun, 26 Apr 2020 18:41:28 +0200 Subject: OpenSSL key agent available? Message-ID: <942f72e9-c9fd-a9a9-cbe8-ec240c30116b@stroeder.com> HI! Does anybody know an engine implementation which delegates private key operations to a running key agent listening on a Unix domain socket? Similar like ssh-agent or gpg-agent but available for applications using OpenSSL API. Ciao, Michael. From rsalz at akamai.com Sun Apr 26 19:35:47 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 26 Apr 2020 19:35:47 +0000 Subject: OpenSSL key agent available? In-Reply-To: <942f72e9-c9fd-a9a9-cbe8-ec240c30116b@stroeder.com> References: <942f72e9-c9fd-a9a9-cbe8-ec240c30116b@stroeder.com> Message-ID: It has been done. For example, we leverage the ASYNC interface to make the private-key operations remote. There was also an RT ticket that had an implementation for a version years ago. (I can't find the RT but I know it was there.) The PKCS#11 stuff might also be appropriate. From t_mitsuya1 at msn.com Sun Apr 26 22:42:45 2020 From: t_mitsuya1 at msn.com (TOSH MITSUYA) Date: Sun, 26 Apr 2020 22:42:45 +0000 Subject: 04/26/2020 openssl smime question... Message-ID: I have seen scripts that have the openssl smime option of -inform, or -outform set to DEM. The documentation for these options cite PEM, DER or SMIME as valid values. Does anyone know where I can find an explanation for DEM? Is it another type of encoding? Thank you, TM -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun Apr 26 23:19:25 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 26 Apr 2020 23:19:25 +0000 Subject: 04/26/2020 openssl smime question... In-Reply-To: References: Message-ID: * I have seen scripts that have the openssl smime option of -inform, or -outform set to DEM. That?s an error. PEM or DER. Interesting mixup. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at foocrypt.net Mon Apr 27 08:07:51 2020 From: openssl at foocrypt.net (FooCrypt) Date: Mon, 27 Apr 2020 18:07:51 +1000 Subject: Openssl s_client error ? Message-ID: <7F1C1148-B681-4C03-B016-D9DD53780759@foocrypt.net> Hi Im just testing openssl s_client against a server IP and it appears to be failing with the following. : openssl s_client -showcerts -servername ${Site} -connect ${Site}:443 -debug References: <7F1C1148-B681-4C03-B016-D9DD53780759@foocrypt.net> Message-ID: <4a753d4a-196d-d342-dbeb-7e2fd12b9692@openssl.org> On 27/04/2020 09:07, FooCrypt wrote: > Hi > > Im just testing openssl s_client against a server IP and it appears to be failing with the following. : > > openssl s_client -showcerts -servername ${Site} -connect ${Site}:443 -debug > OpenSSL 1.0.2u 20 Dec 2019 : 140337275680448:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:827: > OpenSSL 1.1.0l 10 Sep 2019 : 140642678284928:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:251: > OpenSSL 1.1.1a 20 Nov 2018 : 140267470374080:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: > OpenSSL 1.1.1b 26 Feb 2019 : 140658956276928:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: > OpenSSL 1.1.1c 28 May 2019 : 140313236694272:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: > OpenSSL 1.1.1d 10 Sep 2019 : 140526368781568:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: > OpenSSL 1.1.1e 17 Mar 2020 : 139985685132608:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: > OpenSSL 1.1.1f 31 Mar 2020 : 139973563405632:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: > OpenSSL 1.1.1g 21 Apr 2020 : 139893511771456:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: > OpenSSL 1.1.1 11 Sep 2018 : 140632691274944:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: > > > Is this a server side issue / firewall / load balancer / issue ??? Looks like the server is not responding with something that looks like SSL/TLS. A wireshark trace might tell you more. Matt From uri at ll.mit.edu Mon Apr 27 16:29:12 2020 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 27 Apr 2020 16:29:12 +0000 Subject: CONF_MODULE undefined? Message-ID: I hit this problem recompiling libp11 with the current OpenSSL-3.0 master. It's on MacOS Catalina 10.15.4 with the latest Xcode-11.4.1, but I think that's irrelevant. I checked through all the .h files in the OpenSSL sources, and found no definition o CONF_MODULE. OpenSSL-3.0 is installed into /Users/ur20980/openssl-3 (as is obvious from the following). Here are the errors: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -g -I/Users/ur20980/openssl-3/include -Os -Ofast -std=gnu17 -march=native -msha -mavx512f -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MT evp-sign.o -MD -MP -MF $depbase.Tpo -c -o evp-sign.o evp-sign.c &&\ mv -f $depbase.Tpo $depbase.Po In file included from evp-sign.c:40: /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) ^ /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:39:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' return (t2 *)OPENSSL_sk_value((const OPENSSL_STACK *)sk, idx); \ ^ In file included from evp-sign.c:40: /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) ^ /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:67:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' return (t2 *)OPENSSL_sk_delete((OPENSSL_STACK *)sk, i); \ ^ In file included from evp-sign.c:40: /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) ^ /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:71:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' return (t2 *)OPENSSL_sk_delete_ptr((OPENSSL_STACK *)sk, \ ^ In file included from evp-sign.c:40: /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) ^ /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) ^ /Users/ur20980/openssl-3/include/openssl/safestack.h:84:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' return (t2 *)OPENSSL_sk_pop((OPENSSL_STACK *)sk); \ ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] -- Regards, Uri From caieij at firemail.de Mon Apr 27 16:58:07 2020 From: caieij at firemail.de (test test) Date: Mon, 27 Apr 2020 18:58:07 +0200 Subject: yy Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: a Type: application/octet-stream Size: 46 bytes Desc: not available URL: From tomiii at tomiii.com Mon Apr 27 19:51:10 2020 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Mon, 27 Apr 2020 12:51:10 -0700 Subject: EVP Signing and Verifying Message-ID: The first signing example at https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying explicitly calls both EVP_DigestInit_ex() and EVP_DigestSignInit(). Is the former really necessary? It appears that the implementation of EVP_DigestSignInit() in all versions of OpenSSL internally invokes EVP_DigestInit_ex() so I'm confused by this example. Did I miss something? Thanks, Tom.III -------------- next part -------------- An HTML attachment was scrubbed... URL: From norm.green at gemtalksystems.com Mon Apr 27 21:14:12 2020 From: norm.green at gemtalksystems.com (Norm Green) Date: Mon, 27 Apr 2020 14:14:12 -0700 Subject: OpenSSL v3 alpha 1: include file problem Message-ID: <9764b313-3e74-a5ae-30f8-ba075a00d9b8@gemtalksystems.com> I don't know if this change was intentional or not. With 3.0 alpha, compiling this simple program on Linux fails but succeeds on 1.1: ----------------- #include ---------------- gcc -c -I \ /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include test.c In file included from /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/types.h:20:0, ???????????????? from /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/err.h:26, ???????????????? from test.c:1: /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/ssl.h:235:28: error: 'SRTP_PROTECTION_PROFILE' does not name a type ?DEFINE_OR_DECLARE_STACK_OF(SRTP_PROTECTION_PROFILE) ??????????????????????????? ^ /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/safestack.h:30:45: note: in definition of macro 'SKM_DEFINE_STACK_OF' ???? typedef int (*sk_##t1##_compfunc)(const t3 * const *a, const t3 *const *b); \ ... To fix it, all we need is to include err.h first, as follows: ----------------- #include #include ---------------- I scanned the wiki and readme and did not see a requirement to include err.h before ssl.h.? Is this intentional or a bug? It's easy enough for me to fix this in my source code, but other packages that rely upon openssl break with "ssl.h is unusable" errors due of this change (OpenLDAP is one such example). Norm Green From vieuxtech at gmail.com Mon Apr 27 21:35:32 2020 From: vieuxtech at gmail.com (Sam Roberts) Date: Mon, 27 Apr 2020 14:35:32 -0700 Subject: website changelog didn't get updated for 1.1.1 f and g Message-ID: https://www.openssl.org/news/changelog.html#openssl-111 ^--- missing the last two patch releases. Cheers, Sam From kainthjaskamal at gmail.com Tue Apr 28 05:38:01 2020 From: kainthjaskamal at gmail.com (Jaskamal Kainth) Date: Tue, 28 Apr 2020 11:08:01 +0530 Subject: FFT algorithm for BIGNUM multiplication Message-ID: Hi all, Can someone help me with my query for the additional feature request? https://github.com/openssl/openssl/issues/11658 Also, I want to know why we haven't implemented and integrated FFT for bignum multiplication till now? Thanks and regards, Jaskamal Kainth Software Engineer Samsung R&D Bangalore [image: phone-icon] +917017684388 [image: email-icon] kainthjaskamal at gmail.com [image: website-icon] jaskamalkainth.github.io/ [image: facebook icon] [image: linkedin icon] [image: twitter icon] [image: instagram icon] -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Apr 28 07:40:52 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 28 Apr 2020 09:40:52 +0200 Subject: OpenSSL v3 alpha 1: include file problem In-Reply-To: <9764b313-3e74-a5ae-30f8-ba075a00d9b8@gemtalksystems.com> References: <9764b313-3e74-a5ae-30f8-ba075a00d9b8@gemtalksystems.com> Message-ID: <87tv14qcqj.wl-levitte@openssl.org> I hope this is fixed by https://github.com/openssl/openssl/pull/11655 On Mon, 27 Apr 2020 23:14:12 +0200, Norm Green wrote: > > I don't know if this change was intentional or not. > With 3.0 alpha, compiling this simple program on Linux fails but > succeeds on 1.1: > > ----------------- > #include > ---------------- > > gcc -c -I \ > /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include test.c > > > In file included from > /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/types.h:20:0, > ???????????????? from > /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/err.h:26, > ???????????????? from test.c:1: > /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/ssl.h:235:28: > error: 'SRTP_PROTECTION_PROFILE' does not name a type > ?DEFINE_OR_DECLARE_STACK_OF(SRTP_PROTECTION_PROFILE) > ??????????????????????????? ^ > /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/safestack.h:30:45: > note: in definition of macro 'SKM_DEFINE_STACK_OF' > ???? typedef int (*sk_##t1##_compfunc)(const t3 * const *a, const t3 > *const *b); \ > ... > > > > To fix it, all we need is to include err.h first, as follows: > > ----------------- > #include > #include > ---------------- > > I scanned the wiki and readme and did not see a requirement to include > err.h before ssl.h.? Is this intentional or a bug? > > It's easy enough for me to fix this in my source code, but other > packages that rely upon openssl break with "ssl.h is unusable" errors > due of this change (OpenLDAP is one such example). > > Norm Green > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Apr 28 08:35:05 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 28 Apr 2020 10:35:05 +0200 Subject: CONF_MODULE undefined? In-Reply-To: References: Message-ID: <87sggoqa86.wl-levitte@openssl.org> Would you mind testing if https://github.com/openssl/openssl/pull/11655 fixes this? Cheers, Richard On Mon, 27 Apr 2020 18:29:12 +0200, Blumenthal, Uri - 0553 - MITLL wrote: > > I hit this problem recompiling libp11 with the current OpenSSL-3.0 master. It's on MacOS Catalina 10.15.4 with the latest Xcode-11.4.1, but I think that's irrelevant. I checked through all the .h files in the OpenSSL sources, and found no definition o CONF_MODULE. OpenSSL-3.0 is installed into /Users/ur20980/openssl-3 (as is obvious from the following). > > Here are the errors: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -g -I/Users/ur20980/openssl-3/include -Os -Ofast -std=gnu17 -march=native -msha -mavx512f -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MT evp-sign.o -MD -MP -MF $depbase.Tpo -c -o evp-sign.o evp-sign.c &&\ > mv -f $depbase.Tpo $depbase.Po > In file included from evp-sign.c:40: > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:39:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > return (t2 *)OPENSSL_sk_value((const OPENSSL_STACK *)sk, idx); \ > ^ > In file included from evp-sign.c:40: > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:67:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > return (t2 *)OPENSSL_sk_delete((OPENSSL_STACK *)sk, i); \ > ^ > In file included from evp-sign.c:40: > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:71:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > return (t2 *)OPENSSL_sk_delete_ptr((OPENSSL_STACK *)sk, \ > ^ > In file included from evp-sign.c:40: > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:84:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > return (t2 *)OPENSSL_sk_pop((OPENSSL_STACK *)sk); \ > ^ > fatal error: too many errors emitted, stopping now [-ferror-limit=] > > -- > Regards, > Uri > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue Apr 28 10:10:36 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 28 Apr 2020 11:10:36 +0100 Subject: EVP Signing and Verifying In-Reply-To: References: Message-ID: On 27/04/2020 20:51, Thomas Dwyer III wrote: > The first signing example at > https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying explicitly > calls both EVP_DigestInit_ex() and EVP_DigestSignInit(). Is the former > really necessary? It appears that the implementation of > EVP_DigestSignInit() in all versions of OpenSSL internally invokes > EVP_DigestInit_ex() so I'm confused by this example. Did I miss something? No - it's not necessary. In fact both of those HMAC examples looked a bit more complicated to me than they needed to be for the purposes of an example. So I've updated the page to try and simplify things a bit and removed the double init. Matt From tincanteksup at gmail.com Tue Apr 28 13:01:46 2020 From: tincanteksup at gmail.com (tincanteksup) Date: Tue, 28 Apr 2020 14:01:46 +0100 Subject: [openssl-users] 'openssl ca -serial' command line always exit with error 1 ? Message-ID: Greetings openssl users, I'm a long time lurker.. I am trying to use 'openssl ca' command to verify the status of a certificate by serial number only. I can successfully complete this task, however, the 'openssl ca' command always returns an error on completion. I must point out, in advance, that I am using EasyRSA and EasyTLS to build my PKI and I am using OpenSSL command line to get the serial number status. So, apologies in advance if this is an off-topic or spammy question. Also, I am not asking for help with either EasyRSA or EasyTLS, I only want to ascertain if my observation regarding openssl "always returns error 1" is correct. Unfortunately, my C skills are too basic to be able to verify this from openssl source code, which is why I must ask here. Thank you in advance for all of your time and any feedback. Anyway, "in for a penny .." and so I shall continue .. For reference: uname -a: Linux arch-hyv-live-64 5.6.4-arch1-1 #1 SMP PREEMPT Mon, 13 Apr 2020 12:21:19 +0000 x86_64 GNU/Linux OpenSSL: OpenSSL 1.1.1f 31 Mar 2020 EasyRSA: https://github.com/OpenVPN/easy-rsa/releases/tag/v3.0.7 EasyTLS: https://github.com/TinCanTech/easy-tls The steps to reproduce this problem could not be simpler: [tct at arch-hyv-live-64 ~]$ mkdir easytls [tct at arch-hyv-live-64 ~]$ cd easytls/ [tct at arch-hyv-live-64 easytls]$ git clone https://github.com/TinCanTech/easy-tls.git master [tct at arch-hyv-live-64 easytls]$ cd master/ [tct at arch-hyv-live-64 master]$ ./op_test.sh If you choose to run op_test.sh it will: 1. download 'easyrsa' script only (the complete repo is not required). 2. download 'openssl-easyrsa.cnf' (the specific EasyRSA config file to use openssl). 3. download a pre-built version of openvpn-git/master which is required to build tls-crypt-v2 keys and therefore allow the script to complete. 4. build a complete EasyRSA PKI with valid and revoked certificates. 5. build an EasyTLS "PKI" (not a real PKI but I don't have a better name) Steps 1-5 only take a few seconds to complete. Next: [tct at arch-hyv-live-64 master]$ cd pki [tct at arch-hyv-live-64 pki]$ openssl ca -verbose -config safessl-easyrsa.cnf -keyfile private/ca.key -cert ca.crt This will essentially list out index.txt [tct at arch-hyv-live-64 pki]$ echo $? Note exit status Then use a valid and then revoked serial no. from the index.txt above and run: [tct at arch-hyv-live-64 pki]$ openssl ca -verbose -config safessl-easyrsa.cnf -keyfile private/ca.key -cert ca.crt -status $serial_number [tct at arch-hyv-live-64 pki]$ echo $? Note exit status Repeat this last step with another serial number. Again, my apologies if this email appears to be overly spammy but this was the most effective way for me to explain my issue with sufficient details. I am prepared to learn, in advance, that either: * this is not an openssl error and exit code 1 is expected or * if I built the PKI myself then openssl would not return an error but, at this time, this appears to me to be a problem with openssl. Thank you for reading and I welcome any/all feedback. -- Richard Bonhomme. (Independent) From Michael.Wojcik at microfocus.com Tue Apr 28 13:53:27 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 28 Apr 2020 13:53:27 +0000 Subject: FFT algorithm for BIGNUM multiplication In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jaskamal Kainth > Sent: Monday, April 27, 2020 23:38 > Can someone help me with my query for the additional feature request? > https://github.com/openssl/openssl/issues/11658 Help you how? This is the openssl-users list. What you're asking about isn't a feature of OpenSSL, so none of the OpenSSL users use it. You opened that issue *yesterday*, and it's already been responded to. What more do you want? > Also, I want to know why we haven't implemented and integrated FFT for bignum multiplication "We" who? I know why *I* haven't implemented it: because I have no need for it, because there's no justification for implementing it in this context (see bbbrumley's response to your issue), and because it's not my area. Presumably you know why *you* haven't implemented it. I assume no one else has implemented it (in OpenSSL) because no one else sees any reason to do so. > till now? "til now". "til" is a contraction of "until". "till" means to break the surface of the soil, to prepare a field for planting. (Also, "til now" is uncommon usage in many English dialects, where "already" is generally preferred; but English is so crowded with dialectisms that's not really worth worrying about unless you're trying to avoid them.) -- Michael Wojcik Distinguished Engineer, Micro Focus From doctor at doctor.nl2k.ab.ca Tue Apr 28 14:10:40 2020 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 28 Apr 2020 08:10:40 -0600 Subject: CONF_MODULE undefined? In-Reply-To: <87sggoqa86.wl-levitte@openssl.org> References: <87sggoqa86.wl-levitte@openssl.org> Message-ID: <20200428141040.GA85148@doctor.nl2k.ab.ca> On Tue, Apr 28, 2020 at 10:35:05AM +0200, Richard Levitte wrote: > Would you mind testing if https://github.com/openssl/openssl/pull/11655 > fixes this? > > Cheers, > Richard > > On Mon, 27 Apr 2020 18:29:12 +0200, > Blumenthal, Uri - 0553 - MITLL wrote: > > > > I hit this problem recompiling libp11 with the current OpenSSL-3.0 master. It's on MacOS Catalina 10.15.4 with the latest Xcode-11.4.1, but I think that's irrelevant. I checked through all the .h files in the OpenSSL sources, and found no definition o CONF_MODULE. OpenSSL-3.0 is installed into /Users/ur20980/openssl-3 (as is obvious from the following). > > > > Here are the errors: > > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -g -I/Users/ur20980/openssl-3/include -Os -Ofast -std=gnu17 -march=native -msha -mavx512f -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MT evp-sign.o -MD -MP -MF $depbase.Tpo -c -o evp-sign.o evp-sign.c &&\ > > mv -f $depbase.Tpo $depbase.Po > > In file included from evp-sign.c:40: > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > > ^ > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:39:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > > return (t2 *)OPENSSL_sk_value((const OPENSSL_STACK *)sk, idx); \ > > ^ > > In file included from evp-sign.c:40: > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' > > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > > ^ > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:67:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > > return (t2 *)OPENSSL_sk_delete((OPENSSL_STACK *)sk, i); \ > > ^ > > In file included from evp-sign.c:40: > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' > > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > > ^ > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:71:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > > return (t2 *)OPENSSL_sk_delete_ptr((OPENSSL_STACK *)sk, \ > > ^ > > In file included from evp-sign.c:40: > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' > > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > > ^ > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > > ^ > > /Users/ur20980/openssl-3/include/openssl/safestack.h:84:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > > return (t2 *)OPENSSL_sk_pop((OPENSSL_STACK *)sk); \ > > ^ > > fatal error: too many errors emitted, stopping now [-ferror-limit=] > > > > -- > > Regards, > > Uri > > GOt that too when I tried to compile pkg on FreeBSD-12.1 > > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Small opportunities are often the beginning of great enterprises. -Demosthenes From Michael.Wojcik at microfocus.com Tue Apr 28 14:21:50 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 28 Apr 2020 14:21:50 +0000 Subject: [openssl-users] 'openssl ca -serial' command line always exit with error 1 ? In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > tincanteksup > Sent: Tuesday, April 28, 2020 07:02 > [tct at arch-hyv-live-64 pki]$ openssl ca -verbose -config safessl-easyrsa.cnf > -keyfile private/ca.key -cert ca.crt -status $serial_number > > [tct at arch-hyv-live-64 pki]$ echo $? > > Note exit status Yes, with a pure OpenSSL-based test CA I get an exit code of 1 for this command too. That was with OpenSSL 1.1.1 (which I apparently still have installed on this machine as my default dev openssl utility version, even though we're using 1.1.1g in the actual products). My guess is this hasn't changed with 1.1.1g, though, since I don't remember seeing anything in the change log about it. I don't have time to debug it at the moment, though. The openssl utility appears to exit with exit code 1 in a lot of situations. And it doesn't use the standard C exit code macros (EXIT_SUCCESS and EXIT_FAILURE). The exit codes for the utility seem to be a holdover from the days when OpenSSL was very idiosyncratic, instead of merely quite idiosyncratic as it is now. -- Michael Wojcik Distinguished Engineer, Micro Focus From uri at ll.mit.edu Tue Apr 28 15:20:31 2020 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 28 Apr 2020 15:20:31 +0000 Subject: CONF_MODULE undefined? In-Reply-To: <87sggoqa86.wl-levitte@openssl.org> References: <87sggoqa86.wl-levitte@openssl.org> Message-ID: <004D692D-FA78-4C9E-A622-4794AD7C6D4A@ll.mit.edu> On 4/28/20, 04:38, "Richard Levitte" wrote: > Would you mind testing Not at all! ;-) > if https://github.com/openssl/openssl/pull/11655 fixes this? As you suspected - it does! ;-) Thank you! On Mon, 27 Apr 2020 18:29:12 +0200, Blumenthal, Uri - 0553 - MITLL wrote: > > I hit this problem recompiling libp11 with the current OpenSSL-3.0 master. It's on MacOS Catalina 10.15.4 with the latest Xcode-11.4.1, but I think that's irrelevant. I checked through all the .h files in the OpenSSL sources, and found no definition o CONF_MODULE. OpenSSL-3.0 is installed into /Users/ur20980/openssl-3 (as is obvious from the following). > > Here are the errors: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -g -I/Users/ur20980/openssl-3/include -Os -Ofast -std=gnu17 -march=native -msha -mavx512f -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MT evp-sign.o -MD -MP -MF $depbase.Tpo -c -o evp-sign.o evp-sign.c &&\ > mv -f $depbase.Tpo $depbase.Po > In file included from evp-sign.c:40: > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:39:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > return (t2 *)OPENSSL_sk_value((const OPENSSL_STACK *)sk, idx); \ > ^ > In file included from evp-sign.c:40: > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:67:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > return (t2 *)OPENSSL_sk_delete((OPENSSL_STACK *)sk, i); \ > ^ > In file included from evp-sign.c:40: > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:71:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > return (t2 *)OPENSSL_sk_delete_ptr((OPENSSL_STACK *)sk, \ > ^ > In file included from evp-sign.c:40: > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of undeclared identifier 'CONF_MODULE' > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type name 'CONF_MODULE' > /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected expression > DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded from macro 'DEFINE_OR_DECLARE_STACK_OF' > # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded from macro 'DEFINE_STACK_OF' > # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) > ^ > /Users/ur20980/openssl-3/include/openssl/safestack.h:84:21: note: expanded from macro 'SKM_DEFINE_STACK_OF' > return (t2 *)OPENSSL_sk_pop((OPENSSL_STACK *)sk); \ > ^ > fatal error: too many errors emitted, stopping now [-ferror-limit=] > > -- > Regards, > Uri > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From tincanteksup at gmail.com Tue Apr 28 16:26:36 2020 From: tincanteksup at gmail.com (tincanteksup) Date: Tue, 28 Apr 2020 17:26:36 +0100 Subject: [openssl-users] 'openssl ca -serial' command line always exit with error 1 ? In-Reply-To: References: Message-ID: <68511ce1-c54c-8cd9-0740-cb572b0403da@gmail.com> Hi Michael, On 28/04/2020 15:21, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of >> tincanteksup >> Sent: Tuesday, April 28, 2020 07:02 > > >> [tct at arch-hyv-live-64 pki]$ openssl ca -verbose -config safessl-easyrsa.cnf >> -keyfile private/ca.key -cert ca.crt -status $serial_number >> >> [tct at arch-hyv-live-64 pki]$ echo $? >> >> Note exit status > > Yes, with a pure OpenSSL-based test CA I get an exit code of 1 for this command too. Thank you very much for testing this and confirming my suspicions .. I can now at least move forward with my project. > That was with OpenSSL 1.1.1 (which I apparently still have installed on this machine as my default dev openssl utility version, even though we're using 1.1.1g in the actual products). My guess is this hasn't changed with 1.1.1g, though, since I don't remember seeing anything in the change log about it. > > I don't have time to debug it at the moment, though. > > The openssl utility appears to exit with exit code 1 in a lot of situations. And it doesn't use the standard C exit code macros (EXIT_SUCCESS and EXIT_FAILURE). The exit codes for the utility seem to be a holdover from the days when OpenSSL was very idiosyncratic, instead of merely quite idiosyncratic as it is now. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > From kgoldman at us.ibm.com Thu Apr 30 21:12:52 2020 From: kgoldman at us.ibm.com (Ken Goldman) Date: Thu, 30 Apr 2020 17:12:52 -0400 Subject: OpenSSL version 3.0.0-alpha1 build failed In-Reply-To: <20200423142936.GA24450@openssl.org> References: <20200423142936.GA24450@openssl.org> Message-ID: My build failed with the below. x86_64 Linux kernel 2.6.32 RHEL 6.7 Perl 5.10.1 Everything through 1.1.1e was successful. ~~ ./config Operating system: x86_64-whatever-linux2 Configuring OpenSSL version 3.0.0-alpha1 for target linux-x86_64 Using os-specific seed configuration *** glibc detected *** /usr/bin/perl: double free or corruption (out): 0x0000000002a401e0 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3c2fa75dee] /lib64/libc.so.6[0x3c2fa78c80] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x6a5)[0x3c35ab93c5] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] /usr/lib64/perl5/CORE/libperl.so(Perl_av_undef+0x58)[0x3c35aa4018] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x598)[0x3c35ab92b8] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x47c)[0x3c35ab919c] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] /usr/lib64/perl5/CORE/libperl.so(Perl_hv_free_ent+0x42)[0x3c35a9e8c2] /usr/lib64/perl5/CORE/libperl.so[0x3c35a9fde1] /usr/lib64/perl5/CORE/libperl.so(Perl_hv_clear+0xfa)[0x3c35a9ffea] /usr/lib64/perl5/CORE/libperl.so(Perl_leave_scope+0xea8)[0x3c35ad6258] /usr/lib64/perl5/CORE/libperl.so(Perl_pp_unstack+0x59)[0x3c35aa8419] /usr/lib64/perl5/CORE/libperl.so(Perl_runops_standard+0x16)[0x3c35aa4b06] /usr/lib64/perl5/CORE/libperl.so(perl_run+0x338)[0x3c35a4d0d8] /usr/bin/perl(main+0x154)[0x400e74] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3c2fa1ed1d] [snipped] From matt at openssl.org Thu Apr 30 21:44:09 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 30 Apr 2020 22:44:09 +0100 Subject: OpenSSL version 3.0.0-alpha1 build failed In-Reply-To: References: <20200423142936.GA24450@openssl.org> Message-ID: <629958f6-2cab-3899-6139-47f725b471f8@openssl.org> This appears to be a bug in perl. You have a very old version of perl (the oldest we support is 5.10.0). It's probably worth trying to upgrade it. Matt On 30/04/2020 22:12, Ken Goldman wrote: > My build failed with the below. > > x86_64 Linux kernel 2.6.32 > RHEL 6.7 > Perl 5.10.1 > > Everything through 1.1.1e was successful. > > ~~ > > > ./config > Operating system: x86_64-whatever-linux2 > Configuring OpenSSL version 3.0.0-alpha1 for target linux-x86_64 > Using os-specific seed configuration > *** glibc detected *** /usr/bin/perl: double free or corruption (out): > 0x0000000002a401e0 *** > ======= Backtrace: ========= > /lib64/libc.so.6[0x3c2fa75dee] > /lib64/libc.so.6[0x3c2fa78c80] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x6a5)[0x3c35ab93c5] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > /usr/lib64/perl5/CORE/libperl.so(Perl_av_undef+0x58)[0x3c35aa4018] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x598)[0x3c35ab92b8] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x47c)[0x3c35ab919c] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > /usr/lib64/perl5/CORE/libperl.so(Perl_hv_free_ent+0x42)[0x3c35a9e8c2] > /usr/lib64/perl5/CORE/libperl.so[0x3c35a9fde1] > /usr/lib64/perl5/CORE/libperl.so(Perl_hv_clear+0xfa)[0x3c35a9ffea] > /usr/lib64/perl5/CORE/libperl.so(Perl_leave_scope+0xea8)[0x3c35ad6258] > /usr/lib64/perl5/CORE/libperl.so(Perl_pp_unstack+0x59)[0x3c35aa8419] > /usr/lib64/perl5/CORE/libperl.so(Perl_runops_standard+0x16)[0x3c35aa4b06] > /usr/lib64/perl5/CORE/libperl.so(perl_run+0x338)[0x3c35a4d0d8] > /usr/bin/perl(main+0x154)[0x400e74] > /lib64/libc.so.6(__libc_start_main+0xfd)[0x3c2fa1ed1d] > [snipped] > From tomiii at tomiii.com Thu Apr 30 22:06:30 2020 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Thu, 30 Apr 2020 15:06:30 -0700 Subject: OpenSSL version 3.0.0-alpha1 build failed In-Reply-To: <629958f6-2cab-3899-6139-47f725b471f8@openssl.org> References: <20200423142936.GA24450@openssl.org> <629958f6-2cab-3899-6139-47f725b471f8@openssl.org> Message-ID: For what it's worth, I also get similar perl crashes from the Configure script. All of my build servers (which I do not control) have perl 5.10.1 installed on Oracle Linux 6.5. I tested with 5.12.5 and that also crashed in the same way. 5.14.4 is the oldest version (stable branch) I could find that worked. Tom.III On Thu, Apr 30, 2020 at 2:44 PM Matt Caswell wrote: > This appears to be a bug in perl. You have a very old version of perl > (the oldest we support is 5.10.0). It's probably worth trying to upgrade > it. > > Matt > > > On 30/04/2020 22:12, Ken Goldman wrote: > > My build failed with the below. > > > > x86_64 Linux kernel 2.6.32 > > RHEL 6.7 > > Perl 5.10.1 > > > > Everything through 1.1.1e was successful. > > > > ~~ > > > > > > ./config > > Operating system: x86_64-whatever-linux2 > > Configuring OpenSSL version 3.0.0-alpha1 for target linux-x86_64 > > Using os-specific seed configuration > > *** glibc detected *** /usr/bin/perl: double free or corruption (out): > > 0x0000000002a401e0 *** > > ======= Backtrace: ========= > > /lib64/libc.so.6[0x3c2fa75dee] > > /lib64/libc.so.6[0x3c2fa78c80] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x6a5)[0x3c35ab93c5] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > > /usr/lib64/perl5/CORE/libperl.so(Perl_av_undef+0x58)[0x3c35aa4018] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x598)[0x3c35ab92b8] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x47c)[0x3c35ab919c] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > > /usr/lib64/perl5/CORE/libperl.so(Perl_hv_free_ent+0x42)[0x3c35a9e8c2] > > /usr/lib64/perl5/CORE/libperl.so[0x3c35a9fde1] > > /usr/lib64/perl5/CORE/libperl.so(Perl_hv_clear+0xfa)[0x3c35a9ffea] > > /usr/lib64/perl5/CORE/libperl.so(Perl_leave_scope+0xea8)[0x3c35ad6258] > > /usr/lib64/perl5/CORE/libperl.so(Perl_pp_unstack+0x59)[0x3c35aa8419] > > /usr/lib64/perl5/CORE/libperl.so(Perl_runops_standard+0x16)[0x3c35aa4b06] > > /usr/lib64/perl5/CORE/libperl.so(perl_run+0x338)[0x3c35a4d0d8] > > /usr/bin/perl(main+0x154)[0x400e74] > > /lib64/libc.so.6(__libc_start_main+0xfd)[0x3c2fa1ed1d] > > [snipped] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vieuxtech at gmail.com Thu Apr 30 23:22:34 2020 From: vieuxtech at gmail.com (Sam Roberts) Date: Thu, 30 Apr 2020 16:22:34 -0700 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> <5ebc99d8-2260-c5a6-ef76-eb91fd5c10d0@openssl.org> Message-ID: On Fri, Apr 24, 2020 at 9:07 AM Nicola Tuveri wrote: > At https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers there was already an example of how to do this programmatically, and a link to the manpage for the config file syntax. That's not working for me: Failed to load Legacy provider: error:25000067:DSO support routines::could not load the shared library /home/sam/w/core/tls/./node[26693]: ../../src/node_crypto.cc:6804:void node::crypto::InitCryptoOnce(): Assertion `"Unreachable code reached"' failed. 1: 0x557630598d84 node::Abort() [/home/sam/w/core/tls/./node] From: /* Load Multiple providers into the default (NULL) library context */ auto legacy = OSSL_PROVIDER_load(0, "legacy"); if (legacy == nullptr) { unsigned long err = ERR_get_error(); fprintf(stderr, "Failed to load Legacy provider: %s\n", ERR_error_string(err, nullptr)); UNREACHABLE(); } auto deflt = OSSL_PROVIDER_load(0, "default"); if (deflt == nullptr) { unsigned long err = ERR_get_error(); fprintf(stderr, "Failed to load Default provider: %s\n", ERR_error_string(err, nullptr)); OSSL_PROVIDER_unload(legacy); UNREACHABLE(); } I notice that the legacy.so isn't in the same folder as the other .so files, so I tried: LD_LIBRARY_PATH=/usr/local/stow/openssl-3.0.0-alpha1/lib:/usr/local/stow/openssl-3.0.0-alpha1/lib/ossl-modules But that didn't work. It looks like adding this did work: OSSL_PROVIDER_set_default_search_path(0, "/usr/local/stow/openssl-3.0.0-alpha1/lib/ossl-modules"); What are the default values? I built with prefix set to /usr/local, but then installed to the DESTDIR directory above, is that what caused me trouble? Cheers, Sam > I just added also a minimal config file example to load both the default and the legacy provider in the default library context. > > > Cheers, > > Nicola > > On Fri, 24 Apr 2020 at 17:56, Sam Roberts wrote: >> >> On Fri, Apr 24, 2020 at 1:05 AM Matt Caswell wrote: >> > This one is interesting: >> > >> > ERR_OSSL_EVP_FETCH_FAILED >> > >> > >> > This means that the algorithm you are trying to use isn't available in >> > the loaded providers. Since you should be getting the default provider >> > loaded automatically it could be because some legacy algorithms were >> > moved to the legacy provider (MD2, MD4, MDC2, RMD160, CAST5, BF >> > (Blowfish), IDEA, SEED, RC2, RC4, RC5 and DES (but not 3DES)). If you're >> > using something from that list then that would explain it. >> >> Can we add the legacy provider, via configuration, or via code?