From wallboy at wallboy.ca Sun Oct 1 13:48:44 2017 From: wallboy at wallboy.ca (Wallboy) Date: Sun, 1 Oct 2017 06:48:44 -0700 (MST) Subject: [openssl-users] Integrating New Cipher Suite In-Reply-To: References: Message-ID: <1506865724113-0.post@n7.nabble.com> Hi, I'm also interested in adding a few "pseudo" ciphersuites to OpenSSL. Notably the 16 GREASE ones Chrome currently uses (0x0A0A, 0x1A1A...0xFAFA). I made similar changes to the files listed in this thread and compiled successfully (based on 1.1.0f). I see the new cipher when doing "openssl ciphers ALL:eNULL". However I had the same issue that when trying to include it using s_client, the ClientHello message did not actually send it: openssl s_client -cipher "ECDHE-RSA-AES256-SHA:GREASE-0A0A" -connect www.google.com:443 -servername www.google.com ClientHello contained two ciphersuites. The first one listed and also the SCSV cipher I then tried this: openssl s_client -cipher "ECDHE-RSA-AES256-SHA:GREASE-0A0A:@SECLEVEL=0" -connect www.google.com:443 -servername www.google.com Bingo! But the ClientHello now sends 4 Ciphersuites. The first one listed, followed by my GREASE pseudo cipher, then TLS_RSA_WITH_RC4_128_MD5, then the SCSV cipher. I'm not sure why that RC4 cipher is sent. Although it probably has to do with the fact I structured that GREASE cipher after it: { 1, SSL3_TXT_GREASE1, SSL3_CK_GREASE1, SSL_kRSA, SSL_aRSA, SSL_RC4, SSL_MD5, SSL3_VERSION, TLS1_2_VERSION, 0, 0, SSL_NOT_DEFAULT | SSL_MEDIUM, SSL_HANDSHAKE_MAC_DEFAULT | TLS1_PRF, 128, 128, }, If I'm just trying to use it as a pseudo cipher for ClientHello messages, how should it look in the above struct? And how can I get it to send without specifying SECLEVEL=0? Bonus Question: Is it possible to remove the SCSV cipher in the ClientHello? Thanks for any help -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From steve at openssl.org Sun Oct 1 22:47:42 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Sun, 1 Oct 2017 22:47:42 +0000 Subject: [openssl-users] Integrating New Cipher Suite In-Reply-To: <1506865724113-0.post@n7.nabble.com> References: <1506865724113-0.post@n7.nabble.com> Message-ID: <20171001224742.GA10791@openssl.org> On Sun, Oct 01, 2017, Wallboy wrote: > Hi, > > I'm also interested in adding a few "pseudo" ciphersuites to OpenSSL. > Notably the 16 GREASE ones Chrome currently uses (0x0A0A, 0x1A1A...0xFAFA). > > I made similar changes to the files listed in this thread and compiled > successfully (based on 1.1.0f). I see the new cipher when doing "openssl > ciphers ALL:eNULL". > > However I had the same issue that when trying to include it using s_client, > the ClientHello message did not actually send it: > > openssl s_client -cipher "ECDHE-RSA-AES256-SHA:GREASE-0A0A" -connect > www.google.com:443 -servername www.google.com > > ClientHello contained two ciphersuites. The first one listed and also the > SCSV cipher > > I then tried this: > > openssl s_client -cipher "ECDHE-RSA-AES256-SHA:GREASE-0A0A:@SECLEVEL=0" > -connect www.google.com:443 -servername www.google.com > > Bingo! But the ClientHello now sends 4 Ciphersuites. The first one listed, > followed by my GREASE pseudo cipher, then TLS_RSA_WITH_RC4_128_MD5, then the > SCSV cipher. > > I'm not sure why that RC4 cipher is sent. Although it probably has to do > with the fact I structured that GREASE cipher after it: > > { > 1, > SSL3_TXT_GREASE1, > SSL3_CK_GREASE1, > SSL_kRSA, > SSL_aRSA, > SSL_RC4, > SSL_MD5, > SSL3_VERSION, TLS1_2_VERSION, > 0, 0, > SSL_NOT_DEFAULT | SSL_MEDIUM, > SSL_HANDSHAKE_MAC_DEFAULT | TLS1_PRF, > 128, > 128, > }, > > If I'm just trying to use it as a pseudo cipher for ClientHello messages, > how should it look in the above struct? And how can I get it to send without > specifying SECLEVEL=0? > If you want to specify the ciphersuites in the cipher string then they need to be part of the list of ciphers. However these wouldn't be normal ciphersuites: they'd never be selected by a server for example. Giving them separate definitions and handling does go against the requirements of GREASE draft though. Your problems are because you copied the definitions for that RC4 ciphersuite. The fact it uses MD5 means it gets rules out at anything other than security level 0. If you just want to include them in a client hello you can do something similar to the scsv code which adds its own pseudo-ciphersuite. In particular the code in ssl_cipher_list_to_bytes(). > Bonus Question: Is it possible to remove the SCSV cipher in the ClientHello? > You can't remove it without making source changes. Again it's in the ssl_cipher_list_to_bytes() function. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Sun Oct 1 22:54:26 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Sun, 1 Oct 2017 22:54:26 +0000 Subject: [openssl-users] Missing EVP_PKEY method to set engine? In-Reply-To: <03112499-1646-4625-BC93-D90C7315DD10@ll.mit.edu> References: <03112499-1646-4625-BC93-D90C7315DD10@ll.mit.edu> Message-ID: <20171001225426.GA10923@openssl.org> On Fri, Sep 29, 2017, Blumenthal, Uri - 0553 - MITLL wrote: > Apologies in advance for cross-posting ??? but I???m not sure which of the two mailing lists this belongs to. > > A key (say, private key) is loaded from the pkcs11 engine via privkey = ENGINE_load_private_key(engine, ); and this operation succeeds. > > However the resulting key handle has its engine == NULL. I looked for a method or a macro to explicitly set that value to the pointer to the engine that this key is bound to, but couldn???t find any. I define new methods such as pkcs11_pkey_rsa_decrypt(), and ?try to make OpenSSL aware of them via: > > ????????EVP_PKEY_METHOD *orig_pmeth = EVP_PKEY_meth_find(EVP_PKEY_RSA); > > ?? EVP_PKEY_METHOD *pmeth = EVP_PKEY_meth_new(EVP_PKEY_RSA, EVP_PKEY_FLAG_AUTOARGLEN); > > ?? EVP_PKEY_meth_copy(pmeth, orig_pmeth); > > ?? EVP_PKEY_meth_get_decrypt(orig_pmeth, &pdecr_init, &pdecr); > > ?? EVP_PKEY_meth_set_decrypt(pmeth, pdecr_init, pkcs11_pkey_rsa_decrypt); > There doesn't seem to be any easy way to do that for an existing method. If the ENGINE has its own ASN.1 method things become easier. A workaround might be to use a copy of an existing A workaround might be to create a copy of an existing ASN.1 method but I've not tried that. > > In ENGINE_set_pkey_meths(engine, pkey_meths) what should pkey_meths() actually be? Is it documented? > > Not currently but it similar to the cipher/digest functions but handles EVP_PKEY_METHOD instead. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From uri at ll.mit.edu Sun Oct 1 23:59:12 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Sun, 1 Oct 2017 23:59:12 +0000 Subject: [openssl-users] Missing EVP_PKEY method to set engine? In-Reply-To: <20171001225426.GA10923@openssl.org> References: <03112499-1646-4625-BC93-D90C7315DD10@ll.mit.edu> <20171001225426.GA10923@openssl.org> Message-ID: Thank you! I observe that in 1.1.x everything's fine - the structure evp_pkey_methods_st is opaque, but both getters and setters are defined and available. In 1.0.2 the structure is already opaque, the setters are present, but some getters are absent. Which makes it quite hard to work with members of this structure. I think this is a bug, and two possible remedies INHO are: add getter functions for the members, or add/move this structure from evp-int.h to evp.h (so it's no longer opaque). What is your opinion? Thanks! Regards, Uri Sent from my iPhone > On Oct 1, 2017, at 18:54, Dr. Stephen Henson wrote: > >> On Fri, Sep 29, 2017, Blumenthal, Uri - 0553 - MITLL wrote: >> >> Apologies in advance for cross-posting ??? but I???m not sure which of the two mailing lists this belongs to. >> >> A key (say, private key) is loaded from the pkcs11 engine via privkey = ENGINE_load_private_key(engine, ); and this operation succeeds. >> >> However the resulting key handle has its engine == NULL. I looked for a method or a macro to explicitly set that value to the pointer to the engine that this key is bound to, but couldn???t find any. I define new methods such as pkcs11_pkey_rsa_decrypt(), and try to make OpenSSL aware of them via: >> >> EVP_PKEY_METHOD *orig_pmeth = EVP_PKEY_meth_find(EVP_PKEY_RSA); >> >> EVP_PKEY_METHOD *pmeth = EVP_PKEY_meth_new(EVP_PKEY_RSA, EVP_PKEY_FLAG_AUTOARGLEN); >> >> EVP_PKEY_meth_copy(pmeth, orig_pmeth); >> >> EVP_PKEY_meth_get_decrypt(orig_pmeth, &pdecr_init, &pdecr); >> >> EVP_PKEY_meth_set_decrypt(pmeth, pdecr_init, pkcs11_pkey_rsa_decrypt); >> > > There doesn't seem to be any easy way to do that for an existing method. If > the ENGINE has its own ASN.1 method things become easier. > > A workaround might be to use a copy of an existing A workaround might be to > create a copy of an existing ASN.1 method but I've not tried that. > >> >> In ENGINE_set_pkey_meths(engine, pkey_meths) what should pkey_meths() actually be? Is it documented? >> >> > > Not currently but it similar to the cipher/digest functions but handles > EVP_PKEY_METHOD instead. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5801 bytes Desc: not available URL: From jb-openssl at wisemo.com Mon Oct 2 11:52:18 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 2 Oct 2017 13:52:18 +0200 Subject: [openssl-users] Integrating New Cipher Suite In-Reply-To: <20171001224742.GA10791@openssl.org> References: <1506865724113-0.post@n7.nabble.com> <20171001224742.GA10791@openssl.org> Message-ID: <163cb110-2443-fc4b-37fe-18e1a4db6e0a@wisemo.com> On 02/10/2017 00:47, Dr. Stephen Henson wrote: > On Sun, Oct 01, 2017, Wallboy wrote: > >> Hi, >> >> ... >> Bonus Question: Is it possible to remove the SCSV cipher in the ClientHello? >> > You can't remove it without making source changes. Again it's in the > ssl_cipher_list_to_bytes() function. > Have you tried clearing SSL_MODE_SEND_FALLBACK_SCSV (in a program), or (not) using the -fallback_scsv option to s_client? 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 Jose.DiazdeGrenu at digi.com Mon Oct 2 14:29:06 2017 From: Jose.DiazdeGrenu at digi.com (Diaz de Grenu, Jose) Date: Mon, 2 Oct 2017 14:29:06 +0000 Subject: [openssl-users] FIPS Object Module 2.0, fipsalgtest.pl fails In-Reply-To: <239540b0-9fd7-181f-d102-67e551c1f6a5@openssl.com> References: <0B2EBCD48D33654381E736352034C70C01A20EC7@dor-sms-xch01.digi.com> <239540b0-9fd7-181f-d102-67e551c1f6a5@openssl.com> Message-ID: <0B2EBCD48D33654381E736352034C70C01A262ED@dor-sms-xch01.digi.com> > The FIPS module and test suite software (fipsalgtest.pl) are designed to work with exactly those algorithm tests relevant to the associated validations > (#1747/2398/2473). The test labs generate a unique set of test vectors for each platform validation; those test vectors must be of the expected format to > be successfully processed. Often they are not, either because they we incorrectly specified or due to errors. Figuring out such discrepancies can be lots of > fun (not!). > You will want to compare your test vectors with a known good set from http://openssl.com/testing/validation-2.0/testvectors/. Pick a recent set, as the format of the test vectors changes over time. Note that as > a result frequent adjustment of fipsalgtest.pl is often necessary. I have tried with all the tarballs but I am not able to find one which works without errors. Is there any way to check which test vector were used for FIPS Object Module 2.0.16? From marquess at openssl.com Mon Oct 2 15:39:11 2017 From: marquess at openssl.com (Steve Marquess) Date: Mon, 2 Oct 2017 11:39:11 -0400 Subject: [openssl-users] FIPS Object Module 2.0, fipsalgtest.pl fails In-Reply-To: <0B2EBCD48D33654381E736352034C70C01A262ED@dor-sms-xch01.digi.com> References: <0B2EBCD48D33654381E736352034C70C01A20EC7@dor-sms-xch01.digi.com> <239540b0-9fd7-181f-d102-67e551c1f6a5@openssl.com> <0B2EBCD48D33654381E736352034C70C01A262ED@dor-sms-xch01.digi.com> Message-ID: <6e093973-120c-a802-2f2b-bb611771c2cd@openssl.com> On 10/02/2017 10:29 AM, Diaz de Grenu, Jose wrote: > >> The FIPS module and test suite software (fipsalgtest.pl) are designed to work with exactly those algorithm tests relevant to the associated validations >> (#1747/2398/2473). The test labs generate a unique set of test vectors for each platform validation; those test vectors must be of the expected format to >> be successfully processed. Often they are not, either because they we incorrectly specified or due to errors. Figuring out such discrepancies can be lots of > > fun (not!). > >> You will want to compare your test vectors with a known good set from http://openssl.com/testing/validation-2.0/testvectors/. Pick a recent set, as the format of the test vectors changes over time. Note that as >> a result frequent adjustment of fipsalgtest.pl is often necessary. > > I have tried with all the tarballs but I am not able to find one which works without errors. You reprocessed all of the hundreds of test vectors? I'm impressed. That must have taken many days of compute time. > > Is there any way to check which test vector were used for FIPS Object Module 2.0.16? > The most recent set of test vectors used for a 2.0.16 OE is: http://openssl.com/testing/validation-2.0/testvectors/OVS_2859_OE82.results.tar.gz You have no way of knowing that because we don't publish a mapping of test vectors to OEs (and most FIPS 140 module vendors don't publish anything at all). And before you ask, no, while we're delighted to be an open source model for other validations I'm not keen on spending time specifically supporting proprietary validations that don't benefit the OpenSSL community as a whole. Please note that if you're trying to do your own "private label" validation you'll have to use a new unique set of test vectors provided by your accredited test lab; reprocessing a previously used set doesn't buy you much. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 301 874 2571 marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From beldmit at gmail.com Mon Oct 2 20:02:32 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 2 Oct 2017 23:02:32 +0300 Subject: [openssl-users] Engine configuration Message-ID: Hello, I have a question regarding engine configuration. We need to implement such behaviour: - on load the engine is configured with the commands from config file, but the values can be overwritten via environment - application can change the engine's configuration via ENGINE_ctrl_string functions. Is there any way to distinguish whether engine is configured via the config file or via direct calls to ENGINE_ctrl* functions? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Mon Oct 2 21:16:10 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 2 Oct 2017 21:16:10 +0000 Subject: [openssl-users] Engine configuration In-Reply-To: References: Message-ID: <20171002211610.GA28570@openssl.org> On Mon, Oct 02, 2017, Dmitry Belyavsky wrote: > Hello, > > I have a question regarding engine configuration. > > We need to implement such behaviour: > - on load the engine is configured with the commands from config file, but > the values can be overwritten via environment That part can be done with the config file syntax see config(5) > - application can change the engine's configuration via ENGINE_ctrl_string > functions. > > Is there any way to distinguish whether engine is configured via the config > file or via direct calls to ENGINE_ctrl* functions? > Not currently no: the config file calls the relevant control operations. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From stefan.g at gmx.at Tue Oct 3 06:33:46 2017 From: stefan.g at gmx.at (=?UTF-8?Q?Stefan_Gr=c3=bcnwald?=) Date: Tue, 3 Oct 2017 08:33:46 +0200 Subject: [openssl-users] AES CMAC with given iv Message-ID: Hi, I need to calculate an AES CMAC with a given iv and also get the new iv after the calculation. On the internet I found some examples how to calculate the CMAC but if I read the code correctly it always starts with a zero iv. I also found the CMAC_resume function which restores the iv but it also doesn't take the iv as an input parameter. Is there any chance to set and get the iv? The only way I would see at the moment is an ugly hack by setting the tbl field of the context struct in memory before calling CMAC_resume. Thanks, Stefan From Jose.DiazdeGrenu at digi.com Tue Oct 3 21:26:06 2017 From: Jose.DiazdeGrenu at digi.com (Diaz de Grenu, Jose) Date: Tue, 3 Oct 2017 21:26:06 +0000 Subject: [openssl-users] FIPS Object Module 2.0, fipsalgtest.pl fails In-Reply-To: <6e093973-120c-a802-2f2b-bb611771c2cd@openssl.com> References: <0B2EBCD48D33654381E736352034C70C01A20EC7@dor-sms-xch01.digi.com> <239540b0-9fd7-181f-d102-67e551c1f6a5@openssl.com> <0B2EBCD48D33654381E736352034C70C01A262ED@dor-sms-xch01.digi.com>, <6e093973-120c-a802-2f2b-bb611771c2cd@openssl.com> Message-ID: <0B2EBCD48D33654381E736352034C70C01A29838@dor-sms-xch01.digi.com> > You reprocessed all of the hundreds of test vectors? I'm impressed. That > must have taken many days of compute time. Sorry, the download script I set up seg faulted after some time, and I didn't noticed. In fact it only tested a few tarballs. > The most recent set of test vectors used for a 2.0.16 OE is: >http://openssl.com/testing/validation-2.0/testvectors/OVS_2859_OE82.results.tar.gz That one also fails. Thanks for all the information anyways. I will keep trying with other test vector, just in case. From lists at rustichelli.net Wed Oct 4 08:17:32 2017 From: lists at rustichelli.net (lists) Date: Wed, 4 Oct 2017 10:17:32 +0200 Subject: [openssl-users] Storing private key on tokens In-Reply-To: References: <58054950-D246-4374-95D0-42423A74F948@webweaving.org> Message-ID: On 09/27/2017 11:13 PM, Ken Goldman wrote: > On 9/27/2017 2:19 PM, Dirk-Willem van Gulik wrote: >> >>> On 27 Sep 2017, at 20:02, Michael Wojcik >>> >>> The tokens / HSMs I've used don't let you generate a key somewhere >>> else and install it on the token. They insist on doing the key >>> generation locally. That is, after all, part of the point of using >>> a token - the key never leaves it. >> >> I've found that the Feitian ePass2000's and the Yubico keys allow for >> importing of the private key. They do usually want the 'extra' flags >> to specify use: > > FWIW, the TPM hardware also permits key import.? It does validate > attributes, so users will know that the key was not generated on chip. > Most smart cards (G&D, Oberthur and InCard) I've dealt with allow for external generation of RSA keys and import into the token. Currently I mostly use InCard cards sold in Italy, I can't tell if the other brands are still easily purchaseable. From lists at rustichelli.net Wed Oct 4 08:28:57 2017 From: lists at rustichelli.net (lists) Date: Wed, 4 Oct 2017 10:28:57 +0200 Subject: [openssl-users] PKCS7 and RSA_verify In-Reply-To: References: <20170927230645.GA9633@openssl.org> <564601db-ad81-7e01-8812-4f829acde533@fedict.be> <20bfd0d4-78c7-97c8-59ca-83a5edd99b3b@coderhacks.com> Message-ID: <2ce463e3-047a-6810-0766-914647684fdd@rustichelli.net> On 10/01/2017 01:27 AM, Sam Roberts wrote: > On Thu, Sep 28, 2017 at 2:28 AM, ch wrote: >> Hi! >> >> I thought the difference between PEM and DER is NOT ONLY a different >> encoding of the string? >> base64 vs. binary >> >> So to understand that clear please let me ask: >> If I convert a PEM-signature from base64 to binary then it is DER? > Yes. Well, technically it could be BER as well, but the main point is > PEM is just a wrapper to transport binary via email safe text, and you > can unwrap it if you want. PEM also includes a header, so you know if > the object is a cert, a key, an encrypted message, etc, meta-data > which is not known if you just have the binary chunk. Indeed, PEM for S/MIME looks like -----BEGIN PKCS7----- -----END PKCS7----- so you must add the header ("-----BEGIN PKCS7-----") and the trailer >> Thanks >> Chris >> >> On 2017-09-28 11:23, Wouter Verhelst wrote: >>> On 28-09-17 01:19, ch wrote> If the pkcs-signature is binary encoded it >>> is not working for verifiying >>>> a SMIME-message in my experience with >>>> smime or cms-smime on the console. I tried to convert the binary ones to >>>> base64 but that does not everytime the trick. >>> What you call "base64" is commonly known as "PEM" :-) >>> >>> You can get it to parse binary, but to do so you need to specify >>> "-inform der". >>> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From janjust at nikhef.nl Wed Oct 4 08:44:44 2017 From: janjust at nikhef.nl (Jan Just Keijser) Date: Wed, 4 Oct 2017 10:44:44 +0200 Subject: [openssl-users] Storing private key on tokens In-Reply-To: References: <58054950-D246-4374-95D0-42423A74F948@webweaving.org> Message-ID: <90aec320-246f-2baa-cca7-afdafe8369ef@nikhef.nl> Hi, On 04/10/17 10:17, lists wrote: > On 09/27/2017 11:13 PM, Ken Goldman wrote: >> On 9/27/2017 2:19 PM, Dirk-Willem van Gulik wrote: >>> >>>> On 27 Sep 2017, at 20:02, Michael Wojcik >>>> >>>> The tokens / HSMs I've used don't let you generate a key somewhere >>>> else and install it on the token. They insist on doing the key >>>> generation locally. That is, after all, part of the point of using >>>> a token - the key never leaves it. >>> >>> I've found that the Feitian ePass2000's and the Yubico keys allow for >>> importing of the private key. They do usually want the 'extra' flags >>> to specify use: >> >> FWIW, the TPM hardware also permits key import.? It does validate attributes, so users will know that the key was not >> generated on chip. >> > > Most smart cards (G&D, Oberthur and InCard) I've dealt with allow for external generation of RSA keys and import into the token. > Currently I mostly use InCard cards sold in Italy, I can't tell if the other brands are still easily purchaseable. > > FWIW:? I've used mostly Aladdin/Safenet/Gemalto eTokens (32K, 64K, 72K) and they all support the import of RSA keys (as well as generation of keys, of course). Furthermore, if you look at the libp11 library then you will find that it does just that:? generate a key in memory and then store it on the etoken. The source code even has a comment about this: 110 /* 111? * Generate and store a private key on the token 112? * FIXME: We should check first whether the token supports 113? * on-board key generation, and if it does, use its own algorithm 114? */ 115 int 116 PKCS11_generate_key(PKCS11_TOKEN * token, 117???????????? int algorithm, unsigned int bits, char *label, unsigned char* id, size_t id_len) 118 { 119???? PKCS11_KEY *key_obj; 120???? EVP_PKEY *pk; 121???? RSA *rsa; 122???? BIO *err; 123???? int rc; 124 125???? if (algorithm != EVP_PKEY_RSA) { 126???????? PKCS11err(PKCS11_F_PKCS11_GENERATE_KEY, PKCS11_NOT_SUPPORTED); 127???????? return -1; 128???? } 129 130???? err = BIO_new_fp(stderr, BIO_NOCLOSE); 131???? rsa = RSA_generate_key(bits, 0x10001, NULL, err); 132???? BIO_free(err); 133???? if (rsa == NULL) { 134???????? PKCS11err(PKCS11_F_PKCS11_GENERATE_KEY, PKCS11_KEYGEN_FAILED); 135???????? return -1; 136???? } 137 138???? pk = EVP_PKEY_new(); 139???? EVP_PKEY_assign_RSA(pk, rsa); 140???? rc = pkcs11_store_private_key(token, pk, label, id, id_len, &key_obj); JM2CW, JJK From jb-openssl at wisemo.com Wed Oct 4 12:30:36 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 4 Oct 2017 14:30:36 +0200 Subject: [openssl-users] Storing private key on tokens In-Reply-To: <90aec320-246f-2baa-cca7-afdafe8369ef@nikhef.nl> References: <58054950-D246-4374-95D0-42423A74F948@webweaving.org> <90aec320-246f-2baa-cca7-afdafe8369ef@nikhef.nl> Message-ID: On 04/10/2017 10:44, Jan Just Keijser wrote: > Hi, > > On 04/10/17 10:17, lists wrote: >> On 09/27/2017 11:13 PM, Ken Goldman wrote: >>> On 9/27/2017 2:19 PM, Dirk-Willem van Gulik wrote: >>>> >>>>> On 27 Sep 2017, at 20:02, Michael Wojcik >>>>> >>>>> The tokens / HSMs I've used don't let you generate a key somewhere >>>>> else and install it on the token. They insist on doing the key >>>>> generation locally. That is, after all, part of the point of using >>>>> a token - the key never leaves it. >>>> >>>> I've found that the Feitian ePass2000's and the Yubico keys allow for >>>> importing of the private key. They do usually want the 'extra' flags >>>> to specify use: >>> >>> FWIW, the TPM hardware also permits key import.? It does validate >>> attributes, so users will know that the key was not generated on chip. >>> >> >> Most smart cards (G&D, Oberthur and InCard) I've dealt with allow for >> external generation of RSA keys and import into the token. >> Currently I mostly use InCard cards sold in Italy, I can't tell if >> the other brands are still easily purchaseable. >> >> > FWIW:? I've used mostly Aladdin/Safenet/Gemalto eTokens (32K, 64K, > 72K) and they all support the import of RSA keys (as well as > generation of keys, of course). > > Furthermore, if you look at the libp11 library then you will find that > it does just that:? generate a key in memory and then store it on the > etoken. The source code even has a comment about this: > > 110 /* > 111? * Generate and store a private key on the token > 112? * FIXME: We should check first whether the token supports > 113? * on-board key generation, and if it does, use its own algorithm > 114? */ > 115 int > 116 PKCS11_generate_key(PKCS11_TOKEN * token, > 117???????????? int algorithm, unsigned int bits, char *label, > unsigned char* id, size_t id_len) > 118 { > 119???? PKCS11_KEY *key_obj; > 120???? EVP_PKEY *pk; > 121???? RSA *rsa; > 122???? BIO *err; > 123???? int rc; > 124 > 125???? if (algorithm != EVP_PKEY_RSA) { > 126???????? PKCS11err(PKCS11_F_PKCS11_GENERATE_KEY, > PKCS11_NOT_SUPPORTED); > 127???????? return -1; > 128???? } > 129 > 130???? err = BIO_new_fp(stderr, BIO_NOCLOSE); > 131???? rsa = RSA_generate_key(bits, 0x10001, NULL, err); > 132???? BIO_free(err); > 133???? if (rsa == NULL) { > 134???????? PKCS11err(PKCS11_F_PKCS11_GENERATE_KEY, > PKCS11_KEYGEN_FAILED); > 135???????? return -1; > 136???? } > 137 > 138???? pk = EVP_PKEY_new(); > 139???? EVP_PKEY_assign_RSA(pk, rsa); > 140???? rc = pkcs11_store_private_key(token, pk, label, id, id_len, > &key_obj); > > That's a shitty place to hide such a glaring security hole. Hopefully it is also an open, non-hidden bug and a warning in the README, manpage etc. Because most users of PKCS#11 hardware would presume that software using their hardware doesn't silently nullify a key hardware security feature. 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 marquess at openssl.com Wed Oct 4 14:35:47 2017 From: marquess at openssl.com (Steve Marquess) Date: Wed, 4 Oct 2017 10:35:47 -0400 Subject: [openssl-users] FIPS Object Module 2.0, fipsalgtest.pl fails In-Reply-To: <0B2EBCD48D33654381E736352034C70C01A29838@dor-sms-xch01.digi.com> References: <0B2EBCD48D33654381E736352034C70C01A20EC7@dor-sms-xch01.digi.com> <239540b0-9fd7-181f-d102-67e551c1f6a5@openssl.com> <0B2EBCD48D33654381E736352034C70C01A262ED@dor-sms-xch01.digi.com> <6e093973-120c-a802-2f2b-bb611771c2cd@openssl.com> <0B2EBCD48D33654381E736352034C70C01A29838@dor-sms-xch01.digi.com> Message-ID: <7fa066ad-1480-9cf1-4086-a9f598d8e79c@openssl.com> On 10/03/2017 05:26 PM, Diaz de Grenu, Jose wrote: > >> You reprocessed all of the hundreds of test vectors? I'm impressed. That >> must have taken many days of compute time. > > Sorry, the download script I set up seg faulted after some time, and I didn't noticed. In fact it only tested a few tarballs. > > >> The most recent set of test vectors used for a 2.0.16 OE is: >> http://openssl.com/testing/validation-2.0/testvectors/OVS_2859_OE82.results.tar.gz > > That one also fails. > > Thanks for all the information anyways. I will keep trying with other test vector, just in case. > If you use a stock unmodified openssl-fips-2.0.N.tar.gz tarball and an appropriate matching set of test vectors then they can be successfully processed (on a very wide range of platforms). That has literally been done with hundreds of test vector sets. I suggest you circle back to the basics. Download an unmodified openssl-fips-2.0.16.tar.gz and build that on a known supported platform, for instance a modern Linux distro. Then process a recent test vector set, for instance the one noted above. If that fails you have something very broken in your build environment or platform; you'll want to sort that out before trying anything adventurous. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 301 874 2571 marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rschm2 at unh.newhaven.edu Wed Oct 4 14:48:49 2017 From: rschm2 at unh.newhaven.edu (Schmicker, Robert) Date: Wed, 4 Oct 2017 14:48:49 +0000 Subject: [openssl-users] Integrating New Cipher Suite In-Reply-To: References: Message-ID: Not sure if I'm late to the party on this one but check out this link: https://wiki.openssl.org/index.php/How_to_Integrate_a_Symmetric_Cipher I wrote this up a few months back so let me know if you have any questions. Rob From: openssl-users-request at openssl.org Sent: Wednesday, October 4, 4:29 AM Subject: openssl-users Digest, Vol 35, Issue 2 To: openssl-users at openssl.org Send openssl-users mailing list submissions to openssl-users at openssl.org To subscribe or unsubscribe via the World Wide Web, visit https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmta.openssl.org%2Fmailman%2Flistinfo%2Fopenssl-users&data=02%7C01%7Crschm2%40unh.newhaven.edu%7C50cde6976b254f2c412e08d50b021142%7C3c71cbabb5ed4f3bac0d95509d6c0e93%7C0%7C0%7C636427025869613510&sdata=nwv%2FYJCbDn6efXDt5aLvRnrx0yZNb6CO96bSR7i7KpE%3D&reserved=0 or, via email, send a message with subject or body 'help' to openssl-users-request at openssl.org You can reach the person managing the list at openssl-users-owner at openssl.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openssl-users digest..." Today's Topics: 1. Re: Integrating New Cipher Suite (Jakob Bohm) 2. Re: FIPS Object Module 2.0, fipsalgtest.pl fails (Diaz de Grenu, Jose) 3. Re: FIPS Object Module 2.0, fipsalgtest.pl fails (Steve Marquess) 4. Engine configuration (Dmitry Belyavsky) 5. Re: Engine configuration (Dr. Stephen Henson) 6. AES CMAC with given iv (Stefan Gr?nwald) 7. Re: FIPS Object Module 2.0, fipsalgtest.pl fails (Diaz de Grenu, Jose) 8. Re: Storing private key on tokens (lists) ---------------------------------------------------------------------- Message: 1 Date: Mon, 2 Oct 2017 13:52:18 +0200 From: Jakob Bohm To: openssl-users at openssl.org Subject: Re: [openssl-users] Integrating New Cipher Suite Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed On 02/10/2017 00:47, Dr. Stephen Henson wrote: > On Sun, Oct 01, 2017, Wallboy wrote: > >> Hi, >> >> ... >> Bonus Question: Is it possible to remove the SCSV cipher in the ClientHello? >> > You can't remove it without making source changes. Again it's in the > ssl_cipher_list_to_bytes() function. > Have you tried clearing SSL_MODE_SEND_FALLBACK_SCSV (in a program), or (not) using the -fallback_scsv option to s_client? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wisemo.com&data=02%7C01%7Crschm2%40unh.newhaven.edu%7C50cde6976b254f2c412e08d50b021142%7C3c71cbabb5ed4f3bac0d95509d6c0e93%7C0%7C0%7C636427025869613510&sdata=LVMC1kSp3iqPTwUPFYLAfNrPzByVOBFdcH3qMS3P5TY%3D&reserved=0 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 ------------------------------ Message: 2 Date: Mon, 2 Oct 2017 14:29:06 +0000 From: "Diaz de Grenu, Jose" To: "openssl-users at openssl.org" Subject: Re: [openssl-users] FIPS Object Module 2.0, fipsalgtest.pl fails Message-ID: Content-Type: text/plain; charset="us-ascii" > The FIPS module and test suite software (fipsalgtest.pl) are designed to work with exactly those algorithm tests relevant to the associated validations > (#1747/2398/2473). The test labs generate a unique set of test vectors for each platform validation; those test vectors must be of the expected format to > be successfully processed. Often they are not, either because they we incorrectly specified or due to errors. Figuring out such discrepancies can be lots of > fun (not!). > You will want to compare your test vectors with a known good set from https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenssl.com%2Ftesting%2Fvalidation-2.0%2Ftestvectors%2F&data=02%7C01%7Crschm2%40unh.newhaven.edu%7C50cde6976b254f2c412e08d50b021142%7C3c71cbabb5ed4f3bac0d95509d6c0e93%7C0%7C0%7C636427025869613510&sdata=9Eh2AW%2FpJaCMJba4mKGOFEB%2F0VORUG8aocNuMZQnWQw%3D&reserved=0. Pick a recent set, as the format of the test vectors changes over time. Note that as > a result frequent adjustment of fipsalgtest.pl is often necessary. I have tried with all the tarballs but I am not able to find one which works without errors. Is there any way to check which test vector were used for FIPS Object Module 2.0.16? ------------------------------ Message: 3 Date: Mon, 2 Oct 2017 11:39:11 -0400 From: Steve Marquess To: openssl-users at openssl.org Subject: Re: [openssl-users] FIPS Object Module 2.0, fipsalgtest.pl fails Message-ID: Content-Type: text/plain; charset=utf-8 On 10/02/2017 10:29 AM, Diaz de Grenu, Jose wrote: > >> The FIPS module and test suite software (fipsalgtest.pl) are designed to work with exactly those algorithm tests relevant to the associated validations >> (#1747/2398/2473). The test labs generate a unique set of test vectors for each platform validation; those test vectors must be of the expected format to >> be successfully processed. Often they are not, either because they we incorrectly specified or due to errors. Figuring out such discrepancies can be lots of > > fun (not!). > >> You will want to compare your test vectors with a known good set from https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenssl.com%2Ftesting%2Fvalidation-2.0%2Ftestvectors%2F&data=02%7C01%7Crschm2%40unh.newhaven.edu%7C50cde6976b254f2c412e08d50b021142%7C3c71cbabb5ed4f3bac0d95509d6c0e93%7C0%7C0%7C636427025869613510&sdata=9Eh2AW%2FpJaCMJba4mKGOFEB%2F0VORUG8aocNuMZQnWQw%3D&reserved=0. Pick a recent set, as the format of the test vectors changes over time. Note that as >> a result frequent adjustment of fipsalgtest.pl is often necessary. > > I have tried with all the tarballs but I am not able to find one which works without errors. You reprocessed all of the hundreds of test vectors? I'm impressed. That must have taken many days of compute time. > > Is there any way to check which test vector were used for FIPS Object Module 2.0.16? > The most recent set of test vectors used for a 2.0.16 OE is: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenssl.com%2Ftesting%2Fvalidation-2.0%2Ftestvectors%2FOVS_2859_OE82.results.tar.gz&data=02%7C01%7Crschm2%40unh.newhaven.edu%7C50cde6976b254f2c412e08d50b021142%7C3c71cbabb5ed4f3bac0d95509d6c0e93%7C0%7C0%7C636427025869613510&sdata=fW9XGPMi0WRLYelNRQhwhID1bzm3ysI98RO7sghAHhU%3D&reserved=0 You have no way of knowing that because we don't publish a mapping of test vectors to OEs (and most FIPS 140 module vendors don't publish anything at all). And before you ask, no, while we're delighted to be an open source model for other validations I'm not keen on spending time specifically supporting proprietary validations that don't benefit the OpenSSL community as a whole. Please note that if you're trying to do your own "private label" validation you'll have to use a new unique set of test vectors provided by your accredited test lab; reprocessing a previously used set doesn't buy you much. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 301 874 2571 marquess at openssl.com gpg/pgp key: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenssl.com%2Fdocs%2F0x6D1892F5.asc&data=02%7C01%7Crschm2%40unh.newhaven.edu%7C50cde6976b254f2c412e08d50b021142%7C3c71cbabb5ed4f3bac0d95509d6c0e93%7C0%7C0%7C636427025869613510&sdata=5TJfkgEQ75JT2IrsJWwY3NDQ6JntXtQB3nL94RxrSeo%3D&reserved=0 ------------------------------ Message: 4 Date: Mon, 2 Oct 2017 23:02:32 +0300 From: Dmitry Belyavsky To: openssl-users at openssl.org Subject: [openssl-users] Engine configuration Message-ID: Content-Type: text/plain; charset="utf-8" Hello, I have a question regarding engine configuration. We need to implement such behaviour: - on load the engine is configured with the commands from config file, but the values can be overwritten via environment - application can change the engine's configuration via ENGINE_ctrl_string functions. Is there any way to distinguish whether engine is configured via the config file or via direct calls to ENGINE_ctrl* functions? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Mon, 2 Oct 2017 21:16:10 +0000 From: "Dr. Stephen Henson" To: openssl-users at openssl.org Subject: Re: [openssl-users] Engine configuration Message-ID: Content-Type: text/plain; charset=us-ascii On Mon, Oct 02, 2017, Dmitry Belyavsky wrote: > Hello, > > I have a question regarding engine configuration. > > We need to implement such behaviour: > - on load the engine is configured with the commands from config file, but > the values can be overwritten via environment That part can be done with the config file syntax see config(5) > - application can change the engine's configuration via ENGINE_ctrl_string > functions. > > Is there any way to distinguish whether engine is configured via the config > file or via direct calls to ENGINE_ctrl* functions? > Not currently no: the config file calls the relevant control operations. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openssl.org&data=02%7C01%7Crschm2%40unh.newhaven.edu%7C50cde6976b254f2c412e08d50b021142%7C3c71cbabb5ed4f3bac0d95509d6c0e93%7C0%7C0%7C636427025869613510&sdata=Gxzc9T8L%2FC4VWZ3zrO80EhQiXnSp%2BUefxC5mmzODvQ0%3D&reserved=0 ------------------------------ Message: 6 Date: Tue, 3 Oct 2017 08:33:46 +0200 From: Stefan Gr?nwald To: openssl-users at openssl.org Subject: [openssl-users] AES CMAC with given iv Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed Hi, I need to calculate an AES CMAC with a given iv and also get the new iv after the calculation. On the internet I found some examples how to calculate the CMAC but if I read the code correctly it always starts with a zero iv. I also found the CMAC_resume function which restores the iv but it also doesn't take the iv as an input parameter. Is there any chance to set and get the iv? The only way I would see at the moment is an ugly hack by setting the tbl field of the context struct in memory before calling CMAC_resume. Thanks, Stefan ------------------------------ Message: 7 Date: Tue, 3 Oct 2017 21:26:06 +0000 From: "Diaz de Grenu, Jose" To: "openssl-users at openssl.org" Subject: Re: [openssl-users] FIPS Object Module 2.0, fipsalgtest.pl fails Message-ID: Content-Type: text/plain; charset="us-ascii" > You reprocessed all of the hundreds of test vectors? I'm impressed. That > must have taken many days of compute time. Sorry, the download script I set up seg faulted after some time, and I didn't noticed. In fact it only tested a few tarballs. > The most recent set of test vectors used for a 2.0.16 OE is: >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenssl.com%2Ftesting%2Fvalidation-2.0%2Ftestvectors%2FOVS_2859_OE82.results.tar.gz&data=02%7C01%7Crschm2%40unh.newhaven.edu%7C50cde6976b254f2c412e08d50b021142%7C3c71cbabb5ed4f3bac0d95509d6c0e93%7C0%7C0%7C636427025869613510&sdata=fW9XGPMi0WRLYelNRQhwhID1bzm3ysI98RO7sghAHhU%3D&reserved=0 That one also fails. Thanks for all the information anyways. I will keep trying with other test vector, just in case. ------------------------------ Message: 8 Date: Wed, 4 Oct 2017 10:17:32 +0200 From: lists To: openssl-users at openssl.org Subject: Re: [openssl-users] Storing private key on tokens Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed On 09/27/2017 11:13 PM, Ken Goldman wrote: > On 9/27/2017 2:19 PM, Dirk-Willem van Gulik wrote: >> >>> On 27 Sep 2017, at 20:02, Michael Wojcik >>> >>> The tokens / HSMs I've used don't let you generate a key somewhere >>> else and install it on the token. They insist on doing the key >>> generation locally. That is, after all, part of the point of using >>> a token - the key never leaves it. >> >> I've found that the Feitian ePass2000's and the Yubico keys allow for >> importing of the private key. They do usually want the 'extra' flags >> to specify use: > > FWIW, the TPM hardware also permits key import.? It does validate > attributes, so users will know that the key was not generated on chip. > Most smart cards (G&D, Oberthur and InCard) I've dealt with allow for external generation of RSA keys and import into the token. Currently I mostly use InCard cards sold in Italy, I can't tell if the other brands are still easily purchaseable. ------------------------------ Subject: Digest Footer _______________________________________________ openssl-users mailing list openssl-users at openssl.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmta.openssl.org%2Fmailman%2Flistinfo%2Fopenssl-users&data=02%7C01%7Crschm2%40unh.newhaven.edu%7C50cde6976b254f2c412e08d50b021142%7C3c71cbabb5ed4f3bac0d95509d6c0e93%7C0%7C0%7C636427025869613510&sdata=nwv%2FYJCbDn6efXDt5aLvRnrx0yZNb6CO96bSR7i7KpE%3D&reserved=0 ------------------------------ End of openssl-users Digest, Vol 35, Issue 2 ******************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Wed Oct 4 17:28:44 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 4 Oct 2017 20:28:44 +0300 Subject: [openssl-users] Engine configuration In-Reply-To: <20171002211610.GA28570@openssl.org> References: <20171002211610.GA28570@openssl.org> Message-ID: Dear Stephen, On Tue, Oct 3, 2017 at 12:16 AM, Dr. Stephen Henson wrote: > On Mon, Oct 02, 2017, Dmitry Belyavsky wrote: > > > Hello, > > > > I have a question regarding engine configuration. > > > > We need to implement such behaviour: > > - on load the engine is configured with the commands from config file, > but > > the values can be overwritten via environment > > That part can be done with the config file syntax see config(5) > > > - application can change the engine's configuration via > ENGINE_ctrl_string > > functions. > > > > Is there any way to distinguish whether engine is configured via the > config > > file or via direct calls to ENGINE_ctrl* functions? > > > > Not currently no: the config file calls the relevant control operations. > > Does it make sense to create a PR (without code for now) to make these cases distinguishable? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Oct 4 17:35:29 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 4 Oct 2017 19:35:29 +0200 Subject: [openssl-users] Engine configuration In-Reply-To: References: <20171002211610.GA28570@openssl.org> Message-ID: On 04/10/2017 19:28, Dmitry Belyavsky wrote: > Dear Stephen, > > On Tue, Oct 3, 2017 at 12:16 AM, Dr. Stephen Henson > wrote: > >> On Mon, Oct 02, 2017, Dmitry Belyavsky wrote: >> >>> Hello, >>> >>> I have a question regarding engine configuration. >>> >>> We need to implement such behaviour: >>> - on load the engine is configured with the commands from config file, >> but >>> the values can be overwritten via environment >> That part can be done with the config file syntax see config(5) >> >>> - application can change the engine's configuration via >> ENGINE_ctrl_string >>> functions. >>> >>> Is there any way to distinguish whether engine is configured via the >> config >>> file or via direct calls to ENGINE_ctrl* functions? >>> >> Not currently no: the config file calls the relevant control operations. >> >> > Does it make sense to create a PR (without code for now) to make these > cases distinguishable? > Thank you! It would make more sense to ensure that the configuration (from any origin, ENGINE_ctrl_, config file, environment, future mechanisms) is consistently read through the same software "stack" and code path, such that any supplemental / engine specific parameters are passed through all the way and the engine code doesn't need to know or care about where that is. 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 npathak2 at ncsu.edu Thu Oct 5 00:56:04 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Wed, 4 Oct 2017 20:56:04 -0400 Subject: [openssl-users] Research papers on TLS 1.3 Message-ID: Hi All, Could you please suggest few research papers (apart from TLS 1.3 draft) on TLS 1.3 that may b helpful to understand TLS 1.3 implementation and performance. Is there any research available on TLS 1.3 performance benchmarking? Some papers which I am referring right now are: 1. A Cryptographic Analysis of the TLS 1.3 Handshake Protocol Candidates 2) Automated Analysis and Verification of TLS 1.3: 0-RTT, Resumption and Delayed Authentication Thanks Best Regards, Neetish -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Oct 5 00:58:37 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 5 Oct 2017 00:58:37 +0000 Subject: [openssl-users] Research papers on TLS 1.3 In-Reply-To: References: Message-ID: <45325911-9EA0-4D98-8E92-6662CCD82C25@akamai.com> You should look at the IETF TLS working group. Also, there was a mini conference, TLS Ready or Not, that has a bunch of useful papers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Thu Oct 5 01:16:12 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Wed, 4 Oct 2017 21:16:12 -0400 Subject: [openssl-users] Research papers on TLS 1.3 In-Reply-To: <45325911-9EA0-4D98-8E92-6662CCD82C25@akamai.com> References: <45325911-9EA0-4D98-8E92-6662CCD82C25@akamai.com> Message-ID: Thanks, Rich. Do you have the link to the mini-conference proceedings? Thanks Best Regards, Neetish On Wed, Oct 4, 2017 at 8:58 PM, Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > You should look at the IETF TLS working group. Also, there was a mini > conference, TLS Ready or Not, that has a bunch of useful papers. > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh116 at gmail.com Thu Oct 5 09:57:46 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Thu, 5 Oct 2017 15:27:46 +0530 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets Message-ID: Hi All, I have query regarding the SSL_read on blocking socket. How to come out of blocking SSL_read when we have to close the connection ? As per the documentation SSL_read will only return if there is any data or an error occurred. "If the underlying BIO is *blocking*, SSL_read() will only return, *once the read operation has been finished or an error occurred,* except when a renegotiation take place, in which case a SSL_ERROR_WANT_READ may occur" I am trying following methods *method 1:* 1) Thread - 1 blocks in SSL_read 2) Thread - 2 receive indication to stop the connection from application. Call SSL_Shutdown() to unblock the SSL_read in thread - 1. But this is dangerous as calling SSL_shutdown and SSL_read from different threads on same context can lead to undefined behaviour. *method 2:* 1) Thread - 1 blocks in SSL_read 2) Thread - 2 receive indication to stop the connection from application. shutdown the underlying TCP socket using system command (shutdown (socket_id, SHUT_WR)) that cause the SSL_read to unblock. 3) Thread - 1 unwind and close the TCP socket (using close(socket_id)). thread -1 cannot call SSL_Shutdown since the TCP socket is shutdown by thread - 2 for write operation. As per my understanding this violates the TLS standard because of not sending out the close notify handshake. How to ensure to come out of blocking SSL_read and initiate SSL_shutdown from same thread? Thanks, Mahesh G S -------------- next part -------------- An HTML attachment was scrubbed... URL: From murugesh.pitchaiah at gmail.com Thu Oct 5 11:51:14 2017 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Thu, 5 Oct 2017 17:21:14 +0530 Subject: [openssl-users] Openssl FIPS 186-4 Patch Message-ID: Hi All, I am looking for the FIPS 186-4 patch. I see it is not yet implemented in openssl FIPS 2.0 I see many vendors have implemented their own fix for FIPS 186-4 compliance. I am looking for the patch which i can reuse. Looks like redhat too has its own patch. Kindly share any pointers for the (open license for reuse) patch for FIPS 186-4 compliance. I am using openssl FIPS ECP 2.0.16. Thanks, Murugesh P. From jqian at tibco.com Thu Oct 5 14:43:43 2017 From: jqian at tibco.com (Jason Qian) Date: Thu, 5 Oct 2017 10:43:43 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: Here is the stack trace : libeay32.dll!RAND_poll Normal [External Code] libeay32.dll!RAND_poll() Line 523 libeay32.dll!ssleay_rand_bytes(unsigned char * buf, int num, int pseudo) Line 395 libeay32.dll!ssleay_rand_nopseudo_bytes(unsigned char * buf, int num) Line 536 Thanks Jason On Wed, Sep 27, 2017 at 2:02 PM, Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Jason Qian via openssl-users > > Sent: Wednesday, September 27, 2017 07:00 > > To: openssl-users at openssl.org > > Subject: [openssl-users] DH_generate_key Hangs > > > Need some help, one of our application that hangs when calling > > DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded > condition. > > Not sure, if anyone know this issue ? > > The issue is running OpenSSL 0.9.8, which has not been supported since > 2015. > > DH_generate_key can use an engine (at least in supported versions of > OpenSSL - I no longer have any 0.9.8 code around to check), so we really > can't say what it might be doing in your application. But if it's using the > default OpenSSL implementation, then if your DH parameters don't already > include a private key, you'll end up generating random numbers. That can > hang, if OpenSSL is using a blocking CPRNG source such as /dev/random. > > But you haven't provided nearly enough information to do more than > speculate. > > What you need to do: > > 1. Upgrade to OpenSSL 1.0.2 (or possibly 1.1.0, but that has API changes > and isn't an LTS release). There's really no point in proceeding unless you > do so. Your application is broken if it's using 0.9.8. > > 2. If the problem still occurs, debug a hanging instance and find out > where *exactly* it's hung. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Oct 5 15:55:45 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 5 Oct 2017 17:55:45 +0200 Subject: [openssl-users] Openssl FIPS 186-4 Patch In-Reply-To: References: Message-ID: On 05/10/2017 13:51, murugesh pitchaiah wrote: > Hi All, > > I am looking for the FIPS 186-4 patch. I see it is not yet implemented > in openssl FIPS 2.0 I assume FIPS 186-4 is the updated SHA standard that adds the SHA-3 specification. In that case, that would be something that OpenSSL would first add to the basic OpenSSL library (perhaps in version 1.1.x). Once that is working as secure and tested (but not government "validated"), OpenSSL could incorporate that into their upcoming FIPS-validation (which I guess will become the "FIPS module 3.0"). The "FIPS validation" bureaucracy is such that even basic bug fixes are very expensive and time consuming to get approved, thus adding new algorithms or other new features inside the "boundary" of the FIPS module is not something done under normal circumstances, and certainly not just to add another algorithm that isn't used by many people yet to a FIPS module that is only used by the OpenSSL 1.0.x library that they are trying to discontinue. 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 Michael.Wojcik at microfocus.com Thu Oct 5 15:59:30 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 5 Oct 2017 15:59:30 +0000 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: As I speculated, it appears you're hanging in random-number generation, probably due to a blocking CPRNG that can't get the entropy it needs. This is an operating-system issue, and needs to be referred to your OS administrator. Michael Wojcik Distinguished Engineer, Micro Focus From: Jason Qian [mailto:jqian at tibco.com] Sent: Thursday, October 05, 2017 08:44 To: Michael Wojcik Cc: openssl-users at openssl.org Subject: Re: [openssl-users] DH_generate_key Hangs Here is the stack trace : libeay32.dll!RAND_poll Normal [External Code] libeay32.dll!RAND_poll() Line 523 libeay32.dll!ssleay_rand_bytes(unsigned char * buf, int num, int pseudo) Line 395 libeay32.dll!ssleay_rand_nopseudo_bytes(unsigned char * buf, int num) Line 536 Thanks Jason On Wed, Sep 27, 2017 at 2:02 PM, Michael Wojcik > wrote: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jason Qian via openssl-users > Sent: Wednesday, September 27, 2017 07:00 > To: openssl-users at openssl.org > Subject: [openssl-users] DH_generate_key Hangs > Need some help, one of our application that hangs when calling > DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded condition. > Not sure, if anyone know this issue ? The issue is running OpenSSL 0.9.8, which has not been supported since 2015. DH_generate_key can use an engine (at least in supported versions of OpenSSL - I no longer have any 0.9.8 code around to check), so we really can't say what it might be doing in your application. But if it's using the default OpenSSL implementation, then if your DH parameters don't already include a private key, you'll end up generating random numbers. That can hang, if OpenSSL is using a blocking CPRNG source such as /dev/random. But you haven't provided nearly enough information to do more than speculate. What you need to do: 1. Upgrade to OpenSSL 1.0.2 (or possibly 1.1.0, but that has API changes and isn't an LTS release). There's really no point in proceeding unless you do so. Your application is broken if it's using 0.9.8. 2. If the problem still occurs, debug a hanging instance and find out where *exactly* it's hung. -- Michael Wojcik Distinguished Engineer, Micro Focus -------------- next part -------------- An HTML attachment was scrubbed... URL: From jqian at tibco.com Thu Oct 5 18:55:58 2017 From: jqian at tibco.com (Jason Qian) Date: Thu, 5 Oct 2017 14:55:58 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: Thanks Michael, I saw a lot of discussion for this issue on, https://mta.openssl.org/pipermail/openssl-dev/2015-July/002210.html Not sure if openSSL has a workaround or a patch ? It hangs on : *libeay32.dll!RAND_poll() Line 523 * if (*heap_first*(&hentry, hlist.th32ProcessID, hlist.th32HeapID)) Jason On Thu, Oct 5, 2017 at 11:59 AM, Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > As I speculated, it appears you're hanging in random-number generation, > probably due to a blocking CPRNG that can't get the entropy it needs. > > > > This is an operating-system issue, and needs to be referred to your OS > administrator. > > > > Michael Wojcik > Distinguished Engineer, Micro Focus > > > > > > > > *From:* Jason Qian [mailto:jqian at tibco.com] > *Sent:* Thursday, October 05, 2017 08:44 > *To:* Michael Wojcik > *Cc:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] DH_generate_key Hangs > > > > > > Here is the stack trace : > > > > libeay32.dll!RAND_poll Normal > > [External Code] > > > > libeay32.dll!RAND_poll() Line 523 > > libeay32.dll!ssleay_rand_bytes(unsigned char * buf, int num, int pseudo) > Line 395 > > libeay32.dll!ssleay_rand_nopseudo_bytes(unsigned char * buf, int num) > Line 536 > > > > > > Thanks > > Jason > > > > > > > > On Wed, Sep 27, 2017 at 2:02 PM, Michael Wojcik < > Michael.Wojcik at microfocus.com> wrote: > > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Jason Qian via openssl-users > > Sent: Wednesday, September 27, 2017 07:00 > > To: openssl-users at openssl.org > > Subject: [openssl-users] DH_generate_key Hangs > > > Need some help, one of our application that hangs when calling > > DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded > condition. > > Not sure, if anyone know this issue ? > > The issue is running OpenSSL 0.9.8, which has not been supported since > 2015. > > DH_generate_key can use an engine (at least in supported versions of > OpenSSL - I no longer have any 0.9.8 code around to check), so we really > can't say what it might be doing in your application. But if it's using the > default OpenSSL implementation, then if your DH parameters don't already > include a private key, you'll end up generating random numbers. That can > hang, if OpenSSL is using a blocking CPRNG source such as /dev/random. > > But you haven't provided nearly enough information to do more than > speculate. > > What you need to do: > > 1. Upgrade to OpenSSL 1.0.2 (or possibly 1.1.0, but that has API changes > and isn't an LTS release). There's really no point in proceeding unless you > do so. Your application is broken if it's using 0.9.8. > > 2. If the problem still occurs, debug a hanging instance and find out > where *exactly* it's hung. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Oct 5 18:59:03 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 5 Oct 2017 18:59:03 +0000 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: <2F96B4B0-8BF8-48BC-8802-F17F1F928179@akamai.com> You could try to backport the win_rand file from a more recent release. Far better, as Michael first said, to move to 1.0.2 or later. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jqian at tibco.com Thu Oct 5 19:27:13 2017 From: jqian at tibco.com (Jason Qian) Date: Thu, 5 Oct 2017 15:27:13 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: <2F96B4B0-8BF8-48BC-8802-F17F1F928179@akamai.com> References: <2F96B4B0-8BF8-48BC-8802-F17F1F928179@akamai.com> Message-ID: Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no change Thanks On Thu, Oct 5, 2017 at 2:59 PM, Salz, Rich wrote: > You could try to backport the win_rand file from a more recent release. > > > > Far better, as Michael first said, to move to 1.0.2 or later. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Oct 5 19:31:23 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 5 Oct 2017 19:31:23 +0000 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: <2F96B4B0-8BF8-48BC-8802-F17F1F928179@akamai.com> Message-ID: * Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no change Sorry, then try 1.1.0 The HEAPWALK bug/issue is fixed there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Thu Oct 5 19:33:16 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 5 Oct 2017 15:33:16 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: On Thu, Oct 5, 2017 at 2:55 PM, Jason Qian via openssl-users wrote: > Thanks Michael, > > I saw a lot of discussion for this issue on, > > https://mta.openssl.org/pipermail/openssl-dev/2015-July/002210.html > > Not sure if openSSL has a workaround or a patch ? > > > It hangs on : > > libeay32.dll!RAND_poll() Line 523 > > if (heap_first(&hentry, > hlist.th32ProcessID, > hlist.th32HeapID)) You should avoid calls to RAND_poll altogether on Windows. Do so by explicitly seeding the random number generator yourself. Also see https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues on the OpenSSL wiki. Jeff From noloader at gmail.com Thu Oct 5 19:37:53 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 5 Oct 2017 15:37:53 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: <2F96B4B0-8BF8-48BC-8802-F17F1F928179@akamai.com> Message-ID: On Thu, Oct 5, 2017 at 3:27 PM, Jason Qian via openssl-users wrote: > Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no > change I believe it was fixed earlier than that. Also see https://rt.openssl.org/Ticket/Display.html?id=2100&user=guest&pass=guest As Michael suggested, 0.9.8 is the biggest problem. You should probably solve that problem first. Jeff From jqian at tibco.com Thu Oct 5 19:53:22 2017 From: jqian at tibco.com (Jason Qian) Date: Thu, 5 Oct 2017 15:53:22 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: We call DH_generate_key(DH *dh) and the RAND_poll() is called ssleay_rand_bytes libeay32d.dll!RAND_poll() Line 572 C libeay32d.dll!ssleay_rand_bytes(unsigned char * buf=0x03318fe0, int num=128, int pseudo=0) Line 395 C libeay32d.dll!ssleay_rand_nopseudo_bytes(unsigned char * buf=0x03318fe0, int num=128) Line 536 + 0xf bytes C libeay32d.dll!RAND_bytes(unsigned char * buf=0x03318fe0, int num=128) Line 164 + 0x10 bytes C libeay32d.dll!bnrand(int pseudorand=0, bignum_st * rnd=0x03318518, int bits=1023, int top=0, int bottom=0) Line 152 + 0xd bytes C > libeay32d.dll!BN_rand(bignum_st * rnd=0x03318518, int bits=1023, int top=0, int bottom=0) Line 213 + 0x17 bytes C libeay32d.dll!generate_key(dh_st * dh=0x03316a88) Line 170 + 0x11 bytes C libeay32d.dll!DH_generate_key(dh_st * dh=0x03316a88) Line 84 + 0xf bytes C Thanks Jason On Thu, Oct 5, 2017 at 3:33 PM, Jeffrey Walton wrote: > On Thu, Oct 5, 2017 at 2:55 PM, Jason Qian via openssl-users > wrote: > > Thanks Michael, > > > > I saw a lot of discussion for this issue on, > > > > https://mta.openssl.org/pipermail/openssl-dev/2015- > July/002210.html > > > > Not sure if openSSL has a workaround or a patch ? > > > > > > It hangs on : > > > > libeay32.dll!RAND_poll() Line 523 > > > > if (heap_first(&hentry, > > hlist.th32ProcessID, > > hlist.th32HeapID)) > > You should avoid calls to RAND_poll altogether on Windows. Do so by > explicitly seeding the random number generator yourself. > > Also see https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues > on the OpenSSL wiki. > > Jeff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jqian at tibco.com Thu Oct 5 19:56:54 2017 From: jqian at tibco.com (Jason Qian) Date: Thu, 5 Oct 2017 15:56:54 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: More : The call stacks are from 1.0.1c when calling DH_generate_key. Is any fix in the latest version for this ? Thanks Jason On Thu, Oct 5, 2017 at 3:53 PM, Jason Qian wrote: > We call DH_generate_key(DH *dh) and the RAND_poll() is called > ssleay_rand_bytes > > > libeay32d.dll!RAND_poll() Line 572 C > libeay32d.dll!ssleay_rand_bytes(unsigned char * buf=0x03318fe0, int > num=128, int pseudo=0) Line 395 C > libeay32d.dll!ssleay_rand_nopseudo_bytes(unsigned char * > buf=0x03318fe0, int num=128) Line 536 + 0xf bytes C > libeay32d.dll!RAND_bytes(unsigned char * buf=0x03318fe0, int num=128) > Line 164 + 0x10 bytes C > libeay32d.dll!bnrand(int pseudorand=0, bignum_st * rnd=0x03318518, int > bits=1023, int top=0, int bottom=0) Line 152 + 0xd bytes C > > libeay32d.dll!BN_rand(bignum_st * rnd=0x03318518, int bits=1023, int > top=0, int bottom=0) Line 213 + 0x17 bytes C > libeay32d.dll!generate_key(dh_st * dh=0x03316a88) Line 170 + 0x11 bytes > C > libeay32d.dll!DH_generate_key(dh_st * dh=0x03316a88) Line 84 + 0xf > bytes C > > Thanks > Jason > > On Thu, Oct 5, 2017 at 3:33 PM, Jeffrey Walton wrote: > >> On Thu, Oct 5, 2017 at 2:55 PM, Jason Qian via openssl-users >> wrote: >> > Thanks Michael, >> > >> > I saw a lot of discussion for this issue on, >> > >> > https://mta.openssl.org/pipermail/openssl-dev/2015-July/ >> 002210.html >> > >> > Not sure if openSSL has a workaround or a patch ? >> > >> > >> > It hangs on : >> > >> > libeay32.dll!RAND_poll() Line 523 >> > >> > if (heap_first(&hentry, >> > hlist.th32ProcessID, >> > hlist.th32HeapID)) >> >> You should avoid calls to RAND_poll altogether on Windows. Do so by >> explicitly seeding the random number generator yourself. >> >> Also see https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues >> on the OpenSSL wiki. >> >> Jeff >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcepl at cepl.eu Thu Oct 5 22:07:34 2017 From: mcepl at cepl.eu (=?iso-8859-2?Q?Mat=ECj?= Cepl) Date: Fri, 6 Oct 2017 00:07:34 +0200 Subject: [openssl-users] [ANN] M2Crypto 0.27.0 Message-ID: <20171005220734.GA15565@mitmanek.ceplovi.cz> M2Crypto is the most complete Python wrapper for OpenSSL featuring RSA, DSA, DH, EC, HMACs, message digests, symmetric ciphers; SSL functionality to implement clients and servers; HTTPS extensions to Python?s httplib, urllib, and xmlrpclib; unforgeable HMAC?ing AuthCookies for web session management; FTP/TLS client and server; S/MIME. M2Crypto can also be used to provide SSL for Twisted. Smartcards supported through the Engine interface. This is another less earth-shattering release (after 0.26.2 which brought us OpenSSL 1.1.0 compatbility), one more step towards Python 3 compatibility nirvana, still more cleanups and accumulated bug fixes, which could be resolved before the big python3 branch is merged. The release is available on https://pypi.python.org/pypi/M2Crypto/ and all communication with the maintainer (that?s me) should go to https://gitlab.com/m2crypto/m2crypto. Talking about the python3 branch, ALL TESTS PASS on all Pythons from 2.6, 2.7, 3.3 to 3.6!!! Now is the time to test, help with review, and complain about whatever is wrong! I will still keep API stable, but changes are relatively large, so this is your opportunity to suggest whatever substantial thing you don't like with M2Crypto. I may not make it happen in 0.28 (which I expect to be Py3k-compatible release), but for settling the dust down and cleanup I prepare already 0.29, which should include yet more acummulated merge requests and bugfixes, this time ones which should be better served with python 3 layer already happening. Happy hacking! Mat?j -- https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Quod fuimus, estis; quod sumus, vos eritis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From Michael.Wojcik at microfocus.com Thu Oct 5 23:45:37 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 5 Oct 2017 23:45:37 +0000 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jeffrey Walton > Sent: Thursday, October 05, 2017 13:33 > To: Jason Qian; OpenSSL Users > Subject: Re: [openssl-users] DH_generate_key Hangs > > > You should avoid calls to RAND_poll altogether on Windows. Do so by > explicitly seeding the random number generator yourself. As a starting point, try something like this: ----- static ENGINE *rdrand; void init_prng(void) { /* Try to seed the PRNG with the Intel RDRAND on-chip PRNG */ OPENSSL_cpuid_setup(); ENGINE_load_rdrand(); rdrand = ENGINE_by_id("rdrand"); if (rdrand) { int success = 0; if (ENGINE_init(rdrand)) { success = ENGINE_set_default(rdrand, ENGINE_METHOD_RAND); } /*** Per OpenSSL wiki, call ENGINE_free here regardless of whether we're successfully using rdrand. The "functional reference" to rdrand will be released when we call ENGINE_finish. ***/ ENGINE_free(rdrand); if (! success) ENGINE_finish(rdrand), rdrand = NULL; } if (!rdrand && !RAND_status()){ RAND_screen(); /* this isn't really emough entropy, but it's a start */ if (!RAND_status()) { RAND_poll(); /* try to gather additional entropy */ } } } void terminate_engines(void) { if (rdrand) ENGINE_finish(rdrand), rdrand = NULL; /* similarly for any other engines you use */ ENGINE_cleanup(); } ----- Call init_prng after your OpenSSL initialization code (e.g. after calling OpenSSL_add_all_algorithms), and terminate_engines when you're done using OpenSSL (e.g. just before process exit). Note that this code uses RAND_screen if RDRAND isn't available. RAND_screen is really not a very good idea; it may be OK on workstations, but rarely provides much entropy on servers because they typically aren't doing much screen output. And if you still need entropy after the RAND_screen call, you'll end up in RAND_poll anyway. The alternative is to write your own code that harvests entropy from some source (or sources). Other people may have better suggestions. -- Michael Wojcik Distinguished Engineer, Micro Focus From noloader at gmail.com Thu Oct 5 23:52:28 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 5 Oct 2017 19:52:28 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: >> You should avoid calls to RAND_poll altogether on Windows. Do so by >> explicitly seeding the random number generator yourself. > > As a starting point, try something like this: > > ----- > static ENGINE *rdrand; > > void init_prng(void) { > /* Try to seed the PRNG with the Intel RDRAND on-chip PRNG */ > OPENSSL_cpuid_setup(); > ENGINE_load_rdrand(); > rdrand = ENGINE_by_id("rdrand"); > if (rdrand) { > int success = 0; > if (ENGINE_init(rdrand)) { > success = ENGINE_set_default(rdrand, ENGINE_METHOD_RAND); > } > > /*** > Per OpenSSL wiki, call ENGINE_free here regardless of whether we're > successfully using rdrand. The "functional reference" to rdrand will > be released when we call ENGINE_finish. > ***/ > ENGINE_free(rdrand); > if (! success) ENGINE_finish(rdrand), rdrand = NULL; > } > > if (!rdrand && !RAND_status()){ > RAND_screen(); /* this isn't really emough entropy, but it's a start */ > if (!RAND_status()) { > RAND_poll(); /* try to gather additional entropy */ > } > } > } > > void terminate_engines(void) { > if (rdrand) ENGINE_finish(rdrand), rdrand = NULL; > /* similarly for any other engines you use */ > ENGINE_cleanup(); > } > ----- > > Call init_prng after your OpenSSL initialization code (e.g. after calling OpenSSL_add_all_algorithms), and terminate_engines when you're done using OpenSSL (e.g. just before process exit). > > Note that this code uses RAND_screen if RDRAND isn't available. RAND_screen is really not a very good idea; it may be OK on workstations, but rarely provides much entropy on servers because they typically aren't doing much screen output. And if you still need entropy after the RAND_screen call, you'll end up in RAND_poll anyway. The alternative is to write your own code that harvests entropy from some source (or sources). > > Other people may have better suggestions. Headless servers without hw entropy sources are tough. In this case I use hedging. I've got some patches somewhere for 1.0.1, but they won't apply to 0.9.8. Also see: * When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography, http://pages.cs.wisc.edu/~rist/papers/sslhedge.pdf * When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments, http://www.usenix.org/legacy/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf Jeff From murugesh.pitchaiah at gmail.com Fri Oct 6 05:58:04 2017 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Fri, 6 Oct 2017 11:28:04 +0530 Subject: [openssl-users] Openssl FIPS 186-4 Patch In-Reply-To: References: Message-ID: Hi Jacob, Thanks for looking into this. This FIPS186-4 is not just about SHA. It basically about the key generation parameters. Especially I am looking for RSA key generation parameters wrt FIPS 186-4. Thanks, Murugesh P. On 10/5/17, Jakob Bohm wrote: > On 05/10/2017 13:51, murugesh pitchaiah wrote: >> Hi All, >> >> I am looking for the FIPS 186-4 patch. I see it is not yet implemented >> in openssl FIPS 2.0 > I assume FIPS 186-4 is the updated SHA standard that adds the SHA-3 > specification. > > In that case, that would be something that OpenSSL would first add to the > basic OpenSSL library (perhaps in version 1.1.x). > > Once that is working as secure and tested (but not government "validated"), > OpenSSL could incorporate that into their upcoming FIPS-validation (which I > guess will become the "FIPS module 3.0"). > > The "FIPS validation" bureaucracy is such that even basic bug fixes are > very > expensive and time consuming to get approved, thus adding new algorithms or > other new features inside the "boundary" of the FIPS module is not > something > done under normal circumstances, and certainly not just to add another > algorithm that isn't used by many people yet to a FIPS module that is only > used by the OpenSSL 1.0.x library that they are trying to discontinue. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From hrf-ssl at itg.hitachi.co.jp Fri Oct 6 06:24:56 2017 From: hrf-ssl at itg.hitachi.co.jp (=?iso-2022-jp?B?GyRCNiZETDRwSFcjUyNTI0whTjZITDMjSSNEIU8bKEIgLyBDT01NT05T?= =?iso-2022-jp?B?U0wbJEIhJBsoQkdZT1VNVQ==?=) Date: Fri, 6 Oct 2017 06:24:56 +0000 Subject: [openssl-users] Double free of session occurs in multithread program. Message-ID: <15CFFC2F2156164FA093C04D7DB5BFB365A75452@GSjpTK1DCembx01.service.hitachi.net> Hello, I am using OpenSSL's API to create multithreaded programs. Check the contents of the program in ssl_test.c. I have the following two questions. The purpose of the question is to create a program that does not cause double free. Question 1. Is this program correct as a program without double free? Question 2. Because this program is complicated, I want to make it a simple program. I want to easily create a program that does not cause double free. If you can create with this OpenSSL API different from this program, please tell us about API and usage. I will explain this program. It takes time to create a session each time communicate. Therefore, this program reuses sessions. If it set the references of the SSL_SESSION structure to 1 or higher, the session will not be released. SSL_connect() creates a new session. At this time, references are incremented with SSL_get1_session(). This will cause references to be greater than 1, so the session will not be freed. Multiple threads will share this session on subsequent communications. When the session expires, it is necessary to release the old session that was being reused. SSL_SESSION_free() can free old sessions that were being reused. When executing SSL_SESSION_free(), specify the address of the session(SSL_SESSION structure). This program outputs a core dump when deleting the line of "/*add*/" in ssl_test.c. The cause is to double free the address of the same session by two threads. As a measure against this problem, I limit the old session to one release. Therefore, flag (fs_isDelete) is set to 1 when the preceding thread releases the old session. After that, the following thread does not release the old session because the flag (fs_isDelete) is 1. I will explain the API that affects the references of the SSL_SESSION structure. (1) SSL_set_session() Create a session to reuse. I will explain the references. The references of the reusing session are incremented. (2) SSL_connect() If the session has not expired, we will use the session to reuse. If the session has expired, we will create a new session. I will explain the references. If the session has not expired, references will not change. If the session has expired, the references for the new session are 1. If the session has expired, the references of the old session will be decremented. (3) SSL_get1_session() If the session has not expired, obtain the address of the session to reuse. If the session has expired, we will get a new session. I will explain the references. If the session has not expired, the references of the session to be reused will increment. If the session has expired, the references of the new session will increment. (4) SSL_SESSION_free() SSL_SESSION_free() can free old sessions that were being reused. When executing SSL_SESSION_free(), specify the address of the session (SSL_SESSION structure). I will explain the references. The references of the old session are decremented. If references is 0, old sessions are freed. If references are already 0, double the address of the same session. I will explain the sequence of double free. I will explain the operation in single thread. First, thread 0 creates a new session. Thread 0 References for sessions to reuse SSL processing starts. SSL_connect() ---------> (+1) (1) SSL_get1_session() ----> (+1) (2) SSL_free() ------------> (-1) (1) SSL processing is terminated. After that, thread 1 reuses the session. At this time, the session may expire. In that case, SSL_SESSION_free() decrements the references of the old session. Thread 1 References of old sessions that have expired SSL processing starts. SSL_set_session() -----> (+1) (2) SSL_connect() ---------> (-1) (1) SSL_SESSION_free() ----> (-1) (0) SSL processing is terminated. I will explain the operation in multithreading. Thread 1, SSL_SESSION_free() decrements references for old sessions. After that, thread 2 also decrements the references of the same session and double-releases it. Thread 1 Thread 2 SSL processing starts. SSL processing starts. References of old sessions that have expired SSL_set_session() -----> (+1) (2) (+1) (3) <----- SSL_set_session() SSL_connect() ---------> (-1) (2) (-1) (1) <----- SSL_connect() SSL_SESSION_free() ----> (-1) (0) (-1) (-1) <---- SSL_SESSION_free() SSL processing is terminated. Doubles the address of the same session. ssl_test.c --------------------------------------- #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define MAX_SOCKET_COUNT 2 #define SOCKID_EMPTY 0 int localSocket[MAX_SOCKET_COUNT]; int currentSocketCount = 0; char *g_premorthostname = "hoge"; char *g_pserver_port_no = "12345"; #define CERTIFICATEFILEPATH "/home/server.crt" SSL_CTX *ctx = NULL; SSL_SESSION *fs_session = NULL; SSL_SESSION *fs_session_new = NULL; static int fs_refCount = 0; static int fs_isDelete = 0; static int fs_isAdd = 0; static pthread_mutex_t fs_lock_mutex; static pthread_mutex_t *fs_lock_mp = NULL; static long *fs_lock_count; void finalizer(void) { } void do_connect(char *argv1,char *argv2, int *p_localsocket) { int rc; struct hostent connecthostentstruct; struct hostent *connecthostentptr; struct sockaddr_in connectaddr; memset((void *)&connectaddr,0,sizeof(struct sockaddr_in)); *p_localsocket = -1; int sock = socket(AF_INET, SOCK_STREAM, 0); *p_localsocket = sock; rc = fcntl(sock,F_SETFD,FD_CLOEXEC); int ival = 1; rc = setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (const char*)&ival, sizeof ival); u_long lval = 1; int flag = fcntl(sock, F_GETFL, 0); rc = fcntl(sock, F_SETFL, O_NONBLOCK|flag); connecthostentptr = gethostbyname (argv1); connecthostentstruct = *connecthostentptr; connectaddr.sin_family = AF_INET; connectaddr.sin_port = htons(atoi(argv2)); connectaddr.sin_addr = * ((struct in_addr *) connecthostentstruct.h_addr); rc = connect(sock, (const struct sockaddr*)&connectaddr, sizeof connectaddr); if (errno == EINPROGRESS ) { fd_set fds_write; fd_set fds_except; FD_ZERO(&fds_write); FD_SET(sock, &fds_write); FD_ZERO(&fds_except); FD_SET(sock, &fds_except); struct timeval timeout; timeout.tv_sec = 10; timeout.tv_usec = 0; rc = select(sock+1, 0, &fds_write, &fds_except, &timeout); int err = 0; socklen_t err_len = sizeof(err); rc = getsockopt(sock, SOL_SOCKET, SO_ERROR, &err, &err_len ); } lval = 0; rc = fcntl(sock, F_SETFL, flag); } void linux_locking_callback(int mode, int type, const char *file, int line) { if (mode & CRYPTO_LOCK) { pthread_mutex_lock(&(fs_lock_mp[type])); } else { pthread_mutex_unlock(&(fs_lock_mp[type])); } } unsigned long linux_thread_id(void) { unsigned long ret; ret = (unsigned long)pthread_self(); return ret; } int thread_setup() { int i; fs_lock_mp = (pthread_mutex_t *)OPENSSL_malloc(CRYPTO_num_locks() * sizeof(pthread_mutex_t)); for (i = 0; i < CRYPTO_num_locks(); i++) { pthread_mutex_init(&(fs_lock_mp[i]), NULL); } CRYPTO_set_id_callback(linux_thread_id); CRYPTO_set_locking_callback(linux_locking_callback); } int ThreadFunc(void *argv) { int *p_threadIdx = (int *)argv; int threadIdx = *p_threadIdx; long cnt = 0; int localsocket = -1; SSL *ssl = NULL; int ret = 0; SSL_SESSION *session = NULL; SSL_SESSION *session_new = NULL; int nSSLError = SSL_ERROR_NONE; while (1) { session = NULL; session_new = NULL; ssl = SSL_new(ctx); do_connect(g_premorthostname,g_pserver_port_no,&localsocket); pthread_mutex_lock(&fs_lock_mutex); if (fs_isDelete && fs_refCount <= 0) { fs_isDelete = 0; fs_isAdd = 0; fs_session = fs_session_new; } if (fs_isDelete == 0) { fs_refCount++; session = fs_session; } if (session != NULL) { ret = SSL_set_session(ssl, session); /*(1)*/ } pthread_mutex_unlock(&fs_lock_mutex); ret = SSL_set_fd(ssl, localsocket); ret = SSL_connect(ssl); /*(2)*/ session_new = SSL_get0_session(ssl); pthread_mutex_lock(&fs_lock_mutex); if (session != NULL) { fs_refCount--; if ((session_new != session) && (session_new != NULL)) { if (fs_isDelete == 0) { /*add*/ fs_isDelete = 1 SSL_SESSION_free(session); /*(4)*/ fs_isAdd = 1; } /*add*/ } } else if (session_new != NULL) { fs_isAdd = 1; } if (fs_isAdd) { if (fs_session_new == NULL) { fs_session_new = SSL_get1_session(ssl); /*(3)*/ } } pthread_mutex_unlock(&fs_lock_mutex); sleep(1); SSL_shutdown(ssl); SSL_free(ssl); close(localsocket); } } int main(int argc,char *argv[]) { int retCode = 0; pthread_attr_t attr[MAX_SOCKET_COUNT]; pthread_t thid[MAX_SOCKET_COUNT]; int ret = 0; SSL_load_error_strings(); SSL_library_init(); atexit(finalizer); pthread_mutex_init(&fs_lock_mutex, NULL); ctx = SSL_CTX_new(SSLv23_client_method()); SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1); ret = SSL_CTX_load_verify_locations(ctx, CERTIFICATEFILEPATH, NULL); thread_setup(); while (1) { if(currentSocketCount >= MAX_SOCKET_COUNT) { sleep(1); continue; } retCode = pthread_attr_init(&attr[currentSocketCount]); pthread_attr_setdetachstate(&attr[currentSocketCount], PTHREAD_CREATE_JOINABLE); retCode = pthread_create(&thid[currentSocketCount], &attr[currentSocketCount], (void *)ThreadFunc, (void*)¤tSocketCount); pthread_attr_destroy(&attr[currentSocketCount]); currentSocketCount++; usleep(200000); } SSL_CTX_free(ctx); ERR_free_strings(); return 0; } --------------------------------------- Thanks in advance. Regards, Manabu From rsalz at akamai.com Fri Oct 6 13:13:15 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 6 Oct 2017 13:13:15 +0000 Subject: [openssl-users] Openssl FIPS 186-4 Patch In-Reply-To: References: Message-ID: <575911F4-C24A-4F0E-A4ED-7C042B0C3F79@akamai.com> ? This FIPS186-4 is not just about SHA. It basically about the key generation parameters. Especially I am looking for RSA key generation parameters wrt FIPS 186-4. I do not know how you got the opinion that OpenSSL has 186-4 support. It does not. Perhaps other people have written patches. If you find them, ask them to share with us ( From jqian at tibco.com Fri Oct 6 13:14:02 2017 From: jqian at tibco.com (Jason Qian) Date: Fri, 6 Oct 2017 09:14:02 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: Thanks Jeff, The challenge is that, we are not directly calling RAND_poll(). We just call *DH_generate_key* for DH key. >From the following call stacks, you can see the RAND_poll() is triggered by ssleay_rand_bytes. libeay32d.dll!*RAND_poll*() Line 572 C libeay32d.dll!ssleay_rand_bytes(unsigned char * buf=0x03318fe0, int num=128, int pseudo=0) Line 395 C libeay32d.dll!ssleay_rand_nopseudo_bytes(unsigned char * buf=0x03318fe0, int num=128) Line 536 + 0xf bytes C libeay32d.dll!RAND_bytes(unsigned char * buf=0x03318fe0, int num=128) Line 164 + 0x10 bytes C libeay32d.dll!bnrand(int pseudorand=0, bignum_st * rnd=0x03318518, int bits=1023, int top=0, int bottom=0) Line 152 + 0xd bytes C > libeay32d.dll!BN_rand(bignum_st * rnd=0x03318518, int bits=1023, int top=0, int bottom=0) Line 213 + 0x17 bytes C libeay32d.dll!generate_key(dh_st * dh=0x03316a88) Line 170 + 0x11 bytes C libeay32d.dll!*DH_generate_key*(dh_st * dh=0x03316a88) Line 84 + 0xf bytes C Jason On Thu, Oct 5, 2017 at 7:52 PM, Jeffrey Walton wrote: > >> You should avoid calls to RAND_poll altogether on Windows. Do so by > >> explicitly seeding the random number generator yourself. > > > > As a starting point, try something like this: > > > > ----- > > static ENGINE *rdrand; > > > > void init_prng(void) { > > /* Try to seed the PRNG with the Intel RDRAND on-chip PRNG */ > > OPENSSL_cpuid_setup(); > > ENGINE_load_rdrand(); > > rdrand = ENGINE_by_id("rdrand"); > > if (rdrand) { > > int success = 0; > > if (ENGINE_init(rdrand)) { > > success = ENGINE_set_default(rdrand, ENGINE_METHOD_RAND); > > } > > > > /*** > > Per OpenSSL wiki, call ENGINE_free here regardless of whether > we're > > successfully using rdrand. The "functional reference" to rdrand > will > > be released when we call ENGINE_finish. > > ***/ > > ENGINE_free(rdrand); > > if (! success) ENGINE_finish(rdrand), rdrand = NULL; > > } > > > > if (!rdrand && !RAND_status()){ > > RAND_screen(); /* this isn't really emough entropy, but it's a > start */ > > if (!RAND_status()) { > > RAND_poll(); /* try to gather additional entropy */ > > } > > } > > } > > > > void terminate_engines(void) { > > if (rdrand) ENGINE_finish(rdrand), rdrand = NULL; > > /* similarly for any other engines you use */ > > ENGINE_cleanup(); > > } > > ----- > > > > Call init_prng after your OpenSSL initialization code (e.g. after > calling OpenSSL_add_all_algorithms), and terminate_engines when you're done > using OpenSSL (e.g. just before process exit). > > > > Note that this code uses RAND_screen if RDRAND isn't available. > RAND_screen is really not a very good idea; it may be OK on workstations, > but rarely provides much entropy on servers because they typically aren't > doing much screen output. And if you still need entropy after the > RAND_screen call, you'll end up in RAND_poll anyway. The alternative is to > write your own code that harvests entropy from some source (or sources). > > > > Other people may have better suggestions. > > Headless servers without hw entropy sources are tough. In this case I > use hedging. I've got some patches somewhere for 1.0.1, but they won't > apply to 0.9.8. > > Also see: > > * When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities > and Hedging Deployed Cryptography, > http://pages.cs.wisc.edu/~rist/papers/sslhedge.pdf > * When Virtual is Harder than Real: Security Challenges in Virtual > Machine Based Computing Environments, > http://www.usenix.org/legacy/event/hotos05/final_papers/ > full_papers/garfinkel/garfinkel.pdf > > Jeff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Fri Oct 6 13:33:21 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 6 Oct 2017 13:33:21 +0000 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jason Qian via openssl-users > Sent: Friday, October 06, 2017 07:14 > The challenge is that,? we are not directly calling RAND_poll(). We just call DH_generate_key for DH key.? > From the following call stacks, you can see the RAND_poll() is triggered by ssleay_rand_bytes. RAND_poll is being called because the PRNG does not have enough entropy. Seed it with sufficient entropy first, and it won't be called by DH_generate_key. -- Michael Wojcik Distinguished Engineer, Micro Focus From rsalz at akamai.com Fri Oct 6 13:36:48 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 6 Oct 2017 13:36:48 +0000 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: Okay, you seem to be looking for an answer and there isn?t one. The release you are using has problems when it decided to walk the heap. The release you are using WILL NOT BE FIXED. Change your code, backport the fix, or move to a more modern release. Sorry, there is no other way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jqian at tibco.com Fri Oct 6 13:51:53 2017 From: jqian at tibco.com (Jason Qian) Date: Fri, 6 Oct 2017 09:51:53 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: Message-ID: Thanks, On Fri, Oct 6, 2017 at 9:36 AM, Salz, Rich wrote: > Okay, you seem to be looking for an answer and there isn?t one. > > > > The release you are using has problems when it decided to walk the heap. > The release you are using WILL NOT BE FIXED. > > > > Change your code, backport the fix, or move to a more modern release. > Sorry, there is no other way. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jqian at tibco.com Fri Oct 6 14:28:43 2017 From: jqian at tibco.com (Jason Qian) Date: Fri, 6 Oct 2017 10:28:43 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: <2F96B4B0-8BF8-48BC-8802-F17F1F928179@akamai.com> Message-ID: Hi Jeff, Checked https://rt.openssl.org/Ticket/Display.html?id=2100&user= guest&pass=guest and it seems exactly the same issue I have. I have moved to 1.0.1c. One question is where can I find the patch ? I have the built environment and I can build myself. Thanks for the help Jason On Thu, Oct 5, 2017 at 3:37 PM, Jeffrey Walton wrote: > On Thu, Oct 5, 2017 at 3:27 PM, Jason Qian via openssl-users > wrote: > > Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no > > change > > I believe it was fixed earlier than that. Also see > https://rt.openssl.org/Ticket/Display.html?id=2100&user=guest&pass=guest > > As Michael suggested, 0.9.8 is the biggest problem. You should > probably solve that problem first. > > Jeff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jqian at tibco.com Fri Oct 6 15:23:27 2017 From: jqian at tibco.com (Jason Qian) Date: Fri, 6 Oct 2017 11:23:27 -0400 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: <2F96B4B0-8BF8-48BC-8802-F17F1F928179@akamai.com> Message-ID: Hi Salz, I have built the 1.1.0f with vc10 ( have to move some header files) Is the OpenSSL 1.1.0f supported version ? Thanks Jason On Thu, Oct 5, 2017 at 3:31 PM, Salz, Rich wrote: > > - Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it > seems no change > > > > Sorry, then try 1.1.0 The HEAPWALK bug/issue is fixed there. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From delentef at gmail.com Fri Oct 6 15:26:31 2017 From: delentef at gmail.com (Fabrice Delente) Date: Fri, 6 Oct 2017 17:26:31 +0200 Subject: [openssl-users] ca md too weak Message-ID: Hello, Until two days ago I used OpenVPN to connect to my workplace, on a non-security sensitive tunnel (just for convenience). However, OpenSSL updated on my machine (Fedora 26), and now the certificate is rejected: Fri Oct 6 17:25:06 2017 OpenVPN 2.4.4 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017 Fri Oct 6 17:25:06 2017 library versions: OpenSSL 1.1.0f-fips 25 May 2017, LZO 2.08 Fri Oct 6 17:25:06 2017 OpenSSL: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak Fri Oct 6 17:25:06 2017 Cannot load certificate file lcs/delentef.crt Fri Oct 6 17:25:06 2017 Exiting due to fatal error What solutions are there to this problem? Can I configure OpenSSL to accept this certificate after all? Thanks. F. Delente From noloader at gmail.com Fri Oct 6 15:31:12 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 6 Oct 2017 11:31:12 -0400 Subject: [openssl-users] ca md too weak In-Reply-To: References: Message-ID: > Until two days ago I used OpenVPN to connect to my workplace, on a > non-security sensitive tunnel (just for convenience). > > However, OpenSSL updated on my machine (Fedora 26), and now the > certificate is rejected: > > ... > routines:SSL_CTX_use_certificate:ca md too weak > Fri Oct 6 17:25:06 2017 Cannot load certificate file lcs/delentef.crt > Fri Oct 6 17:25:06 2017 Exiting due to fatal error > > What solutions are there to this problem? Can I configure OpenSSL to > accept this certificate after all? https://fedoraproject.org/wiki/Changes/CryptoPolicy Jeff From janjust at nikhef.nl Fri Oct 6 15:49:28 2017 From: janjust at nikhef.nl (Jan Just Keijser) Date: Fri, 6 Oct 2017 17:49:28 +0200 Subject: [openssl-users] ca md too weak In-Reply-To: References: Message-ID: Hi, On 06/10/17 17:26, Fabrice Delente wrote: > Hello, > > Until two days ago I used OpenVPN to connect to my workplace, on a > non-security sensitive tunnel (just for convenience). > > However, OpenSSL updated on my machine (Fedora 26), and now the > certificate is rejected: > > Fri Oct 6 17:25:06 2017 OpenVPN 2.4.4 x86_64-redhat-linux-gnu [SSL > (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on > Sep 26 2017 > Fri Oct 6 17:25:06 2017 library versions: OpenSSL 1.1.0f-fips 25 May > 2017, LZO 2.08 > Fri Oct 6 17:25:06 2017 OpenSSL: error:140AB18E:SSL > routines:SSL_CTX_use_certificate:ca md too weak > Fri Oct 6 17:25:06 2017 Cannot load certificate file lcs/delentef.crt > Fri Oct 6 17:25:06 2017 Exiting due to fatal error > > What solutions are there to this problem? Can I configure OpenSSL to > accept this certificate after all? > > it's not openssl that changed, it's the way openvpn is built on Fedora: - openvpn 2.4.3 was built and linked against openssl 1.0 , which supports MD5 signed certs - openvpn 2.4.4 was built and linked against openssl 1.1, which does not Best solution: - upgrade your CA to use something that's actually secure Second best: - downgrade openvpn to 2.4.3 (and get openssl 1.0 support back). HTH, JJK From delentef at gmail.com Fri Oct 6 16:22:24 2017 From: delentef at gmail.com (Fabrice Delente) Date: Fri, 6 Oct 2017 18:22:24 +0200 Subject: [openssl-users] ca md too weak In-Reply-To: References: Message-ID: OK, I understand, thanks for your answer! I'll look into building openvpn 2.4.3 from source. F. Delente From noloader at gmail.com Fri Oct 6 16:28:01 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 6 Oct 2017 12:28:01 -0400 Subject: [openssl-users] ca md too weak In-Reply-To: References: Message-ID: On Fri, Oct 6, 2017 at 12:22 PM, Fabrice Delente wrote: > OK, I understand, thanks for your answer! I'll look into building > openvpn 2.4.3 from source. I believe you only have to set Fedora's security policy to allow MD5. That is covered in the Fedora wiki page you were provided. There's no need to download and build a new OpenSSL and OpenVPN. However, if you to take that path, then see https://stackoverflow.com/q/38985889/608639. Jeff From delentef at gmail.com Fri Oct 6 16:29:54 2017 From: delentef at gmail.com (Fabrice Delente) Date: Fri, 6 Oct 2017 18:29:54 +0200 Subject: [openssl-users] ca md too weak In-Reply-To: References: Message-ID: Thanks for your answer too, I had already seen this wiki page before posting but I didn't find in it any info on how to do that; I'll look into it again and try harder then. F. Delente From rsalz at akamai.com Fri Oct 6 18:46:03 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 6 Oct 2017 18:46:03 +0000 Subject: [openssl-users] DH_generate_key Hangs In-Reply-To: References: <2F96B4B0-8BF8-48BC-8802-F17F1F928179@akamai.com> Message-ID: 1.0.2 and 1.1.0, whatever the highest letter is, are the supported releases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Sun Oct 8 11:17:38 2017 From: aerowolf at gmail.com (Kyle Hamilton) Date: Sun, 8 Oct 2017 04:17:38 -0700 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: References: Message-ID: The way to handle this situation is simply to never enter SSL_read() if there isn't anything to read on the socket. select() or pselect() are your friends, here, because they'll tell you if there's data to read from the underlying file descriptor. I hope this helps! -Kyle H On Oct 5, 2017 02:58, "mahesh gs" wrote: > Hi All, > > I have query regarding the SSL_read on blocking socket. How to come out of > blocking SSL_read when we have to close the connection ? > > As per the documentation SSL_read will only return if there is any data or > an error occurred. > > "If the underlying BIO is *blocking*, SSL_read() will only return, *once > the read operation has been finished or an error occurred,* except when a > renegotiation take place, in which case a SSL_ERROR_WANT_READ may occur" > > I am trying following methods > > *method 1:* > > 1) Thread - 1 blocks in SSL_read > 2) Thread - 2 receive indication to stop the connection from application. > Call SSL_Shutdown() to unblock the SSL_read in thread - 1. But this is > dangerous as calling SSL_shutdown and SSL_read from different threads on > same context can lead to undefined behaviour. > > *method 2:* > > 1) Thread - 1 blocks in SSL_read > 2) Thread - 2 receive indication to stop the connection from application. > shutdown the underlying TCP socket using system command (shutdown > (socket_id, SHUT_WR)) that cause the SSL_read to unblock. > 3) Thread - 1 unwind and close the TCP socket (using close(socket_id)). > thread -1 cannot call SSL_Shutdown since the TCP socket is shutdown by > thread - 2 for write operation. As per my understanding this violates the > TLS standard because of not sending out the close notify handshake. > > How to ensure to come out of blocking SSL_read and initiate SSL_shutdown > from same thread? > > Thanks, > Mahesh G S > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shinelight at shininglightpro.com Sun Oct 8 13:48:37 2017 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Sun, 8 Oct 2017 06:48:37 -0700 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: References: Message-ID: On 10/8/2017 4:17 AM, Kyle Hamilton wrote: > The way to handle this situation is simply to never enter SSL_read() if > there isn't anything to read on the socket. select() or pselect() are your > friends, here, because they'll tell you if there's data to read from the > underlying file descriptor. > > I hope this helps! > > -Kyle H Since the OP is talking about blocking sockets, I'm going to reiterate something someone pointed out to me on this very list many years ago and save someone a LOT of headaches: select() should NEVER, EVER be used for blocking sockets. Just because select() returns any given descriptor doesn't mean that a call won't still block when working with blocking sockets. select() is for non-blocking descriptors ONLY. The amount of extra code involved for handling non-blocking sockets is actually quite minimal when a state engine is adopted. I'd love to see select() implementations raise an exception and kill the whole application off when passing it a blocking descriptor. Then we would discover how much broken software is floating around out there. Since I still see lots of recommendations for using select() with blocking descriptors and all of the official system-level documentation for select() is silent on this issue, I'm guessing a lot. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From michel.sales at free.fr Sun Oct 8 14:28:27 2017 From: michel.sales at free.fr (Michel) Date: Sun, 8 Oct 2017 16:28:27 +0200 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: References: Message-ID: <000601d34041$b5e60940$21b21bc0$@sales@free.fr> While I understand that using non-blocking descriptors is a better practice, I still do not see why select() should NEVER be used for blocking sockets (except when combined/interfered with the internal OpenSSL state machine or equivalent mechanism). Could you please elaborate or give an example ? Regards, Michel. From shinelight at shininglightpro.com Sun Oct 8 20:55:36 2017 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Sun, 8 Oct 2017 13:55:36 -0700 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: <000601d34041$b5e60940$21b21bc0$@sales@free.fr> References: <000601d34041$b5e60940$21b21bc0$@sales@free.fr> Message-ID: <1557ee7d-2696-ad88-0981-983c0d47a61e@shininglightpro.com> On 10/8/2017 7:28 AM, Michel wrote: > While I understand that using non-blocking descriptors is a better practice, > I still do not see why select() should NEVER be used for blocking sockets > (except when combined/interfered with the internal OpenSSL state machine or > equivalent mechanism). > > Could you please elaborate or give an example ? > > Regards, > > Michel. Example: You call select(), it returns the descriptor as readable, you pass it into SSL_read(), and SSL_read() blocks. You are worse off than before you used select() since you made the incorrect assumption that you could do something when select() returns and not have a blocking socket block. Just because select() says that something is readable (or writable) does not actually make it so. The function only makes sense for non-blocking descriptors. The use of select() with a blocking descriptor is always wrong. Non-blocking code is actually easier to implement than you think. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From michel.sales at free.fr Sun Oct 8 21:34:10 2017 From: michel.sales at free.fr (Michel) Date: Sun, 8 Oct 2017 23:34:10 +0200 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: <1557ee7d-2696-ad88-0981-983c0d47a61e@shininglightpro.com> References: <000601d34041$b5e60940$21b21bc0$@sales@free.fr> <1557ee7d-2696-ad88-0981-983c0d47a61e@shininglightpro.com> Message-ID: <000001d3407d$2e920ed0$8bb62c70$@sales@free.fr> Hi Thomas, I do not think that non-blocking code is hard to implement, but I am not still convinced there is not some kind of confusion here. Pardon me if I do not understand well your reasoning, but I just want to highlight that SSL_read() contract is not to return TCP data, but SSL/TLS data (if some are available), which is more work. As described in https://www.openssl.org/docs/man1.1.0/ssl/SSL_read.html, you may encounter cases where TCP data is available, but just contains TLS records with no usefull application data. Can this be what you experienced or I missed your point ? Regards, Michel -----Message d'origine----- De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Thomas J. Hruska Envoy??: dimanche 8 octobre 2017 22:56 ??: openssl-users at openssl.org Objet?: Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets On 10/8/2017 7:28 AM, Michel wrote: > While I understand that using non-blocking descriptors is a better > practice, I still do not see why select() should NEVER be used for > blocking sockets (except when combined/interfered with the internal > OpenSSL state machine or equivalent mechanism). > > Could you please elaborate or give an example ? > > Regards, > > Michel. Example: You call select(), it returns the descriptor as readable, you pass it into SSL_read(), and SSL_read() blocks. You are worse off than before you used select() since you made the incorrect assumption that you could do something when select() returns and not have a blocking socket block. Just because select() says that something is readable (or writable) does not actually make it so. The function only makes sense for non-blocking descriptors. The use of select() with a blocking descriptor is always wrong. Non-blocking code is actually easier to implement than you think. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From karl at denninger.net Sun Oct 8 21:37:17 2017 From: karl at denninger.net (karl at denninger.net) Date: Sun, 08 Oct 2017 16:37:17 -0500 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets Message-ID: <20171008213722.35F972997AC@denninger.net> In short ssl is not the same as a raw socket fd because of the intervening protocol. That's all.... ? Original Message ? From: michel.sales at free.fr Sent: October 8, 2017 4:34 PM To: openssl-users at openssl.org Reply-to: openssl-users at openssl.org Subject: Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets Hi Thomas, I do not think that non-blocking code is hard to implement, but I am not still convinced there is not some kind of confusion here. Pardon me if I do not understand well your reasoning, but I just want to highlight that SSL_read() contract is not to return TCP data, but SSL/TLS data (if some are available), which is more work. As described in https://www.openssl.org/docs/man1.1.0/ssl/SSL_read.html, you may encounter cases where TCP data is available, but just contains TLS records with no usefull application data. Can this be what you experienced or I missed your point ? Regards, Michel -----Message d'origine----- De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Thomas J. Hruska Envoy??: dimanche 8 octobre 2017 22:56 ??: openssl-users at openssl.org Objet?: Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets On 10/8/2017 7:28 AM, Michel wrote: > While I understand that using non-blocking descriptors is a better > practice, I still do not see why select() should NEVER be used for > blocking sockets (except when combined/interfered with the internal > OpenSSL state machine or equivalent mechanism). > > Could you please elaborate or give an example ? >?? > Regards, > > Michel. Example:? You call select(), it returns the descriptor as readable, you pass it into SSL_read(), and SSL_read() blocks.? You are worse off than before you used select() since you made the incorrect assumption that you could do something when select() returns and not have a blocking socket block. Just because select() says that something is readable (or writable) does not actually make it so.? The function only makes sense for non-blocking descriptors.? The use of select() with a blocking descriptor is always wrong. Non-blocking code is actually easier to implement than you think. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4557 bytes Desc: not available URL: From aerowolf at gmail.com Mon Oct 9 00:58:56 2017 From: aerowolf at gmail.com (Kyle Hamilton) Date: Sun, 8 Oct 2017 17:58:56 -0700 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: References: Message-ID: Do you have a reference to what should be done instead? My understanding of what happens with blocking sockets is that SSL_read() will return SSL_ERROR_WANT_READ if it needs additional data read from a socket that doesn't have it available (and will return SSL_ERROR_WANT_WRITE if it needs to write for a handful of reasons, but can't). I had thought that the appropriate response would be to add that descriptor to the appropriate set to query on the next call to select(), and then call the same function with the same parameters so the library can advance its state machine. write() and read() have the means to tell you how much data was written or read, and that's what you're supposed to use to keep blocking descriptors from hanging your application, I thought. -Kyle H On Sun, Oct 8, 2017 at 6:48 AM, Thomas J. Hruska wrote: > On 10/8/2017 4:17 AM, Kyle Hamilton wrote: >> >> The way to handle this situation is simply to never enter SSL_read() if >> there isn't anything to read on the socket. select() or pselect() are >> your >> friends, here, because they'll tell you if there's data to read from the >> underlying file descriptor. >> >> I hope this helps! >> >> -Kyle H > > > Since the OP is talking about blocking sockets, I'm going to reiterate > something someone pointed out to me on this very list many years ago and > save someone a LOT of headaches: > > select() should NEVER, EVER be used for blocking sockets. > > > Just because select() returns any given descriptor doesn't mean that a call > won't still block when working with blocking sockets. select() is for > non-blocking descriptors ONLY. The amount of extra code involved for > handling non-blocking sockets is actually quite minimal when a state engine > is adopted. > > I'd love to see select() implementations raise an exception and kill the > whole application off when passing it a blocking descriptor. Then we would > discover how much broken software is floating around out there. Since I > still see lots of recommendations for using select() with blocking > descriptors and all of the official system-level documentation for select() > is silent on this issue, I'm guessing a lot. > > -- > Thomas Hruska > Shining Light Productions > > Home of BMP2AVI and Win32 OpenSSL. > http://www.slproweb.com/ > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From aerowolf at gmail.com Mon Oct 9 01:06:21 2017 From: aerowolf at gmail.com (Kyle Hamilton) Date: Sun, 8 Oct 2017 18:06:21 -0700 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: References: Message-ID: Important caveat: SSL_read() and SSL_write() don't directly return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. Those values are returned by SSL_get_error(). I apologize for the misstatement. -Kyle H On Sun, Oct 8, 2017 at 5:58 PM, Kyle Hamilton wrote: > Do you have a reference to what should be done instead? > > My understanding of what happens with blocking sockets is that > SSL_read() will return SSL_ERROR_WANT_READ if it needs additional data > read from a socket that doesn't have it available (and will return > SSL_ERROR_WANT_WRITE if it needs to write for a handful of reasons, > but can't). I had thought that the appropriate response would be to > add that descriptor to the appropriate set to query on the next call > to select(), and then call the same function with the same parameters > so the library can advance its state machine. > > write() and read() have the means to tell you how much data was > written or read, and that's what you're supposed to use to keep > blocking descriptors from hanging your application, I thought. > > -Kyle H > > > On Sun, Oct 8, 2017 at 6:48 AM, Thomas J. Hruska > wrote: >> On 10/8/2017 4:17 AM, Kyle Hamilton wrote: >>> >>> The way to handle this situation is simply to never enter SSL_read() if >>> there isn't anything to read on the socket. select() or pselect() are >>> your >>> friends, here, because they'll tell you if there's data to read from the >>> underlying file descriptor. >>> >>> I hope this helps! >>> >>> -Kyle H >> >> >> Since the OP is talking about blocking sockets, I'm going to reiterate >> something someone pointed out to me on this very list many years ago and >> save someone a LOT of headaches: >> >> select() should NEVER, EVER be used for blocking sockets. >> >> >> Just because select() returns any given descriptor doesn't mean that a call >> won't still block when working with blocking sockets. select() is for >> non-blocking descriptors ONLY. The amount of extra code involved for >> handling non-blocking sockets is actually quite minimal when a state engine >> is adopted. >> >> I'd love to see select() implementations raise an exception and kill the >> whole application off when passing it a blocking descriptor. Then we would >> discover how much broken software is floating around out there. Since I >> still see lots of recommendations for using select() with blocking >> descriptors and all of the official system-level documentation for select() >> is silent on this issue, I'm guessing a lot. >> >> -- >> Thomas Hruska >> Shining Light Productions >> >> Home of BMP2AVI and Win32 OpenSSL. >> http://www.slproweb.com/ >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From shinelight at shininglightpro.com Mon Oct 9 03:38:48 2017 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Sun, 8 Oct 2017 20:38:48 -0700 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: References: Message-ID: <9b3d0929-f291-aed7-3e07-956c8b91bd7c@shininglightpro.com> On 10/8/2017 5:58 PM, Kyle Hamilton wrote: > Do you have a reference to what should be done instead? > > My understanding of what happens with blocking sockets is that > SSL_read() will return SSL_ERROR_WANT_READ if it needs additional data > read from a socket that doesn't have it available (and will return > SSL_ERROR_WANT_WRITE if it needs to write for a handful of reasons, > but can't). I had thought that the appropriate response would be to > add that descriptor to the appropriate set to query on the next call > to select(), and then call the same function with the same parameters > so the library can advance its state machine. > > write() and read() have the means to tell you how much data was > written or read, and that's what you're supposed to use to keep > blocking descriptors from hanging your application, I thought. > > -Kyle H With blocking sockets, you just loop back around and repeat the same call if either of those messages are returned by SSL_get_error(). No select() required. Blocking operations will block (aka "hang") your application until the operation completes. If you don't want that to happen, then that's what non-blocking descriptors are for. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From michel.sales at free.fr Mon Oct 9 08:32:21 2017 From: michel.sales at free.fr (Michel) Date: Mon, 9 Oct 2017 10:32:21 +0200 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: <9b3d0929-f291-aed7-3e07-956c8b91bd7c@shininglightpro.com> References: <9b3d0929-f291-aed7-3e07-956c8b91bd7c@shininglightpro.com> Message-ID: <000301d340d9$21283380$63789a80$@sales@free.fr> > With blocking sockets, you just loop back around and repeat the same call if either of those messages are returned by SSL_get_error(). No select() required. Yes, you have to repeat the same call, but select() is still usefull, especially with blocking sockets. Regards, Michel. From murugesh.pitchaiah at gmail.com Mon Oct 9 11:54:17 2017 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Mon, 9 Oct 2017 17:24:17 +0530 Subject: [openssl-users] Openssl FIPS 186-4 Patch In-Reply-To: <575911F4-C24A-4F0E-A4ED-7C042B0C3F79@akamai.com> References: <575911F4-C24A-4F0E-A4ED-7C042B0C3F79@akamai.com> Message-ID: Hi, Thanks for the comment. I know that openSSL is not 186-4 compliant. That is why I am looking for anybody have the patch for the same. I see there are some works in Fedora: http://pkgs.fedoraproject.org/cgit/rpms/openssl.git/tree/openssl-1.1.0-fips.patch Thanks, Murugesh P. On 10/6/17, Salz, Rich via openssl-users wrote: > ? This FIPS186-4 is not just about SHA. It basically about the key > generation parameters. Especially I am looking for RSA key generation > parameters wrt FIPS 186-4. > > I do not know how you got the opinion that OpenSSL has 186-4 support. It > does not. Perhaps other people have written patches. If you find them, ask > them to share with us ( > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From shinelight at shininglightpro.com Mon Oct 9 13:31:49 2017 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Mon, 9 Oct 2017 06:31:49 -0700 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: <000301d340d9$21283380$63789a80$@sales@free.fr> References: <9b3d0929-f291-aed7-3e07-956c8b91bd7c@shininglightpro.com> <000301d340d9$21283380$63789a80$@sales@free.fr> Message-ID: <335fabfe-e25c-aa1d-1f3d-7e6e4c423e92@shininglightpro.com> On 10/9/2017 1:32 AM, Michel wrote: >> With blocking sockets, you just loop back around and repeat the same call > if either of those messages are returned by SSL_get_error(). No select() > required. > > Yes, you have to repeat the same call, but select() is still usefull, > especially with blocking sockets. And leads to incorrect code and weird blocking scenarios. Been there, done that. You're using select() wrong. If you want to block, then block and don't try to hack around it. Otherwise use non-blocking. This common misunderstanding of select() is precisely why calling it with a blocking descriptor should trigger an exception that kills the application. Doing so would bring a quick end to a lot of bad code. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From jb-openssl at wisemo.com Mon Oct 9 14:29:25 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 9 Oct 2017 16:29:25 +0200 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: <335fabfe-e25c-aa1d-1f3d-7e6e4c423e92@shininglightpro.com> References: <9b3d0929-f291-aed7-3e07-956c8b91bd7c@shininglightpro.com> <000301d340d9$21283380$63789a80$@sales@free.fr> <335fabfe-e25c-aa1d-1f3d-7e6e4c423e92@shininglightpro.com> Message-ID: On 09/10/2017 15:31, Thomas J. Hruska wrote: > On 10/9/2017 1:32 AM, Michel wrote: >>> With blocking sockets, you just loop back around and repeat the same >>> call >> if either of those messages are returned by SSL_get_error(). No select() >> required. >> >> Yes, you have to repeat the same call, but select() is still usefull, >> especially with blocking sockets. > > And leads to incorrect code and weird blocking scenarios.? Been there, > done that.? You're using select() wrong.? If you want to block, then > block and don't try to hack around it.? Otherwise use non-blocking. > > This common misunderstanding of select() is precisely why calling it > with a blocking descriptor should trigger an exception that kills the > application.? Doing so would bring a quick end to a lot of bad code. > The system documentation (at least on Linux) isn't just silent about how select behaves with blocking sockets.? It is *explicitly* written to describe how it works with blocking sockets (but is mostly silent about non-blocking sockets). (My copy is marked as being from Linux man-pages project version 3.74). I suggest you find a good authoritative source for your claim that select() should not be used with blocking sockets. 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 shinelight at shininglightpro.com Mon Oct 9 14:43:17 2017 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Mon, 9 Oct 2017 07:43:17 -0700 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: References: <9b3d0929-f291-aed7-3e07-956c8b91bd7c@shininglightpro.com> <000301d340d9$21283380$63789a80$@sales@free.fr> <335fabfe-e25c-aa1d-1f3d-7e6e4c423e92@shininglightpro.com> Message-ID: <80a595e9-081e-1975-3bd5-44619f704194@shininglightpro.com> On 10/9/2017 7:29 AM, Jakob Bohm wrote: > I suggest you find a good authoritative source for your claim > that select() should not be used with blocking sockets. http://man7.org/linux/man-pages/man2/select.2.html Section BUGS: "Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block." Authoritative enough for you? -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From jb-openssl at wisemo.com Mon Oct 9 14:49:30 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 9 Oct 2017 16:49:30 +0200 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: <80a595e9-081e-1975-3bd5-44619f704194@shininglightpro.com> References: <9b3d0929-f291-aed7-3e07-956c8b91bd7c@shininglightpro.com> <000301d340d9$21283380$63789a80$@sales@free.fr> <335fabfe-e25c-aa1d-1f3d-7e6e4c423e92@shininglightpro.com> <80a595e9-081e-1975-3bd5-44619f704194@shininglightpro.com> Message-ID: <1ec31541-4283-77cd-69c3-eaaaaf7bcba2@wisemo.com> On 09/10/2017 16:43, Thomas J. Hruska wrote: > On 10/9/2017 7:29 AM, Jakob Bohm wrote: >> I suggest you find a good authoritative source for your claim >> that select() should not be used with blocking sockets. > > http://man7.org/linux/man-pages/man2/select.2.html > > Section BUGS: > > "Under Linux, select() may report a socket file descriptor as "ready > for reading", while nevertheless a subsequent read blocks. This could > for example happen when data has arrived but upon examination has > wrong checksum and is discarded.? There may be other circumstances in > which a file descriptor is spuriously reported as ready.? Thus it may > be safer to use O_NONBLOCK on sockets that should not block." > > > Authoritative enough for you? > That must be a recent change then.? But certainly that is a bug in Linux select, not in programs relying on the (long time) documented correct behavior. 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 michel.sales at free.fr Mon Oct 9 15:45:19 2017 From: michel.sales at free.fr (Michel) Date: Mon, 9 Oct 2017 17:45:19 +0200 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: <335fabfe-e25c-aa1d-1f3d-7e6e4c423e92@shininglightpro.com> References: <9b3d0929-f291-aed7-3e07-956c8b91bd7c@shininglightpro.com> <000301d340d9$21283380$63789a80$@sales@free.fr> <335fabfe-e25c-aa1d-1f3d-7e6e4c423e92@shininglightpro.com> Message-ID: <000c01d34115$9d7733f0$d8659bd0$@sales@free.fr> Hi Thomas, As mentioned previously, I do NOT "want to block" or "hack" with OpenSSL state machine. And again, I agree with you that non-blocking socket programming is best and more flexible. I just wanted to understand your point and it is now clear for me since I read the BUGS section of http://man7.org/linux/man-pages/man2/select.2.html. Thanks for this, I was not aware of that, I learned something today. :-) However I don't think this is a "common misunderstanding of select()" as it is a *BUG* [hopefully] of only select() under linux. Not a design implementation of *select() and friends* (pselect, poll, epoll, ...) on every other systems. And on this matter, I don't believe that code relying on interface documentation is *bad code* by nature, and - IMHO - a bug should be fixed rather than killing everything around (kind of terrorism programming ? ;-). Anyway, thanks to have shared your opinion and advices with me. Regards, Michel. -----Message d'origine----- De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Thomas J. Hruska Envoy??: lundi 9 octobre 2017 15:32 ??: openssl-users at openssl.org Objet?: Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets On 10/9/2017 1:32 AM, Michel wrote: >> With blocking sockets, you just loop back around and repeat the same >> call > if either of those messages are returned by SSL_get_error(). No > select() required. > > Yes, you have to repeat the same call, but select() is still usefull, > especially with blocking sockets. And leads to incorrect code and weird blocking scenarios. Been there, done that. You're using select() wrong. If you want to block, then block and don't try to hack around it. Otherwise use non-blocking. This common misunderstanding of select() is precisely why calling it with a blocking descriptor should trigger an exception that kills the application. Doing so would bring a quick end to a lot of bad code. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From shinelight at shininglightpro.com Mon Oct 9 15:47:16 2017 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Mon, 9 Oct 2017 08:47:16 -0700 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: <1ec31541-4283-77cd-69c3-eaaaaf7bcba2@wisemo.com> References: <9b3d0929-f291-aed7-3e07-956c8b91bd7c@shininglightpro.com> <000301d340d9$21283380$63789a80$@sales@free.fr> <335fabfe-e25c-aa1d-1f3d-7e6e4c423e92@shininglightpro.com> <80a595e9-081e-1975-3bd5-44619f704194@shininglightpro.com> <1ec31541-4283-77cd-69c3-eaaaaf7bcba2@wisemo.com> Message-ID: On 10/9/2017 7:49 AM, Jakob Bohm wrote: > On 09/10/2017 16:43, Thomas J. Hruska wrote: >> On 10/9/2017 7:29 AM, Jakob Bohm wrote: >>> I suggest you find a good authoritative source for your claim >>> that select() should not be used with blocking sockets. >> >> http://man7.org/linux/man-pages/man2/select.2.html >> >> Section BUGS: >> >> "Under Linux, select() may report a socket file descriptor as "ready >> for reading", while nevertheless a subsequent read blocks. This could >> for example happen when data has arrived but upon examination has >> wrong checksum and is discarded.? There may be other circumstances in >> which a file descriptor is spuriously reported as ready.? Thus it may >> be safer to use O_NONBLOCK on sockets that should not block." >> >> >> Authoritative enough for you? >> > That must be a recent change then.? But certainly that is a bug > in Linux select, not in programs relying on the (long time) > documented correct behavior. The OpenSSL layer over TCP/IP complicates matters more across ALL platforms: SSL_read() may need to write (and SSL_write() may need to read). Even if the socket has data to read according to select(), if the respective write end is full (or vice versa for SSL_write()), then the call WILL block when using blocking sockets. You can't resolve the above issue with select() or any other function UNLESS you switch to non-blocking socket descriptors. From that point, the only logical conclusion that can be drawn is that select() is for non-blocking I/O only. Then the documented "bug" in Linux becomes a misunderstanding of what select() is actually intended for across all platforms: Preventing spurious CPU usage for non-blocking I/O. select() is just a notification that MAYBE you can read or MAYBE you can write, but there is no guarantee of either succeeding. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From michel.sales at free.fr Mon Oct 9 16:08:52 2017 From: michel.sales at free.fr (Michel) Date: Mon, 9 Oct 2017 18:08:52 +0200 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: References: <9b3d0929-f291-aed7-3e07-956c8b91bd7c@shininglightpro.com> <000301d340d9$21283380$63789a80$@sales@free.fr> <335fabfe-e25c-aa1d-1f3d-7e6e4c423e92@shininglightpro.com> <80a595e9-081e-1975-3bd5-44619f704194@shininglightpro.com> <1ec31541-4283-77cd-69c3-eaaaaf7bcba2@wisemo.com> Message-ID: <000d01d34118$e78c79c0$b6a56d40$@sales@free.fr> [...] > From that point, the only logical conclusion that can be drawn is that select() is for non-blocking I/O only. [...] Ouahhh, it looks to me as an over-simplistic conclusion ! select() was not designed and written with future TLS state machine implementation in mind. But maybe I shoudn't relaunch a debate... :-) From meissner at suse.de Tue Oct 10 06:47:19 2017 From: meissner at suse.de (Marcus Meissner) Date: Tue, 10 Oct 2017 08:47:19 +0200 Subject: [openssl-users] Openssl FIPS 186-4 Patch In-Reply-To: References: <575911F4-C24A-4F0E-A4ED-7C042B0C3F79@akamai.com> Message-ID: <20171010064719.GC29138@suse.de> Hi, On Mon, Oct 09, 2017 at 05:24:17PM +0530, murugesh pitchaiah wrote: > Hi, > > Thanks for the comment. > > I know that openSSL is not 186-4 compliant. That is why I am looking > for anybody have the patch for the same. > > I see there are some works in Fedora: > http://pkgs.fedoraproject.org/cgit/rpms/openssl.git/tree/openssl-1.1.0-fips.patch Yes, the FIPS 140-2 patches done by Redhat provide a FIPS 186-3 or 186-4 enabled keygeneration. There are some small adjustments that could be merged back into the generic e.g. RSA key generation. Ciao, Marcus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Digital signature URL: From murugesh.pitchaiah at gmail.com Tue Oct 10 11:33:40 2017 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Tue, 10 Oct 2017 17:03:40 +0530 Subject: [openssl-users] Openssl FIPS 186-4 Patch In-Reply-To: <20171010064719.GC29138@suse.de> References: <575911F4-C24A-4F0E-A4ED-7C042B0C3F79@akamai.com> <20171010064719.GC29138@suse.de> Message-ID: Hi, That Redhat/Fedora patch is based on openssl library alone. But I am using the fips canister approach where i use both openssl and openssl-fips-ecp libraries. Though the redhat/fedora patch is OK, it is not straight forward portable to the canister model. Any idea of patches available for this kind of fips canister usage ? Thanks, Murugesh P. On 10/10/17, Marcus Meissner wrote: > Hi, > > On Mon, Oct 09, 2017 at 05:24:17PM +0530, murugesh pitchaiah wrote: >> Hi, >> >> Thanks for the comment. >> >> I know that openSSL is not 186-4 compliant. That is why I am looking >> for anybody have the patch for the same. >> >> I see there are some works in Fedora: >> http://pkgs.fedoraproject.org/cgit/rpms/openssl.git/tree/openssl-1.1.0-fips.patch > > Yes, the FIPS 140-2 patches done by Redhat provide a FIPS 186-3 or 186-4 > enabled > keygeneration. > > There are some small adjustments that could be merged back into the generic > e.g. RSA key generation. > > Ciao, Marcus > From jnovonj at gmail.com Tue Oct 10 15:40:42 2017 From: jnovonj at gmail.com (Jorge Novo) Date: Tue, 10 Oct 2017 17:40:42 +0200 Subject: [openssl-users] openssl.cnf asking Subject Alternative Names certificates. Message-ID: Hi everyone, As most of us know, the Google Chrome Navigator ask about Subject Alternative Name instead the Common Name. I want to distribute a little *openssl.cnf* file for creation the CSR files with my specific values and establish the Subject Alternative Name = Common Name. I want yo ask about the CN and assign this value to SAN. This is my beta *openssl.cnf* file: *Sorry for the comments in Spanish I do not how to set a variable (CN Variable) to assign to SAN value. *-------------------------------- 8< -------------------------------- 8< -----------------------------------*# # Este fichero genera los CSR de nuestros sistemas con los paremetros # acordados. # # openssl genrsa -aes256 -out www.rra.lan.key 2048 -config opensslMiCasa.cnf # # Establecemos un directorio de trabajo, el actual para ser exactos. dir = . [ req ] default_bits = 2048 # Size of keys default_keyfile = key.pem # name of generated keys default_md = sha256 # message digest algorithm string_mask = nombstr # permitted characters distinguished_name = req_distinguished_name req_extensions = v3_req [ req_distinguished_name ] # Variable name Prompt string #------------------------- ---------------------------------- 0.organizationName = Nombre de la Organizacion organizationalUnitName = Mi Casa [Desarrollo|Infraestructuras|Laboratorio] emailAddress = Cuenta de Correo emailAddress_max = 64 localityName = Localidad stateOrProvinceName = Comunidad Aut?noma countryName = ISO 3166-1 Codigo de Pa?s countryName_min = 2 countryName_max = 2 commonName = Common Name # Default values for the above, for consistency and less typing. # Variable name Value #------------------------ ------------------------------ 0.organizationName_default = Mi Casa organizationalUnitName_default = Mi Casa Infraestructuras localityName_default = Madrid stateOrProvinceName_default = Comunidad de Madrid countryName_default = ES [ v3_req ] basicConstraints = CA:FALSE subjectKeyIdentifier = hash subjectAltName = *-------------------------------- **>8 -------------------------------- >8 -----------------------------------* --- SALUDE3. http://www.rodeiroag.es/ http://soloeningles.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From security.veteran at gmail.com Tue Oct 10 19:25:01 2017 From: security.veteran at gmail.com (security veteran) Date: Tue, 10 Oct 2017 12:25:01 -0700 Subject: [openssl-users] Enable FIPS mode using OPENSSL_config() Message-ID: Hi All: My understand is by using OPENSSL_config(), we will be able to enable the FIPS mode globally on the system, is that correct? My question is, if we enable FIPS mode through configuration and using OPENSSL_config(), does it means for all the applications which link to OpenSSL library, the FIPS_mode_set() function will be invoked automatically (at some level), even if these application are not modified to invoke the FIPS_mode_set() by themselves? The reason I ask was mainly because I am evaluating how I should modify my server platform and applications in order to adapt FIPS capable OpenSSLlibrary into the platform. >From the previous suggestions seen in this forum, it looks like the best strategy is to only select few important applications to make them run under FIPS mode, and that way we only need to modify these applications to allow them invoke FIPS_mode_set(). My assumption is, for those applications which link to OpenSSL but are not FIPS aware, even if we run OPENSSL_config() to enable FIPS mode globally, they will still be running on non-FIPS mode and they won't be impacted or crash due to they are not FIPS compatible. Is my understanding correct? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Tue Oct 10 21:17:29 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 10 Oct 2017 21:17:29 +0000 Subject: [openssl-users] [ANN] M2Crypto 0.27.0 In-Reply-To: <20171005220734.GA15565@mitmanek.ceplovi.cz> References: <20171005220734.GA15565@mitmanek.ceplovi.cz> Message-ID: <85DE54AB-3906-43F6-800D-290849FA285F@ll.mit.edu> I have to report that this M2Crypto release is broken, as it cannot find OpenSSL installed in /opt/local (apologies for spamming multiple lists and people): /usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -pipe -Os -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/private/tmp/pip-build-lqb2R6/M2Crypto/SWIG -c SWIG/_m2crypto_wrap.c -o build/temp.macosx-10.12-x86_64-2.7/SWIG/_m2crypto_wrap.o -Wno-deprecated-declarations SWIG/_m2crypto_wrap.c:2894:9: warning: variable 'res' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] if (PyType_Ready(tp) < 0) ^~~~~~~~~~~~~~~~~~~~ SWIG/_m2crypto_wrap.c:2918:10: note: uninitialized use occurs here return res; ^~~ SWIG/_m2crypto_wrap.c:2894:5: note: remove the 'if' if its condition is always false if (PyType_Ready(tp) < 0) ^~~~~~~~~~~~~~~~~~~~~~~~~ SWIG/_m2crypto_wrap.c:2875:10: note: initialize the variable 'res' to silence this warning int res; ^ = 0 SWIG/_m2crypto_wrap.c:3554:10: fatal error: 'openssl/err.h' file not found #include ^~~~~~~~~~~~~~~ 1 warning and 1 error generated. error: command '/usr/bin/clang' failed with exit status 1 ---------------------------------------- Command "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -u -c "import setuptools, tokenize;__file__='/private/tmp/pip-build-lqb2R6/M2Crypto/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-VYOp3p-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /private/tmp/pip-build-lqb2R6/M2Crypto/ -- Regards, Uri Blumenthal On 10/5/17, 18:06, "openssl-users on behalf of Mat?j Cepl" wrote: M2Crypto is the most complete Python wrapper for OpenSSL featuring RSA, DSA, DH, EC, HMACs, message digests, symmetric ciphers; SSL functionality to implement clients and servers; HTTPS extensions to Python?s httplib, urllib, and xmlrpclib; unforgeable HMAC?ing AuthCookies for web session management; FTP/TLS client and server; S/MIME. M2Crypto can also be used to provide SSL for Twisted. Smartcards supported through the Engine interface. This is another less earth-shattering release (after 0.26.2 which brought us OpenSSL 1.1.0 compatbility), one more step towards Python 3 compatibility nirvana, still more cleanups and accumulated bug fixes, which could be resolved before the big python3 branch is merged. The release is available on https://pypi.python.org/pypi/M2Crypto/ and all communication with the maintainer (that?s me) should go to https://gitlab.com/m2crypto/m2crypto. Talking about the python3 branch, ALL TESTS PASS on all Pythons from 2.6, 2.7, 3.3 to 3.6!!! Now is the time to test, help with review, and complain about whatever is wrong! I will still keep API stable, but changes are relatively large, so this is your opportunity to suggest whatever substantial thing you don't like with M2Crypto. I may not make it happen in 0.28 (which I expect to be Py3k-compatible release), but for settling the dust down and cleanup I prepare already 0.29, which should include yet more acummulated merge requests and bugfixes, this time ones which should be better served with python 3 layer already happening. Happy hacking! Mat?j -- https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Quod fuimus, estis; quod sumus, vos eritis. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From paul.greene.va at gmail.com Wed Oct 11 02:57:07 2017 From: paul.greene.va at gmail.com (Paul Greene) Date: Tue, 10 Oct 2017 22:57:07 -0400 Subject: [openssl-users] troubleshooting ssl errors Message-ID: Hello All, I'm trying to establish a connection between two servers for the purpose of data sharing. On my end, these are the version numbers of everything I'm using RHEL 7.4 wget 1.14 openssl 1.0.2k-fips Not sure what's on the other end, other than it is a Linux server When I run the connectivity tests, these are the errors I'm getting - you can see the commands run, the output that comes back (hostname and ip address are obfuscated) Any suggestions? PG [root at hostname ~]# wget https://domain.name.com:8443 --secure-protocol=SSLv3 --debug DEBUG output created by Wget 1.14 on linux-gnu. URI encoding = ?UTF-8? Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8) Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8) --2017-10-10 22:20:20-- https://domain.name.com:8443/ Resolving domain.name.com (domain.name.com)... Caching domain.name.com => Connecting to domain.name.com (domain.name.com)||:8443... connected. Created socket 3. Releasing 0x000000000186e340 (new refcount 1). Initiating SSL handshake. SSL handshake failed. Closed fd 3 Unable to establish SSL connection. [root at hostname ~]# curl -k https://domain.name.com:8443 -insecure -v * Couldn't find host domain.name.com in the .netrc file; using defaults * About to connect() to domain.name.com port 8443 (#0) * Trying ... * Connected to domain.name.com () port 8443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * NSS error -5938 (PR_END_OF_FILE_ERROR) * Encountered end of file * Closing connection 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcepl at cepl.eu Wed Oct 11 06:12:38 2017 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl) Date: Wed, 11 Oct 2017 08:12:38 +0200 Subject: [openssl-users] OpenSSL on side [Was: Re: [ANN] M2Crypto 0.27.0] References: <20171005220734.GA15565@mitmanek.ceplovi.cz> <85DE54AB-3906-43F6-800D-290849FA285F@ll.mit.edu> Message-ID: On 2017-10-10, 21:17 GMT, Blumenthal, Uri - 0553 - MITLL wrote: > I have to report that this M2Crypto release is broken, as it > cannot find OpenSSL installed in /opt/local (apologies for > spamming multiple lists and people): Feel free to file a ticket on https://gitlab.com/m2crypto/m2crypto/issues , no need to use mailing lists for issue tracker, when we have a proper one. I work on M2Crypto right now, so I see them immediately. To your real problem: does --openssl set to /opt/local help? If you run python setup.py clean build --openssl /opt/local what happens? What is the generated swig line (which version you use?), and what are the two compiler lines (one for compilation, other for linking)? > /usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -pipe I have made so far all my testing with GCC (on Linux, there are some users on Mac OS X, so I guess CLang should work as well, but I have never tested it myself). > -Os -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes > -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 > -I/private/tmp/pip-build-lqb2R6/M2Crypto/SWIG -c > SWIG/_m2crypto_wrap.c -o > build/temp.macosx-10.12-x86_64-2.7/SWIG/_m2crypto_wrap.o > -Wno-deprecated-declarations > SWIG/_m2crypto_wrap.c:2894:9: warning: variable 'res' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] > if (PyType_Ready(tp) < 0) > ^~~~~~~~~~~~~~~~~~~~ > SWIG/_m2crypto_wrap.c:2918:10: note: uninitialized use occurs here > return res; > ^~~ > SWIG/_m2crypto_wrap.c:2894:5: note: remove the 'if' if its condition is always false > if (PyType_Ready(tp) < 0) > ^~~~~~~~~~~~~~~~~~~~~~~~~ > SWIG/_m2crypto_wrap.c:2875:10: note: initialize the variable 'res' to silence this warning > int res; > ^ > = 0 Just to note that this particular piece of code is generated completely by swig, I have nothing to do with it. > SWIG/_m2crypto_wrap.c:3554:10: fatal error: 'openssl/err.h' file not found > #include > ^~~~~~~~~~~~~~~ > 1 warning and 1 error generated. > error: command '/usr/bin/clang' failed with exit status 1 Where do you actually have err.h? Manually settings CFLAGS and LDFLAGS should be followed by seutp.py, it can help as a workaround, but my dream is that plain settings of --openssl parameter should be sufficient. Feel free to continue here, on on the issue tracker. Best, Mat?j Cepl -- http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Love doesn't just sit there, like a stone; it has to be made, like bread, remade all the time, made new. -- Ursula K. LeGuin From wouter.verhelst at fedict.be Wed Oct 11 07:25:56 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Wed, 11 Oct 2017 09:25:56 +0200 Subject: [openssl-users] Graceful shutdown of TLS connection for blocking sockets In-Reply-To: <1557ee7d-2696-ad88-0981-983c0d47a61e@shininglightpro.com> References: <000601d34041$b5e60940$21b21bc0$@sales@free.fr> <1557ee7d-2696-ad88-0981-983c0d47a61e@shininglightpro.com> Message-ID: On 08-10-17 22:55, Thomas J. Hruska wrote: > On 10/8/2017 7:28 AM, Michel wrote: >> While I understand that using non-blocking descriptors is a better >> practice, >> I still do not see why select() should NEVER be used for blocking sockets >> (except when combined/interfered with the internal OpenSSL state >> machine or >> equivalent mechanism). >> >> Could you please elaborate or give an example ? >> ? Regards, >> >> Michel. > > Example:? You call select(), it returns the descriptor as readable, you > pass it into SSL_read(), and SSL_read() blocks.? You are worse off than > before you used select() since you made the incorrect assumption that > you could do something when select() returns and not have a blocking > socket block. > > Just because select() says that something is readable (or writable) does > not actually make it so. Er, yes it does. Perhaps not as much as you wanted, but yes there will be something there. > The function only makes sense for non-blocking > descriptors.? The use of select() with a blocking descriptor is always > wrong. Er, no it isn't. Example: you select() on all your file descriptors in your main thread. When select() tells you that one of them is ready to read, you fire off a message to a thread pool and have one of the worker threads in that thread pool (eventually) handle reading your data in a blocking manner. Once the thread from the thread pool has finished reading, it will start work on another file descriptor. This allows you to serve more clients than you have threads, so allows to avoid overloading your server, but since you use blocking I/O on your file descriptors you can get away with not having the extra complexity of the state machine that blocking I/O requires. You can't implement that properly without doing select() on blocking file descriptors, however. > Non-blocking code is actually easier to implement than you think. It isn't too hard, to write, that's true. It's more difficult to reason about and to avoid bugs with, however (and for thread pools, you just use a library -- e.g., GThreadPool from libglib). -- Wouter Verhelst From wallboy at wallboy.ca Wed Oct 11 08:55:01 2017 From: wallboy at wallboy.ca (Wallboy) Date: Wed, 11 Oct 2017 01:55:01 -0700 (MST) Subject: [openssl-users] RSA PSS Sigalgs for 1.1.0 Message-ID: <1507712101848-0.post@n7.nabble.com> Hi, Browsers in the last year or so have added support for the the new TLS 1.3 RSA-PSS Signature Algorithms (0x0804, 0x0805,...). I see them added in 1.1.1 dev and they even work without TLS 1.3 enabled in the build. Is there any plan to add support for them to 1.1.0? Thanks, Adam -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From matt at openssl.org Wed Oct 11 09:10:33 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Oct 2017 10:10:33 +0100 Subject: [openssl-users] troubleshooting ssl errors In-Reply-To: References: Message-ID: On 11/10/17 03:57, Paul Greene wrote: > [root at hostname ~]# wget https://domain.name.com:8443 > --secure-protocol=SSLv3 --debug > DEBUG output created by Wget 1.14 on linux-gnu. The "--secure-protocol=SSLv3" bit looks suspect. According to the wget man page this forces only SSLv3 to be negotiated. If the server doesn't support it (which is common) then you're out of luck. SSLv3 is very old, insecure and generally should not be used. Setting "--secure-protocol" to "auto" (the default) would be a better choice. Matt From levitte at openssl.org Wed Oct 11 10:54:04 2017 From: levitte at openssl.org (Richard Levitte) Date: Wed, 11 Oct 2017 12:54:04 +0200 (CEST) Subject: [openssl-users] OpenSSL on side In-Reply-To: References: <20171005220734.GA15565@mitmanek.ceplovi.cz> <85DE54AB-3906-43F6-800D-290849FA285F@ll.mit.edu> Message-ID: <20171011.125404.1762288522687727499.levitte@openssl.org> I got curious and decided to take a look, and well, it appears setup.py has issues. I posted an issue in gitlab about it: https://gitlab.com/m2crypto/m2crypto/issues/184 In message on Wed, 11 Oct 2017 08:12:38 +0200, Mat?j Cepl said: mcepl> On 2017-10-10, 21:17 GMT, Blumenthal, Uri - 0553 - MITLL wrote: mcepl> > I have to report that this M2Crypto release is broken, as it mcepl> > cannot find OpenSSL installed in /opt/local (apologies for mcepl> > spamming multiple lists and people): mcepl> mcepl> Feel free to file a ticket on mcepl> https://gitlab.com/m2crypto/m2crypto/issues , no need to use mcepl> mailing lists for issue tracker, when we have a proper one. mcepl> I work on M2Crypto right now, so I see them immediately. mcepl> mcepl> To your real problem: does --openssl set to /opt/local help? If mcepl> you run mcepl> mcepl> python setup.py clean build --openssl /opt/local mcepl> mcepl> what happens? What is the generated swig line (which version you mcepl> use?), and what are the two compiler lines (one for compilation, mcepl> other for linking)? mcepl> mcepl> > /usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -pipe mcepl> mcepl> I have made so far all my testing with GCC (on Linux, there are mcepl> some users on Mac OS X, so I guess CLang should work as well, mcepl> but I have never tested it myself). mcepl> mcepl> > -Os -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes mcepl> > -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 mcepl> > -I/private/tmp/pip-build-lqb2R6/M2Crypto/SWIG -c mcepl> > SWIG/_m2crypto_wrap.c -o mcepl> > build/temp.macosx-10.12-x86_64-2.7/SWIG/_m2crypto_wrap.o mcepl> > -Wno-deprecated-declarations mcepl> > SWIG/_m2crypto_wrap.c:2894:9: warning: variable 'res' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] mcepl> > if (PyType_Ready(tp) < 0) mcepl> > ^~~~~~~~~~~~~~~~~~~~ mcepl> > SWIG/_m2crypto_wrap.c:2918:10: note: uninitialized use occurs here mcepl> > return res; mcepl> > ^~~ mcepl> > SWIG/_m2crypto_wrap.c:2894:5: note: remove the 'if' if its condition is always false mcepl> > if (PyType_Ready(tp) < 0) mcepl> > ^~~~~~~~~~~~~~~~~~~~~~~~~ mcepl> > SWIG/_m2crypto_wrap.c:2875:10: note: initialize the variable 'res' to silence this warning mcepl> > int res; mcepl> > ^ mcepl> > = 0 mcepl> mcepl> Just to note that this particular piece of code is generated mcepl> completely by swig, I have nothing to do with it. mcepl> mcepl> > SWIG/_m2crypto_wrap.c:3554:10: fatal error: 'openssl/err.h' file not found mcepl> > #include mcepl> > ^~~~~~~~~~~~~~~ mcepl> > 1 warning and 1 error generated. mcepl> > error: command '/usr/bin/clang' failed with exit status 1 mcepl> mcepl> Where do you actually have err.h? Manually settings CFLAGS and mcepl> LDFLAGS should be followed by seutp.py, it can help as mcepl> a workaround, but my dream is that plain settings of --openssl mcepl> parameter should be sufficient. mcepl> mcepl> Feel free to continue here, on on the issue tracker. mcepl> mcepl> Best, mcepl> mcepl> Mat?j Cepl mcepl> -- mcepl> http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz mcepl> GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 mcepl> mcepl> Love doesn't just sit there, like a stone; it has to be made, mcepl> like bread, remade all the time, made new. mcepl> -- Ursula K. LeGuin mcepl> mcepl> From uri at ll.mit.edu Wed Oct 11 11:35:07 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 11 Oct 2017 11:35:07 +0000 Subject: [openssl-users] OpenSSL on side In-Reply-To: <20171011.125404.1762288522687727499.levitte@openssl.org> References: <20171005220734.GA15565@mitmanek.ceplovi.cz> <85DE54AB-3906-43F6-800D-290849FA285F@ll.mit.edu> <20171011.125404.1762288522687727499.levitte@openssl.org> Message-ID: And it is not installable via PIP, though to me being placed on pypi site suggested that it should be (that's how I tried to install it). Regards, Uri Sent from my iPhone > On Oct 11, 2017, at 06:55, Richard Levitte wrote: > > I got curious and decided to take a look, and well, it appears > setup.py has issues. I posted an issue in gitlab about it: > > https://gitlab.com/m2crypto/m2crypto/issues/184 > > In message on Wed, 11 Oct 2017 08:12:38 +0200, Mat?j Cepl said: > > mcepl> On 2017-10-10, 21:17 GMT, Blumenthal, Uri - 0553 - MITLL wrote: > mcepl> > I have to report that this M2Crypto release is broken, as it > mcepl> > cannot find OpenSSL installed in /opt/local (apologies for > mcepl> > spamming multiple lists and people): > mcepl> > mcepl> Feel free to file a ticket on > mcepl> https://gitlab.com/m2crypto/m2crypto/issues , no need to use > mcepl> mailing lists for issue tracker, when we have a proper one. > mcepl> I work on M2Crypto right now, so I see them immediately. > mcepl> > mcepl> To your real problem: does --openssl set to /opt/local help? If > mcepl> you run > mcepl> > mcepl> python setup.py clean build --openssl /opt/local > mcepl> > mcepl> what happens? What is the generated swig line (which version you > mcepl> use?), and what are the two compiler lines (one for compilation, > mcepl> other for linking)? > mcepl> > mcepl> > /usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -pipe > mcepl> > mcepl> I have made so far all my testing with GCC (on Linux, there are > mcepl> some users on Mac OS X, so I guess CLang should work as well, > mcepl> but I have never tested it myself). > mcepl> > mcepl> > -Os -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes > mcepl> > -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 > mcepl> > -I/private/tmp/pip-build-lqb2R6/M2Crypto/SWIG -c > mcepl> > SWIG/_m2crypto_wrap.c -o > mcepl> > build/temp.macosx-10.12-x86_64-2.7/SWIG/_m2crypto_wrap.o > mcepl> > -Wno-deprecated-declarations > mcepl> > SWIG/_m2crypto_wrap.c:2894:9: warning: variable 'res' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] > mcepl> > if (PyType_Ready(tp) < 0) > mcepl> > ^~~~~~~~~~~~~~~~~~~~ > mcepl> > SWIG/_m2crypto_wrap.c:2918:10: note: uninitialized use occurs here > mcepl> > return res; > mcepl> > ^~~ > mcepl> > SWIG/_m2crypto_wrap.c:2894:5: note: remove the 'if' if its condition is always false > mcepl> > if (PyType_Ready(tp) < 0) > mcepl> > ^~~~~~~~~~~~~~~~~~~~~~~~~ > mcepl> > SWIG/_m2crypto_wrap.c:2875:10: note: initialize the variable 'res' to silence this warning > mcepl> > int res; > mcepl> > ^ > mcepl> > = 0 > mcepl> > mcepl> Just to note that this particular piece of code is generated > mcepl> completely by swig, I have nothing to do with it. > mcepl> > mcepl> > SWIG/_m2crypto_wrap.c:3554:10: fatal error: 'openssl/err.h' file not found > mcepl> > #include > mcepl> > ^~~~~~~~~~~~~~~ > mcepl> > 1 warning and 1 error generated. > mcepl> > error: command '/usr/bin/clang' failed with exit status 1 > mcepl> > mcepl> Where do you actually have err.h? Manually settings CFLAGS and > mcepl> LDFLAGS should be followed by seutp.py, it can help as > mcepl> a workaround, but my dream is that plain settings of --openssl > mcepl> parameter should be sufficient. > mcepl> > mcepl> Feel free to continue here, on on the issue tracker. > mcepl> > mcepl> Best, > mcepl> > mcepl> Mat?j Cepl > mcepl> -- > mcepl> http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz > mcepl> GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 > mcepl> > mcepl> Love doesn't just sit there, like a stone; it has to be made, > mcepl> like bread, remade all the time, made new. > mcepl> -- Ursula K. LeGuin > mcepl> > mcepl> > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5801 bytes Desc: not available URL: From steve at openssl.org Wed Oct 11 11:50:15 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 11 Oct 2017 11:50:15 +0000 Subject: [openssl-users] RSA PSS Sigalgs for 1.1.0 In-Reply-To: <1507712101848-0.post@n7.nabble.com> References: <1507712101848-0.post@n7.nabble.com> Message-ID: <20171011115015.GA30757@openssl.org> On Wed, Oct 11, 2017, Wallboy wrote: > > Browsers in the last year or so have added support for the the new TLS 1.3 > RSA-PSS Signature Algorithms (0x0804, 0x0805,...). > > I see them added in 1.1.1 dev and they even work without TLS 1.3 enabled in > the build. Is there any plan to add support for them to 1.1.0? > No: it's a new feature and we don't add new features to stable branches. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From mcepl at cepl.eu Wed Oct 11 11:58:46 2017 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl) Date: Wed, 11 Oct 2017 13:58:46 +0200 Subject: [openssl-users] OpenSSL on side References: <20171005220734.GA15565@mitmanek.ceplovi.cz> <85DE54AB-3906-43F6-800D-290849FA285F@ll.mit.edu> <20171011.125404.1762288522687727499.levitte@openssl.org> Message-ID: On 2017-10-11, 11:35 GMT, Blumenthal, Uri - 0553 - MITLL wrote: > And it is not installable via PIP, though to me being placed > on pypi site suggested that it should be (that's how I tried > to install it). What?s needed for package to be pip installable? I would think that if python setup.py build install works (and it should), then pip should do somehow the right thing? Best, Mat?j -- http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 If we rise from prayer better persons, our prayers have been answered. -- a Jewish prayer book From uri at ll.mit.edu Wed Oct 11 12:11:32 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 11 Oct 2017 12:11:32 +0000 Subject: [openssl-users] OpenSSL on side In-Reply-To: References: <20171005220734.GA15565@mitmanek.ceplovi.cz> <85DE54AB-3906-43F6-800D-290849FA285F@ll.mit.edu> <20171011.125404.1762288522687727499.levitte@openssl.org> Message-ID: <25C17316-8A1C-4B62-A9CE-E1A4CE48D58A@ll.mit.edu> Unfortunately, not quite. Being pip-installable means to the majority of users that the package in question can be installed via, e.g., pip install M2Crypto Regards, Uri Sent from my iPhone > On Oct 11, 2017, at 08:01, Mat?j Cepl wrote: > >> On 2017-10-11, 11:35 GMT, Blumenthal, Uri - 0553 - MITLL wrote: >> And it is not installable via PIP, though to me being placed >> on pypi site suggested that it should be (that's how I tried >> to install it). > > What?s needed for package to be pip installable? I would think > that if > > python setup.py build install > > works (and it should), then pip should do somehow the right > thing? > > Best, > > Mat?j > -- > http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz > GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 > > If we rise from prayer better persons, our prayers have been > answered. > -- a Jewish prayer book > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5801 bytes Desc: not available URL: From paul.greene.va at gmail.com Wed Oct 11 13:27:33 2017 From: paul.greene.va at gmail.com (Paul Greene) Date: Wed, 11 Oct 2017 09:27:33 -0400 Subject: [openssl-users] troubleshooting ssl errors In-Reply-To: References: Message-ID: Thanks for the response Matt. The SSL 3 switch was one of many that were tried just for the sake of testing. I tried a few other switches, but am getting the same results. I did a tcpdump of the attempted connection, and you can see that the initial connection is established, but the connection is immediately dropped after that. We've been try to determine if this is an openssl issue (misconfiguration, incompatibility, or whatever), a wget issue, or a network issue somewhere along the path between the two servers. My support end had me try the "no-check-certificate" option to remove the certificate on my server from the equation. It always fails after trying to initialize the SSL handshake [root at hostname ~]# wget https://domain.name.com:8443 --debug DEBUG output created by Wget 1.14 on linux-gnu. URI encoding = ?UTF-8? Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8) Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8) --2017-10-11 08:45:19-- https://domain.name.com:8443/ Resolving domain.name.com (domain.name.com)... Caching domain.name.com => Connecting to domain.name.com (domain.name.com)||:8443... connected. Created socket 3. Releasing 0x0000000002744320 (new refcount 1). Initiating SSL handshake. SSL handshake failed. Closed fd 3 Unable to establish SSL connection. wget https://domain.name.com:8443 --no-check-certificate --debug [root at hostname ~]# wget https://domain.name.com:8443 --no-check-certificate --debug DEBUG output created by Wget 1.14 on linux-gnu. URI encoding = ?UTF-8? Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8) Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8) --2017-10-11 08:49:26-- https://domain.name.com:8443/ Resolving domain.name.com (domain.name.com)... Caching domain.name.com => Connecting to domain.name.com (domain.name.com)||:8443... connected. Created socket 3. Releasing 0x00000000017b0340 (new refcount 1). Initiating SSL handshake. SSL handshake failed. Closed fd 3 Unable to establish SSL connection. On Wed, Oct 11, 2017 at 5:10 AM, Matt Caswell wrote: > > > On 11/10/17 03:57, Paul Greene wrote: > > [root at hostname ~]# wget https://domain.name.com:8443 > > --secure-protocol=SSLv3 --debug > > DEBUG output created by Wget 1.14 on linux-gnu. > > The "--secure-protocol=SSLv3" bit looks suspect. According to the wget > man page this forces only SSLv3 to be negotiated. If the server doesn't > support it (which is common) then you're out of luck. SSLv3 is very old, > insecure and generally should not be used. Setting "--secure-protocol" > to "auto" (the default) would be a better choice. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcepl at cepl.eu Wed Oct 11 15:23:38 2017 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl) Date: Wed, 11 Oct 2017 17:23:38 +0200 Subject: [openssl-users] OpenSSL on side References: <20171005220734.GA15565@mitmanek.ceplovi.cz> <85DE54AB-3906-43F6-800D-290849FA285F@ll.mit.edu> <20171011.125404.1762288522687727499.levitte@openssl.org> <25C17316-8A1C-4B62-A9CE-E1A4CE48D58A@ll.mit.edu> Message-ID: On 2017-10-11, 12:11 GMT, Blumenthal, Uri - 0553 - MITLL wrote: > Unfortunately, not quite. Being pip-installable means to the > majority of users that the package in question can be > installed via, e.g., > > pip install M2Crypto I understand that, my question was whether you know how to make package with working python setup.py build to be pip-installable. Thanks, Mat?j -- http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 I love deadlines. I like the whooshing sound they make as they fly by. -- Douglas Adams, The Salmon of Doubt From smadwin at adobe.com Wed Oct 11 17:43:17 2017 From: smadwin at adobe.com (Steven Madwin) Date: Wed, 11 Oct 2017 17:43:17 +0000 Subject: [openssl-users] OCSP Response Signed using RSASSA-PSS Message-ID: First, I know the caveat about ONLY use the OpenSSL OCSP Server for test purposes. With that out of the way. Is there any known plan on the horizon, when using the ocsp server, to allow the OCSP response to be signed using the RSASSA-PSS signature algorithm? Thanks for any and all insight, Steve Madwin Steven Madwin Software QA Engineer Adobe Systems Incorporated 345 Park Avenue, MS-W15 San Jose, CA 95110-2704 USA Phone: 408.536.4343 Fax: 408.536.6024 Steven.Madwin at adobe.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1200 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5451 bytes Desc: not available URL: From uri at ll.mit.edu Wed Oct 11 23:59:16 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 11 Oct 2017 23:59:16 +0000 Subject: [openssl-users] OpenSSL on side In-Reply-To: References: <20171005220734.GA15565@mitmanek.ceplovi.cz> <85DE54AB-3906-43F6-800D-290849FA285F@ll.mit.edu> <20171011.125404.1762288522687727499.levitte@openssl.org> <25C17316-8A1C-4B62-A9CE-E1A4CE48D58A@ll.mit.edu> Message-ID: <572EDD6B-9540-4309-984E-0B65E822F544@ll.mit.edu> The only thing I can think of is making sure that inside the setup.py CFLAGS are set properly, including appropriate -I/opt/local/include and whatever else... Regards, Uri Sent from my iPhone > On Oct 11, 2017, at 12:03, Mat?j Cepl wrote: > >> On 2017-10-11, 12:11 GMT, Blumenthal, Uri - 0553 - MITLL wrote: >> Unfortunately, not quite. Being pip-installable means to the >> majority of users that the package in question can be >> installed via, e.g., >> >> pip install M2Crypto > > I understand that, my question was whether you know how to make > package with working python setup.py build to be > pip-installable. > > Thanks, > > Mat?j > -- > http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz > GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 > > I love deadlines. I like the whooshing sound they make as they > fly by. > -- Douglas Adams, The Salmon of Doubt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5801 bytes Desc: not available URL: From lists at rustichelli.net Fri Oct 13 10:03:44 2017 From: lists at rustichelli.net (lists) Date: Fri, 13 Oct 2017 12:03:44 +0200 Subject: [openssl-users] openssl.cnf asking Subject Alternative Names certificates. In-Reply-To: References: Message-ID: <30be5956-76d0-9282-9307-0d6b4f52b405@rustichelli.net> On 10/10/2017 05:40 PM, Jorge Novo wrote: > Hi everyone, > > ? As most of us know, the Google Chrome Navigator ask about Subject > Alternative Name instead the Common Name. > > I want to distribute a little /openssl.cnf/ file for creation the CSR > files with my specific values and establish the Subject Alternative > Name = Common Name. I want yo ask about the CN and assign this value > to SAN. > > This is my beta /openssl.cnf/ file: > > *Sorry for the comments in Spanish > > I do not how to set a variable (CN Variable) to assign to SAN value. > / > / In my limited knowledge, you can't copy the CN name into the SAN in the configuration. Obvious yet clumsy workaround is to have a shell script ask for the FQDN, set a shell variable with the CN value and then recall the ENV variable from inside openssl.cnf, or you can have the script dynamically write/edit opessl.cnf with the user-entered value. > /-------------------------------- 8< -------------------------------- > 8< ----------------------------------- > /# > # Este fichero genera los CSR de nuestros sistemas con los paremetros > # acordados. > # > # openssl genrsa -aes256 -out www.rra.lan.key 2048 -config > opensslMiCasa.cnf > # > > # Establecemos un directorio de trabajo, el actual para ser exactos. > > dir ? ? ? ? ? ? ? ? ? ? ? ? ? ? = . > > [ req ] > default_bits ? ? ? ? ? ? ? ? ? ?= 2048 ? ?# Size of keys > default_keyfile ? ? ? ? ? ? ? ? = key.pem ? ? # name of generated keys > default_md ? ? ? ? ? ? ? ? ? ? ?= sha256 ? ?# message digest algorithm > string_mask ? ? ? ? ? ? ? ? ? ? = nombstr ? ? # permitted characters > distinguished_name ? ? ? ? ? ? ?= req_distinguished_name > req_extensions ? ? ? ? ? ? ? ? ?= v3_req > > [ req_distinguished_name ] > # Variable name ? ? ? ? ? ? ? ? ? ? ? ? Prompt string > #------------------------- ?---------------------------------- > 0.organizationName ? ? ? ? ? ? ?= Nombre de la Organizacion > organizationalUnitName ? ? ? ? ?= Mi Casa > [Desarrollo|Infraestructuras|Laboratorio] > emailAddress ? ? ? ? ? ? ? ? ? ?= Cuenta de Correo > emailAddress_max ? ? ? ? ? ? ? ?= 64 > localityName ? ? ? ? ? ? ? ? ? ?= Localidad > stateOrProvinceName ? ? ? ? ? ? = Comunidad Aut?noma > countryName ? ? ? ? ? ? ? ? ? ? = ISO 3166-1 Codigo de Pa?s > countryName_min ? ? ? ? ? ? ? ? = 2 > countryName_max ? ? ? ? ? ? ? ? = 2 > commonName ? ? ? ? ? ? ? ? ? ? ?= Common Name > > # Default values for the above, for consistency and less typing. > # Variable name ? ? ? ? ? ? ? ? ? ? ? ? Value > #------------------------ ------------------------------ > 0.organizationName_default ? ? ?= Mi Casa > organizationalUnitName_default ?= Mi Casa Infraestructuras > localityName_default ? ? ? ? ? ?= Madrid > stateOrProvinceName_default ? ? = Comunidad de Madrid > countryName_default ? ? ? ? ? ? = ES > > [ v3_req ] > basicConstraints ? ? ? ? ? ? ? ?= CA:FALSE > subjectKeyIdentifier ? ? ? ? ? ?= hash > subjectAltName ? ? ? ? ? ? ? ? ?= > //-------------------------------- //////>8// > -------------------------------- >8 -----------------------------------// -------------- next part -------------- An HTML attachment was scrubbed... URL: From satyakishore09 at gmail.com Fri Oct 13 11:05:00 2017 From: satyakishore09 at gmail.com (kishore) Date: Fri, 13 Oct 2017 16:35:00 +0530 Subject: [openssl-users] Unable to generate privatekey with 128bit salt Message-ID: Hi, I'm trying to generate a private key to use in fips mode with BC as provider for my application. I tried below command to do the same, *./openssl genrsa -out aes256sha12048.key -aes256 2048 -S E1F53135E559C253* but when try to load the key using BouncyCastle code, it throws *"Error salt must be at least 128 bits"* I'm a novice, can someone help me with this. ~Kishore -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnovonj at gmail.com Fri Oct 13 11:30:20 2017 From: jnovonj at gmail.com (Jorge Novo) Date: Fri, 13 Oct 2017 13:30:20 +0200 Subject: [openssl-users] openssl.cnf asking Subject Alternative Names certificates. In-Reply-To: <30be5956-76d0-9282-9307-0d6b4f52b405@rustichelli.net> References: <30be5956-76d0-9282-9307-0d6b4f52b405@rustichelli.net> Message-ID: Hi, On 13 October 2017 at 12:03, lists wrote: > On 10/10/2017 05:40 PM, Jorge Novo wrote: > > As most of us know, the Google Chrome Navigator ask about Subject > Alternative Name instead the Common Name. > > I want to distribute a little *openssl.cnf* file for creation the CSR > files with my specific values and establish the Subject Alternative Name = > Common Name. I want yo ask about the CN and assign this value to SAN. > > This is my beta *openssl.cnf* file: > > *Sorry for the comments in Spanish > > I do not how to set a variable (CN Variable) to assign to SAN value. > > > In my limited knowledge, you can't copy the CN name into the SAN in the > configuration. > Obvious yet clumsy workaround is to have a shell script ask for the FQDN, > set a shell variable with the CN value and then recall the ENV variable > from inside openssl.cnf, or you can have the script dynamically write/edit > opessl.cnf with the user-entered value. > This is correct, it does not exist any configuration to copy the CN to SNA or vice versa, although it is weird because, in fact it exists, a configuration to copy the SMA email address from the distinguished name. This can be done with these settings subjectAltName=email:copy or subjectAltName=email:move. With move I can not confirm it. https://www.openssl.org/docs/man1.1.0/apps/x509v3_config.html _Subject Alternative Name_ [...] The email option include a special 'copy' value. This will automatically include any email addresses contained in the certificate subject name in the extension. [...] My solution for this was: # export Cert_Name=www.micasa.local # openssl req -new -keyout $Cert_Name.key -out $Cert_Name.csr -config opensslMiCasa.cnf # unset $Cert_Name --- SALUDE3. http://www.rodeiroag.es/ http://soloeningles.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Fri Oct 13 17:04:29 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 13 Oct 2017 17:04:29 +0000 Subject: [openssl-users] Unable to generate privatekey with 128bit salt In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of kishore > Sent: Friday, October 13, 2017 07:05 >./openssl genrsa -out aes256sha12048.key -aes256 2048? -S E1F53135E559C253 Using what version of OpenSSL? Running on what platform? Please include basic, essential information in your question. Don't make us guess. > but when try to load the key using BouncyCastle code, it throws? > "Error salt must be at least 128 bits" The version of the openssl utility (1.0.2j) I'm running doesn't list a -S parameter in its help output, and I don't see one in genrsa.c, but there is one in enc.c, so maybe the genrsa command supports it. Though when I tried your command line, the key I got was encrypted with a salt (IV, really) that didn't appear to be related in any way to the value given with -S. In any case, though, the value you're passing for -S is only 64 bits. 64 is less than 128. Have you tried omitting the -S option? You should get a key encrypted with an IV of the appropriate length (128 bits) for AES-CBC-256. What does the PEM header - particularly the DEK-Info line - in the generated key file say? -- Michael Wojcik Distinguished Engineer, Micro Focus From grace.priscilla at gmail.com Tue Oct 17 08:21:50 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Tue, 17 Oct 2017 13:51:50 +0530 Subject: [openssl-users] Query on API availability for openssl versions Message-ID: Hi All, 1) The below APIs used to set the maximum and minimum versions are available in 1.1.0f version of OPENSSL. int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version); int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, int version); int SSL_set_min_proto_version(SSL *ssl, int version); int SSL_set_max_proto_version(SSL *ssl, int version); Do you have the same in any of the 1.0.2x threads or plan to have it in any later versions. We don't see it available in 1.0.2k or 1.0.2l versions. Kindly update us on the same. 2) There are a set of APIs to set/get security level wherein each level supports a set of cipher suites. Is there something available in OPENSSL wherein I can get the level and set it when I provide a cipher suite. We have a case where we give the user a provision to provide his own list of cipher suites and we need to set the appropriate level in the API so that we support it for the connections. Kindly provide your comments. Thanks, Grace -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 17 08:55:21 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 17 Oct 2017 09:55:21 +0100 Subject: [openssl-users] Query on API availability for openssl versions In-Reply-To: References: Message-ID: On 17/10/17 09:21, Grace Priscilla Jero wrote: > Hi All, > > 1) > The below APIs used to set the maximum and minimum versions are > available in 1.1.0f version of OPENSSL. > > ?int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version); > ?int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, int version); > ?int SSL_set_min_proto_version(SSL *ssl, int version); > ?int SSL_set_max_proto_version(SSL *ssl, int version); > > ?Do you have the same in any of the 1.0.2x threads or plan to have it in > any later versions. We don't see it available in 1.0.2k or 1.0.2l > versions. Kindly update us on the same. These APIs were first introduced into 1.1.0, and we intend to continue to support them moving forward in future versions. However they will not be backported to the 1.0.2 branch. We do not add new features to a stable branch. In 1.0.2 you must use the options SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 via the SSL_CTX_set_options() or SSL_set_options() functions. > > 2) > There are a set of APIs to set/get security level wherein each level > supports a set of cipher suites. Is there something available in OPENSSL > wherein I can get the level and set it when I provide a cipher suite. > We have a case where we give the user a provision to provide his own > list of cipher suites and we need to set the appropriate level in the > API so that we support it for the connections. Kindly provide your comments. You can set the security level via the cipher string using the special cipher string command "@SECLEVEL". For example to set all default ciphersuites at security level 2 or above you can use: "DEFAULT:@SECLEVEL=2" Matt From grace.priscilla at gmail.com Tue Oct 17 09:01:37 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Tue, 17 Oct 2017 14:31:37 +0530 Subject: [openssl-users] Query on API availability for openssl versions In-Reply-To: References: Message-ID: Thank you Matt for the quick response. For "2," does it mean that every cipher suite can operate in multiple levels? I thought that there were specific set of cipher suites operating in each of the levels. Thanks, Grace On Tue, Oct 17, 2017 at 2:25 PM, Matt Caswell wrote: > > > On 17/10/17 09:21, Grace Priscilla Jero wrote: > > Hi All, > > > > 1) > > The below APIs used to set the maximum and minimum versions are > > available in 1.1.0f version of OPENSSL. > > > > int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version); > > int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, int version); > > int SSL_set_min_proto_version(SSL *ssl, int version); > > int SSL_set_max_proto_version(SSL *ssl, int version); > > > > Do you have the same in any of the 1.0.2x threads or plan to have it in > > any later versions. We don't see it available in 1.0.2k or 1.0.2l > > versions. Kindly update us on the same. > > These APIs were first introduced into 1.1.0, and we intend to continue > to support them moving forward in future versions. However they will not > be backported to the 1.0.2 branch. We do not add new features to a > stable branch. > > In 1.0.2 you must use the options SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, > SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 via the SSL_CTX_set_options() or > SSL_set_options() functions. > > > > > > 2) > > There are a set of APIs to set/get security level wherein each level > > supports a set of cipher suites. Is there something available in OPENSSL > > wherein I can get the level and set it when I provide a cipher suite. > > We have a case where we give the user a provision to provide his own > > list of cipher suites and we need to set the appropriate level in the > > API so that we support it for the connections. Kindly provide your > comments. > > You can set the security level via the cipher string using the special > cipher string command "@SECLEVEL". For example to set all default > ciphersuites at security level 2 or above you can use: > > "DEFAULT:@SECLEVEL=2" > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Oct 17 09:13:04 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 17 Oct 2017 11:13:04 +0200 Subject: [openssl-users] Query on API availability for openssl versions In-Reply-To: References: Message-ID: The security levels are simply a classification of the cipher suites by quality.? Typically one would select all ciphers above a certain level. Most cipher suites work with all protocol levels >= a certain level, with SSL2 (dead) and TLS1.3 (future) being exceptions. Selecting something like "TLS1.1" in the cipher suite list simply selects those cipher suites that were new in TLS1.1, it does not actually select the TLS1.1 protocol. On 17/10/2017 11:01, Grace Priscilla Jero wrote: > Thank you Matt for the quick response. > For "2," does it mean that every cipher suite can operate in multiple > levels? > I thought that there were specific set of cipher suites operating in > each of the levels. > > Thanks, > Grace > > On Tue, Oct 17, 2017 at 2:25 PM, Matt Caswell > wrote: > > > > On 17/10/17 09:21, Grace Priscilla Jero wrote: > > Hi All, > > > > 1) > > The below APIs used to set the maximum and minimum versions are > > available in 1.1.0f version of OPENSSL. > > > > ?int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version); > > ?int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, int version); > > ?int SSL_set_min_proto_version(SSL *ssl, int version); > > ?int SSL_set_max_proto_version(SSL *ssl, int version); > > > > ?Do you have the same in any of the 1.0.2x threads or plan to > have it in > > any later versions. We don't see it available in 1.0.2k or 1.0.2l > > versions. Kindly update us on the same. > > These APIs were first introduced into 1.1.0, and we intend to continue > to support them moving forward in future versions. However they > will not > be backported to the 1.0.2 branch. We do not add new features to a > stable branch. > > In 1.0.2 you must use the options SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, > SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 via the > SSL_CTX_set_options() or > SSL_set_options() functions. > > > > > > 2) > > There are a set of APIs to set/get security level wherein each level > > supports a set of cipher suites. Is there something available in > OPENSSL > > wherein I can get the level and set it when I provide a cipher > suite. > > We have a case where we give the user a provision to provide his own > > list of cipher suites and we need to set the appropriate level > in the > > API so that we support it for the connections. Kindly provide > your comments. > > You can set the security level via the cipher string using the special > cipher string command "@SECLEVEL". For example to set all default > ciphersuites at security level 2 or above you can use: > > "DEFAULT:@SECLEVEL=2" > -- Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 This message is only for its intended recipient, delete if misaddressed. WiseMo - Remote Service Management for PCs, Phones and Embedded Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From matt at openssl.org Tue Oct 17 09:20:40 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 17 Oct 2017 10:20:40 +0100 Subject: [openssl-users] Query on API availability for openssl versions In-Reply-To: References: Message-ID: <74c0b3fb-e676-7690-e6da-d60793586ae5@openssl.org> On 17/10/17 10:01, Grace Priscilla Jero wrote: > Thank you Matt for the quick response. > For "2," does it mean that every cipher suite can operate in multiple > levels?? > I thought that there were specific set of cipher suites operating in > each of the levels. Not quite. The security levels look at the amount of security you can expect from all the algorithms in a ciphersuite. I dug out this description I had in a document (not checked to see if this is completely current (it was written a couple of years ago while 1.1.0 was still in development), but you get the idea): ? Level 0: No restrictions ? Level 1: 80 bits of security. Encryption algorithms with less than 80 security bits will be excluded, as will RSA, DSA and DH keys shorter than 1024 bits and ECC keys less than 160 bits in length. Also prohibited is any ciphersuite based on MD5 for its MAC. ? Level 2: 112 bits of security. Encryption algorithms with less than 112 security bits will be excluded, as will RSA, DSA and DH keys shorter than 2048 bits and ECC keys less than 224 bits in length. Additionally MD5 based MACs, SSLv3 and compression are prohibited. ? Level 3: 128 bits of security. Encryption algorithms with less than 128 security bits will be excluded, as will RSA, DSA and DH keys shorter than 3072 bits and ECC keys less than 256 bits in length. Additionally MD5, SSLv3, TLSv1.0, compression and session tickets are prohibited. ? Level 4: 192 bits of security. Encryption algorithms with less than 192 security bits will be excluded, as will RSA, DSA and DH keys shorter than 7680 bits and ECC keys less than 384 bits in length. Additionally MD5 or SHA1 based MACs, SSLv3, TLSv1.0, TLSv1.1, compression and session tickets are prohibited. ? Level 5: 256 bits of security. Encryption algorithms with less than 256 security bits will be excluded, as will RSA, DSA and DH keys shorter than 15360 bits and ECC keys less than 512 bits in length. Additionally MD5 or SHA1 based MACs, SSLv3, TLSv1.0, TLSv1.1, compression and session tickets are prohibited. This may mean that an individual ciphersuite is excluded completely by a security level, or it might mean it just has restrictions on the key lengths that are acceptable to use with it. Matt > > Thanks, > Grace > > On Tue, Oct 17, 2017 at 2:25 PM, Matt Caswell > wrote: > > > > On 17/10/17 09:21, Grace Priscilla Jero wrote: > > Hi All, > > > > 1) > > The below APIs used to set the maximum and minimum versions are > > available in 1.1.0f version of OPENSSL. > > > > ?int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version); > > ?int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, int version); > > ?int SSL_set_min_proto_version(SSL *ssl, int version); > > ?int SSL_set_max_proto_version(SSL *ssl, int version); > > > > ?Do you have the same in any of the 1.0.2x threads or plan to have it in > > any later versions. We don't see it available in 1.0.2k or 1.0.2l > > versions. Kindly update us on the same. > > These APIs were first introduced into 1.1.0, and we intend to continue > to support them moving forward in future versions. However they will not > be backported to the 1.0.2 branch. We do not add new features to a > stable branch. > > In 1.0.2 you must use the options SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, > SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 via the SSL_CTX_set_options() or > SSL_set_options() functions. > > > > > > 2) > > There are a set of APIs to set/get security level wherein each level > > supports a set of cipher suites. Is there something available in OPENSSL > > wherein I can get the level and set it when I provide a cipher suite. > > We have a case where we give the user a provision to provide his own > > list of cipher suites and we need to set the appropriate level in the > > API so that we support it for the connections. Kindly provide your comments. > > You can set the security level via the cipher string using the special > cipher string command "@SECLEVEL". For example to set all default > ciphersuites at security level 2 or above you can use: > > "DEFAULT:@SECLEVEL=2" > > Matt > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From manjunathsm1 at gmail.com Tue Oct 17 09:46:00 2017 From: manjunathsm1 at gmail.com (Manjunath SM) Date: Tue, 17 Oct 2017 15:16:00 +0530 Subject: [openssl-users] DSA2048 support in openssl-fips-2.0.14. Message-ID: Hi All, Am using openssl-fips-2.0.14 at server side on top of openssl1.0.2K. Server is operating in FIPS mode(fips mode enabled thru FIPS_mode_set). Created DSA2048 host key at server which is running in FIPS mode, With this configuration when am trying to do SSH from ssh client am getting below error. =========================================================== The authenticity of host '135.249.23.182 (135.249.23.182)' can't be established but keys of different type are already known for this host. DSA key fingerprint is 31:75:2c:96:ac:9c:11:f8:3b:39:0b:86:ba:88:51:02. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '135.249.23.182' (DSA) to the list of known hosts. *ssh_dss_verify: remaining bytes in signature 24key_verify failed for server_host_key* ======================================================== SSH client version is OpenSSH_6.4p1, OpenSSL 1.0.1e-fips 11 Feb 2013 In FIPS use guide doI see, DSA 2048 is supported. Does any one faced similar issue ?If so pls share the findings. -- -- Regards Manju -- ?Take care of the earth and she will take care of you.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From adimallikarjunareddy at gmail.com Tue Oct 17 13:39:56 2017 From: adimallikarjunareddy at gmail.com (Adi Mallikarjuna Reddy V) Date: Tue, 17 Oct 2017 06:39:56 -0700 Subject: [openssl-users] Issue with freeing X509 Message-ID: Hi, If I have an X509 object and is created using PEM_read_bio_X509_AUX(), then Can I free X509 right after the completion of PEM_read_bio_X509_AUX()? BIO *cert_bio = BIO_new(BIO_s_mem()); X509 *cert = X509_new(); BIO_puts(cert_bio, cert_str.c_str()); cert = PEM_read_bio_X509_AUX(cert_bio, &cert, NULL, NULL); if ( (cert != NULL) && SSL_CTX_use_certificate(ctx, cert) < 1) { SSL_CTX_free(ctx); return NULL; } if(cert_bio !=NULL) { BIO_free(cert_bio); } if(cert != NULL) { X509_free(cert); //is it needed? } Thanks Adi -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Tue Oct 17 15:41:55 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 17 Oct 2017 10:41:55 -0500 Subject: [openssl-users] Issue with freeing X509 In-Reply-To: References: Message-ID: <3d226fbc-82b0-6f07-c7e0-c0e3c4262402@akamai.com> On 10/17/2017 08:39 AM, Adi Mallikarjuna Reddy V wrote: > Hi, > > If I have an?X509 object and is created using?PEM_read_bio_X509_AUX(), > then Can I free X509 right after the completion > of?PEM_read_bio_X509_AUX()? > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?BIO *cert_bio = BIO_new(BIO_s_mem()); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? X509 *cert = X509_new(); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? BIO_puts(cert_bio, cert_str.c_str()); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cert = PEM_read_bio_X509_AUX(cert_bio, > &cert, NULL, NULL); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if ( (cert != NULL) && > SSL_CTX_use_certificate(ctx, cert) < 1) { > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SSL_CTX_free(ctx); Yes. -Ben > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? return NULL; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? } > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if(cert_bio !=NULL) { > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? BIO_free(cert_bio); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? } > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if(cert != NULL) { > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? X509_free(cert); //is it needed? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? } > > > Thanks > Adi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adimallikarjunareddy at gmail.com Tue Oct 17 16:08:17 2017 From: adimallikarjunareddy at gmail.com (Adi Mallikarjuna Reddy V) Date: Tue, 17 Oct 2017 16:08:17 +0000 Subject: [openssl-users] Issue with freeing X509 In-Reply-To: <3d226fbc-82b0-6f07-c7e0-c0e3c4262402@akamai.com> References: <3d226fbc-82b0-6f07-c7e0-c0e3c4262402@akamai.com> Message-ID: Forgot to mention that the ssl_ctx is going to be used by another thread later. When I do x509_free, the handshake doesn?t finish. I see a crash in ssl_accept. Thanks Adi On Tue, Oct 17, 2017 at 8:41 AM Benjamin Kaduk wrote: > On 10/17/2017 08:39 AM, Adi Mallikarjuna Reddy V wrote: > > Hi, > > If I have an X509 object and is created using PEM_read_bio_X509_AUX(), > then Can I free X509 right after the completion of PEM_read_bio_X509_AUX()? > > BIO *cert_bio = BIO_new(BIO_s_mem()); > X509 *cert = X509_new(); > BIO_puts(cert_bio, cert_str.c_str()); > cert = PEM_read_bio_X509_AUX(cert_bio, > &cert, NULL, NULL); > if ( (cert != NULL) && > SSL_CTX_use_certificate(ctx, cert) < 1) { > SSL_CTX_free(ctx); > > > Yes. > > -Ben > > > return NULL; > } > > if(cert_bio !=NULL) { > BIO_free(cert_bio); > } > if(cert != NULL) { > X509_free(cert); //is it needed? > } > > > Thanks > Adi > > > > -- Sent from Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Tue Oct 17 16:21:01 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 17 Oct 2017 11:21:01 -0500 Subject: [openssl-users] Issue with freeing X509 In-Reply-To: References: <3d226fbc-82b0-6f07-c7e0-c0e3c4262402@akamai.com> Message-ID: <9f23fb56-a19c-c7cc-d595-584fc2732eec@akamai.com> You only asked about freeing the X509, which is safe in this situation. It is not safe to free the SSL_CTX if you want to use it again later -- remove this SSL_CTX_free(ctx) call and put one in your program's cleanup instead. -Ben On 10/17/2017 11:08 AM, Adi Mallikarjuna Reddy V wrote: > Forgot to mention that the ssl_ctx is going to be used by another > thread later. When I do x509_free, the handshake doesn?t finish. > > I see a crash in ssl_accept. > > Thanks? > Adi > > On Tue, Oct 17, 2017 at 8:41 AM Benjamin Kaduk > wrote: > > On 10/17/2017 08:39 AM, Adi Mallikarjuna Reddy V wrote: >> Hi, >> >> If I have an?X509 object and is created >> using?PEM_read_bio_X509_AUX(), then Can I free X509 right after >> the completion of?PEM_read_bio_X509_AUX()? >> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?BIO *cert_bio = BIO_new(BIO_s_mem()); >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? X509 *cert = X509_new(); >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? BIO_puts(cert_bio, cert_str.c_str()); >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cert = >> PEM_read_bio_X509_AUX(cert_bio, &cert, NULL, NULL); >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if ( (cert != NULL) && >> SSL_CTX_use_certificate(ctx, cert) < 1) { >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SSL_CTX_free(ctx); > > Yes. > > -Ben > > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? return NULL; >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? } >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if(cert_bio !=NULL) { >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? BIO_free(cert_bio); >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? } >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if(cert != NULL) { >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? X509_free(cert); //is it >> needed? >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? } >> >> >> Thanks >> Adi >> >> > > -- > Sent from Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From adimallikarjunareddy at gmail.com Tue Oct 17 16:27:05 2017 From: adimallikarjunareddy at gmail.com (Adi Mallikarjuna Reddy V) Date: Tue, 17 Oct 2017 16:27:05 +0000 Subject: [openssl-users] Issue with freeing X509 In-Reply-To: <9f23fb56-a19c-c7cc-d595-584fc2732eec@akamai.com> References: <3d226fbc-82b0-6f07-c7e0-c0e3c4262402@akamai.com> <9f23fb56-a19c-c7cc-d595-584fc2732eec@akamai.com> Message-ID: I am only worried about the following line. SSL_CTX_use_certificate(ctx, cert) After this line is it safe to free cert object while ctx is still used later on? Thanks Adi On Tue, Oct 17, 2017 at 9:21 AM Benjamin Kaduk wrote: > You only asked about freeing the X509, which is safe in this situation. > > It is not safe to free the SSL_CTX if you want to use it again later -- > remove this SSL_CTX_free(ctx) call and put one in your program's cleanup > instead. > > -Ben > > On 10/17/2017 11:08 AM, Adi Mallikarjuna Reddy V wrote: > > Forgot to mention that the ssl_ctx is going to be used by another thread > later. When I do x509_free, the handshake doesn?t finish. > > I see a crash in ssl_accept. > > Thanks > Adi > > On Tue, Oct 17, 2017 at 8:41 AM Benjamin Kaduk wrote: > >> On 10/17/2017 08:39 AM, Adi Mallikarjuna Reddy V wrote: >> >> Hi, >> >> If I have an X509 object and is created using PEM_read_bio_X509_AUX(), >> then Can I free X509 right after the completion of PEM_read_bio_X509_AUX()? >> >> BIO *cert_bio = BIO_new(BIO_s_mem()); >> X509 *cert = X509_new(); >> BIO_puts(cert_bio, cert_str.c_str()); >> cert = PEM_read_bio_X509_AUX(cert_bio, >> &cert, NULL, NULL); >> if ( (cert != NULL) && >> SSL_CTX_use_certificate(ctx, cert) < 1) { >> SSL_CTX_free(ctx); >> >> >> Yes. >> >> -Ben >> >> >> return NULL; >> } >> >> if(cert_bio !=NULL) { >> BIO_free(cert_bio); >> } >> if(cert != NULL) { >> X509_free(cert); //is it needed? >> } >> >> >> Thanks >> Adi >> >> >> >> -- > Sent from Mobile > > > -- Sent from Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Tue Oct 17 16:50:04 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 17 Oct 2017 11:50:04 -0500 Subject: [openssl-users] Issue with freeing X509 In-Reply-To: References: <3d226fbc-82b0-6f07-c7e0-c0e3c4262402@akamai.com> <9f23fb56-a19c-c7cc-d595-584fc2732eec@akamai.com> Message-ID: <9e9be436-d02c-0fde-0688-98a183fdb26b@akamai.com> On 10/17/2017 11:27 AM, Adi Mallikarjuna Reddy V wrote: >> I am only worried about the following line.? >> >> SSL_CTX_use_certificate(ctx, cert) >> >> After this line is it safe to free cert object while ctx is still >> used later on? >> SSL_CTX_use_certificate(ctx, cert), on successful return, takes an additional reference on the supplied |cert| argument to account for the pointer in |ctx|.? Thus, the caller of SSL_CTX_use_certificate() can safely call X509_free(cert) to release the caller's local reference, while the |ctx| retains a pointer to |cert|. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From adimallikarjunareddy at gmail.com Tue Oct 17 17:32:23 2017 From: adimallikarjunareddy at gmail.com (Adi Mallikarjuna Reddy V) Date: Tue, 17 Oct 2017 10:32:23 -0700 Subject: [openssl-users] Issue with freeing X509 In-Reply-To: <9e9be436-d02c-0fde-0688-98a183fdb26b@akamai.com> References: <3d226fbc-82b0-6f07-c7e0-c0e3c4262402@akamai.com> <9f23fb56-a19c-c7cc-d595-584fc2732eec@akamai.com> <9e9be436-d02c-0fde-0688-98a183fdb26b@akamai.com> Message-ID: Is this documented some where? Also is the same true - with SSL_CTX_use_PrivateKey(ctx, evp_pkey) ? where I can free evp_pkey with EVP_PKEY_free()? Thanks Adi On Tue, Oct 17, 2017 at 9:50 AM, Benjamin Kaduk wrote: > On 10/17/2017 11:27 AM, Adi Mallikarjuna Reddy V wrote: > > I am only worried about the following line. > > SSL_CTX_use_certificate(ctx, cert) > > After this line is it safe to free cert object while ctx is still used > later on? > > > SSL_CTX_use_certificate(ctx, cert), on successful return, takes an > additional reference on the supplied |cert| argument to account for the > pointer in |ctx|. Thus, the caller of SSL_CTX_use_certificate() can safely > call X509_free(cert) to release the caller's local reference, while the > |ctx| retains a pointer to |cert|. > > -Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Tue Oct 17 18:37:02 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 17 Oct 2017 13:37:02 -0500 Subject: [openssl-users] Issue with freeing X509 In-Reply-To: References: <3d226fbc-82b0-6f07-c7e0-c0e3c4262402@akamai.com> <9f23fb56-a19c-c7cc-d595-584fc2732eec@akamai.com> <9e9be436-d02c-0fde-0688-98a183fdb26b@akamai.com> Message-ID: <214ee802-81a0-9a4f-17e8-1dd8f72c6542@akamai.com> I thought this had become documented recently (i.e., in master only, not even in 1.1.0), but can't find any evidence of such documentation. SSL_CTX_use_PrivateKey() takes a reference on its pkey argument in the same way as SSL_CTX_use_certificate(); it is safe for the local code to free its local copy. -Ben On 10/17/2017 12:32 PM, Adi Mallikarjuna Reddy V wrote: > Is this documented some where?? > > Also is the same true - with SSL_CTX_use_PrivateKey(ctx, evp_pkey) ? > where I can free evp_pkey with?EVP_PKEY_free()? > > > Thanks > Adi > > On Tue, Oct 17, 2017 at 9:50 AM, Benjamin Kaduk > wrote: > > On 10/17/2017 11:27 AM, Adi Mallikarjuna Reddy V wrote: >>> I am only worried about the following line.? >>> >>> SSL_CTX_use_certificate(ctx, cert) >>> >>> After this line is it safe to free cert object while ctx is >>> still used later on? >>> > > SSL_CTX_use_certificate(ctx, cert), on successful return, takes an > additional reference on the supplied |cert| argument to account > for the pointer in |ctx|.? Thus, the caller of > SSL_CTX_use_certificate() can safely call X509_free(cert) to > release the caller's local reference, while the |ctx| retains a > pointer to |cert|. > > -Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adimallikarjunareddy at gmail.com Tue Oct 17 19:07:14 2017 From: adimallikarjunareddy at gmail.com (Adi Mallikarjuna Reddy V) Date: Tue, 17 Oct 2017 12:07:14 -0700 Subject: [openssl-users] Issue with freeing X509 In-Reply-To: <214ee802-81a0-9a4f-17e8-1dd8f72c6542@akamai.com> References: <3d226fbc-82b0-6f07-c7e0-c0e3c4262402@akamai.com> <9f23fb56-a19c-c7cc-d595-584fc2732eec@akamai.com> <9e9be436-d02c-0fde-0688-98a183fdb26b@akamai.com> <214ee802-81a0-9a4f-17e8-1dd8f72c6542@akamai.com> Message-ID: Since I tried all that and it crashes, I am going ahead and giving you the more details on how I created *cert/evp_pkey* objects. *X509 *cert = PEM_read_bio_X509_AUX(cert_bio, NULL, NULL, NULL);* *EVP_PKEY *evp_pkey = PEM_read_bio_PrivateKey(key_bio, NULL, NULL, NULL);* I tried freeing both *cert* and *evp_pkey* locally before even I use SSL_Ctx object and after using it and freeing using SSL_CTx_Free(ctx). Both results in a signal 11 crash. */opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(i2c_ASN1_INTEGER+0x10)[0x2b6a4a09d2b0]* */opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(asn1_ex_i2c+0x119)[0x2b6a4a0a8269]* */opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(+0x13835f)[0x2b6a4a0a835f]* */opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(ASN1_item_ex_i2d+0x127)[0x2b6a4a0a85d7]* */opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(+0x138b51)[0x2b6a4a0a8b51]* */opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(ASN1_item_ex_i2d+0x270)[0x2b6a4a0a8720]* */opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(+0x138bdd)[0x2b6a4a0a8bdd]* */opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(ASN1_item_ex_i2d+0x270)[0x2b6a4a0a8720]* */opt/openssl/1.0.2k/lib64/libcrypto.so.1.0.0(ASN1_item_i2d+0x4b)[0x2b6a4a0a8ebb]* */opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(+0x463db)[0x2b6a49d473db]* */opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl_add_cert_chain+0xb1)[0x2b6a49d47551]* */opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl3_output_cert_chain+0x28)[0x2b6a49d2dc88]* */opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl3_send_server_certificate+0x3d)[0x2b6a49d1b2bd]* */opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl3_accept+0xfe8)[0x2b6a49d206b8]* */opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl23_get_client_hello+0x94)[0x2b6a49d2f984]* */opt/openssl/1.0.2k/lib64/libssl.so.1.0.0(ssl23_accept+0xa1)[0x2b6a49d30251]* On Tue, Oct 17, 2017 at 11:37 AM, Benjamin Kaduk wrote: > I thought this had become documented recently (i.e., in master only, not > even in 1.1.0), but can't find any evidence of such documentation. > > SSL_CTX_use_PrivateKey() takes a reference on its pkey argument in the > same way as SSL_CTX_use_certificate(); it is safe for the local code to > free its local copy. > > -Ben > > On 10/17/2017 12:32 PM, Adi Mallikarjuna Reddy V wrote: > > Is this documented some where? > > Also is the same true - with SSL_CTX_use_PrivateKey(ctx, evp_pkey) ? where > I can free evp_pkey with EVP_PKEY_free()? > > > Thanks > Adi > > On Tue, Oct 17, 2017 at 9:50 AM, Benjamin Kaduk wrote: > >> On 10/17/2017 11:27 AM, Adi Mallikarjuna Reddy V wrote: >> >> I am only worried about the following line. >> >> SSL_CTX_use_certificate(ctx, cert) >> >> After this line is it safe to free cert object while ctx is still used >> later on? >> >> >> SSL_CTX_use_certificate(ctx, cert), on successful return, takes an >> additional reference on the supplied |cert| argument to account for the >> pointer in |ctx|. Thus, the caller of SSL_CTX_use_certificate() can safely >> call X509_free(cert) to release the caller's local reference, while the >> |ctx| retains a pointer to |cert|. >> >> -Ben >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.bare at gmail.com Tue Oct 17 20:27:31 2017 From: chris.bare at gmail.com (Chris Bare) Date: Tue, 17 Oct 2017 16:27:31 -0400 Subject: [openssl-users] SSL_shutdown:shutdown while in init Message-ID: I have the following code: setup_ssl (char *server_name, char *port, SSL_CTX *ctx) { BIO *output = BIO_new_ssl_connect (ctx); if (!output) { return (NULL); } BIO_get_ssl (output, &ssl); SSL_set_mode (ssl, SSL_MODE_AUTO_RETRY); SSL_set_verify (ssl, true, NULL); BIO_set_conn_hostname (output, server_name); BIO_set_conn_port(output, port); if (BIO_do_connect (output) <= 0) { BIO_free (output); return (NULL); } } If the server I'm trying to connect to does not have ssl enabled, I get the error: SSL23_GET_SERVER_HELLO:unknown protocol and BIO_do_connect fails as expected, but BIO_free gives this error: SSL_shutdown:shutdown while in init If I don't free it, I have a memory leak. Is there something else I need to do to clean up the BIO? I tried calling BIO_do_handshake, but that crashes (not surprised). -- Chris Bare -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 18 09:14:53 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 18 Oct 2017 10:14:53 +0100 Subject: [openssl-users] SSL_shutdown:shutdown while in init In-Reply-To: References: Message-ID: <623e4221-73c5-e57c-08bc-243891d3fc5f@openssl.org> On 17/10/17 21:27, Chris Bare wrote: > I have the following code: > > setup_ssl (char *server_name, char *port, SSL_CTX *ctx) > { > ??? BIO *output = BIO_new_ssl_connect (ctx); > ??? if (!output) > ??? { > ??? ??? return (NULL); > ??? } > ??? BIO_get_ssl (output, &ssl); > ??? SSL_set_mode (ssl, SSL_MODE_AUTO_RETRY); > ??? SSL_set_verify (ssl, true, NULL); > ??? BIO_set_conn_hostname (output, server_name); > ??? BIO_set_conn_port(output, port); > > ??? if (BIO_do_connect (output) <= 0) > ??? { > ??? ??? BIO_free (output); > ??? ??? return (NULL); > ??? } > } > > If the server I'm trying to connect to does not have ssl enabled, I get > the error: > SSL23_GET_SERVER_HELLO:unknown protocol > and BIO_do_connect fails as expected, but BIO_free gives this error: > SSL_shutdown:shutdown while in init Hmmm...that looks like an OpenSSL bug to me. It should not call SSL_shutdown() if we are still in init. I raised this issue: https://github.com/openssl/openssl/issues/4545 > > If I don't free it, I have a memory leak. > Is there something else I need to do to clean up the BIO? As a workaround for this I think you can just ignore the error. From code inspection it looks to me like it should go ahead and free everything anyway. Matt From wouter.verhelst at fedict.be Wed Oct 18 14:47:28 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Wed, 18 Oct 2017 16:47:28 +0200 Subject: [openssl-users] CRL signature verification Message-ID: <9d8a9fa5-a78a-047b-199f-f356dfee0501@fedict.be> Hi, I have an application which wants to do verification of a certificate. Not in the context of a context or a signature, but simply to verify if the certificates are still valid and from a source that is correct in the context in which the application runs. I used libcrypto to parse out the OCSP URL from the certificate validate it against a whitelist of valid OCSP URLs, send an OCSP request and validate the response and its signature against a custom certificate store, and then parse out the result. Two points on that: - This seems like something that should be in libcrypto rather than in my own code. Did I miss something obvious? - Currently I don't fall back to CRLs when the OCSP server is unavailable. I would like to do so; however, I can't figure out how to validate the signature on a CRL (which would be a pretty obvious failure). Alternatively, is there an obvious alternative thing that I should be doing, rather than manually parsing the CRL? Thanks, -- Wouter Verhelst From rsalz at akamai.com Wed Oct 18 15:46:00 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 18 Oct 2017 15:46:00 +0000 Subject: [openssl-users] CRL signature verification In-Reply-To: <9d8a9fa5-a78a-047b-199f-f356dfee0501@fedict.be> References: <9d8a9fa5-a78a-047b-199f-f356dfee0501@fedict.be> Message-ID: <9EDC45B0-DD21-4016-A4E4-E5FCB3C621B6@akamai.com> ? I used libcrypto to parse out the OCSP URL from the certificate validate it against a whitelist of valid OCSP URLs, send an OCSP request and validate the response and its signature against a custom certificate store, and then parse out the result. Two points on that: ? - This seems like something that should be in libcrypto rather than in my own code. Did I miss something obvious? We generally don?t do any kind of network traffic (except SSL) and would rather leave that up to the application. Especially because there are all sorts of other frameworks, blocking issues, DNS, etc., that make things a non-simple matter. ? - Currently I don't fall back to CRLs when the OCSP server is unavailable. I would like to do so; however, I can't figure out how to validate the signature on a CRL (which would be a pretty obvious failure). Alternatively, is there an obvious alternative thing that I should be doing, rather than manually parsing the CRL? X509_CRL_verify. And yes, looking through to find the serial# is what you have to do. From charlesm at mcn.org Wed Oct 18 20:08:53 2017 From: charlesm at mcn.org (Charles Mills) Date: Wed, 18 Oct 2017 13:08:53 -0700 Subject: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 Message-ID: <12b701d3484c$ebf6a2c0$c3e3e840$@mcn.org> I am migrating a multi-threaded Windows application from OpenSSL 1.0.1h to 1.1.0f. I am using the Shining Light pre-built Windows DLLs. The code, which I wrote some time ago, has a statement HANDLE Comm::sslMutexArray[CRYPTO_NUM_LOCKS]; The array is referenced by my sslLockingFunction. When I compile with the 1.1.0f headers I get at undefined symbol on CRYPTO_NUM_LOCKS. Is my understanding of http://www.manpagez.com/man/3/CRYPTO_num_locks/osx-10.3.php correct? Basically, I need to replace the static array sslMutexArray[CRYPTO_NUM_LOCKS] with a malloc() or new to get an array of the size returned by a call to CRYPTO_num_locks(void)? Is that correct? Anything else I need to do in this regard? Thanks, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Wed Oct 18 21:14:02 2017 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 18 Oct 2017 14:14:02 -0700 (PDT) Subject: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 In-Reply-To: <12b701d3484c$ebf6a2c0$c3e3e840$@mcn.org> References: <12b701d3484c$ebf6a2c0$c3e3e840$@mcn.org> Message-ID: OpenSSL 1.1.x handle the locking themselves. You don't need to install the locking call backs and don't need to provide locking functionality. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Charles Mills [mailto:charlesm at mcn.org] Sent: Thursday, 19 October 2017 6:09 AM To: openssl-users at openssl.org Subject: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 I am migrating a multi-threaded Windows application from OpenSSL 1.0.1h to 1.1.0f. I am using the Shining Light pre-built Windows DLLs. The code, which I wrote some time ago, has a statement HANDLE Comm::sslMutexArray[CRYPTO_NUM_LOCKS]; The array is referenced by my sslLockingFunction. When I compile with the 1.1.0f headers I get at undefined symbol on CRYPTO_NUM_LOCKS. Is my understanding of http://www.manpagez.com/man/3/CRYPTO_num_locks/osx-10.3.php correct? Basically, I need to replace the static array sslMutexArray[CRYPTO_NUM_LOCKS] with a malloc() or new to get an array of the size returned by a call to CRYPTO_num_locks(void)? Is that correct? Anything else I need to do in this regard? Thanks, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesm at mcn.org Wed Oct 18 21:20:21 2017 From: charlesm at mcn.org (Charles Mills) Date: Wed, 18 Oct 2017 14:20:21 -0700 Subject: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 In-Reply-To: References: <12b701d3484c$ebf6a2c0$c3e3e840$@mcn.org> Message-ID: <131301d34856$e7a5b3a0$b6f11ae0$@mcn.org> Wow! Thanks. You are saying to just drop out this array, and the two CRYPTO_set_..._callback() functions, and the functions they reference? Charles From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Paul Dale Sent: Wednesday, October 18, 2017 2:14 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 OpenSSL 1.1.x handle the locking themselves. You don't need to install the locking call backs and don't need to provide locking functionality. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Charles Mills [mailto:charlesm at mcn.org] Sent: Thursday, 19 October 2017 6:09 AM To: openssl-users at openssl.org Subject: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 I am migrating a multi-threaded Windows application from OpenSSL 1.0.1h to 1.1.0f. I am using the Shining Light pre-built Windows DLLs. The code, which I wrote some time ago, has a statement HANDLE Comm::sslMutexArray[CRYPTO_NUM_LOCKS]; The array is referenced by my sslLockingFunction. When I compile with the 1.1.0f headers I get at undefined symbol on CRYPTO_NUM_LOCKS. Is my understanding of http://www.manpagez.com/man/3/CRYPTO_num_locks/osx-10.3.php correct? Basically, I need to replace the static array sslMutexArray[CRYPTO_NUM_LOCKS] with a malloc() or new to get an array of the size returned by a call to CRYPTO_num_locks(void)? Is that correct? Anything else I need to do in this regard? Thanks, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesm at mcn.org Wed Oct 18 21:23:18 2017 From: charlesm at mcn.org (Charles Mills) Date: Wed, 18 Oct 2017 14:23:18 -0700 Subject: [openssl-users] Where is mttest.c? Message-ID: <131801d34857$50fe15e0$f2fa41a0$@mcn.org> Sorry - OpenSSL is not what I do every day. I see in the man pages a reference to crypto/threads/mttest.c. I've got the 1.1.0f tar and the crypto directory does not contain a threads directory. Where do I find mttest.c? Thanks, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Thu Oct 19 00:04:28 2017 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 18 Oct 2017 17:04:28 -0700 (PDT) Subject: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 In-Reply-To: <131301d34856$e7a5b3a0$b6f11ae0$@mcn.org> References: <12b701d3484c$ebf6a2c0$c3e3e840$@mcn.org> <131301d34856$e7a5b3a0$b6f11ae0$@mcn.org> Message-ID: Yes. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Charles Mills [mailto:charlesm at mcn.org] Sent: Thursday, 19 October 2017 7:20 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 Wow! Thanks. You are saying to just drop out this array, and the two CRYPTO_set_..._callback() functions, and the functions they reference? Charles From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Paul Dale Sent: Wednesday, October 18, 2017 2:14 PM To: HYPERLINK "mailto:openssl-users at openssl.org"openssl-users at openssl.org Subject: Re: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 OpenSSL 1.1.x handle the locking themselves. You don't need to install the locking call backs and don't need to provide locking functionality. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Charles Mills [mailto:charlesm at mcn.org] Sent: Thursday, 19 October 2017 6:09 AM To: HYPERLINK "mailto:openssl-users at openssl.org"openssl-users at openssl.org Subject: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 I am migrating a multi-threaded Windows application from OpenSSL 1.0.1h to 1.1.0f. I am using the Shining Light pre-built Windows DLLs. The code, which I wrote some time ago, has a statement HANDLE Comm::sslMutexArray[CRYPTO_NUM_LOCKS]; The array is referenced by my sslLockingFunction. When I compile with the 1.1.0f headers I get at undefined symbol on CRYPTO_NUM_LOCKS. Is my understanding of http://www.manpagez.com/man/3/CRYPTO_num_locks/osx-10.3.php correct? Basically, I need to replace the static array sslMutexArray[CRYPTO_NUM_LOCKS] with a malloc() or new to get an array of the size returned by a call to CRYPTO_num_locks(void)? Is that correct? Anything else I need to do in this regard? Thanks, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Thu Oct 19 00:06:20 2017 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 18 Oct 2017 17:06:20 -0700 (PDT) Subject: [openssl-users] Where is mttest.c? In-Reply-To: <131801d34857$50fe15e0$f2fa41a0$@mcn.org> References: <131801d34857$50fe15e0$f2fa41a0$@mcn.org> Message-ID: <8d2c0471-e1ff-4396-bb29-5d5d0a016a35@default> Are you sure you are using the correct man pages? There is no reference to mttest.c in the repository anymore. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Charles Mills [mailto:charlesm at mcn.org] Sent: Thursday, 19 October 2017 7:23 AM To: openssl-users at openssl.org Subject: [openssl-users] Where is mttest.c? Sorry - OpenSSL is not what I do every day. I see in the man pages a reference to crypto/threads/mttest.c. I've got the 1.1.0f tar and the crypto directory does not contain a threads directory. Where do I find mttest.c? Thanks, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Oct 19 07:18:53 2017 From: levitte at openssl.org (Richard Levitte) Date: Thu, 19 Oct 2017 09:18:53 +0200 (CEST) Subject: [openssl-users] Where is mttest.c? In-Reply-To: <131801d34857$50fe15e0$f2fa41a0$@mcn.org> References: <131801d34857$50fe15e0$f2fa41a0$@mcn.org> Message-ID: <20171019.091853.1419339625806412849.levitte@openssl.org> In message <131801d34857$50fe15e0$f2fa41a0$@mcn.org> on Wed, 18 Oct 2017 14:23:18 -0700, "Charles Mills" said: charlesm> Sorry ? OpenSSL is not what I do every day. charlesm> charlesm> I see in the man pages a reference to crypto/threads/mttest.c. That's the 1.0.2 manpages, right? charlesm> I?ve got the 1.1.0f tar and the crypto directory does not charlesm> contain a threads directory. Where do I find mttest.c? You don't. It's been removed in 1.1.0, and as far as I can see, you won't find any reference to mttest.c in the 1.1.0 docs... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From wouter.verhelst at fedict.be Thu Oct 19 10:09:27 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Thu, 19 Oct 2017 12:09:27 +0200 Subject: [openssl-users] CRL signature verification In-Reply-To: <9EDC45B0-DD21-4016-A4E4-E5FCB3C621B6@akamai.com> References: <9d8a9fa5-a78a-047b-199f-f356dfee0501@fedict.be> <9EDC45B0-DD21-4016-A4E4-E5FCB3C621B6@akamai.com> Message-ID: <838c40a9-a622-7ada-5355-bf1fb687f61d@fedict.be> Hi Rich, On 18-10-17 17:46, Salz, Rich via openssl-users wrote: > ? I used libcrypto to parse out the OCSP URL from the certificate validate > it against a whitelist of valid OCSP URLs, send an OCSP request and > validate the response and its signature against a custom certificate > store, and then parse out the result. > > Two points on that: > ? - This seems like something that should be in libcrypto rather than in > my own code. Did I miss something obvious? > > We generally don?t do any kind of network traffic (except SSL) and would rather leave that up to the application. Especially because there are all sorts of other frameworks, blocking issues, DNS, etc., that make things a non-simple matter. Sorry, I should have been clearer. I didn't mean the HTTP requests etc. I agree that that should not be done by libcrypto. I was more talking about the parsing. Currently I have 40 LOC [1] to find the OCSP URL from a certificate; it seems to me that that's a lot of stuff that I shouldn't have to be doing, and that asking OpenSSL to parse out that URL (or really, any other X.509v3 extension's data) should not be too complicated. Perhaps I missed the call that I should have been using, though ;-) [1] https://github.com/Fedict/eid-mw/blob/master/plugins_tools/eid-viewer/verify.c#L89-L129 > ? - Currently I don't fall back to CRLs when the OCSP server is > unavailable. I would like to do so; however, I can't figure out how to > validate the signature on a CRL (which would be a pretty obvious > failure). Alternatively, is there an obvious alternative thing that I > should be doing, rather than manually parsing the CRL? > > X509_CRL_verify. And yes, looking through to find the serial# is what you have to do. That's 1.1-specific, correct? -- Wouter Verhelst From rsalz at akamai.com Thu Oct 19 12:31:05 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 19 Oct 2017 12:31:05 +0000 Subject: [openssl-users] CRL signature verification In-Reply-To: <838c40a9-a622-7ada-5355-bf1fb687f61d@fedict.be> References: <9d8a9fa5-a78a-047b-199f-f356dfee0501@fedict.be> <9EDC45B0-DD21-4016-A4E4-E5FCB3C621B6@akamai.com> <838c40a9-a622-7ada-5355-bf1fb687f61d@fedict.be> Message-ID: <66CA517E-2AA1-4E9C-BACC-22ABCA68A74E@akamai.com> ? I was more talking about the parsing. Currently I have 40 LOC [1] to Look at X509_get1_ocsp which is in crypto/x509v3/v3_utl.c That?s in 1.0.2 and later ? > X509_CRL_verify. And yes, looking through to find the serial# is what you have to do. ? That's 1.1-specific, correct? Yes. From jb-openssl at wisemo.com Thu Oct 19 17:14:11 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 19 Oct 2017 19:14:11 +0200 Subject: [openssl-users] SSL_shutdown:shutdown while in init In-Reply-To: <623e4221-73c5-e57c-08bc-243891d3fc5f@openssl.org> References: <623e4221-73c5-e57c-08bc-243891d3fc5f@openssl.org> Message-ID: <1cc9eeb9-cea8-2aa2-a906-54fed4d9afba@wisemo.com> On 18/10/2017 11:14, Matt Caswell wrote: > > On 17/10/17 21:27, Chris Bare wrote: >> I have the following code: >> >> setup_ssl (char *server_name, char *port, SSL_CTX *ctx) >> { >> ??? BIO *output = BIO_new_ssl_connect (ctx); >> ??? if (!output) >> ??? { >> ??? ??? return (NULL); >> ??? } >> ??? BIO_get_ssl (output, &ssl); >> ??? SSL_set_mode (ssl, SSL_MODE_AUTO_RETRY); >> ??? SSL_set_verify (ssl, true, NULL); >> ??? BIO_set_conn_hostname (output, server_name); >> ??? BIO_set_conn_port(output, port); >> >> ??? if (BIO_do_connect (output) <= 0) >> ??? { >> ??? ??? BIO_free (output); >> ??? ??? return (NULL); >> ??? } >> } >> >> If the server I'm trying to connect to does not have ssl enabled, I get >> the error: >> SSL23_GET_SERVER_HELLO:unknown protocol >> and BIO_do_connect fails as expected, but BIO_free gives this error: >> SSL_shutdown:shutdown while in init > Hmmm...that looks like an OpenSSL bug to me. It should not call > SSL_shutdown() if we are still in init. I raised this issue: > > https://github.com/openssl/openssl/issues/4545 > From a more general usability perspective, it would be better if SSL_shutdown() (starting from some version number) would always do the right thing to properly and graciously end the SSL/TLS connection, in any state where the connection object pointer is valid at all.? That would probably imply taking completely different actions during init and/or after shutdown has been initiated by either end. Then any complicated rules about when to call/not call SSL_shutdown() could be relegated to a section about historical bugs in older versions. >> If I don't free it, I have a memory leak. >> Is there something else I need to do to clean up the BIO? > As a workaround for this I think you can just ignore the error. From > code inspection it looks to me like it should go ahead and free > everything anyway. > > Matt > > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From chris at marget.com Fri Oct 20 20:00:08 2017 From: chris at marget.com (Chris Marget) Date: Fri, 20 Oct 2017 16:00:08 -0400 Subject: [openssl-users] cms utility "-sign" doesn't include signed content Message-ID: I'm struggling with a PKCS7 signing operation using openssl 1.0.2g. I want to create signed messages like the one in my 'original' file (below). It seemed like extracting and then re-signing this message would be a good start. I'm able to verify/unpack the original message, but not able to sign the unpacked message to get back to where I started. I have access to the signer's certificate and private key. I hope somebody can point me in the right direction? I'm extracting the message with: openssl cms -verify -CAfile CA_cert.pem -inform pem -in original -out extracted I thought I'd be able to re-sign this message using something like: openssl cms -sign -md sha1 -in extracted -inkey signer_key -signer signer_cert -outform pem This 'sign' operation completes successfully, but produces an output that's missing the payload. Using the same procedure to sign 1MB of random data produces a result that's only 1396 bytes long: dd if=/dev/urandom bs=1M count=1 | openssl cms -sign -md sha1 -inkey signer_key -signer signer_cert -outform pem | grep -v -- -- | base64 --decode | wc -c 1396 Clearly this 'sign' function doesn't do what I thought it did. How can I sign blob of data so that it looks like my 'original'? The files I'm using: original https://pastebin.com/raw/CNPLyqcm CA_cert.pem https://pastebin.com/raw/HiE6gMTN signer_key https://pastebin.com/raw/tnCXeYHg (the correct key, but not an actual secret) signer_cert https://pastebin.com/raw/ACtTVHdp Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From devildron at gmail.com Sat Oct 21 11:20:01 2017 From: devildron at gmail.com (Codarren Velvindron) Date: Sat, 21 Oct 2017 15:20:01 +0400 Subject: [openssl-users] Generating CSR based on an x25519 public key Message-ID: Hello, How would we be able to achieve this? I have read somewhere on a 2016 mail in the archives that it is an "encrypt-only" algorithm and that is not possible. But I have found many sites on let's encrypt already using this. Does anyone know how to do this? Thanks, Codarren -------------- next part -------------- An HTML attachment was scrubbed... URL: From devildron at gmail.com Sat Oct 21 11:44:13 2017 From: devildron at gmail.com (Codarren Velvindron) Date: Sat, 21 Oct 2017 15:44:13 +0400 Subject: [openssl-users] Generating CSR based on an x25519 public key Message-ID: Errata: I meant private key -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Oct 21 12:19:23 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 21 Oct 2017 12:19:23 +0000 Subject: [openssl-users] Generating CSR based on an x25519 public key In-Reply-To: References: Message-ID: * How would we be able to achieve this? I have read somewhere on a 2016 mail in the archives that it is an "encrypt-only" algorithm and that is not possible. X25519 is a key-exchange-only algorithm. Ed25519 is a signing algorithm. Unlike classic RSA, the signing and the key exchange are two different operations (well, technically RSA doesn?t have key exchange). Both are defined by IETF RFC?s. OpenSSL doesn?t fully support Ed25519. * But I have found many sites on let's encrypt already using this. Are you sure? Please post a key. Ed25519 is quite different from EdDSA or ECDSA or DSA, which typically use a P-256 curve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From devildron at gmail.com Sat Oct 21 13:38:23 2017 From: devildron at gmail.com (Codarren Velvindron) Date: Sat, 21 Oct 2017 17:38:23 +0400 Subject: [openssl-users] Generating CSR based on an x25519 public key In-Reply-To: References: Message-ID: https://tls13.crypto.mozilla.org is using : The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.3), a strong key exchange (X25519), and a strong cipher (AES_128_GCM). Using openssl standard tools is it possible to generate a CSR through Ed25519 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Sat Oct 21 14:06:07 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 21 Oct 2017 10:06:07 -0400 Subject: [openssl-users] Generating CSR based on an x25519 public key In-Reply-To: References: Message-ID: On Sat, Oct 21, 2017 at 9:38 AM, Codarren Velvindron wrote: > https://tls13.crypto.mozilla.org is using : The connection to this site is > encrypted and authenticated using a strong protocol (TLS 1.3), a strong key > exchange (X25519), and a strong cipher (AES_128_GCM). That's what Rich said: "X25519 is a key-exchange-only algorithm". The shared secret that drops out of the x25519 key exchange is used to key AES128/GCM (some hand waiving). > Using openssl standard tools is it possible to generate a CSR through > Ed25519 ? This is a different application. ed25519 is signing, not key exchange. I'm not sure how to do it because I've never needed it. But keep in mind Rich said: "OpenSSL doesn?t fully support Ed25519". Jeff From rsalz at akamai.com Sat Oct 21 15:01:14 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 21 Oct 2017 15:01:14 +0000 Subject: [openssl-users] Generating CSR based on an x25519 public key In-Reply-To: References: Message-ID: <0321AECA-B6F6-4857-A9AB-65F1F8A32A50@akamai.com> They are NOT using a 25519 certificate; it says ?key exchange? From: Codarren Velvindron Date: Saturday, October 21, 2017 at 9:38 AM To: Rich Salz , openssl-users Subject: Re: [openssl-users] Generating CSR based on an x25519 public key https://tls13.crypto.mozilla.org is using : The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.3), a strong key exchange (X25519), and a strong cipher (AES_128_GCM). Using openssl standard tools is it possible to generate a CSR through Ed25519 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From misaki.miyashita at oracle.com Sat Oct 21 15:20:33 2017 From: misaki.miyashita at oracle.com (Misaki Miyashita) Date: Sat, 21 Oct 2017 10:20:33 -0500 Subject: [openssl-users] Failed to access LDAP server when a valid certificate is at .1+ Message-ID: <59EB65C1.80100@oracle.com> Hi, We encountered a problem using OpenLDAP with OpenSSL when there were more than one certificate with the same subject. In our test setup, there were three self-signed certificates with the same subject, two of which were expired and one was valid. When the valid certificate is at .0, things work fine. However, when an invalid certificate is at .0, it fails to connect to the LDAP server even if the valid certificate is available at .1 or .2. # openldapsearch -H :636 -x -b "" -s base objectclass=\* namingcontexts ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) The trace of the process shows that all 3 certificates were opened but X509_verify_cert() returns 0 when an invalid certificate is at .0. Does OpenSSL stop searching for a valid certificate when it finds a certificate with matching DN? Thank you, -- misaki From openssl-users at dukhovni.org Sat Oct 21 20:21:09 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 21 Oct 2017 16:21:09 -0400 Subject: [openssl-users] Failed to access LDAP server when a valid certificate is at .1+ In-Reply-To: <59EB65C1.80100@oracle.com> References: <59EB65C1.80100@oracle.com> Message-ID: <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org> On Oct 21, 2017, at 11:20 AM, Misaki Miyashita wrote: > We encountered a problem using OpenLDAP with OpenSSL when there were more than one certificate with the same subject. > > Does OpenSSL stop searching for a valid certificate when it finds a certificate with matching DN? Yes, when a matching issuer is found in the trust store, but is expired no alternative certificates will be tested. You need to remove outdated issuer certificates from your trust store before they expire. -- Viktor. From manjunathsm1 at gmail.com Sat Oct 21 23:25:10 2017 From: manjunathsm1 at gmail.com (Manjunath SM) Date: Sun, 22 Oct 2017 04:55:10 +0530 Subject: [openssl-users] DSA2048 support in openssl-fips-2.0.14. In-Reply-To: References: Message-ID: 2nd try, Thx Manju On 17 Oct 2017 3:16 pm, "Manjunath SM" wrote: Hi All, Am using openssl-fips-2.0.14 at server side on top of openssl1.0.2K. Server is operating in FIPS mode(fips mode enabled thru FIPS_mode_set). Created DSA2048 host key at server which is running in FIPS mode, With this configuration when am trying to do SSH from ssh client am getting below error. =========================================================== The authenticity of host '135.249.23.182 (135.249.23.182)' can't be established but keys of different type are already known for this host. DSA key fingerprint is 31:75:2c:96:ac:9c:11:f8:3b:39:0b:86:ba:88:51:02. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '135.249.23.182' (DSA) to the list of known hosts. *ssh_dss_verify: remaining bytes in signature 24key_verify failed for server_host_key* ======================================================== SSH client version is OpenSSH_6.4p1, OpenSSL 1.0.1e-fips 11 Feb 2013 In FIPS use guide I do see, DSA 2048 is supported. Does any one faced similar issue ?If so pls share the findings. -- -- Regards Manju -- ?Take care of the earth and she will take care of you.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesm at mcn.org Mon Oct 23 05:00:31 2017 From: charlesm at mcn.org (Charles Mills) Date: Sun, 22 Oct 2017 22:00:31 -0700 Subject: [openssl-users] Where is mttest.c? In-Reply-To: <20171019.091853.1419339625806412849.levitte@openssl.org> References: <131801d34857$50fe15e0$f2fa41a0$@mcn.org> <20171019.091853.1419339625806412849.levitte@openssl.org> Message-ID: <062b01d34bbb$da91c470$8fb54d50$@mcn.org> Got it. Thanks, Charles -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Richard Levitte Sent: Thursday, October 19, 2017 12:19 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Where is mttest.c? In message <131801d34857$50fe15e0$f2fa41a0$@mcn.org> on Wed, 18 Oct 2017 14:23:18 -0700, "Charles Mills" said: charlesm> Sorry ? OpenSSL is not what I do every day. charlesm> charlesm> I see in the man pages a reference to crypto/threads/mttest.c. That's the 1.0.2 manpages, right? charlesm> I?ve got the 1.1.0f tar and the crypto directory does not charlesm> contain a threads directory. Where do I find mttest.c? You don't. It's been removed in 1.1.0, and as far as I can see, you won't find any reference to mttest.c in the 1.1.0 docs... From charlesm at mcn.org Mon Oct 23 05:02:24 2017 From: charlesm at mcn.org (Charles Mills) Date: Sun, 22 Oct 2017 22:02:24 -0700 Subject: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 In-Reply-To: References: <12b701d3484c$ebf6a2c0$c3e3e840$@mcn.org> <131301d34856$e7a5b3a0$b6f11ae0$@mcn.org> Message-ID: <062c01d34bbc$1d661300$58323900$@mcn.org> Works like a champ! Threaded code is handling 800 TLS server sessions with nary a callback in sight. Charles From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Paul Dale Sent: Wednesday, October 18, 2017 5:04 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 Yes. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Charles Mills [mailto:charlesm at mcn.org] Sent: Thursday, 19 October 2017 7:20 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 Wow! Thanks. You are saying to just drop out this array, and the two CRYPTO_set_..._callback() functions, and the functions they reference? Charles From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Paul Dale Sent: Wednesday, October 18, 2017 2:14 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 OpenSSL 1.1.x handle the locking themselves. You don't need to install the locking call backs and don't need to provide locking functionality. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Charles Mills [mailto:charlesm at mcn.org] Sent: Thursday, 19 October 2017 6:09 AM To: openssl-users at openssl.org Subject: [openssl-users] Replacing CRYPTO_NUM_LOCKS on migration 101 to 110 I am migrating a multi-threaded Windows application from OpenSSL 1.0.1h to 1.1.0f. I am using the Shining Light pre-built Windows DLLs. The code, which I wrote some time ago, has a statement HANDLE Comm::sslMutexArray[CRYPTO_NUM_LOCKS]; The array is referenced by my sslLockingFunction. When I compile with the 1.1.0f headers I get at undefined symbol on CRYPTO_NUM_LOCKS. Is my understanding of http://www.manpagez.com/man/3/CRYPTO_num_locks/osx-10.3.php correct? Basically, I need to replace the static array sslMutexArray[CRYPTO_NUM_LOCKS] with a malloc() or new to get an array of the size returned by a call to CRYPTO_num_locks(void)? Is that correct? Anything else I need to do in this regard? Thanks, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From cognet at ci0.org Mon Oct 23 15:16:30 2017 From: cognet at ci0.org (Olivier Houchard) Date: Mon, 23 Oct 2017 17:16:30 +0200 Subject: [openssl-users] Early data based on SNI with OpenSSL 1.1.1 Message-ID: <20171023151630.GA79754@ci0.org> Hi, I'm trying to use OpenSSL 1.1.1 to accept or reject early data based on the SNI, and I'm a bit confused on how to do so. The problem I have is, I don't know the SNI before the client hello callback is called, and at that time it seems to be too late to make a decision for early data. Either the callback is called from SSL_do_handshake(), and then any call to SSL_read_early_data() will fail with SSL_ERROR_SSL, and early data will be rejected, or it is called if I call SSL_read_early_data() first, but then early data will be considered accepted no matter what. I tried returning -1 from the client hello callback, but if called from SSL_do_handshake to indicate early data are to be read, it seems to be too late to call SSL_read_early_data() anyway, and if called from SSL_read_early_data() to indicate we should stop reading early data, it mostly works, except as s->early_data_state will be SSL_EARLY_DATA_ACCEPT_RETRY, and so any call to SSL_Read() will fail because of that test in ssl_read_internal() : if (s->early_data_state == SSL_EARLY_DATA_CONNECT_RETRY || s->early_data_state == SSL_EARLY_DATA_ACCEPT_RETRY) { SSLerr(SSL_F_SSL_READ_INTERNAL, ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED); return 0; } Am I missing something obvious ? Is there any way I can accept or reject early data based on the SNI ? Thanks ! Olivier From matt at openssl.org Mon Oct 23 15:31:02 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 23 Oct 2017 16:31:02 +0100 Subject: [openssl-users] Early data based on SNI with OpenSSL 1.1.1 In-Reply-To: <20171023151630.GA79754@ci0.org> References: <20171023151630.GA79754@ci0.org> Message-ID: <605d34bf-1ae3-1160-7b92-4b132623d102@openssl.org> On 23/10/17 16:16, Olivier Houchard wrote: > Hi, > > I'm trying to use OpenSSL 1.1.1 to accept or reject early data based on > the SNI, and I'm a bit confused on how to do so. > The problem I have is, I don't know the SNI before the client hello > callback is called, and at that time it seems to be too late to make a > decision for early data. Either the callback is called from > SSL_do_handshake(), and then any call to SSL_read_early_data() will fail > with SSL_ERROR_SSL, and early data will be rejected, or it is called if > I call SSL_read_early_data() first, but then early data will be > considered accepted no matter what. > > I tried returning -1 from the client hello callback, but if called from > SSL_do_handshake to indicate early data are to be read, it seems to be too > late to call SSL_read_early_data() anyway, and if called from > SSL_read_early_data() to indicate we should stop reading early data, it > mostly works, except as s->early_data_state will be > SSL_EARLY_DATA_ACCEPT_RETRY, and so any call to SSL_Read() will fail > because of that test in ssl_read_internal() : > if (s->early_data_state == SSL_EARLY_DATA_CONNECT_RETRY > || s->early_data_state == SSL_EARLY_DATA_ACCEPT_RETRY) { > SSLerr(SSL_F_SSL_READ_INTERNAL, > ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED); > return 0; > } > > Am I missing something obvious ? Is there any way I can accept or reject > early data based on the SNI ? >From the docs: https://www.openssl.org/docs/manmaster/man3/SSL_set_max_early_data.html "When a session is created between a server and a client the server will specify the maximum amount of any early data that it will accept on any future connection attempt. By default this is approximately 16k. A server may override this default value by calling SSL_CTX_set_max_early_data() or SSL_set_max_early_data() to set it for the whole SSL_CTX or an individual SSL object respectively. Similarly the SSL_CTX_get_max_early_data() and SSL_get_max_early_data() functions can be used to obtain the current maximum early data settings for the SSL_CTX and SSL objects respectively." So, probably the best way to do this is to set the max early data for the server CTXs that you don't want to accept early_data to 0. Then any sessions they issue will not allow early_data to be used. If a client does attempt to use that session to send early data then it then it will be automatically rejected. If that doesn't work for you another way (I think?) to do this would be to set the max early data for that SSL object (using SSL_set_max_early_data()) to 0 during the callback. Matt From jb-openssl at wisemo.com Mon Oct 23 22:24:54 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 24 Oct 2017 00:24:54 +0200 Subject: [openssl-users] Generating CSR based on an x25519 public key In-Reply-To: References: Message-ID: <3fe38b86-669d-17cd-f026-100777cae760@wisemo.com> On 21/10/2017 15:38, Codarren Velvindron wrote: > https://tls13.crypto.mozilla.org is using : The connection to this > site is encrypted and authenticated using a strong protocol (TLS 1.3), > a strong key exchange (X25519), and a strong cipher (AES_128_GCM). > > Using openssl standard tools is it possible to generate a CSR through > Ed25519 ? > If you look further into this test page, at least with my browser, it uses x25519 with a regular RSA certificate from Let's encrypt.? I don't know if they use a different certificate with other browsers based on checking some TLS extensions etc. The x25519 public key has no certificate, it is randomly generated for each connection and signed with the RSA key from the certificate. 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 aerowolf at gmail.com Mon Oct 23 22:47:29 2017 From: aerowolf at gmail.com (Kyle Hamilton) Date: Mon, 23 Oct 2017 15:47:29 -0700 Subject: [openssl-users] Generating CSR based on an x25519 public key In-Reply-To: <3fe38b86-669d-17cd-f026-100777cae760@wisemo.com> References: <3fe38b86-669d-17cd-f026-100777cae760@wisemo.com> Message-ID: Out of curiosity, what are the algorithm identifiers for X25519 and Ed25519? -Kyle H On Mon, Oct 23, 2017 at 3:24 PM, Jakob Bohm wrote: > On 21/10/2017 15:38, Codarren Velvindron wrote: >> >> https://tls13.crypto.mozilla.org is using : The connection to this site is >> encrypted and authenticated using a strong protocol (TLS 1.3), a strong key >> exchange (X25519), and a strong cipher (AES_128_GCM). >> >> Using openssl standard tools is it possible to generate a CSR through >> Ed25519 ? >> > > > If you look further into this test page, at least with my > browser, it uses x25519 with a regular RSA certificate from > Let's encrypt. I don't know if they use a different > certificate with other browsers based on checking some TLS > extensions etc. > > The x25519 public key has no certificate, it is randomly > generated for each connection and signed with the RSA key > from the certificate. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From bhat.jayalakshmi at gmail.com Tue Oct 24 06:06:15 2017 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Tue, 24 Oct 2017 11:36:15 +0530 Subject: [openssl-users] Wanted details on ./config or Configure options Message-ID: Hi All, I am looking for details on options used to disable or remove unwanted ciphers, components while openssl building. This is for OpenSSL 1.0.2h. I am seeing many things on internet. But most of them have minimum explanation, please can you tell me is there any link that I can refer. Regards Jaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 24 09:01:58 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 24 Oct 2017 10:01:58 +0100 Subject: [openssl-users] Wanted details on ./config or Configure options In-Reply-To: References: Message-ID: <57a49aa9-9364-461e-1881-6039175f1ebe@openssl.org> On 24/10/17 07:06, Jayalakshmi bhat wrote: > Hi All, > > I am looking for details on options used to disable or remove unwanted > ciphers, components while openssl building. This is for OpenSSL 1.0.2h. > I am seeing many things on internet. But most of them have minimum > explanation, please can you tell me is there any link that I can refer. Have you looked in INSTALL? https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/INSTALL Matt From noloader at gmail.com Tue Oct 24 09:40:38 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 24 Oct 2017 05:40:38 -0400 Subject: [openssl-users] Generating CSR based on an x25519 public key In-Reply-To: References: <3fe38b86-669d-17cd-f026-100777cae760@wisemo.com> Message-ID: On Mon, Oct 23, 2017 at 6:47 PM, Kyle Hamilton wrote: > Out of curiosity, what are the algorithm identifiers for X25519 and Ed25519? > The ones I am aware of are available in http://tools.ietf.org/html/draft-josefsson-pkix-newcurves. Jeff From grace.priscilla at gmail.com Tue Oct 24 10:25:49 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Tue, 24 Oct 2017 15:55:49 +0530 Subject: [openssl-users] Issue with DTLS for UDP Message-ID: Hi All, We are currently facing an issue while initiating DTLS for UDP conenctions. Below is the backtrace for the coredump. Program terminated with signal 11, Segmentation fault. #0 0x00007fdf1825c760 in BIO_method_type () from /opt/OC/ins/external/lib/libcrypto.so.1.1 (gdb) bt #0 0x00007fdf1825c760 in BIO_method_type () from /opt/OC/ins/external/lib/libcrypto.so.1.1 #1 0x00007fdf18260459 in BIO_dgram_is_sctp () from /opt/OC/ins/external/lib/libcrypto.so.1.1 #2 0x00007fdf1865da66 in state_machine () from /opt/OC/ins/external/lib/libssl.so.1.1 #3 0x00007fdf18653f63 in SSL_do_handshake () from /opt/OC/ins/external/lib/libssl.so.1.1 #4 0x00007fdf1a4a4f98 in FI_sip_dtls_accept (AP_server=0x2323b98) at sip_dtls_interface.c:435 #5 0x00007fdf1a5c8a83 in FI_check_scrutation_list (AI_nb=1) at sip_trp_polling.c:875 #6 0x00007fdf1a5c9c7a in FP_scrutation_thread (AP_param=0x0) at sip_trp_polling.c:1244 #7 0x00007fdf19605bb8 in _tbx_thr_start (params=) at tbx_thr_unix_ovms.cxx:345 #8 0x00007fdf1c020b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #9 0x00007fdf1af5efbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #10 0x0000000000000000 in ?? () We are using SSL_accept to accept the connection for which we see the failure. Please let know if you have any thoughts. We are debugging to see why it crashes. The issue is seen only with DTLS over UDP. Thanks, Grace -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 24 10:37:45 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 24 Oct 2017 11:37:45 +0100 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: References: Message-ID: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> On 24/10/17 11:25, Grace Priscilla Jero wrote: > We are using SSL_accept to accept the connection for which we see the > failure. Please let know if you have any thoughts. Have you set the wbio correctly? Does SSL_get_wbio() return your wbio object if you call it immediately before SSL_do_handshake()? Matt From rsalz at akamai.com Tue Oct 24 12:47:20 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 Oct 2017 12:47:20 +0000 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: References: Message-ID: <4D5B4813-0DB5-4F9A-8C55-361BF8EBA6F4@akamai.com> Can you build with debugging enabled? IT might make things easier. But note that BIO_method_type is a trivial function, return b->method->type; which implies that a pointer got clobbered as being a likely cause. Are you sure your code didn?t smash something? #5 0x00007fdf1a5c8a83 in FI_check_scrutation_list (AI_nb=1) at sip_trp_polling.c:875 I have no idea what this does, but I love the name ?scrutation? :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kosowskileszek.leko at gmail.com Wed Oct 25 10:09:36 2017 From: kosowskileszek.leko at gmail.com (Leszek Kosowski) Date: Wed, 25 Oct 2017 12:09:36 +0200 Subject: [openssl-users] load_ssl_client_cert in the ENGINE structure is null. Message-ID: Hey, I am using OPENSSL (and INDY) to send data to web service. It works great when I use certificate in .p12 files. I need to use cryptographic card. I have 2 card Gemalto and Athena and I notice that in the ENGINE structure the field load_ssl_client_cert is null. Are this card prepared properly ? I can not use ENGINE_load_ssl_client_cert, SSL_CTX_set_client_cert_engine because there is an exception in libeay32.dll How to solve this problem ? Please help. From misaki.miyashita at oracle.com Wed Oct 25 14:31:51 2017 From: misaki.miyashita at oracle.com (Misaki Miyashita) Date: Wed, 25 Oct 2017 09:31:51 -0500 Subject: [openssl-users] Failed to access LDAP server when a valid certificate is at .1+ In-Reply-To: <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org> References: <59EB65C1.80100@oracle.com> <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org> Message-ID: <1df501f1-6ea5-e3b2-ed38-bff98bcd6b7a@oracle.com> Thanks for the reply, Viktor. Is it possible to keep searching for a valid certificate if the first matching certificate was not valid? Our customer claims that the NSS Mozilla didn't have this issue, so this is considered a regression for us. Best Regards, -- misaki On 10/21/2017 3:21 PM, Viktor Dukhovni wrote: > > On Oct 21, 2017, at 11:20 AM, Misaki Miyashita wrote: > >> We encountered a problem using OpenLDAP with OpenSSL when there were more than one certificate with the same subject. >> >> Does OpenSSL stop searching for a valid certificate when it finds a certificate with matching DN? > Yes, when a matching issuer is found in the trust store, but is expired > no alternative certificates will be tested. You need to remove outdated > issuer certificates from your trust store before they expire. > From bhat.jayalakshmi at gmail.com Wed Oct 25 17:02:31 2017 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Wed, 25 Oct 2017 22:32:31 +0530 Subject: [openssl-users] Wanted details on ./config or Configure options In-Reply-To: <57a49aa9-9364-461e-1881-6039175f1ebe@openssl.org> References: <57a49aa9-9364-461e-1881-6039175f1ebe@openssl.org> Message-ID: Hi Matt, Thanks a lot. This helps me. I had seen different options for OpenSSL 1.0.1e versions. Hence had some confusions. Does this means, options specified here only can be used for OpenSSL 1.0.2x releases. Regards Jayalakshmi On Tue, Oct 24, 2017 at 2:31 PM, Matt Caswell wrote: > > > On 24/10/17 07:06, Jayalakshmi bhat wrote: > > Hi All, > > > > I am looking for details on options used to disable or remove unwanted > > ciphers, components while openssl building. This is for OpenSSL 1.0.2h. > > I am seeing many things on internet. But most of them have minimum > > explanation, please can you tell me is there any link that I can refer. > > Have you looked in INSTALL? > > https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/INSTALL > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Wed Oct 25 17:06:45 2017 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Wed, 25 Oct 2017 22:36:45 +0530 Subject: [openssl-users] OpenSSL engine and TPM usage. Message-ID: Hi All, Our device uses TPM to protect certificate private keys. We have written engine interface to integrate TPM functionality into OpenSSL. Thus TPM gets loaded as an engine instance. Also we have mapped RSA operations to TPM APIS as like encryption/decryption etc. Now we are into few issues. there are few applications that wants to use application specific identity certificate. In such cases RSA APIs should not get mapped to TPM APIs. I wanted to know when we use engine instance for encyrption/decryption operation, can it be done selectively? Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Oct 25 21:25:56 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 25 Oct 2017 23:25:56 +0200 Subject: [openssl-users] OpenSSL engine and TPM usage. In-Reply-To: References: Message-ID: <4b47f0e3-0785-ce2c-103f-b5aa933225dd@wisemo.com> On 25/10/2017 19:06, Jayalakshmi bhat wrote: > Hi All, > > Our device uses TPM to protect certificate private keys. We have > written engine interface to integrate TPM functionality into OpenSSL. > Thus TPM gets loaded as an engine instance. > Also we have mapped RSA operations to TPM APIS as? like > encryption/decryption etc. > > Now we are into few issues. there are few applications that wants to > use application specific identity certificate. In such cases RSA APIs > should not get mapped to TPM APIs. > > I wanted to know when we use engine instance for encyrption/decryption > operation, can it be done selectively? > Please beware that many TPM chips were recently discovered to contain a broken RSA key generation algorithm, so public/private key pairs keys to be stored in the TPM should probably be generated off-chip (using the OpenSSL software key generator) and imported into the chip, contrary to what would have been best security practice without this firmware bug. 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 mcr at sandelman.ca Thu Oct 26 00:37:26 2017 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 25 Oct 2017 20:37:26 -0400 Subject: [openssl-users] OpenSSL engine and TPM usage. In-Reply-To: <4b47f0e3-0785-ce2c-103f-b5aa933225dd@wisemo.com> References: <4b47f0e3-0785-ce2c-103f-b5aa933225dd@wisemo.com> Message-ID: <1360.1508978246@obiwan.sandelman.ca> Jakob Bohm wrote: >> I wanted to know when we use engine instance for encyrption/decryption >> operation, can it be done selectively? > Please beware that many TPM chips were recently discovered to contain a > broken RSA key generation algorithm, so public/private key pairs keys > to be stored in the TPM should probably be generated off-chip (using > the OpenSSL software key generator) and imported into the chip, > contrary to what would have been best security practice without this > firmware bug. wow, further evidence that everything needs an upgrade path. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network 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 smadwin at adobe.com Thu Oct 26 01:30:09 2017 From: smadwin at adobe.com (Steven Madwin) Date: Thu, 26 Oct 2017 01:30:09 +0000 Subject: [openssl-users] RSA-PSS Certificate Message-ID: Starting with the definition of the subjectPublicKeyInfo from RFC 5280, Section 4.1 - Basic Certificate fields we see that the entry contains two items: SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } In RFC 4055 - Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Section 3 it states, "CAs that use the RSASSA-PSS algorithm for signing certificates SHOULD include RSASSA-PSS-params in the subjectPublicKeyInfo algorithm parameters in their own certificates." This all leads to me wondering if anyone is aware if there is a plan afoot to add the option of including the RSA-PSS params as a third item in the Subject Public Key Info entry in a future version of OpenSSL? Thanks, Steve Steven Madwin Software QA Engineer Adobe Systems Incorporated 345 Park Avenue, MS-W15 San Jose, CA 95110-2704 USA Phone: 408.536.4343 Fax: 408.536.6024 Steven.Madwin at adobe.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1200 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5451 bytes Desc: not available URL: From jb-openssl at wisemo.com Thu Oct 26 01:48:56 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 26 Oct 2017 03:48:56 +0200 Subject: [openssl-users] RSA-PSS Certificate In-Reply-To: References: Message-ID: <90b7cc86-a9fd-cc6e-9b3b-b278679fca08@wisemo.com> On 26/10/2017 03:30, Steven Madwin via openssl-users wrote: > > Starting with the definition of the subjectPublicKeyInfo from RFC > 5280, Section 4.1 ? Basic Certificate fields we see that the entry > contains two items: > > SubjectPublicKeyInfo ::= SEQUENCE { > > algorithm AlgorithmIdentifier, > > subjectPublicKey BIT STRING } > > In RFC 4055 - Additional Algorithms and Identifiers for RSA > Cryptography for use in the Internet X.509 Public Key Infrastructure > Certificate and Certificate Revocation List (CRL) Profile, Section 3 > it states, ?CAs that use the RSASSA-PSS algorithm for signing > certificates SHOULD include RSASSA-PSS-params in the > subjectPublicKeyInfo algorithm parameters in their own certificates.? > > This all leads to me wondering if anyone is aware if there is a plan > afoot to add the option of including the RSA-PSS params as a third > item in the Subject Public Key Info entry in a future version of OpenSSL? > In the X.509 standard, "AlgorithmIdentifier" is itself a structure (see for example RFC5280 section 4.1.1.2).? The RSASSA-PSS-params is the second element of that structure.? See RFC4055 section 6 for some (bad) examples of AlgorithmIdentifier values, such as rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= { algorithm id-RSASSA-PSS, parameters rSSASSA-PSS-SHA512-params } rSSASSA-PSS-SHA512-params RSASSA-PSS-params ::= { hashAlgorithm sha512Identifier, maskGenAlgorithm mgf1SHA512Identifier, saltLength 20, trailerField 1 } -- Note: The saltLength should be 64, not 20, for --??? rSSASSA-PSS-SHA512-param, see RFC4055 section 3.1 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 smadwin at adobe.com Thu Oct 26 05:32:08 2017 From: smadwin at adobe.com (Steven Madwin) Date: Thu, 26 Oct 2017 05:32:08 +0000 Subject: [openssl-users] RSA-PSS Certificate In-Reply-To: <90b7cc86-a9fd-cc6e-9b3b-b278679fca08@wisemo.com> References: <90b7cc86-a9fd-cc6e-9b3b-b278679fca08@wisemo.com> Message-ID: Thanks. Now all I need to do is figure out what parameter to pass the req or ca command to get the get the subject key info to accept the new algorithm. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm Sent: Wednesday, October 25, 2017 6:49 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] RSA-PSS Certificate On 26/10/2017 03:30, Steven Madwin via openssl-users wrote: > > Starting with the definition of the subjectPublicKeyInfo from RFC > 5280, Section 4.1 ? Basic Certificate fields we see that the entry > contains two items: > > SubjectPublicKeyInfo ::= SEQUENCE { > > algorithm AlgorithmIdentifier, > > subjectPublicKey BIT STRING } > > In RFC 4055 - Additional Algorithms and Identifiers for RSA > Cryptography for use in the Internet X.509 Public Key Infrastructure > Certificate and Certificate Revocation List (CRL) Profile, Section 3 > it states, ?CAs that use the RSASSA-PSS algorithm for signing > certificates SHOULD include RSASSA-PSS-params in the > subjectPublicKeyInfo algorithm parameters in their own certificates.? > > This all leads to me wondering if anyone is aware if there is a plan > afoot to add the option of including the RSA-PSS params as a third > item in the Subject Public Key Info entry in a future version of OpenSSL? > In the X.509 standard, "AlgorithmIdentifier" is itself a structure (see for example RFC5280 section 4.1.1.2).? The RSASSA-PSS-params is the second element of that structure.? See RFC4055 section 6 for some (bad) examples of AlgorithmIdentifier values, such as rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= { algorithm id-RSASSA-PSS, parameters rSSASSA-PSS-SHA512-params } rSSASSA-PSS-SHA512-params RSASSA-PSS-params ::= { hashAlgorithm sha512Identifier, maskGenAlgorithm mgf1SHA512Identifier, saltLength 20, trailerField 1 } -- Note: The saltLength should be 64, not 20, for --??? rSSASSA-PSS-SHA512-param, see RFC4055 section 3.1 Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wisemo. com&data=02%7C01%7C%7C1c955d8fda014c805e2e08d51c13ca2d%7Cfa7b1b5a7b34438794a ed2c178decee1%7C0%7C0%7C636445793698999630&sdata=izbl%2F1JP%2BpWj616mFxiNAaO frEFAXrD6JIXjFw7L%2FdY%3D&reserved=0 Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmta.openssl .org%2Fmailman%2Flistinfo%2Fopenssl-users&data=02%7C01%7C%7C1c955d8fda014c80 5e2e08d51c13ca2d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63644579369899 9630&sdata=rOOgAhtfdLrxpnua8Ncipz4poNQ6O8X%2FFQFID2API5c%3D&reserved=0 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5451 bytes Desc: not available URL: From michael at stroeder.com Thu Oct 26 07:33:49 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Thu, 26 Oct 2017 09:33:49 +0200 Subject: [openssl-users] OpenSSL engine and TPM usage. In-Reply-To: <1360.1508978246@obiwan.sandelman.ca> References: <4b47f0e3-0785-ce2c-103f-b5aa933225dd@wisemo.com> <1360.1508978246@obiwan.sandelman.ca> Message-ID: <8efbab52-8729-31c7-42ab-9868e884e889@stroeder.com> Michael Richardson wrote: > > Jakob Bohm wrote: > >> I wanted to know when we use engine instance for encyrption/decryption > >> operation, can it be done selectively? > > > Please beware that many TPM chips were recently discovered to contain a > > broken RSA key generation algorithm, so public/private key pairs keys > > to be stored in the TPM should probably be generated off-chip (using > > the OpenSSL software key generator) and imported into the chip, > > contrary to what would have been best security practice without this > > firmware bug. > > wow, further evidence that everything needs an upgrade path. From the viewpoint of hardware vendors the upgrade path is selling new hardware. It's simply like that. Not very sustainable... Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From kadlecsik.jozsef at wigner.mta.hu Thu Oct 26 10:22:54 2017 From: kadlecsik.jozsef at wigner.mta.hu (=?ISO-8859-15?Q?Kadlecsik_J=F3zsef?=) Date: Thu, 26 Oct 2017 12:22:54 +0200 (CEST) Subject: [openssl-users] SSL_read() failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init Message-ID: Hello, We upgraded one of our dovecot servers to debian stretch with dovecot 2.2.27 and since then an alpine MUA user has been experiencing random IMAP failures. We enabled debugging at both sides, the client tells only: {XXXX}INBOX: [CLOSED] IMAP connection broken (server response) and we could verify that the client indeed did not receive the server response. On the server side the raw log shows that the correct response is pushed to the client, but at the same time in the debug log we see: Oct 20 18:50:05 mail2 dovecot: imap-login: Debug: SSL error: SSL_read() failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init The openssl package is 1.1.0f-3. The error messsage is total cryptic to me: how could three states be intermixed? I think it's a dovecot issue about how the openssl library is used but I'm unfamiliar with the details of the openssl library: what function, macro is used incorrectly then, at which state? Thanks any help! Best regards, Jozsef -- E-mail : kadlecsik.jozsef at wigner.mta.hu PGP key: http://www.kfki.hu/~kadlec/pgp_public_key.txt Address: Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary From matt at openssl.org Thu Oct 26 10:39:00 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 26 Oct 2017 11:39:00 +0100 Subject: [openssl-users] Wanted details on ./config or Configure options In-Reply-To: References: <57a49aa9-9364-461e-1881-6039175f1ebe@openssl.org> Message-ID: <1a6da94e-b2e0-6449-386e-14162fa711d8@openssl.org> On 25/10/17 18:02, Jayalakshmi bhat wrote: > Hi Matt, > > Thanks a lot. This helps me. I had seen different options for OpenSSL > 1.0.1e versions. Hence had some confusions. > Does this means, options specified here only can be used for OpenSSL > 1.0.2x releases. The INSTALL file is specific to a release. Many options are applicable to both 1.0.1 and 1.0.2 but there may be some differences. We did quite a bit of work on the INSTALL file in the latest 1.1.0 release to make sure all options were documented properly. That happened after the 1.0.2 release so it could be the case that there are some options that are undocumented in 1.0.2. Matt > > Regards > Jayalakshmi > > On Tue, Oct 24, 2017 at 2:31 PM, Matt Caswell > wrote: > > > > On 24/10/17 07:06, Jayalakshmi bhat wrote: > > Hi All, > > > > I am looking for details on options used to disable or remove unwanted > > ciphers, components while openssl building. This is for OpenSSL 1.0.2h. > > I am seeing many things on internet. But most of them have minimum > > explanation, please can you tell me is there any link that I can refer. > > Have you looked in INSTALL? > > https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/INSTALL > > > Matt > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From levitte at openssl.org Thu Oct 26 11:57:07 2017 From: levitte at openssl.org (Richard Levitte) Date: Thu, 26 Oct 2017 13:57:07 +0200 (CEST) Subject: [openssl-users] OpenSSL engine and TPM usage. In-Reply-To: References: Message-ID: <20171026.135707.1421528709764134535.levitte@openssl.org> In message on Wed, 25 Oct 2017 22:36:45 +0530, Jayalakshmi bhat said: bhat.jayalakshmi> Our device uses TPM to protect certificate private bhat.jayalakshmi> keys. We have written engine interface to integrate bhat.jayalakshmi> TPM functionality into OpenSSL. Thus TPM gets loaded bhat.jayalakshmi> as an engine instance. Also we have mapped RSA bhat.jayalakshmi> operations to TPM APIS as like encryption/decryption bhat.jayalakshmi> etc. bhat.jayalakshmi> bhat.jayalakshmi> Now we are into few issues. there are few bhat.jayalakshmi> applications that wants to use application specific bhat.jayalakshmi> identity certificate. In such cases RSA APIs should bhat.jayalakshmi> not get mapped to TPM APIs. bhat.jayalakshmi> bhat.jayalakshmi> I wanted to know when we use engine instance for bhat.jayalakshmi> encyrption/decryption operation, can it be done bhat.jayalakshmi> selectively? Yes, it should be possible. However, this is up to the application, not to your engine. The engine simply offers methods, the application chooses to use some or all of them as default algo implementations through the diverse ENGINE_set_default* functions. For keys such as RSA ones, you can simply create the resulting fetched key with RSA_new_method(e), where |e| is your TPM engine, and your engine's RSA method will be attached to that key rather than the default. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Thu Oct 26 12:23:34 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 26 Oct 2017 13:23:34 +0100 Subject: [openssl-users] SSL_read() failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init In-Reply-To: References: Message-ID: <5b287395-f8a5-e2df-f164-23642d7a8e7d@openssl.org> On 26/10/17 11:22, Kadlecsik J?zsef wrote: > Hello, > > We upgraded one of our dovecot servers to debian stretch with dovecot > 2.2.27 and since then an alpine MUA user has been experiencing random IMAP > failures. > > We enabled debugging at both sides, the client tells only: > > {XXXX}INBOX: [CLOSED] IMAP connection broken (server response) > > and we could verify that the client indeed did not receive the server > response. > > On the server side the raw log shows that the correct response is pushed > to the client, but at the same time in the debug log we see: > > Oct 20 18:50:05 mail2 dovecot: imap-login: Debug: SSL error: SSL_read() > failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init > > The openssl package is 1.1.0f-3. > > The error messsage is total cryptic to me: how could three states be > intermixed? > > I think it's a dovecot issue about how the openssl library is used but I'm > unfamiliar with the details of the openssl library: what function, macro > is used incorrectly then, at which state? SSL_shutdown() is used to shut down an SSL/TLS connection that has already been established (meaning that the SSL/TLS handshake has completed and we are ready to send/receive application data). If you call SSL_shutdown() while the handshake is still in progress then you get the "shutdown while in init" error message. Matt From kadlecsik.jozsef at wigner.mta.hu Thu Oct 26 12:28:01 2017 From: kadlecsik.jozsef at wigner.mta.hu (=?ISO-8859-15?Q?Kadlecsik_J=F3zsef?=) Date: Thu, 26 Oct 2017 14:28:01 +0200 (CEST) Subject: [openssl-users] SSL_read() failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init In-Reply-To: <5b287395-f8a5-e2df-f164-23642d7a8e7d@openssl.org> References: <5b287395-f8a5-e2df-f164-23642d7a8e7d@openssl.org> Message-ID: Hi, On Thu, 26 Oct 2017, Matt Caswell wrote: > > Oct 20 18:50:05 mail2 dovecot: imap-login: Debug: SSL error: SSL_read() > > failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init > > > > The openssl package is 1.1.0f-3. > > > > The error messsage is total cryptic to me: how could three states be > > intermixed? > > > > I think it's a dovecot issue about how the openssl library is used but I'm > > unfamiliar with the details of the openssl library: what function, macro > > is used incorrectly then, at which state? > > SSL_shutdown() is used to shut down an SSL/TLS connection that has > already been established (meaning that the SSL/TLS handshake has > completed and we are ready to send/receive application data). If you > call SSL_shutdown() while the handshake is still in progress then you > get the "shutdown while in init" error message. But why SSL_read() failed with this error message? Best regards, Jozsef -- E-mail : kadlecsik.jozsef at wigner.mta.hu PGP key: http://www.kfki.hu/~kadlec/pgp_public_key.txt Address: Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary From matt at openssl.org Thu Oct 26 12:33:40 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 26 Oct 2017 13:33:40 +0100 Subject: [openssl-users] SSL_read() failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init In-Reply-To: References: <5b287395-f8a5-e2df-f164-23642d7a8e7d@openssl.org> Message-ID: <8adbbb6a-3ff3-4448-68c9-49541363f0ac@openssl.org> On 26/10/17 13:28, Kadlecsik J?zsef wrote: > Hi, > > On Thu, 26 Oct 2017, Matt Caswell wrote: > >>> Oct 20 18:50:05 mail2 dovecot: imap-login: Debug: SSL error: SSL_read() >>> failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init >>> >>> The openssl package is 1.1.0f-3. >>> >>> The error messsage is total cryptic to me: how could three states be >>> intermixed? >>> >>> I think it's a dovecot issue about how the openssl library is used but I'm >>> unfamiliar with the details of the openssl library: what function, macro >>> is used incorrectly then, at which state? >> >> SSL_shutdown() is used to shut down an SSL/TLS connection that has >> already been established (meaning that the SSL/TLS handshake has >> completed and we are ready to send/receive application data). If you >> call SSL_shutdown() while the handshake is still in progress then you >> get the "shutdown while in init" error message. > > But why SSL_read() failed with this error message? That I can't explain since SSL_read() does not call SSL_shutdown(). Plausibly if SSL_read() fails (e.g. because the underlying TCP connection died) then dovecot could call SSL_shutdown() immediately even if it's still not completed the handshake. Then dovecot reports the SSL_read() failure along with the error message from the subsequent attempt to shutdown the connection. Just a theory. Matt From kgoldman at us.ibm.com Thu Oct 26 12:37:14 2017 From: kgoldman at us.ibm.com (Ken Goldman) Date: Thu, 26 Oct 2017 08:37:14 -0400 Subject: [openssl-users] OpenSSL engine and TPM usage. In-Reply-To: <8efbab52-8729-31c7-42ab-9868e884e889@stroeder.com> References: <4b47f0e3-0785-ce2c-103f-b5aa933225dd@wisemo.com> <1360.1508978246@obiwan.sandelman.ca> <8efbab52-8729-31c7-42ab-9868e884e889@stroeder.com> Message-ID: On 10/26/2017 3:33 AM, Michael Str?der wrote: > Michael Richardson wrote: >> >> Jakob Bohm wrote: >> >> wow, further evidence that everything needs an upgrade path. > > From the viewpoint of hardware vendors the upgrade path is selling new > hardware. It's simply like that. Not very sustainable... All the TPMs I know of have the ability to do a "field upgrade". They can accept vendor signed firmware updates. In fact, the newer ones can switch between TPM 1.2 and the new TPM 2.0 API. No need to touch the hardware. From kadlecsik.jozsef at wigner.mta.hu Thu Oct 26 12:50:45 2017 From: kadlecsik.jozsef at wigner.mta.hu (=?ISO-8859-15?Q?Kadlecsik_J=F3zsef?=) Date: Thu, 26 Oct 2017 14:50:45 +0200 (CEST) Subject: [openssl-users] SSL_read() failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init In-Reply-To: <8adbbb6a-3ff3-4448-68c9-49541363f0ac@openssl.org> References: <5b287395-f8a5-e2df-f164-23642d7a8e7d@openssl.org> <8adbbb6a-3ff3-4448-68c9-49541363f0ac@openssl.org> Message-ID: Hi Matt, On Thu, 26 Oct 2017, Matt Caswell wrote: > >>> Oct 20 18:50:05 mail2 dovecot: imap-login: Debug: SSL error: SSL_read() > >>> failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init > > > > But why SSL_read() failed with this error message? > > That I can't explain since SSL_read() does not call SSL_shutdown(). > Plausibly if SSL_read() fails (e.g. because the underlying TCP > connection died) then dovecot could call SSL_shutdown() immediately even > if it's still not completed the handshake. Then dovecot reports the > SSL_read() failure along with the error message from the subsequent > attempt to shutdown the connection. Just a theory. The failures happen after several IMAP commands were already issued/answered in the session and not in an initial phase. Both the server and the client machines are virtual and in the same LAN and were moved around the physical machines just to exclude hardware issues. So can SSL_read() be called before the handshake is completed, i.e. in the "while in init" state? Thanks your answers! Best regards, Jozsef -- E-mail : kadlecsik.jozsef at wigner.mta.hu PGP key: http://www.kfki.hu/~kadlec/pgp_public_key.txt Address: Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary From matt at openssl.org Thu Oct 26 12:57:29 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 26 Oct 2017 13:57:29 +0100 Subject: [openssl-users] SSL_read() failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init In-Reply-To: References: <5b287395-f8a5-e2df-f164-23642d7a8e7d@openssl.org> <8adbbb6a-3ff3-4448-68c9-49541363f0ac@openssl.org> Message-ID: On 26/10/17 13:50, Kadlecsik J?zsef wrote: > Hi Matt, > > On Thu, 26 Oct 2017, Matt Caswell wrote: > >>>>> Oct 20 18:50:05 mail2 dovecot: imap-login: Debug: SSL error: SSL_read() >>>>> failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init >>> >>> But why SSL_read() failed with this error message? >> >> That I can't explain since SSL_read() does not call SSL_shutdown(). >> Plausibly if SSL_read() fails (e.g. because the underlying TCP >> connection died) then dovecot could call SSL_shutdown() immediately even >> if it's still not completed the handshake. Then dovecot reports the >> SSL_read() failure along with the error message from the subsequent >> attempt to shutdown the connection. Just a theory. > > The failures happen after several IMAP commands were already > issued/answered in the session and not in an initial phase. > > Both the server and the client machines are virtual and in the same LAN > and were moved around the physical machines just to exclude hardware > issues. > > So can SSL_read() be called before the handshake is completed, i.e. in the > "while in init" state? Yes SSL_read() can be called before the handshake is completed. If that happens then the first thing it does is attempt to perform a handshake. If you have already exchanged application data over a TLS connection then the handshake must have completed. Plausibly a new one could be initiated via a renegotiation. If you call SSL_shutdown() in the middle of that then I think you will also get the "shutdown while in init" error. Basically don't call SSL_shutdown() if SSL_in_init() is true. Matt > > Thanks your answers! > > Best regards, > Jozsef > -- > E-mail : kadlecsik.jozsef at wigner.mta.hu > PGP key: http://www.kfki.hu/~kadlec/pgp_public_key.txt > Address: Wigner Research Centre for Physics, Hungarian Academy of Sciences > H-1525 Budapest 114, POB. 49, Hungary > From grace.priscilla at gmail.com Thu Oct 26 15:43:06 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Thu, 26 Oct 2017 21:13:06 +0530 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> References: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> Message-ID: Thankyou for the responses. We figured the issue. But now we are getting error -5 from "SSL_connect" and the errno is set to 22 which means invalid argument. Is there a easy way to debug or get logs for SSL_connect. Below is the sequence for the dtls udp connect that we are trying. ssl = SSL_new(ctx) bio = BIO_new_dgram(sock_id,BIO_NOCLOSE) SSL_set_bio(ssl, bio, bio); VI_res = SSL_connect(ssl) Thanks, Grace On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell wrote: > > > On 24/10/17 11:25, Grace Priscilla Jero wrote: > > We are using SSL_accept to accept the connection for which we see the > > failure. Please let know if you have any thoughts. > > Have you set the wbio correctly? Does SSL_get_wbio() return your wbio > object if you call it immediately before SSL_do_handshake()? > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Oct 26 15:53:32 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 26 Oct 2017 16:53:32 +0100 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: References: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> Message-ID: <900be4dc-2b5a-5d1b-1441-b4de6dc26584@openssl.org> On 26/10/17 16:43, Grace Priscilla Jero wrote: > Thankyou for the responses. > We figured the issue. But now we are getting error -5 from "SSL_connect" > and the errno is set to 22 which means invalid argument. > Is there a easy way to debug or get logs for SSL_connect. > > Below is the sequence for the dtls udp connect that we are trying. > ssl = SSL_new(ctx) > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE) > SSL_set_bio(ssl, bio, bio); > VI_res = SSL_connect(ssl) Do you really mean SSL_connect() returns -5? Or do you mean that after a negative return value from SSL_connect() you call SSL_get_error() and that return 5 (SSL_ERROR_SYSCALL)? If you really mean SSL_connect() returns -5 then you need to call SSL_get_error() as a next step. If you are getting SSL_ERROR_SYSCALL then my guess is that there is a problem with sock_id. How do create it? Matt > > > > Thanks, > Grace > > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell > wrote: > > > > On 24/10/17 11:25, Grace Priscilla Jero wrote: > > We are using SSL_accept to accept the connection for which we see the > > failure. Please let know if you have any thoughts. > > Have you set the wbio correctly? Does SSL_get_wbio() return your wbio > object if you call it immediately before SSL_do_handshake()? > > Matt > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From kosowskileszek.leko at gmail.com Thu Oct 26 20:28:02 2017 From: kosowskileszek.leko at gmail.com (Leszek Kosowski) Date: Thu, 26 Oct 2017 22:28:02 +0200 Subject: [openssl-users] ENGINE_by_id creates ENGINE with load_ssl_client_cert = null Message-ID: Hi everyone, When I execute ENGINE_by_id ('pkcs11') I get a ENGINE structure where load_ssl_client_cert (ENGINE_SSL_CLIENT_CERT_PTR type) is null. I'm using Gemalto and Athena cards. Is this behavior related to a card or a pkcs11 engine? This is a problem because calling SSL_CTX_set_client_cert_engine and ENGINE_load_ssl_client_cert calls AV in libeay32.dll. How can I write my own function load_ssl_client_cert? Regards Leszek Kosowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Oct 26 20:34:51 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 26 Oct 2017 20:34:51 +0000 Subject: [openssl-users] OpenSSL engine and TPM usage. In-Reply-To: <1360.1508978246@obiwan.sandelman.ca> References: <4b47f0e3-0785-ce2c-103f-b5aa933225dd@wisemo.com> <1360.1508978246@obiwan.sandelman.ca> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Michael Richardson > Sent: Wednesday, October 25, 2017 18:37 > > Jakob Bohm wrote: > >???? > Please beware that many TPM chips were recently discovered to contain a >???? > broken RSA key generation algorithm, so public/private key pairs keys >???? > to be stored in the TPM should probably be generated off-chip (using >???? > the OpenSSL software key generator) and imported into the chip, >???? > contrary to what would have been best security practice without this >???? > firmware bug. > > wow, further evidence that everything needs an upgrade path. Specifically, it's devices using Infineon chips. AIUI, that includes most TPMs and many HSMs, but not, for example, the NitroKey HSM. The researchers who documented the problem, which they've named ROCA, have a site for it: https://crocs.fi.muni.cz/public/papers/rsa_ccs17 They aren't describing the exact nature of the issue yet (at least the last I checked), but it has something to do with the RSA primes having a structure that lets attackers greatly speed factoring. I can imagine a number of optimizations if you know enough about the structure of the primes. They've provided a Python program that can identify problematic keys with high probability, and it's available as a web service, etc. The program doesn't reveal what the mystery structural issues are; it seems to be a Bloom filter that's been trained to identify vulnerable keys (which is pretty interesting in itself). All that's just based on a pretty cursory look, though, so I may be wrong. Michael Wojcik Distinguished Engineer, Micro Focus From freemonj at gmail.com Thu Oct 26 20:37:15 2017 From: freemonj at gmail.com (Freemon Johnson) Date: Thu, 26 Oct 2017 16:37:15 -0400 Subject: [openssl-users] OpenSSL engine and TPM usage. In-Reply-To: References: Message-ID: Hi Jayalakshmi, Is your implementation OSS or intellectual property? If it is OSS can you please provide the URL? Regards, Freemon On Wed, Oct 25, 2017 at 1:06 PM, Jayalakshmi bhat < bhat.jayalakshmi at gmail.com> wrote: > Hi All, > > Our device uses TPM to protect certificate private keys. We have written > engine interface to integrate TPM functionality into OpenSSL. Thus TPM gets > loaded as an engine instance. > Also we have mapped RSA operations to TPM APIS as like > encryption/decryption etc. > > Now we are into few issues. there are few applications that wants to use > application specific identity certificate. In such cases RSA APIs should > not get mapped to TPM APIs. > > I wanted to know when we use engine instance for encyrption/decryption > operation, can it be done selectively? > > Regards > Jayalakshmi > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From agale at alticast.com Thu Oct 26 22:47:50 2017 From: agale at alticast.com (Andrew Gale) Date: Thu, 26 Oct 2017 22:47:50 +0000 Subject: [openssl-users] OpenSSL outputs entire CA bundle with libcurl Message-ID: <1add3dc7826c431ea261e749514b35b0@MDBA.ALTICAST.COM> Hello all, First, some config info: OpenSSL v1.0.1t PLATFORM=arm-linux- OPTIONS=enable-tls enable-threads enable-shared --cross-compile-prefix=arm-linux- -pthread --prefix=/usr/local no-ec_nistp_64_gcc_128 no-gmp no-idea no-jpake no-krb5 no-md2 no-mdc2 no-rc5 no-rfc3779 no-ripemd no-sctp no-ssl2 no-store no-unit-test no-weak-ssl-ciphers no-zlib no-zlib-dynamic no-static-engine CONFIGURE_ARGS=enable-tls no-zlib threads no-idea no-mdc2 no-rc5 no-ripemd shared --cross-compile-prefix=arm-linux- arm-linux- -pthread --prefix=/usr/local SHLIB_TARGET=linux-shared? When making a request every certificate in the cacert.pem bundle is output before the response (without the BEGIN/END): <<< Make request >>> MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCQkUx GTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNVBAMTEkds b2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAwMDBaFw0yODAxMjgxMjAwMDBaMFcxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYD VQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDa DuaZjc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6NiY6arymAZavpxy0Sy6sc THAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp1Wrjsok6Vjk4bwY8iGlb Kk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdGsnUOhugZitVtbNV4FpWi6cgKOOvyJBNP c1STE4U6G7weNLWLBYy5d4ux2x8gkasJU26Qzns3dLlwR5EiUWMWea6xrkEmCMgZK9FGqkjWZCrX gzT/LCrBbBlDSgeF59N89iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUF AAOCAQEA1nPnfE920I2/7LqivjTFKDK1fPxsnCwrvQmeU79rXqoRSLblCKOzyj1hTdNGCbM+w6Dj Y1Ub8rrvrTnhQ7k4o+YviiY776BQVvnGCv04zcQLcFGUl5gE38NflNUVyRRBnMRddWQVDf9VMOyG j/8N7yy5Y0b2qvzfvGn9LhJIZJrglfCm7ymPAbEVtQwdpf5pLGkkeB6zpxxxYu7KyJesF12KwvhH hm4qxFYxldBniYUr+WymXUadDKqC5JlR3XC321Y9YeRq4VzW9v493kHMB65jUr9TU/Qr6cf9tveC X4XSQRjbgbMEHMUfpIBvFSDJ3gyICh3WZlXi/EjJKSZp4A== <<< All other certs follow >>> > POST /ftd/inform HTTP/1.1 Host: Authorization: Basic Accept: */* Content-Type: application/json Content-Length: 267 < HTTP/1.1 200 OK < Server: openresty < Date: Thu, 26 Oct 2017 18:39:48 GMT < Content-Type: application/json;charset=UTF-8 < Transfer-Encoding: chunked < Connection: keep-alive < Cache-Control: no-cache, no-store < x-trace-id: 70110f353234-275b-0000000000013e4b < 334 bytes retrieved Daniel of cURL believes this is an issue with the OpenSSL lib since it's the only component involved that actually knows of the entire CA cert bundle. libcurl lets the SSL library deal with it and never gets to know the entire thing. Does anyone know what could be causing the CA bundle to get spewed out every time a request is made? I received this library with the config already set so I'm not exactly sure if this is caused by one of those options. (and this does not occur when making the same request with the curl command from my host machine) Thanks for your time, Andy Gale From cognet at ci0.org Thu Oct 26 23:13:44 2017 From: cognet at ci0.org (Olivier Houchard) Date: Fri, 27 Oct 2017 01:13:44 +0200 Subject: [openssl-users] Early data based on SNI with OpenSSL 1.1.1 In-Reply-To: <605d34bf-1ae3-1160-7b92-4b132623d102@openssl.org> References: <20171023151630.GA79754@ci0.org> <605d34bf-1ae3-1160-7b92-4b132623d102@openssl.org> Message-ID: <20171026231344.GA24309@ci0.org> Hi Matt, Sorry for the late answer. On Mon, Oct 23, 2017 at 04:31:02PM +0100, Matt Caswell wrote: > > > On 23/10/17 16:16, Olivier Houchard wrote: > > Hi, > > > > I'm trying to use OpenSSL 1.1.1 to accept or reject early data based on > > the SNI, and I'm a bit confused on how to do so. > > The problem I have is, I don't know the SNI before the client hello > > callback is called, and at that time it seems to be too late to make a > > decision for early data. Either the callback is called from > > SSL_do_handshake(), and then any call to SSL_read_early_data() will fail > > with SSL_ERROR_SSL, and early data will be rejected, or it is called if > > I call SSL_read_early_data() first, but then early data will be > > considered accepted no matter what. > > > > I tried returning -1 from the client hello callback, but if called from > > SSL_do_handshake to indicate early data are to be read, it seems to be too > > late to call SSL_read_early_data() anyway, and if called from > > SSL_read_early_data() to indicate we should stop reading early data, it > > mostly works, except as s->early_data_state will be > > SSL_EARLY_DATA_ACCEPT_RETRY, and so any call to SSL_Read() will fail > > because of that test in ssl_read_internal() : > > if (s->early_data_state == SSL_EARLY_DATA_CONNECT_RETRY > > || s->early_data_state == SSL_EARLY_DATA_ACCEPT_RETRY) { > > SSLerr(SSL_F_SSL_READ_INTERNAL, > > ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED); > > return 0; > > } > > > > Am I missing something obvious ? Is there any way I can accept or reject > > early data based on the SNI ? > > >From the docs: > > https://www.openssl.org/docs/manmaster/man3/SSL_set_max_early_data.html > > "When a session is created between a server and a client the server will > specify the maximum amount of any early data that it will accept on any > future connection attempt. By default this is approximately 16k. A > server may override this default value by calling > SSL_CTX_set_max_early_data() or SSL_set_max_early_data() to set it for > the whole SSL_CTX or an individual SSL object respectively. Similarly > the SSL_CTX_get_max_early_data() and SSL_get_max_early_data() functions > can be used to obtain the current maximum early data settings for the > SSL_CTX and SSL objects respectively." > > So, probably the best way to do this is to set the max early data for > the server CTXs that you don't want to accept early_data to 0. Then any > sessions they issue will not allow early_data to be used. If a client > does attempt to use that session to send early data then it then it will > be automatically rejected. > This didn't seem to do the trick, however, > If that doesn't work for you another way (I think?) to do this would be > to set the max early data for that SSL object (using > SSL_set_max_early_data()) to 0 during the callback. > This definitively did ! Thanks a lot ! Regards, Olivier From grace.priscilla at gmail.com Fri Oct 27 07:09:02 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Fri, 27 Oct 2017 12:39:02 +0530 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: <900be4dc-2b5a-5d1b-1441-b4de6dc26584@openssl.org> References: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> <900be4dc-2b5a-5d1b-1441-b4de6dc26584@openssl.org> Message-ID: Hi Matt, SSL_get_error() returns 5. It is the same socket using which the UDP connection is established. Could you suggest some logging that can be done for OPENSSL. Thanks, Grace On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell wrote: > > > On 26/10/17 16:43, Grace Priscilla Jero wrote: > > Thankyou for the responses. > > We figured the issue. But now we are getting error -5 from "SSL_connect" > > and the errno is set to 22 which means invalid argument. > > Is there a easy way to debug or get logs for SSL_connect. > > > > Below is the sequence for the dtls udp connect that we are trying. > > ssl = SSL_new(ctx) > > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE) > > SSL_set_bio(ssl, bio, bio); > > VI_res = SSL_connect(ssl) > > Do you really mean SSL_connect() returns -5? Or do you mean that after a > negative return value from SSL_connect() you call SSL_get_error() and > that return 5 (SSL_ERROR_SYSCALL)? > > If you really mean SSL_connect() returns -5 then you need to call > SSL_get_error() as a next step. > > If you are getting SSL_ERROR_SYSCALL then my guess is that there is a > problem with sock_id. How do create it? > > Matt > > > > > > > > > > Thanks, > > Grace > > > > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell > > wrote: > > > > > > > > On 24/10/17 11:25, Grace Priscilla Jero wrote: > > > We are using SSL_accept to accept the connection for which we see > the > > > failure. Please let know if you have any thoughts. > > > > Have you set the wbio correctly? Does SSL_get_wbio() return your wbio > > object if you call it immediately before SSL_do_handshake()? > > > > Matt > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Oct 27 12:07:26 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 27 Oct 2017 14:07:26 +0200 Subject: [openssl-users] OpenSSL outputs entire CA bundle with libcurl In-Reply-To: <1add3dc7826c431ea261e749514b35b0@MDBA.ALTICAST.COM> References: <1add3dc7826c431ea261e749514b35b0@MDBA.ALTICAST.COM> Message-ID: <99b6956b-417d-44f3-d2da-22f2052c235f@wisemo.com> On 27/10/2017 00:47, Andrew Gale wrote: > Hello all, > > First, some config info: > OpenSSL v1.0.1t > > PLATFORM=arm-linux- > OPTIONS=enable-tls enable-threads enable-shared --cross-compile-prefix=arm-linux- -pthread --prefix=/usr/local no-ec_nistp_64_gcc_128 no-gmp no-idea no-jpake no-krb5 no-md2 no-mdc2 no-rc5 no-rfc3779 no-ripemd no-sctp no-ssl2 no-store no-unit-test no-weak-ssl-ciphers no-zlib no-zlib-dynamic no-static-engine > CONFIGURE_ARGS=enable-tls no-zlib threads no-idea no-mdc2 no-rc5 no-ripemd shared --cross-compile-prefix=arm-linux- arm-linux- -pthread --prefix=/usr/local > SHLIB_TARGET=linux-shared? > > > When making a request every certificate in the cacert.pem bundle is output before the response (without the BEGIN/END): > > <<< Make request >>> > MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCQkUx > GTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNVBAMTEkds > b2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAwMDBaFw0yODAxMjgxMjAwMDBaMFcxCzAJBgNV > BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYD > VQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDa > DuaZjc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6NiY6arymAZavpxy0Sy6sc > THAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp1Wrjsok6Vjk4bwY8iGlb > Kk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdGsnUOhugZitVtbNV4FpWi6cgKOOvyJBNP > c1STE4U6G7weNLWLBYy5d4ux2x8gkasJU26Qzns3dLlwR5EiUWMWea6xrkEmCMgZK9FGqkjWZCrX > gzT/LCrBbBlDSgeF59N89iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV > HRMBAf8EBTADAQH/MB0GA1UdDgQWBBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUF > AAOCAQEA1nPnfE920I2/7LqivjTFKDK1fPxsnCwrvQmeU79rXqoRSLblCKOzyj1hTdNGCbM+w6Dj > Y1Ub8rrvrTnhQ7k4o+YviiY776BQVvnGCv04zcQLcFGUl5gE38NflNUVyRRBnMRddWQVDf9VMOyG > j/8N7yy5Y0b2qvzfvGn9LhJIZJrglfCm7ymPAbEVtQwdpf5pLGkkeB6zpxxxYu7KyJesF12KwvhH > hm4qxFYxldBniYUr+WymXUadDKqC5JlR3XC321Y9YeRq4VzW9v493kHMB65jUr9TU/Qr6cf9tveC > X4XSQRjbgbMEHMUfpIBvFSDJ3gyICh3WZlXi/EjJKSZp4A== > <<< All other certs follow >>> >> POST /ftd/inform HTTP/1.1 > Host: > Authorization: Basic > Accept: */* > Content-Type: application/json > Content-Length: 267 > > < HTTP/1.1 200 OK > < Server: openresty > < Date: Thu, 26 Oct 2017 18:39:48 GMT > < Content-Type: application/json;charset=UTF-8 > < Transfer-Encoding: chunked > < Connection: keep-alive > < Cache-Control: no-cache, no-store > < x-trace-id: 70110f353234-275b-0000000000013e4b > < > 334 bytes retrieved > > > Daniel of cURL believes this is an issue with the OpenSSL lib since it's the only component involved that actually > knows of the entire CA cert bundle. libcurl lets the SSL library deal with it and never gets to know the entire thing. > > Does anyone know what could be causing the CA bundle to get spewed out every time a request is made? > I received this library with the config already set so I'm not exactly sure if this is caused by one of those options. > (and this does not occur when making the same request with the curl command from my host machine) > Please clarify: - Is it being output to the network or to the terminal window where ?curl is used? - Is it being output as shown (Base64 text with ending "=" signs and ?a newline after each cert) or is it being output in another form ?that you just describe that way? 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 david7815 at gmail.com Fri Oct 27 12:35:32 2017 From: david7815 at gmail.com (David Barishev) Date: Fri, 27 Oct 2017 15:35:32 +0300 Subject: [openssl-users] Passing custom CFLAGS,LDFLAGS to configure ? Message-ID: Hello, I am building a custom script for building openssl for android, and i want to use unified headers which are enabled by default with ndk r15+. For this i need to pass custom CFLAGS and LDFLAGS, which i was able to successfully compile openssl when patching the makefile by myself. How to do it directly from configure ? Thanks all ! -- *Have a nice day David Barishev.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Fri Oct 27 12:53:15 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 27 Oct 2017 07:53:15 -0500 Subject: [openssl-users] Passing custom CFLAGS,LDFLAGS to configure ? In-Reply-To: References: Message-ID: On 10/27/2017 07:35 AM, David Barishev wrote: > Hello, > I am building a custom script for building openssl for android, and i > want to use unified headers which are enabled by default with ndk r15+. > For this i need to pass custom CFLAGS and LDFLAGS, which i was able to > successfully compile openssl when patching the makefile by myself. > How to do it directly from configure ? > The current model is that you just pass the relevant CFLAGS and LDFLAGS contents directly to Configure and they are "automagically" determined to be the corresponding CFLAGS/LDFLAGS. E.g., you could ./Configure --strict-warnings -ggdb3 -L/usr/local/lib -ltinfo -I/opt/local/include linux-x86_64 -Ben From ch at coderhacks.com Fri Oct 27 16:51:31 2017 From: ch at coderhacks.com (ch) Date: Fri, 27 Oct 2017 18:51:31 +0200 Subject: [openssl-users] CMS/SMIME: RSASSA-PSS, RSAES-OAEP Message-ID: <2afefa8c-ccac-5872-1fd5-639d9ce3e793@coderhacks.com> Hello! I have an application that uses 3DES for encryption and SHA1 for signing. It is MIME-content and so I use SMIME and CMS. Is there a way to do RSAES-OAEP for keyencryption and RSASSA-PSS for signing with the commandline-tools too or do I need to use the API? Cheers, Chris From agale at alticast.com Fri Oct 27 17:11:04 2017 From: agale at alticast.com (Andrew Gale) Date: Fri, 27 Oct 2017 17:11:04 +0000 Subject: [openssl-users] OpenSSL outputs entire CA bundle with libcurl In-Reply-To: <99b6956b-417d-44f3-d2da-22f2052c235f@wisemo.com> References: <1add3dc7826c431ea261e749514b35b0@MDBA.ALTICAST.COM>, <99b6956b-417d-44f3-d2da-22f2052c235f@wisemo.com> Message-ID: <7819f248b5b7485ca5c0baeb134602c1@MDBA.ALTICAST.COM> Jakob, My responses inline : - Is it being output to the network or to the terminal window where curl is used? The output occurs in the terminal window when the program is run. - Is it being output as shown (Base64 text with ending "=" signs and a newline after each cert) or is it being output in another form that you just describe that way? It is output as shown. Base64 text ending in "=" signs, newline after each cert, but with no "BEGIN / END CERTIFICATE" Thanks, Andy From jb-openssl at wisemo.com Fri Oct 27 17:16:22 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 27 Oct 2017 19:16:22 +0200 Subject: [openssl-users] OpenSSL outputs entire CA bundle with libcurl In-Reply-To: <7819f248b5b7485ca5c0baeb134602c1@MDBA.ALTICAST.COM> References: <1add3dc7826c431ea261e749514b35b0@MDBA.ALTICAST.COM> <99b6956b-417d-44f3-d2da-22f2052c235f@wisemo.com> <7819f248b5b7485ca5c0baeb134602c1@MDBA.ALTICAST.COM> Message-ID: <0fd1f8b8-d84c-5316-03e8-336db87272c3@wisemo.com> On 27/10/2017 19:11, Andrew Gale wrote: > Jakob, > > My responses inline : > > > - Is it being output to the network or to the terminal window where > curl is used? > > The output occurs in the terminal window when the program is run. > > - Is it being output as shown (Base64 text with ending "=" signs and > a newline after each cert) or is it being output in another form > that you just describe that way? > > It is output as shown. Base64 text ending in "=" signs, newline after > each cert, but with no "BEGIN / END CERTIFICATE" > In that case, it looks like it is debug output.? Did you by any chance configure or run curl with options to print lots of debug traces? Perhaps such an option is causing something to print each trusted CA cert as it is loaded into memory or checked. 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 sanandchoubey at yahoo.com Mon Oct 30 11:34:35 2017 From: sanandchoubey at yahoo.com (Anand Choubey) Date: Mon, 30 Oct 2017 11:34:35 +0000 (UTC) Subject: [openssl-users] SSL_read sys error 60. References: <1998833505.5816423.1509363275599.ref@mail.yahoo.com> Message-ID: <1998833505.5816423.1509363275599@mail.yahoo.com> Hi, Client Platform: OSX 10.12OpenSSL: openssl-1.0.2g, built by myself i.e. no system default OpenSSL? server platform: ubuntu 16.4OpenSSL: 1.1.0e built by myself i.e. no system default OpenSSL? Issue:?SSL_read gets failed with?errno?is 60 (ETIMEDOUT, operation?timed out),?ERR_get_error return 0 at client side. ? ? ? ? ? ? ??SSL_read gets failed frequently at client side, ERR_get_error return 0 and?errno is 60 i.e.?ETIMEDOUT.? The client socket is marked non-blocking socket and recv timeout is set. Ideally,? there should not wait inside the SSL_read. I understand this 'may be' socket error but under what probable conditions?SSL_read??returns with error 60. Interesting point is, this issue may occur in ongoing traffic.? 'select' method is used. Could you please give me the pointer to debug this issue further? ThanksAnand Choubey -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Oct 30 13:50:45 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 30 Oct 2017 13:50:45 +0000 Subject: [openssl-users] Forthcoming OpenSSL releases Message-ID: Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.0g and 1.0.2m. These releases will be made available on 2nd November 2017 between approximately 1300-1700 UTC. This is a bug-fix release. It will also include a fix for the low severity security issue previously published here: https://www.openssl.org/news/secadv/20170828.txt Please also note that, as per our previous announcements, support for 1.0.1 ended on 31st December 2016. Yours The OpenSSL Project Team From gupta_nvn at yahoo.com Mon Oct 30 20:36:57 2017 From: gupta_nvn at yahoo.com (naveen gupta) Date: Mon, 30 Oct 2017 20:36:57 +0000 (UTC) Subject: [openssl-users] Compiling OpenSSL 1.0.2l static library with FIPS -2.0.16 on Windows References: <1224258743.7059750.1509395817353.ref@mail.yahoo.com> Message-ID: <1224258743.7059750.1509395817353@mail.yahoo.com> Hi, I have am trying to compile OpenSSL 1.0.2l static library using FIPS - 2.0.16 on Windows 2012 R2, Visual Studio 2015,? using reference from?https://www.openssl.org/docs/fips/UserGuide-2.0.pdf?, page #68. Step 1: - cd?openssl-fips-2.0.16 - ms\do_fips Step 2: - cd openssl-1.0.2l - set FIPSDIR=C:\usr\local\ssl\fips-2.0 - perl Configure? ? ? ?VC-WIN64A fips --with-fipsdir=%FIPSDIR% no-shared zlib no-idea no-mdc2 no-rc5 no-ssl2 no-ssl3 - nmake -f ms\nt.mak all I see that ms\do_fips compile the code with /MD, and somehow step 2 (nmake -f ms\nt.mak all) also ends up compiling with /MD switch. The application now requires the dynamic runt time libraries and compile and run time. OpenSSL static libraries builds fine with /MT switch without FIPS module, so there's something with FIPS module that ends up setting /MD switch. Has anyone else faced this problem? As per user guide, the FIPS module should build fine with static libraries, but looks like there is some issue with it. Is there any option that can be supplied to do_fips.bat, or a different build script that needs to be run? Appreciate any help on this. Thanks,NG?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Oct 30 23:06:27 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 30 Oct 2017 23:06:27 +0000 Subject: [openssl-users] Forthcoming OpenSSL releases In-Reply-To: References: Message-ID: <71d5efbd-31fc-f4b0-91a7-38a95def2c6d@openssl.org> On 30/10/17 13:50, Matt Caswell wrote: > Forthcoming OpenSSL releases > ============================ > > The OpenSSL project team would like to announce the forthcoming release > of OpenSSL versions 1.1.0g and 1.0.2m. > > These releases will be made available on 2nd November 2017 between > approximately 1300-1700 UTC. > > This is a bug-fix release. It will also include a fix for the low > severity security issue previously published here: > https://www.openssl.org/news/secadv/20170828.txt Correction: It will additionally include a fix for a moderate level security issue. > > Please also note that, as per our previous announcements, support for > 1.0.1 ended on 31st December 2016. > > Yours > > The OpenSSL Project Team > From Karyn.Ulriksen at riverbed.com Tue Oct 31 00:20:27 2017 From: Karyn.Ulriksen at riverbed.com (Karyn Ulriksen) Date: Tue, 31 Oct 2017 00:20:27 +0000 Subject: [openssl-users] cross-compiled binary with fips only generates encrypted string output Message-ID: I'm trying to figure out what I have done wrong here... Using openssl-fips-2.0.16 and openssl 1.0.2l (please let me know if there is a newer/better combo to use) Openssl-fips config is: ./Configure linux-generic64 --prefix=/usr/openssl --openssldir=/usr/openssl --cross-compile-prefix=XYZ- Openssl config is: export FIPSDIR=/xyz-cross-compiled-image-dir/usr/openssl FIPS_OBJECT_MODULE=/xyz-cross-compiled-image-dir/usr/openssl/lib/fipscanister.o ./Configure linux-generic64 shared fips --prefix=/usr/openssl --openssldir=/usr/openssl --with-fipsdir=/xyz-cross-compiled-image-dir/usr/openssl There are no complaints while compiling, but when I load it onto the embedded linux device that it is targeted for and run simple version or invoke CLI, i see: # ./openssl version 878ea783d20992bcfcad2d1c474bfc01cc80d831 # ./openssl 878ea783d20992bcfcad2d1c474bfc01cc80d831 Can anyone throw me a bone? Thanks! K -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Tue Oct 31 06:06:33 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Tue, 31 Oct 2017 11:36:33 +0530 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: References: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> <900be4dc-2b5a-5d1b-1441-b4de6dc26584@openssl.org> Message-ID: Thankyou for the suggestions. After correcting few options the "ClientHello" goes successfully but we have failure in "DTLSv1_listen". There are'nt any cookies in the Client Hello request. But DTLSv1_listen return error and the failure in see is in "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);" We are using 1.1.0f version. Is there a way we can disable cookies? Thanks, Grace On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero < grace.priscilla at gmail.com> wrote: > Hi Matt, > > SSL_get_error() returns 5. > It is the same socket using which the UDP connection is established. > Could you suggest some logging that can be done for OPENSSL. > > Thanks, > Grace > > > On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell wrote: > >> >> >> On 26/10/17 16:43, Grace Priscilla Jero wrote: >> > Thankyou for the responses. >> > We figured the issue. But now we are getting error -5 from "SSL_connect" >> > and the errno is set to 22 which means invalid argument. >> > Is there a easy way to debug or get logs for SSL_connect. >> > >> > Below is the sequence for the dtls udp connect that we are trying. >> > ssl = SSL_new(ctx) >> > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE) >> > SSL_set_bio(ssl, bio, bio); >> > VI_res = SSL_connect(ssl) >> >> Do you really mean SSL_connect() returns -5? Or do you mean that after a >> negative return value from SSL_connect() you call SSL_get_error() and >> that return 5 (SSL_ERROR_SYSCALL)? >> >> If you really mean SSL_connect() returns -5 then you need to call >> SSL_get_error() as a next step. >> >> If you are getting SSL_ERROR_SYSCALL then my guess is that there is a >> problem with sock_id. How do create it? >> >> Matt >> >> >> > >> > >> > >> > Thanks, >> > Grace >> > >> > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell > > > wrote: >> > >> > >> > >> > On 24/10/17 11:25, Grace Priscilla Jero wrote: >> > > We are using SSL_accept to accept the connection for which we see >> the >> > > failure. Please let know if you have any thoughts. >> > >> > Have you set the wbio correctly? Does SSL_get_wbio() return your >> wbio >> > object if you call it immediately before SSL_do_handshake()? >> > >> > Matt >> > >> > -- >> > openssl-users mailing list >> > To unsubscribe: >> > https://mta.openssl.org/mailman/listinfo/openssl-users >> > >> > >> > >> > >> > >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch at coderhacks.com Tue Oct 31 09:53:11 2017 From: ch at coderhacks.com (ch) Date: Tue, 31 Oct 2017 10:53:11 +0100 Subject: [openssl-users] CMS-supported ciphers Message-ID: <75cb2edf-976a-90a1-b7ee-7a42ba604f08@coderhacks.com> Hello! I see the CMS-Interface (CMS_encrypt, X_write_CMS, ...) does not support AES128-GCM. https://mta.openssl.org/pipermail/openssl-dev/2015-April/001177.html Is there a list of all supporting ciphers for CMS? Or how can I find out without trying it? Thanks! Chris From matt at openssl.org Tue Oct 31 10:20:09 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Oct 2017 10:20:09 +0000 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: References: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> <900be4dc-2b5a-5d1b-1441-b4de6dc26584@openssl.org> Message-ID: <5bbbfef4-10e1-3920-efcd-ca4db9f0bee0@openssl.org> On 31/10/17 06:06, Grace Priscilla Jero wrote: > Thankyou for the suggestions. After correcting few options the > "ClientHello" goes successfully but we have failure in "DTLSv1_listen". > There are'nt any cookies in the Client Hello request. > But DTLSv1_listen return error and the failure in see is in > "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);" This is most likely because you haven't called SSL_CTX_set_cookie_generate_cb() first. > We are using 1.1.0f version. Is there a way we can disable cookies? Well the whole *point* of calling DTLSv1_listen() is to generate those cookies. If you don't want cookies, don't call it. Matt > > Thanks, > Grace > > On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero > > wrote: > > Hi Matt, > > SSL_get_error()? returns 5.? > It is the same socket using which the UDP connection is established. > Could you suggest some logging that can be done for OPENSSL. > > Thanks, > Grace > > > On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell > wrote: > > > > On 26/10/17 16:43, Grace Priscilla Jero wrote: > > Thankyou for the responses. > > We figured the issue. But now we are getting error -5 from "SSL_connect" > > and the errno is set to 22 which means invalid argument. > > Is there a easy way to debug or get logs for SSL_connect. > > > > Below is the sequence for the dtls udp connect that we are trying. > > ssl = SSL_new(ctx) > > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE) > > SSL_set_bio(ssl, bio, bio); > > VI_res = SSL_connect(ssl) > > Do you really mean SSL_connect() returns -5? Or do you mean that > after a > negative return value from SSL_connect() you call > SSL_get_error() and > that return 5 (SSL_ERROR_SYSCALL)? > > If you really mean SSL_connect() returns -5 then you need to call > SSL_get_error() as a next step. > > If you are getting SSL_ERROR_SYSCALL then my guess is that there > is a > problem with sock_id. How do create it? > > Matt > > > > > > > > > > Thanks, > > Grace > > > > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell > > >> wrote: > > > > > > > >? ? ?On 24/10/17 11:25, Grace Priscilla Jero wrote: > >? ? ?> We are using SSL_accept to accept the connection for which we see the > >? ? ?> failure. Please let know if you have any thoughts. > > > >? ? ?Have you set the wbio correctly? Does SSL_get_wbio() return your wbio > >? ? ?object if you call it immediately before SSL_do_handshake()? > > > >? ? ?Matt > > > >? ? ?-- > >? ? ?openssl-users mailing list > >? ? ?To unsubscribe: > >? ? ?https://mta.openssl.org/mailman/listinfo/openssl-users > > >? ? ? > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > From grace.priscilla at gmail.com Tue Oct 31 10:40:40 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Tue, 31 Oct 2017 16:10:40 +0530 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: <5bbbfef4-10e1-3920-efcd-ca4db9f0bee0@openssl.org> References: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> <900be4dc-2b5a-5d1b-1441-b4de6dc26584@openssl.org> <5bbbfef4-10e1-3920-efcd-ca4db9f0bee0@openssl.org> Message-ID: Hi Matt, yes, we have found that later and have add the call backs. But we never get the Client Hello with cookie. The Hello verify request is sent from the server. Thanks for pointing out that listen was for cookies. Now without that providing the SSL_accept, it hangs. We are unable to figure out why it hangs. Only client hello is sent. Is there any way to spot what is going wrong. Thanks, Grace On Tue, Oct 31, 2017 at 3:50 PM, Matt Caswell wrote: > > > On 31/10/17 06:06, Grace Priscilla Jero wrote: > > Thankyou for the suggestions. After correcting few options the > > "ClientHello" goes successfully but we have failure in "DTLSv1_listen". > > There are'nt any cookies in the Client Hello request. > > But DTLSv1_listen return error and the failure in see is in > > "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);" > > This is most likely because you haven't called > SSL_CTX_set_cookie_generate_cb() first. > > > We are using 1.1.0f version. Is there a way we can disable cookies? > > Well the whole *point* of calling DTLSv1_listen() is to generate those > cookies. If you don't want cookies, don't call it. > > Matt > > > > > Thanks, > > Grace > > > > On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero > > > wrote: > > > > Hi Matt, > > > > SSL_get_error() returns 5. > > It is the same socket using which the UDP connection is established. > > Could you suggest some logging that can be done for OPENSSL. > > > > Thanks, > > Grace > > > > > > On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell > > wrote: > > > > > > > > On 26/10/17 16:43, Grace Priscilla Jero wrote: > > > Thankyou for the responses. > > > We figured the issue. But now we are getting error -5 from > "SSL_connect" > > > and the errno is set to 22 which means invalid argument. > > > Is there a easy way to debug or get logs for SSL_connect. > > > > > > Below is the sequence for the dtls udp connect that we are > trying. > > > ssl = SSL_new(ctx) > > > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE) > > > SSL_set_bio(ssl, bio, bio); > > > VI_res = SSL_connect(ssl) > > > > Do you really mean SSL_connect() returns -5? Or do you mean that > > after a > > negative return value from SSL_connect() you call > > SSL_get_error() and > > that return 5 (SSL_ERROR_SYSCALL)? > > > > If you really mean SSL_connect() returns -5 then you need to call > > SSL_get_error() as a next step. > > > > If you are getting SSL_ERROR_SYSCALL then my guess is that there > > is a > > problem with sock_id. How do create it? > > > > Matt > > > > > > > > > > > > > > > > Thanks, > > > Grace > > > > > > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell < > matt at openssl.org > > > >> wrote: > > > > > > > > > > > > On 24/10/17 11:25, Grace Priscilla Jero wrote: > > > > We are using SSL_accept to accept the connection for > which we see the > > > > failure. Please let know if you have any thoughts. > > > > > > Have you set the wbio correctly? Does SSL_get_wbio() > return your wbio > > > object if you call it immediately before > SSL_do_handshake()? > > > > > > Matt > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 31 10:46:47 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Oct 2017 10:46:47 +0000 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: References: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> <900be4dc-2b5a-5d1b-1441-b4de6dc26584@openssl.org> <5bbbfef4-10e1-3920-efcd-ca4db9f0bee0@openssl.org> Message-ID: <2fb49d2d-b48e-ba7a-54c7-69b2b7193676@openssl.org> On 31/10/17 10:40, Grace Priscilla Jero wrote: > Hi Matt, > yes, we have found that later and have add the call backs. But we never > get the Client Hello with cookie. The Hello verify request is sent from > the server. > > Thanks for pointing out that listen was for cookies. Now without that > providing the SSL_accept, it hangs. We are unable to figure out why it > hangs. Only client hello is sent. Is there any way to spot what is going > wrong. I suggest you use Wireshark to take a look what is happening on the wire. Matt > > Thanks, > Grace > > On Tue, Oct 31, 2017 at 3:50 PM, Matt Caswell > wrote: > > > > On 31/10/17 06:06, Grace Priscilla Jero wrote: > > Thankyou for the suggestions. After correcting few options the > > "ClientHello" goes successfully but we have failure in "DTLSv1_listen". > > There are'nt any cookies in the Client Hello request. > > But DTLSv1_listen return error and the failure in see is in > > "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);" > > This is most likely because you haven't called > SSL_CTX_set_cookie_generate_cb() first. > > > We are using 1.1.0f version. Is there a way we can disable cookies? > > Well the whole *point* of calling DTLSv1_listen() is to generate those > cookies. If you don't want cookies, don't call it. > > Matt > > > > > Thanks, > > Grace > > > > On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero > > > >> wrote: > > > >? ? ?Hi Matt, > > > >? ? ?SSL_get_error()? returns 5.? > >? ? ?It is the same socket using which the UDP connection is established. > >? ? ?Could you suggest some logging that can be done for OPENSSL. > > > >? ? ?Thanks, > >? ? ?Grace > > > > > >? ? ?On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell > >? ? ?>> wrote: > > > > > > > >? ? ? ? ?On 26/10/17 16:43, Grace Priscilla Jero wrote: > >? ? ? ? ?> Thankyou for the responses. > >? ? ? ? ?> We figured the issue. But now we are getting error -5 > from "SSL_connect" > >? ? ? ? ?> and the errno is set to 22 which means invalid argument. > >? ? ? ? ?> Is there a easy way to debug or get logs for SSL_connect. > >? ? ? ? ?> > >? ? ? ? ?> Below is the sequence for the dtls udp connect that we > are trying. > >? ? ? ? ?> ssl = SSL_new(ctx) > >? ? ? ? ?> bio = BIO_new_dgram(sock_id,BIO_NOCLOSE) > >? ? ? ? ?> SSL_set_bio(ssl, bio, bio); > >? ? ? ? ?> VI_res = SSL_connect(ssl) > > > >? ? ? ? ?Do you really mean SSL_connect() returns -5? Or do you > mean that > >? ? ? ? ?after a > >? ? ? ? ?negative return value from SSL_connect() you call > >? ? ? ? ?SSL_get_error() and > >? ? ? ? ?that return 5 (SSL_ERROR_SYSCALL)? > > > >? ? ? ? ?If you really mean SSL_connect() returns -5 then you need > to call > >? ? ? ? ?SSL_get_error() as a next step. > > > >? ? ? ? ?If you are getting SSL_ERROR_SYSCALL then my guess is that > there > >? ? ? ? ?is a > >? ? ? ? ?problem with sock_id. How do create it? > > > >? ? ? ? ?Matt > > > > > >? ? ? ? ?> > >? ? ? ? ?> > >? ? ? ? ?> > >? ? ? ? ?> Thanks, > >? ? ? ? ?> Grace > >? ? ? ? ?> > >? ? ? ? ?> On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell > > > >? ? ? ? ?> > >>> wrote: > >? ? ? ? ?> > >? ? ? ? ?> > >? ? ? ? ?> > >? ? ? ? ?>? ? ?On 24/10/17 11:25, Grace Priscilla Jero wrote: > >? ? ? ? ?>? ? ?> We are using SSL_accept to accept the connection > for which we see the > >? ? ? ? ?>? ? ?> failure. Please let know if you have any thoughts. > >? ? ? ? ?> > >? ? ? ? ?>? ? ?Have you set the wbio correctly? Does SSL_get_wbio() > return your wbio > >? ? ? ? ?>? ? ?object if you call it immediately before > SSL_do_handshake()? > >? ? ? ? ?> > >? ? ? ? ?>? ? ?Matt > >? ? ? ? ?> > >? ? ? ? ?>? ? ?-- > >? ? ? ? ?>? ? ?openssl-users mailing list > >? ? ? ? ?>? ? ?To unsubscribe: > >? ? ? ? ?>? ? > ?https://mta.openssl.org/mailman/listinfo/openssl-users > > >? ? ? ? ? > > >? ? ? ? ?>? ? > ? > >? ? ? ? ? >> > >? ? ? ? ?> > >? ? ? ? ?> > >? ? ? ? ?> > >? ? ? ? ?> > >? ? ? ? ?-- > >? ? ? ? ?openssl-users mailing list > >? ? ? ? ?To unsubscribe: > >? ? ? ? ?https://mta.openssl.org/mailman/listinfo/openssl-users > > >? ? ? ? ? > > > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From dcoombs at carillon.ca Tue Oct 31 13:06:44 2017 From: dcoombs at carillon.ca (Dave Coombs) Date: Tue, 31 Oct 2017 09:06:44 -0400 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 Message-ID: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> Hello, I was fiddling around with OpenSSL 1.1.0 this past weekend, because One Day We'll Need To Upgrade (tm), and ran into the following. We have some code that uses OCSP_BASICRESP_verify() with 1.0.1 / 1.0.2 to confirm that the signature on an ocsp response is correct. This is a macro in ocsp.h, which directly accesses the signature, signatureAlgorithm, and tbsResponseData members of the OCSP_BASICRESP structure. In 1.1.0, this structure is now opaque, but the macros are still present in the public ocsp.h, so any external code that uses this macro can't compile. I can get around this by copying the struct definitions from ocsp_lcl.h into the external code, but that both defeats the purpose of opaque structures and will cause me problems if the structure contents ever change. Is the correct solution to use OCSP_basic_verify(), which feels like overkill for my needs (the code in question is *part of* our own path-validation routine), or might there be some other way? Either way, I hereby report you've got a few macros in a public header that can't possibly work as things stand. :-) Thanks, -Dave From grace.priscilla at gmail.com Tue Oct 31 13:26:43 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Tue, 31 Oct 2017 18:56:43 +0530 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: References: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> <900be4dc-2b5a-5d1b-1441-b4de6dc26584@openssl.org> <5bbbfef4-10e1-3920-efcd-ca4db9f0bee0@openssl.org> <2fb49d2d-b48e-ba7a-54c7-69b2b7193676@openssl.org> Message-ID: Matt, Here is more info on the process backtrace where it is stuck. cat /proc/15602/stack [] inet_csk_accept+0xc1/0x1f0 [] inet_accept+0x28/0xf5 [] sys_accept4+0x11b/0x1b8 [] sys_accept+0xb/0xd [] system_call_fastpath+0x16/0x1b [] 0xffffffffffffffff Thanks, Grace On Tue, Oct 31, 2017 at 4:22 PM, Grace Priscilla Jero < grace.priscilla at gmail.com> wrote: > Please find attached the pcap. It only has Client Hello. > While debugging SSL_accept, I see it stuck in s->method->ssl_read_bytes > > Thanks, > Grace > > > On Tue, Oct 31, 2017 at 4:16 PM, Matt Caswell wrote: > >> >> >> On 31/10/17 10:40, Grace Priscilla Jero wrote: >> > Hi Matt, >> > yes, we have found that later and have add the call backs. But we never >> > get the Client Hello with cookie. The Hello verify request is sent from >> > the server. >> > >> > Thanks for pointing out that listen was for cookies. Now without that >> > providing the SSL_accept, it hangs. We are unable to figure out why it >> > hangs. Only client hello is sent. Is there any way to spot what is going >> > wrong. >> >> I suggest you use Wireshark to take a look what is happening on the wire. >> >> Matt >> >> >> > >> > Thanks, >> > Grace >> > >> > On Tue, Oct 31, 2017 at 3:50 PM, Matt Caswell > > > wrote: >> > >> > >> > >> > On 31/10/17 06:06, Grace Priscilla Jero wrote: >> > > Thankyou for the suggestions. After correcting few options the >> > > "ClientHello" goes successfully but we have failure in >> "DTLSv1_listen". >> > > There are'nt any cookies in the Client Hello request. >> > > But DTLSv1_listen return error and the failure in see is in >> > > "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);" >> > >> > This is most likely because you haven't called >> > SSL_CTX_set_cookie_generate_cb() first. >> > >> > > We are using 1.1.0f version. Is there a way we can disable >> cookies? >> > >> > Well the whole *point* of calling DTLSv1_listen() is to generate >> those >> > cookies. If you don't want cookies, don't call it. >> > >> > Matt >> > >> > > >> > > Thanks, >> > > Grace >> > > >> > > On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero >> > > >> > > > >> wrote: >> > > >> > > Hi Matt, >> > > >> > > SSL_get_error() returns 5. >> > > It is the same socket using which the UDP connection is >> established. >> > > Could you suggest some logging that can be done for OPENSSL. >> > > >> > > Thanks, >> > > Grace >> > > >> > > >> > > On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell < >> matt at openssl.org >> > > >> wrote: >> > > >> > > >> > > >> > > On 26/10/17 16:43, Grace Priscilla Jero wrote: >> > > > Thankyou for the responses. >> > > > We figured the issue. But now we are getting error -5 >> > from "SSL_connect" >> > > > and the errno is set to 22 which means invalid argument. >> > > > Is there a easy way to debug or get logs for >> SSL_connect. >> > > > >> > > > Below is the sequence for the dtls udp connect that we >> > are trying. >> > > > ssl = SSL_new(ctx) >> > > > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE) >> > > > SSL_set_bio(ssl, bio, bio); >> > > > VI_res = SSL_connect(ssl) >> > > >> > > Do you really mean SSL_connect() returns -5? Or do you >> > mean that >> > > after a >> > > negative return value from SSL_connect() you call >> > > SSL_get_error() and >> > > that return 5 (SSL_ERROR_SYSCALL)? >> > > >> > > If you really mean SSL_connect() returns -5 then you need >> > to call >> > > SSL_get_error() as a next step. >> > > >> > > If you are getting SSL_ERROR_SYSCALL then my guess is that >> > there >> > > is a >> > > problem with sock_id. How do create it? >> > > >> > > Matt >> > > >> > > >> > > > >> > > > >> > > > >> > > > Thanks, >> > > > Grace >> > > > >> > > > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell >> > > matt at openssl.org >> > > >> > > > >> > >>> wrote: >> > > > >> > > > >> > > > >> > > > On 24/10/17 11:25, Grace Priscilla Jero wrote: >> > > > > We are using SSL_accept to accept the connection >> > for which we see the >> > > > > failure. Please let know if you have any thoughts. >> > > > >> > > > Have you set the wbio correctly? Does SSL_get_wbio() >> > return your wbio >> > > > object if you call it immediately before >> > SSL_do_handshake()? >> > > > >> > > > Matt >> > > > >> > > > -- >> > > > openssl-users mailing list >> > > > To unsubscribe: >> > > > >> > https://mta.openssl.org/mailman/listinfo/openssl-users >> > >> > > > > > >> > > > >> > > > >> > > > > >> >> > > > >> > > > >> > > > >> > > > >> > > -- >> > > openssl-users mailing list >> > > To unsubscribe: >> > > https://mta.openssl.org/mailman/listinfo/openssl-users >> > >> > > > > > >> > > >> > > >> > > >> > > >> > > >> > -- >> > openssl-users mailing list >> > To unsubscribe: >> > https://mta.openssl.org/mailman/listinfo/openssl-users >> > >> > >> > >> > >> > >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Tue Oct 31 15:16:08 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Tue, 31 Oct 2017 20:46:08 +0530 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: References: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> <900be4dc-2b5a-5d1b-1441-b4de6dc26584@openssl.org> <5bbbfef4-10e1-3920-efcd-ca4db9f0bee0@openssl.org> <2fb49d2d-b48e-ba7a-54c7-69b2b7193676@openssl.org> Message-ID: Matt, If you have any way to enable some kind of logging it will be useful to find what is the issue. Why do we get error 2 for ssl_accept. We have seen this for connect but not sure why we get it for accept. Thanks, Grace On 31-Oct-2017 6:56 PM, "Grace Priscilla Jero" wrote: > Matt, > Here is more info on the process backtrace where it is stuck. > > cat /proc/15602/stack > [] inet_csk_accept+0xc1/0x1f0 > [] inet_accept+0x28/0xf5 > [] sys_accept4+0x11b/0x1b8 > [] sys_accept+0xb/0xd > [] system_call_fastpath+0x16/0x1b > [] 0xffffffffffffffff > > Thanks, > Grace > > On Tue, Oct 31, 2017 at 4:22 PM, Grace Priscilla Jero < > grace.priscilla at gmail.com> wrote: > >> Please find attached the pcap. It only has Client Hello. >> While debugging SSL_accept, I see it stuck in s->method->ssl_read_bytes >> >> Thanks, >> Grace >> >> >> On Tue, Oct 31, 2017 at 4:16 PM, Matt Caswell wrote: >> >>> >>> >>> On 31/10/17 10:40, Grace Priscilla Jero wrote: >>> > Hi Matt, >>> > yes, we have found that later and have add the call backs. But we never >>> > get the Client Hello with cookie. The Hello verify request is sent from >>> > the server. >>> > >>> > Thanks for pointing out that listen was for cookies. Now without that >>> > providing the SSL_accept, it hangs. We are unable to figure out why it >>> > hangs. Only client hello is sent. Is there any way to spot what is >>> going >>> > wrong. >>> >>> I suggest you use Wireshark to take a look what is happening on the wire. >>> >>> Matt >>> >>> >>> > >>> > Thanks, >>> > Grace >>> > >>> > On Tue, Oct 31, 2017 at 3:50 PM, Matt Caswell >> > > wrote: >>> > >>> > >>> > >>> > On 31/10/17 06:06, Grace Priscilla Jero wrote: >>> > > Thankyou for the suggestions. After correcting few options the >>> > > "ClientHello" goes successfully but we have failure in >>> "DTLSv1_listen". >>> > > There are'nt any cookies in the Client Hello request. >>> > > But DTLSv1_listen return error and the failure in see is in >>> > > "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAIL >>> URE);" >>> > >>> > This is most likely because you haven't called >>> > SSL_CTX_set_cookie_generate_cb() first. >>> > >>> > > We are using 1.1.0f version. Is there a way we can disable >>> cookies? >>> > >>> > Well the whole *point* of calling DTLSv1_listen() is to generate >>> those >>> > cookies. If you don't want cookies, don't call it. >>> > >>> > Matt >>> > >>> > > >>> > > Thanks, >>> > > Grace >>> > > >>> > > On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero >>> > > >>> > >> > >> wrote: >>> > > >>> > > Hi Matt, >>> > > >>> > > SSL_get_error() returns 5. >>> > > It is the same socket using which the UDP connection is >>> established. >>> > > Could you suggest some logging that can be done for OPENSSL. >>> > > >>> > > Thanks, >>> > > Grace >>> > > >>> > > >>> > > On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell < >>> matt at openssl.org >>> > > >> wrote: >>> > > >>> > > >>> > > >>> > > On 26/10/17 16:43, Grace Priscilla Jero wrote: >>> > > > Thankyou for the responses. >>> > > > We figured the issue. But now we are getting error -5 >>> > from "SSL_connect" >>> > > > and the errno is set to 22 which means invalid >>> argument. >>> > > > Is there a easy way to debug or get logs for >>> SSL_connect. >>> > > > >>> > > > Below is the sequence for the dtls udp connect that we >>> > are trying. >>> > > > ssl = SSL_new(ctx) >>> > > > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE) >>> > > > SSL_set_bio(ssl, bio, bio); >>> > > > VI_res = SSL_connect(ssl) >>> > > >>> > > Do you really mean SSL_connect() returns -5? Or do you >>> > mean that >>> > > after a >>> > > negative return value from SSL_connect() you call >>> > > SSL_get_error() and >>> > > that return 5 (SSL_ERROR_SYSCALL)? >>> > > >>> > > If you really mean SSL_connect() returns -5 then you need >>> > to call >>> > > SSL_get_error() as a next step. >>> > > >>> > > If you are getting SSL_ERROR_SYSCALL then my guess is >>> that >>> > there >>> > > is a >>> > > problem with sock_id. How do create it? >>> > > >>> > > Matt >>> > > >>> > > >>> > > > >>> > > > >>> > > > >>> > > > Thanks, >>> > > > Grace >>> > > > >>> > > > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell >>> > >> matt at openssl.org >>> > > >>> > > > >>> > >>> wrote: >>> > > > >>> > > > >>> > > > >>> > > > On 24/10/17 11:25, Grace Priscilla Jero wrote: >>> > > > > We are using SSL_accept to accept the connection >>> > for which we see the >>> > > > > failure. Please let know if you have any >>> thoughts. >>> > > > >>> > > > Have you set the wbio correctly? Does >>> SSL_get_wbio() >>> > return your wbio >>> > > > object if you call it immediately before >>> > SSL_do_handshake()? >>> > > > >>> > > > Matt >>> > > > >>> > > > -- >>> > > > openssl-users mailing list >>> > > > To unsubscribe: >>> > > > >>> > https://mta.openssl.org/mailman/listinfo/openssl-users >>> > >>> > > >> > > >>> > > > >>> > >> > >>> > > >> > >> >>> > > > >>> > > > >>> > > > >>> > > > >>> > > -- >>> > > openssl-users mailing list >>> > > To unsubscribe: >>> > > https://mta.openssl.org/mailman/listinfo/openssl-users >>> > >>> > > >> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > -- >>> > openssl-users mailing list >>> > To unsubscribe: >>> > https://mta.openssl.org/mailman/listinfo/openssl-users >>> > >>> > >>> > >>> > >>> > >>> -- >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 31 15:19:08 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Oct 2017 15:19:08 +0000 Subject: [openssl-users] Issue with DTLS for UDP In-Reply-To: References: <390fad2f-1fec-c917-320e-3fe4df3bb9db@openssl.org> <900be4dc-2b5a-5d1b-1441-b4de6dc26584@openssl.org> <5bbbfef4-10e1-3920-efcd-ca4db9f0bee0@openssl.org> <2fb49d2d-b48e-ba7a-54c7-69b2b7193676@openssl.org> Message-ID: I did not get the pcap file? Perhaps it got blocked due to message size. Try sending it direct to me. Matt On 31/10/17 13:26, Grace Priscilla Jero wrote: > Matt, > Here is more info on the process backtrace where it is stuck. > > cat /proc/15602/stack > [] inet_csk_accept+0xc1/0x1f0 > [] inet_accept+0x28/0xf5 > [] sys_accept4+0x11b/0x1b8 > [] sys_accept+0xb/0xd > [] system_call_fastpath+0x16/0x1b > [] 0xffffffffffffffff > > Thanks, > Grace > > On Tue, Oct 31, 2017 at 4:22 PM, Grace Priscilla Jero > > wrote: > > Please find attached the pcap. It only has Client Hello. > While debugging SSL_accept, I see it stuck in?s->method->ssl_read_bytes > > Thanks, > Grace > > > On Tue, Oct 31, 2017 at 4:16 PM, Matt Caswell > wrote: > > > > On 31/10/17 10:40, Grace Priscilla Jero wrote: > > Hi Matt, > > yes, we have found that later and have add the call backs. But we never > > get the Client Hello with cookie. The Hello verify request is sent from > > the server. > > > > Thanks for pointing out that listen was for cookies. Now without that > > providing the SSL_accept, it hangs. We are unable to figure out why it > > hangs. Only client hello is sent. Is there any way to spot what is going > > wrong. > > I suggest you use Wireshark to take a look what is happening on > the wire. > > Matt > > > > > > Thanks, > > Grace > > > > On Tue, Oct 31, 2017 at 3:50 PM, Matt Caswell > > >> wrote: > > > > > > > >? ? ?On 31/10/17 06:06, Grace Priscilla Jero wrote: > >? ? ?> Thankyou for the suggestions. After correcting few options the > >? ? ?> "ClientHello" goes successfully but we have failure in "DTLSv1_listen". > >? ? ?> There are'nt any cookies in the Client Hello request. > >? ? ?> But DTLSv1_listen return error and the failure in see is in > >? ? ?> "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);" > > > >? ? ?This is most likely because you haven't called > >? ? ?SSL_CTX_set_cookie_generate_cb() first. > > > >? ? ?> We are using 1.1.0f version. Is there a way we can disable cookies? > > > >? ? ?Well the whole *point* of calling DTLSv1_listen() is to generate those > >? ? ?cookies. If you don't want cookies, don't call it. > > > >? ? ?Matt > > > >? ? ?> > >? ? ?> Thanks, > >? ? ?> Grace > >? ? ?> > >? ? ?> On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero > >? ? ?> > > > >? ? ? > >? ? ?>>> > wrote: > >? ? ?> > >? ? ?>? ? ?Hi Matt, > >? ? ?> > >? ? ?>? ? ?SSL_get_error()? returns 5.? > >? ? ?>? ? ?It is the same socket using which the UDP connection is established. > >? ? ?>? ? ?Could you suggest some logging that can be done for OPENSSL. > >? ? ?> > >? ? ?>? ? ?Thanks, > >? ? ?>? ? ?Grace > >? ? ?> > >? ? ?> > >? ? ?>? ? ?On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell > > > >? ? ?>? ? ? > >>> wrote: > >? ? ?> > >? ? ?> > >? ? ?> > >? ? ?>? ? ? ? ?On 26/10/17 16:43, Grace Priscilla Jero wrote: > >? ? ?>? ? ? ? ?> Thankyou for the responses. > >? ? ?>? ? ? ? ?> We figured the issue. But now we are getting > error -5 > >? ? ?from "SSL_connect" > >? ? ?>? ? ? ? ?> and the errno is set to 22 which means invalid > argument. > >? ? ?>? ? ? ? ?> Is there a easy way to debug or get logs for > SSL_connect. > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?> Below is the sequence for the dtls udp connect > that we > >? ? ?are trying. > >? ? ?>? ? ? ? ?> ssl = SSL_new(ctx) > >? ? ?>? ? ? ? ?> bio = BIO_new_dgram(sock_id,BIO_NOCLOSE) > >? ? ?>? ? ? ? ?> SSL_set_bio(ssl, bio, bio); > >? ? ?>? ? ? ? ?> VI_res = SSL_connect(ssl) > >? ? ?> > >? ? ?>? ? ? ? ?Do you really mean SSL_connect() returns -5? Or > do you > >? ? ?mean that > >? ? ?>? ? ? ? ?after a > >? ? ?>? ? ? ? ?negative return value from SSL_connect() you call > >? ? ?>? ? ? ? ?SSL_get_error() and > >? ? ?>? ? ? ? ?that return 5 (SSL_ERROR_SYSCALL)? > >? ? ?> > >? ? ?>? ? ? ? ?If you really mean SSL_connect() returns -5 then > you need > >? ? ?to call > >? ? ?>? ? ? ? ?SSL_get_error() as a next step. > >? ? ?> > >? ? ?>? ? ? ? ?If you are getting SSL_ERROR_SYSCALL then my > guess is that > >? ? ?there > >? ? ?>? ? ? ? ?is a > >? ? ?>? ? ? ? ?problem with sock_id. How do create it? > >? ? ?> > >? ? ?>? ? ? ? ?Matt > >? ? ?> > >? ? ?> > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?> Thanks, > >? ? ?>? ? ? ? ?> Grace > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?> On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell > >? ? ? > > > > >? ? ?>> > >? ? ?>? ? ? ? ?> > > >? ? ? > >>>> wrote: > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?>? ? ?On 24/10/17 11:25, Grace Priscilla Jero wrote: > >? ? ?>? ? ? ? ?>? ? ?> We are using SSL_accept to accept the > connection > >? ? ?for which we see the > >? ? ?>? ? ? ? ?>? ? ?> failure. Please let know if you have any > thoughts. > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?>? ? ?Have you set the wbio correctly? Does > SSL_get_wbio() > >? ? ?return your wbio > >? ? ?>? ? ? ? ?>? ? ?object if you call it immediately before > >? ? ?SSL_do_handshake()? > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?>? ? ?Matt > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?>? ? ?-- > >? ? ?>? ? ? ? ?>? ? ?openssl-users mailing list > >? ? ?>? ? ? ? ?>? ? ?To unsubscribe: > >? ? ?>? ? ? ? ?>? ? > >? ? ??https://mta.openssl.org/mailman/listinfo/openssl-users > > >? ? ? > > >? ? ?>? ? ? ? > ? > >? ? ? >> > >? ? ?>? ? ? ? ?>? ? > >? ? ?? > >? ? ? > > >? ? ?>? ? ? ? > ? > >? ? ? >>> > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?> > >? ? ?>? ? ? ? ?-- > >? ? ?>? ? ? ? ?openssl-users mailing list > >? ? ?>? ? ? ? ?To unsubscribe: > >? ? ?>? ? ? ? > ?https://mta.openssl.org/mailman/listinfo/openssl-users > > >? ? ? > > >? ? ?>? ? ? ? > ? > >? ? ? >> > >? ? ?> > >? ? ?> > >? ? ?> > >? ? ?> > >? ? ?> > >? ? ?-- > >? ? ?openssl-users mailing list > >? ? ?To unsubscribe: > >? ? ?https://mta.openssl.org/mailman/listinfo/openssl-users > > >? ? ? > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > From matt at openssl.org Tue Oct 31 15:36:15 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Oct 2017 15:36:15 +0000 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> Message-ID: On 31/10/17 13:06, Dave Coombs wrote: > Hello, > > I was fiddling around with OpenSSL 1.1.0 this past weekend, because > One Day We'll Need To Upgrade (tm), and ran into the following. > > We have some code that uses OCSP_BASICRESP_verify() with 1.0.1 / > 1.0.2 to confirm that the signature on an ocsp response is correct. > This is a macro in ocsp.h, which directly accesses the signature, > signatureAlgorithm, and tbsResponseData members of the OCSP_BASICRESP > structure. In 1.1.0, this structure is now opaque, but the macros > are still present in the public ocsp.h, so any external code that > uses this macro can't compile. > > I can get around this by copying the struct definitions from > ocsp_lcl.h into the external code, but that both defeats the purpose > of opaque structures and will cause me problems if the structure > contents ever change. > > Is the correct solution to use OCSP_basic_verify(), which feels like > overkill for my needs (the code in question is *part of* our own > path-validation routine), or might there be some other way? Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final "flags" argument? This basically finds the signer certificate and verifies the signature using OCSP_BASICRESP_verify(), but skips all the chain validation bit. > Either way, I hereby report you've got a few macros in a public > header that can't possibly work as things stand. :-) Yes - a bug. I'm tempted just to remove them. Matt From bkaduk at akamai.com Tue Oct 31 15:39:28 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 31 Oct 2017 10:39:28 -0500 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> Message-ID: <902eff93-de99-4032-d89f-b305121f7b96@akamai.com> On 10/31/2017 10:36 AM, Matt Caswell wrote: > > On 31/10/17 13:06, Dave Coombs wrote: > >> Either way, I hereby report you've got a few macros in a public >> header that can't possibly work as things stand. :-) > Yes - a bug. I'm tempted just to remove them. > That seems like the best course of action.? It's not like we're actually removing them from the public API, since they never worked at all (on this branch).? They were actually "removed"/desupported in the 1.1.0 release, we just didn't realize it at the time. -Ben From wouter.verhelst at fedict.be Tue Oct 31 16:02:37 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Tue, 31 Oct 2017 17:02:37 +0100 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> Message-ID: Hi Matt, On 31-10-17 16:36, Matt Caswell wrote: > Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final > "flags" argument? This basically finds the signer certificate and > verifies the signature using OCSP_BASICRESP_verify(), but skips all the > chain validation bit. Just wanted to point out that that is, actually, a confusing name for that flag. "NOVERIFY" seems to imply that there is no verification being done, at all. Intuitively one senses that's not right, and that at least some verification will be done (in casu the signature will still be checked); but figuring out which part of the verification is being dropped and which part isn't requires one to read either the library source or the documentation, both of which are annoying if they can be avoided and do not help for the readability of code that uses the flag in question. Might I suggest that this flag be renamed somehow, to something that makes it more clear what exactly it does? -- Wouter Verhelst From matt at openssl.org Tue Oct 31 16:26:24 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Oct 2017 16:26:24 +0000 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> Message-ID: <65b1aebd-6f8d-12a0-28d5-33e45f47494a@openssl.org> On 31/10/17 16:02, Wouter Verhelst wrote: > Hi Matt, > > On 31-10-17 16:36, Matt Caswell wrote: >> Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final >> "flags" argument? This basically finds the signer certificate and >> verifies the signature using OCSP_BASICRESP_verify(), but skips all the >> chain validation bit. > Just wanted to point out that that is, actually, a confusing name for > that flag. > > "NOVERIFY" seems to imply that there is no verification being done, at > all. Intuitively one senses that's not right, and that at least some > verification will be done (in casu the signature will still be checked); > but figuring out which part of the verification is being dropped and > which part isn't requires one to read either the library source or the > documentation, both of which are annoying if they can be avoided and do > not help for the readability of code that uses the flag in question. > > Might I suggest that this flag be renamed somehow, to something that > makes it more clear what exactly it does? > I agree its not a great name for it. Unfortunately we are stuck with it for compatibility reasons. If we renamed it we would break any code that is currently using it. We could introduce a new flag with a different name which does the same thing - but I'm not sure that does anything to make things less confusing. The best way forward is to document it. It isn't documented at all at the moment along with a number of other OCSP related functions and features. PRs welcome for that. Matt From jb-openssl at wisemo.com Tue Oct 31 16:40:08 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 31 Oct 2017 17:40:08 +0100 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: <65b1aebd-6f8d-12a0-28d5-33e45f47494a@openssl.org> References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> <65b1aebd-6f8d-12a0-28d5-33e45f47494a@openssl.org> Message-ID: <146c10fe-3ab1-8ef1-a795-577d3fb967d8@wisemo.com> On 31/10/2017 17:26, Matt Caswell wrote: > > On 31/10/17 16:02, Wouter Verhelst wrote: >> Hi Matt, >> >> On 31-10-17 16:36, Matt Caswell wrote: >>> Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final >>> "flags" argument? This basically finds the signer certificate and >>> verifies the signature using OCSP_BASICRESP_verify(), but skips all the >>> chain validation bit. >> Just wanted to point out that that is, actually, a confusing name for >> that flag. >> >> "NOVERIFY" seems to imply that there is no verification being done, at >> all. Intuitively one senses that's not right, and that at least some >> verification will be done (in casu the signature will still be checked); >> but figuring out which part of the verification is being dropped and >> which part isn't requires one to read either the library source or the >> documentation, both of which are annoying if they can be avoided and do >> not help for the readability of code that uses the flag in question. >> >> Might I suggest that this flag be renamed somehow, to something that >> makes it more clear what exactly it does? >> > I agree its not a great name for it. Unfortunately we are stuck with it > for compatibility reasons. If we renamed it we would break any code that > is currently using it. We could introduce a new flag with a different > name which does the same thing - but I'm not sure that does anything to > make things less confusing. > > The best way forward is to document it. It isn't documented at all at > the moment along with a number of other OCSP related functions and > features. PRs welcome for that. > > Matt You could introduce the new name, but define the old name to it, and document that the flag is alsoavailable under the other name for backwards compatibility.? Then code that doesn't need compatibility with 1.1.0 or older can just use the new name. As for the macro that doesn't work, wouldn't it be better to make it a function (or a wrapper around the call with the badly named flag). One could just as easily argue that the API was accidentally broken, not accidentally kept.? After all, the references to internal structures is internal to the inline implementation, not part of the interface. 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 wouter.verhelst at fedict.be Tue Oct 31 16:42:48 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Tue, 31 Oct 2017 17:42:48 +0100 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: <65b1aebd-6f8d-12a0-28d5-33e45f47494a@openssl.org> References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> <65b1aebd-6f8d-12a0-28d5-33e45f47494a@openssl.org> Message-ID: On 31-10-17 17:26, Matt Caswell wrote: > I agree its not a great name for it. Unfortunately we are stuck with it > for compatibility reasons. If we renamed it we would break any code that > is currently using it. We could introduce a new flag with a different > name which does the same thing - but I'm not sure that does anything to > make things less confusing. You could always keep the old name around and mark it deprecated. GCC even has a pragma for that -- __attribute__((deprecated)) -- although I doubt it works on macros (haven't tested that). I suppose it might be too much of an effort for too little gain, though. -- Wouter Verhelst From matt at openssl.org Tue Oct 31 16:47:13 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Oct 2017 16:47:13 +0000 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> <65b1aebd-6f8d-12a0-28d5-33e45f47494a@openssl.org> Message-ID: <3b60b590-90f7-46e6-52a2-d708ad8b66e8@openssl.org> On 31/10/17 16:42, Wouter Verhelst wrote: > On 31-10-17 17:26, Matt Caswell wrote: >> I agree its not a great name for it. Unfortunately we are stuck with it >> for compatibility reasons. If we renamed it we would break any code that >> is currently using it. We could introduce a new flag with a different >> name which does the same thing - but I'm not sure that does anything to >> make things less confusing. > > You could always keep the old name around and mark it deprecated. GCC > even has a pragma for that -- __attribute__((deprecated)) -- although I > doubt it works on macros (haven't tested that). > > I suppose it might be too much of an effort for too little gain, though. > As a matter of policy we won't deprecate anything more until we do a 1.2.0 release. If someone wants to create a PR for a new name for this (defining the old one to point at the new one), then I'd review it. But if we're going to go to that effort then we should write the documentation as part of the PR (there seems little sense to me in replacing an undocumented name which you have to read the source to understand with another undocumented name that you also have to read the source to understand). Matt From matt at openssl.org Tue Oct 31 17:07:34 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Oct 2017 17:07:34 +0000 Subject: [openssl-users] DTLS UDP issue In-Reply-To: References: Message-ID: <55aff155-7019-160a-709e-4b0df4466ac6@openssl.org> On 31/10/17 16:58, Grace Priscilla Jero wrote: > Hi Matt, > > Please find attached the pcap which contains only the "Hello Client". Thanks. Switching back to openssl-users. > Search with?ip.src==22.33.40.11 > > SSL_accept fails with -1 and get error gives the number as 2. Error 2 is SSL_ERROR_WANT_READ which is normal. It just means it wants to read data but hasn't got enough yet (probably because the data has not arrived yet). You need to loop and retry SSL_accept() - are you doing that? > > Below is the sequence for accept: > > Socket creation > Make it non-blocking How are you creating the socket? > BIO_new_dgram > SSL_new > SSL_set_bio > BIO_set_fd Why are you calling BIO_set_fd() here? Has the fd changed from when you called BIO_new_dgram()? > SSL_set_accept_state > SSL_set_fd This replaces the BIO you created earlier with a new standard socket BIO (i.e. not dgram) based on the supplied fd. That is not going to work. Remove this call. Matt > SSL_accept > > Thanks, > Grace > From dcoombs at carillon.ca Tue Oct 31 17:30:03 2017 From: dcoombs at carillon.ca (Dave Coombs) Date: Tue, 31 Oct 2017 13:30:03 -0400 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> Message-ID: <69E2FD50-3DB1-44F9-9CB4-C3C49A953618@carillon.ca> Hi Matt, thanks for your response. >> Is the correct solution to use OCSP_basic_verify(), which feels like >> overkill for my needs (the code in question is *part of* our own >> path-validation routine), or might there be some other way? > > Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final > "flags" argument? This basically finds the signer certificate and > verifies the signature using OCSP_BASICRESP_verify(), but skips all the > chain validation bit. If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and NULL for X509_STORE *st since it won't be used, then I think I should get the desired result, yes, at the cost of ocsp_find_signer(single-entry certs) and the internal creation/destruction of an unused X509_STORE_CTX. I'd have a small performance hit but it probably wouldn't be too bad. The alternative would be to change the OCSP_BASICRESP_verify() macro into an externally available function, and then both it and OCSP_basic_verify() could call the former macro, suitably renamed and internally scoped. Clearly I'd be happy with that, though I understand if you don't want to go that route. Cheers, -Dave From matt at openssl.org Tue Oct 31 17:34:29 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Oct 2017 17:34:29 +0000 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: <69E2FD50-3DB1-44F9-9CB4-C3C49A953618@carillon.ca> References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> <69E2FD50-3DB1-44F9-9CB4-C3C49A953618@carillon.ca> Message-ID: On 31/10/17 17:30, Dave Coombs wrote: > Hi Matt, thanks for your response. > >>> Is the correct solution to use OCSP_basic_verify(), which feels like >>> overkill for my needs (the code in question is *part of* our own >>> path-validation routine), or might there be some other way? >> >> Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final >> "flags" argument? This basically finds the signer certificate and >> verifies the signature using OCSP_BASICRESP_verify(), but skips all the >> chain validation bit. > > If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and NULL for X509_STORE *st since it won't be used, then I think I should get the desired result, yes, at the cost of ocsp_find_signer(single-entry certs) and the internal creation/destruction of an unused X509_STORE_CTX. I'd have a small performance hit but it probably wouldn't be too bad. Probably the construction of that ctx is in the wrong place. It should be later in the function. I can't imagine the ocsp_find_signer() hit is too great. > > The alternative would be to change the OCSP_BASICRESP_verify() macro into an externally available function, and then both it and OCSP_basic_verify() could call the former macro, suitably renamed and internally scoped. Clearly I'd be happy with that, though I understand if you don't want to go that route. I did consider it, but I'm not especially keen. I think the intended application interface here is to use OCSP_basic_verify(). OCSP_BASICRESP_verify() should probably have never been exposed in the first place. Matt From dcoombs at carillon.ca Tue Oct 31 18:05:10 2017 From: dcoombs at carillon.ca (Dave Coombs) Date: Tue, 31 Oct 2017 14:05:10 -0400 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> <69E2FD50-3DB1-44F9-9CB4-C3C49A953618@carillon.ca> Message-ID: >> If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and NULL for X509_STORE *st since it won't be used, then I think I should get the desired result, yes, at the cost of ocsp_find_signer(single-entry certs) and the internal creation/destruction of an unused X509_STORE_CTX. I'd have a small performance hit but it probably wouldn't be too bad. > > Probably the construction of that ctx is in the wrong place. It should > be later in the function. I can't imagine the ocsp_find_signer() hit is > too great. Having tried this, I now see that my copying the structs from ocsp_lcl.h into the external code masked the fact that the external code is getting the signer's cert beforehand by directly accessing OCSP_BASICRESP->certs (and ->tbsResponseData) anyway, effectively doing what ocsp_find_signer() does. So it is clear that I will need to be rework this, potentially centred around OCSP_basic_verify(), while remaining ignorant of the signer cert. It would be nice, though, if the API provided a way to get the signer's certificate. There is OCSP_resp_get0_signature(), but that only returns the bit string. Comparable functions in other modules (eg: X509_get0_signature(), X509_REQ_get0_signature(), X509_CRL_get0_signature(), CMS_SignerInfo_get0_algs()) provide a way to get any combination of bit string, algorithm, and signer cert. Cheers, -Dave From bkaduk at akamai.com Tue Oct 31 18:07:29 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 31 Oct 2017 13:07:29 -0500 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> <69E2FD50-3DB1-44F9-9CB4-C3C49A953618@carillon.ca> Message-ID: <2ba07e10-4ad7-de60-20c1-4329481b0dea@akamai.com> On 10/31/2017 01:05 PM, Dave Coombs wrote: >>> If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and NULL for X509_STORE *st since it won't be used, then I think I should get the desired result, yes, at the cost of ocsp_find_signer(single-entry certs) and the internal creation/destruction of an unused X509_STORE_CTX. I'd have a small performance hit but it probably wouldn't be too bad. >> Probably the construction of that ctx is in the wrong place. It should >> be later in the function. I can't imagine the ocsp_find_signer() hit is >> too great. > Having tried this, I now see that my copying the structs from ocsp_lcl.h into the external code masked the fact that the external code is getting the signer's cert beforehand by directly accessing OCSP_BASICRESP->certs (and ->tbsResponseData) anyway, effectively doing what ocsp_find_signer() does. So it is clear that I will need to be rework this, potentially centred around OCSP_basic_verify(), while remaining ignorant of the signer cert. > > It would be nice, though, if the API provided a way to get the signer's certificate. There is OCSP_resp_get0_signature(), but that only returns the bit string. Comparable functions in other modules (eg: X509_get0_signature(), X509_REQ_get0_signature(), X509_CRL_get0_signature(), CMS_SignerInfo_get0_algs()) provide a way to get any combination of bit string, algorithm, and signer cert. > Kind of like https://github.com/openssl/openssl/pull/4573 ? -Ben From Karyn.Ulriksen at riverbed.com Tue Oct 31 21:51:13 2017 From: Karyn.Ulriksen at riverbed.com (Karyn Ulriksen) Date: Tue, 31 Oct 2017 21:51:13 +0000 Subject: [openssl-users] Latest stable FIPS and SSL Library combo? Message-ID: What is the recommended versions for the latest FIPS module (2.0.16 ?) and SSL libraries (1.0.2l ?) There was not a clear answer. I dug around and came up with the ones I mentioned, but need a sanity check. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew_Porter at bmc.com Tue Oct 31 23:10:16 2017 From: Andrew_Porter at bmc.com (Porter, Andrew) Date: Tue, 31 Oct 2017 23:10:16 +0000 Subject: [openssl-users] Latest stable FIPS and SSL Library combo? In-Reply-To: References: Message-ID: <0550df3f22e4429b9712ebb5ce9e1ef9@phx-exmbprd-02.adprod.bmc.com> Yes, 2.0.16 and 1.0.2l as per https://www.openssl.org/source/ But there will be a 1.0.2m out on Thursday. Andrew From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Karyn Ulriksen Sent: Tuesday, October 31, 2017 14:51 To: openssl-users at openssl.org Subject: [openssl-users] Latest stable FIPS and SSL Library combo? What is the recommended versions for the latest FIPS module (2.0.16 ?) and SSL libraries (1.0.2l ?) There was not a clear answer. I dug around and came up with the ones I mentioned, but need a sanity check. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: