From dcoombs at carillon.ca Wed Nov 1 14:52:08 2017 From: dcoombs at carillon.ca (Dave Coombs) Date: Wed, 1 Nov 2017 10:52:08 -0400 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: <2ba07e10-4ad7-de60-20c1-4329481b0dea@akamai.com> References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> <69E2FD50-3DB1-44F9-9CB4-C3C49A953618@carillon.ca> <2ba07e10-4ad7-de60-20c1-4329481b0dea@akamai.com> Message-ID: >> 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 ? Quite a lot like that, yes. Neat. Is there any chance this might be included in the 1.1.0 series? Thanks, -Dave From bkaduk at akamai.com Wed Nov 1 16:20:34 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 1 Nov 2017 11:20:34 -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> <2ba07e10-4ad7-de60-20c1-4329481b0dea@akamai.com> Message-ID: <0c0ea007-01e8-fe70-cec9-0bbfca89cc7a@akamai.com> On 11/01/2017 09:52 AM, Dave Coombs wrote: >>> 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 ? > Quite a lot like that, yes. Neat. Is there any chance this might be included in the 1.1.0 series? > Since there have been no reviews yet, it's easy enough for me to add the "1.1.0" label and see if a reviewer is persuaded that it is relevant there. -Ben From rmawatson at hotmail.com Wed Nov 1 17:16:09 2017 From: rmawatson at hotmail.com (rmawatson rmawatson) Date: Wed, 1 Nov 2017 17:16:09 +0000 Subject: [openssl-users] Problem with using EC private keys Message-ID: Hi, I am confused about the two different ways I can generate an EC private key and why this is causing me problems with the test s_client s_server applications So, I am using the command below to generate a private key, then using this to create a certificate to work with openssl s_client s_server. openssl ecparam -name secp384r1 -genkey -out privkey.pem (1) I then create the .csr with the following two commands, openssl req -key privkey.pem -out pub.csr -new (2) openssl x509 -req -in pub.csr -signkey privkey.pem -out pub.crt (3) This works with s_server/s_client. But, when I generate a key like this: openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:secp384r1 -out privkey.pem (4) If I now create a signed .crt with (2) and (3) above, then use this pair with openssl s_server it does not negotiate a cipher suite and it doesn't work. Client: CONNECTED(00000154) 2546392219:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure:ssl_pkt.c:1205:SSL alert number 40 2546392219:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:ssl_pkt.c:585: ... Server: ... ERROR 2867046282:error:140270C1:SSL routines:ACCEPT_SR_CLNT_HELLO_C:no shared cipher:ssl_srvr.c:1024: shutting down SSL CONNECTION CLOSED Using this url (https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations) It turns out, if I take the key generated by (4) above, and convert it to pk8 with openssl pkcs8 -topk8 -nocrypt -in privkey_ec.pem -out privkey.pem If I now use this key to create the .crt and use this key pair with openssl s_server it works. My question is why does the format of the private key make any difference. Surely openssl can decode the key in any supported format, after all it created it, and all the required information must be in it, as it is able to convert to pk8 format that works. Note: I am running openssl server/client like this.. openssl.exe s_server -tls1_2 -key privkey.pem -cert pub.crt -debug and openssl.exe s_client -tls1_2 Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey at sierrachart.com Wed Nov 1 18:44:49 2017 From: jeffrey at sierrachart.com (Jeffrey Lindsey) Date: Wed, 1 Nov 2017 11:44:49 -0700 Subject: [openssl-users] "shutdown while in init" error from SSL_read Message-ID: What might cause the following error as a result of a call to SSL_read: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init I'm seeing this error reported well after the initial handshake should have been completed, and before any call to SSL_shutdown on the SSL object given to SSL_read.? So, externally, there is no intention or knowledge of SSL being actively shutdown or initialized at the time of the read call.? No other errors were reported before this one.? Occurrences of the error are uncommon, and I have not found a way to reliably reproduce it.? What could possibly be the cause of this error, and how could it be prevented? For additional context: Using OpenSLL version 1.0.2l. This error is seen on the client side, using TLS 1.0 (TLSv1_client_method). Only memory BIO objects (BIO_s_mem) are set into the SSL object. Looking at the code, this error (SSL_R_SHUTDOWN_WHILE_IN_INIT) is only reported in SSL_shutdown, but I have not yet found how SSL_shutdown might be called from SSL_read. Additionally, the program in which this error occurs may be using multiple SSL objects at a time, potentially with SSL objects on different threads, but no SSL objects are shared between threads. The SSL objects are created (via SSL_new) using the same shared context object (SSL_CTX).? Is there any chance the states or errors from different SSL objects are interfering with each other? ?- Jeffrey From bhat.jayalakshmi at gmail.com Thu Nov 2 07:07:46 2017 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Thu, 2 Nov 2017 12:37:46 +0530 Subject: [openssl-users] Wanted details on ./config or Configure options In-Reply-To: <1a6da94e-b2e0-6449-386e-14162fa711d8@openssl.org> References: <57a49aa9-9364-461e-1881-6039175f1ebe@openssl.org> <1a6da94e-b2e0-6449-386e-14162fa711d8@openssl.org> Message-ID: Hi Matt, Thanks a lot for the response. Sorry for the delayed reply. I was out of office for a while. This helped me. However I am not seeing option to remove unwanted engine files to go away from compilation. OpenSSL 1.01x method (no-hw no-hw-4758-cca no-hw-aep no-hw-atalla no-hw-chil no-hw-cswift no-hw-ibmca no-hw-ncipher no-hw-nuron no-hw-padlock no-hw-sureware no-hw-ubsec no-hw-zencod) does not seems to work. Is there any way to do it? Regards Jayalakshmi On Thu, Oct 26, 2017 at 4:09 PM, Matt Caswell wrote: > > > 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 > > stable/INSTALL> > > > > 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 matt at openssl.org Thu Nov 2 10:26:07 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 2 Nov 2017 10:26:07 +0000 Subject: [openssl-users] Wanted details on ./config or Configure options In-Reply-To: References: <57a49aa9-9364-461e-1881-6039175f1ebe@openssl.org> <1a6da94e-b2e0-6449-386e-14162fa711d8@openssl.org> Message-ID: <372406bb-0460-9dcb-46dc-061a3570f939@openssl.org> On 02/11/17 07:07, Jayalakshmi bhat wrote: > Hi Matt, > > Thanks a lot for the response. Sorry for the delayed reply. I was out of > office for a while. This helped me.? However I am not seeing option to > remove unwanted engine files to go away from compilation. OpenSSL 1.01x > method > (no-hw?no-hw-4758-cca?no-hw-aep?no-hw-atalla?no-hw-chil?no-hw-cswift?no-hw-ibmca?no-hw-ncipher?no-hw-nuron?no-hw-padlock?no-hw-sureware?no-hw-ubsec?no-hw-zencod) > does not seems to work. Is there any way to do it? Hmmm - that looks like a possible bug to me. I think that should work (Richard Levitte may be able to comment). You can also use no-engine which switches off engine support altogether Matt > > > Regards > Jayalakshmi > > On Thu, Oct 26, 2017 at 4:09 PM, Matt Caswell > wrote: > > > > 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 > > >? ? ? > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From christian at python.org Thu Nov 2 10:32:45 2017 From: christian at python.org (Christian Heimes) Date: Thu, 2 Nov 2017 11:32:45 +0100 Subject: [openssl-users] TLS 1.3 handshake: Limit signature algorithm? Message-ID: Hi, I'm one of the maintainers of Python's ssl module. A couple of days ago Hanno B?ck opened an issue [1] against ssl.get_server_certificate() function [2][3]. It's a helper function to retrieve the end-entity certificate from a remote TLS/SSL server over an unverified connection. The implementation [3] is rather simple and has some limitations. Hanno pointed out that it cannot handle servers with multiple certificate types. For example Facebook supports RSA and ECDSA certs. Python's ssl.get_server_certificate() can only retrieve the ECDSA cert. It's fairly simple to fix the problem for TLS 1.2 and lower by limiting the cipher suites to "aRSA:!NULL" for RSA certs and "aECDSA:!NULL" for ECDSA certs [4]. However this trick will not work with TLS 1.3. The new TLS 1.3 cipher suites no longer specify authentication algorithm or key agreement/exchange. TLS 1.3 RFC specifies a signature_algorithms extension [5]. I could not find any API call in OpenSSL master to set the extension for TLS 1.3 handshakes. How can a client enforce a specific authentication algorithm or set of signature algorithms for TLS 1.3 handshake? Regards, Christian [1] https://bugs.python.org/issue31892 [2] https://docs.python.org/3/library/ssl.html#ssl.get_server_certificate [3] https://github.com/python/cpython/blob/v3.6.2/Lib/ssl.py#L1201-L1218 [4] https://gist.github.com/tiran/6e7a5b00483376e164c951730db7d4e5 [5] https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.2.3 From matt at openssl.org Thu Nov 2 10:45:26 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 2 Nov 2017 10:45:26 +0000 Subject: [openssl-users] TLS 1.3 handshake: Limit signature algorithm? In-Reply-To: References: Message-ID: <146b22a2-a88c-f2ac-a956-4af4e68a9df5@openssl.org> On 02/11/17 10:32, Christian Heimes wrote: > However this trick will not work with TLS 1.3. The new TLS 1.3 cipher > suites no longer specify authentication algorithm or key > agreement/exchange. TLS 1.3 RFC specifies a signature_algorithms > extension [5]. I could not find any API call in OpenSSL master to set > the extension for TLS 1.3 handshakes. Probably you want to look at these functions: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_sigalgs.html Matt From Jagan.Govindarajan at dish.com Thu Nov 2 10:38:43 2017 From: Jagan.Govindarajan at dish.com (Govindarajan, Jagan) Date: Thu, 2 Nov 2017 10:38:43 +0000 Subject: [openssl-users] SSL_write & SSL_read speed optimization on embedded platform Message-ID: Dear friends, I am looking for optimizing the SSL_write() and SSL_read() operation on an embedded platform. Below is the setup currently I have 1. Hardware OpenSSL engine library for the platform is present for carrying out any HW AES encryption and AES decryption functionality 2. The platform requires data to be present in the specific HW memory range before the HW encryption or decryption API be called from the HW OpenSSL engine. 3. The application calls SSL_read(pSSL, pbuf, num); and SSL_wirte(pSSL, pbuf, num); 4. If we pass a pointer "pbuf" from the HW memory range, we observe the buffer pointer pbuf is not passed to the HW OpenSSL engine, but some other intermediate buffer pointer is getting passed. 5. We are now copying the data from the intermediate buffer passed to the HW OpenSSL engine into the HW memory range for doing the encryption or decryption. And copying back the data from the HW memory range into the intermediate buffer passed to the HW openssl engine. Is there a way I can force the OpenSSL to pass the required buffer pointer to HW OpenSSL engine to avoid any memcpy in the HW OpenSSL engine. Appreciate any help on this. Regards, Jagan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jagan.Govindarajan at dish.com Thu Nov 2 10:53:36 2017 From: Jagan.Govindarajan at dish.com (Govindarajan, Jagan) Date: Thu, 2 Nov 2017 10:53:36 +0000 Subject: [openssl-users] SSL_write & SSL_read speed optimization on embedded platform Message-ID: Dear friends, I am looking for optimizing the SSL_write() and SSL_read() operation on an embedded platform. Below is the setup currently I have 1. Hardware OpenSSL engine library for the platform is present for carrying out any HW AES encryption and AES decryption functionality 2. The platform requires data to be present in the specific HW memory range before the HW encryption or decryption API be called from the HW OpenSSL engine. 3. The application calls SSL_read(pSSL, pbuf, num); and SSL_wirte(pSSL, pbuf, num); 4. If we pass a pointer "pbuf" from the HW memory range, we observe the buffer pointer pbuf is not passed to the HW OpenSSL engine, but some other intermediate buffer pointer is getting passed. 5. We are now copying the data from the intermediate buffer passed to the HW OpenSSL engine into the HW memory range for doing the encryption or decryption. And copying back the data from the HW memory range into the intermediate buffer passed to the HW openssl engine. Is there a way I can force the OpenSSL to pass the required buffer pointer to HW OpenSSL engine to avoid any memcpy in the HW OpenSSL engine. Appreciate any help on this. Regards, Jagan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Thu Nov 2 11:08:17 2017 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Thu, 2 Nov 2017 16:38:17 +0530 Subject: [openssl-users] Wanted details on ./config or Configure options In-Reply-To: <372406bb-0460-9dcb-46dc-061a3570f939@openssl.org> References: <57a49aa9-9364-461e-1881-6039175f1ebe@openssl.org> <1a6da94e-b2e0-6449-386e-14162fa711d8@openssl.org> <372406bb-0460-9dcb-46dc-061a3570f939@openssl.org> Message-ID: Hi Matt, Thanks for the reply. We dont want to turn off the engine fully. We have TPM chip, that is part of OpenSSL. I just want to turn off default available hardware using no-hw-4758-cca no-hw-aep no-hw-atalla no-hw-chil no-hw-cswift no-hw-ibmca no-hw-ncipher no-hw-nuron no-hw- padlock no-hw-sureware no-hw-ubsec no-hw-zencod. However as of now using the above values with ./Configure is not turning off the compilation of the other hardware components. Regards Jaya On Thu, Nov 2, 2017 at 3:56 PM, Matt Caswell wrote: > > > On 02/11/17 07:07, Jayalakshmi bhat wrote: > > Hi Matt, > > > > Thanks a lot for the response. Sorry for the delayed reply. I was out of > > office for a while. This helped me. However I am not seeing option to > > remove unwanted engine files to go away from compilation. OpenSSL 1.01x > > method > > (no-hw no-hw-4758-cca no-hw-aep no-hw-atalla no-hw-chil > no-hw-cswift no-hw-ibmca no-hw-ncipher no-hw-nuron no-hw- > padlock no-hw-sureware no-hw-ubsec no-hw-zencod) > > does not seems to work. Is there any way to do it? > > Hmmm - that looks like a possible bug to me. I think that should work > (Richard Levitte may be able to comment). > > You can also use no-engine which switches off engine support altogether > > Matt > > > > > > > Regards > > Jayalakshmi > > > > On Thu, Oct 26, 2017 at 4:09 PM, Matt Caswell > > wrote: > > > > > > > > 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 > > stable/INSTALL> > > > stable/INSTALL > > stable/INSTALL>> > > > > > > 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 wouter.verhelst at fedict.be Thu Nov 2 13:41:05 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Thu, 2 Nov 2017 14:41:05 +0100 Subject: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0 In-Reply-To: <3b60b590-90f7-46e6-52a2-d708ad8b66e8@openssl.org> References: <7E6DC9C7-2948-4B74-8CDD-7B6A45DF6BA1@carillon.ca> <65b1aebd-6f8d-12a0-28d5-33e45f47494a@openssl.org> <3b60b590-90f7-46e6-52a2-d708ad8b66e8@openssl.org> Message-ID: On 31-10-17 17:47, Matt Caswell wrote: > > > 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. That's a sensible policy, thanks. > 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). As I ran into this when reviewing how to do OCSP, but ended up not needing it (I need normal path validation within a limited set of root certificates), I might look into doing that if/when I find the time for it some time soon. Thanks, -- Wouter Verhelst From paul.greene.va at gmail.com Thu Nov 2 14:23:49 2017 From: paul.greene.va at gmail.com (Paul Greene) Date: Thu, 2 Nov 2017 10:23:49 -0400 Subject: [openssl-users] Troubleshooting SSL connections Message-ID: <061905cd-82b5-ddff-31b0-0e9b9899ac30@gmail.com> Hello All, I've got two servers that need to communicate with each other using SSL. The applications that are supposed to talk to each other are custom in house applications. When I try to connect to the upstream server, you can see the initial connection established - "Connecting to "":8443 ... connected" Then you get "Initiating SSL handshake. SSL handshake failed. Closed fd 3. Unable to establish SSL connection" The network path between the two servers is rather convoluted - the IP address of my server gets NATed at least twice, it passes through a couple of different firewalls, proxy servers, and load balancers. The upstream server is on a public IP address, but the path to get there is an internal network that doesn't hit the public internet directly. As a test with the application administrator, I cloned my server and moved the cloned copy (vmware servers) to a public IP address and attempted the connection from there, and it worked without an issue. The connection was established and it started polling the upstream server the way it was supposed to. That should indicate that there isn't an issue with either the server I'm managing or the upstream server, and the problem must be somewhere in the network in between. (the upstream server has been up and running for at least a year, so I'm pretty sure there is no issue with their server itself) There's three different tech support groups that I have to deal with to troubleshoot this issue. They all have monitored the traffic and seen the initial connection being established, so they believe there is nothing on their side blocking the traffic, but no one can determine why the SSL connection keeps failing. But something, somewhere in that network path is messing with the network stream when it comes to processing the SSL packets. Sorry this post is rather convoluted and long winded - what I'm hoping is that someone might suggest what might be happening here that is messing with the connections (because this is an openssl list and the problem is related to failing ssl connections). I don't manage or have control over any of the network devices in between, so all I can do is suggest something "out of the box" that they might not have thought of before. Thanks, Paul From rsalz at akamai.com Thu Nov 2 14:52:49 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 2 Nov 2017 14:52:49 +0000 Subject: [openssl-users] Wanted details on ./config or Configure options In-Reply-To: <372406bb-0460-9dcb-46dc-061a3570f939@openssl.org> References: <57a49aa9-9364-461e-1881-6039175f1ebe@openssl.org> <1a6da94e-b2e0-6449-386e-14162fa711d8@openssl.org> <372406bb-0460-9dcb-46dc-061a3570f939@openssl.org> Message-ID: <6FE4C81A-7433-4160-B790-F0FD27B2C206@akamai.com> > remove unwanted engine files to go away from compilation. OpenSSL 1.01x 1.0.1 or 1.1.0 release? I?m guessing 1.0.1, since many of those engines are removed from 1.1.0 From rsalz at akamai.com Thu Nov 2 15:00:58 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 2 Nov 2017 15:00:58 +0000 Subject: [openssl-users] Troubleshooting SSL connections In-Reply-To: <061905cd-82b5-ddff-31b0-0e9b9899ac30@gmail.com> References: <061905cd-82b5-ddff-31b0-0e9b9899ac30@gmail.com> Message-ID: <854B82F9-8C99-4174-B91A-9C0CF83FBF03@akamai.com> Have you thought of putting a packet-capture on, say, the client side and then viewing it? From openssl at openssl.org Thu Nov 2 15:16:56 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 2 Nov 2017 15:16:56 +0000 Subject: [openssl-users] OpenSSL version 1.0.2m published Message-ID: <20171102151656.GA14031@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.0.2m released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2m of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2m is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2m.tar.gz Size: 5373776 SHA1 checksum: 27fb00641260f97eaa587eb2b80fab3647f6013b SHA256 checksum: 8c6ff15ec6b319b50788f42c7abc2890c08ba5a1cdcd3810eb9092deada37b0f The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2m.tar.gz openssl sha256 openssl-1.0.2m.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ+yzNAAoJENnE0m0OYESRd2UIAK0+Ht1wVP/VaL97rv7l4aBp l5JRH/0OnvIwvGh5CEGywY5MDXWZisMAzDB8AeNtDfGcN3eMDJkUITglT6EiDavF P4g3ZoK+JPJRER4i3S8z33z6x8yUBMZ26o0xVvI/JndsPGxa5oTLOGVYAi9YNwGu /IYuuYfZctzY/kVzlVn1AsoorD7trwsvAzh2bBCyWELJx3s7D40riQ8NpElmHXTg InSQRZmb83i70RYEqYTwSKKpCUjaUSZeUo3OWgzxoQfTh4IshlyB1Pdrwab7x69l gsLx914YkO+i388lqGTIMpCsdFVnu9Feap8Q2L+HsyIsnN8M8ZSvqudV6di9EO4= =al6h -----END PGP SIGNATURE----- From openssl at openssl.org Thu Nov 2 15:17:15 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 2 Nov 2017 15:17:15 +0000 Subject: [openssl-users] OpenSSL version 1.1.0g published Message-ID: <20171102151715.GA14329@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.0g released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0g of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0g is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0g.tar.gz Size: 5404748 SHA1 checksum: e8240a8be304d4317a750753321b073c664bfdd4 SHA256 checksum: de4d501267da39310905cb6dc8c6121f7a2cad45a7707f76df828fe1b85073af The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0g.tar.gz openssl sha256 openssl-1.1.0g.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ+yu1AAoJENnE0m0OYESRqkkH/3LhY0dicqyjbrE/COsUmHsi TWjd35afOl5N1LRouz7lhLE1lQsKXP67h5FCXsuCvmqwk4sJu6ItfeHOBQqkL41Q 9GS1jXasJwB4EQ0cYIPQwjC+DN1H+TWj9AYeCrvnfBTczTOujW7neEUVH2yuknk0 Gd+KOdhCIvVRxEucDQPmoza+yESpZNY01VPtGutjMAp2WDq+rYm9MUqUyAYzbRhj 5EgHx1ZRrmOU3//qsMC6sNea3uUyQL+AHdKHAsAP1QgeVEJoEgxi283FNG9cYvRh ZaaV9qZzg26dubXfOjUkIW7DxMyQ64WwIwJWDL/GtQwBLKIr5hvWqEYRnllvbZE= =I8uX -----END PGP SIGNATURE----- From openssl at openssl.org Thu Nov 2 15:20:52 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 2 Nov 2017 15:20:52 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20171102152052.GA17825@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [02 Nov 2017] ======================================== bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736) ====================================================== Severity: Moderate There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. This only affects processors that support the BMI1, BMI2 and ADX extensions like Intel Broadwell (5th generation) and later or AMD Ryzen. Note: This issue is very similar to CVE-2017-3732 and CVE-2015-3193 but must be treated as a separate problem. OpenSSL 1.1.0 users should upgrade to 1.1.0g OpenSSL 1.0.2 users should upgrade to 1.0.2m This issue was reported to OpenSSL on 10th August 2017 by the OSS-Fuzz project. The fix was developed by Andy Polyakov of the OpenSSL development team. Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735) ==================================================================== Severity: Low This issue was previously announced in security advisory https://www.openssl.org/news/secadv/20170828.txt, but the fix has not previously been included in a release due to its low severity. OpenSSL 1.1.0 users should upgrade to 1.1.0g OpenSSL 1.0.2 users should upgrade to 1.0.2m Note ==== Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20171102.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ+y3yAAoJENnE0m0OYESRWooH/2cS+HkzBCCdnJ/CWuhKomTe hshdBbYw/eYeZgrUYZX6CYosvhLX1Hkwef3vVMxHDXsnBnnZfGfwCS2EfXJ96xXK KiXVchBwlpmovrOuAvrGtPqLkiVOZZpGMfopP30WCKc6tkdqjw/NvruMbg7Iz+Sy ki5AM7Vw7kAEa18KAGjSN4jSrCHMIKkOeGkmay5hHlYLwQRQDAAo5EmWmVOJpUXF ddvQ6h+NKqlWAMF+2/U3PhUFa4V7xqlKR3GMdRawVSaoKQUsPXvRGAhLnvqfOonx y0yl7y9a7EJrcRl8HWf7qqZf0B/m3YapCHNNcBYWry+qk7LJgGjIHDF8VFkEABg= =k+bJ -----END PGP SIGNATURE----- From bhat.jayalakshmi at gmail.com Thu Nov 2 17:12:53 2017 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Thu, 2 Nov 2017 22:42:53 +0530 Subject: [openssl-users] Wanted details on ./config or Configure options In-Reply-To: References: <57a49aa9-9364-461e-1881-6039175f1ebe@openssl.org> <1a6da94e-b2e0-6449-386e-14162fa711d8@openssl.org> <372406bb-0460-9dcb-46dc-061a3570f939@openssl.org> Message-ID: Hi Rich, I am using OpenSSL 1.0.2h. And I am trying to strip off unused hardware support. I tried using the options mentioned for 1.0.1e which I have explained in the previous mail. They dont seems to work for 1.0.2h. Hence I wanted to know what would be the best way to remove the unsupported hardware like aep, chill, cswift etc from compilation. Regards Jayalakshmi On Thu, Nov 2, 2017 at 4:38 PM, Jayalakshmi bhat wrote: > Hi Matt, > > Thanks for the reply. We dont want to turn off the engine fully. We have > TPM chip, that is part of OpenSSL. I just want to turn off default > available hardware using > > no-hw-4758-cca no-hw-aep no-hw-atalla no-hw-chil no-hw- > cswift no-hw-ibmca no-hw-ncipher no-hw-nuron no-hw-padl > ock no-hw-sureware no-hw-ubsec no-hw-zencod. > > However as of now using the above values with ./Configure is not turning > off the compilation of the other hardware components. > > Regards > Jaya > > On Thu, Nov 2, 2017 at 3:56 PM, Matt Caswell wrote: > >> >> >> On 02/11/17 07:07, Jayalakshmi bhat wrote: >> > Hi Matt, >> > >> > Thanks a lot for the response. Sorry for the delayed reply. I was out of >> > office for a while. This helped me. However I am not seeing option to >> > remove unwanted engine files to go away from compilation. OpenSSL 1.01x >> > method >> > (no-hw no-hw-4758-cca no-hw-aep no-hw-atalla no-hw-chil no- >> hw-cswift no-hw-ibmca no-hw-ncipher no-hw-nuron no-hw-padl >> ock no-hw-sureware no-hw-ubsec no-hw-zencod) >> > does not seems to work. Is there any way to do it? >> >> Hmmm - that looks like a possible bug to me. I think that should work >> (Richard Levitte may be able to comment). >> >> You can also use no-engine which switches off engine support altogether >> >> Matt >> >> > >> > >> > Regards >> > Jayalakshmi >> > >> > On Thu, Oct 26, 2017 at 4:09 PM, Matt Caswell > > > wrote: >> > >> > >> > >> > 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-stabl >> e/INSTALL >> > > le/INSTALL> >> > > > le/INSTALL >> > > le/INSTALL>> >> > > >> > > 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 paul.greene.va at gmail.com Thu Nov 2 23:23:36 2017 From: paul.greene.va at gmail.com (Paul Greene) Date: Thu, 2 Nov 2017 19:23:36 -0400 Subject: [openssl-users] Troubleshooting SSL connections In-Reply-To: <854B82F9-8C99-4174-B91A-9C0CF83FBF03@akamai.com> References: <061905cd-82b5-ddff-31b0-0e9b9899ac30@gmail.com> <854B82F9-8C99-4174-B91A-9C0CF83FBF03@akamai.com> Message-ID: Yes. I've made captures on both - the production client that I manage and the test client I have at home. On the production client, the conversation lasts only 8 packets - the initial 3 way handshake, my client sends a PUSH packet, gets an ACK from the upstream, and then the upstream sends a FIN packet and closes the connection. The actual error message you see from the commandline is what I posted above. On the test client, after the PUSH packet is sent to the upstream server, it starts a conversation, and they continue the conversation until I did a CTRL-C. Paul On Thu, Nov 2, 2017 at 11:00 AM, Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > Have you thought of putting a packet-capture on, say, the client side and > then viewing it? > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Fri Nov 3 00:43:38 2017 From: aerowolf at gmail.com (Kyle Hamilton) Date: Thu, 2 Nov 2017 17:43:38 -0700 Subject: [openssl-users] Troubleshooting SSL connections In-Reply-To: References: <061905cd-82b5-ddff-31b0-0e9b9899ac30@gmail.com> <854B82F9-8C99-4174-B91A-9C0CF83FBF03@akamai.com> Message-ID: What kind of stateful packet inspection are the NATs doing? Can you run packet captures on each network that's being translated? -Kyle H On Thu, Nov 2, 2017 at 4:23 PM, Paul Greene wrote: > Yes. I've made captures on both - the production client that I manage and > the test client I have at home. > On the production client, the conversation lasts only 8 packets - the > initial 3 way handshake, my client sends a PUSH packet, gets an ACK from the > upstream, and then the upstream sends a FIN packet and closes the > connection. The actual error message you see from the commandline is what I > posted above. > On the test client, after the PUSH packet is sent to the upstream server, it > starts a conversation, and they continue the conversation until I did a > CTRL-C. > > Paul > > On Thu, Nov 2, 2017 at 11:00 AM, Salz, Rich via openssl-users > wrote: >> >> Have you thought of putting a packet-capture on, say, the client side and >> then viewing it? >> >> >> -- >> 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 shinelight at shininglightpro.com Fri Nov 3 13:54:29 2017 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Fri, 3 Nov 2017 06:54:29 -0700 Subject: [openssl-users] Latest releases missing from website Message-ID: I still only see 1.0.2l and 1.1.0f at: https://www.openssl.org/source/ Tried multiple browsers, flushed caches, etc. The problem does not appear to be on my end of things. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From matt at openssl.org Fri Nov 3 13:58:35 2017 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 Nov 2017 13:58:35 +0000 Subject: [openssl-users] Latest releases missing from website In-Reply-To: References: Message-ID: <1ba66827-16ef-492d-aa04-b6f54c96d160@openssl.org> On 03/11/17 13:54, Thomas J. Hruska wrote: > I still only see 1.0.2l and 1.1.0f at: > > https://www.openssl.org/source/ > > Tried multiple browsers, flushed caches, etc.? The problem does not > appear to be on my end of things. > Hmmm....its working for me. Perhaps an Akamai issue Rich Salz? In the meantime try downloading them using the direct links: https://www.openssl.org/source/openssl-1.0.2m.tar.gz https://www.openssl.org/source/openssl-1.1.0g.tar.gz Matt From rsalz at akamai.com Fri Nov 3 14:03:11 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 3 Nov 2017 14:03:11 +0000 Subject: [openssl-users] Latest releases missing from website In-Reply-To: <1ba66827-16ef-492d-aa04-b6f54c96d160@openssl.org> References: <1ba66827-16ef-492d-aa04-b6f54c96d160@openssl.org> Message-ID: <7A7B90B3-553B-492F-A564-C81123D47226@akamai.com> ? Hmmm....its working for me. Perhaps an Akamai issue Rich Salz? Don?t know, looked okay to me. I re-flushed the cache From Michael.Wojcik at microfocus.com Fri Nov 3 14:55:51 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 3 Nov 2017 14:55:51 +0000 Subject: [openssl-users] Latest releases missing from website In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Thomas J. Hruska > Sent: Friday, November 03, 2017 09:54 > > I still only see 1.0.2l and 1.1.0f at: > > https://www.openssl.org/source/ There will probably be a million of these replies, but I see the links for the new releases, and they (the links) appear to be working. Michael Wojcik Distinguished Engineer, Micro Focus From jgh at wizmail.org Sat Nov 4 23:11:40 2017 From: jgh at wizmail.org (Jeremy Harris) Date: Sat, 4 Nov 2017 23:11:40 +0000 Subject: [openssl-users] Fwd: SSL_get_certificate() Message-ID: 1.0.2k fips. Server, having loaded two certs (one rsa, one ecdsa) using SSL_CTX_use_certificate_chain_file(). After SSL_accept(), call SSL_get_certificate() to see what cert was presented. The actual on-the-wire does what I'm expecting - the presented server cert varies according to the server ciphers list ordering. However, the SSL_get_certificate() call always returns the last cert loaded. What should I be doing different? -- Thanks, Jeremy From openssl-users at dukhovni.org Sat Nov 4 23:39:00 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 4 Nov 2017 19:39:00 -0400 Subject: [openssl-users] Fwd: SSL_get_certificate() In-Reply-To: References: Message-ID: <9020368E-6A01-44EB-9189-1E7CBC9AECBD@dukhovni.org> > On Nov 4, 2017, at 7:11 PM, Jeremy Harris wrote: > > 1.0.2k fips. I hope you're not enabling, or at least not voluntarily enabling FIPS mode, but that's off-topic... > Server, having loaded two certs (one rsa, one ecdsa) using > SSL_CTX_use_certificate_chain_file(). > > After SSL_accept(), call SSL_get_certificate() to see what > cert was presented. The negotiated certificate is only populated in the server SSL handle when you've registered a TLS status callback. See SSL_CTX_set_tlsext_status_cb(3) > What should I be doing different? For now, instantiate the callback. I think we should look into changing the behaviour at some point to always make this available at the completion of the handshake. And document SSL_get_certificate(). Feel free to open an issue on Github... -- Viktor. From openssl-users at dukhovni.org Sun Nov 5 00:36:52 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 4 Nov 2017 20:36:52 -0400 Subject: [openssl-users] Fwd: SSL_get_certificate() In-Reply-To: <6d50ddf5-7d32-2ad3-5abe-5872baaeee7a@wizmail.org> References: <9020368E-6A01-44EB-9189-1E7CBC9AECBD@dukhovni.org> <6d50ddf5-7d32-2ad3-5abe-5872baaeee7a@wizmail.org> Message-ID: <5526C995-01ED-49B9-A459-0B578D92CC68@dukhovni.org> > On Nov 4, 2017, at 8:12 PM, Jeremy Harris wrote: > >>> After SSL_accept(), call SSL_get_certificate() to see what >>> cert was presented. >> >> The negotiated certificate is only populated in the server SSL >> handle when you've registered a TLS status callback. See >> >> SSL_CTX_set_tlsext_status_cb(3) >> >>> What should I be doing different? >> >> For now, instantiate the callback. > > It doesn't appear to make any difference :-( Looking more closely, the server might actually need to have received a status request *and* for there to a callback: https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/t1_lib.c#L3174 The assignment of the current keypair happens on: https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/t1_lib.c#L3193 I think we should probably do: if (certpkey != NULL) { /* * Set current certificate to one we will use so SSL_get_certificate * et al can pick it up. */ s->cert->key = certpkey; Unconditionally, at the top of the function, even if there's no callback and no status request... -- Viktor. From Michal.Trojnara at stunnel.org Sun Nov 5 23:02:51 2017 From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=) Date: Mon, 6 Nov 2017 00:02:51 +0100 Subject: [openssl-users] stunnel 5.43 released Message-ID: Dear Users, I have released version 5.43 of stunnel. Version 5.43, 2017.11.05, urgency: LOW * New features - OpenSSL DLLs updated to version 1.0.2m. - Android build updated to OpenSSL 1.1.0g. - Allow for multiple "accept" ports per section. - Self-test framework (make check). - Added config load before OpenSSL init (thx to Dmitrii Pichulin). - OpenSSL 1.1.0 support for Travis CI. - OpenSSL 1.1.1-dev compilation fixes. * Bugfixes - Fixed a memory fault on Solaris. - Fixed round-robin failover in the FORK threading model. - Fixed handling SSL_ERROR_ZERO_RETURN in SSL_shutdown(). - Minor fixes of the logging subsystem. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 05915babf705a0494886a72a7367913d403d07fc908ebb7b380d639e2d8bcee2 stunnel-5.43.tar.gz 5249479d295f482ecac9cd3d5c89c0e5d41ae6ff8e265d4634ecfd8761834201 stunnel-5.43-win32-installer.exe e628fa7027d19bf4f0a62392f9dc042d97959498c292e13ebdf30c65a545dd6d stunnel-5.43-android.zip Best regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 866 bytes Desc: OpenPGP digital signature URL: From wangqun at alumni.nus.edu.sg Mon Nov 6 06:13:46 2017 From: wangqun at alumni.nus.edu.sg (Wang) Date: Sun, 5 Nov 2017 23:13:46 -0700 (MST) Subject: [openssl-users] Potential memory leak in RSA_private_decrypt Message-ID: <1509948826636-0.post@n7.nabble.com> Hello, The memory usage of one of our OpenSSL applications increases quickly.Valgrind detects the only possible leak below. We are using OpenSSL 1.0.2k. ==9721== 520 bytes in 1 blocks are indirectly lost in loss record 1,178 of1,294 ==9721== at 0x4A0817C: malloc (vg_replace_malloc.c:298) ==9721== by 0x5B29CD0: comn_malloc (comalloc.c:28) ==9721== by 0x58E7DD2: comn__csi_malloc (netenc2.c:52) ==9721== by 0xBBC37EA: local_malloc (csi_provider_common.c:624) ==9721== by 0xBC1747F: default_malloc_ex (mem.c:79) ==9721== by 0xBC17BA6: CRYPTO_malloc (mem.c:350) ==9721== by 0xBC2648F: bn_expand_internal (bn_lib.c:303) ==9721== by 0xBC266AA: bn_expand2 (bn_lib.c:431) ==9721== by 0xBC26FF6: BN_set_bit (bn_lib.c:736) ==9721== by 0xBCE0880: BN_MONT_CTX_set (bn_mont.c:494) ==9721== by 0xBCE0A2F: BN_MONT_CTX_set_locked (bn_mont.c:544) ==9721== by 0xBCED0C0: RSA_eay_mod_exp (rsa_eay.c:763) ==9721== by 0xBCEC747: RSA_eay_private_decrypt (rsa_eay.c:554) ==9721== by 0xBC3B7DE: RSA_private_decrypt (rsa_crpt.c:111) I searched in this forum. I found a post reporting the same issue, but noresolution provided -http://openssl.6102.n7.nabble.com/Memory-issues-with-ssl-handshake-td20851.html#a20854. I wonder if anyone knows how to resolve this issue? Any help is appreciated. Aaron -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From viney.yadav at gmail.com Mon Nov 6 12:52:59 2017 From: viney.yadav at gmail.com (Viney Yadav) Date: Mon, 6 Nov 2017 18:22:59 +0530 Subject: [openssl-users] SSL_renegotiate for DTLS client Message-ID: Going through the documentation of SSL_renegotiate , it says "For historical reasons, DTLS clients will not attempt to resume the session in the new handshake". The paragraph is about how OpenSSL client would handle a renegotiation request from the server. Does this mean that the DLTS client on receiving a HelloRequest will always go for a full handshake and will not include the session id or ticket info that it has from the previous session? Thanks, Viney -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Nov 6 13:23:26 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 6 Nov 2017 13:23:26 +0000 Subject: [openssl-users] SSL_renegotiate for DTLS client In-Reply-To: References: Message-ID: On 06/11/17 12:52, Viney Yadav wrote: > Going through the documentation of SSL_renegotiate > , it > says "For historical reasons, DTLS clients will not attempt to resume > the session in the new handshake". The paragraph is about how OpenSSL > client would handle a renegotiation request from the server. > > Does this mean that the DLTS client on receiving a HelloRequest will > always go for a full handshake and will not include the session id or > ticket info that it has from the previous session? Yes. Matt From charlesm at mcn.org Mon Nov 6 22:04:08 2017 From: charlesm at mcn.org (Charles Mills) Date: Mon, 6 Nov 2017 14:04:08 -0800 Subject: [openssl-users] Help with making a SHA >1 certificate Message-ID: <20e801d3574b$2b704ca0$8250e5e0$@mcn.org> Please forgive my ignorance here. I'm really not a certificate expert. I'm a software developer trying to make certificates to use in a testing situation. I've got some scripts that I have been using for years. I've just upgraded to 1.10f (but there are no upgrade issues that I know of - that's not the problem). My last test certificate expired. So I am trying to make another one. All I seem to be able to make are SHA-1 signed certificates, but I'm trying to load them into a FIPS-140 (non-OpenSSL) key repository and it is failing, I think because of the SHA-1. Here is how I am making the certificate. What do I have to do differently to make a SHA-512 (or at least some SHA > 1) certificate? C:\OpenSSL-Win32-110f\bin\openssl.exe req -newkey rsa:2048 -sha512 -keyout %1.key.pem -out %1.req.pem -config openssl_edited_win32_default.cfg -extensions usr_cert -reqexts usr_cert -nodes -days 3650 C:\OpenSSL-Win32-110f\bin\openssl req -text -in %1.req.pem -sha512 C:\OpenSSL-Win32-110f\bin\openssl.exe ca -in %1.req.pem -config CMC_root_config.cnf -out %1.pem -verbose -cert CMC_root.pem -keyfile CMC_root.key.pem -passin pass:password Here is what I end up with: Signature Algorithm: sha1WithRSAEncryption Issuer: CN=Charles Mills Consulting, LLC, ST=California, C=US/emailAddress=charlesm at mcn.org, O=Charles Mills Consulting, LLC Validity Not Before: Nov 6 19:13:09 2017 GMT Not After : Nov 6 19:13:09 2018 GMT Subject: CN=Charles Mills Consulting, LLC, ST=California, C=US/emailAddress=charlesm at mcn.org, O=CZAGENT_Nov2017 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) While we're at it, why doesn't my -days 3650 seem to have any effect? Thanks! Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From warron.french at gmail.com Tue Nov 7 00:02:10 2017 From: warron.french at gmail.com (warron.french) Date: Mon, 6 Nov 2017 19:02:10 -0500 Subject: [openssl-users] Help with making a SHA >1 certificate In-Reply-To: <20e801d3574b$2b704ca0$8250e5e0$@mcn.org> References: <20e801d3574b$2b704ca0$8250e5e0$@mcn.org> Message-ID: Charles, I am no expert either - sorry. However, the question about why is your signed certificate at least not getting to be over 1 year in "length?" What is the duration of the CA's certificate? -------------------------- Warron French On Mon, Nov 6, 2017 at 5:04 PM, Charles Mills wrote: > Please forgive my ignorance here. I?m really not a certificate expert. I?m > a software developer trying to make certificates to use in a testing > situation. > > > > I?ve got some scripts that I have been using for years. I?ve just upgraded > to 1.10f (but there are no upgrade issues that I know of ? that?s not the > problem). > > > > My last test certificate expired. So I am trying to make another one. All > I seem to be able to make are SHA-1 signed certificates, but I?m trying to > load them into a FIPS-140 (non-OpenSSL) key repository and it is failing, I > think because of the SHA-1. Here is how I am making the certificate. What > do I have to do differently to make a SHA-512 (or at least some SHA > 1) > certificate? > > > > C:\OpenSSL-Win32-110f\bin\openssl.exe req -newkey rsa:2048 -sha512 > -keyout %1.key.pem -out %1.req.pem -config openssl_edited_win32_default.cfg > -extensions usr_cert -reqexts usr_cert -nodes -days 3650 > > C:\OpenSSL-Win32-110f\bin\openssl req -text -in %1.req.pem -sha512 > > C:\OpenSSL-Win32-110f\bin\openssl.exe ca -in %1.req.pem -config > CMC_root_config.cnf -out %1.pem -verbose -cert CMC_root.pem -keyfile > CMC_root.key.pem -passin pass:password > > > > Here is what I end up with: > > > > Signature Algorithm: sha1WithRSAEncryption > > Issuer: CN=Charles Mills Consulting, LLC, ST=California, > C=US/emailAddress=charlesm at mcn.org, O=Charles Mills Consulting, LLC > > Validity > > Not Before: Nov 6 19:13:09 2017 GMT > > Not After : Nov 6 19:13:09 2018 GMT > > Subject: CN=Charles Mills Consulting, LLC, ST=California, > C=US/emailAddress=charlesm at mcn.org, O=CZAGENT_Nov2017 > > Subject Public Key Info: > > Public Key Algorithm: rsaEncryption > > Public-Key: (2048 bit) > > > > While we?re at it, why doesn?t my ?days 3650 seem to have any effect? > > > > Thanks! > > > > *Charles * > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Karyn.Ulriksen at riverbed.com Tue Nov 7 00:14:04 2017 From: Karyn.Ulriksen at riverbed.com (Karyn Ulriksen) Date: Tue, 7 Nov 2017 00:14:04 +0000 Subject: [openssl-users] Cross-compile runtime issues Message-ID: I am currently cross compiling for an embedded linux platform running mips64 hardware. It successfully compiles using linux-generic64. Also, openssl with the fips parameter successfully compiles. However, once I install it on the platform, I just get an encrypted string back from it no matter the parameter I pass it. For example: # ./openssl version 831d69ae76f30335ae4fdfd243bccca8656950c4 If I build openssl without the fips module, it spits out the standard version info as expected. I've started playing around with the incore utility, but it would be helpful to know that this is the right direction to work on. Is the output above expected if the the signature is incorrect? Is incore the tool to use to get it back on track? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangqun at alumni.nus.edu.sg Tue Nov 7 00:53:05 2017 From: wangqun at alumni.nus.edu.sg (Wang) Date: Mon, 6 Nov 2017 17:53:05 -0700 (MST) Subject: [openssl-users] Potential memory leak in RSA_private_decrypt In-Reply-To: <1509948826636-0.post@n7.nabble.com> References: <1509948826636-0.post@n7.nabble.com> Message-ID: <1510015985402-0.post@n7.nabble.com> The product can be build in threaded or non-threaded mode. The memory leak can be detected only in threaded mode. Hence I think I hit the same issue reported by Thomas in 2012. "One thing I noticed is that all goes well if I cause the code to run sequentially (e.g. cause requests to come one ater another). Yet it starts eating up memory like crazy if I cause several (HTTPS) requests to come at once. " http://openssl.6102.n7.nabble.com/Memory-issues-with-ssl-handshake-td20851.html#a20854. Don't understand why this issue is not encountered by other users and why it has not been fixed for so many years. Thanks, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From rsalz at akamai.com Tue Nov 7 03:29:57 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 7 Nov 2017 03:29:57 +0000 Subject: [openssl-users] Potential memory leak in RSA_private_decrypt In-Reply-To: <1510015985402-0.post@n7.nabble.com> References: <1509948826636-0.post@n7.nabble.com> <1510015985402-0.post@n7.nabble.com> Message-ID: <7D1F82EC-49C6-4E58-A944-136A9C75CBE3@akamai.com> ? http://openssl.6102.n7.nabble.com/Memory-issues-with-ssl-handshake-td20851.html#a20854. ? Don't understand why this issue is not encountered by other users and why it has not been fixed for so many years. The first part answer the second. It is not encountered by others, so there might not be anything in OpenSSL to fix. Can you use valgrind or something, to see where the memory is being leaked? From d3ck0r at gmail.com Tue Nov 7 03:56:37 2017 From: d3ck0r at gmail.com (J Decker) Date: Mon, 6 Nov 2017 19:56:37 -0800 Subject: [openssl-users] How to know maximum sendable fragment size? Message-ID: I've been developing this NodeJS plugin, it implements HTTPS server and now client. I was having an issue with HTTPS request getting ECONNRESET for no apparent reason; so I implemented my own request, and ran into the same sort of issue. What I was requesting was some .js files from the server, and apparently my most recent changes to those files made them larger than some magic number greater than 4096 but less than 6561. The server was sending using OpenSSL (statically linked in the NodeJS executable) on CentOS, and it was sending the full length of the file as one buffer. I'm using memory BIO to interact with the SSL object; The buffer was transmitted as one block. With my own client, (where I could add debugging) was receiving the full count of bytes from the server but in two blocks, the first 4096 and the second 2472(something like that). Because my network read buffer was only 4096.... So the first read was short, and caused SSL_read to fail, which I had initially treated as a failure and terminated my connection. I then found I could (almost) check using SSL_pending before getting an error (really I ended up doing SSL_read( ssl, NULL, 0 ) and then SSL_pending(ssl) ). But after receiving the full count of bytes and having nothing else to receive, the message never completed (read return -1, and error 2, pending returned 0 ). I manually broke up the transmission to 4356 (3*1452 -29) bytes so it ends up sending in 3 full tcp buffer units, and that works. (it's http protocol so it's got higher level gathering for the fragments). It also works if I revert to using the NodeJS HTTPS request object instead of my own. So - how do I know what the maximum amount of data I can send is? Node TLS object (on which HTTPS is based) has tlsSocket.setMaxSendFragment(size)(which defaults to 16384) but that's about sending, not receiving, so I really have no idea how big the receive buffer is actually.... (same as SSL send fragment default) I did find https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_ split_send_fragment.html but there's no get_for fragment size I could find. (this would be on the server side that I need to know how much I can send). how do I set how big of a fragment I can receive? Like what if I tried to send 100's of Meg as a single fragment? (I guess it should auto fragment to like 16k) I guess there (will be) SSL_CTX_set_default_read_buffer_len() (1.1.0) (node's open ssl version) # define OPENSSL_VERSION_TEXT "OpenSSL 1.0.2l 25 May 2017" I guess read should default to something like SSL3_RT_MAX_PLAIN_LENGTH + SSL3_RT_MAX_ENCRYPTED_OVERHEAD (16704) ? I wonder why it doesn't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Nov 7 07:34:22 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 7 Nov 2017 08:34:22 +0100 Subject: [openssl-users] Help with making a SHA >1 certificate In-Reply-To: <20e801d3574b$2b704ca0$8250e5e0$@mcn.org> References: <20e801d3574b$2b704ca0$8250e5e0$@mcn.org> Message-ID: <063244cb-1640-3cc0-180e-0c1ec9eddfda@wisemo.com> Both the validity and the hash in the certificate are decided by the "ca" command, which you didn't tell about wanting sha512 and 10 years. sha512 on req determines only the hash used by the requestor to prove he has the private key and sign the name etc. *suggested* to the ca. -days on req when generating a request does noting, and should perhaps produce a warning, since this option is only meaningful when used with the -x509 option to produce a self-signed cert instead of a request. On 06/11/2017 23:04, Charles Mills wrote: > > Please forgive my ignorance here. I?m really not a certificate expert. > I?m a software developer trying to make certificates to use in a > testing situation. > > I?ve got some scripts that I have been using for years. I?ve just > upgraded to 1.10f (but there are no upgrade issues that I know of ? > that?s not the problem). > > My last test certificate expired. So I am trying to make another one. > All I seem to be able to make are SHA-1 signed certificates, but I?m > trying to load them into a FIPS-140 (non-OpenSSL) key repository and > it is failing, I think because of the SHA-1. Here is how I am making > the certificate. What do I have to do differently to make a SHA-512 > (or at least some SHA > 1) certificate? > > C:\OpenSSL-Win32-110f\bin\openssl.exe req -newkey rsa:2048 -sha512 > -keyout %1.key.pem -out %1.req.pem -config > openssl_edited_win32_default.cfg -extensions usr_cert -reqexts > usr_cert -nodes -days 3650 > > C:\OpenSSL-Win32-110f\bin\openssl req -text -in %1.req.pem -sha512 > > C:\OpenSSL-Win32-110f\bin\openssl.exe ca -in %1.req.pem -config > CMC_root_config.cnf -out %1.pem -verbose -cert CMC_root.pem -keyfile > CMC_root.key.pem -passin pass:password > > Here is what I end up with: > > ??? Signature Algorithm: sha1WithRSAEncryption > > ??????? Issuer: CN=Charles Mills Consulting, LLC, ST=California, > C=US/emailAddress=charlesm at mcn.org, O=Charles Mills Consulting, LLC > > ??????? Validity > > ??????????? Not Before: Nov? 6 19:13:09 2017 GMT > > ??????????? Not After : Nov? 6 19:13:09 2018 GMT > > ??????? Subject: CN=Charles Mills Consulting, LLC, ST=California, > C=US/emailAddress=charlesm at mcn.org, O=CZAGENT_Nov2017 > > ??????? Subject Public Key Info: > > ??????????? Public Key Algorithm: rsaEncryption > > ??????????????? Public-Key: (2048 bit) > > While we?re at it, why doesn?t my ?days 3650 seem to have any effect? > > Thanks! > > /Charles / > > > 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 wangqun at alumni.nus.edu.sg Tue Nov 7 10:01:14 2017 From: wangqun at alumni.nus.edu.sg (Wang) Date: Tue, 7 Nov 2017 03:01:14 -0700 (MST) Subject: [openssl-users] Potential memory leak in RSA_private_decrypt In-Reply-To: <1509948826636-0.post@n7.nabble.com> References: <1509948826636-0.post@n7.nabble.com> Message-ID: <1510048874324-0.post@n7.nabble.com> Hello Rich, Thank you for trying to help. My product is running on Linux. The following leak was detected by Valgrind. Valgrind only reportes the leak in threaded mode. I run 'top' on linux to monitor the memory usage of my product. I can see the memory usage increases quickly. ==9721== 520 bytes in 1 blocks are indirectly lost in loss record 1,178 of 1,294 ==9721== at 0x4A0817C: malloc (vg_replace_malloc.c:298) ==9721== by 0x5B29CD0: comn_malloc (comalloc.c:28) ==9721== by 0x58E7DD2: comn__csi_malloc (netenc2.c:52) ==9721== by 0xBBC37EA: local_malloc (csi_provider_common.c:624) ==9721== by 0xBC1747F: default_malloc_ex (mem.c:79) ==9721== by 0xBC17BA6: CRYPTO_malloc (mem.c:350) ==9721== by 0xBC2648F: bn_expand_internal (bn_lib.c:303) ==9721== by 0xBC266AA: bn_expand2 (bn_lib.c:431) ==9721== by 0xBC26FF6: BN_set_bit (bn_lib.c:736) ==9721== by 0xBCE0880: BN_MONT_CTX_set (bn_mont.c:494) ==9721== by 0xBCE0A2F: BN_MONT_CTX_set_locked (bn_mont.c:544) ==9721== by 0xBCED0C0: RSA_eay_mod_exp (rsa_eay.c:763) ==9721== by 0xBCEC747: RSA_eay_private_decrypt (rsa_eay.c:554) ==9721== by 0xBC3B7DE: RSA_private_decrypt (rsa_crpt.c:111) Regards, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From matt at openssl.org Tue Nov 7 10:28:29 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 7 Nov 2017 10:28:29 +0000 Subject: [openssl-users] How to know maximum sendable fragment size? In-Reply-To: References: Message-ID: <18f72535-2908-f43c-ec50-fcad912e3dbe@openssl.org> On 07/11/17 03:56, J Decker wrote: > I've been developing this NodeJS plugin, it implements HTTPS server and > now?client.? I was having an issue with HTTPS request getting ECONNRESET > for no?apparent reason; so I implemented my own request, and ran into > the same sort?of issue.? What I was requesting was some .js files from > the server, and?apparently my most recent changes to those files made > them larger than some?magic number greater than 4096 but less than > 6561.? The server was sending?using OpenSSL (statically linked in the > NodeJS executable) on CentOS, and it?was sending the full length of the > file as one buffer.? I'm using memory BIO?to interact with the SSL > object; The buffer was transmitted as one block.?With my own client, > (where I could add debugging) was receiving the full?count of bytes from > the server but in two blocks, the first 4096 and the?second > 2472(something like that).? Because my network read buffer was > only?4096.... So the first read was short, and caused SSL_read to fail, What do you mean this cause SSL_read() to fail? You got a <= 0 return value? This should not happen. It is perfectly valid to read less bytes than OpenSSL has available. > which I?had initially treated as a failure and terminated my > connection.? I then > found I could (almost) check using SSL_pending before getting an > error?(really I ended up doing SSL_read( ssl, NULL, 0 ) and then > SSL_pending(ssl) > ).? But after receiving the full count of bytes and having nothing else > to?receive, the message never completed (read return -1, and error 2, > pending > returned 0 ). I'm not sure sure what you mean by "the message never completed". Do you mean you were expecting more bytes but they never came? > I manually broke up the transmission to 4356 (3*1452 -29) > bytes so it ends?up sending in 3 full tcp buffer units, and that works.? > (it's http protocol?so it's got higher level gathering for the > fragments).? It also works if I?revert to using the NodeJS HTTPS request > object instead of my own. > > So - how do I know what the maximum amount of data I can send is? TLS is a stream protocol. There is no maximum amount of data you can send in one go. Internally the protocol breaks up the data into a number of records. The maximum amount of plaintext data sent in a single record is SSL3_RT_MAX_PLAIN_LENGTH (16384) bytes. This can be changed by your application (to something smaller - not larger) but you have to explicitly do that. However changing this should have no impact on the functional behaviour of your application. > > Node TLS object (on which HTTPS is based) > has?tlsSocket.setMaxSendFragment(size)(which defaults to 16384)? but > that's?about sending, not receiving, so I really have no idea how big > the receive?buffer is actually.... (same as SSL send fragment default) > > I did > find?https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_split_send_fragment.html > ?but > there's no get_for fragment size I could find.? (this would be on > the?server side that I need to know how much I can send). > > how do I set how big of a fragment I can receive? The TLS protocol defines the size of the maximum fragment so no well behaved implementation will ever send more than that. The OpenSSL buffers are sized accordingly. In normal operation you should never need to play around with these settings. Currently it is not possible to change the size of the receive fragment - the sender is always allowed to send any size up the to the maximum, so the receive buffers must always be at least as big as that. In 1.1.1 (in development) there is a feature which allows the client and server to negotiate a smaller fragment size if they wish - but this is typically only useful in resource constrained environments. >? Like what if I tried > to?send 100's of Meg as a single fragment?? ?(I guess it should auto > fragment to like 16k) If you send a large amount of data in an SSL_write() call then OpenSSL will automatically break that up into a series of records containing the maximum amount of data until all of the data has been sent. > > I guess there (will be)?SSL_CTX_set_default_read_buffer_len() (1.1.0) Unless you are doing pipelining with an engine that can support it then you do not need to call this function. Matt From matt at openssl.org Tue Nov 7 10:36:13 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 7 Nov 2017 10:36:13 +0000 Subject: [openssl-users] Potential memory leak in RSA_private_decrypt In-Reply-To: <1510048874324-0.post@n7.nabble.com> References: <1509948826636-0.post@n7.nabble.com> <1510048874324-0.post@n7.nabble.com> Message-ID: <99883d51-5a38-e99a-f6ee-30faf8e17033@openssl.org> On 07/11/17 10:01, Wang wrote: > Hello Rich, > > Thank you for trying to help. > > My product is running on Linux. The following leak was detected by Valgrind. > Valgrind only reportes > the leak in threaded mode. I run 'top' on linux to monitor the memory usage > of my product. I can see the memory usage increases quickly. > > ==9721== 520 bytes in 1 blocks are indirectly lost in loss record 1,178 of > 1,294 > ==9721== at 0x4A0817C: malloc (vg_replace_malloc.c:298) > ==9721== by 0x5B29CD0: comn_malloc (comalloc.c:28) > ==9721== by 0x58E7DD2: comn__csi_malloc (netenc2.c:52) > ==9721== by 0xBBC37EA: local_malloc (csi_provider_common.c:624) > ==9721== by 0xBC1747F: default_malloc_ex (mem.c:79) > ==9721== by 0xBC17BA6: CRYPTO_malloc (mem.c:350) > ==9721== by 0xBC2648F: bn_expand_internal (bn_lib.c:303) > ==9721== by 0xBC266AA: bn_expand2 (bn_lib.c:431) > ==9721== by 0xBC26FF6: BN_set_bit (bn_lib.c:736) > ==9721== by 0xBCE0880: BN_MONT_CTX_set (bn_mont.c:494) > ==9721== by 0xBCE0A2F: BN_MONT_CTX_set_locked (bn_mont.c:544) > ==9721== by 0xBCED0C0: RSA_eay_mod_exp (rsa_eay.c:763) > ==9721== by 0xBCEC747: RSA_eay_private_decrypt (rsa_eay.c:554) > ==9721== by 0xBC3B7DE: RSA_private_decrypt (rsa_crpt.c:111) Is this the "bottom" of the OpenSSL stack? i.e. your application calls RSA_private_decrypt() directly? Do you share a single RSA object across multiple threads? Matt From rsalz at akamai.com Tue Nov 7 12:05:46 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 7 Nov 2017 12:05:46 +0000 Subject: [openssl-users] Help with making a SHA >1 certificate In-Reply-To: <063244cb-1640-3cc0-180e-0c1ec9eddfda@wisemo.com> References: <20e801d3574b$2b704ca0$8250e5e0$@mcn.org> <063244cb-1640-3cc0-180e-0c1ec9eddfda@wisemo.com> Message-ID: ? -days on req when generating a request does noting, and should perhaps produce a warning, since this option is only meaningful when used with the -x509 option to produce a self-signed cert instead of a request. https://github.com/openssl/openssl/pull/4692 From rsalz at akamai.com Tue Nov 7 12:19:46 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 7 Nov 2017 12:19:46 +0000 Subject: [openssl-users] Potential memory leak in RSA_private_decrypt In-Reply-To: <1510048874324-0.post@n7.nabble.com> References: <1509948826636-0.post@n7.nabble.com> <1510048874324-0.post@n7.nabble.com> Message-ID: <7CC31D8C-DD7F-4624-826A-83C29E7AD5B7@akamai.com> There is something strange with the RSA private key or it?s BN_CONT object. Are you sure that you are properly releasing all OpenSSL objecdts in your code? From charlesm at mcn.org Tue Nov 7 14:37:48 2017 From: charlesm at mcn.org (Charles Mills) Date: Tue, 7 Nov 2017 06:37:48 -0800 Subject: [openssl-users] Help with making a SHA >1 certificate In-Reply-To: References: <20e801d3574b$2b704ca0$8250e5e0$@mcn.org> Message-ID: <225601d357d5$fbe86b80$f3b94280$@mcn.org> The CA?s certificate validity is Not After : Nov 18 17:39:38 2024 GMT Charles From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of warron.french Sent: Monday, November 6, 2017 4:02 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Help with making a SHA >1 certificate Charles, I am no expert either - sorry. However, the question about why is your signed certificate at least not getting to be over 1 year in "length?" What is the duration of the CA's certificate? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at rustichelli.net Tue Nov 7 18:10:43 2017 From: lists at rustichelli.net (lists) Date: Tue, 7 Nov 2017 19:10:43 +0100 Subject: [openssl-users] cms utility "-sign" doesn't include signed content In-Reply-To: References: Message-ID: On 10/20/2017 10:00 PM, Chris Marget wrote: > 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: > I think you want to add the option? "-nodetach" > 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 dfreed at epic.com Wed Nov 8 00:13:58 2017 From: dfreed at epic.com (Dan Freed) Date: Wed, 8 Nov 2017 00:13:58 +0000 Subject: [openssl-users] Help compiling on HPUX Message-ID: <4D4C39A5A374AB5C.041D5BA8-4110-462F-B5A1-47403756C9A1@mail.outlook.com> I see that there are a few posts about compiling openssl on HP-UX, so I?m hopeful that someone can help me out. I?m having issues getting things to completely finish the compilation process. There is an issue that some folks on Git-hub helped me resolve that was caused by some incompatibilities with HP?s make utility, but I have that resolved now (https://github.com/openssl/openssl/issues/4689). Now I'm seeing an issue with what I think is the final link step that I cannot find a solution to, and those people on Git-Hub were unable to help with. The issue changed - and of course I cannot figure out why, but the current scenario is below. Any help would be much appreciated. I'm using all HP utilities, which mean their make and the aCC compiler to build the package. I'm configuring with: HP-UX : B.11.31 ia64 CFLAGS=+DD64 LDOPTS=+b /usr/local/epic/Epic2018/lib -L/usr/local/epic/Epic2018/lib PERL=/usr/local/epic/Epic2018/bin/perl ./config no-ssl3 no-zlib no-zlib-dynamic --prefix=/usr/local/epic/Epic2018/ --libdir=lib -D_FORTIFY_SOURCE=2 Make errors out with the following (this is just the last bits of the output): cc -I. -Iinclude -Iapps -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2 -D_REENTRANT -DOPENSSLDIR="\"/usr/local/epic/Epic2018/ssl\"" -DENGINESDIR="\"/usr/local/epic/Epic2018/lib/engines-1.1\"" -Ae +DD64 +Olit=all -z -DB_ENDIAN +O3 -D_REENTRANT -c -o apps/x509.o apps/x509.c rm -f apps/openssl make -f ./Makefile.shared -e \ PERL="/usr/local/epic/Epic2018/bin/perl" SRCDIR=. \ APPNAME=apps/openssl OBJECTS="apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o" \ LIBDEPS=' '" -L. -lssl -L. -lcrypto"' -ldl -lpthread ' \ CC='cc' CFLAGS='-DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2 -D_REENTRANT -DOPENSSLDIR="\"/usr/local/epic/Epic2018/ssl\"" -DENGINESDIR="\"/usr/local/epic/Epic2018/lib/engines-1.1\"" -Ae +DD64 +Olit=all -z -DB_ENDIAN +O3 -D_REENTRANT ' \ LDFLAGS='' \ link_app.hpux-shared LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -D_FORTIFY _SOURCE=2 -D_REENTRANT -DOPENSSLDIR="/usr/local/epic/Epic2018/ssl" -DENGINESDIR="/usr/local/epic/Epic2018/lib/engines-1.1" -Ae +DD64 +Olit=all -z -DB_ENDIAN +O3 -D_REENTRANT -Wl,+s,+cdp,../:,+cdp,./: -o apps/openssl apps/app_ran d.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o app s/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps /rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o -L. -lssl -L. -lc rypto -ldl -lpthread ld: (Warning) Unsatisfied symbol "bn_mul_comba4" in file ./libcrypto.so.1.1 ld: (Warning) Unsatisfied symbol "bn_mul_comba8" in file ./libcrypto.so.1.1 ld: (Warning) Unsatisfied symbol "bn_sqr_comba4" in file ./libcrypto.so.1.1 ld: (Warning) Unsatisfied symbol "bn_sqr_comba8" in file ./libcrypto.so.1.1 ld: (Warning) Unsatisfied symbol "OPENSSL_cpuid_setup" in file ./libcrypto.so.1.1 ld: (Warning) Unsatisfied symbol "bn_sub_words" in file ./libcrypto.so.1.1 ld: (Warning) Unsatisfied symbol "bn_sqr_words" in file ./libcrypto.so.1.1 ld: (Warning) Unsatisfied symbol "bn_mul_words" in file ./libcrypto.so.1.1 ld: (Warning) Unsatisfied symbol "bn_add_words" in file ./libcrypto.so.1.1 ld: (Warning) Unsatisfied symbol "bn_div_words" in file ./libcrypto.so.1.1 ld: (Warning) Unsatisfied symbol "CRYPTO_memcmp" in file ./libssl.so ld: (Warning) Unsatisfied symbol "bn_mul_add_words" in file ./libcrypto.so.1.1 ld: (Warning) Unsatisfied symbol "AES_decrypt" in file ./libcrypto.so.1.1 ld: Unsatisfied symbol "AES_encrypt" in file apps/speed.o ld: Unsatisfied symbol "OPENSSL_cleanse" in file apps/apps.o 13 warnings. 2 errors. *** Error exit code 1 Stop. *** Error exit code 1 Stop. *** Error exit code 1 Stop. Get Outlook for iOS -------------- next part -------------- An HTML attachment was scrubbed... URL: From warron.french at gmail.com Wed Nov 8 02:48:07 2017 From: warron.french at gmail.com (warron.french) Date: Tue, 7 Nov 2017 21:48:07 -0500 Subject: [openssl-users] Help with making a SHA >1 certificate In-Reply-To: <225601d357d5$fbe86b80$f3b94280$@mcn.org> References: <20e801d3574b$2b704ca0$8250e5e0$@mcn.org> <225601d357d5$fbe86b80$f3b94280$@mcn.org> Message-ID: Charles, thanks for clarifying. I was on the correct track, but for some reason couldn't confirm it. (I chalk it up to being tired. That's my story and I'm sticking to it. lol). -------------------------- Warron French On Tue, Nov 7, 2017 at 9:37 AM, Charles Mills wrote: > The CA?s certificate validity is > > > > Not After : Nov 18 17:39:38 2024 GMT > > > > *Charles* > > > > *From:* openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *warron.french > *Sent:* Monday, November 6, 2017 4:02 PM > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] Help with making a SHA >1 certificate > > > > Charles, I am no expert either - sorry. > > > > However, the question about why is your signed certificate at least not > getting to be over 1 year in "length?" What is the duration of the CA's > certificate? > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangqun at alumni.nus.edu.sg Wed Nov 8 09:47:39 2017 From: wangqun at alumni.nus.edu.sg (Wang) Date: Wed, 8 Nov 2017 02:47:39 -0700 (MST) Subject: [openssl-users] Potential memory leak in RSA_private_decrypt In-Reply-To: <99883d51-5a38-e99a-f6ee-30faf8e17033@openssl.org> References: <1509948826636-0.post@n7.nabble.com> <1510048874324-0.post@n7.nabble.com> <99883d51-5a38-e99a-f6ee-30faf8e17033@openssl.org> Message-ID: <1510134459165-0.post@n7.nabble.com> Hello Matt, Thank you for trying to help. >>>Is this the "bottom" of the OpenSSL stack? i.e. your application calls >>>RSA_private_decrypt() directly? Yes, it does. >>>Do you share a single RSA object across multiple threads? Yes, my application shares a single RSA object across many concurrent threads. Namely RSA_private_decrypt() is called with the same RSA object concurrently across many threads. Does this cause any issue? I checked OpenSSL document, but didn't find anything related to this kind of restriction (https://www.openssl.org/docs/manmaster/man3/RSA_public_encrypt.html). Or this restriction is undocumented? Regards, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From matt at openssl.org Wed Nov 8 10:00:56 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Nov 2017 10:00:56 +0000 Subject: [openssl-users] Potential memory leak in RSA_private_decrypt In-Reply-To: <1510134459165-0.post@n7.nabble.com> References: <1509948826636-0.post@n7.nabble.com> <1510048874324-0.post@n7.nabble.com> <99883d51-5a38-e99a-f6ee-30faf8e17033@openssl.org> <1510134459165-0.post@n7.nabble.com> Message-ID: On 08/11/17 09:47, Wang wrote: > Hello Matt, > > Thank you for trying to help. > >>>> Is this the "bottom" of the OpenSSL stack? i.e. your application calls >>>> RSA_private_decrypt() directly? > Yes, it does. > >>>> Do you share a single RSA object across multiple threads? > Yes, my application shares a single RSA object across many concurrent > threads. Namely RSA_private_decrypt() is called with the same RSA object > concurrently across many threads. > > Does this cause any issue? I checked OpenSSL document, but didn't find > anything related to this kind of restriction > (https://www.openssl.org/docs/manmaster/man3/RSA_public_encrypt.html). Or > this restriction is undocumented? https://www.openssl.org/docs/faq.html#PROG1 >From the FAQ: "1. Is OpenSSL thread-safe? Yes but with some limitations; for example, an SSL connection cannot be used concurrently by multiple threads. This is true for most OpenSSL objects. ..." This is also true for the RSA object. Temporary, thread specific blinding state is held in the RSA object so it cannot be shared across multiple threads. Matt From wangqun at alumni.nus.edu.sg Wed Nov 8 10:09:18 2017 From: wangqun at alumni.nus.edu.sg (Wang) Date: Wed, 8 Nov 2017 03:09:18 -0700 (MST) Subject: [openssl-users] Potential memory leak in RSA_private_decrypt In-Reply-To: <7CC31D8C-DD7F-4624-826A-83C29E7AD5B7@akamai.com> References: <1509948826636-0.post@n7.nabble.com> <1510048874324-0.post@n7.nabble.com> <7CC31D8C-DD7F-4624-826A-83C29E7AD5B7@akamai.com> Message-ID: <1510135758393-0.post@n7.nabble.com> Thanks again, Rich. >>>There is something strange with the RSA private key or it?s BN_CONT object. >>>Are you sure that you are properly releasing all OpenSSL objecdts in your code? My application is a server. When it is initialized it calls RSA_new() to allocate a RSA object. When the server is running, it keeps accepting concurrent connection requests from many clients. When handling a connection request it calls RSA_private_decrypt() to decrypt the encrypted password. What a client does is to connect to the server and then disconnect at once. Hence it takes very little time for each client. The RSA object is not released until the server is shutdown. Regards, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From Michael.Wojcik at microfocus.com Wed Nov 8 13:03:02 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 8 Nov 2017 13:03:02 +0000 Subject: [openssl-users] Help compiling on HPUX In-Reply-To: <4D4C39A5A374AB5C.041D5BA8-4110-462F-B5A1-47403756C9A1@mail.outlook.com> References: <4D4C39A5A374AB5C.041D5BA8-4110-462F-B5A1-47403756C9A1@mail.outlook.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dan Freed > Sent: Tuesday, November 07, 2017 19:14 > To: openssl-users at openssl.org > Subject: [openssl-users] Help compiling on HPUX > I see that there are a few posts about compiling openssl on HP-UX, so I?m hopeful that someone can help me out. My initial suspect is the assembly modules. I suggest configuring with no-asm, and if that works and you really want the assembly code for performance, then investigate further. Another possibility is optimization. We had issues building OpenSSL for HP-UX (PA-RISC and Itanium) with +O4, which is what Configure specifies for at least some HP-UX builds. We backed it off to +O1 (by editing Configure; we actually use our own Configure script, and merge in changes from the official one each time we update to a new OpenSSL release). -- Michael Wojcik Distinguished Engineer, Micro Focus From ludwig.mark at siemens.com Wed Nov 8 13:27:30 2017 From: ludwig.mark at siemens.com (Ludwig, Mark) Date: Wed, 8 Nov 2017 13:27:30 +0000 Subject: [openssl-users] Help compiling on HPUX In-Reply-To: References: <4D4C39A5A374AB5C.041D5BA8-4110-462F-B5A1-47403756C9A1@mail.outlook.com> Message-ID: > From: Michael Wojcik, Wednesday, November 08, 2017 7:03 AM > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Help compiling on HPUX > > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Dan Freed > > Sent: Tuesday, November 07, 2017 19:14 > > To: openssl-users at openssl.org > > Subject: [openssl-users] Help compiling on HPUX > > > I see that there are a few posts about compiling openssl on HP-UX, so I?m > hopeful that someone can help me out. > > My initial suspect is the assembly modules. I suggest configuring with no-asm, > and if that works and you really want the assembly code for performance, then > investigate further. > > Another possibility is optimization. We had issues building OpenSSL for HP-UX > (PA-RISC and Itanium) with +O4, which is what Configure specifies for at least > some HP-UX builds. We backed it off to +O1 (by editing Configure; we actually > use our own Configure script, and merge in changes from the official one each > time we update to a new OpenSSL release). Dan, you did not specify the platform. I have not built on RISC since OpenSSL 0.9.8. I have built OpenSSL 1.0.2k on Itanium as follows. I mostly agree with Michael, but have not backed off optimization quite as far. Note that my use cases do not include encrypting/decrypting large payloads, so can get away with reduced performance to get correct results (i.e., pass the tests). I had to edit util/selftest.pl for the compiler's identification output and because the ar(1) command will not accept /dev/null as an input file. I also eliminated a lot of the tests in test/cms-tests, because we do not use the modules being tested. (They were failing.) I can believe these might work with lower optimization such as Michael recommends. Below is the Configure output. Hope this helps. Configuring for hpux64-ia64-cc no-asm [option] OPENSSL_NO_ASM no-dso [option] no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =cc CFLAG =+Z -DOPENSSL_PIC -DOPENSSL_THREADS -Ae +DD64 +O3 +Olit=all -z -DB_ENDIAN -D_REENTRANT EX_LIBS =-ldl CPUID_OBJ =mem_clr.o BN_ASM =bn_asm.o EC_ASM = DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_core.o aes_cbc.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o rc4_skey.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM = SHA1_OBJ_ASM = RMD160_OBJ_ASM= CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o MODES_OBJ = ENGINES_OBJ = PROCESSOR = RANLIB =/usr/ccs/bin/ranlib ARFLAGS = PERL =/usr/local/smd/bin/perl SIXTY_FOUR_BIT_LONG mode DES_RISC1 used DES_UNROLL used DES_INT used RC4_INDEX mode RC4_CHUNK is undefined MD2 uses uchar > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From dfreed at epic.com Wed Nov 8 15:43:52 2017 From: dfreed at epic.com (Dan Freed) Date: Wed, 8 Nov 2017 15:43:52 +0000 Subject: [openssl-users] Help compiling on HPUX Message-ID: Thanks! I am compiling on Itanium (ia64). I've not had these issues compiling OpenSSL 1.0.1 version, but this is the first time I'm attempting to move to the 1.1.0 version. I'm attempting a no-asm compile right now, to see if I can get past the error. Then I'll play the optimizations to see if I can get it to compile with the assembly optimizations or not. -Dan ?On 11/8/17, 7:33 AM, "openssl-users on behalf of Ludwig, Mark" wrote: > From: Michael Wojcik, Wednesday, November 08, 2017 7:03 AM > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Help compiling on HPUX > > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Dan Freed > > Sent: Tuesday, November 07, 2017 19:14 > > To: openssl-users at openssl.org > > Subject: [openssl-users] Help compiling on HPUX > > > I see that there are a few posts about compiling openssl on HP-UX, so I?m > hopeful that someone can help me out. > > My initial suspect is the assembly modules. I suggest configuring with no-asm, > and if that works and you really want the assembly code for performance, then > investigate further. > > Another possibility is optimization. We had issues building OpenSSL for HP-UX > (PA-RISC and Itanium) with +O4, which is what Configure specifies for at least > some HP-UX builds. We backed it off to +O1 (by editing Configure; we actually > use our own Configure script, and merge in changes from the official one each > time we update to a new OpenSSL release). Dan, you did not specify the platform. I have not built on RISC since OpenSSL 0.9.8. I have built OpenSSL 1.0.2k on Itanium as follows. I mostly agree with Michael, but have not backed off optimization quite as far. Note that my use cases do not include encrypting/decrypting large payloads, so can get away with reduced performance to get correct results (i.e., pass the tests). I had to edit util/selftest.pl for the compiler's identification output and because the ar(1) command will not accept /dev/null as an input file. I also eliminated a lot of the tests in test/cms-tests, because we do not use the modules being tested. (They were failing.) I can believe these might work with lower optimization such as Michael recommends. Below is the Configure output. Hope this helps. Configuring for hpux64-ia64-cc no-asm [option] OPENSSL_NO_ASM no-dso [option] no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =cc CFLAG =+Z -DOPENSSL_PIC -DOPENSSL_THREADS -Ae +DD64 +O3 +Olit=all -z -DB_ENDIAN -D_REENTRANT EX_LIBS =-ldl CPUID_OBJ =mem_clr.o BN_ASM =bn_asm.o EC_ASM = DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_core.o aes_cbc.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o rc4_skey.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM = SHA1_OBJ_ASM = RMD160_OBJ_ASM= CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o MODES_OBJ = ENGINES_OBJ = PROCESSOR = RANLIB =/usr/ccs/bin/ranlib ARFLAGS = PERL =/usr/local/smd/bin/perl SIXTY_FOUR_BIT_LONG mode DES_RISC1 used DES_UNROLL used DES_INT used RC4_INDEX mode RC4_CHUNK is undefined MD2 uses uchar > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -- > 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 dfreed at epic.com Wed Nov 8 17:07:22 2017 From: dfreed at epic.com (Dan Freed) Date: Wed, 8 Nov 2017 17:07:22 +0000 Subject: [openssl-users] Help compiling on HPUX Message-ID: <2150B376-B68B-4F49-9A3F-7AC758D769B5@epic.com> I can confirm that I can compile with no-asm. That?s a good thing. I cannot however get any level of optimizations to compile correctly. This may not be a problem for my use case, but it may be for others. If I update Configurations/10-main.conf for hpux64-ia64-cc to use +O0, +O1, or +O2 (+O3 was the default) it will trigger the issue. "hpux64-ia64-cc" => { inherit_from => [ "BASE_unix", asm("ia64_asm") ], cc => "cc", cflags => combine(picker(default => "-Ae +DD64 +Olit=all -z -DB_ENDIAN", debug => "+O0 +d -g", release => "+O0"), #### I changed the value here! This is also shown in the CFLAGS in the summary output from Configure: Configuring for hpux64-ia64-cc CC =cc CFLAG =-Ae +DD64 +Olit=all -z -DB_ENDIAN +O0 -D_REENTRANT While I can proceed with my project using no-asm, I am willing to try other changes to help the OpenSSL project out to see if the problem is just around one function that cannot be optimized, etc if anyone has any suggestions. I'm not sure if the git-hub bug moderators are on this list, so I'll update the bug report there with this new info. -Dan ?On 11/8/17, 7:33 AM, "openssl-users on behalf of Ludwig, Mark" wrote: > From: Michael Wojcik, Wednesday, November 08, 2017 7:03 AM > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Help compiling on HPUX > > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Dan Freed > > Sent: Tuesday, November 07, 2017 19:14 > > To: openssl-users at openssl.org > > Subject: [openssl-users] Help compiling on HPUX > > > I see that there are a few posts about compiling openssl on HP-UX, so I?m > hopeful that someone can help me out. > > My initial suspect is the assembly modules. I suggest configuring with no-asm, > and if that works and you really want the assembly code for performance, then > investigate further. > > Another possibility is optimization. We had issues building OpenSSL for HP-UX > (PA-RISC and Itanium) with +O4, which is what Configure specifies for at least > some HP-UX builds. We backed it off to +O1 (by editing Configure; we actually > use our own Configure script, and merge in changes from the official one each > time we update to a new OpenSSL release). Dan, you did not specify the platform. I have not built on RISC since OpenSSL 0.9.8. I have built OpenSSL 1.0.2k on Itanium as follows. I mostly agree with Michael, but have not backed off optimization quite as far. Note that my use cases do not include encrypting/decrypting large payloads, so can get away with reduced performance to get correct results (i.e., pass the tests). I had to edit util/selftest.pl for the compiler's identification output and because the ar(1) command will not accept /dev/null as an input file. I also eliminated a lot of the tests in test/cms-tests, because we do not use the modules being tested. (They were failing.) I can believe these might work with lower optimization such as Michael recommends. Below is the Configure output. Hope this helps. Configuring for hpux64-ia64-cc no-asm [option] OPENSSL_NO_ASM no-dso [option] no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =cc CFLAG =+Z -DOPENSSL_PIC -DOPENSSL_THREADS -Ae +DD64 +O3 +Olit=all -z -DB_ENDIAN -D_REENTRANT EX_LIBS =-ldl CPUID_OBJ =mem_clr.o BN_ASM =bn_asm.o EC_ASM = DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_core.o aes_cbc.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o rc4_skey.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM = SHA1_OBJ_ASM = RMD160_OBJ_ASM= CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o MODES_OBJ = ENGINES_OBJ = PROCESSOR = RANLIB =/usr/ccs/bin/ranlib ARFLAGS = PERL =/usr/local/smd/bin/perl SIXTY_FOUR_BIT_LONG mode DES_RISC1 used DES_UNROLL used DES_INT used RC4_INDEX mode RC4_CHUNK is undefined MD2 uses uchar > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -- > 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 minfrin at sharp.fm Thu Nov 9 01:11:07 2017 From: minfrin at sharp.fm (Graham Leggett) Date: Thu, 9 Nov 2017 03:11:07 +0200 Subject: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: Message-ID: Hi all, I am having quite a time trying to get postgresql v9.5 to talk over SSL on Ubuntu Xenial, running openssl v1.0.1f. Previously my setup was Ubuntu Trusty, and this works fine. The questions I have based on the info below: - It is the openssl s_client side that is triggering the handshake failure. Is there a way to get openssl to log why the handshake failed in the returned error message? Verification depth issue? No path to requested target? Something else? - What is the significance of "no peer certificate available?? A tcpdump and the ssldump shows that three certificates are sent by the postgresql server, why would openssl claim no certificates were sent? - The same certificates work fine in Ubuntu Trusty, they don?t work in Ubuntu Xenial. The certs are SHA256 certs, and consist of a root, two intermediates and a leaf cert. The postgresql server provides the two intermediates and the leaf cert, and the root as passed in -CAfile. - Are there any known incompatibility issues with openssl on Xenial? When I attempt to connect to postgresql using openssl s_client, I get this: postgres at sql02:~$ openssl s_client -verify 10 -CAfile .postgresql/root.crt -key .postgresql/postgresql.key -cert .postgresql/postgresql.crt -connect sql01:5432 -servername sql01 verify depth is 10 CONNECTED(00000003) 139930468939416:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 379 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1510188432 Timeout : 300 (sec) Verify return code: 0 (ok) ? ssldump confirms that it is the client side - that?s openssl - that?s rejecting the handshake and returning unknown ca: New TCP connection #42: 172.29.231.43(33116) <-> 172.29.228.240(5432) 42 1 0.0038 (0.0038) C>SV3.1(300) Handshake ClientHello Version 3.3 random[32]= 80 cf 99 66 b3 07 55 c2 3f cf b2 61 13 39 89 c1 33 37 f4 77 21 a3 fd 2e f9 fa 9b 65 4e b5 bd 24 cipher suites Unknown value 0xc030 Unknown value 0xc02c Unknown value 0xc028 Unknown value 0xc024 Unknown value 0xc014 Unknown value 0xc00a Unknown value 0xa5 Unknown value 0xa3 Unknown value 0xa1 Unknown value 0x9f Unknown value 0x6b Unknown value 0x6a Unknown value 0x69 Unknown value 0x68 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA Unknown value 0x88 Unknown value 0x87 Unknown value 0x86 Unknown value 0x85 Unknown value 0xc032 Unknown value 0xc02e Unknown value 0xc02a Unknown value 0xc026 Unknown value 0xc00f Unknown value 0xc005 Unknown value 0x9d Unknown value 0x3d TLS_RSA_WITH_AES_256_CBC_SHA Unknown value 0x84 Unknown value 0xc02f Unknown value 0xc02b Unknown value 0xc027 Unknown value 0xc023 Unknown value 0xc013 Unknown value 0xc009 Unknown value 0xa4 Unknown value 0xa2 Unknown value 0xa0 Unknown value 0x9e TLS_DHE_DSS_WITH_NULL_SHA Unknown value 0x40 Unknown value 0x3f Unknown value 0x3e TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA Unknown value 0x9a Unknown value 0x99 Unknown value 0x98 Unknown value 0x97 Unknown value 0x45 Unknown value 0x44 Unknown value 0x43 Unknown value 0x42 Unknown value 0xc031 Unknown value 0xc02d Unknown value 0xc029 Unknown value 0xc025 Unknown value 0xc00e Unknown value 0xc004 Unknown value 0x9c Unknown value 0x3c TLS_RSA_WITH_AES_128_CBC_SHA Unknown value 0x96 Unknown value 0x41 Unknown value 0xc011 Unknown value 0xc007 Unknown value 0xc00c Unknown value 0xc002 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 Unknown value 0xc012 Unknown value 0xc008 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xc00d Unknown value 0xc003 TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0xff compression methods NULL 42 2 0.0056 (0.0017) S>CV3.3(62) Handshake ServerHello Version 3.3 random[32]= f9 4d fa 63 ee d5 65 6d ba dd 58 de 51 00 8e ac 9f 45 24 43 e2 17 88 07 41 9a 8d aa 7f 95 2a 13 session_id[0]= cipherSuite Unknown value 0xc030 compressionMethod NULL 42 3 0.0056 (0.0000) S>CV3.3(3345) Handshake Certificate certificate[1329]=[snip] certificate[1010]=[snip] certificate[990]=[snip] 42 4 0.0056 (0.0000) S>CV3.3(333) Handshake ServerKeyExchange 42 5 0.0056 (0.0000) S>CV3.3(179) Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_types unknown value Not enough data. Found 163 bytes (expecting 32767) ServerHelloDone 42 6 0.0061 (0.0004) C>SV3.3(2) Alert level fatal value unknown_ca 42 0.0062 (0.0001) C>S TCP RST Regards, Graham ? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3240 bytes Desc: not available URL: From Michael.Wojcik at microfocus.com Thu Nov 9 02:17:30 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 9 Nov 2017 02:17:30 +0000 Subject: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Graham Leggett > Sent: Wednesday, November 08, 2017 20:11 > To: openssl-users at openssl.org > Subject: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL > routines:ssl23_write:ssl handshake failure:s23_lib.c:177: > > - What is the significance of "no peer certificate available?? You can get this message from s_client even if the handshake failed for other reasons. I've seen it when there are no common cipher suites, for example. One case I recently observed: A stock OpenSSL 1.0.2j s_client talking to an older IIS. IIS negotiated TLSv1.2 but didn't actually support any of the TLSv1.2 suites. s_client reported the negotiated suite was 0 (i.e. none), but it also gave me the "no peer certificate" diagnostic. (In this case, forcing TLSv1.1 got the connection working, and since this was for an internal demo I didn't bother beating IIS into submission.) > New, (NONE), Cipher is (NONE) > SSL-Session: > Protocol : TLSv1.2 > Cipher : 0000 Yeah. TLSv1.2, no cipher. My guess is the server is allowing the 1.2 protocol level but not supporting any of the 1.2 suites. > ssldump confirms that it is the client side - that?s openssl - that?s rejecting the > handshake and returning unknown ca: > > New TCP connection #42: 172.29.231.43(33116) <-> 172.29.228.240(5432) > 42 1 0.0038 (0.0038) C>SV3.1(300) Handshake > ClientHello > Version 3.3 > random[32]= > 80 cf 99 66 b3 07 55 c2 3f cf b2 61 13 39 89 c1 > 33 37 f4 77 21 a3 fd 2e f9 fa 9b 65 4e b5 bd 24 > cipher suites > Unknown value 0xc030 > Unknown value 0xc02c > Unknown value 0xc028 > Unknown value 0xc024 > Unknown value 0xc014 > Unknown value 0xc00a > Unknown value 0xa5 > Unknown value 0xa3 > Unknown value 0xa1 > Unknown value 0x9f > Unknown value 0x6b > Unknown value 0x6a > Unknown value 0x69 > Unknown value 0x68 > TLS_DHE_RSA_WITH_AES_256_CBC_SHA > TLS_DHE_DSS_WITH_AES_256_CBC_SHA > TLS_DH_RSA_WITH_AES_256_CBC_SHA > TLS_DH_DSS_WITH_AES_256_CBC_SHA > Unknown value 0x88 > Unknown value 0x87 > Unknown value 0x86 > Unknown value 0x85 > Unknown value 0xc032 > Unknown value 0xc02e > Unknown value 0xc02a > Unknown value 0xc026 > Unknown value 0xc00f > Unknown value 0xc005 > Unknown value 0x9d > Unknown value 0x3d > TLS_RSA_WITH_AES_256_CBC_SHA > Unknown value 0x84 > Unknown value 0xc02f > Unknown value 0xc02b > Unknown value 0xc027 > Unknown value 0xc023 > Unknown value 0xc013 > Unknown value 0xc009 > Unknown value 0xa4 > Unknown value 0xa2 > Unknown value 0xa0 > Unknown value 0x9e > TLS_DHE_DSS_WITH_NULL_SHA > Unknown value 0x40 > Unknown value 0x3f > Unknown value 0x3e > TLS_DHE_RSA_WITH_AES_128_CBC_SHA > TLS_DHE_DSS_WITH_AES_128_CBC_SHA > TLS_DH_RSA_WITH_AES_128_CBC_SHA > TLS_DH_DSS_WITH_AES_128_CBC_SHA > Unknown value 0x9a > Unknown value 0x99 > Unknown value 0x98 > Unknown value 0x97 > Unknown value 0x45 > Unknown value 0x44 > Unknown value 0x43 > Unknown value 0x42 > Unknown value 0xc031 > Unknown value 0xc02d > Unknown value 0xc029 > Unknown value 0xc025 > Unknown value 0xc00e > Unknown value 0xc004 > Unknown value 0x9c > Unknown value 0x3c > TLS_RSA_WITH_AES_128_CBC_SHA > Unknown value 0x96 > Unknown value 0x41 > Unknown value 0xc011 > Unknown value 0xc007 > Unknown value 0xc00c > Unknown value 0xc002 > TLS_RSA_WITH_RC4_128_SHA > TLS_RSA_WITH_RC4_128_MD5 > Unknown value 0xc012 > Unknown value 0xc008 > TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA > TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA > TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA > TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA > Unknown value 0xc00d > Unknown value 0xc003 > TLS_RSA_WITH_3DES_EDE_CBC_SHA > Unknown value 0xff > compression methods > NULL > 42 2 0.0056 (0.0017) S>CV3.3(62) Handshake > ServerHello > Version 3.3 > random[32]= > f9 4d fa 63 ee d5 65 6d ba dd 58 de 51 00 8e ac > 9f 45 24 43 e2 17 88 07 41 9a 8d aa 7f 95 2a 13 > session_id[0]= > > cipherSuite Unknown value 0xc030 Hmm. This claims they agreed on TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. Maybe no ECC curves in common for ECDHE Kx? > compressionMethod NULL > 42 3 0.0056 (0.0000) S>CV3.3(3345) Handshake > Certificate > certificate[1329]=[snip] > certificate[1010]=[snip] > certificate[990]=[snip] > 42 4 0.0056 (0.0000) S>CV3.3(333) Handshake > ServerKeyExchange > 42 5 0.0056 (0.0000) S>CV3.3(179) Handshake > CertificateRequest > certificate_types rsa_sign > certificate_types dss_sign > certificate_types unknown value > Not enough data. Found 163 bytes (expecting 32767) > ServerHelloDone Not seeing any curve agreement there. There should be a ServerKeyExchange before the ServerHelloDone, if memory serves. (Someone may correct me on this - it's been some time since I looked at the details of ECDHE key exchange.) > 42 6 0.0061 (0.0004) C>SV3.3(2) Alert > level fatal > value unknown_ca This looks to me like the wrong Alert value, but again maybe someone can correct me on that. Anyway, my suggestion is try setting a cipher list that doesn't include the ECC suites, to confirm that's the problem. -- Michael Wojcik Distinguished Engineer, Micro Focus From sanandchoubey at yahoo.com Thu Nov 9 05:55:45 2017 From: sanandchoubey at yahoo.com (Anand Choubey) Date: Thu, 9 Nov 2017 05:55:45 +0000 (UTC) Subject: [openssl-users] Openssl DTLS performance References: <841475598.5225358.1510206945630.ref@mail.yahoo.com> Message-ID: <841475598.5225358.1510206945630@mail.yahoo.com> Hi all, We are building VPN using OpenSSL 1.1.0e.? VPN can work with TLS and DTLS. The test server is Linux Ubuntu 16.04 and client windows 7/10.? We tested using dummy net with different parameters like? 0.1/0.2 /.5% packet drop and 20 ms delay. In this scenario,?DTLS shows marginal?5 to 7% poor performance than TLS under different network conditions. We are using async socket. epoll on linux?and select on the windows side.? Do we know any known performance limitation with DTLS in existing OpenSSL lib? Thanks in advanceAnand -------------- next part -------------- An HTML attachment was scrubbed... URL: From murugesh.pitchaiah at gmail.com Thu Nov 9 07:42:14 2017 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Thu, 9 Nov 2017 13:12:14 +0530 Subject: [openssl-users] FIPS 186-4 RSA CAVS Message-ID: Dear All, I am working on doing CAVS algorithm testing for RSA, FIPS 186-4. Able to make up the 186-4 patches for RSA key generation from Fedora, SuSe patches. The new API to generate RSA key based on 186-4 is "fips_rsa_builtin_keygen". But I suspect if this has CAVS support as well. In the fips_rsagtest, above API is not invoked at all. I see the fips_rsagtest invokes only the old "RSA_X931_derive_ex". Please share if any patch available for CAVS algorithm test support for RSA 186-4. Thanks, Murugesh P. From wangqun at alumni.nus.edu.sg Thu Nov 9 09:28:40 2017 From: wangqun at alumni.nus.edu.sg (Wang) Date: Thu, 9 Nov 2017 02:28:40 -0700 (MST) Subject: [openssl-users] Potential memory leak in RSA_private_decrypt In-Reply-To: References: <1509948826636-0.post@n7.nabble.com> <1510048874324-0.post@n7.nabble.com> <99883d51-5a38-e99a-f6ee-30faf8e17033@openssl.org> <1510134459165-0.post@n7.nabble.com> Message-ID: <1510219720735-0.post@n7.nabble.com> This is very important information. Thank you very much, Matt. I will update the code of my product and test if it resolves my issue. If it does, I will post my feedback here. Hence other users can aviod the same issue. My product is complex and I have other things to do, so it may take a few days. Regards, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From minfrin at sharp.fm Thu Nov 9 11:17:30 2017 From: minfrin at sharp.fm (Graham Leggett) Date: Thu, 9 Nov 2017 13:17:30 +0200 Subject: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: In-Reply-To: References: Message-ID: <619997BF-F179-434C-8372-6E8D009D4030@sharp.fm> On 09 Nov 2017, at 4:17 AM, Michael Wojcik wrote: >> New, (NONE), Cipher is (NONE) >> SSL-Session: >> Protocol : TLSv1.2 >> Cipher : 0000 > > Yeah. TLSv1.2, no cipher. My guess is the server is allowing the 1.2 protocol level but not supporting any of the 1.2 suites. Does this definitely mean no cipher, or could it mean ?I failed earlier in the process before I took note of the cipher, like with the no peer certificate available"? >> 42 2 0.0056 (0.0017) S>CV3.3(62) Handshake >> ServerHello >> Version 3.3 >> random[32]= >> f9 4d fa 63 ee d5 65 6d ba dd 58 de 51 00 8e ac >> 9f 45 24 43 e2 17 88 07 41 9a 8d aa 7f 95 2a 13 >> session_id[0]= >> >> cipherSuite Unknown value 0xc030 > > Hmm. This claims they agreed on TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. Maybe no ECC curves in common for ECDHE Kx? This is openssl v1.0.1f (ubuntu xenial) talking to openssl v1.0.1f (ubuntu xenial), although trying openssl as shipped by MacOS Sierra on the client side gives the same result. I set the ciphers explicitly on the server side to DEFAULT and got the same result (eliminating whatever weird settings postgresql-on-ubuntu might have as a default). Next step was to bring openssl up onto a debugger and see what openssl was doing internally. I created a debug build of v1.0.2m, and I now have different behaviour: When openssl v1.0.2m tries to connect to postgresql running openssl v1.0.1f (ubuntu xenial), I get different behaviour: New TCP connection #2: localhost(61009) <-> localhost(15432) 2 1 0.0002 (0.0002) C>S Handshake ClientHello Version 3.3 cipher suites Unknown value 0xc030 Unknown value 0xc02c Unknown value 0xc028 Unknown value 0xc024 Unknown value 0xc014 Unknown value 0xc00a Unknown value 0xa5 Unknown value 0xa3 Unknown value 0xa1 Unknown value 0x9f Unknown value 0x6b Unknown value 0x6a Unknown value 0x69 Unknown value 0x68 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA Unknown value 0x88 Unknown value 0x87 Unknown value 0x86 Unknown value 0x85 Unknown value 0xc032 Unknown value 0xc02e Unknown value 0xc02a Unknown value 0xc026 Unknown value 0xc00f Unknown value 0xc005 Unknown value 0x9d Unknown value 0x3d TLS_RSA_WITH_AES_256_CBC_SHA Unknown value 0x84 Unknown value 0xc02f Unknown value 0xc02b Unknown value 0xc027 Unknown value 0xc023 Unknown value 0xc013 Unknown value 0xc009 Unknown value 0xa4 Unknown value 0xa2 Unknown value 0xa0 Unknown value 0x9e TLS_DHE_DSS_WITH_NULL_SHA Unknown value 0x40 Unknown value 0x3f Unknown value 0x3e TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA Unknown value 0x9a Unknown value 0x99 Unknown value 0x98 Unknown value 0x97 Unknown value 0x45 Unknown value 0x44 Unknown value 0x43 Unknown value 0x42 Unknown value 0xc031 Unknown value 0xc02d Unknown value 0xc029 Unknown value 0xc025 Unknown value 0xc00e Unknown value 0xc004 Unknown value 0x9c Unknown value 0x3c TLS_RSA_WITH_AES_128_CBC_SHA Unknown value 0x96 Unknown value 0x41 TLS_RSA_WITH_IDEA_CBC_SHA Unknown value 0xc011 Unknown value 0xc007 Unknown value 0xc00c Unknown value 0xc002 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 Unknown value 0xc012 Unknown value 0xc008 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xc00d Unknown value 0xc003 TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0xff compression methods unknown value NULL 2 0.0151 (0.0148) S>C TCP FIN 2 0.0161 (0.0009) C>S TCP FIN The server side logs the following and slams the phone down: 2017-11-09 11:01:19 UTC [12025-1] [unknown]@[unknown] LOG: invalid length of startup packet The client side logs the following hint: SSL handshake has read 0 bytes and written 382 bytes Why would 382 bytes be an invalid length for an SSL startup packet? I did see old bug reports from around 2012 where Ubuntu shipped an openssl that broke on many sites, and there were references that buggy SSL implementations were limited to 255 bytes only. Was openssl ever such a buggy implementation? Regards, Graham ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3240 bytes Desc: not available URL: From Michael.Wojcik at microfocus.com Thu Nov 9 12:57:48 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 9 Nov 2017 12:57:48 +0000 Subject: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: In-Reply-To: <619997BF-F179-434C-8372-6E8D009D4030@sharp.fm> References: <619997BF-F179-434C-8372-6E8D009D4030@sharp.fm> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Graham Leggett > Sent: Thursday, November 09, 2017 06:18 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: > On 09 Nov 2017, at 4:17 AM, Michael Wojcik wrote: > > Yeah. TLSv1.2, no cipher. My guess is the server is allowing the 1.2 protocol level but not > > supporting any of the 1.2 suites. > Does this definitely mean no cipher, or could it mean ?I failed earlier in the process before > I took note of the cipher, like with the no peer certificate available"? Well, in this case it seems to mean "the server and I agreed on a cipher suite, but the server didn't do the thing it needed to do to make that suite usable". > > Hmm. This claims they agreed on TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. Maybe > > no ECC curves in common for ECDHE Kx? > This is openssl v1.0.1f (ubuntu xenial) talking to openssl v1.0.1f (ubuntu xenial), although > trying openssl as shipped by MacOS Sierra on the client side gives the same result. At least prior to 1.1.0, to use ECC in OpenSSL the application has to make some additional calls. (I don't remember offhand how much of this goes away in the 1.1.0 API.) So it's quite possible for two applications using stock OpenSSL 1.0.x to fail to use an ECC suite. > I set the ciphers explicitly on the server side to DEFAULT and got the same result (eliminating > whatever weird settings postgresql-on-ubuntu might have as a default). DEFAULT includes ECC suites. You should try something like DEFAULT:!ECDHE:!ECDH to eliminate the ECC Kx suites. > When openssl v1.0.2m tries to connect to postgresql running openssl v1.0.1f (ubuntu xenial), I get different behaviour: > ... > 2017-11-09 11:01:19 UTC [12025-1] [unknown]@[unknown] LOG:? invalid length of startup packet Offhand, I don't know what the problem is here. -- Michael Wojcik Distinguished Engineer, Micro Focus From minfrin at sharp.fm Thu Nov 9 13:30:19 2017 From: minfrin at sharp.fm (Graham Leggett) Date: Thu, 9 Nov 2017 15:30:19 +0200 Subject: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: In-Reply-To: References: <619997BF-F179-434C-8372-6E8D009D4030@sharp.fm> Message-ID: On 09 Nov 2017, at 2:57 PM, Michael Wojcik wrote: >> This is openssl v1.0.1f (ubuntu xenial) talking to openssl v1.0.1f (ubuntu xenial), although >> trying openssl as shipped by MacOS Sierra on the client side gives the same result. > > At least prior to 1.1.0, to use ECC in OpenSSL the application has to make some additional calls. (I don't remember offhand how much of this goes away in the 1.1.0 API.) So it's quite possible for two applications using stock OpenSSL 1.0.x to fail to use an ECC suite. > >> I set the ciphers explicitly on the server side to DEFAULT and got the same result (eliminating >> whatever weird settings postgresql-on-ubuntu might have as a default). > > DEFAULT includes ECC suites. You should try something like DEFAULT:!ECDHE:!ECDH to eliminate the ECC Kx suites. I just tried that - no change in behaviour, apart from the negotiation of a different cipher before the connection fails (0x9f). >> When openssl v1.0.2m tries to connect to postgresql running openssl v1.0.1f (ubuntu xenial), I get different behaviour: >> ... >> 2017-11-09 11:01:19 UTC [12025-1] [unknown]@[unknown] LOG: invalid length of startup packet > > Offhand, I don't know what the problem is here. Does or did openssl server have any known bugs with respect to the length of a ClientHello packet being in excess of 255 bytes? This is what a tcpdump looks like when psql linked to openssl v1.0.1f attempts to connect to postgresql linked to openssl v1.0.1f, the client side sends 8 bytes, then 1 byte, then 305 bytes in my case: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 11:51:45.113996 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [S], seq 3580373978, win 26883, options [mss 8961,sackOK,TS val 12226525 ecr 0,nop,wscale 7], length 0 11:51:45.114035 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [S.], seq 3310545722, ack 3580373979, win 26847, options [mss 8961,sackOK,TS val 12327573 ecr 12226525,nop,wscale 7], length 0 11:51:45.114243 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [.], ack 1, win 211, options [nop,nop,TS val 12226525 ecr 12327573], length 0 11:51:45.114271 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [P.], seq 1:9, ack 1, win 211, options [nop,nop,TS val 12226525 ecr 12327573], length 8 11:51:45.114277 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [.], ack 9, win 210, options [nop,nop,TS val 12327573 ecr 12226525], length 0 11:51:45.114934 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [P.], seq 1:2, ack 9, win 210, options [nop,nop,TS val 12327574 ecr 12226525], length 1 11:51:45.115132 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [.], ack 2, win 211, options [nop,nop,TS val 12226525 ecr 12327574], length 0 11:51:45.117703 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [P.], seq 9:314, ack 2, win 211, options [nop,nop,TS val 12226526 ecr 12327574], length 305 11:51:45.119459 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [P.], seq 2:3941, ack 314, win 219, options [nop,nop,TS val 12327575 ecr 12226526], length 3939 11:51:45.120234 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [P.], seq 314:321, ack 3941, win 350, options [nop,nop,TS val 12226526 ecr 12327575], length 7 11:51:45.120324 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [R.], seq 321, ack 3941, win 350, options [nop,nop,TS val 12226526 ecr 12327575], length 0 The openssl v1.0.1f server side responds with a ServerHello, however the client side rejects the ServerHello saying "unknown ca", even though this same set of certificates works fine in Ubuntu Trusty. In a second test, if I use openssl v1.0.2m compiled from source to connect to the same server, the client side sends 308 bytes in one go: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 11:53:02.032126 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [S], seq 1471313029, win 26883, options [mss 8961,sackOK,TS val 645036074 ecr 0,nop,wscale 7], length 0 11:53:02.032165 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [S.], seq 126514461, ack 1471313030, win 26847, options [mss 8961,sackOK,TS val 12346803 ecr 645036074,nop,wscale 7], length 0 11:53:02.032490 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [.], ack 1, win 211, options [nop,nop,TS val 645036074 ecr 12346803], length 0 11:53:02.039507 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [P.], seq 1:309, ack 1, win 211, options [nop,nop,TS val 645036076 ecr 12346803], length 308 11:53:02.039521 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [.], ack 309, win 219, options [nop,nop,TS val 12346805 ecr 645036076], length 0 11:53:02.040625 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [F.], seq 1, ack 309, win 219, options [nop,nop,TS val 12346805 ecr 645036076], length 0 11:53:02.041682 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [.], ack 2, win 211, options [nop,nop,TS val 645036077 ecr 12346805], length 0 11:53:02.049476 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [F.], seq 309, ack 2, win 211, options [nop,nop,TS val 645036078 ecr 12346805], length 0 11:53:02.049492 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [.], ack 310, win 219, options [nop,nop,TS val 12346807 ecr 645036078], length 0 In this case the postgresql linked to openssl v1.0.1f immediately slams the phone down after the initial ClientHello, leading to the "SSL handshake has read 0 bytes" in the openssl client side. In my case I have an SNI header with a long DNS name in it, and a very long list of ciphers on the client side that postgresql does not appear to give me control over. Is this is known problem, does it ring any bells? Regards, Graham ? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3240 bytes Desc: not available URL: From rsalz at akamai.com Thu Nov 9 13:48:22 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 Nov 2017 13:48:22 +0000 Subject: [openssl-users] FIPS 186-4 RSA CAVS In-Reply-To: References: Message-ID: <34DA6D4C-3B83-4053-BDE4-2C24243C947C@akamai.com> ? Please share if any patch available for CAVS algorithm test support for RSA 186-4. There is not. Unless someone in the community has one they are willing to share. From Michael.Wojcik at microfocus.com Thu Nov 9 16:05:31 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 9 Nov 2017 16:05:31 +0000 Subject: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: In-Reply-To: References: <619997BF-F179-434C-8372-6E8D009D4030@sharp.fm> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Graham Leggett > Sent: Thursday, November 09, 2017 08:30 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL > routines:ssl23_write:ssl handshake failure:s23_lib.c:177: > > On 09 Nov 2017, at 2:57 PM, Michael Wojcik > wrote: > > > DEFAULT includes ECC suites. You should try something like > > DEFAULT:!ECDHE:!ECDH to eliminate the ECC Kx suites. > > I just tried that - no change in behaviour, apart from the negotiation of a > different cipher before the connection fails (0x9f). OK. 9f is TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, so it's not an ECC issue after all. At least not with this client. It's not clear to me if you've gone back to the 1.0.1f client, or if you were still using 1.0.2m here. > Does or did openssl server have any known bugs with respect to the length > of a ClientHello packet being in excess of 255 bytes? Someone else will have to answer this. As far as I know, it was only the F5 TLS implementation that had this issue. -- Michael Wojcik Distinguished Engineer, Micro Focus From ariel.silverman at intel.com Thu Nov 9 20:17:18 2017 From: ariel.silverman at intel.com (Silverman, Ariel) Date: Thu, 9 Nov 2017 20:17:18 +0000 Subject: [openssl-users] Question regarding TLS renegotiation and configuration of Openssl ssl context Message-ID: <688584B194541D4BA885B3F50F14010793F39C42@ORSMSX116.amr.corp.intel.com> Dear Openssl Gurus, I am facing the following problem, I am required to create an SSL client that talks (TLSv1.2, TLSv1.1 and TLSv1.0) against 3 different types of servers, one talks TLSv1.2 only (server_12) , one TLSv1.1 only (server_11) and one TLSv1.0 only (server_10) The way I am configuring my tls context is as following Note: I am using Openssl v1.0.2l SSL_CTX *ctx; ctx = SSL_CTX_new( SSLv23_method() ) SSL_CTX_set_options(ctx,SSL_OP_NO_SSLv3 | SSL_OP_NO_TICKET); Now... When I try to connect to server_10 I see the trace below, the negotiation fails with: Alert Message Level: Fatal (2) Description: Protocol Version (70) It makes sense, since the decription for this failure is: 70 protocol_version The protocol version the client attempted to negotiate is recognized, but not supported. For example, old protocol versions might be avoided for security reasons. This message is always fatal. Now my question is: How do I configure my SSL_CTX options so that I can talk to server_10 whilst being able to connect to server_12 and server_11 and at the same time maintaining security and not becoming vulnerable to RFC7507 ( TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) Thank you in advance for your help!!! :) -Ariel Silverman Wireshark Trace of TLS negotiation: =================================== No. Time Source Destination Protocol Length Info 517 35.593453 192.168.0.70 192.168.0.102 TLSv1 249 Client Hello Frame 517: 249 bytes on wire (1992 bits), 249 bytes captured (1992 bits) on interface 0 Ethernet II, Src: Vmware_e4:ae:09 (00:0c:29:e4:ae:09), Dst: Dell_c0:9a:2e (b8:ca:3a:c0:9a:2e) Internet Protocol Version 4, Src: 192.168.0.70, Dst: 192.168.0.102 Transmission Control Protocol, Src Port: 63441, Dst Port: 16993, Seq: 1, Ack: 1, Len: 195 Secure Sockets Layer TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 190 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 186 Version: TLS 1.1 (0x0302) Random: cdf0b0cb59d22675e6f840363eed6481674ce6e8714eeb45... Session ID Length: 0 Cipher Suites Length: 100 Cipher Suites (50 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 45 Extension: ec_point_formats (len=4) Extension: supported_groups (len=28) Extension: heartbeat (len=1) No. Time Source Destination Protocol Length Info 519 35.595600 192.168.0.102 192.168.0.70 TLSv1 1063 Server Hello, Certificate, Certificate Request, Server Hello Done Frame 519: 1063 bytes on wire (8504 bits), 1063 bytes captured (8504 bits) on interface 0 Ethernet II, Src: Dell_c0:9a:2e (b8:ca:3a:c0:9a:2e), Dst: Vmware_e4:ae:09 (00:0c:29:e4:ae:09) Internet Protocol Version 4, Src: 192.168.0.102, Dst: 192.168.0.70 Transmission Control Protocol, Src Port: 16993, Dst Port: 63441, Seq: 1, Ack: 196, Len: 1009 Secure Sockets Layer TLSv1 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 46 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 42 Version: TLS 1.0 (0x0301) Random: a0cb439203175bf9bb313ad516e0722288bd8d2b0ceb14f6... Session ID Length: 4 Session ID: 79010000 Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Compression Method: null (0) TLSv1 Record Layer: Handshake Protocol: Certificate Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 931 Handshake Protocol: Certificate Handshake Type: Certificate (11) Length: 927 Certificates Length: 924 Certificates (924 bytes) TLSv1 Record Layer: Handshake Protocol: Certificate Request Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 8 Handshake Protocol: Certificate Request Handshake Type: Certificate Request (13) Length: 4 Certificate types count: 1 Certificate types (1 type) Distinguished Names Length: 0 TLSv1 Record Layer: Handshake Protocol: Server Hello Done Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 4 Handshake Protocol: Server Hello Done Handshake Type: Server Hello Done (14) Length: 0 No. Time Source Destination Protocol Length Info 520 35.595660 192.168.0.70 192.168.0.102 TLSv1 61 Alert (Level: Fatal, Description: Protocol Version) Frame 520: 61 bytes on wire (488 bits), 61 bytes captured (488 bits) on interface 0 Ethernet II, Src: Vmware_e4:ae:09 (00:0c:29:e4:ae:09), Dst: Dell_c0:9a:2e (b8:ca:3a:c0:9a:2e) Internet Protocol Version 4, Src: 192.168.0.70, Dst: 192.168.0.102 Transmission Control Protocol, Src Port: 63441, Dst Port: 16993, Seq: 196, Ack: 1010, Len: 7 Secure Sockets Layer TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version) Content Type: Alert (21) Version: TLS 1.0 (0x0301) Length: 2 Alert Message Level: Fatal (2) Description: Protocol Version (70) -------------- next part -------------- An HTML attachment was scrubbed... URL: From smadwin at adobe.com Thu Nov 9 21:43:21 2017 From: smadwin at adobe.com (Steven Madwin) Date: Thu, 9 Nov 2017 21:43:21 +0000 Subject: [openssl-users] OCSP Server -port Message-ID: Hi All, Once upon a time in the 0.98 timeframe, when I first configured OpenSSL as a test OCSP server, using the format -port 8888 worked. This format however stopped working when version 1.0 was released. After living inside Google like Jeff Bridges in Tron, it came to light that the format needed to be -port 0.0.0.0:8888 at which point the OCSP server was resurrected. Now with version 1.1 uses the v1.0 format it returns the message: ocsp: Can't parse "0.0.0.0:8888" as an octal number ocsp: Non-positive number "0.0.0.0:8888" for -port ocsp: Use -help for summary. error in ocsp Falling back to the v0.98 format, that is going back to -port 8888, allows the server to start, and the message "Waiting for OCSP client connections..." is displayed. The problem is, the client can't make the connection and the OCSP process times out. This all leads up to the question, has anyone been able to get version 1.1 to act as an OCSP server using the -port option? 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 pschmehl at tx.rr.com Fri Nov 10 01:09:05 2017 From: pschmehl at tx.rr.com (Paul Schmehl) Date: Thu, 09 Nov 2017 19:09:05 -0600 Subject: [openssl-users] Strange problem with openssl Message-ID: I'm running FreeBSD 10.3-RELEASE with # openssl version OpenSSL 1.0.1s-freebsd 1 Mar 2016 This is the FreeBSD base version of openssl, not the ports version. I have ssh access to the server and can sudo to root. Please note: In the error messages below, I have removed some of the pathing so as not to reveal the exact locations on the server. I have two problems. When I use https with an rss reader module in Joomla, I get this error: Warning: fopen(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed in /Sites/www.vvfh.org/libraries/joomla/filesystem/file.php on line 335 Warning: fopen(): Failed to enable crypto in /Sites/www.vvfh.org/libraries/joomla/filesystem/file.php on line 335 Warning: fopen(https://blog.vvfh.org/feed/rss2): failed to open stream: operation failed in /Sites/www.vvfh.org/libraries/joomla/filesystem/file.php on line 335 I've worked around this problem by not forcing https on the blog. That way the module can read the rss feed without encryption. The blog works without SSL and with SSL, and I force SSL for logins. I had someone test the feed from a different server, and it worked fine with SSL, so the problem appears to be isolated to this server. The second problem occurs when I try to run some commandline python scripts, I get this error: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='wiki.vvfh.org', port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),)) Both of them appear to be related to how openssl handles ssl sessions. When I run openssl s_client -connect wiki.vvfh.org:443, I get the following error: Verify return code: 18 (self signed certificate) This is very odd, because ssllabs.com scores the site as an A, and says the chain is intact, no missing parts. Yet, for some reason, ssl doesn't see it that way. Furthermore, it sees the certs as self-signed, which makes no sense at all. I'm using a wildcard cert (Comodo) for three sites: www, wiki and blog - all in the vvfh.org domain. Even more confusing, if I verify the cert from the commandline, openssl says it's OK. openssl verify -untrusted comodo-rsa-domain-validation-sha-2-w-root.ca-bundle STAR_vvfh_org.crt STAR_vvfh_org.crt: OK If I verify the cert without the chain, I get an error: openssl verify STAR_vvfh_org.crt STAR_vvfh_org.crt: OU = Domain Control Validated, OU = PositiveSSL Wildcard, CN = *.vvfh.org error 20 at 0 depth lookup:unable to get local issuer certificate This is my apache (2.4) config: # Enable SSL SSLEngine On SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 SSLHonorCipherOrder on SSLCertificateFile /webcerts/STAR_vvfh_org.crt SSLCertificateKeyFile /webcerts/STAR.vvfh.org.key SSLCACertificateFile /webcerts/COMODORSADomainValidationSecureServerCA.crt SSLCertificateChainFile /webcerts/comodo-rsa-domain-validation-sha-2-w-root.ca-bundle I've been working around the problem, but I'd like to figure it out and get it fixed. "The man who never looks into a newspaper is better informed than he who reads them, inasmuch as he who knows nothing is nearer the truth than he whose mind is filled with falsehoods and errors." - Thomas Jefferson Paul Schmehl (pschmehl at tx.rr.com) Independent Researcher From aileronajay at gmail.com Fri Nov 10 05:48:44 2017 From: aileronajay at gmail.com (ajay saxena) Date: Fri, 10 Nov 2017 00:48:44 -0500 Subject: [openssl-users] How is the AES CTR encryption working in openssl EVP api Message-ID: Hi, I am trying to use AES CTR encryption to encrypt/decrypt data using EVP API. The earlier API, AES_ctr128_encrypt does explicitly use a counter. How is the counter handled in the EVP implmentation. I followed this documentation here, https://wiki.openssl. org/index.php/EVP_Symmetric_Encryption_and_Decryption and replaced the cbc with ctr function. Can someone please help me understand the usage of AES CTR encryption using EVP api. Thanks, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajaygargnsit at gmail.com Fri Nov 10 07:22:41 2017 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Fri, 10 Nov 2017 12:52:41 +0530 Subject: [openssl-users] How to compile for ARM-Cortex M4? Message-ID: Hi All. I am using bleeding-edge openssl code, and wish to compile it for https://www.digikey.com/product-detail/en/microchip-technology/ATSAM4E8CA-AUR/ATSAM4E8CA-AURCT-ND/4140758 What is the best/recommended way to accomplish this? Will be grateful for a reply. Thanks and Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Fri Nov 10 16:33:41 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 10 Nov 2017 16:33:41 +0000 Subject: [openssl-users] Strange problem with openssl In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Paul Schmehl > Sent: Thursday, November 09, 2017 20:09 > To: openssl-users at openssl.org > Subject: [openssl-users] Strange problem with openssl > > When I run openssl s_client -connect wiki.vvfh.org:443, I get the following > error: Verify return code: 18 (self signed certificate) > > This is very odd, because ssllabs.com scores the site as an A, and says the > chain is intact, no missing parts. Yet, for some reason, ssl doesn't see it > that way. Furthermore, it sees the certs as self-signed, which makes no > sense at all. It sees *a* certificate as self-signed. And indeed there is one. You're sending the entire chain, including the root. By definition, the root is self-signed. So s_client is saying: I'm verifying the chain from the server, and I got to the point where I found a self-signed certificate (which is the same as saying "I found a root certificate"). OpenSSL isn't contradicting ssllabs. s_client reports the whole chain is there. > Even more confusing, if I verify the cert from the commandline, openssl > says it's OK. > openssl verify -untrusted > comodo-rsa-domain-validation-sha-2-w-root.ca-bundle STAR_vvfh_org.crt > STAR_vvfh_org.crt: OK s_client isn't saying the certificate isn't OK. It's saying it received a root certificate from the server. You didn't give s_client any trust anchors to verify the chain. So it's going to walk the whole chain, and it's going to find the root, and it's going to complain about that. Programs don't normally send the root certificate, on the grounds that if the peer doesn't already have it, they're not going to trust it anyway. But it's not forbidden. Try this: 1. Run "openssl s_client -connect wiki.vvfh.org:443 -showcerts". Copy the last certificate in the output (which will be the root) and paste it into tmp.pem. 2. Run " openssl s_client -connect wiki.vvfh.org:443 -verify 2 -CAfile tmp.pem". No complaint from s_client now. -- Michael Wojcik Distinguished Engineer, Micro Focus From pschmehl at tx.rr.com Fri Nov 10 16:59:17 2017 From: pschmehl at tx.rr.com (Paul Schmehl) Date: Fri, 10 Nov 2017 10:59:17 -0600 Subject: [openssl-users] Strange problem with openssl In-Reply-To: References: Message-ID: <082BC67DEC314A624C1C360C@Pauls-MacBook-Pro.local> --On November 10, 2017 at 4:33:41 PM +0000 Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Paul Schmehl >> Sent: Thursday, November 09, 2017 20:09 >> To: openssl-users at openssl.org >> Subject: [openssl-users] Strange problem with openssl >> >> When I run openssl s_client -connect wiki.vvfh.org:443, I get the >> following error: Verify return code: 18 (self signed certificate) >> >> This is very odd, because ssllabs.com scores the site as an A, and says >> the chain is intact, no missing parts. Yet, for some reason, ssl doesn't >> see it that way. Furthermore, it sees the certs as self-signed, which >> makes no sense at all. > > It sees *a* certificate as self-signed. And indeed there is one. You're > sending the entire chain, including the root. By definition, the root is > self-signed. > > So s_client is saying: I'm verifying the chain from the server, and I got > to the point where I found a self-signed certificate (which is the same > as saying "I found a root certificate"). > > OpenSSL isn't contradicting ssllabs. s_client reports the whole chain is > there. > Thanks for clearing that up, Michael. >> Even more confusing, if I verify the cert from the commandline, openssl >> says it's OK. >> openssl verify -untrusted >> comodo-rsa-domain-validation-sha-2-w-root.ca-bundle STAR_vvfh_org.crt >> STAR_vvfh_org.crt: OK > > s_client isn't saying the certificate isn't OK. It's saying it received a > root certificate from the server. > > You didn't give s_client any trust anchors to verify the chain. So it's > going to walk the whole chain, and it's going to find the root, and it's > going to complain about that. > > Programs don't normally send the root certificate, on the grounds that if > the peer doesn't already have it, they're not going to trust it anyway. > But it's not forbidden. > > Try this: > > 1. Run "openssl s_client -connect wiki.vvfh.org:443 -showcerts". Copy the > last certificate in the output (which will be the root) and paste it into > tmp.pem. 2. Run " openssl s_client -connect wiki.vvfh.org:443 -verify 2 > -CAfile tmp.pem". No complaint from s_client now. You are correct. Thanks for clarifying this. Do you have any thoughts on why I'm getting the errors when trying to connect to the rss2 feed or the commandline issue with python? "The man who never looks into a newspaper is better informed than he who reads them, inasmuch as he who knows nothing is nearer the truth than he whose mind is filled with falsehoods and errors." - Thomas Jefferson Paul Schmehl (pschmehl at tx.rr.com) Independent Researcher From Michael.Wojcik at microfocus.com Fri Nov 10 17:21:25 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 10 Nov 2017 17:21:25 +0000 Subject: [openssl-users] Strange problem with openssl In-Reply-To: <082BC67DEC314A624C1C360C@Pauls-MacBook-Pro.local> References: <082BC67DEC314A624C1C360C@Pauls-MacBook-Pro.local> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Paul Schmehl > Sent: Friday, November 10, 2017 11:59 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Strange problem with openssl > > Do you have any thoughts on why I'm getting the errors when trying to > connect to the rss2 feed or the commandline issue with python? All we have from the rss2 issue is a generic complaint about verifying the server's certificate chain, so it's really hard to say. The module you're using either doesn't provide good diagnostics, or it's putting them somewhere other than stderr. It's possible that the module is configuring OpenSSL to not allow wildcard certificates. It's possible that it doesn't have the Comodo root in its trust collection. I'm not offhand seeing any other problems with the certs, though I certainly didn't try to check every possibility. The openssl verify commands you ran will have tested a number of the possible reasons for rejection, but not all of them. (There are options to test other things, but that gets complicated, too; you don't know what checks your failing applications are making.) The Python issue looks like it's probably the same thing, whatever that thing may be. It's also complaining about certificate verification. If you can get either of those clients to provide more detailed diagnostics, we might be able to narrow it down. Or someone else on the list might have a better idea. Certificate validation with the public Internet X.509 PKI hierarchy is a nightmare, to be honest. (Ivan Ristic's /Bulletproof TLS/ book discusses many of the problems; the Cypherpunks presentation "X.509 PKI: The OSI of a New Generation" is another good source.) There are a zillion things that can go wrong, and it's often very difficult to figure out why some particular application is unhappy. -- Michael Wojcik Distinguished Engineer, Micro Focus From pschmehl at tx.rr.com Fri Nov 10 17:47:39 2017 From: pschmehl at tx.rr.com (Paul Schmehl) Date: Fri, 10 Nov 2017 11:47:39 -0600 Subject: [openssl-users] Strange problem with openssl In-Reply-To: References: <082BC67DEC314A624C1C360C@Pauls-MacBook-Pro.local> Message-ID: <7CB2B9F40164BD31B45C91B7@Pauls-MacBook-Pro.local> --On November 10, 2017 at 5:21:25 PM +0000 Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Paul Schmehl >> Sent: Friday, November 10, 2017 11:59 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] Strange problem with openssl >> >> Do you have any thoughts on why I'm getting the errors when trying to >> connect to the rss2 feed or the commandline issue with python? > > All we have from the rss2 issue is a generic complaint about verifying > the server's certificate chain, so it's really hard to say. The module > you're using either doesn't provide good diagnostics, or it's putting > them somewhere other than stderr. > > It's possible that the module is configuring OpenSSL to not allow > wildcard certificates. It's possible that it doesn't have the Comodo root > in its trust collection. I'm not offhand seeing any other problems with > the certs, though I certainly didn't try to check every possibility. The > openssl verify commands you ran will have tested a number of the possible > reasons for rejection, but not all of them. (There are options to test > other things, but that gets complicated, too; you don't know what checks > your failing applications are making.) > > The Python issue looks like it's probably the same thing, whatever that > thing may be. It's also complaining about certificate verification. > > If you can get either of those clients to provide more detailed > diagnostics, we might be able to narrow it down. Or someone else on the > list might have a better idea. > > Certificate validation with the public Internet X.509 PKI hierarchy is a > nightmare, to be honest. (Ivan Ristic's /Bulletproof TLS/ book discusses > many of the problems; the Cypherpunks presentation "X.509 PKI: The OSI of > a New Generation" is another good source.) There are a zillion things > that can go wrong, and it's often very difficult to figure out why some > particular application is unhappy. > Thanks again for your detailed response, Michael. WRT the RSS issue, the vendor was able to view the feed over https without any errors, using the same software that I'm using (Joomla 3.8.2 and Simple RSS Feed Reader (by JoomlaWorks) 3.5). So, that seems to point to a problem unique to my server. The python problem I may be able to enable debug on and see if any additional detail is helpful. I'll check in to that. > -- > Michael Wojcik > Distinguished Engineer, Micro Focus "The man who never looks into a newspaper is better informed than he who reads them, inasmuch as he who knows nothing is nearer the truth than he whose mind is filled with falsehoods and errors." - Thomas Jefferson Paul Schmehl (pschmehl at tx.rr.com) Independent Researcher From simon.d.matthews at gmail.com Sun Nov 12 04:39:21 2017 From: simon.d.matthews at gmail.com (Simon Matthews) Date: Sat, 11 Nov 2017 20:39:21 -0800 Subject: [openssl-users] alert number 46: Message-ID: I have generated a new certificate for my CentOS 6/postfix server, and it seems to work with most clients, but when I try to send email using tls from my Android device, it always fails. In my postfix log, I see: warning: TLS library problem: 13671:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1275:SSL alert number 46: I get the same message when using the same new certificate with dovecot, so I don't think it is a postfix issue. To generate the certificate, I used the following commands: openssl genrsa -out MatthewsCA2017.key 2048 openssl genrsa -des3 -out MatthewsCA2017.key 2048 openssl req -x509 -new -nodes -key MatthewsCA2017.key -sha256 -days 3000 -out MatthewsCA2017.pem openssl genrsa -out smtp.matthews-family.org.uk.key 2048 openssl req -new -key smtp.matthews-family.org.uk.key -out smtp.matthews-family.org.uk.csr openssl x509 -req -in smtp.matthews-family.org.uk.csr -CA MatthewsCA2017.pem -CAkey MatthewsCA2017.key -CAcreateserial -out smtp.matthews-family.org.uk.crt -days 3000 -sha256 Any ideas on what might be wrong? Simon From janjust at nikhef.nl Sun Nov 12 12:55:10 2017 From: janjust at nikhef.nl (Jan Just Keijser) Date: Sun, 12 Nov 2017 13:55:10 +0100 Subject: [openssl-users] alert number 46: In-Reply-To: References: Message-ID: <5A0844AE.3020300@nikhef.nl> Hi, On 12/11/17 05:39, Simon Matthews wrote: > I have generated a new certificate for my CentOS 6/postfix server, and > it seems to work with most clients, but when I try to send email using > tls from my Android device, it always fails. > > In my postfix log, I see: > > warning: TLS library problem: 13671:error:14094416:SSL > routines:SSL3_READ_BYTES:sslv3 alert certificate > unknown:s3_pkt.c:1275:SSL alert number 46: > > I get the same message when using the same new certificate with > dovecot, so I don't think it is a postfix issue. > > To generate the certificate, I used the following commands: > > openssl genrsa -out MatthewsCA2017.key 2048 > openssl genrsa -des3 -out MatthewsCA2017.key 2048 > openssl req -x509 -new -nodes -key MatthewsCA2017.key -sha256 -days > 3000 -out MatthewsCA2017.pem > openssl genrsa -out smtp.matthews-family.org.uk.key 2048 > openssl req -new -key smtp.matthews-family.org.uk.key -out > smtp.matthews-family.org.uk.csr > openssl x509 -req -in smtp.matthews-family.org.uk.csr -CA > MatthewsCA2017.pem -CAkey MatthewsCA2017.key -CAcreateserial -out > smtp.matthews-family.org.uk.crt -days 3000 -sha256 > > Any ideas on what might be wrong? > you seem to have generated your own (new) CA and server certificate; is this CA (public) cert installed in postfix correctly. More importantly, is this new CA distributed to all devices? An alert 46 usually hints at SSL3_AD_CERTIFICATE_UNKNOWN HTH, JJK From simon.d.matthews at gmail.com Sun Nov 12 15:47:25 2017 From: simon.d.matthews at gmail.com (Simon Matthews) Date: Sun, 12 Nov 2017 07:47:25 -0800 Subject: [openssl-users] alert number 46: In-Reply-To: <5A0844AE.3020300@nikhef.nl> References: <5A0844AE.3020300@nikhef.nl> Message-ID: On Sun, Nov 12, 2017 at 4:55 AM, Jan Just Keijser wrote: > Hi, > > On 12/11/17 05:39, Simon Matthews wrote: >> >> I have generated a new certificate for my CentOS 6/postfix server, and >> it seems to work with most clients, but when I try to send email using >> tls from my Android device, it always fails. >> >> In my postfix log, I see: >> >> warning: TLS library problem: 13671:error:14094416:SSL >> routines:SSL3_READ_BYTES:sslv3 alert certificate >> unknown:s3_pkt.c:1275:SSL alert number 46: >> >> I get the same message when using the same new certificate with >> dovecot, so I don't think it is a postfix issue. >> >> To generate the certificate, I used the following commands: >> >> openssl genrsa -out MatthewsCA2017.key 2048 >> openssl genrsa -des3 -out MatthewsCA2017.key 2048 >> openssl req -x509 -new -nodes -key MatthewsCA2017.key -sha256 -days >> 3000 -out MatthewsCA2017.pem >> openssl genrsa -out smtp.matthews-family.org.uk.key 2048 >> openssl req -new -key smtp.matthews-family.org.uk.key -out >> smtp.matthews-family.org.uk.csr >> openssl x509 -req -in smtp.matthews-family.org.uk.csr -CA >> MatthewsCA2017.pem -CAkey MatthewsCA2017.key -CAcreateserial -out >> smtp.matthews-family.org.uk.crt -days 3000 -sha256 >> >> Any ideas on what might be wrong? >> > > you seem to have generated your own (new) CA and server certificate; is this > CA (public) cert installed in postfix correctly. More importantly, is this > new CA distributed to all devices? > An alert 46 usually hints at SSL3_AD_CERTIFICATE_UNKNOWN In my Android device, I am using the option "TLS (Accept all certificates)" which was working with my prior certificate. I built a new CA and certificate because Microsoft/Hotmail would not send email to my server because of the use of MD5 in the certificate chain. In the postfix main.cf, I have: smtpd_tls_CAfile = /etc/ssl/MatthewsCA2017.pem The file exists: # ls /etc/ssl/MatthewsCA2017.pem /etc/ssl/MatthewsCA2017.pem This is CentOS 6 VM. Is there anything else I should do to install the certificates? I notice that the dovecot configuration doesn't explicitly define the CA certificate location, so perhaps I have missed something? Simon From simon.d.matthews at gmail.com Sun Nov 12 21:03:30 2017 From: simon.d.matthews at gmail.com (Simon Matthews) Date: Sun, 12 Nov 2017 13:03:30 -0800 Subject: [openssl-users] Certificate expired on https://mta.openssl.org/ Message-ID: I am getting a certificate expired error on the above URL. Simon From levitte at openssl.org Sun Nov 12 22:21:41 2017 From: levitte at openssl.org (Richard Levitte) Date: Sun, 12 Nov 2017 23:21:41 +0100 (CET) Subject: [openssl-users] Certificate expired on https://mta.openssl.org/ In-Reply-To: References: Message-ID: <20171112.232141.1470781419891882673.levitte@openssl.org> Thanks for the notification. There are new certificates, but I forgot to update the apache config on mta accordingly. Fixed now. Cheers, Richard In message on Sun, 12 Nov 2017 13:17:58 -0800, Simon Matthews said: simon.d.matthews> Richard, simon.d.matthews> Please see the subject. simon.d.matthews> simon.d.matthews> Simon simon.d.matthews> simon.d.matthews> ---------- Forwarded message ---------- simon.d.matthews> From: Jeffrey Walton simon.d.matthews> Date: Sun, Nov 12, 2017 at 1:10 PM simon.d.matthews> Subject: Re: [openssl-users] Certificate expired on https://mta.openssl.org/ simon.d.matthews> To: simon.d.matthews at gmail.com simon.d.matthews> simon.d.matthews> simon.d.matthews> On Sun, Nov 12, 2017 at 4:03 PM, Simon Matthews simon.d.matthews> wrote: simon.d.matthews> > I am getting a certificate expired error on the above URL. simon.d.matthews> simon.d.matthews> You might want to contact Richard Levitte at levitte at openssl.org. I simon.d.matthews> think he handles most OpenSSL infrastructure. simon.d.matthews> simon.d.matthews> Jeff simon.d.matthews> From aerowolf at gmail.com Sun Nov 12 22:28:41 2017 From: aerowolf at gmail.com (Kyle Hamilton) Date: Sun, 12 Nov 2017 14:28:41 -0800 Subject: [openssl-users] alert number 46: In-Reply-To: References: <5A0844AE.3020300@nikhef.nl> Message-ID: Use a publicly-trusted certification authority, such as Let's Encrypt. The problem is from the remote side (it's sending the alert that it does not recognize your certificate issuer). -Kyle H On Sun, Nov 12, 2017 at 7:47 AM, Simon Matthews wrote: > On Sun, Nov 12, 2017 at 4:55 AM, Jan Just Keijser wrote: >> Hi, >> >> On 12/11/17 05:39, Simon Matthews wrote: >>> >>> I have generated a new certificate for my CentOS 6/postfix server, and >>> it seems to work with most clients, but when I try to send email using >>> tls from my Android device, it always fails. >>> >>> In my postfix log, I see: >>> >>> warning: TLS library problem: 13671:error:14094416:SSL >>> routines:SSL3_READ_BYTES:sslv3 alert certificate >>> unknown:s3_pkt.c:1275:SSL alert number 46: >>> >>> I get the same message when using the same new certificate with >>> dovecot, so I don't think it is a postfix issue. >>> >>> To generate the certificate, I used the following commands: >>> >>> openssl genrsa -out MatthewsCA2017.key 2048 >>> openssl genrsa -des3 -out MatthewsCA2017.key 2048 >>> openssl req -x509 -new -nodes -key MatthewsCA2017.key -sha256 -days >>> 3000 -out MatthewsCA2017.pem >>> openssl genrsa -out smtp.matthews-family.org.uk.key 2048 >>> openssl req -new -key smtp.matthews-family.org.uk.key -out >>> smtp.matthews-family.org.uk.csr >>> openssl x509 -req -in smtp.matthews-family.org.uk.csr -CA >>> MatthewsCA2017.pem -CAkey MatthewsCA2017.key -CAcreateserial -out >>> smtp.matthews-family.org.uk.crt -days 3000 -sha256 >>> >>> Any ideas on what might be wrong? >>> >> >> you seem to have generated your own (new) CA and server certificate; is this >> CA (public) cert installed in postfix correctly. More importantly, is this >> new CA distributed to all devices? >> An alert 46 usually hints at SSL3_AD_CERTIFICATE_UNKNOWN > > In my Android device, I am using the option "TLS (Accept all > certificates)" which was working with my prior certificate. I built a > new CA and certificate because Microsoft/Hotmail would not send email > to my server because of the use of MD5 in the certificate chain. > > In the postfix main.cf, I have: > smtpd_tls_CAfile = /etc/ssl/MatthewsCA2017.pem > > The file exists: > # ls /etc/ssl/MatthewsCA2017.pem > /etc/ssl/MatthewsCA2017.pem > > This is CentOS 6 VM. > > Is there anything else I should do to install the certificates? I > notice that the dovecot configuration doesn't explicitly define the CA > certificate location, so perhaps I have missed something? > > Simon > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From simon.d.matthews at gmail.com Mon Nov 13 05:35:35 2017 From: simon.d.matthews at gmail.com (Simon Matthews) Date: Sun, 12 Nov 2017 21:35:35 -0800 Subject: [openssl-users] alert number 46: In-Reply-To: References: <5A0844AE.3020300@nikhef.nl> Message-ID: I installed letsencrypt and generated a certificate. Even with this certificate, I got the same error. The error went away when I changed the connection to "TLS" from "TLS (Accept All Certificates)". I wonder if the root problem was that the mail app on my phone won't accept newer certificates unless it can validate them fully? Simon On Sun, Nov 12, 2017 at 2:28 PM, Kyle Hamilton wrote: > Use a publicly-trusted certification authority, such as Let's Encrypt. > The problem is from the remote side (it's sending the alert that it > does not recognize your certificate issuer). > > -Kyle H > > On Sun, Nov 12, 2017 at 7:47 AM, Simon Matthews > wrote: >> On Sun, Nov 12, 2017 at 4:55 AM, Jan Just Keijser wrote: >>> Hi, >>> >>> On 12/11/17 05:39, Simon Matthews wrote: >>>> >>>> I have generated a new certificate for my CentOS 6/postfix server, and >>>> it seems to work with most clients, but when I try to send email using >>>> tls from my Android device, it always fails. >>>> >>>> In my postfix log, I see: >>>> >>>> warning: TLS library problem: 13671:error:14094416:SSL >>>> routines:SSL3_READ_BYTES:sslv3 alert certificate >>>> unknown:s3_pkt.c:1275:SSL alert number 46: >>>> >>>> I get the same message when using the same new certificate with >>>> dovecot, so I don't think it is a postfix issue. >>>> >>>> To generate the certificate, I used the following commands: >>>> >>>> openssl genrsa -out MatthewsCA2017.key 2048 >>>> openssl genrsa -des3 -out MatthewsCA2017.key 2048 >>>> openssl req -x509 -new -nodes -key MatthewsCA2017.key -sha256 -days >>>> 3000 -out MatthewsCA2017.pem >>>> openssl genrsa -out smtp.matthews-family.org.uk.key 2048 >>>> openssl req -new -key smtp.matthews-family.org.uk.key -out >>>> smtp.matthews-family.org.uk.csr >>>> openssl x509 -req -in smtp.matthews-family.org.uk.csr -CA >>>> MatthewsCA2017.pem -CAkey MatthewsCA2017.key -CAcreateserial -out >>>> smtp.matthews-family.org.uk.crt -days 3000 -sha256 >>>> >>>> Any ideas on what might be wrong? >>>> >>> >>> you seem to have generated your own (new) CA and server certificate; is this >>> CA (public) cert installed in postfix correctly. More importantly, is this >>> new CA distributed to all devices? >>> An alert 46 usually hints at SSL3_AD_CERTIFICATE_UNKNOWN >> >> In my Android device, I am using the option "TLS (Accept all >> certificates)" which was working with my prior certificate. I built a >> new CA and certificate because Microsoft/Hotmail would not send email >> to my server because of the use of MD5 in the certificate chain. >> >> In the postfix main.cf, I have: >> smtpd_tls_CAfile = /etc/ssl/MatthewsCA2017.pem >> >> The file exists: >> # ls /etc/ssl/MatthewsCA2017.pem >> /etc/ssl/MatthewsCA2017.pem >> >> This is CentOS 6 VM. >> >> Is there anything else I should do to install the certificates? I >> notice that the dovecot configuration doesn't explicitly define the CA >> certificate location, so perhaps I have missed something? >> >> Simon >> -- >> 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 openssl-users at dukhovni.org Mon Nov 13 05:38:43 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 13 Nov 2017 00:38:43 -0500 Subject: [openssl-users] alert number 46: In-Reply-To: References: <5A0844AE.3020300@nikhef.nl> Message-ID: > On Nov 13, 2017, at 12:35 AM, Simon Matthews wrote: > > I installed letsencrypt and generated a certificate. > > Even with this certificate, I got the same error. The error went away > when I changed the connection to "TLS" from "TLS (Accept All > Certificates)". > > I wonder if the root problem was that the mail app on my phone won't > accept newer certificates unless it can validate them fully? Your phone is not using OpenSSL. So sadly, this is not the right forum for this question. Ask on the appropriate Android, iOS etc. forum. -- Viktor. From grace.priscilla at gmail.com Mon Nov 13 06:48:18 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Mon, 13 Nov 2017 12:18:18 +0530 Subject: [openssl-users] Same library usage for DTLS on SCTP and UDP Message-ID: Hi, We are using openssl library for UDP and SCTP connections. The library is compiled with "sctp" option. But when it is used for DTLS on UDP the connection hangs at SSL_accept. When we remove the sctp option in compilation, the call for DTLS on UDP goes fine. Do we have any additional option to configure the library for build so that it supports both UDP and SCTP connections without any issue? Thanks, Grace -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Nov 13 10:31:43 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Nov 2017 10:31:43 +0000 Subject: [openssl-users] Same library usage for DTLS on SCTP and UDP In-Reply-To: References: Message-ID: <61657cb0-cb25-b6f7-4c0b-dc8dcd6bafea@openssl.org> On 13/11/17 06:48, Grace Priscilla Jero wrote: > Hi, > > We are using openssl library for UDP and SCTP connections. The library > is compiled with "sctp" option. But when it is used for DTLS on UDP the > connection hangs at SSL_accept. > > When we remove the sctp option in compilation, the call for DTLS on UDP > goes fine. Do we have any additional option to configure the library for > build so that it supports both UDP and SCTP connections without any issue? That smells like an OpenSSL bug. Choosing the sctp option during compilation should have no impact on your ability to do DTLS on UDP. Which OpenSSL version is this? Matt From grace.priscilla at gmail.com Mon Nov 13 11:42:18 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Mon, 13 Nov 2017 17:12:18 +0530 Subject: [openssl-users] Same library usage for DTLS on SCTP and UDP In-Reply-To: References: <61657cb0-cb25-b6f7-4c0b-dc8dcd6bafea@openssl.org> Message-ID: It is 1.1.0f version. Thanks, Grace On 13-Nov-2017 4:02 PM, "Matt Caswell" wrote: On 13/11/17 06:48, Grace Priscilla Jero wrote: > Hi, > > We are using openssl library for UDP and SCTP connections. The library > is compiled with "sctp" option. But when it is used for DTLS on UDP the > connection hangs at SSL_accept. > > When we remove the sctp option in compilation, the call for DTLS on UDP > goes fine. Do we have any additional option to configure the library for > build so that it supports both UDP and SCTP connections without any issue? That smells like an OpenSSL bug. Choosing the sctp option during compilation should have no impact on your ability to do DTLS on UDP. Which OpenSSL version is this? 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 Mon Nov 13 12:05:42 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Nov 2017 12:05:42 +0000 Subject: [openssl-users] Same library usage for DTLS on SCTP and UDP In-Reply-To: References: <61657cb0-cb25-b6f7-4c0b-dc8dcd6bafea@openssl.org> Message-ID: On 13/11/17 11:42, Grace Priscilla Jero wrote: > It is 1.1.0f version. Ah! This is probably this bug: https://github.com/openssl/openssl/issues/3723 Which was fixed in 1.1.0 here: https://github.com/openssl/openssl/commit/21815512063d00325fd8e25f3f39ced047cb968b That fix was made available in the latest 1.1.0g release, so please upgrade. Matt > > Thanks, > Grace > > On 13-Nov-2017 4:02 PM, "Matt Caswell" > wrote: > > > > On 13/11/17 06:48, Grace Priscilla Jero wrote: > > Hi, > > > > We are using openssl library for UDP and SCTP connections. The library > > is compiled with "sctp" option. But when it is used for DTLS on > UDP the > > connection hangs at SSL_accept. > > > > When we remove the sctp option in compilation, the call for DTLS > on UDP > > goes fine. Do we have any additional option to configure the > library for > > build so that it supports both UDP and SCTP connections without > any issue? > > That smells like an OpenSSL bug. Choosing the sctp option during > compilation should have no impact on your ability to do DTLS on UDP. > Which OpenSSL version is this? > > Matt > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From steven.logan at optomany.com Mon Nov 13 13:53:17 2017 From: steven.logan at optomany.com (Steven Logan) Date: Mon, 13 Nov 2017 13:53:17 +0000 Subject: [openssl-users] Automatically populating X509_STORE object cache from directory Message-ID: Hi, We have an embedded device which will be loaded with a public key for validating data signatures. We identify this key by means of its SHA-1 fingerprint; to do this we have implemented a custom X509_LOOKUP_METHOD. The lookup, performed via X509_LOOKUP_by_fingerprint works great, that is at least when we call X509_STORE_load_locations with a file identifying the certificate file directly. Our problem begins when I wish to create a store using the directory that contains our data signing certificates. My hope was to identify the relevant certificate by fingerprint and return the X509* to be used in validating the certificate itself against a separate Root/Intermediate store and then the verify signature itself by retrieving the key from the certificate. Sadly, it seems that X509_STORE_load_locations does not automatically populate the object cache with the certificates contained in the directory. It appears this may be by design and not an issue with our code. 1. Is there any way to have OpenSSL automatically populate the cache with the certificates in the directory? 2. In the source code, I can see that X509_STORE_get1_certs will go off and call X509_STORE_get_by_subject and potentially load the certificates from the directory based on their subject. Will I need to implement the equivalent of this in order to load certificates from the directory by fingerprint? 3. Is there anything particularly wrong with this approach? It seemed odd to me that OpenSSL itself does not implement the fingerprint lookup itself. Regards, Steve From jb-openssl at wisemo.com Mon Nov 13 15:03:20 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 13 Nov 2017 16:03:20 +0100 Subject: [openssl-users] Automatically populating X509_STORE object cache from directory In-Reply-To: References: Message-ID: <4bc91044-9ccc-2fb5-be1b-3e1bc8e47868@wisemo.com> On 13/11/2017 14:53, Steven Logan via openssl-users wrote: > Hi, > > We have an embedded device which will be loaded with a public key for validating data signatures. We identify this key by means of its SHA-1 fingerprint; to do this we have implemented a custom X509_LOOKUP_METHOD. > > The lookup, performed via X509_LOOKUP_by_fingerprint works great, that is at least when we call X509_STORE_load_locations with a file identifying the certificate file directly. Our problem begins when I wish to create a store using the directory that contains our data signing certificates. My hope was to identify the relevant certificate by fingerprint and return the X509* to be used in validating the certificate itself against a separate Root/Intermediate store and then the verify signature itself by retrieving the key from the certificate. > > Sadly, it seems that X509_STORE_load_locations does not automatically populate the object cache with the certificates contained in the directory. It appears this may be by design and not an issue with our code. > > 1. Is there any way to have OpenSSL automatically populate the cache with the certificates in the directory? > 2. In the source code, I can see that X509_STORE_get1_certs will go off and call X509_STORE_get_by_subject and potentially load the certificates from the directory based on their subject. Will I need to implement the equivalent of this in order to load certificates from the directory by fingerprint? > 3. Is there anything particularly wrong with this approach? It seemed odd to me that OpenSSL itself does not implement the fingerprint lookup itself. > > Regards, > Steve The by-directory method is designed to avoid keeping the entire collection of trusted certificate in memory, and to avoid slowing down program startup with the time to load all the certificates.? Because the main use is to find the issuer of a certificate received from another computer, the directory contains certificate files whose name is an 8-digit checksum of the subject referenced by other certificate, with a file extensions being simply a counter from 0 to the number of certificates with a duplicate hash value. For your use of finding certificates by weak certificate hash (SHA-1 is being phased out of this world as quickly as possible), the options are to either write a script that symlinks from the first 10 hex digits of the SHA-1 hash (with similar collision-counting extension) and write your own lookup code, or to write a function to load all the certificates either by looping over the directory or using a traditional all-certs-in-one-file like ca-certificates.crt. However unless you have a hard requirement to start from the SHA-1 "fingerprint", it is probably a lot easier to just change your code to identify the certificate by a "friendly name", which would simple be the filename without directory and .pem extension.? For example "ValiCert_Class_1_VA" as input loading /etc/ssl/certs/ValiCert_Class_1_VA.pem . 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 doroshenkoay at bk.ru Mon Nov 13 15:12:34 2017 From: doroshenkoay at bk.ru (Miguel_Diaz) Date: Mon, 13 Nov 2017 08:12:34 -0700 (MST) Subject: [openssl-users] Building OpenSSL for Intel Xeon Phi Message-ID: <1510585954413-0.post@n7.nabble.com> Hi, I try build OpenSSl for Intel Xeon Phi coprocessor. So far as I understand this problem reduced to building OpenSSL for "linux-generic64" as target. ( https://software.intel.com/sites/default/files/article/373907/intel-r-xeon-phi-tm-cluster-configuration_1.pdf ) I use next string for configure: /perl ./Configure --prefix=D:\openssl\bin shared linux-generic64/ configure.png but makefile not change. Please, help me build OpenSSL for Intel Xeon Phi. Thanks! -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From doroshenkoay at bk.ru Mon Nov 13 15:15:14 2017 From: doroshenkoay at bk.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCU0L7RgNC+0YjQtdC90LrQvg==?=) Date: Mon, 13 Nov 2017 18:15:14 +0300 Subject: [openssl-users] =?utf-8?q?Fwd=3A_Build_OpenSSL_for_Intel_Xeon_Phi?= Message-ID: <1510586114.556681951@f425.i.mail.ru> Hi, please, post my question. ---------------------------------------------------------------------- ? ?????????, ????????? ????????? ???.: ???. +7(951)3326360 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: Miguel_Diaz Subject: Build OpenSSL for Intel Xeon Phi Date: Mon, 13 Nov 2017 08:08:47 -0700 (MST) Size: 1864 URL: From ajaygargnsit at gmail.com Tue Nov 14 04:10:02 2017 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Tue, 14 Nov 2017 09:40:02 +0530 Subject: [openssl-users] How to compile for ARM-Cortex M4? In-Reply-To: References: Message-ID: Help please... experts ?!! On Fri, Nov 10, 2017 at 12:52 PM, Ajay Garg wrote: > Hi All. > > I am using bleeding-edge openssl code, and wish to compile it for > https://www.digikey.com/product-detail/en/microchip- > technology/ATSAM4E8CA-AUR/ATSAM4E8CA-AURCT-ND/4140758 > > What is the best/recommended way to accomplish this? > > > Will be grateful for a reply. > > > Thanks and Regards, > Ajay > -- Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Tue Nov 14 05:18:34 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Tue, 14 Nov 2017 10:48:34 +0530 Subject: [openssl-users] Same library usage for DTLS on SCTP and UDP In-Reply-To: References: <61657cb0-cb25-b6f7-4c0b-dc8dcd6bafea@openssl.org> Message-ID: Thank-you Matt. We will upgrade and test On 13-Nov-2017 5:36 PM, "Matt Caswell" wrote: > > > On 13/11/17 11:42, Grace Priscilla Jero wrote: > > It is 1.1.0f version. > > Ah! This is probably this bug: > > https://github.com/openssl/openssl/issues/3723 > > Which was fixed in 1.1.0 here: > > https://github.com/openssl/openssl/commit/21815512063d00325fd8e25f3f39ce > d047cb968b > > That fix was made available in the latest 1.1.0g release, so please > upgrade. > > Matt > > > > > > Thanks, > > Grace > > > > On 13-Nov-2017 4:02 PM, "Matt Caswell" > > wrote: > > > > > > > > On 13/11/17 06:48, Grace Priscilla Jero wrote: > > > Hi, > > > > > > We are using openssl library for UDP and SCTP connections. The > library > > > is compiled with "sctp" option. But when it is used for DTLS on > > UDP the > > > connection hangs at SSL_accept. > > > > > > When we remove the sctp option in compilation, the call for DTLS > > on UDP > > > goes fine. Do we have any additional option to configure the > > library for > > > build so that it supports both UDP and SCTP connections without > > any issue? > > > > That smells like an OpenSSL bug. Choosing the sctp option during > > compilation should have no impact on your ability to do DTLS on UDP. > > Which OpenSSL version is this? > > > > 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 marcus.lundblad at primekey.com Tue Nov 14 07:30:13 2017 From: marcus.lundblad at primekey.com (Marcus Lundblad) Date: Tue, 14 Nov 2017 08:30:13 +0100 Subject: [openssl-users] Verifying a timestamp signed using a cert issued by a sub CA (intermediate) Message-ID: <1510644613.21909.12.camel@primekey.com> Hi! I'm trying to verify a timestamp that was signed using a signer certificate that has been issued by an intermediate CA. I'm only able to verify when specifying the intermediate CA certificate as "-untrusted" and the root CA cert as "-CAfile": openssl ts -verify -in /tmp/out10.tsp -queryfile /tmp/out10.tsq -CAfile res/test/dss10/DSSRootCA10.cacert.pem -untrusted res/test/dss10/DSSSubCA11.cacert.pem Using configuration from /usr/lib/ssl/openssl.cnf Verification: OK When running with just -CAfile pointing to the intermediate CA cert, I get: Using configuration from /usr/lib/ssl/openssl.cnf Verification: FAILED 140693337339136:error:2F06D064:time stamp routines:ts_verify_cert:certificate verify error:../crypto/ts/ts_rsp_verify.c:182:Verify error:unable to get issuer certificate And if setting -CAfile to point to the root CA cert: Using configuration from /usr/lib/ssl/openssl.cnf Verification: FAILED 140228374308096:error:2F06D064:time stamp routines:ts_verify_cert:certificate verify error:../crypto/ts/ts_rsp_verify.c:182:Verify error:unable to get local issuer certificate I'm thinking both these variants should have worked (the timestamp response is including the complete chain in the ESSCertID structure). Attached are the CA certs, the signer cert (ts00003.pem), the query (out10.tsq), and the response (out10.tsp) Regards, Marcus Lundblad -------------- next part -------------- A non-text attachment was scrubbed... Name: DSSRootCA10.cacert.pem Type: application/x-pem-file Size: 7140 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DSSSubCA11.cacert.pem Type: application/x-x509-ca-cert Size: 1619 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: out10.tsp Type: application/octet-stream Size: 4336 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: out10.tsq Type: application/octet-stream Size: 49 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ts00003.pem Type: application/x-x509-ca-cert Size: 5200 bytes Desc: URL: From levitte at openssl.org Tue Nov 14 09:25:11 2017 From: levitte at openssl.org (Richard Levitte) Date: Tue, 14 Nov 2017 10:25:11 +0100 (CET) Subject: [openssl-users] Building OpenSSL for Intel Xeon Phi In-Reply-To: <1510585954413-0.post@n7.nabble.com> References: <1510585954413-0.post@n7.nabble.com> Message-ID: <20171114.102511.1953468690468288699.levitte@openssl.org> >From the look of that PNG, you're building in a native Windows environment. The ony configs available in the main source are for Visual C, and are configured like this: perl Configure --prefix=D:\openssl\bin shared VC-WIN64A If you meant to cross compile for a Linux, I do not have an answer for you. In that case, it would probably be better if you could build directly on the intended box. Cheers, Richard In message <1510585954413-0.post at n7.nabble.com> on Mon, 13 Nov 2017 08:12:34 -0700 (MST), Miguel_Diaz said: doroshenkoay> Hi, doroshenkoay> I try build OpenSSl for Intel Xeon Phi coprocessor. doroshenkoay> So far as I understand this problem reduced to building OpenSSL for doroshenkoay> "linux-generic64" as target. doroshenkoay> ( doroshenkoay> https://software.intel.com/sites/default/files/article/373907/intel-r-xeon-phi-tm-cluster-configuration_1.pdf doroshenkoay> doroshenkoay> ) doroshenkoay> I use next string for configure: doroshenkoay> doroshenkoay> /perl ./Configure --prefix=D:\openssl\bin shared linux-generic64/ doroshenkoay> doroshenkoay> configure.png doroshenkoay> but makefile not change. doroshenkoay> doroshenkoay> Please, help me build OpenSSL for Intel Xeon Phi. doroshenkoay> doroshenkoay> Thanks! doroshenkoay> doroshenkoay> doroshenkoay> doroshenkoay> -- doroshenkoay> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html doroshenkoay> From Marcus.Schafheutle at gmx.de Tue Nov 14 09:40:47 2017 From: Marcus.Schafheutle at gmx.de (Marcus.Schafheutle at gmx.de) Date: Tue, 14 Nov 2017 10:40:47 +0100 Subject: [openssl-users] Deactivation of client renegotiation particularily in OpenSSL 1.1.0 Message-ID: An HTML attachment was scrubbed... URL: From mahesh116 at gmail.com Tue Nov 14 10:00:27 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Tue, 14 Nov 2017 15:30:27 +0530 Subject: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application Message-ID: Hi All, We have application that provide DTLS security for SCTP connections. During our testing we found that API "*SSL_connect* " fail and always returns SSL_ERROR_WANT_READ which causes infinite loop in the application. Scenario: 1) On Server side "Client Certificate Request" is enabled by setting the SSL context as shown below SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL); 2) On client side we have not configured the public certificate. *Logs:* [10/14/0117 15:05:06] F42C2700 Link-2 (SSL_accept) Failed to accept new connection, Socket Id 65, Return Value 1 [10/14/0117 15:05:06] F42C2700 Link-2 SSL File :* ssl/statem/statem_srvr.c *, Line number : *2882 *, Linux Error Code 0 [10/14/0117 15:05:06] F26B7700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true [10/14/0117 15:05:06] F26B7700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true [10/14/0117 15:05:06] F26B7700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true *<<< SSL_connect() always returns error code 2 that leeds to infinite loop in application >>>* Attaching PCAP file for your reference. *Thanks,* *Mahesh G S* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: connect.pcap Type: application/octet-stream Size: 62993 bytes Desc: not available URL: From minfrin at sharp.fm Tue Nov 14 10:31:29 2017 From: minfrin at sharp.fm (Graham Leggett) Date: Tue, 14 Nov 2017 12:31:29 +0200 Subject: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application In-Reply-To: References: Message-ID: <4976CBFA-17F5-4BDB-AEE0-212BBD6B28A2@sharp.fm> On 14 Nov 2017, at 12:00 PM, mahesh gs wrote: > We have application that provide DTLS security for SCTP connections. During our testing we found that API "SSL_connect " fail and always returns SSL_ERROR_WANT_READ which causes infinite loop in the application. Are you properly handling that SSL_ERROR_WANT_READ, or are you ignoring it? The message isn?t an error (the symbol was misnamed), it just means openssl is asking you permission to read. If your code is saying "yes openssl you may read" when you actually aren?t ready you?ll end up in an infinite loop. Regards, Graham ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3240 bytes Desc: not available URL: From mahesh116 at gmail.com Tue Nov 14 10:44:15 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Tue, 14 Nov 2017 16:14:15 +0530 Subject: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application In-Reply-To: <4976CBFA-17F5-4BDB-AEE0-212BBD6B28A2@sharp.fm> References: <4976CBFA-17F5-4BDB-AEE0-212BBD6B28A2@sharp.fm> Message-ID: Hi, As per the suggestion from openssl documentation whenever the SSL API returns SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, The calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_connect(). I am copying the code bits here, do { /* Clear openssl error queue */ ERR_clear_error(); /* Initiate SSL Handshake */ aRetValue = SSL_connect(ivSSL); if (aRetValue <= 0) { aTlsError = SSL_get_error(ivSSL, aRetValue); switch(aTlsError) { case SSL_ERROR_WANT_READ: case SSL_ERROR_WANT_WRITE: { /* Select on the socket for read/write events */ * retry = pollSocketForEvents(aTlsError); --------------> Function is copied below* /* Nothing to do, retry to connect again*/ LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL_connect() fails to connect " "need to retry, returned error code %d , retry ? %s", ivLink->getLinkId(), aTlsError, retry?"true":"false"); } break; case SSL_ERROR_SYSCALL: if (EWOULDBLOCK == errno || EAGAIN == errno) { /* Nothing to do, retry to connect again */ } else { int aRet = ERR_get_error_line(&aFile, &aLine); LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL File : %s , Line number : %d , " "Socket Id %d, Linux Error Code %d",ivLink->getLinkId(), aFile, aLine, getFd(), errno); LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL_connect () :: Result Code : %d ",ivLink->getLinkId(), aTlsError); retry = false; } break; default: { int aRet = ERR_get_error_line(&aFile, &aLine); LOGG_DBUG(Logger::M3UA_LOG,"Link-%d (SSL_connect) Failed to connect to server, " " Socket Id %d, Return Value %d ", ivLink->getLinkId(), getFd(), aTlsError); LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL File : %s , Line number : %d , Linux Error Code %d",ivLink->getLinkId(), aFile, aLine, errno); retry = false; } break; } } }while (aRetValue != 1 && retry != false); bool TlsAssociation::pollSocketForEvents(long aTlsError) { /* This function is to implement the SSL Socket call behaviour http://jmarshall.com/stuff/handling-nbio-errors-in-openssl.html */ fd_set readFds, writeFds; struct timeval timeout; int retValue; int nfds = getFd(); FD_ZERO (&readFds); FD_ZERO (&writeFds); FD_SET(nfds, &readFds); FD_SET(nfds, &writeFds); /* Wait for 5 Seconds */ timeout.tv_usec = 0; timeout.tv_sec = 5; if (SSL_ERROR_WANT_READ == aTlsError) { retValue = select(nfds + 1, &readFds, NULL, NULL, &timeout); if (retValue <= 0) { // Timeout or error just return failure return false; } } if (SSL_ERROR_WANT_WRITE == aTlsError) { retValue = select(nfds + 1, NULL, &writeFds, NULL, &timeout); if (retValue <= 0) { // Timeout or error just return failure return false; } } return true; } Thanks, Mahesh G S On Tue, Nov 14, 2017 at 4:01 PM, Graham Leggett wrote: > On 14 Nov 2017, at 12:00 PM, mahesh gs wrote: > > We have application that provide DTLS security for SCTP connections. > During our testing we found that API "*SSL_connect* " fail and always > returns SSL_ERROR_WANT_READ which causes infinite loop in the application. > > > Are you properly handling that SSL_ERROR_WANT_READ, or are you ignoring it? > > The message isn?t an error (the symbol was misnamed), it just means > openssl is asking you permission to read. If your code is saying "yes > openssl you may read" when you actually aren?t ready you?ll end up in an > infinite loop. > > Regards, > Graham > ? > > > -- > 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 Nov 14 11:05:29 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Nov 2017 11:05:29 +0000 Subject: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application In-Reply-To: References: <4976CBFA-17F5-4BDB-AEE0-212BBD6B28A2@sharp.fm> Message-ID: <7a4b067c-ce3a-29dd-d05c-0caf045479eb@openssl.org> On 14/11/17 10:44, mahesh gs wrote: > case SSL_ERROR_SYSCALL: > > if (EWOULDBLOCK == errno || EAGAIN == errno) > { > ? /* Nothing to do, retry to connect again */ > } This doesn't look right. If SSL_connect() fails due to an NBIO event then you should get SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE back. If you get SSL_ERROR_SYSCALL then something bad happened and you should not retry. Could you add some logging here? I'm wondering whether you are ending up here but missing it and looping around again. Matt From dcoombs at carillon.ca Tue Nov 14 14:04:41 2017 From: dcoombs at carillon.ca (Dave Coombs) Date: Tue, 14 Nov 2017 09:04:41 -0500 Subject: [openssl-users] Verifying a timestamp signed using a cert issued by a sub CA (intermediate) In-Reply-To: <1510644613.21909.12.camel@primekey.com> References: <1510644613.21909.12.camel@primekey.com> Message-ID: <91102AF2-A1D4-43F6-86BA-E2EFD427EB15@carillon.ca> Hi Marcus, Try giving -CAfile a concatenated file with both CA certificates inside. hulk:/tmp $ cat DSS* > chain.pem hulk:/tmp $ openssl ts -verify -in /tmp/out10.tsp -queryfile /tmp/out10.tsq -CAfile chain.pem Verification: OK Cheers, -Dave > On Nov 14, 2017, at 02:30, Marcus Lundblad wrote: > > Hi! > > I'm trying to verify a timestamp that was signed using a signer > certificate that has been issued by an intermediate CA. > I'm only able to verify when specifying the intermediate CA certificate > as "-untrusted" and the root CA cert as "-CAfile": > > openssl ts -verify -in /tmp/out10.tsp -queryfile /tmp/out10.tsq -CAfile > res/test/dss10/DSSRootCA10.cacert.pem -untrusted > res/test/dss10/DSSSubCA11.cacert.pem > Using configuration from /usr/lib/ssl/openssl.cnf > Verification: OK > > When running with just -CAfile pointing to the intermediate CA cert, I > get: > > Using configuration from /usr/lib/ssl/openssl.cnf > Verification: FAILED > 140693337339136:error:2F06D064:time stamp > routines:ts_verify_cert:certificate verify > error:../crypto/ts/ts_rsp_verify.c:182:Verify error:unable to get > issuer certificate > > And if setting -CAfile to point to the root CA cert: > > Using configuration from /usr/lib/ssl/openssl.cnf > Verification: FAILED > 140228374308096:error:2F06D064:time stamp > routines:ts_verify_cert:certificate verify > error:../crypto/ts/ts_rsp_verify.c:182:Verify error:unable to get local > issuer certificate > > I'm thinking both these variants should have worked (the timestamp > response is including the complete chain in the ESSCertID structure). > > Attached are the CA certs, the signer cert (ts00003.pem), the query > (out10.tsq), and the response (out10.tsp) > > Regards, > Marcus Lundblad-- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From janjust at nikhef.nl Tue Nov 14 14:44:39 2017 From: janjust at nikhef.nl (Jan Just Keijser) Date: Tue, 14 Nov 2017 15:44:39 +0100 Subject: [openssl-users] Building OpenSSL for Intel Xeon Phi In-Reply-To: <20171114.102511.1953468690468288699.levitte@openssl.org> References: <1510585954413-0.post@n7.nabble.com> <20171114.102511.1953468690468288699.levitte@openssl.org> Message-ID: <5A0B0157.4020704@nikhef.nl> Hi, On 14/11/17 10:25, Richard Levitte wrote: > From the look of that PNG, you're building in a native Windows > environment. The ony configs available in the main source are for > Visual C, and are configured like this: > > perl Configure --prefix=D:\openssl\bin shared VC-WIN64A > > If you meant to cross compile for a Linux, I do not have an answer for > you. In that case, it would probably be better if you could build > directly on the intended box. > good catch - but that is an issue that is hard to overcome with the (almost obsolete) Xeon Phi COprocessors. Normally you'd build a cross-compile for the Phi on the host system using the Intel C/C++ compiler, by adding a flag "-mmic" (or /mmic) to the CFLAGS variable. On Linux, this is easy to do - I have built several versions of OpenSSL for the KNC Xeon Phi. For Windows, however, you are stuck between an OpenSSL environment which only supports VC and an Intel/Xeon Phi environment which insists that you use ICC with the flag "-mmic" . The question asked by the original poster is better answered on the Intel MIC developer forum. cheers, JJK / Jan Just Keijser > In message <1510585954413-0.post at n7.nabble.com> on Mon, 13 Nov 2017 08:12:34 -0700 (MST), Miguel_Diaz said: > > doroshenkoay> Hi, > doroshenkoay> I try build OpenSSl for Intel Xeon Phi coprocessor. > doroshenkoay> So far as I understand this problem reduced to building OpenSSL for > doroshenkoay> "linux-generic64" as target. > doroshenkoay> ( > doroshenkoay> https://software.intel.com/sites/default/files/article/373907/intel-r-xeon-phi-tm-cluster-configuration_1.pdf > doroshenkoay> > doroshenkoay> ) > doroshenkoay> I use next string for configure: > doroshenkoay> > doroshenkoay> /perl ./Configure --prefix=D:\openssl\bin shared linux-generic64/ > doroshenkoay> > doroshenkoay> configure.png > doroshenkoay> but makefile not change. > doroshenkoay> > doroshenkoay> Please, help me build OpenSSL for Intel Xeon Phi. > doroshenkoay> > doroshenkoay> Thanks! > doroshenkoay> > doroshenkoay> > doroshenkoay> > doroshenkoay> -- > doroshenkoay> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > doroshenkoay> From gupta_nvn at yahoo.com Tue Nov 14 16:15:24 2017 From: gupta_nvn at yahoo.com (naveen gupta) Date: Tue, 14 Nov 2017 16:15:24 +0000 (UTC) Subject: [openssl-users] Compiling OpenSSL 1.0.2l static library with FIPS -2.0.16 on Windows In-Reply-To: <1224258743.7059750.1509395817353@mail.yahoo.com> References: <1224258743.7059750.1509395817353.ref@mail.yahoo.com> <1224258743.7059750.1509395817353@mail.yahoo.com> Message-ID: <10636867.1779132.1510676124691@mail.yahoo.com> FYI, I came up with following manual solution to correctly build 1.0.2l static library with FIPS - 2.0.16 on Windows, using Visual Studio 2015. This seems towork, and I no longer need to carry run time DLLs along with the application. I feel this should be an acceptable solution. Does anyone see any problems with editing the switch from /MD to /MT in the generated Makefiles? ? -?????????FIPS module: o? ?Set VS environment on the Windows terminal, and change directory to? to unarchived FIPS module directory. o?? SETMFILE=nt.mak o?? SETTARGET=VC-WIN64A o?? SETASM=nasm o?? perlConfigure %TARGET% fipscheck o?? perlutil\mkfiles.pl >MINFO o?? perlutil\mk1mf.pl %ASM% %TARGET% >ms\%MFILE% o?? editnt.mak to link static runtime library libcmt.lib to the executables that itgenerates. ? -EX_LIBS=ws2_32.libgdi32.lib advapi32.lib crypt32.lib user32.lib +EX_LIBS=ws2_32.libgdi32.lib advapi32.lib crypt32.lib user32.lib libcmt.lib ? o?? nmake-f ms\%MFILE% clean o?? nmake-f ms\%MFILE% o?? nmake-f ms\%MFILE% install ? -?????????OpenSSL ? o?? perlConfigure?????? VC-WIN64A no-shared zlib no-ideano-mdc2 no-rc5 no-ssl2 no-ssl3 o?? editms\nt.mak ? -CFLAG= /MD /Ox /O2 /Ob2 -DZLIB-DOPENSSL_THREADS? -DDSO_WIN32 -W3 -Gs0 ??????. +CFLAG= /MT /Ox /O2 /Ob2 -DZLIB-DOPENSSL_THREADS? -DDSO_WIN32 -W3 -Gs0 ??????. o?? ??nmake-f ms\nt.mak all ? -? ? ? ? ? Follow additional linking step 5.3.2 describedin the document?https://www.openssl.org/docs/fips/UserGuide-2.0.pdf, page #74 in the final executable.?? Thanks,Naveen On Monday, October 30, 2017 3:37 PM, naveen gupta via openssl-users wrote: 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??-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From gupta_nvn at yahoo.com Tue Nov 14 16:15:24 2017 From: gupta_nvn at yahoo.com (naveen gupta) Date: Tue, 14 Nov 2017 16:15:24 +0000 (UTC) Subject: [openssl-users] Compiling OpenSSL 1.0.2l static library with FIPS -2.0.16 on Windows In-Reply-To: <1224258743.7059750.1509395817353@mail.yahoo.com> References: <1224258743.7059750.1509395817353.ref@mail.yahoo.com> <1224258743.7059750.1509395817353@mail.yahoo.com> Message-ID: <10636867.1779132.1510676124691@mail.yahoo.com> FYI, I came up with following manual solution to correctly build 1.0.2l static library with FIPS - 2.0.16 on Windows, using Visual Studio 2015. This seems towork, and I no longer need to carry run time DLLs along with the application. I feel this should be an acceptable solution. Does anyone see any problems with editing the switch from /MD to /MT in the generated Makefiles? ? -?????????FIPS module: o? ?Set VS environment on the Windows terminal, and change directory to? to unarchived FIPS module directory. o?? SETMFILE=nt.mak o?? SETTARGET=VC-WIN64A o?? SETASM=nasm o?? perlConfigure %TARGET% fipscheck o?? perlutil\mkfiles.pl >MINFO o?? perlutil\mk1mf.pl %ASM% %TARGET% >ms\%MFILE% o?? editnt.mak to link static runtime library libcmt.lib to the executables that itgenerates. ? -EX_LIBS=ws2_32.libgdi32.lib advapi32.lib crypt32.lib user32.lib +EX_LIBS=ws2_32.libgdi32.lib advapi32.lib crypt32.lib user32.lib libcmt.lib ? o?? nmake-f ms\%MFILE% clean o?? nmake-f ms\%MFILE% o?? nmake-f ms\%MFILE% install ? -?????????OpenSSL ? o?? perlConfigure?????? VC-WIN64A no-shared zlib no-ideano-mdc2 no-rc5 no-ssl2 no-ssl3 o?? editms\nt.mak ? -CFLAG= /MD /Ox /O2 /Ob2 -DZLIB-DOPENSSL_THREADS? -DDSO_WIN32 -W3 -Gs0 ??????. +CFLAG= /MT /Ox /O2 /Ob2 -DZLIB-DOPENSSL_THREADS? -DDSO_WIN32 -W3 -Gs0 ??????. o?? ??nmake-f ms\nt.mak all ? -? ? ? ? ? Follow additional linking step 5.3.2 describedin the document?https://www.openssl.org/docs/fips/UserGuide-2.0.pdf, page #74 in the final executable.?? Thanks,Naveen On Monday, October 30, 2017 3:37 PM, naveen gupta via openssl-users wrote: 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??-- 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 Nov 14 17:14:33 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Nov 2017 17:14:33 +0000 Subject: [openssl-users] Deactivation of client renegotiation particularily in OpenSSL 1.1.0 In-Reply-To: References: Message-ID: <305dfcfd-ddba-a990-1651-178ca2223960@openssl.org> On 14/11/17 09:40, Marcus.Schafheutle at gmx.de wrote: > Hello, > ? > I am referring to the DoS via repeated SSL session renegotiations > (http://kalilinuxtutorials.com/thc-ssl-dos/). > ? > Prior to OpenSSL 1.1.0 the approach to deactivate client renegotiation > was to set the corresponding flag via a > callback function, e.g. : > --- > SSL *connection; > ... > connection->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS; > --- > ? > The problem now is, that this approach does not work for?OpenSSL 1.1.0, > because the "flags" are not accessible any longer. > It also seems that there is no *_set_flags() function for deactivating > client renegotiation. Yes, you're right this doesn't work any more. There is no way to do this in 1.1.0. Arguably this is a bug in 1.1.0 since we inadvertently removed the capability to do this as part of the opacity changes. Actually in master (1.1.1) the SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS functionality has been removed because it wasn't being used by anything. That may have been a mistake. > 1) How can the client-renegotiation in OpenSSL generally be deactivated, > preferably without accessing internal data structures as in the approach > above? The only way we can solve this is by adding a new API. Generally those are backported to stable releases. However if people agree this is a bug as a result of the opacity changes then we should still be able to do it. > 2) Is it possible in OpenSSL 1.1.0 to access attributes like "flags" > above? It seems that there is no dedicated API function for that. No - and I don't think we would want to do that anyway. The "flags" really are an internal thing that you shouldn't be directly modifying (even though that was the only API we provided for doing this in 1.0.2). I opened a github issue for this: https://github.com/openssl/openssl/issues/4739 Matt From openssl-users at dukhovni.org Tue Nov 14 17:37:23 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 14 Nov 2017 12:37:23 -0500 Subject: [openssl-users] Verifying a timestamp signed using a cert issued by a sub CA (intermediate) In-Reply-To: <1510644613.21909.12.camel@primekey.com> References: <1510644613.21909.12.camel@primekey.com> Message-ID: <3B4AAD1A-3302-4CFB-A8E9-F637E24D0E8C@dukhovni.org> > On Nov 14, 2017, at 2:30 AM, Marcus Lundblad wrote: > > I'm trying to verify a timestamp that was signed using a signer > certificate that has been issued by an intermediate CA. > I'm only able to verify when specifying the intermediate CA certificate > as "-untrusted" and the root CA cert as "-CAfile": This means that: * OpenSSL either does not see or does not support the intermediate CA in the peer's message. * The root CA in question is not part of the default trust store. > When running with just -CAfile pointing to the intermediate CA cert, I > get: > > Using configuration from /usr/lib/ssl/openssl.cnf > Verification: FAILED > 140693337339136:error:2F06D064:time stamp > routines:ts_verify_cert:certificate verify > error:../crypto/ts/ts_rsp_verify.c:182:Verify error:unable to get > issuer certificate For validation based on just the intermediate CA, you'd need to enable "partial chains", which are supported in the 1.1.0 "ts" command via the "-partial_chain" option: https://www.openssl.org/docs/man1.1.0/apps/ts.html > And if setting -CAfile to point to the root CA cert: > > Using configuration from /usr/lib/ssl/openssl.cnf > Verification: FAILED > 140228374308096:error:2F06D064:time stamp > routines:ts_verify_cert:certificate verify > error:../crypto/ts/ts_rsp_verify.c:182:Verify error:unable to get local > issuer certificate Looking at the TS code in OpenSSL, it seems that the peer's chain is not used in the way one might expect (to help construct the untrusted portion of the chain). Rather, surprisingly, it looks like the peer's certificates appear to be used as a "constraint" on the constructed chain, and verification fails some chain element was not provided by the peer. I don't know why this is done. -- Viktor. From doroshenkoay at bk.ru Tue Nov 14 17:56:07 2017 From: doroshenkoay at bk.ru (Miguel_Diaz) Date: Tue, 14 Nov 2017 10:56:07 -0700 (MST) Subject: [openssl-users] Building OpenSSL for Intel Xeon Phi In-Reply-To: <5A0B0157.4020704@nikhef.nl> References: <1510585954413-0.post@n7.nabble.com> <20171114.102511.1953468690468288699.levitte@openssl.org> <5A0B0157.4020704@nikhef.nl> Message-ID: <1510682167104-0.post@n7.nabble.com> Thank for your answer, it is very helpful: I build OpenSSL with a Linux installed on the virtual box. I think it's much easier than looking for solutions on a Windows. best regards, Alexander. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From rsalz at akamai.com Tue Nov 14 23:10:09 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 14 Nov 2017 23:10:09 +0000 Subject: [openssl-users] Compiling OpenSSL 1.0.2l static library with FIPS -2.0.16 on Windows In-Reply-To: <10636867.1779132.1510676124691@mail.yahoo.com> References: <1224258743.7059750.1509395817353.ref@mail.yahoo.com> <1224258743.7059750.1509395817353@mail.yahoo.com> <10636867.1779132.1510676124691@mail.yahoo.com> Message-ID: <3C12AEE7-B15B-4728-9329-778DD3D1029D@akamai.com> * FYI, I came up with following manual solution to correctly build 1.0.2l static library with FIPS - 2.0.16 on Windows, using Visual Studio 2015. This seems to work, and I no longer need to carry run time DLLs along with the application. I feel this should be an acceptable solution. Does anyone see any problems with editing the switch from /MD to /MT in the generated Makefiles? If you edit the makefiles, then you are no longer officially FIPS validated. See https://docs/fipsnotes.html This may not be a problem for you, but you should know this info. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Wed Nov 15 06:08:01 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Wed, 15 Nov 2017 11:38:01 +0530 Subject: [openssl-users] Supported cipher suites Message-ID: Hi All, Do we have the exact list of cipher suites supported by default in openssl for each of the below in 1.1.0g version of openSSL. TLS 1.0 TLS 1.1 TLS 1.2 DTLS 1.0 DTLS 1.2 Thanks, Grace -------------- next part -------------- An HTML attachment was scrubbed... URL: From hokusai at gmx.ch Wed Nov 15 08:37:26 2017 From: hokusai at gmx.ch (hokusai at gmx.ch) Date: Wed, 15 Nov 2017 09:37:26 +0100 Subject: [openssl-users] Loading RSA private key from ENGINE Message-ID: An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Nov 15 09:33:06 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 15 Nov 2017 09:33:06 +0000 Subject: [openssl-users] Supported cipher suites In-Reply-To: References: Message-ID: On 15/11/17 06:08, Grace Priscilla Jero wrote: > Hi All, > Do we have the exact list of cipher suites supported by default in > openssl for each of the below in 1.1.0g version of openSSL. > > TLS 1.0 > TLS 1.1 > TLS 1.2 > DTLS 1.0 > DTLS 1.2 You can use the command line "ciphers" command for this information, i.e. $ openssl ciphers -s -v -tls1 $ openssl ciphers -s -v -tls1_1 $ openssl ciphers -s -v -tls1_2 DTLS1.0 is the same list as for TLS1.1 and DTLS1.2 is the same as for TLS1.2. Matt From ossl at mts.cz Wed Nov 15 12:26:20 2017 From: ossl at mts.cz (Libor Chocholaty) Date: Wed, 15 Nov 2017 13:26:20 +0100 Subject: [openssl-users] How to parse DER encoded x509 attributes? Message-ID: Hello, I would like to parse DER encoded x509 attributes and have no clue how to use d2i_ASN1_SET_OF_X509_ATTRIBUTE. There are params that cannot find what to pass like free_func. I am trying to uderstand by collecting pieces of known code, looking into openssl sources but... PKCS7_SIGNER_INFO *p7si = PKCS7_SIGNER_INFO_new(); d2i_ASN1_SET_OF_X509_ATTRIBUTE(&p7si->auth_attr, &der_data, der_data_length, d2i_X509_ATTRIBUTE, free_func, V_ASN1_SET, V_ASN1_UNIVERSAL); Could somebody help how to do it or give a link to some useful documentation? Search internet looks completely not useful in this topic... or do not know how to ask... Regards, Libor -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcoombs at carillon.ca Wed Nov 15 14:31:29 2017 From: dcoombs at carillon.ca (Dave Coombs) Date: Wed, 15 Nov 2017 09:31:29 -0500 Subject: [openssl-users] How to parse DER encoded x509 attributes? In-Reply-To: References: Message-ID: <598F6614-E52C-4CA8-9C6E-88F518E7EAE8@carillon.ca> Hello, You can do something like the following. First make a type corresponding to a stack of x509 attributes: typedef STACK_OF(X509_ATTRIBUTE) SEQ_X509_ATTRIBUTE; DECLARE_ASN1_FUNCTIONS(SEQ_X509_ATTRIBUTE); Then make an asn1 template that specifies how the stack should be encoded. (You can use ASN1_TFLG_SET_OF instead of ..SEQUENCE_OF here, depending on the DER you're trying to interpret, I don't know.) ASN1_ITEM_TEMPLATE(SEQ_X509_ATTRIBUTE) = ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, x509attribute, X509_ATTRIBUTE) ASN1_ITEM_TEMPLATE_END(SEQ_X509_ATTRIBUTE) IMPLEMENT_ASN1_FUNCTIONS(SEQ_X509_ATTRIBUTE) Now your type has its own d2i and i2d functions, and you can use them: STACK_OF(X509_ATTRIBUTE) *attrs = d2i_SEQ_X509_ATTRIBUTE(NULL, &data, length); Cheers, -Dave > On Nov 15, 2017, at 07:26, Libor Chocholaty wrote: > > Hello, > > I would like to parse DER encoded x509 attributes and have no clue how to use d2i_ASN1_SET_OF_X509_ATTRIBUTE. There are params that cannot find what to pass like free_func. > > I am trying to uderstand by collecting pieces of known code, looking into openssl sources but... > > PKCS7_SIGNER_INFO *p7si = PKCS7_SIGNER_INFO_new(); > d2i_ASN1_SET_OF_X509_ATTRIBUTE(&p7si->auth_attr, &der_data, der_data_length, d2i_X509_ATTRIBUTE, free_func, V_ASN1_SET, V_ASN1_UNIVERSAL); > > Could somebody help how to do it or give a link to some useful documentation? > Search internet looks completely not useful in this topic... or do not know how to ask... > > Regards, > Libor > > > -- > 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 Wed Nov 15 14:42:12 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Wed, 15 Nov 2017 20:12:12 +0530 Subject: [openssl-users] Supported cipher suites In-Reply-To: References: Message-ID: Thankyou Matt. Some of them that we tried does not work. Is there any additional criteria for it to work. I read about some PSK ciphers which I am not sure depends on something else. Thanks, Grace On Wed, Nov 15, 2017 at 3:03 PM, Matt Caswell wrote: > > > On 15/11/17 06:08, Grace Priscilla Jero wrote: > > Hi All, > > Do we have the exact list of cipher suites supported by default in > > openssl for each of the below in 1.1.0g version of openSSL. > > > > TLS 1.0 > > TLS 1.1 > > TLS 1.2 > > DTLS 1.0 > > DTLS 1.2 > > You can use the command line "ciphers" command for this information, i.e. > > $ openssl ciphers -s -v -tls1 > $ openssl ciphers -s -v -tls1_1 > $ openssl ciphers -s -v -tls1_2 > > DTLS1.0 is the same list as for TLS1.1 and DTLS1.2 is the same as for > TLS1.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 grace.priscilla at gmail.com Thu Nov 16 06:51:16 2017 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Thu, 16 Nov 2017 12:21:16 +0530 Subject: [openssl-users] Supported cipher suites In-Reply-To: References: Message-ID: Hi, How to check the default ciphers? We are not setting any ciphers in our code. Below is the configuration output. CC =gcc CFLAG =-Wall -O3 -pthread -m64 -DL_ENDIAN -udp -Wa,--noexecstack SHARED_CFLAG =-fPIC -DOPENSSL_USE_NODELETE DEFINES =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM LFLAG = PLIB_LFLAG = EX_LIBS =-ldl APPS_OBJ = CPUID_OBJ =x86_64cpuid.o UPLINK_OBJ = BN_ASM =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM =md5-x86_64.o SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o RMD160_OBJ_ASM= CMLL_ENC =cmll-x86_64.o cmll_misc.o MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o PADLOCK_OBJ =e_padlock-x86_64.o CHACHA_ENC =chacha-x86_64.o POLY1305_OBJ =poly1305-x86_64.o BLAKE2_OBJ = PROCESSOR = RANLIB =ranlib ARFLAGS = PERL =/usr/bin/perl Thanks, Grace On Wed, Nov 15, 2017 at 8:12 PM, Grace Priscilla Jero < grace.priscilla at gmail.com> wrote: > Thankyou Matt. > Some of them that we tried does not work. Is there any additional criteria > for it to work. > I read about some PSK ciphers which I am not sure depends on something > else. > > Thanks, > Grace > > On Wed, Nov 15, 2017 at 3:03 PM, Matt Caswell wrote: > >> >> >> On 15/11/17 06:08, Grace Priscilla Jero wrote: >> > Hi All, >> > Do we have the exact list of cipher suites supported by default in >> > openssl for each of the below in 1.1.0g version of openSSL. >> > >> > TLS 1.0 >> > TLS 1.1 >> > TLS 1.2 >> > DTLS 1.0 >> > DTLS 1.2 >> >> You can use the command line "ciphers" command for this information, i.e. >> >> $ openssl ciphers -s -v -tls1 >> $ openssl ciphers -s -v -tls1_1 >> $ openssl ciphers -s -v -tls1_2 >> >> DTLS1.0 is the same list as for TLS1.1 and DTLS1.2 is the same as for >> TLS1.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 openssl-users at dukhovni.org Thu Nov 16 07:00:04 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 16 Nov 2017 02:00:04 -0500 Subject: [openssl-users] Supported cipher suites In-Reply-To: References: Message-ID: <02A9B8A4-5545-444B-AEC2-789E14C77F36@dukhovni.org> > On Nov 16, 2017, at 1:51 AM, Grace Priscilla Jero wrote: > > How to check the default ciphers? We are not setting any ciphers in our code. What specifically are you looking for? The cipherlist sent to the server depends in part on which protocols are enabled in the client, and as of OpenSSL 1.1.0 also on the "security level" (default 1). PSK and SRP ciphers require an application callback to provide shared secrets and so are not used in most applications. The "openssl ciphers" command (see the manpage) lists the ciphers that match either the DEFAULT or some explicit cipher string. With OpenSSL 1.1.0 you can specify a TLS protocol versions and see only the ciphers compatible with that protocol version. In the upcoming TLS 1.3 the ciphers are completely different from previous versions, and configuration via cipher strings was not implemented last I looked. This may have changed... -- Viktor. From matt at openssl.org Thu Nov 16 10:16:07 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 16 Nov 2017 10:16:07 +0000 Subject: [openssl-users] Supported cipher suites In-Reply-To: <02A9B8A4-5545-444B-AEC2-789E14C77F36@dukhovni.org> References: <02A9B8A4-5545-444B-AEC2-789E14C77F36@dukhovni.org> Message-ID: <57b5452f-09db-b434-56a0-bd19a307ace2@openssl.org> On 16/11/17 07:00, Viktor Dukhovni wrote: > In the upcoming TLS 1.3 the ciphers are completely different from > previous versions, and configuration via cipher strings was not > implemented last I looked. This may have changed... You have always been able to configure the TLSv1.3 ciphers via cipher strings. Matt From nacao2001 at hotmail.com Thu Nov 16 11:18:42 2017 From: nacao2001 at hotmail.com (Ignacio Alamo Corsino) Date: Thu, 16 Nov 2017 11:18:42 +0000 Subject: [openssl-users] Loading RSA private key from ENGINE In-Reply-To: References: Message-ID: Hello Fabrizio, actually the whole private key and all its components are not loaded with ENGINE_load_private_key. Only a part of them (modulus and public exponent). These components are enough to, for example, make a key/certificate match verification. Once a private key operation is needed (ex. signature) then your custom RSA method will be called because the key that you have previously loaded is not able to perform that kind of operations. Depending on how you have written your method, one function or another will be called (rsa_sign or RSA_private_encrypt). If you have loaded your engine correctly, the SSL methods will know when to call your rsa methods to perform their operations. Regards, Ignacio ________________________________ De: openssl-users en nombre de hokusai at gmx.ch Enviado: mi?rcoles, 15 de noviembre de 2017 9:37 Para: openssl-users at openssl.org Asunto: [openssl-users] Loading RSA private key from ENGINE I am currently exporing the ENGINE capabilities. The examples are quite clear about how to link OpenSSL with methods that are available in a hardware module: - implement RSA_METHOD in MyEngine, e.g. rsaSign() wich calls rsaSign_HW() - ENGINE_register_RSA(MyEngine) --> OpenSSL will then automatically call that method when rsa signing is required. So far, so good. The gap in my understanding is how to access the private key. Assumimg that my hardware module contains a list of private keys, which cannot and shall not be exported, they will be referenced by some opaque reference or id, e.g "KEY_1" rsaSign_HW(dataToSign,"KEY_1") Now I need some way to configure SSL_CTX with "KEY_1" instead of the "real" key. I'm thinking of some pseudo-code in the way: SSL_CTX_use_certificate(ctx, cert) // certificate from PEM file as usual SSL_CTX_use_PrivateKeyReferenceForEngine(ctx, "KEY_1") Also there is a engine interface that looks promising, as takes some arbitrary keyId as parameter.... privKey = ENGINE_load_private_key(MyEngine, "KEY_1") .. but as far as I understand, it returns the "real" key, which is not exportable. Am I completety on the wrong track? What is the recommended technique? Thanks for any suggestion Fabrizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Nov 16 13:28:09 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 16 Nov 2017 13:28:09 +0000 Subject: [openssl-users] Supported cipher suites In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Grace Priscilla Jero > Sent: Wednesday, November 15, 2017 09:42 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Supported cipher suites > Some of them that we tried does not work. Is there any additional criteria for it to work. > I read about some PSK ciphers which I am not sure depends on something else. PSK stands for "Pre-Shared Key", because the PSK suites require sharing a key before you can use them. Trying to test suites without knowing what they are is a bad idea. Why are you trying to do that? Would you operate a machine without knowing what it does? If you really want to test *all* the supported suites, I would suggest you first acquire an in-depth knowlege of TLS, perhaps by reading the books by Eric Rescorla and Ivan Ristic; then read through the specifications for each of the suites you want to test; study background material on the algorithms and protocols they use as necessary. Then familiarize yourself with the relevant parts of OpenSSL by reading the OpenSSL documentation and wiki. Then you'll be in a good position to try all the suites. You'll also know more about TLS than all but a handful of people, which ought to be good for your career prospects. The downside is that it would likely take months of intense study, even for a fast learner with the requisite technical background. So perhaps a better option is not trying to test the obscure suites. -- Michael Wojcik Distinguished Engineer, Micro Focus From angus at magsys.co.uk Thu Nov 16 17:59:00 2017 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Thu, 16 Nov 2017 17:59 +0000 (GMT Standard Time) Subject: [openssl-users] Upgrading to 1.1.1 Message-ID: I'm updating our Delphi SSL code to support 1.1.1 in addition to 1.0.2 and 1.1.0, common code with a few version checks. This is using Windows 10. With 1.1.1, SSL connections fail to initialise, failing with the first BIO_read after setting up the context and BIOs. There is no real error (I can see), read just fails and BIO_should_retry says no with a zero reason. We are using SSL filter I/O with a BIO pair, we handle all I/O using non-blocking Windows APIs. There was no particular issue updating to 1.1.0, apart from new context stuff, but 1.1.1 seems to have changed something to make our code fail. I can not see anything in the TLS/1.3 notes that relates to simple SSL initialisation. The main APIs called are, in order: SSL_new(myContext) BIO_new(BIO_f_ssl) BIO_new_bio_pair SSL_set_ex_data SSL_set_session SSL_set_tlsext_host_name SSL_set_connect_state SSL_set_bio SSL_set_info_callback SSL_set_msg_callback BIO_set_ssl BIO_read - 0 bytes which is where it dies, after a SSL_CB_HANDSHAKE_START info message and a 512 byte write client hello. The openssl.exe built with 1.1.1 seems to work OK making a client connection, but uses different BIO I/O. Is some new initialisation required for 1.1.1? Angus From jb-openssl at wisemo.com Thu Nov 16 23:30:28 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 17 Nov 2017 00:30:28 +0100 Subject: [openssl-users] How do I run the OpenSSL library self-tests on embedded platforms Message-ID: <01a63431-1e54-b480-aff3-3ba33682afa9@wisemo.com> (This is for the regular OpenSSL 1.0.2, not 1.1.x): As I build OpenSSL for various embedded or semi-embedded (mobile) platforms, I have run into the basic issue of how to run the equivalent of "make test" when the code is compiled for an embedded platform that is neither self-hosting (so make, compilers etc. are not available on the target), nor inherently command line oriented. The only thing I can find in the included docs (so far) is that a special procedure was created for Windows CE (which I also target), but I find no instructions for other embedded/mobile targets such as iOS and bare hardware. For example is there a known-good way to compile the test scripts into one or more functions that can be called from a platform-specific test program without relying on the availability of such POSIXly things as stdout, terminals, shells etc.? (CE does have such things, and those are used in the CE procedure). Regression testing is desired as I have done some fairly extensive patching to make the library code build for the targets. 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 mahesh116 at gmail.com Fri Nov 17 06:42:13 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Fri, 17 Nov 2017 12:12:13 +0530 Subject: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application In-Reply-To: <7a4b067c-ce3a-29dd-d05c-0caf045479eb@openssl.org> References: <4976CBFA-17F5-4BDB-AEE0-212BBD6B28A2@sharp.fm> <7a4b067c-ce3a-29dd-d05c-0caf045479eb@openssl.org> Message-ID: Hi Matt, Thanks for the response, I added a log as suggested by you. I don't see the call entering the above mentioned code block. Logs on server side: [10/15/0117 10:34:43] 803F1700 Link-2 (SSL_accept) Failed to accept new connection, Socket Id 65, Return Value 1 [10/15/0117 10:34:43] 803F1700 Link-2 SSL File : ssl/statem/statem_srvr.c , Line number : 2882 , Linux Error Code 0 Logs on client side: [10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true [10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true [10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true [10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true [10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true [10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true We observe from wireshark capture, client sending out the certificate with length = 0 (because we have not configured the public key on client side) and also server sends handshake failure "Alert" to client. Why does client respond with "Client key exchange" even if the the handshake failure alert is sent from server? Openssl version used is 01.01.00g. I am also attaching the latest pcap file for your reference. On Tue, Nov 14, 2017 at 4:35 PM, Matt Caswell wrote: > > > On 14/11/17 10:44, mahesh gs wrote: > > > case SSL_ERROR_SYSCALL: > > > > if (EWOULDBLOCK == errno || EAGAIN == errno) > > { > > /* Nothing to do, retry to connect again */ > > } > > This doesn't look right. If SSL_connect() fails due to an NBIO event > then you should get SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE back. If > you get SSL_ERROR_SYSCALL then something bad happened and you should not > retry. Could you add some logging here? I'm wondering whether you are > ending up here but missing it and looping around again. > > Matt > > > -- > 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: 4.pcap Type: application/octet-stream Size: 13929 bytes Desc: not available URL: From levitte at openssl.org Fri Nov 17 10:04:28 2017 From: levitte at openssl.org (Richard Levitte) Date: Fri, 17 Nov 2017 11:04:28 +0100 (CET) Subject: [openssl-users] Upgrading to 1.1.1 In-Reply-To: References: Message-ID: <20171117.110428.1042733037321900639.levitte@openssl.org> In message on Thu, 16 Nov 2017 17:59 +0000 (GMT Standard Time), "Angus Robertson - Magenta Systems Ltd" said: angus> I'm updating our Delphi SSL code to support 1.1.1 in addition to 1.0.2 angus> and 1.1.0, common code with a few version checks. This is using Windows angus> 10. angus> angus> With 1.1.1, SSL connections fail to initialise, failing with the first angus> BIO_read after setting up the context and BIOs. There is no real error angus> (I can see), read just fails and BIO_should_retry says no with a zero angus> reason. angus> angus> We are using SSL filter I/O with a BIO pair, we handle all I/O using angus> non-blocking Windows APIs. angus> angus> There was no particular issue updating to 1.1.0, apart from new context angus> stuff, but 1.1.1 seems to have changed something to make our code fail. angus> I can not see anything in the TLS/1.3 notes that relates to simple SSL angus> initialisation. angus> angus> The main APIs called are, in order: angus> angus> SSL_new(myContext) angus> BIO_new(BIO_f_ssl) angus> BIO_new_bio_pair angus> SSL_set_ex_data angus> SSL_set_session angus> SSL_set_tlsext_host_name angus> SSL_set_connect_state angus> SSL_set_bio angus> SSL_set_info_callback angus> SSL_set_msg_callback angus> BIO_set_ssl angus> BIO_read - 0 bytes angus> angus> which is where it dies, after a SSL_CB_HANDSHAKE_START info message and angus> a 512 byte write client hello. angus> angus> The openssl.exe built with 1.1.1 seems to work OK making a client angus> connection, but uses different BIO I/O. angus> angus> Is some new initialisation required for 1.1.1? Doesn't one of the test programs in test/ do something similar? Another option is if you could craft a simple program that demonstrates the issue, that would certainly help. Lastly, unless you get a quick answer here, this might be worth making a github issue here: https://github.com/openssl/openssl/issues Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Fri Nov 17 10:06:41 2017 From: matt at openssl.org (Matt Caswell) Date: Fri, 17 Nov 2017 10:06:41 +0000 Subject: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application In-Reply-To: References: <4976CBFA-17F5-4BDB-AEE0-212BBD6B28A2@sharp.fm> <7a4b067c-ce3a-29dd-d05c-0caf045479eb@openssl.org> Message-ID: <78f45c84-52fb-86a1-24b2-1b7f94e2328e@openssl.org> On 17/11/17 06:42, mahesh gs wrote: > Why > does client respond with "Client key exchange" even if the the handshake > failure alert is sent from server? The client will send its entire flight of messages before it attempts to read anything from the server. So, in this case, the ClientKeyExchange message is still sent because the client hasn't read the alert yet. Matt From Karyn.Ulriksen at riverbed.com Fri Nov 17 21:23:05 2017 From: Karyn.Ulriksen at riverbed.com (Karyn Ulriksen) Date: Fri, 17 Nov 2017 21:23:05 +0000 Subject: [openssl-users] fips_premain.c multiple definition of main Message-ID: Hi All, I'm trying to cross compile for linux64 on Mips64 with FIPS and OpenSSL. It hasn't been easy! I know that MIPS isn't officially supportive, but we have been getting private validations in the past and plan to revisit that with this upgrade. My current blocking point is that when building the openssl libraries, I'm getting hung up on the build reporting that fips_premain.c has multiple definitions of main. This happens regardless of which combos of MTYPE I declare for my make. I've tried the linux-generic and various mips for linux and irix MTYPES. My build machine info: Linux 4.4.0-98-generic #121-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux My Target machine and toolchain info: gcc version 4.7.0 (Cavium Inc. Version: SDK_BUILD build 45) Linux 3.10.20 #1 SMP mips64 GNU/Linux Openssl versions: openssl-fips 2.0.16 openssl 1.0.1m The specific error on building openssl: /tmp/ccdtHgwu.o: In function `main': fips_premain.c:(.text.startup+0x0): multiple definition of `main' /tmp/cc2MrZWZ.o:fips_premain.c:(.text.startup+0x0): first defined here collect2: error: ld returned 1 exit status -------------- next part -------------- An HTML attachment was scrubbed... URL: From bertlee.gonzaga at gmail.com Sun Nov 19 16:09:08 2017 From: bertlee.gonzaga at gmail.com (Bertlee Gonzaga) Date: Mon, 20 Nov 2017 00:09:08 +0800 Subject: [openssl-users] Problem when using RSA_meth_set_sign and RSA_meth_set_verify Message-ID: Good day! I'm trying to upgrade a driver/engine for an old hardware to OpenSSL 1.1.0.f. However, I am encountering below compilation error. Need some advise if do I really need to set the struct rsa_st parameter declared as const in my function. I noticed that the RSA *rsa parameter on other RSA_meth_set functions was not declared as const. hw_cavium.c:3688:35: warning: passing argument 2 of ?RSA_meth_set_sign? from incompatible pointer type [-Wincompatible-pointer-types] RSA_meth_set_sign(cavium_rsa, cav_rsa_sign); ^~~~~~~~~~~~ In file included from /usr/local/Cavium_Networks/NITROX-SDK/apps/Turbo_SSL/openssl-1.1.0f/include/openssl/engine.h:24:0, from hw_cavium.c:59: /usr/local/Cavium_Networks/NITROX-SDK/apps/Turbo_SSL/openssl-1.1.0f/include/openssl/rsa.h:433:5: note: expected ?int (*)(int, const unsigned char *, unsigned int, unsigned char *, unsigned int *, const RSA *) {aka int (*)(int, const unsigned char *, unsigned int, unsigned char *, unsigned int *, const struct rsa_st *)}? but argument is of type ?int (*)(int, const unsigned char *, unsigned int, unsigned char *, unsigned int *, RSA *) {aka int (*)(int, const unsigned char *, unsigned int, unsigned char *, unsigned int *, struct rsa_st *)}? int RSA_meth_set_sign(RSA_METHOD *rsa, ^~~~~~~~~~~~~~~~~ hw_cavium.c:3689:37: warning: passing argument 2 of ?RSA_meth_set_verify? from incompatible pointer type [-Wincompatible-pointer-types] RSA_meth_set_verify(cavium_rsa, cav_rsa_verify); ^~~~~~~~~~~~~~ In file included from /usr/local/Cavium_Networks/NITROX-SDK/apps/Turbo_SSL/openssl-1.1.0f/include/openssl/engine.h:24:0, from hw_cavium.c:59: /usr/local/Cavium_Networks/NITROX-SDK/apps/Turbo_SSL/openssl-1.1.0f/include/openssl/rsa.h:442:5: note: expected ?int (*)(int, const unsigned char *, unsigned int, const unsigned char *, unsigned int, const RSA *) {aka int (*)(int, const unsigned char *, unsigned int, const unsigned char *, unsigned int, const struct rsa_st *)}? but argument is of type ?int (*)(int, const unsigned char *, unsigned int, unsigned char *, size_t *, const unsigned char *, size_t, RSA *) {aka int (*)(int, const unsigned char *, unsigned int, unsigned char *, long unsigned int *, const unsigned char *, long unsigned int, struct rsa_st *)}? int RSA_meth_set_verify(RSA_METHOD *rsa, ^~~~~~~~~~~~~~~~~~~ Thanks and best regards, Bertlee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh116 at gmail.com Mon Nov 20 11:12:05 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Mon, 20 Nov 2017 16:42:05 +0530 Subject: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application In-Reply-To: <78f45c84-52fb-86a1-24b2-1b7f94e2328e@openssl.org> References: <4976CBFA-17F5-4BDB-AEE0-212BBD6B28A2@sharp.fm> <7a4b067c-ce3a-29dd-d05c-0caf045479eb@openssl.org> <78f45c84-52fb-86a1-24b2-1b7f94e2328e@openssl.org> Message-ID: Hi Matt, Thanks for the response. We debugged through openssl code to get to know the reason why client is not reading "SSL Alert". Once the "ClientKeyExchange" is sent openssl trying to send out the "ChangeCipherSpec" message which is creating the problem. The pre-work function for "ChangeCipherSpec" enables SCTP dry event and wait for dry event notification. [image: Inline image 1] In this scenario, dry notification is never sent from SCTP. "dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow never enters "read_state_machine" where alert is to be red.This causes SSL_Connect to be in infinite loop. Thanks, Mahesh G S On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell wrote: > > > On 17/11/17 06:42, mahesh gs wrote: > > Why > > does client respond with "Client key exchange" even if the the handshake > > failure alert is sent from server? > > The client will send its entire flight of messages before it attempts to > read anything from the server. So, in this case, the ClientKeyExchange > message is still sent because the client hasn't read the alert yet. > > Matt > > -- > 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: image.png Type: image/png Size: 52144 bytes Desc: not available URL: From ossl at mts.cz Mon Nov 20 14:03:29 2017 From: ossl at mts.cz (Libor Chocholaty) Date: Mon, 20 Nov 2017 15:03:29 +0100 Subject: [openssl-users] How to parse DER encoded x509 attributes? In-Reply-To: <598F6614-E52C-4CA8-9C6E-88F518E7EAE8@carillon.ca> References: <598F6614-E52C-4CA8-9C6E-88F518E7EAE8@carillon.ca> Message-ID: Hello, thanks a lot. Works nice. Just it is interesting that I get X509_ATTRIBUTEs what should be a SEQUENCE but need to parse as SET. And to free the memory: X509_ATTRIBUTE *attr; while ((attr = sk_X509_ATTRIBUTE_pop(attrs)) != NULL) { X509_ATTRIBUTE_free(attr); } sk_X509_ATTRIBUTE_free(attrs); Looks working. Regards, Libor On 2017-11-15 15:31, Dave Coombs wrote: > Hello, > > You can do something like the following. > > First make a type corresponding to a stack of x509 attributes: > > typedef STACK_OF(X509_ATTRIBUTE) SEQ_X509_ATTRIBUTE; > DECLARE_ASN1_FUNCTIONS(SEQ_X509_ATTRIBUTE); > > Then make an asn1 template that specifies how the stack should be encoded. (You can use ASN1_TFLG_SET_OF instead of ..SEQUENCE_OF here, depending on the DER you're trying to interpret, I don't know.) > > ASN1_ITEM_TEMPLATE(SEQ_X509_ATTRIBUTE) = > ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, x509attribute, X509_ATTRIBUTE) > ASN1_ITEM_TEMPLATE_END(SEQ_X509_ATTRIBUTE) > IMPLEMENT_ASN1_FUNCTIONS(SEQ_X509_ATTRIBUTE) > > Now your type has its own d2i and i2d functions, and you can use them: > > STACK_OF(X509_ATTRIBUTE) *attrs = d2i_SEQ_X509_ATTRIBUTE(NULL, &data, length); > > Cheers, > -Dave > >> On Nov 15, 2017, at 07:26, Libor Chocholaty wrote: >> >> Hello, >> >> I would like to parse DER encoded x509 attributes and have no clue how to use d2i_ASN1_SET_OF_X509_ATTRIBUTE. There are params that cannot find what to pass like free_func. >> >> I am trying to uderstand by collecting pieces of known code, looking into openssl sources but... >> >> PKCS7_SIGNER_INFO *p7si = PKCS7_SIGNER_INFO_new(); >> d2i_ASN1_SET_OF_X509_ATTRIBUTE(&p7si->auth_attr, &der_data, der_data_length, d2i_X509_ATTRIBUTE, free_func, V_ASN1_SET, V_ASN1_UNIVERSAL); >> >> Could somebody help how to do it or give a link to some useful documentation? >> Search internet looks completely not useful in this topic... or do not know how to ask... >> >> Regards, >> Libor >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcoombs at carillon.ca Mon Nov 20 14:09:42 2017 From: dcoombs at carillon.ca (Dave Coombs) Date: Mon, 20 Nov 2017 09:09:42 -0500 Subject: [openssl-users] How to parse DER encoded x509 attributes? In-Reply-To: References: <598F6614-E52C-4CA8-9C6E-88F518E7EAE8@carillon.ca> Message-ID: <25096517-2CCF-422F-902E-105F417B02A9@carillon.ca> Hello, As I said, you could experiment with ASN1_TFLG_SET_OF instead of ASN1_TFLG_SEQUENCE_OF. Also, to free the memory, you should be able to use just one call: sk_X509_ATTRIBUTE_pop_free(attrs, X509_ATTRIBUTE_free); This frees each element in the stack, and also frees the stack. All the best, -Dave > On Nov 20, 2017, at 09:03, Libor Chocholaty wrote: > Hello, > > thanks a lot. Works nice. Just it is interesting that I get X509_ATTRIBUTEs what should be a SEQUENCE but need to parse as SET. > > And to free the memory: > > X509_ATTRIBUTE *attr; > while ((attr = sk_X509_ATTRIBUTE_pop(attrs)) != NULL) { > X509_ATTRIBUTE_free(attr); > } > sk_X509_ATTRIBUTE_free(attrs); > > Looks working. > > Regards, > Libor > > > On 2017-11-15 15:31, Dave Coombs wrote: > >> Hello, >> >> You can do something like the following. >> >> First make a type corresponding to a stack of x509 attributes: >> >> typedef STACK_OF(X509_ATTRIBUTE) SEQ_X509_ATTRIBUTE; >> DECLARE_ASN1_FUNCTIONS(SEQ_X509_ATTRIBUTE); >> >> Then make an asn1 template that specifies how the stack should be encoded. (You can use ASN1_TFLG_SET_OF instead of ..SEQUENCE_OF here, depending on the DER you're trying to interpret, I don't know.) >> >> ASN1_ITEM_TEMPLATE(SEQ_X509_ATTRIBUTE) = >> ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, x509attribute, X509_ATTRIBUTE) >> ASN1_ITEM_TEMPLATE_END(SEQ_X509_ATTRIBUTE) >> IMPLEMENT_ASN1_FUNCTIONS(SEQ_X509_ATTRIBUTE) >> >> Now your type has its own d2i and i2d functions, and you can use them: >> >> STACK_OF(X509_ATTRIBUTE) *attrs = d2i_SEQ_X509_ATTRIBUTE(NULL, &data, length); >> >> Cheers, >> -Dave >> >> >>> On Nov 15, 2017, at 07:26, Libor Chocholaty > wrote: >>> Hello, >>> >>> I would like to parse DER encoded x509 attributes and have no clue how to use d2i_ASN1_SET_OF_X509_ATTRIBUTE. There are params that cannot find what to pass like free_func. >>> >>> I am trying to uderstand by collecting pieces of known code, looking into openssl sources but... >>> >>> PKCS7_SIGNER_INFO *p7si = PKCS7_SIGNER_INFO_new(); >>> d2i_ASN1_SET_OF_X509_ATTRIBUTE(&p7si->auth_attr, &der_data, der_data_length, d2i_X509_ATTRIBUTE, free_func, V_ASN1_SET, V_ASN1_UNIVERSAL); >>> >>> Could somebody help how to do it or give a link to some useful documentation? >>> Search internet looks completely not useful in this topic... or do not know how to ask... >>> >>> Regards, >>> Libor >>> >>> >>> -- >>> 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 ncsuandrew12 at gmail.com Mon Nov 20 18:29:36 2017 From: ncsuandrew12 at gmail.com (Andrew Felsher) Date: Mon, 20 Nov 2017 13:29:36 -0500 Subject: [openssl-users] X509_ATTRIBUTE_create_by_NID reversing sequence Message-ID: Hi, I'm working on a CSR-generating API using OpenSSL 1.0.2m. My question is: does OpenSSL do any sort of reordering of the entries in an ASN1 sequence? Specifically, when encoding a postal address X509_ATTRIBUTE. Background: To create a postal address X509_ATTRIBUTE, I'm calling X509_ATTRIBUTE_create_by_NID(NULL, nid, atrtype, data, len). nid is 861 (0x35d) (postal address), atrtype is 16 (ASN1 sequence). My data is the concatenated results of three i2d_ASN1_GENERALSTRING() calls for three strings, resulting in this data: 0000: 1B 11 32 32 31 42 20 42 61 6B 65 72 20 53 74 72 ..221B Baker Str 0010: 65 65 74 1B 06 4C 6F 6E 64 6F 6E 1B 02 55 4B -- eet..London..UK X509_ATTRIBUTE_create_by_NID seems to handle this fine, and various later X509_ATTRIBUTE*() calls work fine. However, when I call i2d_X509_ATTRIBUTE() just after generating the attribute, the three strings seem to be reversed in the output: 0000: 30 26 06 03 55 04 10 31 1F 1B 02 55 4B 1B 06 4C 0&..U..1...UK..L 0010: 6F 6E 64 6F 6E 1B 11 32 32 31 42 20 42 61 6B 65 ondon..221B Bake 0020: 72 20 53 74 72 65 65 74 -- -- -- -- -- -- -- -- r Street Any idea what could be causing that? Thanks, Andrew Felsher -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncsuandrew12 at gmail.com Mon Nov 20 20:03:32 2017 From: ncsuandrew12 at gmail.com (Andrew Felsher) Date: Mon, 20 Nov 2017 15:03:32 -0500 Subject: [openssl-users] X509_ATTRIBUTE_create_by_NID reversing sequence Message-ID: Hi, I'm working on a CSR-generating API using OpenSSL 1.0.2m. My question is: does OpenSSL do any sort of reordering of the entries in an ASN1 sequence? Specifically, when encoding a postal address X509_ATTRIBUTE. Background: To create a postal address X509_ATTRIBUTE, I'm calling X509_ATTRIBUTE_create_by_NID(NULL, nid, atrtype, data, len). nid is 861 (0x35d) (postal address), atrtype is 16 (ASN1 sequence). My data is the concatenated results of three i2d_ASN1_GENERALSTRING() calls for three strings, resulting in this data: 0000: 1B 11 32 32 31 42 20 42 61 6B 65 72 20 53 74 72 ..221B Baker Str 0010: 65 65 74 1B 06 4C 6F 6E 64 6F 6E 1B 02 55 4B -- eet..London..UK X509_ATTRIBUTE_create_by_NID seems to handle this fine, and various later X509_ATTRIBUTE*() calls work fine. However, when I call i2d_X509_ATTRIBUTE() just after generating the attribute, the three strings seem to be reversed in the output: 0000: 30 26 06 03 55 04 10 31 1F 1B 02 55 4B 1B 06 4C 0&..U..1...UK..L 0010: 6F 6E 64 6F 6E 1B 11 32 32 31 42 20 42 61 6B 65 ondon..221B Bake 0020: 72 20 53 74 72 65 65 74 -- -- -- -- -- -- -- -- r Street Any idea what could be causing that? Thanks, Andrew Felsher -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh116 at gmail.com Tue Nov 21 08:53:00 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Tue, 21 Nov 2017 14:23:00 +0530 Subject: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application In-Reply-To: References: <4976CBFA-17F5-4BDB-AEE0-212BBD6B28A2@sharp.fm> <7a4b067c-ce3a-29dd-d05c-0caf045479eb@openssl.org> <78f45c84-52fb-86a1-24b2-1b7f94e2328e@openssl.org> Message-ID: Hi, We were able to further localize this problem and found the problem is with the function "BIO_dgram_sctp_wait_for_dry". In this function after enabling the "sctp_sender_dry_event" we are trying to do MSG_PEEK to peek to the message at SCTP layer, in this case the size of the message waiting in the lower layer is 15 which size is exactly the size of "Handshake Alert" that is received from the server and waiting to be read. Dry event is never read from the lower layer that causes the SUB_STATE_ERROR and intern causes the SSL_Connect to loop in application. Current version of openssl we are using is 01.01.00g. We have tested and able to reproduce this issue with the OPENSSL 01.00.02k version that is packaged with RHEL 7.4 as well. Thanks, Mahesh G S On Mon, Nov 20, 2017 at 4:42 PM, mahesh gs wrote: > Hi Matt, > > Thanks for the response. > > We debugged through openssl code to get to know the reason why client is > not reading "SSL Alert". > > Once the "ClientKeyExchange" is sent openssl trying to send out the > "ChangeCipherSpec" message which is creating the problem. > > The pre-work function for "ChangeCipherSpec" enables SCTP dry event and > wait for dry event notification. > > [image: Inline image 1] > > > In this scenario, dry notification is never sent from SCTP. > "dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow never > enters "read_state_machine" where alert is to be red.This causes > SSL_Connect to be in infinite loop. > > > Thanks, > Mahesh G S > > On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell wrote: > >> >> >> On 17/11/17 06:42, mahesh gs wrote: >> > Why >> > does client respond with "Client key exchange" even if the the handshake >> > failure alert is sent from server? >> >> The client will send its entire flight of messages before it attempts to >> read anything from the server. So, in this case, the ClientKeyExchange >> message is still sent because the client hasn't read the alert yet. >> >> Matt >> >> -- >> 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: image.png Type: image/png Size: 52144 bytes Desc: not available URL: From matt at openssl.org Tue Nov 21 09:56:41 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Nov 2017 09:56:41 +0000 Subject: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application In-Reply-To: References: <4976CBFA-17F5-4BDB-AEE0-212BBD6B28A2@sharp.fm> <7a4b067c-ce3a-29dd-d05c-0caf045479eb@openssl.org> <78f45c84-52fb-86a1-24b2-1b7f94e2328e@openssl.org> Message-ID: <4cc2efe5-d00a-4aed-53b6-6c6e3b9e80e5@openssl.org> Sounds like a bug. Can you raise this as an issue on github? https://github.com/openssl/openssl/issues Thanks Matt On 21/11/17 08:53, mahesh gs wrote: > Hi, > > We were able to further localize this problem and found the problem is > with the function "BIO_dgram_sctp_wait_for_dry". In this function after > enabling the "sctp_sender_dry_event" we are trying to do MSG_PEEK to > peek to the message at SCTP layer, in this case the size of the message > waiting in the lower layer is 15 which size is exactly the size of > "Handshake Alert" that is received from the server and waiting to be > read. Dry event is never read from the lower layer that causes the > SUB_STATE_ERROR and intern causes the SSL_Connect to loop in application. > > Current version of openssl we are using is 01.01.00g. > > We have tested and able to reproduce this issue with the OPENSSL > 01.00.02k version that is packaged with RHEL 7.4 as well. > > > Thanks, > Mahesh G S > > On Mon, Nov 20, 2017 at 4:42 PM, mahesh gs > wrote: > > Hi Matt, > > Thanks for the response. > > We debugged through openssl code to get to know the reason why > client is not reading "SSL Alert". > > Once the "ClientKeyExchange" is sent openssl trying to send out the > "ChangeCipherSpec"? message which is creating the problem.? > > The pre-work function for "ChangeCipherSpec" enables SCTP dry event > and wait for dry event notification. > > Inline image 1 > > > In this scenario, dry notification is never sent from SCTP. > "dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow > never enters "read_state_machine" where alert is to be red.This > causes SSL_Connect to be in infinite loop. > > > Thanks, > Mahesh G S > > On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell > wrote: > > > > On 17/11/17 06:42, mahesh gs wrote: > >? Why > > does client respond with "Client key exchange" even if the the handshake > > failure alert is sent from server? > > The client will send its entire flight of messages before it > attempts to > read anything from the server. So, in this case, the > ClientKeyExchange > message is still sent because the client hasn't read the alert yet. > > Matt > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > From mahesh116 at gmail.com Tue Nov 21 10:42:34 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Tue, 21 Nov 2017 16:12:34 +0530 Subject: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application In-Reply-To: <4cc2efe5-d00a-4aed-53b6-6c6e3b9e80e5@openssl.org> References: <4976CBFA-17F5-4BDB-AEE0-212BBD6B28A2@sharp.fm> <7a4b067c-ce3a-29dd-d05c-0caf045479eb@openssl.org> <78f45c84-52fb-86a1-24b2-1b7f94e2328e@openssl.org> <4cc2efe5-d00a-4aed-53b6-6c6e3b9e80e5@openssl.org> Message-ID: Hi Matt, I have raised bug. https://github.com/openssl/openssl/issues/4763 Thanks, Mahesh G S On Tue, Nov 21, 2017 at 3:26 PM, Matt Caswell wrote: > Sounds like a bug. Can you raise this as an issue on github? > > https://github.com/openssl/openssl/issues > > Thanks > > Matt > > > On 21/11/17 08:53, mahesh gs wrote: > > Hi, > > > > We were able to further localize this problem and found the problem is > > with the function "BIO_dgram_sctp_wait_for_dry". In this function after > > enabling the "sctp_sender_dry_event" we are trying to do MSG_PEEK to > > peek to the message at SCTP layer, in this case the size of the message > > waiting in the lower layer is 15 which size is exactly the size of > > "Handshake Alert" that is received from the server and waiting to be > > read. Dry event is never read from the lower layer that causes the > > SUB_STATE_ERROR and intern causes the SSL_Connect to loop in application. > > > > Current version of openssl we are using is 01.01.00g. > > > > We have tested and able to reproduce this issue with the OPENSSL > > 01.00.02k version that is packaged with RHEL 7.4 as well. > > > > > > Thanks, > > Mahesh G S > > > > On Mon, Nov 20, 2017 at 4:42 PM, mahesh gs > > wrote: > > > > Hi Matt, > > > > Thanks for the response. > > > > We debugged through openssl code to get to know the reason why > > client is not reading "SSL Alert". > > > > Once the "ClientKeyExchange" is sent openssl trying to send out the > > "ChangeCipherSpec" message which is creating the problem. > > > > The pre-work function for "ChangeCipherSpec" enables SCTP dry event > > and wait for dry event notification. > > > > Inline image 1 > > > > > > In this scenario, dry notification is never sent from SCTP. > > "dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow > > never enters "read_state_machine" where alert is to be red.This > > causes SSL_Connect to be in infinite loop. > > > > > > Thanks, > > Mahesh G S > > > > On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell > > wrote: > > > > > > > > On 17/11/17 06:42, mahesh gs wrote: > > > Why > > > does client respond with "Client key exchange" even if the the > handshake > > > failure alert is sent from server? > > > > The client will send its entire flight of messages before it > > attempts to > > read anything from the server. So, in this case, the > > ClientKeyExchange > > message is still sent because the client hasn't read the alert > yet. > > > > 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 milindchangire at gmail.com Tue Nov 21 14:13:15 2017 From: milindchangire at gmail.com (Milind Changire) Date: Tue, 21 Nov 2017 19:43:15 +0530 Subject: [openssl-users] how to complete non-blocking IO with multiple worker threads ? Message-ID: Environment: Linux (Fedora/RHEL) I have a client server implementation with the server waiting for connections via an epoll fd. Many worker threads epoll_wait( ) on the epoll fd. This implementation has the static thread-id and thread-locking callbacks registered to handle multiple threads to use the SSL API. However, the current implementation also spawns a dedicated thread to SSL_accept( )/SSL_connect( )/SSL_read( )/SSL_write( ) with SSL connections and works perfectly. I want to discard the dedicated thread implementation for SSL and use the worker threads waiting in epoll_wait( ) to service the non-blocking IO requests as is done for non-SSL communication, using the SSL API of course. Can this be done ? So, is there a way that such a multi-threaded non-blocking IO client/server application can complete the IO via various worker threads when a WANT_READ/WANT_WRITE is returned by SSL_get_error( ) Also, can WANT_READ/WANT_WRITE returned from SSL_accept( )/SSL_connect( ) also be serviced with non-blocking IO and via different worker threads ? I couldn't find anything pertaining to this in the archives. Please point me to one if I missed it. Regards, Milind -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncsuandrew12 at gmail.com Tue Nov 21 14:50:25 2017 From: ncsuandrew12 at gmail.com (Andrew Felsher) Date: Tue, 21 Nov 2017 09:50:25 -0500 Subject: [openssl-users] X509_ATTRIBUTE_create_by_NID reversing ASN1 sequence Message-ID: Hi, (Apologies if this was sent multiple times; I'm experiencing some technical difficulties.) I'm working on a CSR-generating API using OpenSSL 1.0.2m. My question is: does OpenSSL do any sort of reordering of the entries in an ASN1 sequence? Specifically, when encoding a postal address X509_ATTRIBUTE. Background: To create a postal address X509_ATTRIBUTE, I'm calling X509_ATTRIBUTE_create_by_NID(NULL, nid, atrtype, data, len). nid is 861 (0x35d) (postal address), atrtype is 16 (ASN1 sequence). My data is the concatenated results of three i2d_ASN1_GENERALSTRING() calls for three strings, resulting in this data: 0000: 1B 11 32 32 31 42 20 42 61 6B 65 72 20 53 74 72 ..221B Baker Str 0010: 65 65 74 1B 06 4C 6F 6E 64 6F 6E 1B 02 55 4B -- eet..London..UK X509_ATTRIBUTE_create_by_NID seems to handle this fine, and various later X509_ATTRIBUTE*() calls work fine. However, when I call i2d_X509_ATTRIBUTE() just after generating the attribute, the three strings seem to be reversed in the output: 0000: 30 26 06 03 55 04 10 31 1F 1B 02 55 4B 1B 06 4C 0&..U..1...UK..L 0010: 6F 6E 64 6F 6E 1B 11 32 32 31 42 20 42 61 6B 65 ondon..221B Bake 0020: 72 20 53 74 72 65 65 74 -- -- -- -- -- -- -- -- r Street Any idea what could be causing that? Thanks, Andrew Felsher -------------- next part -------------- An HTML attachment was scrubbed... URL: From Holger.Seiberlich at bruker.com Wed Nov 22 10:19:15 2017 From: Holger.Seiberlich at bruker.com (Seiberlich, Holger) Date: Wed, 22 Nov 2017 10:19:15 +0000 Subject: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m) Message-ID: <9984110daedd4f7ca0bdaa3f4832c933@bruexc101.brumgt.local> Dear OpenSSL community, in a C++ (vc14, OpenSSL 1.0.2h/m) project, I'm trying to negotiate a secret between two parties, using EC crypto. I've used https://wiki.openssl.org/index.php/EVP_Key_Agreement as a recipe and wrapped memory allocations into unique_ptrs. The code fulfills its purpose of deriving a shared secret, but memory leak detection with _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); _CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE ); _CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT ); produces a warning: Detected memory leaks! Dumping objects -> {10316} normal block at 0x00307680, 12 bytes long. Data: < v0 > F0 76 30 00 00 00 00 00 0D 00 00 00 {10315} normal block at 0x00351068, 16 bytes long. Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 {10314} normal block at 0x00350F68, 20 bytes long. Data: < h 5 > 00 00 00 00 68 10 35 00 00 00 00 00 04 00 00 00 {10313} normal block at 0x003076F0, 12 bytes long. Data: < h 5 > 0D 00 00 00 68 0F 35 00 00 00 00 00 {10312} normal block at 0x00310A70, 64 bytes long. Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 {10311} normal block at 0x00309E98, 96 bytes long. Data:

70 0A 31 00 90 41 20 0F A0 0D 27 0F 08 00 00 00 Object dump complete. Let me note two things: - The line without which the memory leak disappears is the line triggering the actual secret derivation: if(EVP_PKEY_derive(ctx.get(), skey.get(), &skeylen) <= 0) - The size of the leak is independent of how often I run the procedure of generating two sets of keys and then calling DeriveSecret(). *** Therefore, I'm wondering whether I've missed a call to free that I must trigger to deallocate this memory. *** I have added an allocation hook to check, as an example, when the 96-byte allocation occurs: [Name] [Language] libeay32.dll!default_malloc_ex(unsigned int num, const char * file, int line) Line 79 C libeay32.dll!CRYPTO_malloc(int num, const char * file, int line) Line 342 C libeay32.dll!lh_new(unsigned long(*)(const void *) h, int(*)(const void *, const void *) c) Line 120 C libeay32.dll!ex_data_check() Line 279 C libeay32.dll!def_get_class(int class_index) Line 316 C libeay32.dll!int_new_ex_data(int class_index, void * obj, crypto_ex_data_st * ad) Line 421 C libeay32.dll!CRYPTO_new_ex_data(int class_index, void * obj, crypto_ex_data_st * ad) Line 583 C libeay32.dll!ECDH_DATA_new_method(engine_st * engine) Line 165 C libeay32.dll!ecdh_data_new() Line 178 C libeay32.dll!ecdh_check(ec_key_st * key) Line 215 C libeay32.dll!ECDH_compute_key(void * out, unsigned int outlen, const ec_point_st * pub_key, ec_key_st * eckey, void *(*)(const void *, unsigned int, void *, unsigned int *) KDF) Line 77 C libeay32.dll!pkey_ec_derive(evp_pkey_ctx_st * ctx, unsigned char * key, unsigned int * keylen) Line 237 C libeay32.dll!pkey_ec_kdf_derive(evp_pkey_ctx_st * ctx, unsigned char * key, unsigned int * keylen) Line 252 C libeay32.dll!EVP_PKEY_derive(evp_pkey_ctx_st * ctx, unsigned char * key, unsigned int * pkeylen) Line 345 C [.]DeriveSecret() Line 802 C++ Please see below for how I call EVP_PKEY_derive. Can you tell me what I'm missing? Do you need more info? Thank you for looking into this and helping! Regards, Holger template using deleted_unique_ptr = std::unique_ptr>; deleted_unique_ptr m_pOwnKey; deleted_unique_ptr m_pPeerKey; void [...]::DeriveSecret() { if (!(m_pOwnKey && m_pOwnKey->pkey.ec)) { throw KeyUninitializedError("Secret cannot be derived if own key is missing"); } if (!m_pPeerKey) { throw KeyUninitializedError("Secret cannot be derived if peer key is missing"); } deleted_unique_ptr ctx(EVP_PKEY_CTX_new(m_pOwnKey.get(), NULL), [](EVP_PKEY_CTX* obj) { EVP_PKEY_CTX_free(obj); }); size_t skeylen; if(!ctx) { /* Error occurred */ throw OpenSslError("Error creating EVP_PKEY_CTX"); } if(EVP_PKEY_derive_init(ctx.get()) <= 0) { /* Error */ throw OpenSslError("Error in EVP_PKEY_derive_init"); } if(EVP_PKEY_derive_set_peer(ctx.get(), m_pPeerKey.get()) <= 0) { /* Error */ throw OpenSslError("Error setting peer key in key negotiation"); } /* Determine buffer length */ if(EVP_PKEY_derive(ctx.get(), NULL, &skeylen) <= 0) { /* Error */ throw OpenSslError("Error computing length of shared secret"); } if (skeylen != secretSize) { throw OpenSslError("Shared secret has unexpected size"); } deleted_unique_ptr skey((unsigned char*)OPENSSL_malloc(skeylen), [](unsigned char* obj) { OPENSSL_free(obj); }); /// @note The derivation of the secret seems to leak memory within OpenSSL if(EVP_PKEY_derive(ctx.get(), skey.get(), &skeylen) <= 0) { /* Error */ throw OpenSslError("Error deriving shared secret"); } [...] } Dr. Holger Seiberlich Software Developer Bruker Optik GmbH Rudolf-Plank-Str. 27 76275 Ettlingen, Germany Phone: +49 7243 504-2626 Fax: +49 7243 504-42626 Holger.Seiberlich at bruker.com www.bruker.com Sitz der Gesellschaft ist Ettlingen, HRB 36 2608 Amtsgericht Mannheim Gesch?ftsf?hrer: Urban Faeh, Marc Beisel, Juergen Srega Diese E-Mail und alle Anlagen k?nnen Betriebs- oder Gesch?ftsgeheimnisse, oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder Weitergabe der E-Mail und aller Anlagen ausdr?cklich untersagt. Bitte benachrichtigen Sie den Absender und l?schen/vernichten Sie die empfangene E-Mail und alle Anlagen. Vielen Dank. This message and any attachments may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it and its attachments is strictly prohibited. Please inform the sender immediately and delete/destroy the original message and any copies. Thank you. From yahiaelsawiabd1974 at gmail.com Wed Nov 22 10:44:52 2017 From: yahiaelsawiabd1974 at gmail.com (yahiaelsawiabd1974 at gmail.com) Date: Wed, 22 Nov 2017 10:44:52 +0000 Subject: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m) In-Reply-To: <9984110daedd4f7ca0bdaa3f4832c933@bruexc101.brumgt.local> References: <9984110daedd4f7ca0bdaa3f4832c933@bruexc101.brumgt.local> Message-ID: <5a1555245f481_17523fbaae87ee401199148a@ip-172-31-19-87.mail> Thanks for emailing me! No, I haven?t been hacked :) I signed up for a spam filtering service called BitBounce. To deliver your email to my inbox, please click the link below. Thanks! https://bitbounce.com/pay_bitbounce_fee/4093641092 BitBounce is a product by: Turing Cloud Turing-Cloud.com/bitbounce Redwood City, CA BitBounce integrates with: CoinBase CoinBase.com San Francisco, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Nov 22 10:49:48 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 22 Nov 2017 10:49:48 +0000 Subject: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m) In-Reply-To: <9984110daedd4f7ca0bdaa3f4832c933@bruexc101.brumgt.local> References: <9984110daedd4f7ca0bdaa3f4832c933@bruexc101.brumgt.local> Message-ID: <0deb6ed3-d76a-d379-b4b7-30b70524448c@openssl.org> Before you close your application down try calling: CRYPTO_cleanup_all_ex_data() See: https://wiki.openssl.org/index.php/Library_Initialization#Cleanup The whole dance around init/de-init of the library becomes a whole lot easier in 1.1.0 (it should all happen automatically) - but in 1.0.2 you have to call several functions to properly de-initialise the library. Matt On 22/11/17 10:19, Seiberlich, Holger via openssl-users wrote: > Dear OpenSSL community, > > in a C++ (vc14, OpenSSL 1.0.2h/m) project, I'm trying to negotiate a secret between two parties, using EC crypto. I've used > https://wiki.openssl.org/index.php/EVP_Key_Agreement > as a recipe and wrapped memory allocations into unique_ptrs. The code fulfills its purpose of deriving a shared secret, but memory leak detection with > _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); > _CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE ); > _CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT ); > produces a warning: > Detected memory leaks! > Dumping objects -> > {10316} normal block at 0x00307680, 12 bytes long. > Data: < v0 > F0 76 30 00 00 00 00 00 0D 00 00 00 > {10315} normal block at 0x00351068, 16 bytes long. > Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > {10314} normal block at 0x00350F68, 20 bytes long. > Data: < h 5 > 00 00 00 00 68 10 35 00 00 00 00 00 04 00 00 00 > {10313} normal block at 0x003076F0, 12 bytes long. > Data: < h 5 > 0D 00 00 00 68 0F 35 00 00 00 00 00 > {10312} normal block at 0x00310A70, 64 bytes long. > Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > {10311} normal block at 0x00309E98, 96 bytes long. > Data:

70 0A 31 00 90 41 20 0F A0 0D 27 0F 08 00 00 00 > Object dump complete. > > Let me note two things: > - The line without which the memory leak disappears is the line triggering the actual secret derivation: > if(EVP_PKEY_derive(ctx.get(), skey.get(), &skeylen) <= 0) > - The size of the leak is independent of how often I run the procedure of generating two sets of keys and then calling DeriveSecret(). > > *** > Therefore, I'm wondering whether I've missed a call to free that I must trigger to deallocate this memory. > *** > > I have added an allocation hook to check, as an example, when the 96-byte allocation occurs: > > [Name] [Language] > libeay32.dll!default_malloc_ex(unsigned int num, const char * file, int line) Line 79 C > libeay32.dll!CRYPTO_malloc(int num, const char * file, int line) Line 342 C > libeay32.dll!lh_new(unsigned long(*)(const void *) h, int(*)(const void *, const void *) c) Line 120 C > libeay32.dll!ex_data_check() Line 279 C > libeay32.dll!def_get_class(int class_index) Line 316 C > libeay32.dll!int_new_ex_data(int class_index, void * obj, crypto_ex_data_st * ad) Line 421 C > libeay32.dll!CRYPTO_new_ex_data(int class_index, void * obj, crypto_ex_data_st * ad) Line 583 C > libeay32.dll!ECDH_DATA_new_method(engine_st * engine) Line 165 C > libeay32.dll!ecdh_data_new() Line 178 C > libeay32.dll!ecdh_check(ec_key_st * key) Line 215 C > libeay32.dll!ECDH_compute_key(void * out, unsigned int outlen, const ec_point_st * pub_key, ec_key_st * eckey, void *(*)(const void *, unsigned int, void *, unsigned int *) KDF) Line 77 C > libeay32.dll!pkey_ec_derive(evp_pkey_ctx_st * ctx, unsigned char * key, unsigned int * keylen) Line 237 C > libeay32.dll!pkey_ec_kdf_derive(evp_pkey_ctx_st * ctx, unsigned char * key, unsigned int * keylen) Line 252 C > libeay32.dll!EVP_PKEY_derive(evp_pkey_ctx_st * ctx, unsigned char * key, unsigned int * pkeylen) Line 345 C > [.]DeriveSecret() Line 802 C++ > > Please see below for how I call EVP_PKEY_derive. Can you tell me what I'm missing? Do you need more info? > > Thank you for looking into this and helping! > > Regards, > Holger > > > template using deleted_unique_ptr = std::unique_ptr>; > > deleted_unique_ptr m_pOwnKey; > deleted_unique_ptr m_pPeerKey; > > void [...]::DeriveSecret() > { > if (!(m_pOwnKey && m_pOwnKey->pkey.ec)) > { > throw KeyUninitializedError("Secret cannot be derived if own key is missing"); > } > if (!m_pPeerKey) > { > throw KeyUninitializedError("Secret cannot be derived if peer key is missing"); > } > > deleted_unique_ptr ctx(EVP_PKEY_CTX_new(m_pOwnKey.get(), NULL), [](EVP_PKEY_CTX* obj) > { > EVP_PKEY_CTX_free(obj); > }); > > size_t skeylen; > if(!ctx) > { > /* Error occurred */ > throw OpenSslError("Error creating EVP_PKEY_CTX"); > } > if(EVP_PKEY_derive_init(ctx.get()) <= 0) > { > /* Error */ > throw OpenSslError("Error in EVP_PKEY_derive_init"); > } > if(EVP_PKEY_derive_set_peer(ctx.get(), m_pPeerKey.get()) <= 0) > { > /* Error */ > throw OpenSslError("Error setting peer key in key negotiation"); > } > /* Determine buffer length */ > if(EVP_PKEY_derive(ctx.get(), NULL, &skeylen) <= 0) > { > /* Error */ > throw OpenSslError("Error computing length of shared secret"); > } > > if (skeylen != secretSize) > { > throw OpenSslError("Shared secret has unexpected size"); > } > > deleted_unique_ptr skey((unsigned char*)OPENSSL_malloc(skeylen), [](unsigned char* obj) > { > OPENSSL_free(obj); > }); > > /// @note The derivation of the secret seems to leak memory within OpenSSL > if(EVP_PKEY_derive(ctx.get(), skey.get(), &skeylen) <= 0) > { > /* Error */ > throw OpenSslError("Error deriving shared secret"); > } > > [...] > } > > > > > Dr. Holger Seiberlich > Software Developer > Bruker Optik GmbH > Rudolf-Plank-Str. 27 > 76275 Ettlingen, Germany > > Phone: +49 7243 504-2626 > Fax: +49 7243 504-42626 > Holger.Seiberlich at bruker.com > www.bruker.com > > Sitz der Gesellschaft ist Ettlingen, HRB 36 2608 Amtsgericht Mannheim > Gesch?ftsf?hrer: Urban Faeh, Marc Beisel, Juergen Srega > > Diese E-Mail und alle Anlagen k?nnen Betriebs- oder Gesch?ftsgeheimnisse, oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder Weitergabe der E-Mail und aller Anlagen ausdr?cklich untersagt. Bitte benachrichtigen Sie den Absender und l?schen/vernichten Sie die empfangene E-Mail und alle Anlagen. Vielen Dank. > > This message and any attachments may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it and its attachments is strictly prohibited. Please inform the sender immediately and delete/destroy the original message and any copies. Thank you. > > From Holger.Seiberlich at bruker.com Wed Nov 22 12:00:36 2017 From: Holger.Seiberlich at bruker.com (Seiberlich, Holger) Date: Wed, 22 Nov 2017 12:00:36 +0000 Subject: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m) In-Reply-To: <0deb6ed3-d76a-d379-b4b7-30b70524448c@openssl.org> References: <9984110daedd4f7ca0bdaa3f4832c933@bruexc101.brumgt.local> <0deb6ed3-d76a-d379-b4b7-30b70524448c@openssl.org> Message-ID: <0dfa82d097ca4c7faa9e6003b5788505@bruexc101.brumgt.local> Hi Matt: Thank you very much for your answer! I did what you told me, and there's no longer an indication of a memory leak. Sincerely, Holger -----Urspr?ngliche Nachricht----- Von: Matt Caswell [mailto:matt at openssl.org] Gesendet: Mittwoch, 22. November 2017 11:50 An: Seiberlich, Holger; openssl-users at openssl.org Betreff: Re: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m) Before you close your application down try calling: CRYPTO_cleanup_all_ex_data() See: https://wiki.openssl.org/index.php/Library_Initialization#Cleanup The whole dance around init/de-init of the library becomes a whole lot easier in 1.1.0 (it should all happen automatically) - but in 1.0.2 you have to call several functions to properly de-initialise the library. Matt On 22/11/17 10:19, Seiberlich, Holger via openssl-users wrote: > Dear OpenSSL community, > > in a C++ (vc14, OpenSSL 1.0.2h/m) project, I'm trying to negotiate a > secret between two parties, using EC crypto. I've used > https://wiki.openssl.org/index.php/EVP_Key_Agreement > as a recipe and wrapped memory allocations into unique_ptrs. The code fulfills its purpose of deriving a shared secret, but memory leak detection with > _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); > _CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE ); > _CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT ); produces a > warning: > Detected memory leaks! > Dumping objects -> > {10316} normal block at 0x00307680, 12 bytes long. > Data: < v0 > F0 76 30 00 00 00 00 00 0D 00 00 00 > {10315} normal block at 0x00351068, 16 bytes long. > Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > {10314} normal block at 0x00350F68, 20 bytes long. > Data: < h 5 > 00 00 00 00 68 10 35 00 00 00 00 00 04 00 00 00 > {10313} normal block at 0x003076F0, 12 bytes long. > Data: < h 5 > 0D 00 00 00 68 0F 35 00 00 00 00 00 > {10312} normal block at 0x00310A70, 64 bytes long. > Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > {10311} normal block at 0x00309E98, 96 bytes long. > Data:

70 0A 31 00 90 41 20 0F A0 0D 27 0F 08 00 00 00 > Object dump complete. > > Let me note two things: > - The line without which the memory leak disappears is the line triggering the actual secret derivation: > if(EVP_PKEY_derive(ctx.get(), skey.get(), &skeylen) <= 0) > - The size of the leak is independent of how often I run the procedure of generating two sets of keys and then calling DeriveSecret(). > > *** > Therefore, I'm wondering whether I've missed a call to free that I must trigger to deallocate this memory. > *** > > I have added an allocation hook to check, as an example, when the 96-byte allocation occurs: > > [Name] [Language] > libeay32.dll!default_malloc_ex(unsigned int num, const char * file, int line) Line 79 C > libeay32.dll!CRYPTO_malloc(int num, const char * file, int line) Line 342 C > libeay32.dll!lh_new(unsigned long(*)(const void *) h, int(*)(const void *, const void *) c) Line 120 C > libeay32.dll!ex_data_check() Line 279 C > libeay32.dll!def_get_class(int class_index) Line 316 C > libeay32.dll!int_new_ex_data(int class_index, void * obj, crypto_ex_data_st * ad) Line 421 C > libeay32.dll!CRYPTO_new_ex_data(int class_index, void * obj, crypto_ex_data_st * ad) Line 583 C > libeay32.dll!ECDH_DATA_new_method(engine_st * engine) Line 165 C > libeay32.dll!ecdh_data_new() Line 178 C > libeay32.dll!ecdh_check(ec_key_st * key) Line 215 C > libeay32.dll!ECDH_compute_key(void * out, unsigned int outlen, const ec_point_st * pub_key, ec_key_st * eckey, void *(*)(const void *, unsigned int, void *, unsigned int *) KDF) Line 77 C > libeay32.dll!pkey_ec_derive(evp_pkey_ctx_st * ctx, unsigned char * key, unsigned int * keylen) Line 237 C > libeay32.dll!pkey_ec_kdf_derive(evp_pkey_ctx_st * ctx, unsigned char * key, unsigned int * keylen) Line 252 C > libeay32.dll!EVP_PKEY_derive(evp_pkey_ctx_st * ctx, unsigned char * key, unsigned int * pkeylen) Line 345 C > [.]DeriveSecret() Line 802 C++ > > Please see below for how I call EVP_PKEY_derive. Can you tell me what I'm missing? Do you need more info? > > Thank you for looking into this and helping! > > Regards, > Holger > > > template using deleted_unique_ptr = > std::unique_ptr>; > > deleted_unique_ptr m_pOwnKey; deleted_unique_ptr > m_pPeerKey; > > void [...]::DeriveSecret() > { > if (!(m_pOwnKey && m_pOwnKey->pkey.ec)) > { > throw KeyUninitializedError("Secret cannot be derived if own key is missing"); > } > if (!m_pPeerKey) > { > throw KeyUninitializedError("Secret cannot be derived if peer key is missing"); > } > > deleted_unique_ptr ctx(EVP_PKEY_CTX_new(m_pOwnKey.get(), NULL), [](EVP_PKEY_CTX* obj) > { > EVP_PKEY_CTX_free(obj); > }); > > size_t skeylen; > if(!ctx) > { > /* Error occurred */ > throw OpenSslError("Error creating EVP_PKEY_CTX"); > } > if(EVP_PKEY_derive_init(ctx.get()) <= 0) > { > /* Error */ > throw OpenSslError("Error in EVP_PKEY_derive_init"); > } > if(EVP_PKEY_derive_set_peer(ctx.get(), m_pPeerKey.get()) <= 0) > { > /* Error */ > throw OpenSslError("Error setting peer key in key negotiation"); > } > /* Determine buffer length */ > if(EVP_PKEY_derive(ctx.get(), NULL, &skeylen) <= 0) > { > /* Error */ > throw OpenSslError("Error computing length of shared secret"); > } > > if (skeylen != secretSize) > { > throw OpenSslError("Shared secret has unexpected size"); > } > > deleted_unique_ptr skey((unsigned char*)OPENSSL_malloc(skeylen), [](unsigned char* obj) > { > OPENSSL_free(obj); > }); > > /// @note The derivation of the secret seems to leak memory within OpenSSL > if(EVP_PKEY_derive(ctx.get(), skey.get(), &skeylen) <= 0) > { > /* Error */ > throw OpenSslError("Error deriving shared secret"); > } > > [...] > } > > > > > Dr. Holger Seiberlich > Software Developer > Bruker Optik GmbH > Rudolf-Plank-Str. 27 > 76275 Ettlingen, Germany > > Phone: +49 7243 504-2626 > Fax: +49 7243 504-42626 > Holger.Seiberlich at bruker.com > www.bruker.com > > Sitz der Gesellschaft ist Ettlingen, HRB 36 2608 Amtsgericht Mannheim > Gesch?ftsf?hrer: Urban Faeh, Marc Beisel, Juergen Srega > > Diese E-Mail und alle Anlagen k?nnen Betriebs- oder Gesch?ftsgeheimnisse, oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder Weitergabe der E-Mail und aller Anlagen ausdr?cklich untersagt. Bitte benachrichtigen Sie den Absender und l?schen/vernichten Sie die empfangene E-Mail und alle Anlagen. Vielen Dank. > > This message and any attachments may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it and its attachments is strictly prohibited. Please inform the sender immediately and delete/destroy the original message and any copies. Thank you. > > From noadsplease at web.de Wed Nov 22 11:58:08 2017 From: noadsplease at web.de (Dirk Menstermann) Date: Wed, 22 Nov 2017 12:58:08 +0100 Subject: [openssl-users] Example code to add several CRL distribution points Message-ID: Hi, can anybody share example code to add more than 1 CRL distribution point to a certificate? The below works only for one URI: X509_EXTENSION *ext = X509V3_EXT_conf_nid (NULL, &v3ctx, NID_crl_distribution_points, (char*) "URI:http://exmaple.com/crl"); X509_add_ext (certificate, ext, -1); Thanks a lot Dirk From yahiaelsawiabd1974 at gmail.com Wed Nov 22 12:06:39 2017 From: yahiaelsawiabd1974 at gmail.com (yahiaelsawiabd1974 at gmail.com) Date: Wed, 22 Nov 2017 12:06:39 +0000 Subject: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m) In-Reply-To: <0dfa82d097ca4c7faa9e6003b5788505@bruexc101.brumgt.local> References: <0dfa82d097ca4c7faa9e6003b5788505@bruexc101.brumgt.local> Message-ID: <5a15684f74c89_502f3f95eca02c3012739241@ip-172-31-22-119.mail> Thanks for emailing me! No, I haven?t been hacked :) I signed up for a spam filtering service called BitBounce. To deliver your email to my inbox, please click the link below. Thanks! https://bitbounce.com/pay_bitbounce_fee/1808859525 BitBounce is a product by: Turing Cloud Turing-Cloud.com/bitbounce Redwood City, CA BitBounce integrates with: CoinBase CoinBase.com San Francisco, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcoombs at carillon.ca Wed Nov 22 14:04:01 2017 From: dcoombs at carillon.ca (Dave Coombs) Date: Wed, 22 Nov 2017 09:04:01 -0500 Subject: [openssl-users] Example code to add several CRL distribution points In-Reply-To: References: Message-ID: <35417419-8A91-4A1B-A363-D8D85CACC10A@carillon.ca> Hi, You can use X509V3_EXT_i2d(NID_crl_distribution_points, critical, sk) where sk is a STACK_OF(DIST_POINT) that you have previously filled with multiple URIs. Cheers, -Dave > On Nov 22, 2017, at 06:58, Dirk Menstermann wrote: > Hi, > > can anybody share example code to add more than 1 CRL distribution point to a > certificate? > > The below works only for one URI: > > X509_EXTENSION *ext = X509V3_EXT_conf_nid (NULL, &v3ctx, > NID_crl_distribution_points, (char*) "URI:http://exmaple.com/crl"); > X509_add_ext (certificate, ext, -1); > > Thanks a lot > Dirk > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From eldlistmailingz at tropicsoft.com Wed Nov 22 14:42:15 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Wed, 22 Nov 2017 09:42:15 -0500 Subject: [openssl-users] Non const input for EVP_EncryptUpdate and EVP_DecryptUpdate Message-ID: When calling EVP_EncryptUpdate with some plaintext to be encrypted the parameter for the plaintext is a pointer to a non-const array of unsigned char, as in the function prototype: int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, unsigned char *in, int inl); Similarly when calling EVP_DecryptUpdate with some ciphertext to be decrypted the parameter for the ciphertext is a pointer to a non-const array of unsigned char, as in the function prototype: int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, unsigned char *in, int inl); I have taken both these function prototypes from the OpenSSL documentation at https://wiki.openssl.org/index.php/Manual:EVP_EncryptInit(3). Does this mean that the input array in both cases actually is modified in any way by the functions ? Or is this just an error in that if the input remains unmodified the functions do not specify the parameter as 'const unsigned char * in' instead ? From matt at openssl.org Wed Nov 22 15:46:39 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 22 Nov 2017 15:46:39 +0000 Subject: [openssl-users] Non const input for EVP_EncryptUpdate and EVP_DecryptUpdate In-Reply-To: References: Message-ID: This is a bug in the docs. In the header files they are declared as const: int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, const unsigned char *in, int inl); int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, const unsigned char *in, int inl); Please file a bug report! https://github.com/openssl/openssl/issues Matt On 22/11/17 14:42, Edward Diener wrote: > When calling EVP_EncryptUpdate with some plaintext to be encrypted the > parameter for the plaintext is a pointer to a non-const array of > unsigned char, as in the function prototype: > > int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, > ???????? int *outl, unsigned char *in, int inl); > > Similarly when calling EVP_DecryptUpdate with some ciphertext to be > decrypted the parameter for the ciphertext is a pointer to a non-const > array of unsigned char, as in the function prototype: > > int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, > ???????? int *outl, unsigned char *in, int inl); > > I have taken both these function prototypes from the OpenSSL > documentation at > https://wiki.openssl.org/index.php/Manual:EVP_EncryptInit(3). > > Does this mean that the input array in both cases actually is modified > in any way by the functions ? Or is this just an error in that if the > input remains unmodified the functions do not specify the parameter as > 'const unsigned char * in' instead ? > > From eldlistmailingz at tropicsoft.com Wed Nov 22 20:41:35 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Wed, 22 Nov 2017 15:41:35 -0500 Subject: [openssl-users] Non const input for EVP_EncryptUpdate and EVP_DecryptUpdate In-Reply-To: References: Message-ID: On 11/22/2017 10:46 AM, Matt Caswell wrote: > This is a bug in the docs. In the header files they are declared as const: > > int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, > const unsigned char *in, int inl); > > int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, > const unsigned char *in, int inl); > > Please file a bug report! I filed an issue. It is now the 333th open issue. Thanks for the information. I guess I should have looked myself. > > https://github.com/openssl/openssl/issues > > Matt > > > On 22/11/17 14:42, Edward Diener wrote: >> When calling EVP_EncryptUpdate with some plaintext to be encrypted the >> parameter for the plaintext is a pointer to a non-const array of >> unsigned char, as in the function prototype: >> >> int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, >> ???????? int *outl, unsigned char *in, int inl); >> >> Similarly when calling EVP_DecryptUpdate with some ciphertext to be >> decrypted the parameter for the ciphertext is a pointer to a non-const >> array of unsigned char, as in the function prototype: >> >> int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, >> ???????? int *outl, unsigned char *in, int inl); >> >> I have taken both these function prototypes from the OpenSSL >> documentation at >> https://wiki.openssl.org/index.php/Manual:EVP_EncryptInit(3). >> >> Does this mean that the input array in both cases actually is modified >> in any way by the functions ? Or is this just an error in that if the >> input remains unmodified the functions do not specify the parameter as >> 'const unsigned char * in' instead ? >> >> From kavita.jindal at gmail.com Thu Nov 23 07:54:06 2017 From: kavita.jindal at gmail.com (kavita jindal) Date: Thu, 23 Nov 2017 13:24:06 +0530 Subject: [openssl-users] ssl3_get_client_hello:no shared cipher Message-ID: Hi All, I am using free radius 3.0.15 ,while using i am getting following error I searched the forums ,some people have already raised the issue but i could not find any solution. eap_tls: (other): before/accept initialization (1) eap_tls: TLS_accept: before/accept initialization (1) eap_tls: <<< recv TLS 1.2 [length 0042] (1) eap_tls: >>> send TLS 1.2 [length 0002] (1) eap_tls: ERROR: TLS Alert write:fatal:handshake failure tls: TLS_accept: Error in error tls: TLS_accept: Error in error (1) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher (1) eap_tls: ERROR: System call (I/O) error (-1) (1) eap_tls: ERROR: TLS receive handshake failed during operation (1) eap_tls: ERROR: [eaptls process] = fail (1) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed (1) eap: Sending EAP Failure (code 4) ID 96 length 4 Also when i use ,its shows my ciphersuite : openssl ciphers 'ALL' | grep ECDHE-ECDSA-AES128-GCM-SHA256 Regards Kavita -------------- next part -------------- An HTML attachment was scrubbed... URL: From noadsplease at web.de Thu Nov 23 08:54:34 2017 From: noadsplease at web.de (Dirk Menstermann) Date: Thu, 23 Nov 2017 09:54:34 +0100 Subject: [openssl-users] Example code to add several CRL distribution points In-Reply-To: <35417419-8A91-4A1B-A363-D8D85CACC10A@carillon.ca> References: <35417419-8A91-4A1B-A363-D8D85CACC10A@carillon.ca> Message-ID: Thanks Dave, It seems that I do something wrong when filling the STACK_OF(DIST_POINT): X509_NAME_ENTRY *nameEntry = X509_NAME_ENTRY_new(); X509_NAME_ENTRY_set_data (nameEntry, V_ASN1_IA5STRING /*MBSTRING_ASC*/, (const unsigned char*) "http://example.com/", 19); STACK_OF (X509_NAME_ENTRY) *nameStack = sk_X509_NAME_ENTRY_new_null(); sk_X509_NAME_ENTRY_push (nameStack, nameEntry); DIST_POINT *distPoint = DIST_POINT_new(); distPoint->distpoint = DIST_POINT_NAME_new(); distPoint->distpoint->name.relativename = nameStack; distPoint->distpoint->type = 0; STACK_OF(DIST_POINT) *distPoints = sk_DIST_POINT_new_null(); sk_DIST_POINT_push (distPoints, distPoint); X509_EXTENSION *ext = X509V3_EXT_i2d (NID_crl_distribution_points, 0, distPoints); X509_add_ext (cert, ext, -1); X509_EXTENSION_free (ext); The extension will be added, but is empty. Do you see where it breaks? Dirk On 22.11.2017 15:04, Dave Coombs wrote: > You can use X509V3_EXT_i2d(NID_crl_distribution_points, critical, sk) where sk is a STACK_OF(DIST_POINT) that you have previously filled with multiple URIs. From dcoombs at carillon.ca Thu Nov 23 17:04:34 2017 From: dcoombs at carillon.ca (Dave Coombs) Date: Thu, 23 Nov 2017 12:04:34 -0500 Subject: [openssl-users] Example code to add several CRL distribution points In-Reply-To: References: <35417419-8A91-4A1B-A363-D8D85CACC10A@carillon.ca> Message-ID: Hi Dirk, First point: you are populating distpoint->name.relativename (which is a union member) but setting the discriminator distpoint->type to 0, which indicates to use fullname rather than relativename. So your structure will not be interpreted correctly. In any case, I think you want to populate fullname, instead of relativename. You're using a url, not a relative DN. Make a GENERAL_NAMES, and add to it a GENERAL_NAME whose type is GEN_URI, and whose value (as an IA5String) is the url you want, and then point distpoint->name.fullname at the GENERAL_NAMES. And, as before, you can do this multiple times and add additional DIST_POINTs. Good luck, -Dave > On Nov 23, 2017, at 03:54, Dirk Menstermann wrote: > Thanks Dave, > > It seems that I do something wrong when filling the STACK_OF(DIST_POINT): > > X509_NAME_ENTRY *nameEntry = X509_NAME_ENTRY_new(); > X509_NAME_ENTRY_set_data (nameEntry, V_ASN1_IA5STRING /*MBSTRING_ASC*/, (const > unsigned char*) "http://example.com/", 19); > > STACK_OF (X509_NAME_ENTRY) *nameStack = sk_X509_NAME_ENTRY_new_null(); > sk_X509_NAME_ENTRY_push (nameStack, nameEntry); > > DIST_POINT *distPoint = DIST_POINT_new(); > distPoint->distpoint = DIST_POINT_NAME_new(); > distPoint->distpoint->name.relativename = nameStack; > distPoint->distpoint->type = 0; > > STACK_OF(DIST_POINT) *distPoints = sk_DIST_POINT_new_null(); > sk_DIST_POINT_push (distPoints, distPoint); > X509_EXTENSION *ext = X509V3_EXT_i2d (NID_crl_distribution_points, 0, distPoints); > X509_add_ext (cert, ext, -1); > X509_EXTENSION_free (ext); > > The extension will be added, but is empty. > > Do you see where it breaks? > Dirk > > On 22.11.2017 15:04, Dave Coombs wrote: >> You can use X509V3_EXT_i2d(NID_crl_distribution_points, critical, sk) where sk is a STACK_OF(DIST_POINT) that you have previously filled with multiple URIs. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From noadsplease at web.de Fri Nov 24 12:19:26 2017 From: noadsplease at web.de (Dirk Menstermann) Date: Fri, 24 Nov 2017 13:19:26 +0100 Subject: [openssl-users] Example code to add several CRL distribution points In-Reply-To: References: <35417419-8A91-4A1B-A363-D8D85CACC10A@carillon.ca> Message-ID: <8d1597de-42a2-1076-ef69-3a04eb6e3972@web.de> Thanks a lot Dave. That helped. Bye Dirk On 23.11.2017 18:04, Dave Coombs wrote: > Hi Dirk, > > First point: you are populating distpoint->name.relativename (which is a union member) but setting the discriminator distpoint->type to 0, which indicates to use fullname rather than relativename. So your structure will not be interpreted correctly. > > In any case, I think you want to populate fullname, instead of relativename. You're using a url, not a relative DN. > > Make a GENERAL_NAMES, and add to it a GENERAL_NAME whose type is GEN_URI, and whose value (as an IA5String) is the url you want, and then point distpoint->name.fullname at the GENERAL_NAMES. > > And, as before, you can do this multiple times and add additional DIST_POINTs. > > Good luck, > -Dave > > >> On Nov 23, 2017, at 03:54, Dirk Menstermann wrote: >> Thanks Dave, >> >> It seems that I do something wrong when filling the STACK_OF(DIST_POINT): >> >> X509_NAME_ENTRY *nameEntry = X509_NAME_ENTRY_new(); >> X509_NAME_ENTRY_set_data (nameEntry, V_ASN1_IA5STRING /*MBSTRING_ASC*/, (const >> unsigned char*) "http://example.com/", 19); >> >> STACK_OF (X509_NAME_ENTRY) *nameStack = sk_X509_NAME_ENTRY_new_null(); >> sk_X509_NAME_ENTRY_push (nameStack, nameEntry); >> >> DIST_POINT *distPoint = DIST_POINT_new(); >> distPoint->distpoint = DIST_POINT_NAME_new(); >> distPoint->distpoint->name.relativename = nameStack; >> distPoint->distpoint->type = 0; >> >> STACK_OF(DIST_POINT) *distPoints = sk_DIST_POINT_new_null(); >> sk_DIST_POINT_push (distPoints, distPoint); >> X509_EXTENSION *ext = X509V3_EXT_i2d (NID_crl_distribution_points, 0, distPoints); >> X509_add_ext (cert, ext, -1); >> X509_EXTENSION_free (ext); >> >> The extension will be added, but is empty. >> >> Do you see where it breaks? >> Dirk >> >> On 22.11.2017 15:04, Dave Coombs wrote: >>> You can use X509V3_EXT_i2d(NID_crl_distribution_points, critical, sk) where sk is a STACK_OF(DIST_POINT) that you have previously filled with multiple URIs. >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From Michal.Trojnara at stunnel.org Sun Nov 26 22:30:51 2017 From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=) Date: Sun, 26 Nov 2017 23:30:51 +0100 Subject: [openssl-users] stunnel 5.44 released Message-ID: <8102610d-a2e1-ace9-8534-267a4107cd88@stunnel.org> Dear Users, I have released version 5.44 of stunnel. It is a bugfix release. I recommend updating to this version. Version 5.44, 2017.11.26, urgency: MEDIUM * New features - Signed Win32 executables, libraries, and installer. * Bugfixes - Default accept address restored to INADDR_ANY. - Fixed a race condition in "make check". - Fixed removing the pid file after configuration reload. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 990a325dbb47d77d88772dd02fbbd27d91b1fea3ece76c9ff4461eca93f12299 stunnel-5.44.tar.gz 4099650ae7be17b81412a0d4caa91db19c8678c8d8d2975398814e583f4c51aa stunnel-5.44-win32-installer.exe 643365b53ee6f16f87a902c3df849209155e603f02f7a761fc2457c89e5ac243 stunnel-5.44-android.zip Best regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 866 bytes Desc: OpenPGP digital signature URL: From john.sha.jiang at gmail.com Mon Nov 27 02:59:15 2017 From: john.sha.jiang at gmail.com (John Jiang) Date: Mon, 27 Nov 2017 10:59:15 +0800 Subject: [openssl-users] How to get SNI info from s_client debug logs? Message-ID: Hi, The following is my OpenSSL version info, OpenSSL 1.1.0f 25 May 2017 I supposed the below command can give me some SNI info, but nothing was found. openssl s_client -debug -tlsextdebug -msg -connect -servername < /dev/null | grep "server name" But I found SNI extension with Wireshark while running the above command. Is it possible get SNI info with s_client? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Nov 27 03:17:35 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 27 Nov 2017 03:17:35 +0000 Subject: [openssl-users] How to get SNI info from s_client debug logs? In-Reply-To: References: Message-ID: <0705EFEC-9F8E-40E4-BCDE-55DAE2A40845@akamai.com> The ?server name? is something that the client sends to the server. This allows a single host to server multiple ?virtual hosts? From: John Jiang Reply-To: openssl-users Date: Sunday, November 26, 2017 at 9:59 PM To: openssl-users Subject: [openssl-users] How to get SNI info from s_client debug logs? Hi, The following is my OpenSSL version info, OpenSSL 1.1.0f 25 May 2017 I supposed the below command can give me some SNI info, but nothing was found. openssl s_client -debug -tlsextdebug -msg -connect -servername < /dev/null | grep "server name" But I found SNI extension with Wireshark while running the above command. Is it possible get SNI info with s_client? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Mon Nov 27 04:27:08 2017 From: aerowolf at gmail.com (Kyle Hamilton) Date: Sun, 26 Nov 2017 20:27:08 -0800 Subject: [openssl-users] How to get SNI info from s_client debug logs? In-Reply-To: References: Message-ID: The -servername [host] is what causes the SNI extension to be sent. I don't think its sending is put into the debug output. Do you really need it there? I'm pretty certain that s_server outputs it in debug output. -Kyle H On Nov 26, 2017 18:59, "John Jiang" wrote: > Hi, > The following is my OpenSSL version info, > OpenSSL 1.1.0f 25 May 2017 > > I supposed the below command can give me some SNI info, but nothing was > found. > openssl s_client -debug -tlsextdebug -msg -connect -servername > < /dev/null | grep "server name" > But I found SNI extension with Wireshark while running the above command. > > Is it possible get SNI info with s_client? > Thanks! > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.sha.jiang at gmail.com Mon Nov 27 07:04:25 2017 From: john.sha.jiang at gmail.com (John Jiang) Date: Mon, 27 Nov 2017 15:04:25 +0800 Subject: [openssl-users] How to get SNI info from s_client debug logs? In-Reply-To: References: Message-ID: I just tried s_server, and its logs included something like "Hostname in TLS extension". But I still have a couple of puzzles. 1. Why does s_server need option "-servername"? I supposed only s_client needs this option. With my test, if only s_client specified "-servername server", the desired certificate still was not used. My commands like: Server side: openssl s_server -cert cert1 -key key1 -cert2 cert2 -key2 key2 -www -accept 4433 Client side: openssl s_client -connect localhost:4433 -servername www.server2.com < /dev/null Here, if www.server2.com is selected, (I hoped) cert2/key2 is used. But it didn't happen with the above case. 2. It looks options -servername and -alpn cannot work together. Please consider the following case, Server side: openssl s_server -cert cert1 -key key1 -cert2 cert2 -key2 key2 -servername www.server2.com -alpn h2 -www -accept 4433 Client side: openssl s_client -connect localhost:4433 -servername www.server2.com -alpn h2 < /dev/null With the above commands, s_client outputted "No ALPN negotiated", and cert2 was selected. But removed "-servername www.server2.com" from server side, and re-run client side command, it outputted "ALPN protocol: h2", but cert1 was selected (namely, SNI didn't work). Thanks! 2017-11-27 12:27 GMT+08:00 Kyle Hamilton : > The -servername [host] is what causes the SNI extension to be sent. I > don't think its sending is put into the debug output. Do you really need it > there? > > I'm pretty certain that s_server outputs it in debug output. > > -Kyle H > > On Nov 26, 2017 18:59, "John Jiang" wrote: > >> Hi, >> The following is my OpenSSL version info, >> OpenSSL 1.1.0f 25 May 2017 >> >> I supposed the below command can give me some SNI info, but nothing was >> found. >> openssl s_client -debug -tlsextdebug -msg -connect >> -servername < /dev/null | grep "server name" >> But I found SNI extension with Wireshark while running the above command. >> >> Is it possible get SNI info with s_client? >> Thanks! >> >> -- >> 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 joshi.sanjaya at gmail.com Mon Nov 27 08:47:23 2017 From: joshi.sanjaya at gmail.com (Sanjaya Joshi) Date: Mon, 27 Nov 2017 14:17:23 +0530 Subject: [openssl-users] Compatibility between different openssl versions Message-ID: Hello, Whether openssl 1.0.x and 1.1.x can interwork ? That is, whether TLS client on top of openssl 1.1.x and TLS server on top of openssl 1.0.x (or vice versa) can interwork efficiently ? Regards, Sanjaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Nov 27 10:20:40 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Nov 2017 10:20:40 +0000 Subject: [openssl-users] Compatibility between different openssl versions In-Reply-To: References: Message-ID: On 27/11/17 08:47, Sanjaya Joshi wrote: > Hello, > Whether openssl 1.0.x and 1.1.x can interwork ? > That is, whether TLS client on top of openssl 1.1.x and TLS server on > top of openssl 1.0.x (or vice versa) can interwork efficiently ? Yes - absolutely. Matt From joshi.sanjaya at gmail.com Mon Nov 27 10:28:24 2017 From: joshi.sanjaya at gmail.com (Sanjaya Joshi) Date: Mon, 27 Nov 2017 15:58:24 +0530 Subject: [openssl-users] Compatibility between different openssl versions In-Reply-To: References: Message-ID: Thank you for the confirmation Matt. Regards, Sanjaya On Mon, Nov 27, 2017 at 3:50 PM, Matt Caswell wrote: > > > On 27/11/17 08:47, Sanjaya Joshi wrote: > > Hello, > > Whether openssl 1.0.x and 1.1.x can interwork ? > > That is, whether TLS client on top of openssl 1.1.x and TLS server on > > top of openssl 1.0.x (or vice versa) can interwork efficiently ? > > Yes - absolutely. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Nov 27 13:12:09 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 27 Nov 2017 13:12:09 +0000 Subject: [openssl-users] Compatibility between different openssl versions In-Reply-To: References: Message-ID: <70F7C9F1-8FFE-44B1-981F-295C5EAAB13D@akamai.com> * Whether openssl 1.0.x and 1.1.x can interwork ? Yup. As long as they share a TLS version, no problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Nov 27 13:27:05 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 27 Nov 2017 13:27:05 +0000 Subject: [openssl-users] How to get SNI info from s_client debug logs? In-Reply-To: References: Message-ID: * 1. Why does s_server need option "-servername"? For debugging, so that you can test that clients are sending the right SNI extension and properly handling the TLS error when they don?t. * 2. It looks options -servername and -alpn cannot work together. Yes, kind-of. The s_client and s_server programs aren?t fully-featured production programs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanandchoubey at yahoo.com Mon Nov 27 14:50:32 2017 From: sanandchoubey at yahoo.com (Anand Choubey) Date: Mon, 27 Nov 2017 14:50:32 +0000 (UTC) Subject: [openssl-users] DTLS in multi-thread and concurrent connection acceptance environment References: <421331336.2441020.1511794232152.ref@mail.yahoo.com> Message-ID: <421331336.2441020.1511794232152@mail.yahoo.com> Hi, OpenSSL version is 1.1.0e. I am writing high-performance?DTLS server which can accept thousands of connections concurrently.?? Originally, I decided, DTLSv1_listen would be called inside the listener thread, once?DTLSv1_listen returns 1 i.e. successful, a new async socket will be created, it will be bound (using bind) and connected (using?BIO_connect) with?DTLSv1_listen returned address.?This new socket will be passed to service thread, BIO_set_fd will set this fd and SSL_accept will be called from service thread to complete the remaining handshake and data exchange etc. But behavior is not same as above, I have to call?SSL_accept? after bind and connect inside the listen, where DTLS handshake is completed. If SSL_accept is not called then?DTLSv1_listen is continuously called and always return 1 in listener thread.? Could you please guide to resolve this issue or how to write multi-threaded dtls server where connection acceptance can be done inside the listener thread using?DTLSv1_listen? Thanks in Advance,Anand -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshi.sanjaya at gmail.com Mon Nov 27 15:20:37 2017 From: joshi.sanjaya at gmail.com (Sanjaya Joshi) Date: Mon, 27 Nov 2017 20:50:37 +0530 Subject: [openssl-users] Compatibility between different openssl versions In-Reply-To: <70F7C9F1-8FFE-44B1-981F-295C5EAAB13D@akamai.com> References: <70F7C9F1-8FFE-44B1-981F-295C5EAAB13D@akamai.com> Message-ID: Hi, Thank you Salz Rich. It's clear now. Regards, Sanjaya On Mon, Nov 27, 2017 at 6:42 PM, Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > > - Whether openssl 1.0.x and 1.1.x can interwork ? > > > > Yup. As long as they share a TLS version, no problem. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wizard2010 at gmail.com Mon Nov 27 16:07:44 2017 From: wizard2010 at gmail.com (wizard2010 at gmail.com) Date: Mon, 27 Nov 2017 16:07:44 +0000 Subject: [openssl-users] SSL alert number 48 Message-ID: Hi there. I'm getting this error on a TLS server&client that I'm implementing and I can't really understand what I'm doing wrong. 139853560931992:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert > unknown ca:s3_pkt.c:1487:SSL alert number 48 > 139853560931992:error:140790E5:SSL routines:ssl23_write:ssl handshake > failure:s23_lib.c:177: This is the code of my server: https://pastebin.com/Fyuki8v0 and I generate the certificates this way: https://pastebin.com/CDRKU2Gc And I'm testing the server this way: openssl s_client -host 127.0.0.1 -port 4444 -cert client.crt -key client.key -CAfile ca.crt If I run a server this way openssl s_server -key server.key -cert server.crt -CAfile ca.crt -accept 4444 I'm able to communicate with the same certificates and on my server code I always get: > Handshake Error 1 > SSL_ERROR_SSL... This is the result of openssl s_client command: https://pastebin.com/AWid1mxi Any idea what's happening to get this error? Kind regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Tue Nov 28 09:11:08 2017 From: janjust at nikhef.nl (Jan Just Keijser) Date: Tue, 28 Nov 2017 10:11:08 +0100 Subject: [openssl-users] SSL alert number 48 In-Reply-To: References: Message-ID: Hi, On 27/11/17 17:07, wizard2010 at gmail.com wrote: > Hi there. > > I'm getting this error on a TLS server&client that I'm implementing and I can't really understand what I'm doing wrong. > > 139853560931992:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:s3_pkt.c:1487:SSL alert number 48 > 139853560931992:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: > > > This is the code of my server: https://pastebin.com/Fyuki8v0 and I generate the certificates this way: > https://pastebin.com/CDRKU2Gc > And I'm testing the server this way: openssl s_client -host 127.0.0.1 -port 4444 -cert client.crt -key client.key -CAfile ca.crt > > If I run a server this way openssl s_server -key server.key -cert server.crt -CAfile ca.crt -accept 4444 > I'm able to communicate with the same certificates and on my server code I always get: > > Handshake Error 1 > SSL_ERROR_SSL... > > This is the result of openssl s_client command: https://pastebin.com/AWid1mxi > FWIW: I've downloaded and compiled your code, generated certs using your script (which generates a client and server cert with the same serial number, BTW) and ran the code: I can connect just fine using either openssl 1.0.1e or 1.1.0e My bet is that when you run your code you are not loading the right ca.crt file ; another way to debug is , is to add a x509 verify callback which prints out each cert as it is passed for verification. HTH, JJK -------------- next part -------------- An HTML attachment was scrubbed... URL: From wizard2010 at gmail.com Tue Nov 28 10:03:12 2017 From: wizard2010 at gmail.com (wizard2010 at gmail.com) Date: Tue, 28 Nov 2017 10:03:12 +0000 Subject: [openssl-users] SSL alert number 48 In-Reply-To: References: Message-ID: Hi there. I guess my problem is really related to verify callback on SSL_CTX_set_verify function. I just add to my code a dummy callback returning 1 and everything works properly. > int verify_callback (int ok, X509_STORE_CTX *ctx); > int verify_callback (int ok, X509_STORE_CTX *ctx) > { > printf("Verification callback OK!\n"); > return 1; > } > ... > SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER | > SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback); > ... The problem is that error don't tell much information about what's really going on or what's really missing. Thanks for your help. Kind regards. On Tue, Nov 28, 2017 at 9:11 AM, Jan Just Keijser wrote: > Hi, > > On 27/11/17 17:07, wizard2010 at gmail.com wrote: > > Hi there. > > I'm getting this error on a TLS server&client that I'm implementing and I > can't really understand what I'm doing wrong. > > 139853560931992:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert >> unknown ca:s3_pkt.c:1487:SSL alert number 48 >> 139853560931992:error:140790E5:SSL routines:ssl23_write:ssl handshake >> failure:s23_lib.c:177: > > > This is the code of my server: https://pastebin.com/Fyuki8v0 and I > generate the certificates this way: https://pastebin.com/CDRKU2Gc > And I'm testing the server this way: openssl s_client -host 127.0.0.1 > -port 4444 -cert client.crt -key client.key -CAfile ca.crt > > If I run a server this way openssl s_server -key server.key -cert > server.crt -CAfile ca.crt -accept 4444 > I'm able to communicate with the same certificates and on my server code I > always get: > >> Handshake Error 1 >> SSL_ERROR_SSL... > > > This is the result of openssl s_client command: > https://pastebin.com/AWid1mxi > > FWIW: I've downloaded and compiled your code, generated certs using your > script (which generates a client and server cert with the same serial > number, BTW) and ran the code: I can connect just fine using either openssl > 1.0.1e or 1.1.0e > > My bet is that when you run your code you are not loading the right ca.crt > file ; another way to debug is , is to add a x509 verify callback which > prints out each cert as it is passed for verification. > > HTH, > > JJK > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanandchoubey at yahoo.com Tue Nov 28 14:01:02 2017 From: sanandchoubey at yahoo.com (Anand Choubey) Date: Tue, 28 Nov 2017 14:01:02 +0000 (UTC) Subject: [openssl-users] DTLS in multi-thread and concurrent connection acceptance environment In-Reply-To: <421331336.2441020.1511794232152@mail.yahoo.com> References: <421331336.2441020.1511794232152.ref@mail.yahoo.com> <421331336.2441020.1511794232152@mail.yahoo.com> Message-ID: <1477119098.3173296.1511877662922@mail.yahoo.com> Hi, I am new in OpenSSL.? I was confused with 1.0.2 implementation where SSL_accept?is called inside the DTLSv1_Listen method. But in 1.1.0, SSL_accept must be called after?DTLSv1_Listen in listener thread otherwise async socket will not be reset and epoll?will always return data ready.?Now things are working. But I do not know, whether?DTLSv1_Listen/ SSL_accept in the listener thread?is capable to deal with thousands concurrent?connection establishment. Is there known?limitation around it?? An alternative way, Call?recvfrom?from listener thread, pass the buffer and peer remote addresses to service thread, make new SSL object and Mem BIO and call??DTLSv1_Listen/?SSL_accept methods. Later use, Mem BIO and recvfrom and sendto?calls for data exchange. Could you please help me decide the better way? Regards,Anand Choubey On Monday, November 27, 2017, 8:21:46 PM GMT+5:30, Anand Choubey via openssl-users wrote: Hi, OpenSSL version is 1.1.0e. I am writing high-performance?DTLS server which can accept thousands of connections concurrently.?? Originally, I decided, DTLSv1_listen would be called inside the listener thread, once?DTLSv1_listen returns 1 i.e. successful, a new async socket will be created, it will be bound (using bind) and connected (using?BIO_connect) with?DTLSv1_listen returned address.?This new socket will be passed to service thread, BIO_set_fd will set this fd and SSL_accept will be called from service thread to complete the remaining handshake and data exchange etc. But behavior is not same as above, I have to call?SSL_accept? after bind and connect inside the listen, where DTLS handshake is completed. If SSL_accept is not called then?DTLSv1_listen is continuously called and always return 1 in listener thread.? Could you please guide to resolve this issue or how to write multi-threaded dtls server where connection acceptance can be done inside the listener thread using?DTLSv1_listen? Thanks in Advance,Anand -- 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 Nov 28 14:04:03 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 28 Nov 2017 14:04:03 +0000 Subject: [openssl-users] DTLS in multi-thread and concurrent connection acceptance environment In-Reply-To: <1477119098.3173296.1511877662922@mail.yahoo.com> References: <421331336.2441020.1511794232152.ref@mail.yahoo.com> <421331336.2441020.1511794232152@mail.yahoo.com> <1477119098.3173296.1511877662922@mail.yahoo.com> Message-ID: <50aaef27-25b8-d442-26ae-cd2f9ca2c23c@openssl.org> On 28/11/17 14:01, Anand Choubey via openssl-users wrote: > But I do not know, whether?DTLSv1_Listen/SSL_accept in the listener > thread?is capable to deal with thousands concurrent?connection > establishment. Is there known?limitation around it?? I don't know if anyone has ever created any metrics on how far it can be scaled. I've certainly not seen it if they have. But there are no known limitations on this approach (this is the intended way to do things). Matt From openssl-users at dukhovni.org Tue Nov 28 21:11:07 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 28 Nov 2017 21:11:07 +0000 Subject: [openssl-users] SSL alert number 48 In-Reply-To: References: Message-ID: <20171128211107.GA3322@mournblade.imrryr.org> On Tue, Nov 28, 2017 at 10:03:12AM +0000, wizard2010 at gmail.com wrote: > I guess my problem is really related to verify callback > on SSL_CTX_set_verify function. > I just add to my code a dummy callback returning 1 and everything works > properly. > > > > int verify_callback (int ok, X509_STORE_CTX *ctx); > > int verify_callback (int ok, X509_STORE_CTX *ctx) > > { > > printf("Verification callback OK!\n"); > > return 1; > > } > > ... > > SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER | > > SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback); The above completely disables authentication of the peer certificate, and makes your application vulnerable to man-in-the-middle attacks. Perhaps that's OK, but often it is not. > The problem is that error don't tell much information about what's really > going on or what's really missing. When the verification callback is failing, the peer's certificate chain is either incomplete or is using a trust-anchor (root CA) that is not configured as trusted on your end. -- Viktor. From janjust at nikhef.nl Wed Nov 29 08:56:35 2017 From: janjust at nikhef.nl (Jan Just Keijser) Date: Wed, 29 Nov 2017 09:56:35 +0100 Subject: [openssl-users] SSL alert number 48 In-Reply-To: References: Message-ID: <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl> Hi, On 28/11/17 11:03, wizard2010 at gmail.com wrote: > Hi there. > > I guess my problem is really related to verify callback on?SSL_CTX_set_verify function. > I just add to my code a dummy callback returning 1 and everything works properly. > > > int verify_callback (int ok, X509_STORE_CTX *ctx); > int verify_callback (int ok, X509_STORE_CTX *ctx) > { > printf("Verification callback OK!\n"); > ? ? return 1; > } > ... > SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback); > ... > > > The problem is that error don't tell much information about what's really going on or what's really missing. > Thanks for your help. > Now you've effectively disabled all security :) Try adding this to the verify_callback static int verify_callback(int ok, X509_STORE_CTX *ctx) { ??? X509?????????? *cert = NULL; ??? char?????????? *cert_DN = NULL; ??? printf("ok = %d\n", ok); ??? cert??? = X509_STORE_CTX_get_current_cert(ctx); ??? cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0 ); ??? printf( "cert DN: %s\n", cert_DN); } that way, you will know whether your server is processing the right certificate chain. HTH, JJK -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanumesh at in.ibm.com Wed Nov 29 12:30:10 2017 From: sanumesh at in.ibm.com (Sandeep Umesh) Date: Wed, 29 Nov 2017 18:00:10 +0530 Subject: [openssl-users] FIPS certification for openssl Message-ID: Hello As per this blog: https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/ Steve who is instrumental in handling FIPS certification for openssl object module is no more associated with OSF. How can we proceed for future FIPS certification ? Is there any other contact person to perform FIPS certification for openssl object module ? Thanks Regards Sandeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From wizard2010 at gmail.com Wed Nov 29 13:37:44 2017 From: wizard2010 at gmail.com (wizard2010 at gmail.com) Date: Wed, 29 Nov 2017 13:37:44 +0000 Subject: [openssl-users] SSL alert number 48 In-Reply-To: <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl> References: <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl> Message-ID: Hi JJK, I test you function and I've got this result: > ok = 0 > cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd > ok = 1 > cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd Why I see this 2 time? When I create the certificates I didn't fill with any special information, just type enter in every question that is made. Did you think this could cause this issue? Kind regards. On Wed, Nov 29, 2017 at 8:56 AM, Jan Just Keijser wrote: > Hi, > > On 28/11/17 11:03, wizard2010 at gmail.com wrote: > > Hi there. > > I guess my problem is really related to verify callback > on SSL_CTX_set_verify function. > I just add to my code a dummy callback returning 1 and everything works > properly. > > >> int verify_callback (int ok, X509_STORE_CTX *ctx); >> int verify_callback (int ok, X509_STORE_CTX *ctx) >> { >> printf("Verification callback OK!\n"); >> return 1; >> } >> ... >> SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER | >> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback); >> ... > > > The problem is that error don't tell much information about what's really > going on or what's really missing. > Thanks for your help. > > Now you've effectively disabled all security :) > > Try adding this to the verify_callback > > > static int verify_callback(int ok, X509_STORE_CTX *ctx) > { > X509 *cert = NULL; > char *cert_DN = NULL; > > printf("ok = %d\n", ok); > cert = X509_STORE_CTX_get_current_cert(ctx); > cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0 ); > printf( "cert DN: %s\n", cert_DN); > > } > > > that way, you will know whether your server is processing the right > certificate chain. > > HTH, > > JJK > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wizard2010 at gmail.com Wed Nov 29 13:44:01 2017 From: wizard2010 at gmail.com (wizard2010 at gmail.com) Date: Wed, 29 Nov 2017 13:44:01 +0000 Subject: [openssl-users] SSL alert number 48 In-Reply-To: <20171128211107.GA3322@mournblade.imrryr.org> References: <20171128211107.GA3322@mournblade.imrryr.org> Message-ID: On Tue, Nov 28, 2017 at 9:11 PM, Viktor Dukhovni wrote: > On Tue, Nov 28, 2017 at 10:03:12AM +0000, wizard2010 at gmail.com wrote: > > > I guess my problem is really related to verify callback > > on SSL_CTX_set_verify function. > > I just add to my code a dummy callback returning 1 and everything works > > properly. > > > > > > > int verify_callback (int ok, X509_STORE_CTX *ctx); > > > int verify_callback (int ok, X509_STORE_CTX *ctx) > > > { > > > printf("Verification callback OK!\n"); > > > return 1; > > > } > > > ... > > > SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER | > > > SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback); > > The above completely disables authentication of the peer certificate, > and makes your application vulnerable to man-in-the-middle attacks. > Perhaps that's OK, but often it is not. > Why did you say that code disable the authentication? One thing that I didn't understand is what type of verification is made on SSL_CTX_set_verify function. And what is supposed/right thing to do on verify_callback in order to perform the client certificate authentication? Kind regards. > > The problem is that error don't tell much information about what's really > > going on or what's really missing. > > When the verification callback is failing, the peer's certificate > chain is either incomplete or is using a trust-anchor (root CA) > that is not configured as trusted on your end. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Nov 29 13:50:53 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Nov 2017 13:50:53 +0000 Subject: [openssl-users] SSL alert number 48 In-Reply-To: References: <20171128211107.GA3322@mournblade.imrryr.org> Message-ID: <20171129135052.GG3322@mournblade.imrryr.org> On Wed, Nov 29, 2017 at 01:44:01PM +0000, wizard2010 at gmail.com wrote: > > > > int verify_callback (int ok, X509_STORE_CTX *ctx) > > > > { > > > > printf("Verification callback OK!\n"); > > > > return 1; > > > > } > > > > ... > > > > SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER | > > > > SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback); > > > > The above completely disables authentication of the peer certificate, > > and makes your application vulnerable to man-in-the-middle attacks. > > Perhaps that's OK, but often it is not. > > Why did you say that code disable the authentication? Because it is true. Your verification callback overrides all certificate verification failures by unconditionally returning "1" for success, regardless of the "ok" value, or the error status in the X509_STORE_CTX. > One thing that I didn't understand is what type of verification is made on > SSL_CTX_set_verify function. Clearly not, so you need to either find some documentation that makes it clear to you (manpages, examples in other code, a book, ...) or not use that feature. Calling functions whose meaning you do not understand is a bad idea, especially in security-related code. > And what is supposed/right thing to do on verify_callback in order to > perform the client certificate authentication? The right thing normally is not have a callback at all. Or always return the passed-in "ok" value, but log some information about the certificate chain and any errors reported. In rare situations you might choose to ignore very specific error conditions, but getting that right requries a deeper understanding of the implications. -- Viktor. From openssl-users at dukhovni.org Wed Nov 29 13:54:10 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Nov 2017 13:54:10 +0000 Subject: [openssl-users] SSL alert number 48 In-Reply-To: <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl> References: <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl> Message-ID: <20171129135409.GH3322@mournblade.imrryr.org> On Wed, Nov 29, 2017 at 09:56:35AM +0100, Jan Just Keijser wrote: > Try adding this to the verify_callback > > > static int verify_callback(int ok, X509_STORE_CTX *ctx) > { > ??? X509?????????? *cert = NULL; > ??? char?????????? *cert_DN = NULL; > > ??? printf("ok = %d\n", ok); > ??? cert??? = X509_STORE_CTX_get_current_cert(ctx); > ??? cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0 ); > ??? printf( "cert DN: %s\n", cert_DN); > > } You've left out the final "return ok;", and there's a new memory leak. Closer would be: static int verify_callback(int ok, X509_STORE_CTX *ctx) { ??? X509?????????? *cert = NULL; ??? char?????????? *cert_DN = NULL; ??? printf("ok = %d\n", ok); ??? cert??? = X509_STORE_CTX_get_current_cert(ctx); ??? cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0 ); ??? printf( "cert DN: %s\n", cert_DN); OPENSSL_free(cert_DN); return ok; } -- Viktor. From Michael.Wojcik at microfocus.com Wed Nov 29 13:58:18 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 29 Nov 2017 13:58:18 +0000 Subject: [openssl-users] FIPS certification for openssl In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Sandeep Umesh > Sent: Wednesday, November 29, 2017 07:30 > To: openssl-users at openssl.org; info at openssl.org > As per this blog: > https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/ Thanks for pointing that out. I somehow hadn't even noticed there was an official OpenSSL blog (I'm now subscribed). I see from it that Steve Henson is also leaving (or has left) the project. > Steve who is instrumental in handling FIPS certification for openssl object module is no more associated with OSF. > How can we proceed for future FIPS certification ? Is there any other contact person to perform FIPS certification for > openssl object module ? In homage to Steve, I'd like to point out that there's no such thing as "FIPS certification". Presumably you mean FIPS validation. I assume that the OpenSSL Management Committee will find someone else to take on the various roles Steve Marquess filled over the years, including shepherding the FIPS validations through. Now that the OpenSSL Project is bigger and better-funded, it's quite possible FIPS validation, and other aspects, won't be as closely associated with a single person as they historically were. And that's good, generally speaking; they should be owned by the Project and the OMC. While I'm sure we're all grateful to Steve M for his work with OpenSSL over the years - and I for one will miss hearing from him on this list, on matters FIPS-related and others - for a project as important as OpenSSL it's not really healthy for users to see aspects of it as tied to an individual. That said, it wouldn't hurt for the OMC to post a message to the list stating that business will continue as planned, since two very key figures have left the project. -- Michael Wojcik Distinguished Engineer, Micro Focus From wizard2010 at gmail.com Wed Nov 29 13:58:59 2017 From: wizard2010 at gmail.com (wizard2010 at gmail.com) Date: Wed, 29 Nov 2017 13:58:59 +0000 Subject: [openssl-users] SSL alert number 48 In-Reply-To: <20171129135409.GH3322@mournblade.imrryr.org> References: <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl> <20171129135409.GH3322@mournblade.imrryr.org> Message-ID: On Wed, Nov 29, 2017 at 1:54 PM, Viktor Dukhovni wrote: > On Wed, Nov 29, 2017 at 09:56:35AM +0100, Jan Just Keijser wrote: > > > Try adding this to the verify_callback > > > > > > static int verify_callback(int ok, X509_STORE_CTX *ctx) > > { > > X509 *cert = NULL; > > char *cert_DN = NULL; > > > > printf("ok = %d\n", ok); > > cert = X509_STORE_CTX_get_current_cert(ctx); > > cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0 > ); > > printf( "cert DN: %s\n", cert_DN); > > > > } > > You've left out the final "return ok;", and there's a new memory > leak. Closer would be: > > static int verify_callback(int ok, X509_STORE_CTX *ctx) > { > X509 *cert = NULL; > char *cert_DN = NULL; > > printf("ok = %d\n", ok); > cert = X509_STORE_CTX_get_current_cert(ctx); > cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, > 0 ); > printf( "cert DN: %s\n", cert_DN); > > OPENSSL_free(cert_DN); > return ok; > } > > With that code I've got this: > ok = 0 > cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd > Handshake Error 1 > I can't really understand why this is happen since I'm creating the certificates with the right way (at least I guess I'm doing this in the right way). Thanks for your help. Kind regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Nov 29 14:12:16 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 29 Nov 2017 14:12:16 +0000 Subject: [openssl-users] FIPS certification for openssl In-Reply-To: References: Message-ID: <152EC153-CC2D-4275-B34F-77E06348959D@akamai.com> We are no longer doing additional platforms for the existing certifications. We are working on a plan for future FIPS validation, based on the 1.1.x line. From: Sandeep Umesh Reply-To: openssl-users Date: Wednesday, November 29, 2017 at 7:30 AM To: openssl-users , "info at openssl.org" Subject: [openssl-users] FIPS certification for openssl Hello As per this blog: https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/ Steve who is instrumental in handling FIPS certification for openssl object module is no more associated with OSF. How can we proceed for future FIPS certification ? Is there any other contact person to perform FIPS certification for openssl object module ? Thanks Regards Sandeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwithopf at adiscon.com Wed Nov 29 15:33:39 2017 From: pwithopf at adiscon.com (Pascal Withopf) Date: Wed, 29 Nov 2017 16:33:39 +0100 Subject: [openssl-users] Problem verifying a certificate chain Message-ID: Hi, I'm reading the book "Network Security with OpenSSL" published by O'Reilly at the moment. I'm following the example program and trying to establish a connection between a server and a client. I did the following to create my certificates: To create the root CA: $ openssl req -newkey rsa:1024 -sha1 -nodes -keyout rootkey.pem -out rootreq.pem $ openssl x509 -req -in rootreq.pem -sha1 -extensions v3_ca -signkey rootkey.pem -out rootcert.pem $ cat rootcert.pem rootkey.pem > root.pem To create the server CA and sign it with the root CA: $ openssl req -newkey rsa:1024 -sha1 -nodes -keyout serverCAkey.pem -out serverCAreq.pem $ openssl x509 -req -in serverCAreq.pem -sha1 -extensions v3_ca -CA root.pem -CAkey root.pem -CAcreateserial -out serverCAcert.pem $ cat serverCAcert.pem serverCAkey.pem rootcert.pem > serverCA.pem To create the server's certificate and sign it with the Server CA: $ openssl req -newkey rsa:1024 -sha1 -nodes -keyout serverkey.pem -out serverreq.pem $ openssl x509 -req -in serverreq.pem -sha1 -extensions usr_cert -CA serverCA.pem -CAkey serverCA.pem -CAcreateserial -out servercert.pem $ cat servercert.pem serverkey.pem serverCAcert.pem rootcert.pem > server.pem Which means I have the following certificate chain: root.pem -> serverCA.pem -> server.pem But when I try to make a connection I see following error at the client side: Error with certificate at depth: 1 issuer = /C=XX/ST=XX/L=test/O=Testorganisation/CN=Root CA subject = /C=XX/ST=XX/L=test/O=Testorganisation/CN=Server CA err 24:invalid CA certificate I get the same error with this command: $ openssl verify -CAfile root.pem -untrusted serverCA.pem server.pem server.pem: C = XX, ST = XX, L = test, O = Testorganisation, CN = Server CA error 24 at 1 depth lookup:invalid CA certificate OK When I sign my server certificate directly with the root CA and leave the server CA out everything works fine. Did I do something wrong creating the certificates? Or where could the problem be? Best Regards Pascal Withopf -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Nov 29 15:48:29 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Nov 2017 15:48:29 +0000 Subject: [openssl-users] Problem verifying a certificate chain In-Reply-To: References: Message-ID: <20171129154829.GK3322@mournblade.imrryr.org> On Wed, Nov 29, 2017 at 04:33:39PM +0100, Pascal Withopf wrote: > Which means I have the following certificate chain: > root.pem -> serverCA.pem -> server.pem > > But when I try to make a connection I see following error at the client > side: > Error with certificate at depth: 1 > issuer = /C=XX/ST=XX/L=test/O=Testorganisation/CN=Root CA > subject = /C=XX/ST=XX/L=test/O=Testorganisation/CN=Server CA > err 24:invalid CA certificate The intermediate CA extensions are likely incorrect. Post the certificate in question. > Did I do something wrong creating the certificates? Likely yes. -- Viktor. From pwithopf at adiscon.com Wed Nov 29 15:57:05 2017 From: pwithopf at adiscon.com (Pascal Withopf) Date: Wed, 29 Nov 2017 16:57:05 +0100 Subject: [openssl-users] Problem verifying a certificate chain In-Reply-To: <20171129154829.GK3322@mournblade.imrryr.org> References: <20171129154829.GK3322@mournblade.imrryr.org> Message-ID: $ openssl x509 -in serverCA.pem -noout -purpose gave me this Certificate purposes: SSL client : Yes SSL client CA : No SSL server : Yes SSL server CA : No Netscape SSL server : Yes Netscape SSL server CA : No S/MIME signing : Yes S/MIME signing CA : No S/MIME encryption : Yes S/MIME encryption CA : No CRL signing : Yes CRL signing CA : No Any Purpose : Yes Any Purpose CA : Yes OCSP helper : Yes OCSP helper CA : No Time Stamp signing : No Time Stamp signing CA : No If the purpose is incorrect how can I set it? 2017-11-29 16:48 GMT+01:00 Viktor Dukhovni : > On Wed, Nov 29, 2017 at 04:33:39PM +0100, Pascal Withopf wrote: > > > Which means I have the following certificate chain: > > root.pem -> serverCA.pem -> server.pem > > > > But when I try to make a connection I see following error at the client > > side: > > Error with certificate at depth: 1 > > issuer = /C=XX/ST=XX/L=test/O=Testorganisation/CN=Root CA > > subject = /C=XX/ST=XX/L=test/O=Testorganisation/CN=Server CA > > err 24:invalid CA certificate > > The intermediate CA extensions are likely incorrect. Post > the certificate in question. > > > Did I do something wrong creating the certificates? > > Likely yes. > > -- > Viktor. > -- > 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 Wed Nov 29 16:17:22 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 29 Nov 2017 17:17:22 +0100 Subject: [openssl-users] FIPS certification for openssl In-Reply-To: References: Message-ID: <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com> On 29/11/2017 14:58, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Sandeep Umesh >> Sent: Wednesday, November 29, 2017 07:30 >> To: openssl-users at openssl.org; info at openssl.org >> As per this blog: >> https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/ > Thanks for pointing that out. I somehow hadn't even noticed there was an official OpenSSL blog (I'm now subscribed). I see from it that Steve Henson is also leaving (or has left) the project. > >> Steve who is instrumental in handling FIPS certification for openssl object module is no more associated with OSF. >> How can we proceed for future FIPS certification ? Is there any other contact person to perform FIPS certification for >> openssl object module ? > In homage to Steve, I'd like to point out that there's no such thing as "FIPS certification". Presumably you mean FIPS validation. > > I assume that the OpenSSL Management Committee will find someone else to take on the various roles Steve Marquess filled over the years, including shepherding the FIPS validations through. Now that the OpenSSL Project is bigger and better-funded, it's quite possible FIPS validation, and other aspects, won't be as closely associated with a single person as they historically were. > > And that's good, generally speaking; they should be owned by the Project and the OMC. While I'm sure we're all grateful to Steve M for his work with OpenSSL over the years - and I for one will miss hearing from him on this list, on matters FIPS-related and others - for a project as important as OpenSSL it's not really healthy for users to see aspects of it as tied to an individual. > > That said, it wouldn't hurt for the OMC to post a message to the list stating that business will continue as planned, since two very key figures have left the project. > Indeed, over the past few years I have seen an increasing tendency to hide monumental news in the blog, in press releases etc. Anywhere but the well established and independently archived public mailing lists. One really has to wonder if this is still OpenSSL that the world has known and loved for 20 years, or just some expensive imitation. 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 rsalz at akamai.com Wed Nov 29 16:53:43 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 29 Nov 2017 16:53:43 +0000 Subject: [openssl-users] FIPS certification for openssl In-Reply-To: <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com> References: <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com> Message-ID: <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com> > That said, it wouldn't hurt for the OMC to post a message to the list stating that business will continue as planned, since two very key figures have left the project. I have two reactions, just my personal view. First, it?s premature to say anything, we?re still figuring things out. Second, what open source project can guarantee that things will continue as they were after people left? Or the larger question, what guarantees can any project really make? ? Indeed, over the past few years I have seen an increasing tendency to hide monumental news in the blog, in press releases etc. To pick a nit, it?s just the blog. The press release was copied to the blog, and I don?t know of anything that would qualify as ?etc? -- can you remind me? We started using the blog because we thought it would be a better way to get higher-quality information out, without being swallowed up by the volume of email messages. ? Anywhere but the well established and independently archived public mailing lists. It?s not the same Internet that it used to be? Lots of discussion happens on GitHub issues these days, which I?m not thrilled with either. (Hey you kids, get off my lawn.) It seems that posting a note to the lists would be useful whenever we post a blog entry? > One really has to wonder if this is still OpenSSL that the world has known and loved for 20 years, or just some expensive imitation. I am biased, but I believe the project is better, by almost any metric, then it used to be. If you have specific suggestions for how you think it could be improved, it would be great to see them. From mark at fips.pro Wed Nov 29 17:32:44 2017 From: mark at fips.pro (Mark Minnoch) Date: Wed, 29 Nov 2017 09:32:44 -0800 Subject: [openssl-users] FIPS certification for openssl Message-ID: If you need a FIPS resource for the OpenSSL FIPS Object Module -- my business partner (Steve Weymann) and I worked with Steve Marquess when we were at a FIPS Testing Lab to achieve the FIPS 140-2 Cert. #1747 for the OpenSSL FIPS Object Module. We are now helping technology companies that need FIPS testing of the OpenSSL FOM on specific operating systems. We also perform Private Label validations to rebrand the OpenSSL FOM for our clients. Mark J. Minnoch Co-Founder, CISSP, CISA KeyPair Consulting +1 (805) 550-3231 mobile https://KeyPair.us https://www.linkedin.com/in/minnoch *We expertly guide technology companies in achieving their FIPS 140 goals* -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Nov 29 17:38:59 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Nov 2017 12:38:59 -0500 Subject: [openssl-users] Problem verifying a certificate chain In-Reply-To: References: <20171129154829.GK3322@mournblade.imrryr.org> Message-ID: <7548F499-C526-47EF-83BE-0647A7199FD8@dukhovni.org> > On Nov 29, 2017, at 10:57 AM, Pascal Withopf wrote: > > $ openssl x509 -in serverCA.pem -noout -purpose > > ... > > If the purpose is incorrect how can I set it? > > 2017-11-29 16:48 GMT+01:00 Viktor Dukhovni : > On Wed, Nov 29, 2017 at 04:33:39PM +0100, Pascal Withopf wrote: > >>> err 24:invalid CA certificate >> >> The intermediate CA extensions are likely incorrect. Post >> the certificate in question. Post the certificate in question. -- Viktor. From Michael.Wojcik at microfocus.com Wed Nov 29 22:51:43 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 29 Nov 2017 22:51:43 +0000 Subject: [openssl-users] FIPS certification for openssl In-Reply-To: <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com> References: <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com> <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Salz, Rich via openssl-users > Sent: Wednesday, November 29, 2017 11:54 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] FIPS certification for openssl > [I wrote:] > > That said, it wouldn't hurt for the OMC to post a message to the list stating > > that business will continue as planned, since two very key figures have left > > the project. > > I have two reactions, just my personal view. First, it?s premature to say > anything, we?re still figuring things out. Second, what open source project > can guarantee that things will continue as they were after people left? Or > the larger question, what guarantees can any project really make? That's fair. And on further consideration I'll withdraw the "to the list" part. [Jakob wrote:] > > Anywhere but the well established and independently archived public > > mailing lists. > > It?s not the same Internet that it used to be? Lots of discussion happens on > GitHub issues these days, which I?m not thrilled with either. (Hey you kids, > get off my lawn.) It seems that posting a note to the lists would be useful > whenever we post a blog entry? I can't speak for Jakob, of course. I was surprised to learn of the blog posts, because I hadn't been following the blog; if I knew it existed at some point, I'd forgotten. But I'm following it now. It probably wouldn't hurt to post something to the lists when there's a blog post with news like this - items that subscribers would likely feel is important. Blog posts like the recent "OpenSSL in China" series probably don't need to be mentioned on the lists. But it's subjective, and I wouldn't want to create more work for anyone. -- Michael Wojcik Distinguished Engineer, Micro Focus From rsalz at akamai.com Wed Nov 29 23:01:35 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 29 Nov 2017 23:01:35 +0000 Subject: [openssl-users] FIPS certification for openssl In-Reply-To: References: <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com> <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com> Message-ID: ? It probably wouldn't hurt to post something to the lists when there's a blog post with news like this - items that subscribers would likely feel is important. Blog posts like the recent "OpenSSL in China" series probably don't need to be mentioned on the lists. But it's subjective, and I wouldn't want to create more work for anyone. It?s a lot easier than writing the blog posts ( We should have been doing this from the very beginning, oops. We?ll try to do better. From openssl at jordan.maileater.net Thu Nov 30 00:55:43 2017 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 29 Nov 2017 16:55:43 -0800 Subject: [openssl-users] FIPS certification for openssl In-Reply-To: <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com> References: <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com> <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com> Message-ID: <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net> On 11/29/2017 8:53 AM, Salz, Rich via openssl-users wrote: > I am biased, but I believe the project is better, by almost any > metric, then it used to be. If you have specific suggestions for how > you think it could be improved, it would be great to see them. My number one complaint is that it seems like the defaults are generally set up to do the wrong things, and the application has to either explicitly set "yes, you should be secure" options or do stuff on its own.? This seems to have been getting better - gaining hostname validation, for instance - but really a client should be able to say "give me a secure connection to host:port" and have sensible and secure things happen with a single call.? Maybe two, one to create a handle and the other to actually set up the connection (to allow for intervening calls that customize the connection). -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Nov 30 02:13:14 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 30 Nov 2017 02:13:14 +0000 Subject: [openssl-users] FIPS certification for openssl In-Reply-To: <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net> References: <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com> <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com> <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net> Message-ID: <0D2E376C-E755-4105-B282-87F19F496092@akamai.com> > My number one complaint is that it seems like the defaults are generally set up to do the wrong things, and the application has to either explicitly set "yes, you should be secure" options or do stuff on its own. This seems to have been getting better - gaining hostname validation, for instance - but really a client should be able to say "give me a secure connection to host:port" and have sensible and secure things happen with a single call. Maybe two, one to create a handle and the other to actually set up the connection (to allow for intervening calls that customize the connection). I agree with you, but a problem is that ?safe and secure? changes over time when new crypto and other new features are added. And then users get upset when their connections no longer work. I think the right approach is to be able to specify a policy, then at least you know what you?re signing up for. Right now it?s a collection of low-level things. And the policy is ?SECLEVEL? which ain?t great. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at jordan.maileater.net Thu Nov 30 05:34:10 2017 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 29 Nov 2017 21:34:10 -0800 Subject: [openssl-users] FIPS certification for openssl In-Reply-To: <0D2E376C-E755-4105-B282-87F19F496092@akamai.com> References: <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com> <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com> <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net> <0D2E376C-E755-4105-B282-87F19F496092@akamai.com> Message-ID: On 11/29/2017 6:13 PM, Salz, Rich via openssl-users wrote: > I agree with you, but a problem is that ?safe and secure? changes over > time when new? crypto and other new features are added. And then users > get upset when their connections no longer work. Agreed, that's a tough trade-off. Still, I'd rather have compatibility problems - as long as there's a way to explicitly request the less-secure option - than silently be insecure. Having per-user or system-wide configuration files that are consulted under the covers would help, since then the user could revert to less-secure settings without needing the application source.? Maybe have the "create handle" function take an application name as an argument, so that individual applications could be managed separately. Looking at it another way:? browsers manage to do it... -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwithopf at adiscon.com Thu Nov 30 07:46:27 2017 From: pwithopf at adiscon.com (Pascal Withopf) Date: Thu, 30 Nov 2017 08:46:27 +0100 Subject: [openssl-users] Problem verifying a certificate chain In-Reply-To: <7548F499-C526-47EF-83BE-0647A7199FD8@dukhovni.org> References: <20171129154829.GK3322@mournblade.imrryr.org> <7548F499-C526-47EF-83BE-0647A7199FD8@dukhovni.org> Message-ID: Here is serverCA.pem as a file and as text -----BEGIN CERTIFICATE----- MIICJTCCAY4CCQCS+4ZH1+sfwzANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJY WDELMAkGA1UECAwCWFgxDTALBgNVBAcMBHRlc3QxGTAXBgNVBAoMEFRlc3Rvcmdh bmlzYXRpb24xEDAOBgNVBAMMB1Jvb3QgQ0EwHhcNMTcxMTMwMDczMDEzWhcNMTcx MjMwMDczMDEzWjBYMQswCQYDVQQGEwJYWDELMAkGA1UECAwCWFgxDTALBgNVBAcM BHRlc3QxGTAXBgNVBAoMEFRlc3RvcmdhbmlzYXRpb24xEjAQBgNVBAMMCVNlcnZl ciBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAuvN7K+Pm7eTskAGZBVli lBbr8P0Hjl0TOIUEckgFSHbCC7tjecdJS9IzXXVv8nnHVdsjTbZKiYK2/6od0gcb TWjI9T2HtnYFvUoKedgn4A2np3s5E4V707ACyw49J9mmiqBlfKg6cnOpYa+ZOZfl 95yNPUq9rK9KgDHXRseaP2UCAwEAATANBgkqhkiG9w0BAQUFAAOBgQCq0JJnFwD+ M3+5lCxjbs7PAiV32d8eiT9r/QJUcwQ2VMFapTUnS51VVfGf1HIQmuA9QuKKr4Cq AJIWPRZJmt+UE2PfUJlQhx6gUl7siyNMKOj48/wQ/I1yHT9ArIlCGNWAA9+tJP90 w07g3qwBet+wYmcbhYS9xNSJeUEhRtZZBg== -----END CERTIFICATE----- -----BEGIN PRIVATE KEY----- MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBALrzeyvj5u3k7JAB mQVZYpQW6/D9B45dEziFBHJIBUh2wgu7Y3nHSUvSM111b/J5x1XbI022SomCtv+q HdIHG01oyPU9h7Z2Bb1KCnnYJ+ANp6d7OROFe9OwAssOPSfZpoqgZXyoOnJzqWGv mTmX5fecjT1KvayvSoAx10bHmj9lAgMBAAECgYAa021NMvqkEEFRuKj4d4cJsPBS ODypVPm5Fn042NTJPSFDBbSUeOAvnQ35zywtIwRTcYpzUEEJ0lPoA8UbqiFkjvpb KtsyHmxxoCcyX7YWCCS0N7Z1pMzqTJNlpoLGt9l4hysqI87oiQxhr+wqcFimUXCn cWFXqX+L0nWHv1AUAQJBAPXcn9dftsvqvjkL5lwxw0VZzuvt/B3zrPt0iGWnLWOb OBfPs2mhe4dbxOH/V/Z9d2fQ5D13xzYBE/SjgWrXz6UCQQDCqPs0jAq6JsFPQc0d 3jfV10FM6BLZ58fuOJzEczWETbwjpxBgpsjBREhL3OSqXKsNPJiWj83gUXHYxNxs jaTBAkEAnMVyksWwbLShWQTSfcUpa4ZJoD0e/wZLLgfvlUoVcicejGhfUaKrfvMw Rp8oOr9kLSmQ7/T5bOEhFWRQ+IzmFQJANPxoPHpuJRONhPRlT98AFc4c8UEueG/1 5Os2COdPRu8d6hp8g8KCXNEoWLYM7C6DRPwckMceBBRHR/j2AvpfQQJBAKu0I6XE CZxyoPv1mRqTR7rU2dUQfrKGOccj8h8HFLbq2oWp+I9dnwRrWaPGlrmBLzoc49Fz qpj4m4Bv4xA94Uc= -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIICIzCCAYwCCQC1OoUz04RMqDANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJY WDELMAkGA1UECAwCWFgxDTALBgNVBAcMBHRlc3QxGTAXBgNVBAoMEFRlc3Rvcmdh bmlzYXRpb24xEDAOBgNVBAMMB1Jvb3QgQ0EwHhcNMTcxMTMwMDcyOTA0WhcNMTcx MjMwMDcyOTA0WjBWMQswCQYDVQQGEwJYWDELMAkGA1UECAwCWFgxDTALBgNVBAcM BHRlc3QxGTAXBgNVBAoMEFRlc3RvcmdhbmlzYXRpb24xEDAOBgNVBAMMB1Jvb3Qg Q0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMJnOIgoR56VGV+3waIP6xqX fD31MUXL0+24W8QL6N7fSrpNbGwB8koUMAYIibMGL/d0WvkbzNq7415J87Qz7VDv VWvuDsl8QNixHqN2HhUPwBTGUPMVR7Zda3oH0YstXgrf05bnMjTkK/m39mOE7PrN d9R++4btVwLuhlfO8WNnAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAmlpfCIlsO+hw PcyIF48wPXrd9/UWf8bNWMQ0wsMJCIxlHzb+dHaM/2B06oRbwfwvj/rdcA4hueJF HY1fvva2E7YEpaGAKoT1LKQhadyJBf5a7UIhEzUV/OUsIfYCDzmF4DmwI5biBZpy S887uY+40OP1b1NXktdPF3ejjYKZC7U= -----END CERTIFICATE----- 2017-11-29 18:38 GMT+01:00 Viktor Dukhovni : > > > > On Nov 29, 2017, at 10:57 AM, Pascal Withopf > wrote: > > > > $ openssl x509 -in serverCA.pem -noout -purpose > > > > ... > > > > If the purpose is incorrect how can I set it? > > > > 2017-11-29 16:48 GMT+01:00 Viktor Dukhovni : > > On Wed, Nov 29, 2017 at 04:33:39PM +0100, Pascal Withopf wrote: > > > >>> err 24:invalid CA certificate > >> > >> The intermediate CA extensions are likely incorrect. Post > >> the certificate in question. > > Post the certificate in question. > > -- > Viktor. > > -- > 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: serverCA.pem Type: application/octet-stream Size: 2524 bytes Desc: not available URL: From olegst90 at ukr.net Thu Nov 30 10:52:39 2017 From: olegst90 at ukr.net (Oleg Stepanenko) Date: Thu, 30 Nov 2017 12:52:39 +0200 Subject: [openssl-users] Application tags with ASN.1 template engine References: <1512035534.730325833.mqxrv3xh@frv45.fwdcdn.com> Message-ID: <1512039026.704791516.xbjys2s7@frv45.fwdcdn.com> Hello, everybody! I'm trying to use OpenSSL ASN.1 template API (from asn1t.h) to parse ASN.1 objects in my application. The thing is that I have to use application tags instead of default ones: Foo ::= [APPLICATION 13] SEQUENCE { m01 INTEGER, m02 OCTET STRING and the macros (like ASN1_SEQUENCE) don't seem to provide app tags params, or at least I can't get how to do it. The macro?IMPLEMENT_ASN1_FUNCTIONS seems to make use of?ASN1_item_d2i which in turn calls?ASN1_item_ex_d2i passing -1 as tag.? So how do I define Foo parsing functions so that they could regognize the struct by the app tag 13? Should I simply manually tweak generated templates?? What member do I change, then? Can I just reassign the tag member of the template? How do I specify that this is application tag, not universal? Thank you in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Nov 30 13:41:05 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 30 Nov 2017 13:41:05 +0000 Subject: [openssl-users] FIPS certification for openssl In-Reply-To: References: <2091bc11-128e-49c7-75f0-a09a57e56f8d@wisemo.com> <9E309687-E56F-48BB-BC09-7E6C72861C0E@akamai.com> <97d31e0a-bce2-0d38-fcc8-6caa6c03829b@jordan.maileater.net> <0D2E376C-E755-4105-B282-87F19F496092@akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jordan Brown > Sent: Thursday, November 30, 2017 00:34 > On 11/29/2017 6:13 PM, Salz, Rich via openssl-users wrote: > > I agree with you, but a problem is that ?safe and secure? changes over time when new? crypto and other new features > > are added. And then users get upset when their connections no longer work. That, and many applications will reasonably disagree on what an appropriate default is. > Still, I'd rather have compatibility problems - as long as there's a way to explicitly request the less-secure option - than > silently be insecure. But some other people would not prefer compatibility problems. There are a great many OpenSSL consumers. Making radical changes to the default behavior of the API would break many applications - and so it's likely those applications would stop updating their OpenSSL builds. > Having per-user or system-wide configuration files that are consulted under the covers would help, For many applications, no, it really wouldn't. It would be a huge mess. > since then the user could revert to less-secure settings without needing the application source. If the application is well-written, the user doesn't need the application source now. If the application isn't well-written, being able to change "settings" is not one of your bigger problems. > Maybe have the "create handle" function take an application name as an argument, so that individual applications > could be managed separately. And we have another namespace problem. No thanks. > Looking at it another way:? browsers manage to do it... Manage to do what, exactly? And how are browsers a good model for the vast range of OpenSSL applications? They're just one type of client that nearly always uses a very particular PKI model. Not all the world's a VAX. -- Michael Wojcik Distinguished Engineer, Micro Focus From jsouthwell at serengeti.com Thu Nov 30 14:22:05 2017 From: jsouthwell at serengeti.com (Joseph Southwell) Date: Thu, 30 Nov 2017 09:22:05 -0500 Subject: [openssl-users] How to limit advertised maximum ssl version in ssl23 client helo Message-ID: <3E8EB351-4039-421F-B421-9256372A84C5@serengeti.com> So I have a server I connect to that replies ?insufficient security? when I connect with an ssl23 client helo from openssl 1.0.2. However when I connect with any of ssl3-tls1.1 client helo it works. It doesn?t work if I try to connect with a tls1.2 client helo. I am trying to narrow down the problem so I would like to send an ssl23 client helo that only advertises up to 1.1. Any idea how to do just that? From janjust at nikhef.nl Thu Nov 30 14:45:26 2017 From: janjust at nikhef.nl (Jan Just Keijser) Date: Thu, 30 Nov 2017 15:45:26 +0100 Subject: [openssl-users] SSL alert number 48 In-Reply-To: References: <02e5ff66-62b1-d6f6-5765-010cf930b512@nikhef.nl> Message-ID: <642397e5-68c2-f2fc-3b4e-5e9c867d6b17@nikhef.nl> Hi, On 29/11/17 14:37, wizard2010 at gmail.com wrote: > Hi JJK, > > I test you function and I've got this result: > > ok = 0 > cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd > ok = 1 > cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd > > > Why I see this 2 time? > When I create the certificates I didn't fill with any special information, just type enter in every question that is made. Did > you think this could cause this issue? > what you should have seen is the certificate stack, starting with the CA, and then the client cert, e.g. Connection accept... ok = 1 cert DN: /C=US/O=Cookbook 2.4/CN=Cookbook 2.4 CA/emailAddress=openvpn at example.com ok = 1 cert DN: /C=US/O=Cookbook 2.4/CN=client1 so I suspect that your ca.crt on the server side is not specified correctly. You may also send me your ca.crt, server.{crt,key} and client.{crt,key} files privately, and I will run the same test using your set of certificates. HTH, JJK > > On Wed, Nov 29, 2017 at 8:56 AM, Jan Just Keijser > wrote: > > Hi, > > On 28/11/17 11:03, wizard2010 at gmail.com wrote: >> Hi there. >> >> I guess my problem is really related to verify callback on?SSL_CTX_set_verify function. >> I just add to my code a dummy callback returning 1 and everything works properly. >> >> >> int verify_callback (int ok, X509_STORE_CTX *ctx); >> int verify_callback (int ok, X509_STORE_CTX *ctx) >> { >> printf("Verification callback OK!\n"); >> ? ? return 1; >> } >> ... >> SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback); >> ... >> >> >> The problem is that error don't tell much information about what's really going on or what's really missing. >> Thanks for your help. >> > Now you've effectively disabled all security :) > > Try adding this to the verify_callback > > > static int verify_callback(int ok, X509_STORE_CTX *ctx) > { > ??? X509?????????? *cert = NULL; > ??? char?????????? *cert_DN = NULL; > > ??? printf("ok = %d\n", ok); > ??? cert??? = X509_STORE_CTX_get_current_cert(ctx); > ??? cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0 ); > ??? printf( "cert DN: %s\n", cert_DN); > > } > > > that way, you will know whether your server is processing the right certificate chain. > > HTH, > > JJK > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toyashgautam at gmail.com Thu Nov 30 18:24:21 2017 From: toyashgautam at gmail.com (toyash gautam) Date: Thu, 30 Nov 2017 23:54:21 +0530 Subject: [openssl-users] Urgent Issue in debug build of openssl version 0.9.8 on Red Hat Linux 5 machine Message-ID: Hi, I am aware of the fact that this version of openssl is no longer supported, but it is extremely urgent from the customer point of view. I used ./config -d [options], but the release build was made using "-d" as well. "-d" was ignored. Please help if it is possible to build openssl 0.9.8 debug build on the same machine or any other linux machine. Regards, Toyash -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Nov 30 18:54:01 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 30 Nov 2017 13:54:01 -0500 Subject: [openssl-users] Problem verifying a certificate chain In-Reply-To: References: <20171129154829.GK3322@mournblade.imrryr.org> <7548F499-C526-47EF-83BE-0647A7199FD8@dukhovni.org> Message-ID: > On Nov 30, 2017, at 2:46 AM, Pascal Withopf wrote: > > Here is serverCA.pem as a file and as text These are, I expect, test certs and keys, so posting the keys too is presumably not a problem... In any case, the problem is that the CA certificate is a v1 certificate with no extensions. It needs to be a v3 certificate with basicConstraints CA:true, and keyUsage befitting a CA. Certificate: Data: Version: 1 (0x0) Serial Number: 92:fb:86:47:d7:eb:1f:c3 Signature Algorithm: sha1WithRSAEncryption Issuer: C=XX, ST=XX, L=test, O=Testorganisation, CN=Root CA Validity Not Before: Nov 30 07:30:13 2017 GMT Not After : Dec 30 07:30:13 2017 GMT Subject: C=XX, ST=XX, L=test, O=Testorganisation, CN=Server CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:ba:f3:7b:2b:e3:e6:ed:e4:ec:90:01:99:05:59: 62:94:16:eb:f0:fd:07:8e:5d:13:38:85:04:72:48: 05:48:76:c2:0b:bb:63:79:c7:49:4b:d2:33:5d:75: 6f:f2:79:c7:55:db:23:4d:b6:4a:89:82:b6:ff:aa: 1d:d2:07:1b:4d:68:c8:f5:3d:87:b6:76:05:bd:4a: 0a:79:d8:27:e0:0d:a7:a7:7b:39:13:85:7b:d3:b0: 02:cb:0e:3d:27:d9:a6:8a:a0:65:7c:a8:3a:72:73: a9:61:af:99:39:97:e5:f7:9c:8d:3d:4a:bd:ac:af: 4a:80:31:d7:46:c7:9a:3f:65 Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption aa:d0:92:67:17:00:fe:33:7f:b9:94:2c:63:6e:ce:cf:02:25: 77:d9:df:1e:89:3f:6b:fd:02:54:73:04:36:54:c1:5a:a5:35: 27:4b:9d:55:55:f1:9f:d4:72:10:9a:e0:3d:42:e2:8a:af:80: aa:00:92:16:3d:16:49:9a:df:94:13:63:df:50:99:50:87:1e: a0:52:5e:ec:8b:23:4c:28:e8:f8:f3:fc:10:fc:8d:72:1d:3f: 40:ac:89:42:18:d5:80:03:df:ad:24:ff:74:c3:4e:e0:de:ac: 01:7a:df:b0:62:67:1b:85:84:bd:c4:d4:89:79:41:21:46:d6: 59:06 -- Viktor. From openssl-users at dukhovni.org Thu Nov 30 20:25:09 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 30 Nov 2017 15:25:09 -0500 Subject: [openssl-users] How to limit advertised maximum ssl version in ssl23 client helo In-Reply-To: <3E8EB351-4039-421F-B421-9256372A84C5@serengeti.com> References: <3E8EB351-4039-421F-B421-9256372A84C5@serengeti.com> Message-ID: > On Nov 30, 2017, at 9:22 AM, Joseph Southwell wrote: > > So I have a server I connect to that replies ?insufficient security? when I connect with an ssl23 client helo from openssl 1.0.2. However when I connect with any of ssl3-tls1.1 client helo it works. It doesn?t work if I try to connect with a tls1.2 client helo. I am trying to narrow down the problem so I would like to send an ssl23 client helo that only advertises up to 1.1. Any idea how to do just that? OpenSSL 1.1.0 provides controls to explicitly set the maximum and/or minimum SSL/TLS protocol version. In OpenSSL 1.0.2, you can only disable specific versions via SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLS1, SSL_OP_NO_TLSv1_1 or SSL_OP_NO_TLSv1_2, making sure to not introduce "holes"! After disabled protocols are removed the remaining protocols *MUST* form a contiguous range with no gaps in the middle. -- Viktor.