From paliopipis at gmail.com Tue Dec 1 09:14:20 2015 From: paliopipis at gmail.com (findor) Date: Tue, 1 Dec 2015 02:14:20 -0700 (MST) Subject: [openssl-users] OpenSSL - asn1parse how to use offset-hlentgth-length In-Reply-To: <1448913769989-61324.post@n7.nabble.com> References: <1448913769989-61324.post@n7.nabble.com> Message-ID: <1448961260519-61338.post@n7.nabble.com> Here is the attachment, I made a mistake on the original post. X.rtf -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-asn1parse-how-to-use-offset-hlentgth-length-tp61324p61338.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From Wouter.Verhelst at fedict.be Tue Dec 1 13:58:13 2015 From: Wouter.Verhelst at fedict.be (Verhelst Wouter (Consultant)) Date: Tue, 1 Dec 2015 14:58:13 +0100 Subject: [openssl-users] OCSP signature verification Message-ID: <314AD38167954C4BBE91263CA425506D577EFDB231@MAIL2K7CL.yourict.net> Hi folks, I'm trying to write an application that needs to verify the validity of data on a smartcard. That data is signed with an RSA key for which a certificate exists on the card; but if the card is stolen or lost, the certificate will be revoked, so I want to ensure that the certificate is valid. I'm doing an OCSP request to take care of that. Since OpenSSL's own OCSP_sendreq_* functions don't support HTTP proxies, I'm currently using libcurl to send the request to the OCSP endpoint. This seems to work; when I get the reply and use d2i_OCSP_RESPONSE(), then with things like OCSP_response_status() and OCSP_resp_find_status() and friends I can manage to get the status of the request and a given certificate. However, that doesn't do signature verification. I believe that I should use OCSP_basic_verify() for that, but I'm not entirely sure whether that is the case, and if so whether I would need to do some additional checks beforehand. Unfortunately, I can't find any documentation on OCSP_basic_verify(). I should note that due to the nature of my needs, I have a rather huge set of valid intermediate CAs, but a fairly limited set of root CAs that can be used for valid cards (that is, if the signature validates but it wasn't signed by any of the CAs under one of my limited set of roots, the card is a forgery and should be rejected as invalid). A few questions: - Am I right in assuming that OCSP_basic_verify will check the signature on the OCSP request? - In "OCSP_basic_verify(OCSP_BASICRESP *bs, STACK_OF(X509) *certs, X509_STORE *st, unsigned long flags)", I'm not entirely certain of what the "st" argument is meant to contain, and can't figure out the "certs" one. Pouring over the code, I believe the "st" argument should allow me to limit validation to my set of root certificates, but I could be mistaken. As for the "certs" one, I can't understand that one at all. The only thing I can think of is that maybe it should contain the issuer certificate that I used for the original request, but then why is it a STACK_OF(X509)* and not just an X509*? What am I missing? Thanks for any help, -- Wouter Verhelst From Michael.Wojcik at microfocus.com Tue Dec 1 21:57:58 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 1 Dec 2015 21:57:58 +0000 Subject: [openssl-users] long (~2.5 minute) delay in TLS handshake In-Reply-To: <20151130233803.GA10359@roeckx.be> References: <20151130233803.GA10359@roeckx.be> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Kurt Roeckx > Sent: Monday, November 30, 2015 18:38 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] long (~2.5 minute) delay in TLS handshake > > On Mon, Nov 30, 2015 at 10:46:45PM +0000, Michael Wojcik wrote: > > I'm curious if anyone has seen anything like this before. > > > > We have a situation at one customer site. They see it happen every few > days. No one else has reported it, and we can't reproduce it. > > Have you considered that this might be a path MTU discovery issue > and that the TCP layer is just resending the (too large) packet > without it reaching the other side? Interesting suggestion, but the trace was taken on the server, and it's definitely not resending. Just sitting there, as far as this one conversation is concerned. Existing conversations from other clients continue with no problems. It acks the ClientHello, then 2.5 minutes later sends the ServerHello, which the client responds to with an RST (because it's long since gone away). This same client connects successfully about 5 minutes later, with no unusual delays. Pretty odd. -- Michael Wojcik Technology Specialist, Micro Focus From ronc at lanl.gov Tue Dec 1 22:34:09 2015 From: ronc at lanl.gov (Ron Croonenberg) Date: Tue, 1 Dec 2015 15:34:09 -0700 Subject: [openssl-users] explicitly including other ciphers. Message-ID: <565E2061.30302@lanl.gov> Hello, I want to build/compile openssl including the 'eNULL' cipher. I know it's not in ALL or default, because of "security risks". How do I include it and built it (downloaded a version from the github) thanks, Ron From nounou.dadoun at avigilon.com Tue Dec 1 23:28:48 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Tue, 1 Dec 2015 23:28:48 +0000 Subject: [openssl-users] s_client -no_tls1 option Message-ID: <8149AB08BCB1F54F92680ED6104891A0DFC50A@mbx027-w1-ca-4.exch027.domain.local> Getting an unexpected result, does the no_tls1 option for s_client mean "don't use tls1" (and everything else is ok) or does it mean "don't use tls1 or tls1.1 or tls1.2"? I expected the former but I'm observing the latter! (The man page doesn't go into that much detail.) ... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. From bkaduk at akamai.com Tue Dec 1 23:33:41 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 1 Dec 2015 17:33:41 -0600 Subject: [openssl-users] s_client -no_tls1 option In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0DFC50A@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0DFC50A@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <565E2E55.6050804@akamai.com> On 12/01/2015 05:28 PM, Nounou Dadoun wrote: > Getting an unexpected result, does the no_tls1 option for s_client mean "don't use tls1" (and everything else is ok) or does it mean "don't use tls1 or tls1.1 or tls1.2"? I expected the former but I'm observing the latter! (The man page doesn't go into that much detail.) ... N > The latter. The TLS protocol only specifies a maximum version supported by the client (and in practice there are some heuristics using the record protocol version to indicate the minimum version supported), so the client is essentially claiming just a contiguous range. Once 1.0 is removed, the higher versions are as well. (I would have to check to see how this interacts with no_ssl2 and no_ssl3.) -Ben Kaduk From nounou.dadoun at avigilon.com Tue Dec 1 23:48:20 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Tue, 1 Dec 2015 23:48:20 +0000 Subject: [openssl-users] s_client -no_tls1 option In-Reply-To: <565E2E55.6050804@akamai.com> References: <8149AB08BCB1F54F92680ED6104891A0DFC50A@mbx027-w1-ca-4.exch027.domain.local> <565E2E55.6050804@akamai.com> Message-ID: <8149AB08BCB1F54F92680ED6104891A0DFC536@mbx027-w1-ca-4.exch027.domain.local> That makes sense, we've disabled sslv2 and sslv3 and I expected the no_tls1 option to allow a higher version to connect but it wouldn't connect at all. I should have remembered that it's implemented as a contiguous range! Thanks for the quick response .. N -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Benjamin Kaduk Sent: Tuesday, December 01, 2015 3:34 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] s_client -no_tls1 option On 12/01/2015 05:28 PM, Nounou Dadoun wrote: > Getting an unexpected result, does the no_tls1 option for s_client > mean "don't use tls1" (and everything else is ok) or does it mean > "don't use tls1 or tls1.1 or tls1.2"? I expected the former but I'm > observing the latter! (The man page doesn't go into that much > detail.) ... N > The latter. The TLS protocol only specifies a maximum version supported by the client (and in practice there are some heuristics using the record protocol version to indicate the minimum version supported), so the client is essentially claiming just a contiguous range. Once 1.0 is removed, the higher versions are as well. (I would have to check to see how this interacts with no_ssl2 and no_ssl3.) -Ben Kaduk _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl-users at dukhovni.org Wed Dec 2 01:46:23 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 2 Dec 2015 01:46:23 +0000 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <565E2061.30302@lanl.gov> References: <565E2061.30302@lanl.gov> Message-ID: <20151202014623.GR18315@mournblade.imrryr.org> On Tue, Dec 01, 2015 at 03:34:09PM -0700, Ron Croonenberg wrote: > I want to build/compile openssl including the 'eNULL' cipher. I know it's > not in ALL or default, because of "security risks". No need to recompile. > How do I include it and built it (downloaded a version from the github) The eNULL ciphers are available by default, but not in ALL. Just use: "ALL:COMPLEMENTOFALL" or "ALL:eNULL" or just "eNULL" as appropriate. This is documented in ciphers(1). -- Viktor. From openssl-users at dukhovni.org Wed Dec 2 02:10:31 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 2 Dec 2015 02:10:31 +0000 Subject: [openssl-users] s_client -no_tls1 option In-Reply-To: <565E2E55.6050804@akamai.com> References: <8149AB08BCB1F54F92680ED6104891A0DFC50A@mbx027-w1-ca-4.exch027.domain.local> <565E2E55.6050804@akamai.com> Message-ID: <20151202021031.GS18315@mournblade.imrryr.org> On Tue, Dec 01, 2015 at 05:33:41PM -0600, Benjamin Kaduk wrote: > On 12/01/2015 05:28 PM, Nounou Dadoun wrote: > > Getting an unexpected result, does the no_tls1 option for s_client mean "don't use tls1" (and everything else is ok) or does it mean "don't use tls1 or tls1.1 or tls1.2"? I expected the former but I'm observing the latter! (The man page doesn't go into that much detail.) ... N > > > > The latter. > > The TLS protocol only specifies a maximum version supported by the > client (and in practice there are some heuristics using the record > protocol version to indicate the minimum version supported), so the > client is essentially claiming just a contiguous range. Once 1.0 is > removed, the higher versions are as well. (I would have to check to see > how this interacts with no_ssl2 and no_ssl3.) If one also specifies -no_ssl2 and -no_ssl3, then the client will advertise TLS 1.2 and accept either TLS 1.2 or TLS 1.1. -- Viktor. From ant.rao at gmail.com Wed Dec 2 10:21:22 2015 From: ant.rao at gmail.com (Anty Rao) Date: Wed, 2 Dec 2015 18:21:22 +0800 Subject: [openssl-users] Response from server is lost on close In-Reply-To: References: Message-ID: > > Using non-blocking openssl , after detecting underlying TCP is broken, i > invoke SSL_read to attempting reading response. *sometimes* response from > server is lost, sometimes not. But tcpdump show that response is always > send back to me. what is special is that RST packages come next the > response. Can someone shed some light on me, Thanks.Here is the result of > tcpdump: > >> 16:18:00.168274 IP 17.143.161.207.2195 > xx.xxx.xx.xx.43361: Flags [P.], seq 4764:4801, ack 37462, win 432, option s [nop,nop,TS val 1248125705 ecr 2355901348], length 37 0x0000: 4500 0059 c936 4000 3006 14ba 118f a1cf E..Y.6 at .0....... 0x0010: b73c 0214 0893 a961 1e10 133f 2197 3724 .<.....a...?!.7$ 0x0020: 8018 01b0 245e 0000 0101 080a 4a64 e309 ....$^......Jd.. 0x0030: 8c6c 33a4 1503 0100 2012 a99f e30c 37aa .l3...........7. 0x0040: eda1 e24a 1819 74cb 1a73 2396 f76e b9fa ...J..t..s#..n.. 0x0050: 293b 8625 8a9d 09a7 30 );.%....016:18:00.168326 IP 17.143.161.207.2195 > xx.xxx.xx.xx.43361: Flags [R.], seq 4801, ack 37462, win 498, options [no p,nop,TS val 1248125705 ecr 2355901348], length 0 0x0000: 4500 0034 c937 4000 3006 14de 118f a1cf E..4.7 at .0....... 0x0010: b73c 0214 0893 a961 1e10 1364 2197 3724 .<.....a...d!.7$ 0x0020: 8014 01f2 de75 0000 0101 080a 4a64 e309 .....u......Jd.. 0x0030: 8c6c 33a4 .l3. -- Anty Rao -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Dec 2 16:16:38 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 2 Dec 2015 11:16:38 -0500 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses Message-ID: <565F1966.7060303@openssl.com> If you don't know or care what FIPS 140-2 is, be very glad this isn't your problem and turn your charitable attentions to some worthy cause. The CMVP has introduced a new policy that will result in the effective termination of many extant validations if they are not updated by January 31 2016[1]. That update is a pure paper shuffle -- adding politically correct verbiage to the Security Policy document -- but without it the CMVP will "de-list" the validation. The original OpenSSL FIPS Object Module validations (#1747, #2398, #2473) and all validations based on them -- which is a lot of validations -- are affected. I'll be doing the labor to prepare the revised Security Policy documents for all the validations that have been performed by OSF, both the well known open source based ones and also "private label" ones, and the test labs for some of those validations are also doing their part pro bono. However, the test lab we used for the original open source based validations (#1747, #2398, #2473) is charging $1250 for those three related validations of the same module. Note this is not unreasonable as these updates involve a non-trivial amount of work. In years past that would be just another routine cost of doing business that we would absorb, as for instance we did earlier this year for the "ransom" of the "RE" validation[2]. However, 2015 has not been a good year for the open source based FIPS validation business; it has gone from economically marginal to unsustainable and as a result we'll probably be shutting down the corporate entity that does the FIPS validation work at the end of this year. I want to turn off the lights while that business is still (barely) in the black, and so have vowed not to take on any new expenses and will not be paying this $1250 out of those cash reserves, or out of my retirement savings. I also feel rather strongly that the FIPS related OpenSSL activities should not be subsidized out of donations or other general OpenSSL revenues. IMHO it's enough that I've worked on FIPS issues all this year with no income to show for it. So if you're a corporate user of the OpenSSL FIPS Object Module v2.0, validation(s) #1747/#2398/#2473, and want to continue using it past January 31, please be aware we'll need someone to cover that $1250 cost. Don't send any money to us; if you're interested in covering this cost I'll put you directly in touch with the test lab to work out specific payment arrangements. Thanks, -Steve M. [1] See "X9.31 RNG transition, December 31, 2015" at http://csrc.nist.gov/groups/STM/cmvp/notices.html [2] http://openssl.com/fips/ransom.html -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From ronc at lanl.gov Wed Dec 2 17:32:41 2015 From: ronc at lanl.gov (Ron Croonenberg) Date: Wed, 2 Dec 2015 10:32:41 -0700 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <20151202014623.GR18315@mournblade.imrryr.org> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> Message-ID: <565F2B39.6090506@lanl.gov> ok, thanks, but if I do a: openssl ciphers -v "ALL:eNULL" | grep eNULL I don't see anything. How do I configure openssl so it will always be able to use the eNULL 'encryption' ? Ron On 12/01/2015 06:46 PM, Viktor Dukhovni wrote: > On Tue, Dec 01, 2015 at 03:34:09PM -0700, Ron Croonenberg wrote: > >> I want to build/compile openssl including the 'eNULL' cipher. I know it's >> not in ALL or default, because of "security risks". > > No need to recompile. > >> How do I include it and built it (downloaded a version from the github) > > The eNULL ciphers are available by default, but not in ALL. Just use: > > "ALL:COMPLEMENTOFALL" > > or > > "ALL:eNULL" > > or just > > "eNULL" > > as appropriate. This is documented in ciphers(1). > From rsalz at akamai.com Wed Dec 2 17:37:56 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 2 Dec 2015 17:37:56 +0000 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <565F2B39.6090506@lanl.gov> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> Message-ID: <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> > but if I do a: openssl ciphers -v "ALL:eNULL" | grep eNULL Look for NULL, not eNULL. Or "Enc=None" From ronc at lanl.gov Wed Dec 2 17:53:27 2015 From: ronc at lanl.gov (Ron Croonenberg) Date: Wed, 2 Dec 2015 10:53:27 -0700 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <565F3017.60703@lanl.gov> thanks! that seemed to work, So the idea is to use an object store on an isolated network and push and get objects out of it using https. Encryption in https/apache is handled by mod_ssl. does that means, since there are NULL ciphers I can just use them in apache/mod_ssl by just changing a setting like: SSLCipherSuite eNULL in httpd.conf? do I need a different certificate/key? Ron On 12/02/2015 10:37 AM, Salz, Rich wrote: >> but if I do a: openssl ciphers -v "ALL:eNULL" | grep eNULL > > Look for NULL, not eNULL. Or "Enc=None" > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From swall at redcom.com Wed Dec 2 18:06:50 2015 From: swall at redcom.com (Wall, Stephen) Date: Wed, 2 Dec 2015 13:06:50 -0500 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <565F3017.60703@lanl.gov> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> Message-ID: <401084E5E73F4241A44F3C9E6FD7942803662ADF9B@exch-01> > Encryption in https/apache is handled by mod_ssl. does that means, > since there are NULL ciphers I can just use them in apache/mod_ssl by > just changing a setting like: > > SSLCipherSuite eNULL > > in httpd.conf? No. mod_ssl modifiers the ciphers you specify by appending ':!aNULL:!eNULL:!EXP' in recent versions, or by prepending '!aNULL:!eNULL:!EXP:' in older versions. There were some releases where it was possible to specify ciphers as SSLOpenSSLConfCMD CipherString "eNULL" and the ciphers you listed were not modified, but that has since been changed. If you are not lucky enough to be using a version of apache that is in that window, you will need to obtain the apache source, modify mod_ssl, and build a custom version. Be aware of potential license issues with doing this if it is for a deliverable. -spw From marquess at openssl.com Wed Dec 2 18:56:40 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 2 Dec 2015 13:56:40 -0500 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses In-Reply-To: <565F1966.7060303@openssl.com> References: <565F1966.7060303@openssl.com> Message-ID: <565F3EE8.7050302@openssl.com> On 12/02/2015 11:16 AM, Steve Marquess wrote: > If you don't know or care what FIPS 140-2 is, be very glad this isn't > your problem and turn your charitable attentions to some worthy > cause. > > The CMVP has introduced a new policy that will result in the > effective termination of many extant validations if they are not > updated by January 31 2016[1]. That update is a pure paper shuffle > -- adding politically correct verbiage to the Security Policy > document -- but without it the CMVP will "de-list" the validation. > > ... > > So if you're a corporate user of the OpenSSL FIPS Object Module >v2.0 validation(s) #1747/#2398/#2473, and want to continue using >it past January 31, please be aware we'll need someone to cover >that $1250 cost. > > Don't send any money to us; if you're interested in covering this > cost I'll put you directly in touch with the test lab to work out > specific payment arrangements. > > ... I'm getting private queries about this (why is there is such reluctance to discuss the delights of FIPS 140-2 in public?). To save some time here's an anonymous query I received, with my reply: >> ... We are thinking of using openssl FIPS in our product but >> haven't started the work yet. >> >> What will be the impacts to people like us who want to use the >> OpenSSL FIPS modules but haven't started yet? Should we still use >> the modules now or should we wait? > > Well, the #1747/#2398/#2473 validation is very widely used, so > while the CMVP may block our future FIPS related initiatives I don't > think they would dare kill those validations outright. Some > stakeholder will pay the cost to surmount this latest obstacle, in > fact we have had some contacts already. > > So I think you have safety in numbers if you decide to use that > module now, and should be good for the next year or two. Keep >in mind though that the long term future of the FIPS module is in >doubt, as the upcoming OpenSSL 1.1 release may not have any FIPS >support(at least initially). We're not going to try tackling a sixth new >open source based validation on an at-risk basis like we've done in >the past, as we think that risk is now too high. A new validation will > require a sponsor willing to absorb that risk and champion the new > validation within the government bureaucracy, and we have no such > current prospects. > >> Will there be any code changes in the modules and will there be >>new version of module (or will it be just the policy document >> updated)? > > It's just a paper shuffle with no real-world impacts for end users. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Dec 2 20:56:34 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 2 Dec 2015 21:56:34 +0100 Subject: [openssl-users] Generation of the primes p, q and g for DSA using an Hash Function in OpenSSL In-Reply-To: <1634057561.11650838.1448533553897.JavaMail.yahoo@mail.yahoo.com> References: <1634057561.11650838.1448533553897.JavaMail.yahoo.ref@mail.yahoo.com> <1634057561.11650838.1448533553897.JavaMail.yahoo@mail.yahoo.com> Message-ID: <565F5B02.7060005@wisemo.com> On 26/11/2015 11:25, Mofassir Ul Haque wrote: > We can generate primes p,q and g for DSA in OpenSSL by using command: > > openssl dsaparam -text -out dsaparam.pem 1024 > > Is it possible to generate primes p , q and g using an Hash Function > in OpenSSL if value of L , N and hash function is known ? > > Any help will be greatly appreciated ! One solution (if all else fails) is to implement the calculations direcly using the bigint functions in version 1.0.2 and older of OpenSSL. This has worked very well for me in code that didn't need FIPS certification. 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 noloader at gmail.com Wed Dec 2 21:10:16 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 2 Dec 2015 16:10:16 -0500 Subject: [openssl-users] Better understanding of EC encryption API In-Reply-To: References: <56578700.10903@gmail.com> Message-ID: > In the past BouncyCastle and Crypto++ could not interop even though > they both claim to follow P1363. IEEE did not publish test vectors, so > each library had a misinterpretation that ensured they did not > interop. Here were the issues for each library: > > * BouncyCastle > - Label should be 8 octets > > * Crypto++ > - Length of the label specified in bits > > BouncyCastle fixed their issue in version 1.53 (about 2 months ago). > Crypto++ is fixing their issue at 5.7 (in about 2 months). > > If you need a "gold" standard, then use BouncyCastle's implementation, > version 5.7 or above. That should be BouncyCastle 1.53 or above. Jeff From jb-openssl at wisemo.com Wed Dec 2 21:16:43 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 2 Dec 2015 22:16:43 +0100 Subject: [openssl-users] Response from server is lost on close In-Reply-To: References: Message-ID: <565F5FBB.2040706@wisemo.com> On 02/12/2015 11:21, Anty Rao wrote: > > Using non-blocking openssl , after detecting underlying TCP is > broken, i invoke SSL_read to attempting reading response. > *sometimes* response from server is lost, sometimes not. But > tcpdump show that response is always send back to me. what is > special is that RST packages come next the response. Can someone > shed some light on me, Thanks.Here is the result of tcpdump: > > |16:18:00.168274IP 17.143.161.207.2195>xx.xxx.xx.xx.43361:Flags[P.],seq > 4764:4801,ack 37462,win 432,option s [nop,nop,TS val 1248125705ecr > 2355901348],length 370x0000:45000059c936 4000300614ba118fa1cf > E..Y.6 at .0.......0x0010:b73c 02140893a961 > 1e10133f21973724.<.....a...?!.7$ > 0x0020:801801b0245e00000101080a4a64e309 > ....$^......Jd..0x0030:8c6c33a4150301002012a99f e30c > 37aa.l3...........7.0x0040:eda1 e24a 181974cb1a732396f76e b9fa > ...J..t..s#..n..0x0050:293b86258a9d09a730);.%....016:18:00.168326IP > 17.143.161.207.2195>xx.xxx.xx.xx.43361:Flags[R.],seq 4801,ack > 37462,win 498,options [no p,nop,TS val 1248125705ecr > 2355901348],length 00x0000:45000034c937 4000300614de118fa1cf > E..4.7 at .0.......0x0010:b73c 02140893a961 > 1e10136421973724.<.....a...d!.7$ 0x0020:801401f2de75 > 00000101080a4a64e309 .....u......Jd..0x0030:8c6c33a4.l3.| > > When the TCP/IP stack on 17.143.161.207 sends back an RST it means (amongst other things) that the entire connection is dead and invalid (not a pretty/graceful close, but dead and invalid). Thus the TCP/IP stack on xx.xxx.xx.xx is correct in throwing away any received data it has not yet passed to application layer code (such as OpenSSL). An ordinary connection close should be sending a packet with the FIN flag, not the RST flag and expect your computer to send back an ACK of that FIN packet. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Dec 2 23:53:14 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 2 Dec 2015 23:53:14 +0000 Subject: [openssl-users] Response from server is lost on close In-Reply-To: <565F5FBB.2040706@wisemo.com> References: <565F5FBB.2040706@wisemo.com> Message-ID: Just to amplify on Jakob's response: the reason that sometimes you see the reply is that sometimes your application manages to get it from the stack before the stack receives and processes the RST from the peer. In the example you provided, there was a 52ms window in which you could have read that response before the RST told the stack to throw it away. If the conversation is aborting for cause - for example because the peer process exited without reading some received data - then this is the correct behavior. If the peer is causing the RST by mucking around with the SO_LINGER socket option, then the peer application is probably broken. (There are cases where an application might legitimately want to send an RST rather than a FIN, but they're few and far between.) In any event, you're at the mercy of TCP's semantics. When the conversation is aborted, rather than terminated normally, unprocessed data goes away. That's a Good Thing, because the peer has no way of knowing whether you received it. As is usually the case with this sort of issue, the real question is what problem are you actually trying to solve? "How can I make TCP behave differently?" is not the right question. Michael Wojcik Technology Specialist, Micro Focus -------------- next part -------------- An HTML attachment was scrubbed... URL: From ant.rao at gmail.com Thu Dec 3 03:15:54 2015 From: ant.rao at gmail.com (Anty Rao) Date: Thu, 3 Dec 2015 11:15:54 +0800 Subject: [openssl-users] Response from server is lost on close In-Reply-To: References: <565F5FBB.2040706@wisemo.com> Message-ID: Thanks Jakob & Michael for your reply. I'm using openssl to interact with apple's APNS server. Sending data as fast as possible, most of the time APNS server don't reply, but in some circumstance, APNS server will rely with a response and then close the connection. So the RST is expected most of the time if APNS don't process all received data. At first i doubt this is maybe properties of TCP : tcp discard received data on RST. and i do some test on TCP not openssl. 1. client write data until the connection is broken, sleep for a number of seconds, then try to read. the response can be read. 2. server on accept, don't read the data, sleep for a number of seconds. and write some bytes ,then just exit. here is result of tcpdump on closing: 09:50:10.188952 IP xx.90.82.138.irisa > 10.241.95.197.48252: Flags [P.], seq 730306105:730306205, ack 1556413186 Connection was reset.,nop,TS val 118133437 ecr 511650777], length 100 09:50:10.188963 IP 10.241.95.197.48252 > xx.90.82.138.irisa: Flags [.], ack 100, win 6, options [nop,nop,TS val 511653112 ecr 118133437], length 0 09:50:10.188971 IP xx.90.82.138.irisa > 10.241.95.197.48252: Flags [R.], seq 100, ack 1, win 39, options [nop,no p,TS val 118133437 ecr 511650777], length 0 It seems that if data is placed in socket buffer, it can be read. So the received package could be discard in TCP stack? Thank you very much. On Thu, Dec 3, 2015 at 7:53 AM, Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > Just to amplify on Jakob's response: the reason that sometimes you see the > reply is that sometimes your application manages to get it from the stack > before the stack receives and processes the RST from the peer. In the > example you provided, there was a 52ms window in which you could have read > that response before the RST told the stack to throw it away. > > > If the conversation is aborting for cause - for example because the peer > process exited without reading some received data - then this is the > correct behavior. If the peer is causing the RST by mucking around with the > SO_LINGER socket option, then the peer application is probably broken. > (There are cases where an application might legitimately want to send an > RST rather than a FIN, but they're few and far between.) > > > > In any event, you're at the mercy of TCP's semantics. When the > conversation is aborted, rather than terminated normally, unprocessed data > goes away. That's a Good Thing, because the peer has no way of knowing > whether you received it. > > > > As is usually the case with this sort of issue, the real question is what > problem are you actually trying to solve? "How can I make TCP behave > differently?" is not the right question. > > > > Michael Wojcik > Technology Specialist, Micro Focus > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- Anty Rao -------------- next part -------------- An HTML attachment was scrubbed... URL: From mofassir_haque at yahoo.com Thu Dec 3 05:18:43 2015 From: mofassir_haque at yahoo.com (Mofassir Ul Haque) Date: Thu, 3 Dec 2015 05:18:43 +0000 (UTC) Subject: [openssl-users] Generation of the primes p, q and g for DSA using an Hash Function in OpenSSL In-Reply-To: <565F5B02.7060005@wisemo.com> References: <565F5B02.7060005@wisemo.com> Message-ID: <2035005740.15247952.1449119923143.JavaMail.yahoo@mail.yahoo.com> Hi Jakob, ?????????????? Many thanks for pointing this to me. I will give it a try.Kind Regards,? On Thursday, 3 December 2015 9:57 AM, Jakob Bohm wrote: On 26/11/2015 11:25, Mofassir Ul Haque wrote: > We can generate primes p,q and g for DSA in OpenSSL by using command: > > openssl dsaparam -text -out dsaparam.pem 1024 > > Is it possible to generate primes p , q and g using an Hash Function > in OpenSSL if value of L , N and hash function is known ? > > Any help will be greatly appreciated ! One solution (if all else fails) is to implement the calculations direcly using the bigint functions in version 1.0.2 and older of OpenSSL. This has worked very well for me in code that didn't need FIPS certification. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S.? https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark.? Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nounou.dadoun at avigilon.com Thu Dec 3 06:01:36 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Thu, 3 Dec 2015 06:01:36 +0000 Subject: [openssl-users] Verify callback to ignore certificate expiry Message-ID: <8149AB08BCB1F54F92680ED6104891A0DFCD6F@mbx027-w1-ca-4.exch027.domain.local> Another quick question, I'm setting up a server ssl handshake on a device on which the certificate verification will sometimes fail not because the certificate is bad but because the time is not set properly on the device. I'm doing an ssl verify callback that is almost identical to one of the examples in https://www.openssl.org/docs/manmaster/crypto/X509_STORE_CTX_set_verify_cb.html I.e. int verify_callback(int ok, X509_STORE_CTX *ctx) { int err = X509_STORE_CTX_get_error(ctx); X509 *err_cert = X509_STORE_CTX_get_current_cert(ctx); if (err == X509_V_ERR_CERT_HAS_EXPIRED) { if (check_is_acceptable_expired_cert(err_cert) return 1; } return ok; } I have some other slight differences but basically what I need is an implementation for the (fictitious) "check_is_acceptable_expired_cert(err_cert)" function call. Is there any quick way of doing this that doesn't involve completely reconstructing the steps for verification (and leaving one out)? I can do that if I need to but this is only one part of a larger endeavour that will take much more time - any pointers? thanks .... N From openssl-users at dukhovni.org Thu Dec 3 14:59:48 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Dec 2015 14:59:48 +0000 Subject: [openssl-users] Verify callback to ignore certificate expiry In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0DFCD6F@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0DFCD6F@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <20151203145947.GG18315@mournblade.imrryr.org> On Thu, Dec 03, 2015 at 06:01:36AM +0000, Nounou Dadoun wrote: > Another quick question, I'm setting up a server ssl handshake on a device on which the certificate verification will sometimes fail not because the certificate is bad but because the time is not set properly on the device. > > I'm doing an ssl verify callback that is almost identical to one of the examples in https://www.openssl.org/docs/manmaster/crypto/X509_STORE_CTX_set_verify_cb.html > I.e. > > int verify_callback(int ok, X509_STORE_CTX *ctx) > { > int err = X509_STORE_CTX_get_error(ctx); > X509 *err_cert = X509_STORE_CTX_get_current_cert(ctx); > if (err == X509_V_ERR_CERT_HAS_EXPIRED) > { > if (check_is_acceptable_expired_cert(err_cert) > return 1; > } > return ok; > } > > I have some other slight differences but basically what I need is an > implementation for the (fictitious) > "check_is_acceptable_expired_cert(err_cert)" function call. > > Is there any quick way of doing this that doesn't involve completely > reconstructing the steps for verification (and leaving one out)? I can > do that if I need to but this is only one part of a larger endeavour that > will take much more time - any pointers? thanks .... N The required function is mostly a NOOP, after you return 1, OpenSSL will continue to perform all the other checks it would do had the certificate not been expired. However, you probably want the verification result to be OK at the completion of the handshake (have SSL_get_verify_result() return X509_V_OK). So all that the code needs to do is to set the error status to X509_V_OK. X509_STORE_CTX_set_error(ctx, X509_V_OK); Provided you return 0 (abort the handshake on any errors you're not explicitly ignoring, you're OK. If you ever decide to continue handshakes despite other errors, then more care is required to restore any previous error status (which you'll need to store somewhere) when ignoring the errors you want to suppress. -- Viktor. From rcdelgado05 at gmail.com Thu Dec 3 15:41:19 2015 From: rcdelgado05 at gmail.com (R C Delgado) Date: Thu, 3 Dec 2015 15:41:19 +0000 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses In-Reply-To: <565F3EE8.7050302@openssl.com> References: <565F1966.7060303@openssl.com> <565F3EE8.7050302@openssl.com> Message-ID: Thank you Steve, This is very useful information. >>I'm getting private queries about this (why is there is such reluctance to discuss the delights of FIPS 140-2 in public?). I've noticed technical questions related to private FIPS certifications never get answered, at least not on this distribution list. I know mine was never answered. Maybe that's why users are reluctant to post their questions publicly and hope that a private email will get answered for sure. Obviously there are also company restrictions related to confidentiality to consider, knowing that competitors and even customers are registered on the distribution list too. BTW, I had guessed why FIPS certification questions don't get answered: it's all about funding, but thank you for explaining it in your email. >>... FIPS validation business; it has gone from economically marginal to unsustainable and as a result we'll probably be shutting down the corporate entity that does the FIPS validation work at the end of this year. I want to turn off the lights while that business is still (barely) in the black... I think a formal statement should be posted on the OpenSSL website, so that all (FIPS) users know the level of support to expect. Thank you all for you great work. On Wed, Dec 2, 2015 at 6:56 PM, Steve Marquess wrote: > On 12/02/2015 11:16 AM, Steve Marquess wrote: > > If you don't know or care what FIPS 140-2 is, be very glad this isn't > > your problem and turn your charitable attentions to some worthy > cause. > > > The CMVP has introduced a new policy that will result in the > effective > termination of many extant validations if they are not > updated by January > 31 2016[1]. That update is a pure paper shuffle > -- adding politically > correct verbiage to the Security Policy > document -- but without it the > CMVP will "de-list" the validation. > > ... > > So if you're a corporate > user of the OpenSSL FIPS Object Module > > v2.0 validation(s) #1747/#2398/#2473, and want to continue using > > it past January 31, please be aware we'll need someone to cover > > that $1250 cost. > > Don't send any money to us; if you're interested > in covering this > cost I'll put you directly in touch with the test lab to > work out > specific payment arrangements. > > ... > > I'm getting private queries about this (why is there is such reluctance to > discuss the delights of FIPS 140-2 in public?). To save some time here's an > anonymous query I received, with my reply: > > >> ... We are thinking of using openssl FIPS in our product but >> haven't > started the work yet. >> >> What will be the impacts to people like us who > want to use the >> OpenSSL FIPS modules but haven't started yet? Should we > still use >> the modules now or should we wait? > > Well, the > #1747/#2398/#2473 validation is very widely used, so > while the CMVP may > block our future FIPS related initiatives I don't > think they would dare > kill those validations outright. Some > stakeholder will pay the cost to > surmount this latest obstacle, in > fact we have had some contacts already. > > > So I think you have safety in numbers if you decide to use that > > module now, and should be good for the next year or two. Keep > > in mind though that the long term future of the FIPS module is in > > doubt, as the upcoming OpenSSL 1.1 release may not have any FIPS > > support (at least initially). We're not going to try tackling a sixth > new > > open source based validation on an at-risk basis like we've done in > > the past, as we think that risk is now too high. A new validation will > > require a sponsor willing to absorb that risk and champion the new > > validation within the government bureaucracy, and we have no such > current > prospects. > >> Will there be any code changes in the modules and will > there be > >> new version of module (or will it be just the policy document >> > updated)? > > It's just a paper shuffle with no real-world impacts for end > users. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Thu Dec 3 15:51:37 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 3 Dec 2015 15:51:37 +0000 Subject: [openssl-users] OpenSSL version 0.9.8zh released Message-ID: <20151203155137.GA29017@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 0.9.8zh released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8zh of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-0.9.8-notes.html OpenSSL 0.9.8zh is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.8zh.tar.gz Size: 3817665 MD5 checksum: c00f014c64dfac1ec40dc7459d9673e6 SHA1 checksum: 77cc99e7c83794a212bc7b047480d8288addf9df SHA256 checksum: ea1a43a47900b90e014360572d752f85617fb119fa048800872c1b37db04fad3 The checksums were calculated using the following commands: openssl md5 openssl-0.9.8zh.tar.gz openssl sha1 openssl-0.9.8zh.tar.gz openssl sha256 openssl-0.9.8zh.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYFkEAAoJENnE0m0OYESRs8MIAJNsinLBj9zDUwXMMO7f289r oOfwzhCsnjdNb40N5/j6EEiqYC3TwuFBEm6BD59Jr8R7GaUthpFoc8isIAMu+xYS rNFCneu8cM4vX23Wefg7e9MC0RAOG2GTlYmmbxDUXQUv3z+LX/DNc1rxCcOPbnf1 1TQdAiXBpU14kXNuauFbxj9y2mHslkmaiE/4riaQZKgMOU9oJKbMH/aDGHZjmzaf AEeLV0i51JxjUQ3aLvOYZnn+fSxPTJDkv3U3n2+sUYfPwqxTp365VKJ240YbjIx+ llYgloiU1chJo09hBBp+HavaBNcB1uorvsRCKo1PDYxQt4qeFirfM3VNJ1fESug= =Q6ea -----END PGP SIGNATURE----- From openssl at openssl.org Thu Dec 3 15:52:17 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 3 Dec 2015 15:52:17 +0000 Subject: [openssl-users] OpenSSL version 1.0.0t released Message-ID: <20151203155217.GA29510@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.0t released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.0t of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.0-notes.html OpenSSL 1.0.0t is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.0t.tar.gz Size: 4091806 MD5 checksum: 62f5f2127c9bdd3d2768c78c8306039e SHA1 checksum: 949ecd8aa821b0cc5fde12862e4dde33c0320682 SHA256 checksum: 7ce1c3cab7a33bf494330074f70039a10856a972f6b8c430ef4b73db844bde50 The checksums were calculated using the following commands: openssl md5 openssl-1.0.0t.tar.gz openssl sha1 openssl-1.0.0t.tar.gz openssl sha256 openssl-1.0.0t.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYFgZAAoJENnE0m0OYESRXuEH/iRgWMcdta23AqUGiPEhBZs0 GWj9VY85g0477EsWqS2wz+kYlnIcbXLGnt1IlPvuXv++VboAyhAyGVpqGMyvka8q pxLxUM7wDdUpdSCV/+wKrbF1nmZCYIhQFdbLHwGKw195+vWM/PlDUGpKTBfrZECf HaBF4FsrRnGew4ZIORyvJSD49/Qc8GCygR5ZB3+cGguCjo/+pCRgAA75DeTxbkjb hf7xZ/8umZZdBgE+ZsPu5+aM8pMKsTc42bv4cPqqwGvygEJPWyMEL16rkomOVshe m6vXPLFYcNNkd4JEUWpZRMQEelpw8/kKSu8ZGNZ3G3RW4EJipMuN7nxUSEmVvfE= =6tot -----END PGP SIGNATURE----- From openssl at openssl.org Thu Dec 3 15:53:30 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 3 Dec 2015 15:53:30 +0000 Subject: [openssl-users] OpenSSL version 1.0.1q released Message-ID: <20151203155330.GA30297@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1q released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1q of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1q is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1q.tar.gz Size: 4548189 MD5 checksum: d1221e2f88085b0953670779656b452f SHA1 checksum: 8f390cd667f87d9c393464ff91d42df89a6df3ac SHA256 checksum: 68f3b2f0f1e8da770f89c38eadf7e6c4dbf690fd4bb648f651addd3b92a9ddf1 The checksums were calculated using the following commands: openssl md5 openssl-1.0.1q.tar.gz openssl sha1 openssl-1.0.1q.tar.gz openssl sha256 openssl-1.0.1q.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYFa1AAoJENnE0m0OYESRUnQIAKtEW4xb1nGTdJmGCevAQIS7 GjmIIJsIpKhNGx7j2Cm02F0HFKG6IQOy4gLcl84eNkxkgAnc6D4/H4MroFQQe7/x P9jrWjNqXNtoHKm8OdMUKVFDpzv0AGbVz/3r0XRCPS/zxj5ig8bq7IirrcWx137N /mLgm0OIuNnL99GBSSjUdji4aW50GwCYFZBtr85CdhKU5EMg6hQld6q72VbBBoBi cTRgRnTvl/s1dxqi7DTMTyUXglcYNvm+/QYBKNK10IMXuhhu20MIwUNIy9WVgkCo +bRkdNhHE7A1RklSEQyOCoJXkElTdXDwTElSlYhCdhcgRSX2eM63rOvwm9Zp45s= =9n6L -----END PGP SIGNATURE----- From openssl at openssl.org Thu Dec 3 15:53:46 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 3 Dec 2015 15:53:46 +0000 Subject: [openssl-users] OpenSSL version 1.0.2e released Message-ID: <20151203155346.GA30466@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2e released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2e of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2e is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2e.tar.gz Size: 5255719 MD5 checksum: 2218c1a6f807f7206c11eb3ee3a5ec80 SHA1 checksum: fa4d6e94084e80478d4a7749b97d955e89f04ec2 SHA256 checksum: eee11def03647aa2267434a779608af6fca645023c9a194ddb82f14426835537 The checksums were calculated using the following commands: openssl md5 openssl-1.0.2e.tar.gz openssl sha1 openssl-1.0.2e.tar.gz openssl sha256 openssl-1.0.2e.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYFVTAAoJENnE0m0OYESR+VYIAJjA5F9echoXC39pYUw1SmdT DIy2ExFbfXsWJXhoRA2H/OImo9rWxo715BGvkHSNWHZQxXaisFUkB3OLuU0BwGRR U5yUbQDSFIBXH0p2OXKburS7LhzI61SFSirQb4jiRnkohidC9crxl2VDGbeP7yhe M6d1AHwkZp7pnAC8RG3RpzP5sU2oMHPnWTMajAQNZpnrcY0sN4QcW5Ko7kPCHRNv mCUdc1fu2R99HWpky6pySVu5efheGxGDk+W+rjNYDzb1RuFdWStBZTbfEFGI7+ER O63SPMm7bqAkIpfopRsLNpjlHcLpx5C15tj9QQUlTTlTOORq7ZDTFFipY1aYpok= =cM6W -----END PGP SIGNATURE----- From marquess at openssl.com Thu Dec 3 15:57:13 2015 From: marquess at openssl.com (Steve Marquess) Date: Thu, 3 Dec 2015 10:57:13 -0500 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses In-Reply-To: References: <565F1966.7060303@openssl.com> <565F3EE8.7050302@openssl.com> Message-ID: <56606659.1020608@openssl.com> On 12/03/2015 10:41 AM, R C Delgado wrote: > ... > > BTW, I had guessed why FIPS certification questions don't get answered: > it's all about funding, but thank you for explaining it in your email. >>>... FIPS validation business; it has gone > from economically marginal to unsustainable and as a result we'll > probably be shutting down the corporate entity that does the FIPS > validation work at the end of this year. I want to turn off the lights > while that business is still (barely) in the black... > > I think a formal statement should be posted on the OpenSSL website, so > that all (FIPS) users know the level of support to expect. We already have, in the form of a blog entry: https://openssl.org/blog/blog/2015/09/29/fips/ That's still an accurate representation of the situation. We'll continue to try to do "change letter" updates for the existing 2.0 OpenSSL FIPS module for as long as that remains possible. The CMVP has recently introduced a number of new policies and practices with a possibly significant impact on existing validations; at this point I really don't know what the future holds. I'll blog again when I know the outcome of the X9.31 RNG transition issue. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From openssl at openssl.org Thu Dec 3 15:57:34 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 3 Dec 2015 15:57:34 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20151203155734.GA493@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [3 Dec 2015] ======================================= NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE 0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS. BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193) ================================================================== 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. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2e This issue was reported to OpenSSL on August 13 2015 by Hanno B??ck. The fix was developed by Andy Polyakov of the OpenSSL development team. Certificate verify crash with missing PSS parameter (CVE-2015-3194) =================================================================== Severity: Moderate The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and absent mask generation function parameter. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q This issue was reported to OpenSSL on August 27 2015 by Lo??c Jonas Etienne (Qnective AG). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. X509_ATTRIBUTE memory leak (CVE-2015-3195) ========================================== Severity: Moderate When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak memory. This structure is used by the PKCS#7 and CMS routines so any application which reads PKCS#7 or CMS data from untrusted sources is affected. SSL/TLS is not affected. This issue affects OpenSSL versions 1.0.2 and 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q OpenSSL 1.0.0 users should upgrade to 1.0.0t OpenSSL 0.9.8 users should upgrade to 0.9.8zh This issue was reported to OpenSSL on November 9 2015 by Adam Langley (Google/BoringSSL) using libFuzzer. The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Race condition handling PSK identify hint (CVE-2015-3196) ========================================================= Severity: Low If PSK identity hints are received by a multi-threaded client then the values are wrongly updated in the parent SSL_CTX structure. This can result in a race condition potentially leading to a double free of the identify hint data. This issue was fixed in OpenSSL 1.0.2d and 1.0.1p but has not been previously listed in an OpenSSL security advisory. This issue also affects OpenSSL 1.0.0 and has not been previously fixed in an OpenSSL 1.0.0 release. OpenSSL 1.0.2 users should upgrade to 1.0.2d OpenSSL 1.0.1 users should upgrade to 1.0.1p OpenSSL 1.0.0 users should upgrade to 1.0.0t The fix for this issue can be identified in the OpenSSL git repository by commit ids 3c66a669dfc7 (1.0.2), d6be3124f228 (1.0.1) and 1392c238657e (1.0.0). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these versions will be provided after that date. In the absence of significant security issues being identified prior to that date, the 1.0.0t and 0.9.8zh releases will be the last for those versions. Users of these versions are advised to upgrade. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20151203.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/about/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYFodAAoJENnE0m0OYESRWZwIALI/Vd1a4QJVCbwkmkx76fUw DguuYXXk6+w59Ie39xA5PN/YJ3PygbIeS/WbFSeZTTlMFyiNMn/B5WSD6Uyfmsm0 pqiyRZZonSXcK7m89D3SaCRw86rAN9K5aVuCM6YQly1A+cuvwhnRJwNVIfzzFYRH 7eWKv8eBBZ+013FQxeiDgNZRPPR69HnHVS3029LXuTuvqqb54TB83ekB6R97eFY5 MoYNzbPrnyRrkDVrcRuAZyblbTUT1jkfrhl+V5f6jtvuAvpbawIk1riwMplIp4Dj mymP7epl5JUfUkdAjXSdOULBL4ps3I7r64JznI5njs+96i4SpcWuDi1mFfzpoLE= =6qxq -----END PGP SIGNATURE----- From Michal.Trojnara at mirt.net Thu Dec 3 16:37:41 2015 From: Michal.Trojnara at mirt.net (Michal Trojnara) Date: Thu, 3 Dec 2015 17:37:41 +0100 Subject: [openssl-users] stunnel 5.27 released Message-ID: <56606FD5.2050406@mirt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Users, I have released version 5.27 of stunnel. The ChangeLog entry: Version 5.27, 2015.12.03, urgency: MEDIUM * Security bugfixes - OpenSSL DLLs updated to version 1.0.2e. https://www.openssl.org/news/secadv_20151203.txt * New features - Automated build testing configured with .travis.yml. - Added reading server certificates from hardware engines. For example: cert = id_45 - Only attempt to use potentially harmful compiler or linker options if gcc was detected. - /opt/csw added to the OpenSSL directory lookup list. - mingw.mak updates (thx to Jose Alf.). - TODO list updated. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 7474e986710e88a5cc3330b6b1762f9449f01eccf826fa0f97e56d064c05ead3 stunnel-5.27.tar.gz 04b11dea9a29e7a16d46b2c4e6c66a5ca6f588abb29a827dcca2c6f6456eb4c6 stunnel-5.27-installer.exe 76e4297212eaa99a674191f3e955ec3959abcdd0c081d2df0ce8786a577a6883 stunnel-5.27-android.zip Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWYG/VAAoJEC78f/DUFuAUKloP/jRcbtEuSpiLbFTg2hQqJcZf T6C6x+pCRDqefPZMQNgN5HIU9TBUAm1dGNH3KxRqrfCTlYKnhqafDoj66fsQe6sm vUDOxxxwCcKBZaiO4II5cLxd05d9GX9FnI86GBfiztSX0nr2wMLu1EdKHdTO2R5s VXsjRl1ey2X0ukhzQ+gsD2bOf2tz0gkCjrcoAZZyGqBE+Zy3hMGSlK8mXeTfU8Of ygUT+nEcUmQb+zbEBrJCp+Q2TP0dMzXSgpKz67toH1wJJ85iTpxqPa6L6LcKwHXd kA2c75Y7HXmc4C+eKpXessifbHTHdJXbsF4ZOc06IxIg2+v47Fqqz13sL2rMKdYQ aldOP7NiOyCxywjQ3bZElvF8f8Q1RJz/+qMKG0QEWwe1cRHmDOweZ2BrqsBsZNbE Pxx2lavAqRruREL9PnL12mH/u9e0SBIaXsgmN1xo9IvaVy98K9+VL23m2GpXeVMp cPGOtfwX2M0NWRIU6keQ8FOqszuP0A7CSFTKwmM2/ZGNjPOk00/NCJk9qchyqZcr 8RDnkMOknvqEp5Uf0PWpBafK0yUps7aPwyTQX9SQ8uvz3ra/30ghkpEyAeIeEP3p Y5DqlSXupIbPAmUw3fNblU7E7SgflPP4LXF8oznLUkWFmPpR/wPUiHC1EnEOGtEQ GHF3H9CS1fr51rPm0UaK =hfT6 -----END PGP SIGNATURE----- From gmane.bl4 at gishpuppy.com Thu Dec 3 16:38:55 2015 From: gmane.bl4 at gishpuppy.com (Guy) Date: Thu, 03 Dec 2015 10:38:55 -0600 Subject: [openssl-users] Latest tarballs; symlink errors Message-ID: Hello, (0.9.8zh, 1.0.0t, 1.0.1q, 1.0.2e) I try to extract the tarballs and receive errors like: tar: openssl-1.0.2e/apps/md4.c: Cannot create symlink to `openssl-1.0.2e/../crypto/md4/md4.c': No such file or directory tar: Exiting with failure status due to previous errors $ gpg --verify openssl-1.0.2e.tar.gz.asc openssl-1.0.2e.tar.gz gpg: Signature made 12/03/15 08:44:34 gpg: using RSA key 0xD9C4D26D0E604491 gpg: Good signature from "Matt Caswell " gpg: aka "Matt Caswell " Primary key fingerprint: 8657 ABB2 60F0 56B1 E519 0839 D9C4 D26D 0E60 4491 $ sha1sum openssl-1.0.2e.tar.gz fa4d6e94084e80478d4a7749b97d955e89f04ec2 *openssl-1.0.2e.tar.gz $ Thank you. From norm.green at gemtalksystems.com Thu Dec 3 16:47:11 2015 From: norm.green at gemtalksystems.com (Norm Green) Date: Thu, 3 Dec 2015 08:47:11 -0800 Subject: [openssl-users] Symlinks broken in 1.0.2e ? Message-ID: <5660720F.2060308@gemtalksystems.com> It looks like symlinks are broken in 1.0.2e. A relative path was used in 1.0.2d but not 1.0.2e. Here's an example compared with 1.0.2d: normg at bunk>tar -ztvf openssl-1.0.2e.tar.gz |grep cast.h -rw-rw-r-- openssl/openssl 4659 2015-12-03 06:04 openssl-1.0.2e/crypto/cast/cast.h lrwxrwxrwx openssl/openssl 0 2015-12-03 06:44 openssl-1.0.2e/include/openssl/cast.h -> openssl-1.0.2e/../../crypto/cast/cast.h normg at bunk>cat openssl-1.0.2e/include/openssl/cast.h cat: openssl-1.0.2e/include/openssl/cast.h: No such file or directory /home/normg/local/b3 normg at bunk>tar -ztvf openssl-1.0.2d.tar.gz |grep cast.h -rw-rw-r-- openssl/openssl 4659 2015-07-09 04:53 openssl-1.0.2d/crypto/cast/cast.h lrwxrwxrwx openssl/openssl 0 2015-07-09 05:03 openssl-1.0.2d/include/openssl/cast.h -> ../../crypto/cast/cast.h How can I resolve this? Norm Green From ajs+openssl at aeschi.ch.eu.org Thu Dec 3 16:31:09 2015 From: ajs+openssl at aeschi.ch.eu.org (ajs+openssl at aeschi.ch.eu.org) Date: Thu, 3 Dec 2015 17:31:09 +0100 (W. Europe Standard Time) Subject: [openssl-users] Compiling up 1.0.2e - missing files Message-ID: Anyone else seeing these two issues... ./Configure shared linux-elf make make test [...] This test will take some time....123456789ABCDEF ok ../util/shlib_wrap.sh ./randtest test 1 done test 2 done test 3 done test 4 done make[1]: *** No rule to make target `bctest', needed by `test_bn'. Stop. make[1]: Leaving directory `/tmp/openssl-1.0.2e/test' make: *** [tests] Error 2 test/bctest was part of 1.0.2d - it's missing in 1.0.2e. Disregarding that, make install then yields this: making all in tools... make[1]: Entering directory `/tmp/openssl-1.0.2e/tools' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/openssl-1.0.2e/tools' /bin/sh: ./pod2mantest: No such file or directory installing man1/CA.pl.1 sh: --section=1: command not found make: *** [install_docs] Error 1 Similarly, util/pod2mantest was part of the 1.0.2d distribution - missing in 1.0.2e. Regards, Al. From openssl-users at dukhovni.org Thu Dec 3 16:59:57 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Dec 2015 16:59:57 +0000 Subject: [openssl-users] Symlinks broken in 1.0.2e ? In-Reply-To: <5660720F.2060308@gemtalksystems.com> References: <5660720F.2060308@gemtalksystems.com> Message-ID: <20151203165956.GI18315@mournblade.imrryr.org> On Thu, Dec 03, 2015 at 08:47:11AM -0800, Norm Green wrote: > It looks like symlinks are broken in 1.0.2e. A relative path was used in > 1.0.2d but not 1.0.2e. Oops... Work-around below: > How can I resolve this? # Create parent directories for missing "openssl-1.0.2e" nodes $ tar ztvf openssl-1.0.2e.tar.gz | awk '/ -> / {print $(NF-2)}' | sed -e 's,/[^/]*$,,' | sort -u | xargs mkdir -p # Symlink "openssl-1.0.2e" to "." in each $ tar ztvf openssl-1.0.2e.tar.gz | awk '/ -> / {print $(NF-2)}' | sed -e 's,/[^/]*$,,' | sort -u | while read d; do (cd $d; ln -s . openssl-1.0.2e); done # Extract the tarball $ tar zxf openssl-1.0.2e.tar.gz # Clean up $ find openssl-1.0.2e -name openssl-1.0.2e -type l -print0 | xargs -0 rm -- Viktor. From nounou.dadoun at avigilon.com Thu Dec 3 17:00:12 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Thu, 3 Dec 2015 17:00:12 +0000 Subject: [openssl-users] Verify callback to ignore certificate expiry In-Reply-To: <20151203145947.GG18315@mournblade.imrryr.org> References: <8149AB08BCB1F54F92680ED6104891A0DFCD6F@mbx027-w1-ca-4.exch027.domain.local> <20151203145947.GG18315@mournblade.imrryr.org> Message-ID: <8149AB08BCB1F54F92680ED6104891A0DFD202@mbx027-w1-ca-4.exch027.domain.local> Calling X509_STORE_CTX_set_error(ctx, X509_V_OK); Is actually what I'm doing already but I was worried that it would then ignore any other errors (e.g. bad signature etc.); I'd actually thought the errors might be ORed together but that doesn't look like the case. So does it invoke the callback for each error (which is sort of a convoluted way of ORing)? If I say ok to EXPIRED will it catch a bad signature? Thanks for your help ... N Nou Dadoun -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Thursday, December 03, 2015 7:00 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Verify callback to ignore certificate expiry On Thu, Dec 03, 2015 at 06:01:36AM +0000, Nou Dadoun wrote: > Another quick question, I'm setting up a server ssl handshake on a device on which the certificate verification will sometimes fail not because the certificate is bad but because the time is not set properly on the device. > > I'm doing an ssl verify callback that is almost identical to one of > the examples in > https://www.openssl.org/docs/manmaster/crypto/X509_STORE_CTX_set_verif > y_cb.html > I.e. > > int verify_callback(int ok, X509_STORE_CTX *ctx) > { > int err = X509_STORE_CTX_get_error(ctx); > X509 *err_cert = X509_STORE_CTX_get_current_cert(ctx); > if (err == X509_V_ERR_CERT_HAS_EXPIRED) > { > if (check_is_acceptable_expired_cert(err_cert) > return 1; > } > return ok; > } > > I have some other slight differences but basically what I need is an > implementation for the (fictitious) > "check_is_acceptable_expired_cert(err_cert)" function call. > > Is there any quick way of doing this that doesn't involve completely > reconstructing the steps for verification (and leaving one out)? I > can do that if I need to but this is only one part of a larger > endeavour that will take much more time - any pointers? thanks .... N The required function is mostly a NOOP, after you return 1, OpenSSL will continue to perform all the other checks it would do had the certificate not been expired. However, you probably want the verification result to be OK at the completion of the handshake (have SSL_get_verify_result() return X509_V_OK). So all that the code needs to do is to set the error status to X509_V_OK. X509_STORE_CTX_set_error(ctx, X509_V_OK); Provided you return 0 (abort the handshake on any errors you're not explicitly ignoring, you're OK. If you ever decide to continue handshakes despite other errors, then more care is required to restore any previous error status (which you'll need to store somewhere) when ignoring the errors you want to suppress. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl-users at dukhovni.org Thu Dec 3 17:05:23 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Dec 2015 17:05:23 +0000 Subject: [openssl-users] Symlinks broken in 1.0.2e ? In-Reply-To: <20151203165956.GI18315@mournblade.imrryr.org> References: <5660720F.2060308@gemtalksystems.com> <20151203165956.GI18315@mournblade.imrryr.org> Message-ID: <20151203170523.GJ18315@mournblade.imrryr.org> On Thu, Dec 03, 2015 at 04:59:56PM +0000, Viktor Dukhovni wrote: > $ tar zxf openssl-1.0.2e.tar.gz > > # Clean up > $ find openssl-1.0.2e -name openssl-1.0.2e -type l -print0 | xargs -0 rm Sorry, to be clear, the "cleanup" is not something you can do until after you've built the software, the various symlinks don't work if you do it too early. Just ignore this step. -- Viktor. From openssl-users at dukhovni.org Thu Dec 3 17:07:31 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Dec 2015 17:07:31 +0000 Subject: [openssl-users] Verify callback to ignore certificate expiry In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0DFD202@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0DFCD6F@mbx027-w1-ca-4.exch027.domain.local> <20151203145947.GG18315@mournblade.imrryr.org> <8149AB08BCB1F54F92680ED6104891A0DFD202@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <20151203170731.GK18315@mournblade.imrryr.org> On Thu, Dec 03, 2015 at 05:00:12PM +0000, Nounou Dadoun wrote: > Calling > X509_STORE_CTX_set_error(ctx, X509_V_OK); > Is actually what I'm doing already but I was worried that it would then > ignore any other errors (e.g. bad signature etc.); No, because is error is reported separately, and you're not setting "ok = 1" for the other errors. > I'd actually thought > the errors might be ORed together but that doesn't look like the case. Each error is reported separately. > So does it invoke the callback for each error (which is sort of a convoluted way of ORing)? Yes, though I don't think of it as "ORing". > If I say ok to EXPIRED will it catch a bad signature? Yes. -- Viktor. From nounou.dadoun at avigilon.com Thu Dec 3 17:11:17 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Thu, 3 Dec 2015 17:11:17 +0000 Subject: [openssl-users] Verify callback to ignore certificate expiry In-Reply-To: <20151203170731.GK18315@mournblade.imrryr.org> References: <8149AB08BCB1F54F92680ED6104891A0DFCD6F@mbx027-w1-ca-4.exch027.domain.local> <20151203145947.GG18315@mournblade.imrryr.org> <8149AB08BCB1F54F92680ED6104891A0DFD202@mbx027-w1-ca-4.exch027.domain.local> <20151203170731.GK18315@mournblade.imrryr.org> Message-ID: <8149AB08BCB1F54F92680ED6104891A0DFD246@mbx027-w1-ca-4.exch027.domain.local> Thanks for your help, I posted the sample (which I guess is a little misleading given that it's taken straight off the OpenSSL page I noted) and not what it currently does which is very close to what you've suggested. So that's one problem I don't have to worry about! Thanks again ... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Thursday, December 03, 2015 9:08 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Verify callback to ignore certificate expiry On Thu, Dec 03, 2015 at 05:00:12PM +0000, Nounou Dadoun wrote: > Calling > X509_STORE_CTX_set_error(ctx, X509_V_OK); Is actually what I'm doing > already but I was worried that it would then ignore any other errors > (e.g. bad signature etc.); No, because is error is reported separately, and you're not setting "ok = 1" for the other errors. > I'd actually thought > the errors might be ORed together but that doesn't look like the case. Each error is reported separately. > So does it invoke the callback for each error (which is sort of a convoluted way of ORing)? Yes, though I don't think of it as "ORing". > If I say ok to EXPIRED will it catch a bad signature? Yes. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From norm.green at gemtalksystems.com Thu Dec 3 17:34:03 2015 From: norm.green at gemtalksystems.com (Norm Green) Date: Thu, 3 Dec 2015 09:34:03 -0800 Subject: [openssl-users] Symlinks broken in 1.0.2e ? In-Reply-To: <20151203170523.GJ18315@mournblade.imrryr.org> References: <5660720F.2060308@gemtalksystems.com> <20151203165956.GI18315@mournblade.imrryr.org> <20151203170523.GJ18315@mournblade.imrryr.org> Message-ID: <56607D0B.8040808@gemtalksystems.com> Hi Viktor, Thanks for the workaround. After running your code I now see this: cast.h -> openssl-1.0.2e/../../crypto/cast/cast.h openssl-1.0.2e -> . Which is still different than 1.0.2d: cast.h -> ../../crypto/cast/cast.h Are these new symlinks here to stay or were they included in the in error? What will 1.0.2f look like in this regard? I need to merge 1.0.2e into a vendor branch in svn and I can foresee these symlink changes causing me a lot of grief. Norm Green On 12/3/2015 9:05 AM, Viktor Dukhovni wrote: > On Thu, Dec 03, 2015 at 04:59:56PM +0000, Viktor Dukhovni wrote: > >> $ tar zxf openssl-1.0.2e.tar.gz >> >> # Clean up >> $ find openssl-1.0.2e -name openssl-1.0.2e -type l -print0 | xargs -0 rm > Sorry, to be clear, the "cleanup" is not something you can do until > after you've built the software, the various symlinks don't work > if you do it too early. Just ignore this step. > From openssl-users at dukhovni.org Thu Dec 3 17:41:53 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Dec 2015 17:41:53 +0000 Subject: [openssl-users] Symlinks broken in 1.0.2e ? In-Reply-To: <56607D0B.8040808@gemtalksystems.com> References: <5660720F.2060308@gemtalksystems.com> <20151203165956.GI18315@mournblade.imrryr.org> <20151203170523.GJ18315@mournblade.imrryr.org> <56607D0B.8040808@gemtalksystems.com> Message-ID: <20151203174152.GL18315@mournblade.imrryr.org> On Thu, Dec 03, 2015 at 09:34:03AM -0800, Norm Green wrote: > Thanks for the workaround. After running your code I now see this: > > cast.h -> openssl-1.0.2e/../../crypto/cast/cast.h > openssl-1.0.2e -> . > > Which is still different than 1.0.2d: > > cast.h -> ../../crypto/cast/cast.h > > Are these new symlinks here to stay or were they included in the in error? > What will 1.0.2f look like in this regard? > > I need to merge 1.0.2e into a vendor branch in svn and I can foresee these > symlink changes causing me a lot of grief. The symlinks are not intentional, and it turns out that a test script and a "pod" documentation file are also missing. I expect an updated tarball is imminent. -- Viktor. From ronc at lanl.gov Thu Dec 3 18:13:22 2015 From: ronc at lanl.gov (Ron Croonenberg) Date: Thu, 3 Dec 2015 11:13:22 -0700 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <401084E5E73F4241A44F3C9E6FD7942803662ADF9B@exch-01> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <401084E5E73F4241A44F3C9E6FD7942803662ADF9B@exch-01> Message-ID: <56608642.4090208@lanl.gov> So in general, I would have to build apache before I could use null ciphers? On 12/02/2015 11:06 AM, Wall, Stephen wrote: >> Encryption in https/apache is handled by mod_ssl. does that means, >> since there are NULL ciphers I can just use them in apache/mod_ssl by >> just changing a setting like: >> >> SSLCipherSuite eNULL >> >> in httpd.conf? > > No. mod_ssl modifiers the ciphers you specify by appending ':!aNULL:!eNULL:!EXP' in recent versions, or by prepending '!aNULL:!eNULL:!EXP:' in older versions. There were some releases where it was possible to specify ciphers as > > SSLOpenSSLConfCMD CipherString "eNULL" > > and the ciphers you listed were not modified, but that has since been changed. If you are not lucky enough to be using a version of apache that is in that window, you will need to obtain the apache source, modify mod_ssl, and build a custom version. Be aware of potential license issues with doing this if it is for a deliverable. > > -spw > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From swall at redcom.com Thu Dec 3 18:15:52 2015 From: swall at redcom.com (Wall, Stephen) Date: Thu, 3 Dec 2015 13:15:52 -0500 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <56608642.4090208@lanl.gov> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <401084E5E73F4241A44F3C9E6FD7942803662ADF9B@exch-01> <56608642.4090208@lanl.gov> Message-ID: <401084E5E73F4241A44F3C9E6FD7942803662AE2E8@exch-01> > So in general, I would have to build apache before I could use null > ciphers? That is correct. -spw From gmane.bl4 at gishpuppy.com Thu Dec 3 18:37:06 2015 From: gmane.bl4 at gishpuppy.com (Guy) Date: Thu, 03 Dec 2015 12:37:06 -0600 Subject: [openssl-users] Latest tarballs; symlink errors References: Message-ID: Hello, I still have symlink errors with 4 latest uploads. $ gpg --verify openssl-1.0.2e.tar.gz.asc openssl-1.0.2e.tar.gz gpg: Signature made 12/03/15 12:01:26 gpg: using RSA key 0xD5E9E43F7DF9EE8C gpg: Good signature from "Richard Levitte " Primary key fingerprint: 7953 AC1F BC3D C8B3 B292 393E D5E9 E43F 7DF9 EE8C $ sha1sum openssl*tar.gz 3ff71636bea85a99f4d76a10d119c09bda0421e3 *openssl-0.9.8zh.tar.gz ab41cb253405a974063392063a034951a30076e9 *openssl-1.0.0t.tar.gz c65a7bec49b72092d7ebb97a263c496cc1e1d6af *openssl-1.0.1q.tar.gz 2c5691496761cb18f98476eefa4d35c835448fb6 *openssl-1.0.2e.tar.gz $ > (0.9.8zh, 1.0.0t, 1.0.1q, 1.0.2e) > > I try to extract the tarballs and receive errors like: > > tar: openssl-1.0.2e/apps/md4.c: > Cannot create symlink to `openssl-1.0.2e/../crypto/md4/md4.c': > No such file or directory > tar: Exiting with failure status due to previous errors > From matt at openssl.org Thu Dec 3 18:53:21 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 18:53:21 +0000 Subject: [openssl-users] OpenSSL version 1.0.2e released (corrected download) Message-ID: <56608FA1.2080403@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 1.0.2e released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2e of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2e is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2e.tar.gz Size: 5256555 MD5 checksum: 5262bfa25b60ed9de9f28d5d52d77fc5 SHA1 checksum: 2c5691496761cb18f98476eefa4d35c835448fb6 SHA256 checksum: e23ccafdb75cfcde782da0151731aa2185195ac745eea3846133f2e05c0e0bff The checksums were calculated using the following commands: openssl md5 openssl-1.0.2e.tar.gz openssl sha1 openssl-1.0.2e.tar.gz openssl sha256 openssl-1.0.2e.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWYI+hAAoJENnE0m0OYESRdz8IALIWuYoQnsCnwISeaIDuKMqj VDYdPtJRHz3dLXIal6tHtuqPP/NAq+EY+7WMCufUiCLJaVLOm5baw/G69ksF7RMd yeaLsBw7Lq4B/glSFXfPopi2rY6zmhQV6/DdGQ/BvCH9Z38nH8ZR/GTYR546XN7o GLWyHwe18HEUoRQok7UbGopC2iZPMDah0V7KB3q1fHIOIfeVstw33khNMBBZ7O8R m4SsUyJ1tVgpSv2UB1L2rkxuKPfCYBrS+7sw8ZH2kyNMVeAuHPxcG9LKoDCMSii5 00b0XcIC7MoOXeTmXK93N7NDRRYhKfeJYCSwBBBAshJrGtj27avAZR4jB5PpdsU= =JPLJ -----END PGP SIGNATURE----- From matt at openssl.org Thu Dec 3 18:57:34 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 18:57:34 +0000 Subject: [openssl-users] OpenSSL version 1.0.1q released (corrected download) Message-ID: <5660909E.8090403@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 1.0.1q released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1q of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1q is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1q.tar.gz Size: 4549898 MD5 checksum: 54538d0cdcb912f9bc2b36268388205e SHA1 checksum: c65a7bec49b72092d7ebb97a263c496cc1e1d6af SHA256 checksum: b3658b84e9ea606a5ded3c972a5517cd785282e7ea86b20c78aa4b773a047fb7 The checksums were calculated using the following commands: openssl md5 openssl-1.0.1q.tar.gz openssl sha1 openssl-1.0.1q.tar.gz openssl sha256 openssl-1.0.1q.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWYJCeAAoJENnE0m0OYESRQqsIAL/W3CN6X1Lm5cySm0ludaxX 7GZTIIjQjoPLu5UFhgHb0MlYFxvU2CgeahpR8wCFI/s10/enGs7bD54chlBJMqZC C+7+QWq6oY45f2Jnb5toGWK7jkWSW6ASkwTfvK086D+XlIGwgokI1cy3nL+UhdVl YHPb5hoR51l6rMQBB3uR1k2SXp3CEanMnJ1vL81gY05gPkc8qGfFaDj7JrteyOcB o+vwqaGg/J6VIPQIlxC46xeANAg6H3uDXHHjbOYyGHdNRhkQHaFx7c85dIHv8WJ5 J1XXcEmAae4Th+LCQkSu7IKr4Qezr0sw2xMnRgne7oytgYQpyY4xbkTdBFoFtTA= =2dkv -----END PGP SIGNATURE----- From matt at openssl.org Thu Dec 3 19:00:51 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 19:00:51 +0000 Subject: [openssl-users] OpenSSL version 1.0.0t released (corrected download) Message-ID: <56609163.2070501@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 1.0.0t released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.0t of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.0-notes.html OpenSSL 1.0.0t is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.0t.tar.gz Size: 4092302 MD5 checksum: 7b7e9f6039a97e4a453b596055912435 SHA1 checksum: ab41cb253405a974063392063a034951a30076e9 SHA256 checksum: 5ab6e348c6c2a95d457e7a00e0aa653bfc7eb4df7b24e7c9ab63163ac0299097 The checksums were calculated using the following commands: openssl md5 openssl-1.0.0t.tar.gz openssl sha1 openssl-1.0.0t.tar.gz openssl sha256 openssl-1.0.0t.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWYJFjAAoJENnE0m0OYESR1d8H/3j6OADtQxQY6bLoQ6Nv65OM oztdsyGQz9hU7ttWwaFi/n2h0sC71fRsEVPR2UkewwnCnX4+VyduVZMg+fhMBP5d TyxN7fbNKfRZD7kus3odVIjUrJX/Rp0LdG5+5hc3fPlnvLJ/QSb+jAVZJy6HWLEO 4M5yJOvcPFaiWEuoVnIEhUuJ5K9xfKNk8nwURkA/aiFi88NgI1d/NZ10SX8IjyGV 1Znfe6ck2c09zA09iKLngmbXWDBwXMzFnvtBdk9Xni/Usn1m/fEkf0LehRVy8cKp woVKGUcWKEGt85l6RitjFXkNmMrPuimRiBYoajFQ7JNTPYbUaqh+xtnowSemTbc= =ygoc -----END PGP SIGNATURE----- From matt at openssl.org Thu Dec 3 19:03:57 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 19:03:57 +0000 Subject: [openssl-users] OpenSSL version 0.9.8zh released (corrected download) Message-ID: <5660921D.2000303@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 0.9.8zh released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8zh of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-0.9.8-notes.html OpenSSL 0.9.8zh is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.8zh.tar.gz Size: 3818524 MD5 checksum: c813c065dd53d7bd0a560a870ddd0af5 SHA1 checksum: 3ff71636bea85a99f4d76a10d119c09bda0421e3 SHA256 checksum: f1d9f3ed1b85a82ecf80d0e2d389e1fda3fca9a4dba0bf07adbf231e1a5e2fd6 The checksums were calculated using the following commands: openssl md5 openssl-0.9.8zh.tar.gz openssl sha1 openssl-0.9.8zh.tar.gz openssl sha256 openssl-0.9.8zh.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWYJIdAAoJENnE0m0OYESR2LoH/j+PPvqiLnh1AgcXMFXlJ+2L 1GxJXVhUVW/d6ws6P1u0ogvX8/W6VCtiWHEcP08zhzQKoQNrga6EvxYlSNQgE80s z+GTC1fI2F8gnz9my1s4IowKQOCumSUKU39YhhZ+JpicbThj3tTE3eC07mnJtHYK bCl3Ec6Q4K5HRq7KxHRFLPwD7Mt3gJ4SCMLgRLT/Q/kbHdV20luMFqS6YsI0tdpB mPBZYeNrU0n8OtRS4aXu8O0+iYHN6xsnaLhGNGVtqkbb9cy3GFcU7clP990D67Td R6XHEae4hA0gxsI91/ARfkRsbwr3HToOmjqasmYWdzS9YfULtyXCvHGwPYJv8O8= =ps/C -----END PGP SIGNATURE----- From ronc at lanl.gov Thu Dec 3 20:48:33 2015 From: ronc at lanl.gov (Ron Croonenberg) Date: Thu, 3 Dec 2015 13:48:33 -0700 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <401084E5E73F4241A44F3C9E6FD7942803662AE2E8@exch-01> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <401084E5E73F4241A44F3C9E6FD7942803662ADF9B@exch-01> <56608642.4090208@lanl.gov> <401084E5E73F4241A44F3C9E6FD7942803662AE2E8@exch-01> Message-ID: <5660AAA1.7040203@lanl.gov> What about openssl? (little confused here).. I would expect openssl being the one that needs to be rebuild, not apache. On 12/03/2015 11:15 AM, Wall, Stephen wrote: >> So in general, I would have to build apache before I could use null >> ciphers? > > That is correct. > > -spw > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From norm.green at gemtalksystems.com Thu Dec 3 21:27:01 2015 From: norm.green at gemtalksystems.com (Norm Green) Date: Thu, 3 Dec 2015 13:27:01 -0800 Subject: [openssl-users] Symlinks STILL broken in 1.0.2e In-Reply-To: <20151203174152.GL18315@mournblade.imrryr.org> References: <5660720F.2060308@gemtalksystems.com> <20151203165956.GI18315@mournblade.imrryr.org> <20151203170523.GJ18315@mournblade.imrryr.org> <56607D0B.8040808@gemtalksystems.com> <20151203174152.GL18315@mournblade.imrryr.org> Message-ID: <5660B3A5.50303@gemtalksystems.com> There are still many broken symbolic links in the new 1.0.2e tarball: Example: >ls -l ./test/ecdsatest.c lrwxrwxrwx 1 normg smalltalk 42 Dec 3 06:44 ./test/ecdsatest.c -> openssl-1.0.2e/../crypto/ecdsa/ecdsatest.c >cat ./test/ecdsatest.c cat: ./test/ecdsatest.c: No such file or directory find . -type l -! -exec test -e {} \; -print ./apps/md4.c ./test/ssltest.c ./test/bftest.c ./test/md4test.c ./test/casttest.c ./test/rmdtest.c ./test/verify_extra_test.c ./test/dsatest.c ./test/rc4test.c ./test/v3nametest.c ./test/sha256t.c ./test/srptest.c ./test/shatest.c ./test/enginetest.c ./test/heartbeat_test.c ./test/md5test.c ./test/md2test.c ./test/wp_test.c ./test/destest.c ./test/hmactest.c ./test/bntest.c ./test/sha512t.c ./test/ideatest.c ./test/ecdsatest.c ./test/randtest.c ./test/jpaketest.c ./test/clienthellotest.c ./test/evp_extra_test.c ./test/dhtest.c ./test/sha1test.c ./test/rsa_test.c ./test/evp_test.c ./test/ecdhtest.c ./test/mdc2test.c ./test/rc5test.c ./test/rc2test.c ./test/ectest.c ./test/exptest.c ./test/constant_time_test.c Will there be a 3rd 1.0.2e tarball released to fix this? Norm Green On 12/3/15 09:41, Viktor Dukhovni wrote: > On Thu, Dec 03, 2015 at 09:34:03AM -0800, Norm Green wrote: > >> Thanks for the workaround. After running your code I now see this: >> >> cast.h -> openssl-1.0.2e/../../crypto/cast/cast.h >> openssl-1.0.2e -> . >> >> Which is still different than 1.0.2d: >> >> cast.h -> ../../crypto/cast/cast.h >> >> Are these new symlinks here to stay or were they included in the in error? >> What will 1.0.2f look like in this regard? >> >> I need to merge 1.0.2e into a vendor branch in svn and I can foresee these >> symlink changes causing me a lot of grief. > The symlinks are not intentional, and it turns out that a test > script and a "pod" documentation file are also missing. I expect > an updated tarball is imminent. > From matt at openssl.org Thu Dec 3 21:31:38 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 21:31:38 +0000 Subject: [openssl-users] Symlinks STILL broken in 1.0.2e In-Reply-To: <5660B3A5.50303@gemtalksystems.com> References: <5660720F.2060308@gemtalksystems.com> <20151203165956.GI18315@mournblade.imrryr.org> <20151203170523.GJ18315@mournblade.imrryr.org> <56607D0B.8040808@gemtalksystems.com> <20151203174152.GL18315@mournblade.imrryr.org> <5660B3A5.50303@gemtalksystems.com> Message-ID: <5660B4BA.9000405@openssl.org> On 03/12/15 21:27, Norm Green wrote: > There are still many broken symbolic links in the new 1.0.2e tarball: > > Example: >>ls -l ./test/ecdsatest.c > lrwxrwxrwx 1 normg smalltalk 42 Dec 3 06:44 ./test/ecdsatest.c -> > openssl-1.0.2e/../crypto/ecdsa/ecdsatest.c >>cat ./test/ecdsatest.c > cat: ./test/ecdsatest.c: No such file or directory > > > find . -type l -! -exec test -e {} \; -print > ./apps/md4.c > ./test/ssltest.c > ./test/bftest.c > ./test/md4test.c > ./test/casttest.c > ./test/rmdtest.c > ./test/verify_extra_test.c > ./test/dsatest.c > ./test/rc4test.c > ./test/v3nametest.c > ./test/sha256t.c > ./test/srptest.c > ./test/shatest.c > ./test/enginetest.c > ./test/heartbeat_test.c > ./test/md5test.c > ./test/md2test.c > ./test/wp_test.c > ./test/destest.c > ./test/hmactest.c > ./test/bntest.c > ./test/sha512t.c > ./test/ideatest.c > ./test/ecdsatest.c > ./test/randtest.c > ./test/jpaketest.c > ./test/clienthellotest.c > ./test/evp_extra_test.c > ./test/dhtest.c > ./test/sha1test.c > ./test/rsa_test.c > ./test/evp_test.c > ./test/ecdhtest.c > ./test/mdc2test.c > ./test/rc5test.c > ./test/rc2test.c > ./test/ectest.c > ./test/exptest.c > ./test/constant_time_test.c > > Will there be a 3rd 1.0.2e tarball released to fix this? The sym links are not required to successfully build - they get recreated anyway when you run "Configure". I've had some reports of some versions of tar (the one I've heard of is on mingw) complaining about the sym links but actually all the files are extracted ok, and it is perfectly possible to successfully build. As its a relatively minor issue I'm currently minded to stick with what we've got. Matt From swall at redcom.com Thu Dec 3 21:32:47 2015 From: swall at redcom.com (Wall, Stephen) Date: Thu, 3 Dec 2015 16:32:47 -0500 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <5660AAA1.7040203@lanl.gov> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <401084E5E73F4241A44F3C9E6FD7942803662ADF9B@exch-01> <56608642.4090208@lanl.gov> <401084E5E73F4241A44F3C9E6FD7942803662AE2E8@exch-01> <5660AAA1.7040203@lanl.gov> Message-ID: <401084E5E73F4241A44F3C9E6FD7942803662AE448@exch-01> > What about openssl? (little confused here).. I would expect openssl > being the one that needs to be rebuild, not apache. As Viktor previously stated, openssl has the NULL ciphers built in by default. Your reply to Rich seemed to confirm that your version of openssl does include them: >>>> but if I do a: openssl ciphers -v "ALL:eNULL" | grep eNULL >>>> I don't see anything. >>> Look for NULL, not eNULL. Or "Enc=None" >> thanks! that seemed to work, You further asked: >> does that means, since there are NULL ciphers I can just use them in apache/mod_ssl by just changing a setting like: >> >> SSLCipherSuite eNULL >> >> in httpd.conf? To which I responded "No". If mod_ssl were passing the SSLCipherSuite value straight through to openssl, the answer would have been yes. Unfortunately for you, mod_ssl manipulates the value of SSLCipherSuite to prevent NULL and export ciphers from being used. You need to rebuild Apache without that manipulation to use any NULL ciphers. -spw From norm.green at gemtalksystems.com Thu Dec 3 21:37:39 2015 From: norm.green at gemtalksystems.com (Norm Green) Date: Thu, 3 Dec 2015 13:37:39 -0800 Subject: [openssl-users] Symlinks STILL broken in 1.0.2e In-Reply-To: <5660B4BA.9000405@openssl.org> References: <5660720F.2060308@gemtalksystems.com> <20151203165956.GI18315@mournblade.imrryr.org> <20151203170523.GJ18315@mournblade.imrryr.org> <56607D0B.8040808@gemtalksystems.com> <20151203174152.GL18315@mournblade.imrryr.org> <5660B3A5.50303@gemtalksystems.com> <5660B4BA.9000405@openssl.org> Message-ID: <5660B623.7070303@gemtalksystems.com> Are these sym links going to remain this way in subsequent releases? Or will they revert back to the way they were in 1.0.2d? Merging changes like this into svn is a pain because it causes conflicts. Norm Green On 12/3/15 13:31, Matt Caswell wrote: > > On 03/12/15 21:27, Norm Green wrote: >> There are still many broken symbolic links in the new 1.0.2e tarball: >> >> Example: >>> ls -l ./test/ecdsatest.c >> lrwxrwxrwx 1 normg smalltalk 42 Dec 3 06:44 ./test/ecdsatest.c -> >> openssl-1.0.2e/../crypto/ecdsa/ecdsatest.c >>> cat ./test/ecdsatest.c >> cat: ./test/ecdsatest.c: No such file or directory >> >> >> find . -type l -! -exec test -e {} \; -print >> ./apps/md4.c >> ./test/ssltest.c >> ./test/bftest.c >> ./test/md4test.c >> ./test/casttest.c >> ./test/rmdtest.c >> ./test/verify_extra_test.c >> ./test/dsatest.c >> ./test/rc4test.c >> ./test/v3nametest.c >> ./test/sha256t.c >> ./test/srptest.c >> ./test/shatest.c >> ./test/enginetest.c >> ./test/heartbeat_test.c >> ./test/md5test.c >> ./test/md2test.c >> ./test/wp_test.c >> ./test/destest.c >> ./test/hmactest.c >> ./test/bntest.c >> ./test/sha512t.c >> ./test/ideatest.c >> ./test/ecdsatest.c >> ./test/randtest.c >> ./test/jpaketest.c >> ./test/clienthellotest.c >> ./test/evp_extra_test.c >> ./test/dhtest.c >> ./test/sha1test.c >> ./test/rsa_test.c >> ./test/evp_test.c >> ./test/ecdhtest.c >> ./test/mdc2test.c >> ./test/rc5test.c >> ./test/rc2test.c >> ./test/ectest.c >> ./test/exptest.c >> ./test/constant_time_test.c >> >> Will there be a 3rd 1.0.2e tarball released to fix this? > The sym links are not required to successfully build - they get > recreated anyway when you run "Configure". I've had some reports of some > versions of tar (the one I've heard of is on mingw) complaining about > the sym links but actually all the files are extracted ok, and it is > perfectly possible to successfully build. As its a relatively minor > issue I'm currently minded to stick with what we've got. > > Matt > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Thu Dec 3 21:40:19 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 21:40:19 +0000 Subject: [openssl-users] Symlinks STILL broken in 1.0.2e In-Reply-To: <5660B623.7070303@gemtalksystems.com> References: <5660720F.2060308@gemtalksystems.com> <20151203165956.GI18315@mournblade.imrryr.org> <20151203170523.GJ18315@mournblade.imrryr.org> <56607D0B.8040808@gemtalksystems.com> <20151203174152.GL18315@mournblade.imrryr.org> <5660B3A5.50303@gemtalksystems.com> <5660B4BA.9000405@openssl.org> <5660B623.7070303@gemtalksystems.com> Message-ID: <5660B6C3.6000509@openssl.org> On 03/12/15 21:37, Norm Green wrote: > Are these sym links going to remain this way in subsequent releases? Or > will they revert back to the way they were in 1.0.2d? Merging changes > like this into svn is a pain because it causes conflicts. They won't remain broken. It's undecided whether they will go back to the way they were, or be removed completely. Matt From richmoore44 at gmail.com Thu Dec 3 21:50:59 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Thu, 3 Dec 2015 21:50:59 +0000 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <565F3017.60703@lanl.gov> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> Message-ID: On 2 December 2015 at 17:53, Ron Croonenberg wrote: > So the idea is to use an object store on an isolated network and push and > get objects out of it using https. > > ?If network is fully isolated you could use plain text. Using 'https' and null encryption is basically just pretending to do security. Rich.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From champion.p at gmail.com Thu Dec 3 22:32:58 2015 From: champion.p at gmail.com (Jacob Champion) Date: Thu, 3 Dec 2015 14:32:58 -0800 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> Message-ID: <5660C31A.1030104@gmail.com> On 12/03/2015 01:50 PM, Richard Moore wrote: > ?If network is fully isolated you could use plain text. Using 'https' > and null encryption is basically just pretending to do security. I've never done any work with the eNULL ciphers, so please correct me if I'm wrong, but wouldn't they still prevent active tampering with the HTTPS communication? (I understand your point; most web applications today require confidentiality to be secure, since sniffing cookies and passwords will give you access to the system, but maybe the OP has a use case that doesn't require it.) --Jacob From ronc at lanl.gov Thu Dec 3 23:35:22 2015 From: ronc at lanl.gov (Ron Croonenberg) Date: Thu, 3 Dec 2015 16:35:22 -0700 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> Message-ID: <5660D1BA.8030404@lanl.gov> The network is isolated from the outside worl, BUT we still need authentication because different users are using it. So what I preferably want is sort of a set up where, authentication is done the "standard way" and after that just use the https connection without the overhead of actually encrypting anything. (and the lesss modifications and recompiling the better) thanks, Ron On 12/03/2015 02:50 PM, Richard Moore wrote: > > > On 2 December 2015 at 17:53, Ron Croonenberg > wrote: > > So the idea is to use an object store on an isolated network and > push and get objects out of it using https. > > > ?If network is fully isolated you could use plain text. Using 'https' > and null encryption is basically just pretending to do security. > > Rich.? > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From ronc at lanl.gov Thu Dec 3 23:41:22 2015 From: ronc at lanl.gov (Ron Croonenberg) Date: Thu, 3 Dec 2015 16:41:22 -0700 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <5660C31A.1030104@gmail.com> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <5660C31A.1030104@gmail.com> Message-ID: <5660D322.4040106@lanl.gov> 1: correct: you could still evesdrop on the connection, BUT we know who is on there since we authenticated. (It is a storage system, not on a public network and has an internal network for communicating between the node (approx 30PB and 50 servers) We know exactly who are on there and 'things' are tracked per user, it wouldn't make sense to "sniff" other people's connections, besides we'd know. 2: It is for internal communication between nodes in a distributed storage system (as I mentioned 30PB 50 servers). The users will never be directly to the network (an IB fabric between servers) The users are on a front end talking to several "connectors" data transfer nodes. I want the authentication as if it was a Unix box with hard drives. Once you're authenticated you have "unencrypted" access to the drives... the stuff with your permissions. This networked cluster is nothing more than a "cluster drive" On 12/03/2015 03:32 PM, Jacob Champion wrote: > On 12/03/2015 01:50 PM, Richard Moore wrote: >> ?If network is fully isolated you could use plain text. Using 'https' >> and null encryption is basically just pretending to do security. > > I've never done any work with the eNULL ciphers, so please correct me if > I'm wrong, but wouldn't they still prevent active tampering with the > HTTPS communication? > > (I understand your point; most web applications today require > confidentiality to be secure, since sniffing cookies and passwords will > give you access to the system, but maybe the OP has a use case that > doesn't require it.) > > --Jacob > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Michael.Wojcik at microfocus.com Fri Dec 4 02:03:28 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 4 Dec 2015 02:03:28 +0000 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <5660D1BA.8030404@lanl.gov> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <5660D1BA.8030404@lanl.gov> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Ron Croonenberg > Sent: Thursday, December 03, 2015 18:35 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] explicitly including other ciphers. > > The network is isolated from the outside worl, BUT we still need > authentication because different users are using it. > > So what I preferably want is sort of a set up where, > authentication is done the "standard way" and after that just use the > https connection without the overhead of actually encrypting anything. > (and the lesss modifications and recompiling the better) So rather than connecting directly to Apache, how about connecting to a TLS proxy like stunnel, which would then connect to Apache over vanilla HTTP. Configure Apache to only bind to loopback addresses (127/8 and/or ::1), so no one can bypass the proxy. That's assuming stunnel doesn't also play silly buggers with the cipher suite list. -- Michael Wojcik Technology Specialist, Micro Focus From jb-openssl at wisemo.com Fri Dec 4 02:10:40 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 4 Dec 2015 03:10:40 +0100 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <5660D1BA.8030404@lanl.gov> Message-ID: <5660F620.3070409@wisemo.com> On 04/12/2015 03:03, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Ron Croonenberg >> Sent: Thursday, December 03, 2015 18:35 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] explicitly including other ciphers. >> >> The network is isolated from the outside worl, BUT we still need >> authentication because different users are using it. >> >> So what I preferably want is sort of a set up where, >> authentication is done the "standard way" and after that just use the >> https connection without the overhead of actually encrypting anything. >> (and the lesss modifications and recompiling the better) > So rather than connecting directly to Apache, how about connecting to a TLS proxy like stunnel, which would then connect to Apache over vanilla HTTP. Configure Apache to only bind to loopback addresses (127/8 and/or ::1), so no one can bypass the proxy. > > That's assuming stunnel doesn't also play silly buggers with the cipher suite list. > Wouldn't that extra hop via stunnel cost performance (noting that Ron is apparently running at faster than gigabit speed). 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 jb-openssl at wisemo.com Fri Dec 4 02:11:28 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 4 Dec 2015 03:11:28 +0100 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <5660D1BA.8030404@lanl.gov> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <5660D1BA.8030404@lanl.gov> Message-ID: <5660F650.80307@wisemo.com> Since the network is (as I understand it) physically secure against wiretapping, how about using plain http with http auth? Or are you trying to protect against TCP connection hijacks by other computers/processes on the "secure" network? On 04/12/2015 00:35, Ron Croonenberg wrote: > The network is isolated from the outside worl, BUT we still need > authentication because different users are using it. > > So what I preferably want is sort of a set up where, > > authentication is done the "standard way" and after that just use the > https connection without the overhead of actually encrypting anything. > (and the lesss modifications and recompiling the better) > > thanks, > > Ron > > > On 12/03/2015 02:50 PM, Richard Moore wrote: >> >> >> On 2 December 2015 at 17:53, Ron Croonenberg > > wrote: >> >> So the idea is to use an object store on an isolated network and >> push and get objects out of it using https. >> >> >> ???If network is fully isolated you could use plain text. Using 'https' >> and null encryption is basically just pretending to do security. >> 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 mahodardev at gmail.com Fri Dec 4 02:16:44 2015 From: mahodardev at gmail.com (Mahoda Ratnayaka) Date: Fri, 4 Dec 2015 15:16:44 +1300 Subject: [openssl-users] PKEY signing failing in fips mode Message-ID: Hi, I'm trying to change the ssh-rsa.c to be fips compliant. So, after some investigation I added the following code to to ssh_rsa_sign function to make it fips compliant. ========================================================================== signing_key = EVP_PKEY_new(); EVP_PKEY_assign_RSA(signing_key, key->rsa); ctx = EVP_PKEY_CTX_new(signing_key, NULL /* no engine */); EVP_PKEY_sign_init(ctx); EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING); EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()); EVP_PKEY_sign(ctx, sig, &slen, digest, sizeof(digest)); ============================================================================ I also, tried changing the code to be as follows: ========================================================================= + + EVP_MD_CTX_init(&mctx); + EVP_SignInit_ex(&mctx, EVP_sha256 (), NULL); + EVP_SignUpdate(&mctx, data, datalen); slen = RSA_size(key->rsa); sig = xmalloc(slen); - ok = RSA_sign(nid, digest, dlen, sig, &len, key->rsa); + EVP_SignFinal(&mctx, sig, &len, pkey); =========================================================================== But, unfortunately both these approaches end with the following error message. "error:0408E09E:rsa routines:PKEY_RSA_SIGN:operation not allowed in fips mode." It would be much appreciated if anyone can let me know why I'm hitting this, and if there is any way of getting around it. Thanks, Mahoda -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Fri Dec 4 05:32:32 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 4 Dec 2015 05:32:32 +0000 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <5660F620.3070409@wisemo.com> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <5660D1BA.8030404@lanl.gov> <5660F620.3070409@wisemo.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jakob Bohm > Sent: Thursday, December 03, 2015 21:11 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] explicitly including other ciphers. > > On 04/12/2015 03:03, Michael Wojcik wrote: > > So rather than connecting directly to Apache, how about connecting to a > TLS proxy like stunnel, which would then connect to Apache over vanilla > HTTP. Configure Apache to only bind to loopback addresses (127/8 and/or > ::1), so no one can bypass the proxy. > > > Wouldn't that extra hop via stunnel cost performance > (noting that Ron is apparently running at faster than > gigabit speed). Yes, but depending on the actual application behavior, it might be negligible compared to the cost of certificate validation and the like. I don't know enough about the situation to guess whether the impact would be an issue, so I thought I'd propose this as one possible alternative. The application might even be such that a caching proxy could be used in front of Apache for a performance gain - for example if the same content is re-read frequently and the HTTP cache control mechanisms allow it to be usefully cached. -- Michael Wojcik Technology Specialist, Micro Focus From bhat.jayalakshmi at gmail.com Fri Dec 4 06:53:00 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Fri, 4 Dec 2015 12:23:00 +0530 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d Message-ID: Hi All, Recently we have ported OpenSSL 1.0.2d. Everything works perfect except the below explained issue. When we enable only TLS 1.0 protocol and select CBC ciphers, TLS handshake fails with the error "bad record mac". Error is in function static int ssl3_get_record(SSL *s). Error happens at if (i < 0 || mac == NULL || CRYPTO_memcmp(md, mac, (size_t)mac_size) != 0). CRYPTO_memcmp is failing. I debugged further. I replaced constant_time_eq_8 usage in s3_cbc.c with the implementation available in OpenSSL 1.0.1e. Things worked fine. OpenSSL 1.0.2d has this implementation in constant_time_locl.h. OpenSSL 1.0.1e has this implementation local to s3_cbc.c Now my question is whatever I did is it correct? Or Do need to replace complete s3_cbc.c with OpenSSL 1.0.1e? Regards Jaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From ant.rao at gmail.com Fri Dec 4 07:03:40 2015 From: ant.rao at gmail.com (Anty Rao) Date: Fri, 4 Dec 2015 15:03:40 +0800 Subject: [openssl-users] Response from server is lost on close In-Reply-To: References: <565F5FBB.2040706@wisemo.com> Message-ID: Hi, yes, tcp is free to discard receive buffer on receiving RST however after looking through the source code of linux kernel, it seems that process just set state of socket, not discard data in receive buffer. 1. tcp_validate_incoming 5184 /* Step 2: check RST bit */ 5185 if (th->rst) { 5186 tcp_reset(sk); 5187 goto discard; 5188 } 2. tcp_reset 4055 if (!sock_flag(sk, SOCK_DEAD)) 4056 sk->sk_error_report(sk); 4057 4058 tcp_done(sk); 3. tcp_done 3183 void tcp_done(struct sock *sk) 3184 { 3185 if (sk->sk_state == TCP_SYN_SENT || sk->sk_state == TCP_SYN_RECV) 3186 TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_ATTEMPTFAILS); 3187 3188 tcp_set_state(sk, TCP_CLOSE); 3189 tcp_clear_xmit_timers(sk); 3190 3191 sk->sk_shutdown = SHUTDOWN_MASK; 3192 3193 if (!sock_flag(sk, SOCK_DEAD)) 3194 sk->sk_state_change(sk); 3195 else 3196 inet_csk_destroy_sock(sk); 3197 } On Thu, Dec 3, 2015 at 7:53 AM, Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > Just to amplify on Jakob's response: the reason that sometimes you see the > reply is that sometimes your application manages to get it from the stack > before the stack receives and processes the RST from the peer. In the > example you provided, there was a 52ms window in which you could have read > that response before the RST told the stack to throw it away. > > > > If the conversation is aborting for cause - for example because the peer > process exited without reading some received data - then this is the > correct behavior. If the peer is causing the RST by mucking around with the > SO_LINGER socket option, then the peer application is probably broken. > (There are cases where an application might legitimately want to send an > RST rather than a FIN, but they're few and far between.) > > > > In any event, you're at the mercy of TCP's semantics. When the > conversation is aborted, rather than terminated normally, unprocessed data > goes away. That's a Good Thing, because the peer has no way of knowing > whether you received it. > > > > As is usually the case with this sort of issue, the real question is what > problem are you actually trying to solve? "How can I make TCP behave > differently?" is not the right question. > > > > Michael Wojcik > Technology Specialist, Micro Focus > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- Anty Rao -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Dec 4 09:32:07 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 4 Dec 2015 09:32:07 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: Message-ID: <56615D97.7050306@openssl.org> Hello Jaya We're going to need some more information. There isn't a generic problem with CBC ciphers and TLS1.0 in 1.0.2d (it's working fine for me) - so there is something specific about your environment that is causing the issue. Comments inserted below. On 04/12/15 06:53, Jayalakshmi bhat wrote: > Hi All, > > > > Recently we have ported OpenSSL 1.0.2d. Everything works perfect except > the below explained issue. Is your application a client or a server? Are both ends using OpenSSL 1.0.2d? If not, what is the other end using? > When we enable only TLS 1.0 protocol and select CBC ciphers, How exactly are you doing that? Which specific cipher are you seeing fail? > Now my question is whatever I did is it correct? That would not be a recommended solution > Or Do need to replace > complete s3_cbc.c with OpenSSL 1.0.1e? No. You cannot just copy and paste stuff from 1.0.1 to 1.0.2. Some other questions: Are you able to provide a packet capture? How did you build OpenSSL...i.e. what "Configure" options did you use? What O/S is this on? Matt From sonali.ritu10 at gmail.com Fri Dec 4 10:40:39 2015 From: sonali.ritu10 at gmail.com (Sonali Priyadarshini) Date: Fri, 4 Dec 2015 16:10:39 +0530 Subject: [openssl-users] Openssl Compilation Error Message-ID: Hi all I am compiling Openssl 1.0.h version in SLES 11 SP1 ,in make command I am facing some errors.I have the instructions properly as given. The error was: /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: libcrypto.a(x86_64-gcc.o): relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC libcrypto.a(x86_64-gcc.o): could not read symbols: Bad value collect2: ld returned 1 exit status make[4]: *** [link_a.gnu] Error 1 make[4]: Leaving directory `/home/build/ps/openssl-1.0.1h.tar/openssl-1.0.1h' make[3]: *** [do_linux-shared] Error 2 make[3]: Leaving directory `/home/build/ps/openssl-1.0.1h.tar/openssl-1.0.1h' make[2]: *** [libcrypto.so.1.0.0] Error 2 make[2]: Leaving directory `/home/build/ps/openssl-1.0.1h.tar/openssl-1.0.1h' make[1]: *** [shared] Error 2 make[1]: Leaving directory `/home/build/ps/openssl-1.0.1h.tar/openssl-1.0.1h/crypto' make: *** [build_crypto] Error 1 I followed this link https://stackoverflow.com/questions/10368671/cannot-find-libcrypto-library-error for solution. Can anyone please check this.The reason behind this error. Thanks & regards Sonali -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Fri Dec 4 11:31:23 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Fri, 4 Dec 2015 17:01:23 +0530 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <56615D97.7050306@openssl.org> References: <56615D97.7050306@openssl.org> Message-ID: Hi Matt, Thanks a lot for the response. Is your application a client or a server? Are both ends using OpenSSL 1.0.2d? If not, what is the other end using? >>Our device has both TLS client,server apps. As client, device communicates with radius server, LDAP server etc.As server device is accessed using various web browsers. Hence both the end will not be OpenSSL 1.0.2d. How exactly are you doing that? Which specific cipher are you seeing fail? >> We have provided user option to select TLS protocol versions similar to the browsers. Depending upon the user configurations we set the protocol flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL context using SSL_CTX_clear_options/SSL_CTX_set_options. >> We have provided user option to chose ciphers as well. All these are in the application space,no changes have been done and they have been working good with OpenSSL 1.0.1c. Only the library is upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers and with both the ciphers issue is seen. Are you able to provide a packet capture? >> Please find the attached traces for server mode. What O/S is this on? >>This is built for WinCE and Vxworks Regards Jaya On Fri, Dec 4, 2015 at 3:02 PM, Matt Caswell wrote: > Hello Jaya > > We're going to need some more information. There isn't a generic problem > with CBC ciphers and TLS1.0 in 1.0.2d (it's working fine for me) - so > there is something specific about your environment that is causing the > issue. Comments inserted below. > > On 04/12/15 06:53, Jayalakshmi bhat wrote: > > Hi All, > > > > > > > > Recently we have ported OpenSSL 1.0.2d. Everything works perfect except > > the below explained issue. > > Is your application a client or a server? Are both ends using OpenSSL > 1.0.2d? If not, what is the other end using? > > > > When we enable only TLS 1.0 protocol and select CBC ciphers, > > How exactly are you doing that? Which specific cipher are you seeing fail? > > > > Now my question is whatever I did is it correct? > > That would not be a recommended solution > > > Or Do need to replace > > complete s3_cbc.c with OpenSSL 1.0.1e? > > No. You cannot just copy and paste stuff from 1.0.1 to 1.0.2. > > Some other questions: > > Are you able to provide a packet capture? > How did you build OpenSSL...i.e. what "Configure" options did you use? > What O/S is this on? > > 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: server.pcapng Type: application/octet-stream Size: 3692 bytes Desc: not available URL: From jb-openssl at wisemo.com Fri Dec 4 12:35:27 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 4 Dec 2015 13:35:27 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> Message-ID: <5661888F.7090201@wisemo.com> For clarity, which version of WinCE, and which CPU (Arm, MIPS,PPC, x86, SH3, SH4, ...)? Which Microsoft Compiler version (EVC3, EVC4, one of the Visual Studio projects, 3rd party compiler) and which exact compiler version (reported by running the compiler executable (named according to CPU) with no arguments. I ask because your proposed fix may be affected by compiler and/or CPU quirks. On 04/12/2015 12:31, Jayalakshmi bhat wrote: > Hi Matt, > > Thanks a lot for the response. > > Is your application a client or a server? Are both ends using OpenSSL > 1.0.2d? If not, what is the other end using? > >>Our device has both TLS client,server apps. As client, device communicates with radius > server, LDAP server etc.As server device is accessed using various > web browsers. > Hence both the end will not be OpenSSL 1.0.2d. > > How exactly are you doing that? Which specific cipher are you seeing fail? > >> We have provided user option to select TLS protocol versions similar to the browsers. > Depending upon the user configurations we set the protocol flags > (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL > context using SSL_CTX_clear_options/SSL_CTX_set_options. > >> We have provided user option to chose ciphers as well. > All these are in the application space,no changes have been done and > they have been working good with OpenSSL 1.0.1c. Only the library is > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC > ciphers and with both the ciphers issue is seen. > > Are you able to provide a packet capture? > >> Please find the attached traces for server mode. > What O/S is this on? > >>This is built for WinCE and Vxworks > > Regards > Jaya > > > > On Fri, Dec 4, 2015 at 3:02 PM, Matt Caswell > wrote: > > Hello Jaya > > We're going to need some more information. There isn't a generic > problem > with CBC ciphers and TLS1.0 in 1.0.2d (it's working fine for me) - so > there is something specific about your environment that is causing the > issue. Comments inserted below. > > On 04/12/15 06:53, Jayalakshmi bhat wrote: > > Hi All, > > > > > > > > Recently we have ported OpenSSL 1.0.2d. Everything works perfect > except > > the below explained issue. > > Is your application a client or a server? Are both ends using OpenSSL > 1.0.2d? If not, what is the other end using? > > > > When we enable only TLS 1.0 protocol and select CBC ciphers, > > How exactly are you doing that? Which specific cipher are you > seeing fail? > > > > Now my question is whatever I did is it correct? > > That would not be a recommended solution > > > Or Do need to replace > > complete s3_cbc.c with OpenSSL 1.0.1e? > > No. You cannot just copy and paste stuff from 1.0.1 to 1.0.2. > > Some other questions: > > Are you able to provide a packet capture? > How did you build OpenSSL...i.e. what "Configure" options did you use? > What O/S is this on? > > 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Dec 4 13:34:33 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 4 Dec 2015 13:34:33 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> Message-ID: <56619669.2020403@openssl.org> On 04/12/15 11:31, Jayalakshmi bhat wrote: > Hi Matt, > > Thanks a lot for the response. > > Is your application a client or a server? Are both ends using > OpenSSL 1.0.2d? If not, what is the other end using? >>>Our device has both TLS client,server apps. As client, device communicates with radius server, LDAP server etc.As > server device is accessed using various web browsers. > Hence both the end will not be OpenSSL 1.0.2d. > > How exactly are you doing that? Which specific cipher are you seeing fail? >>> We have provided user option to select TLS protocol versions similar to the browsers. Depending upon the user configurations we set the protocol flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL context using SSL_CTX_clear_options/SSL_CTX_set_options. >>> We have provided user option to chose ciphers as well. > All these are in the application space,no changes have been done and > they have been working good with OpenSSL 1.0.1c. Only the library is > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers > and with both the ciphers issue is seen. > > Are you able to provide a packet capture? >>> Please find the attached traces for server mode. > What O/S is this on? >>>This is built for WinCE and Vxworks Thanks. Please could you also send the exact patch that you applied that resolved the issue? Matt From openssl at openssl.org Fri Dec 4 14:41:32 2015 From: openssl at openssl.org (OpenSSL) Date: Fri, 4 Dec 2015 14:41:32 +0000 Subject: [openssl-users] Updated OpenSSL Security Advisory Message-ID: <20151204144132.GA16102@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [3 Dec 2015] - Updated [4 Dec 2015] ============================================================= [Updated 4 Dec 2015]: This advisory has been updated to include the details of CVE-2015-1794, a Low severity issue affecting OpenSSL 1.0.2 which had a fix included in the released packages but was missed from the advisory text. NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE 0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS. BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193) ================================================================== 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. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2e This issue was reported to OpenSSL on August 13 2015 by Hanno B??ck. The fix was developed by Andy Polyakov of the OpenSSL development team. Certificate verify crash with missing PSS parameter (CVE-2015-3194) =================================================================== Severity: Moderate The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and absent mask generation function parameter. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q This issue was reported to OpenSSL on August 27 2015 by Lo??c Jonas Etienne (Qnective AG). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. X509_ATTRIBUTE memory leak (CVE-2015-3195) ========================================== Severity: Moderate When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak memory. This structure is used by the PKCS#7 and CMS routines so any application which reads PKCS#7 or CMS data from untrusted sources is affected. SSL/TLS is not affected. This issue affects OpenSSL versions 1.0.2 and 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q OpenSSL 1.0.0 users should upgrade to 1.0.0t OpenSSL 0.9.8 users should upgrade to 0.9.8zh This issue was reported to OpenSSL on November 9 2015 by Adam Langley (Google/BoringSSL) using libFuzzer. The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Race condition handling PSK identify hint (CVE-2015-3196) ========================================================= Severity: Low If PSK identity hints are received by a multi-threaded client then the values are wrongly updated in the parent SSL_CTX structure. This can result in a race condition potentially leading to a double free of the identify hint data. This issue was fixed in OpenSSL 1.0.2d and 1.0.1p but has not been previously listed in an OpenSSL security advisory. This issue also affects OpenSSL 1.0.0 and has not been previously fixed in an OpenSSL 1.0.0 release. OpenSSL 1.0.2 users should upgrade to 1.0.2d OpenSSL 1.0.1 users should upgrade to 1.0.1p OpenSSL 1.0.0 users should upgrade to 1.0.0t The fix for this issue can be identified in the OpenSSL git repository by commit ids 3c66a669dfc7 (1.0.2), d6be3124f228 (1.0.1) and 1392c238657e (1.0.0). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Anon DH ServerKeyExchange with 0 p parameter (CVE-2015-1794) ============================================================ Severity: Low If a client receives a ServerKeyExchange for an anonymous DH ciphersuite with the value of p set to 0 then a seg fault can occur leading to a possible denial of service attack. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2e This issue was reported to OpenSSL on August 3 2015 by Guy Leaver (Cisco). The fix was developed by Matt Caswell of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these versions will be provided after that date. In the absence of significant security issues being identified prior to that date, the 1.0.0t and 0.9.8zh releases will be the last for those versions. Users of these versions are advised to upgrade. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20151203.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/about/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYaMQAAoJENnE0m0OYESRvMAIAKkGjtOTKeqpUuWvzCVs8VV/ lHWZ7ZKZMI3LQHLX0lOTu8Ypipth83eHPDQxEzhkjzjGPsVrEZ+2Labm/awTKr7H UhrvFEl0R1hag/ssvyXWOaQ+ZyHITzeSHVcOu35tf9cSrHf6JMYOwV1H2JDyAoX/ 7Spwxj/scmH2VS9Xz9sIzV5FTxZV1V0QrerU67gjp7ZYiUMW+4nvCGsEk6fOW52G R06XjV4HyDP9TbAVYexu8uqpBLPavWT+zGxDlMZzyY41OptDHcHwPRfI/pgPdA2g m9oVmxGRAi6MMz/uOAXaUC5dPFSqt9iJATIrFALpXsY4OjebpqFucN/qyT0KDco= =VWCg -----END PGP SIGNATURE----- From openssl-users at dukhovni.org Fri Dec 4 17:16:23 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 4 Dec 2015 17:16:23 +0000 Subject: [openssl-users] [openssl-dev] [openssl.org #4166] Bug: OpenSSL 1.0.1l fails to verify SOME root CAs: error:num=20:unable to get local issuer certificate In-Reply-To: References: <56615C48.7010003@schonrocks.com> Message-ID: <20151204171623.GW18315@mournblade.imrryr.org> [ Redirecting to openssl-users ] On Fri, Dec 04, 2015 at 03:25:35PM +0000, Oliver Schonrock via RT wrote: > To Reproduce: > $ openssl s_client -connect api.textmarketer.co.uk:443 > depth=2 C = US, O = "thawte, Inc.", OU = Certification Services > Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = > thawte Primary Root CA > verify error:num=20:unable to get local issuer certificate > ... Despite the CN string, the certificate presented by that server on the wire is not a root certificate. See the attached chain. Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server at thawte.com Validity Not Before: Nov 17 00:00:00 2006 GMT Not After : Dec 30 23:59:59 2020 GMT Subject: C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA > The same command on FreeBSD 10.2 (OpenSSL 1.0.1p) results in: > $ openssl s_client -connect api.textmarketer.co.uk:443 > depth=2 C = US, O = "thawte, Inc.", OU = Certification Services > Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = > thawte Primary Root CA > verify return:1 In 1.0.1p OpenSSL looks in the trust store before consulting the provided chain. You likely have a better Thawte certificate there than the one sent by the server. -- Viktor. -------------- next part -------------- Certificate: Data: Version: 3 (0x2) Serial Number: 21:b8:6b:cc:47:2f:b7:b0:d1:0e:15:eb:af:30:61:8f Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=thawte, Inc., OU=Domain Validated SSL, CN=thawte DV SSL CA - G2 Validity Not Before: May 25 00:00:00 2015 GMT Not After : Jul 23 23:59:59 2017 GMT Subject: CN=api.textmarketer.co.uk Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:a6:ca:50:c1:29:ad:4d:da:26:ca:de:ac:8e:05: ba:ff:00:ae:18:3f:02:ad:39:66:ec:f6:16:23:f0: 80:94:cc:8c:d5:96:9c:63:bc:50:63:07:8b:ad:d5: 86:09:cf:2a:ff:9a:ca:ae:0e:88:07:9b:32:7b:4e: b0:12:a1:df:a9:02:b5:96:9c:61:55:17:30:79:14: 2c:38:ea:18:07:b4:a1:2d:40:a2:5d:62:0b:bd:67: 41:0e:c9:4e:a3:bd:bf:ce:03:ac:0f:ac:fc:a2:7c: 23:6b:05:ea:88:78:7e:c6:2c:ac:6f:8c:67:2b:6f: 15:c7:cb:a7:ad:2e:8c:27:2f:4f:02:92:1d:6d:72: 15:f7:5d:bf:55:be:53:57:c5:0c:38:29:33:a7:f0: 97:02:c9:00:88:0e:bc:7e:2e:23:37:3b:54:ce:98: 24:fd:6c:cd:5b:d4:5e:fe:c4:8b:60:0e:c6:54:63: 7c:d6:ad:91:eb:53:ce:d6:b6:77:9d:9e:fa:20:a7: 20:7f:2f:00:59:4b:af:50:09:f4:8a:61:58:3d:b3: b8:ba:ce:79:a7:66:00:c3:a3:a5:a2:71:ab:b3:6e: 40:66:32:c4:b4:2b:b1:37:f5:0c:93:66:68:54:5c: ba:35:ef:75:62:70:9a:2b:d3:8f:b4:de:3c:79:a4: ea:c3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: DNS:api.textmarketer.co.uk X509v3 Basic Constraints: CA:FALSE X509v3 CRL Distribution Points: Full Name: URI:http://tn.symcb.com/tn.crl X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 CPS: https://www.thawte.com/cps User Notice: Explicit Text: https://www.thawte.com/repository X509v3 Authority Key Identifier: keyid:9F:B8:C1:A9:6C:F2:F5:C0:22:2A:94:ED:5C:99:AC:D4:EC:D7:C6:07 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Authority Information Access: OCSP - URI:http://tn.symcd.com CA Issuers - URI:http://tn.symcb.com/tn.crt Signature Algorithm: sha256WithRSAEncryption 84:85:37:ae:9c:6f:e8:3f:3b:3d:da:a4:a9:ff:ba:56:3d:ad: f9:bf:ea:8f:d8:9d:4b:35:ac:73:76:c4:f6:67:1b:c0:1f:fe: 7e:3d:56:3b:70:e0:74:71:bd:0d:e0:cd:a7:03:61:8c:25:72: 4c:6a:c2:db:d7:fd:14:7b:92:0a:8d:2b:0f:f7:c0:c2:0e:46: 65:29:21:cf:b1:aa:ed:92:b0:db:e7:fe:54:de:fb:1a:a7:b0: 61:14:fa:a6:14:ab:99:a3:26:8e:75:97:cf:de:fb:33:25:10: ef:23:da:91:14:d8:2a:d4:cf:0d:dc:e7:14:4b:9a:ed:31:34: e0:a1:7c:1e:2d:0f:e1:52:0d:83:3c:c8:eb:df:43:85:4b:96: 03:e8:75:a6:46:9b:99:6e:02:e4:38:0b:9c:93:c2:8e:97:db: 27:77:75:a6:e6:46:c1:02:bd:d4:14:a0:af:3e:f8:56:4f:94: 0c:e6:d3:49:5e:67:c8:4c:be:75:a3:a5:8f:b6:6a:4c:3d:52: ab:24:ac:e5:69:5f:d7:fe:01:08:ce:24:7a:ad:0f:3c:6f:46: fe:b9:5a:2d:c5:37:00:5e:6b:40:ab:1b:61:7e:8c:13:df:8f: 5c:e1:76:7e:73:e3:28:33:07:3b:31:81:03:fe:91:a2:ec:f5: 99:95:56:ed -----BEGIN CERTIFICATE----- MIIEiDCCA3CgAwIBAgIQIbhrzEcvt7DRDhXrrzBhjzANBgkqhkiG9w0BAQsFADBj MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMdGhhd3RlLCBJbmMuMR0wGwYDVQQLExRE b21haW4gVmFsaWRhdGVkIFNTTDEeMBwGA1UEAxMVdGhhd3RlIERWIFNTTCBDQSAt IEcyMB4XDTE1MDUyNTAwMDAwMFoXDTE3MDcyMzIzNTk1OVowITEfMB0GA1UEAxQW YXBpLnRleHRtYXJrZXRlci5jby51azCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKbKUMEprU3aJsrerI4Fuv8Arhg/Aq05Zuz2FiPwgJTMjNWWnGO8UGMH i63VhgnPKv+ayq4OiAebMntOsBKh36kCtZacYVUXMHkULDjqGAe0oS1Aol1iC71n QQ7JTqO9v84DrA+s/KJ8I2sF6oh4fsYsrG+MZytvFcfLp60ujCcvTwKSHW1yFfdd v1W+U1fFDDgpM6fwlwLJAIgOvH4uIzc7VM6YJP1szVvUXv7Ei2AOxlRjfNatketT zta2d52e+iCnIH8vAFlLr1AJ9IphWD2zuLrOeadmAMOjpaJxq7NuQGYyxLQrsTf1 DJNmaFRcujXvdWJwmivTj7TePHmk6sMCAwEAAaOCAXgwggF0MCEGA1UdEQQaMBiC FmFwaS50ZXh0bWFya2V0ZXIuY28udWswCQYDVR0TBAIwADArBgNVHR8EJDAiMCCg HqAchhpodHRwOi8vdG4uc3ltY2IuY29tL3RuLmNybDBuBgNVHSAEZzBlMGMGBmeB DAECATBZMCYGCCsGAQUFBwIBFhpodHRwczovL3d3dy50aGF3dGUuY29tL2NwczAv BggrBgEFBQcCAjAjDCFodHRwczovL3d3dy50aGF3dGUuY29tL3JlcG9zaXRvcnkw HwYDVR0jBBgwFoAUn7jBqWzy9cAiKpTtXJms1OzXxgcwDgYDVR0PAQH/BAQDAgWg MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBXBggrBgEFBQcBAQRLMEkw HwYIKwYBBQUHMAGGE2h0dHA6Ly90bi5zeW1jZC5jb20wJgYIKwYBBQUHMAKGGmh0 dHA6Ly90bi5zeW1jYi5jb20vdG4uY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCEhTeu nG/oPzs92qSp/7pWPa35v+qP2J1LNaxzdsT2ZxvAH/5+PVY7cOB0cb0N4M2nA2GM JXJMasLb1/0Ue5IKjSsP98DCDkZlKSHPsartkrDb5/5U3vsap7BhFPqmFKuZoyaO dZfP3vszJRDvI9qRFNgq1M8N3OcUS5rtMTTgoXweLQ/hUg2DPMjr30OFS5YD6HWm RpuZbgLkOAuck8KOl9snd3Wm5kbBAr3UFKCvPvhWT5QM5tNJXmfITL51o6WPtmpM PVKrJKzlaV/X/gEIziR6rQ88b0b+uVotxTcAXmtAqxthfowT349c4XZ+c+MoMwc7 MYED/pGi7PWZlVbt -----END CERTIFICATE----- Certificate: Data: Version: 3 (0x2) Serial Number: 2c:69:e1:2f:6a:67:0b:d9:9d:d2:0f:91:9e:f0:9e:51 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA Validity Not Before: Jun 10 00:00:00 2014 GMT Not After : Jun 9 23:59:59 2024 GMT Subject: C=US, O=thawte, Inc., OU=Domain Validated SSL, CN=thawte DV SSL CA - G2 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ea:94:07:85:c8:41:2c:f6:83:12:6c:92:5f:ab: 1f:00:d4:96:6f:74:cd:2e:11:e9:6c:0f:39:01:b9: 48:90:40:39:4d:c4:a2:c8:79:6a:a5:9a:bd:91:44: 65:77:54:ad:ff:25:5f:ee:42:fb:b3:02:0f:ea:5d: 7a:dd:1a:54:9e:d7:73:42:9b:cc:79:5f:c5:4d:f4: b7:0b:18:39:20:7a:dd:50:01:5d:34:45:5f:4c:11: 0e:f5:87:26:26:b4:b0:f3:7e:71:a0:31:71:50:89: 68:5a:63:8a:14:62:e5:8c:3a:16:55:0d:3e:eb:aa: 80:1d:71:7a:e3:87:07:ab:bd:a2:74:cd:da:08:01: 9d:1b:cc:27:88:8c:47:d4:69:25:42:d6:bb:50:6d: 85:50:d0:48:82:0d:08:9f:e9:23:e3:42:c6:3c:98: b8:bb:6e:c5:70:13:df:19:1d:01:fd:d2:b5:4e:e6: 62:f4:07:fa:6b:7d:11:77:c4:62:4f:40:4e:a5:78: 97:ab:2c:4d:0c:a7:7c:c3:c4:50:32:9f:d0:70:9b: 0f:ff:ff:75:59:34:85:ad:49:d5:35:ee:4f:5b:d4: d4:36:95:a0:7e:e8:c5:a1:1c:bd:13:4e:7d:ee:63: 6a:96:19:99:c8:a7:2a:00:e6:51:8d:46:eb:30:58: e8:2d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Certificate Policies: Policy: 2.16.840.1.113733.1.7.54 CPS: https://www.thawte.com/cps X509v3 Key Usage: critical Certificate Sign, CRL Sign Authority Information Access: OCSP - URI:http://t.symcd.com X509v3 CRL Distribution Points: Full Name: URI:http://t.symcb.com/ThawtePCA.crl X509v3 Subject Alternative Name: DirName:/CN=SymantecPKI-1-698 X509v3 Subject Key Identifier: 9F:B8:C1:A9:6C:F2:F5:C0:22:2A:94:ED:5C:99:AC:D4:EC:D7:C6:07 X509v3 Authority Key Identifier: keyid:7B:5B:45:CF:AF:CE:CB:7A:FD:31:92:1A:6A:B6:F3:46:EB:57:48:50 Signature Algorithm: sha256WithRSAEncryption 53:54:f2:47:a8:02:d7:ef:aa:35:78:be:4a:08:0d:90:18:4b: 6d:9e:2a:53:2b:e9:54:17:77:74:29:7e:d0:37:07:05:b8:e4: fa:b8:b4:63:98:44:dc:c6:4f:81:06:8c:3a:be:c7:30:57:c6: 70:fc:d6:93:19:9f:c3:55:d7:3e:1f:72:8a:9d:30:5a:35:97: 32:cb:63:e4:c6:72:df:fb:68:ca:69:2f:db:cd:50:38:3e:2b: bb:ab:3b:82:c7:fd:4b:9b:bd:7c:41:98:ef:01:53:d8:35:8f: 25:c9:03:06:e6:9c:57:c1:51:0f:9e:f6:7d:93:4d:f8:76:c8: 3a:6b:f4:c4:8f:33:32:7f:9d:21:84:34:d9:a7:f9:92:fa:41: 91:61:84:05:9d:a3:79:46:ce:67:e7:81:f2:5e:ac:4c:bc:a8: ab:6a:6d:15:e2:9c:4e:5a:d9:63:80:bc:f7:42:eb:9a:44:c6: 8c:6b:06:36:b4:8b:32:89:de:c2:f1:a8:26:aa:a9:ac:ff:ea: 71:a6:e7:8c:41:fa:17:35:bb:b3:87:31:a9:93:c2:c8:58:e1: 0a:4e:95:83:9c:b9:ed:3b:a5:ef:08:e0:74:f9:c3:1b:e6:07: a3:ee:07:d7:42:22:79:21:a0:a1:d4:1d:26:d3:d0:d6:a6:5d: 2b:41:c0:79 -----BEGIN CERTIFICATE----- MIIE0jCCA7qgAwIBAgIQLGnhL2pnC9md0g+RnvCeUTANBgkqhkiG9w0BAQsFADCB qTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjE4MDYGA1UECxMvKGMpIDIw MDYgdGhhd3RlLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNV BAMTFnRoYXd0ZSBQcmltYXJ5IFJvb3QgQ0EwHhcNMTQwNjEwMDAwMDAwWhcNMjQw NjA5MjM1OTU5WjBjMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMdGhhd3RlLCBJbmMu MR0wGwYDVQQLExREb21haW4gVmFsaWRhdGVkIFNTTDEeMBwGA1UEAxMVdGhhd3Rl IERWIFNTTCBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 6pQHhchBLPaDEmySX6sfANSWb3TNLhHpbA85AblIkEA5TcSiyHlqpZq9kURld1St /yVf7kL7swIP6l163RpUntdzQpvMeV/FTfS3Cxg5IHrdUAFdNEVfTBEO9YcmJrSw 835xoDFxUIloWmOKFGLljDoWVQ0+66qAHXF644cHq72idM3aCAGdG8wniIxH1Gkl Qta7UG2FUNBIgg0In+kj40LGPJi4u27FcBPfGR0B/dK1TuZi9Af6a30Rd8RiT0BO pXiXqyxNDKd8w8RQMp/QcJsP//91WTSFrUnVNe5PW9TUNpWgfujFoRy9E0597mNq lhmZyKcqAOZRjUbrMFjoLQIDAQABo4IBOTCCATUwEgYDVR0TAQH/BAgwBgEB/wIB ADBBBgNVHSAEOjA4MDYGCmCGSAGG+EUBBzYwKDAmBggrBgEFBQcCARYaaHR0cHM6 Ly93d3cudGhhd3RlLmNvbS9jcHMwDgYDVR0PAQH/BAQDAgEGMC4GCCsGAQUFBwEB BCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL3Quc3ltY2QuY29tMDEGA1UdHwQqMCgw JqAkoCKGIGh0dHA6Ly90LnN5bWNiLmNvbS9UaGF3dGVQQ0EuY3JsMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFTeW1hbnRlY1BLSS0xLTY5ODAdBgNVHQ4EFgQUn7jB qWzy9cAiKpTtXJms1OzXxgcwHwYDVR0jBBgwFoAUe1tFz6/Oy3r9MZIaarbzRutX SFAwDQYJKoZIhvcNAQELBQADggEBAFNU8keoAtfvqjV4vkoIDZAYS22eKlMr6VQX d3QpftA3BwW45Pq4tGOYRNzGT4EGjDq+xzBXxnD81pMZn8NV1z4fcoqdMFo1lzLL Y+TGct/7aMppL9vNUDg+K7urO4LH/UubvXxBmO8BU9g1jyXJAwbmnFfBUQ+e9n2T Tfh2yDpr9MSPMzJ/nSGENNmn+ZL6QZFhhAWdo3lGzmfngfJerEy8qKtqbRXinE5a 2WOAvPdC65pExoxrBja0izKJ3sLxqCaqqaz/6nGm54xB+hc1u7OHMamTwshY4QpO lYOcue07pe8I4HT5wxvmB6PuB9dCInkhoKHUHSbT0NamXStBwHk= -----END CERTIFICATE----- Certificate: Data: Version: 3 (0x2) Serial Number: 5f:a6:be:80:b6:86:c6:2f:01:ed:0c:ab:b1:96:a1:05 Signature Algorithm: sha1WithRSAEncryption Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server at thawte.com Validity Not Before: Nov 17 00:00:00 2006 GMT Not After : Dec 30 23:59:59 2020 GMT Subject: C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ac:a0:f0:fb:80:59:d4:9c:c7:a4:cf:9d:a1:59: 73:09:10:45:0c:0d:2c:6e:68:f1:6c:5b:48:68:49: 59:37:fc:0b:33:19:c2:77:7f:cc:10:2d:95:34:1c: e6:eb:4d:09:a7:1c:d2:b8:c9:97:36:02:b7:89:d4: 24:5f:06:c0:cc:44:94:94:8d:02:62:6f:eb:5a:dd: 11:8d:28:9a:5c:84:90:10:7a:0d:bd:74:66:2f:6a: 38:a0:e2:d5:54:44:eb:1d:07:9f:07:ba:6f:ee:e9: fd:4e:0b:29:f5:3e:84:a0:01:f1:9c:ab:f8:1c:7e: 89:a4:e8:a1:d8:71:65:0d:a3:51:7b:ee:bc:d2:22: 60:0d:b9:5b:9d:df:ba:fc:51:5b:0b:af:98:b2:e9: 2e:e9:04:e8:62:87:de:2b:c8:d7:4e:c1:4c:64:1e: dd:cf:87:58:ba:4a:4f:ca:68:07:1d:1c:9d:4a:c6: d5:2f:91:cc:7c:71:72:1c:c5:c0:67:eb:32:fd:c9: 92:5c:94:da:85:c0:9b:bf:53:7d:2b:09:f4:8c:9d: 91:1f:97:6a:52:cb:de:09:36:a4:77:d8:7b:87:50: 44:d5:3e:6e:29:69:fb:39:49:26:1e:09:a5:80:7b: 40:2d:eb:e8:27:85:c9:fe:61:fd:7e:e6:7c:97:1d: d5:9d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Certificate Policies: Policy: X509v3 Any Policy CPS: https://www.thawte.com/cps X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Key Identifier: 7B:5B:45:CF:AF:CE:CB:7A:FD:31:92:1A:6A:B6:F3:46:EB:57:48:50 X509v3 CRL Distribution Points: Full Name: URI:http://crl.thawte.com/ThawtePremiumServerCA.crl X509v3 Extended Key Usage: Netscape Server Gated Crypto, 2.16.840.1.113733.1.8.1 X509v3 Authority Key Identifier: DirName:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server at thawte.com serial:01 Signature Algorithm: sha1WithRSAEncryption 2b:ca:12:c9:dd:d7:cc:63:1c:9b:31:35:4a:dd:e4:b7:f6:9d: d1:a4:fb:1e:f8:47:f9:ae:07:8e:0d:58:12:fb:da:ed:b5:cc: 33:e5:97:68:47:61:42:d5:66:a9:6e:1e:47:bf:85:db:7d:58: d1:77:5a:cc:90:61:98:9a:29:f5:9d:b1:cf:b8:dc:f3:7b:80: 47:48:d1:7d:f4:68:8c:c4:41:cb:b4:e9:fd:f0:23:e0:b1:9b: 76:2a:6d:28:56:a3:8c:cd:e9:ec:21:00:71:f0:5f:dd:50:a5: 69:42:1b:83:11:5d:84:28:d3:27:ae:ec:2a:ab:2f:60:42:c5: c4:78 -----BEGIN CERTIFICATE----- MIIFUTCCBLqgAwIBAgIQX6a+gLaGxi8B7QyrsZahBTANBgkqhkiG9w0BAQUFADCB zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl cnZlckB0aGF3dGUuY29tMB4XDTA2MTExNzAwMDAwMFoXDTIwMTIzMDIzNTk1OVow gakxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwx0aGF3dGUsIEluYy4xKDAmBgNVBAsT H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xODA2BgNVBAsTLyhjKSAy MDA2IHRoYXd0ZSwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYD VQQDExZ0aGF3dGUgUHJpbWFyeSBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEArKDw+4BZ1JzHpM+doVlzCRBFDA0sbmjxbFtIaElZN/wLMxnC d3/MEC2VNBzm600JpxzSuMmXNgK3idQkXwbAzESUlI0CYm/rWt0RjSiaXISQEHoN vXRmL2o4oOLVVETrHQefB7pv7un9Tgsp9T6EoAHxnKv4HH6JpOih2HFlDaNRe+68 0iJgDblbnd+6/FFbC6+Ysuku6QToYofeK8jXTsFMZB7dz4dYukpPymgHHRydSsbV L5HMfHFyHMXAZ+sy/cmSXJTahcCbv1N9Kwn0jJ2RH5dqUsveCTakd9h7h1BE1T5u KWn7OUkmHgmlgHtALevoJ4XJ/mH9fuZ8lx3VnQIDAQABo4IBzTCCAckwDwYDVR0T AQH/BAUwAwEB/zA7BgNVHSAENDAyMDAGBFUdIAAwKDAmBggrBgEFBQcCARYaaHR0 cHM6Ly93d3cudGhhd3RlLmNvbS9jcHMwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBR7W0XPr87Lev0xkhpqtvNG61dIUDBABgNVHR8EOTA3MDWgM6Axhi9odHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUHJlbWl1bVNlcnZlckNBLmNybDAgBgNVHSUE GTAXBglghkgBhvhCBAEGCmCGSAGG+EUBCAEwgeUGA1UdIwSB3TCB2qGB1KSB0TCB zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl cnZlckB0aGF3dGUuY29tggEBMA0GCSqGSIb3DQEBBQUAA4GBACvKEsnd18xjHJsx NUrd5Lf2ndGk+x74R/muB44NWBL72u21zDPll2hHYULVZqluHke/hdt9WNF3WsyQ YZiaKfWdsc+43PN7gEdI0X30aIzEQcu06f3wI+Cxm3YqbShWo4zN6ewhAHHwX91Q pWlCG4MRXYQo0yeu7CqrL2BCxcR4 -----END CERTIFICATE----- From nounou.dadoun at avigilon.com Fri Dec 4 17:29:54 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Fri, 4 Dec 2015 17:29:54 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <56619669.2020403@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> Message-ID: <8149AB08BCB1F54F92680ED6104891A0DFF60A@mbx027-w1-ca-4.exch027.domain.local> Just coincidentally we may have an issue in a pending release that looks much like this scenario as well; In our case, the server is 1.0.2d and the client is not. I'll update details as I get them .. N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Friday, December 04, 2015 5:35 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d On 04/12/15 11:31, Jayalakshmi bhat wrote: > Hi Matt, > > Thanks a lot for the response. > > Is your application a client or a server? Are both ends using OpenSSL > 1.0.2d? If not, what is the other end using? >>>Our device has both TLS client,server apps. As client, device >>>communicates with radius server, LDAP server etc.As > server device is accessed using various web browsers. > Hence both the end will not be OpenSSL 1.0.2d. > > How exactly are you doing that? Which specific cipher are you seeing fail? >>> We have provided user option to select TLS protocol versions similar to the browsers. Depending upon the user configurations we set the protocol flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL context using SSL_CTX_clear_options/SSL_CTX_set_options. >>> We have provided user option to chose ciphers as well. > All these are in the application space,no changes have been done and > they have been working good with OpenSSL 1.0.1c. Only the library is > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC > ciphers and with both the ciphers issue is seen. > > Are you able to provide a packet capture? >>> Please find the attached traces for server mode. > What O/S is this on? >>>This is built for WinCE and Vxworks Thanks. Please could you also send the exact patch that you applied that resolved the issue? Matt _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From bhat.jayalakshmi at gmail.com Fri Dec 4 18:21:48 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Fri, 4 Dec 2015 23:51:48 +0530 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <56619669.2020403@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> Message-ID: Hi Matt, I replaced constant_time_eq_8 usage in s3_cbc.c with the implementation available in OpenSSL 1.0.1e. Things worked fine. Regards Jaya On Fri, Dec 4, 2015 at 7:04 PM, Matt Caswell wrote: > > > On 04/12/15 11:31, Jayalakshmi bhat wrote: > > Hi Matt, > > > > Thanks a lot for the response. > > > > Is your application a client or a server? Are both ends using > > OpenSSL 1.0.2d? If not, what is the other end using? > >>>Our device has both TLS client,server apps. As client, device > communicates with radius server, LDAP server etc.As > > server device is accessed using various web browsers. > > Hence both the end will not be OpenSSL 1.0.2d. > > > > How exactly are you doing that? Which specific cipher are you seeing > fail? > >>> We have provided user option to select TLS protocol versions similar > to the browsers. Depending upon the user configurations we set the protocol > flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL > context using SSL_CTX_clear_options/SSL_CTX_set_options. > >>> We have provided user option to chose ciphers as well. > > All these are in the application space,no changes have been done and > > they have been working good with OpenSSL 1.0.1c. Only the library is > > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers > > and with both the ciphers issue is seen. > > > > Are you able to provide a packet capture? > >>> Please find the attached traces for server mode. > > What O/S is this on? > >>>This is built for WinCE and Vxworks > > Thanks. Please could you also send the exact patch that you applied that > resolved the issue? > > Matt > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Fri Dec 4 18:37:49 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Sat, 5 Dec 2015 00:07:49 +0530 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <56619669.2020403@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> Message-ID: Hi Matt, s3_cbc.c uses the function constant_time_eq_8. I pulled only this function definition from OpenSSL 1.0.1e into OpenSSL 1.0.2d. I renamed this function as constant_time_eq_8_local and used it in s3_cbc.c instead of constant_time_eq_8. This renaming was just to avoid multiple definitions. OpenSSL 1.0.1e has the function constant_time_eq_8 defined as below: *#define DUPLICATE_MSB_TO_ALL(x) ( (unsigned)( (int)(x) >> (sizeof(int)*8-1) ) )#define DUPLICATE_MSB_TO_ALL_8(x) ((unsigned char)(DUPLICATE_MSB_TO_ALL(x)))* *static unsigned char constant_time_eq_8(unsigned a, unsigned b)* * {* * unsigned c = a ^ b;* * c--;* * return DUPLICATE_MSB_TO_ALL_8(c);* * }* OpenSSL 1.0.2d has the function constant_time_eq_8 defined as below. static inline unsigned int constant_time_msb(unsigned int a) { return 0 - (a >> (sizeof(a) * 8 - 1)); } static inline unsigned int constant_time_is_zero(unsigned int a) { return constant_time_msb(~a & (a - 1)); } static inline unsigned int constant_time_eq(unsigned int a, unsigned int b) { return constant_time_is_zero(a ^ b); } static inline unsigned char constant_time_eq_8(unsigned int a, unsigned int b) { return (unsigned char)(constant_time_eq(a, b)); } Regards Jaya On Fri, Dec 4, 2015 at 7:04 PM, Matt Caswell wrote: > > > On 04/12/15 11:31, Jayalakshmi bhat wrote: > > Hi Matt, > > > > Thanks a lot for the response. > > > > Is your application a client or a server? Are both ends using > > OpenSSL 1.0.2d? If not, what is the other end using? > >>>Our device has both TLS client,server apps. As client, device > communicates with radius server, LDAP server etc.As > > server device is accessed using various web browsers. > > Hence both the end will not be OpenSSL 1.0.2d. > > > > How exactly are you doing that? Which specific cipher are you seeing > fail? > >>> We have provided user option to select TLS protocol versions similar > to the browsers. Depending upon the user configurations we set the protocol > flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL > context using SSL_CTX_clear_options/SSL_CTX_set_options. > >>> We have provided user option to chose ciphers as well. > > All these are in the application space,no changes have been done and > > they have been working good with OpenSSL 1.0.1c. Only the library is > > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers > > and with both the ciphers issue is seen. > > > > Are you able to provide a packet capture? > >>> Please find the attached traces for server mode. > > What O/S is this on? > >>>This is built for WinCE and Vxworks > > Thanks. Please could you also send the exact patch that you applied that > resolved the issue? > > Matt > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Fri Dec 4 18:57:07 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Sat, 5 Dec 2015 00:27:07 +0530 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5661888F.7090201@wisemo.com> References: <56615D97.7050306@openssl.org> <5661888F.7090201@wisemo.com> Message-ID: Hi Jakob CPU is ARMARCH4. WinCE version is 6.0. I will get the compiler details shortly. Regards Jaya On Fri, Dec 4, 2015 at 6:05 PM, Jakob Bohm wrote: > For clarity, which version of WinCE, and which CPU (Arm, > MIPS, PPC, x86, SH3, SH4, ...)? > > Which Microsoft Compiler version (EVC3, EVC4, one of the > Visual Studio projects, 3rd party compiler) and which > exact compiler version (reported by running the compiler > executable (named according to CPU) with no arguments. > > I ask because your proposed fix may be affected by compiler and/or CPU > quirks. > > On 04/12/2015 12:31, Jayalakshmi bhat wrote: > > Hi Matt, > > Thanks a lot for the response. > > Is your application a client or a server? Are both ends using OpenSSL 1.0.2d? > If not, what is the other end using? > >>Our device has both TLS client,server apps. As client, device > communicates with radius server, LDAP server etc.As server device is > accessed using various web browsers. > Hence both the end will not be OpenSSL 1.0.2d. > > How exactly are you doing that? Which specific cipher are you seeing fail? > >> We have provided user option to select TLS protocol versions similar to > the browsers. Depending upon the user configurations we set the protocol > flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL > context using SSL_CTX_clear_options/SSL_CTX_set_options. > >> We have provided user option to chose ciphers as well. > All these are in the application space,no changes have been done and they > have been working good with OpenSSL 1.0.1c. Only the library is upgraded to > OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers and with > both the ciphers issue is seen. > > Are you able to provide a packet capture? > >> Please find the attached traces for server mode. > What O/S is this on? > >>This is built for WinCE and Vxworks > > Regards > Jaya > > > > On Fri, Dec 4, 2015 at 3:02 PM, Matt Caswell wrote: > >> Hello Jaya >> >> We're going to need some more information. There isn't a generic problem >> with CBC ciphers and TLS1.0 in 1.0.2d (it's working fine for me) - so >> there is something specific about your environment that is causing the >> issue. Comments inserted below. >> >> On 04/12/15 06:53, Jayalakshmi bhat wrote: >> > Hi All, >> > >> > >> > >> > Recently we have ported OpenSSL 1.0.2d. Everything works perfect except >> > the below explained issue. >> >> Is your application a client or a server? Are both ends using OpenSSL >> 1.0.2d? If not, what is the other end using? >> >> >> > When we enable only TLS 1.0 protocol and select CBC ciphers, >> >> How exactly are you doing that? Which specific cipher are you seeing fail? >> >> >> > Now my question is whatever I did is it correct? >> >> That would not be a recommended solution >> >> > Or Do need to replace >> > complete s3_cbc.c with OpenSSL 1.0.1e? >> >> No. You cannot just copy and paste stuff from 1.0.1 to 1.0.2. >> >> Some other questions: >> >> Are you able to provide a packet capture? >> How did you build OpenSSL...i.e. what "Configure" options did you use? >> What O/S is this on? >> >> 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 > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg_gryb at yahoo.com Fri Dec 4 19:50:49 2015 From: oleg_gryb at yahoo.com (Oleg Gryb) Date: Fri, 4 Dec 2015 19:50:49 +0000 (UTC) Subject: [openssl-users] Invalid ref coiunt for an openssl engine References: <906832467.15501411.1449258649967.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <906832467.15501411.1449258649967.JavaMail.yahoo@mail.yahoo.com> I'm trying to create a dynamic openssl engine, activate it from a client's code and then de-activate to do some important cleanup through the engine's "finish" function, when it's not needed anymore. I use ENGINE_finish(e) call from a client's side to do that, but that function will call engine's "finish" only if ref count to the engine's object is equal to 1. In my case the ref count is 3 and I don't understand why it's happening since the mentioned client was the only one who has used the engine. I've stripped out the client's and engine's code and put it here: http://stackoverflow.com/questions/34079310/why-ref-count-for-an-openssl-engine-is-so-high As a work around I use the code below on the client's side: while (e->funct_ref) { ENGINE_finish(e); } I got a feeling that this code could be unsafe and want to understand what the right way of fixing the problem is. Thanks,Oleg -------------- next part -------------- An HTML attachment was scrubbed... URL: From Walter.H at mathemainzel.info Sat Dec 5 18:55:50 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Sat, 05 Dec 2015 19:55:50 +0100 Subject: [openssl-users] CA design question? Message-ID: <56633336.1060801@mathemainzel.info> Hello, my website has an official SSL certificate, which I renewed this year to have a SHA-256 certificate; when I test my site with SSLLabs.com, I'm shows two certificate paths: the first one: my SSL cert (SHA-256) sent by server (SHA1 Fingerprint: 0fae9fd23852fb834fe4f32d7d3c73714daa6aa9) the intermediate (SHA-256) sent by server (SHA1 Fingerprint: 064969b7f4d6a74fd098be59d379fae429a906fb) the self-signed (SHA-256) in trust store (SHA1 Fingerprint: a3f1333fe242bfcfc5d14e8f394298406810d1a0) the second one: my SSL cert (SHA-256) sent by server (SHA1 Fingerprint: 0fae9fd23852fb834fe4f32d7d3c73714daa6aa9) the intermediate (SHA-256) sent by server (SHA1 Fingerprint: 064969b7f4d6a74fd098be59d379fae429a906fb) the self-signed (SHA-1) in trust store (SHA1 Fingerprint: 3e2bf7f2031b96f38ce6c4d8a85d3e2d58476a0f) before I renewed the SSL certificate, my server sent a intermediate with SHA-1, I just exchanged this intermediate certificate with a SHA-256 cert. exchange the intermediate cert to one with SHA-256, with this I had this situation: before exchange intermediate, path one: my SSL cert (SHA-1) sent by server (SHA1 Fingerprint: ...) the intermediate (SHA-1) sent by server (SHA1 Fingerprint: ...) the self-signed (SHA-256) in trust store (SHA1 Fingerprint: a3f1333fe242bfcfc5d14e8f394298406810d1a0) before exchange intermediate, path two: my SSL cert (SHA-1) sent by server (SHA1 Fingerprint: ...) the intermediate (SHA-1) sent by server (SHA1 Fingerprint: ...) the self-signed (SHA-1) in trust store (SHA1 Fingerprint: 3e2bf7f2031b96f38ce6c4d8a85d3e2d58476a0f) after exchange intermediate, path one: my SSL cert (SHA-1) sent by server (SHA1 Fingerprint: ...) the intermediate (SHA-256) sent by server (SHA1 Fingerprint: 064969b7f4d6a74fd098be59d379fae429a906fb) the self-signed (SHA-256) in trust store (SHA1 Fingerprint: a3f1333fe242bfcfc5d14e8f394298406810d1a0) after exchange intermediate, path two: my SSL cert (SHA-1) sent by server (SHA1 Fingerprint: ...) the intermediate (SHA-256) sent by server (SHA1 Fingerprint: 064969b7f4d6a74fd098be59d379fae429a906fb) the self-signed (SHA-1) in trust store (SHA1 Fingerprint: 3e2bf7f2031b96f38ce6c4d8a85d3e2d58476a0f) now my question how would it be possible to generate a SSL certificate that can be used with two different certificate paths? Thanks, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From openssl-users at dukhovni.org Sat Dec 5 19:20:00 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 5 Dec 2015 19:20:00 +0000 Subject: [openssl-users] CA design question? In-Reply-To: <56633336.1060801@mathemainzel.info> References: <56633336.1060801@mathemainzel.info> Message-ID: <20151205192000.GH18315@mournblade.imrryr.org> On Sat, Dec 05, 2015 at 07:55:50PM +0100, Walter H. wrote: > my website has an official SSL certificate, which I renewed this year to > have a SHA-256 certificate; > when I test my site with SSLLabs.com, I'm shows two certificate paths: > > the first one: > my SSL cert (SHA-256) sent by server > the intermediate (SHA-256) sent by server (SHA1 Fingerprint: > 064969b7f4d6a74fd098be59d379fae429a906fb) > the self-signed (SHA-256) in trust store (SHA1 Fingerprint: > a3f1333fe242bfcfc5d14e8f394298406810d1a0) All this obfuscation is rather pointless (and annoying), please just post the certificates. The last one above is: Certificate: Data: Version: 3 (0x2) Serial Number: 45 (0x2d) Signature Algorithm: sha256WithRSAEncryption Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority Validity Not Before: Sep 17 19:46:37 2006 GMT Not After : Sep 17 19:46:36 2036 GMT Subject: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Key Identifier: 4E:0B:EF:1A:A4:40:5B:A5:17:69:87:30:CA:34:68:43:D0:41:AE:F2 X509v3 Authority Key Identifier: keyid:4E:0B:EF:1A:A4:40:5B:A5:17:69:87:30:CA:34:68:43:D0:41:AE:F2 X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.23223.1.1.1 CPS: http://www.startssl.com/policy.pdf CPS: http://www.startssl.com/intermediate.pdf User Notice: Organization: Start Commercial (StartCom) Ltd. Number: 1 Explicit Text: Limited Liability, read the section *Legal Limitations* of the StartCom Certification Authority Policy available at http://www.startssl.com/policy.pdf Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA Netscape Comment: StartCom Free SSL Certification Authority Signature Algorithm: sha256WithRSAEncryption ... > the second one: > my SSL cert (SHA-256) sent by server > the intermediate (SHA-256) sent by server (SHA1 Fingerprint: > 064969b7f4d6a74fd098be59d379fae429a906fb) > the self-signed (SHA-1) in trust store (SHA1 Fingerprint: > 3e2bf7f2031b96f38ce6c4d8a85d3e2d58476a0f) Here the last one is: Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority Validity Not Before: Sep 17 19:46:36 2006 GMT Not After : Sep 17 19:46:36 2036 GMT Subject: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:TRUE X509v3 Key Usage: Digital Signature, Key Encipherment, Key Agreement, Certificate Sign, CRL Sign X509v3 Subject Key Identifier: 4E:0B:EF:1A:A4:40:5B:A5:17:69:87:30:CA:34:68:43:D0:41:AE:F2 X509v3 CRL Distribution Points: Full Name: URI:http://cert.startcom.org/sfsca-crl.crl Full Name: URI:http://crl.startcom.org/sfsca-crl.crl X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.23223.1.1.1 CPS: http://cert.startcom.org/policy.pdf CPS: http://cert.startcom.org/intermediate.pdf User Notice: Organization: Start Commercial (StartCom) Ltd. Number: 1 Explicit Text: Limited Liability, read the section *Legal Limitations* of the StartCom Certification Authority Policy available at http://cert.startcom.org/policy.pdf Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA Netscape Comment: StartCom Free SSL Certification Authority Signature Algorithm: sha1WithRSAEncryption ... Same subject, issuer and public key, different hash function in the self signature. Nothing up my sleeve. Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority Subject: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority X509v3 Subject Key Identifier: 4E:0B:EF:1A:A4:40:5B:A5:17:69:87:30:CA:34:68:43:D0:41:AE:F2 > now my question how would it be possible to generate a SSL certificate that > can be used with two different certificate paths? There are two versions of one of the issuer certificates. -- Viktor. From Walter.H at mathemainzel.info Sat Dec 5 21:37:43 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Sat, 05 Dec 2015 22:37:43 +0100 Subject: [openssl-users] CA design question? In-Reply-To: <20151205192000.GH18315@mournblade.imrryr.org> References: <56633336.1060801@mathemainzel.info> <20151205192000.GH18315@mournblade.imrryr.org> Message-ID: <56635927.4030909@mathemainzel.info> On 05.12.2015 20:20, Viktor Dukhovni wrote: > On Sat, Dec 05, 2015 at 07:55:50PM +0100, Walter H. wrote: > >> my website has an official SSL certificate, which I renewed this year to >> have a SHA-256 certificate; >> when I test my site with SSLLabs.com, I'm shows two certificate paths: >> >> the first one: >> my SSL cert (SHA-256) sent by server >> the intermediate (SHA-256) sent by server (SHA1 Fingerprint: >> 064969b7f4d6a74fd098be59d379fae429a906fb) >> the self-signed (SHA-256) in trust store (SHA1 Fingerprint: >> a3f1333fe242bfcfc5d14e8f394298406810d1a0) > All this obfuscation is rather pointless (and annoying), please > just post the certificates. take these examples https://www.ssllabs.com/ssltest/analyze.html?d=fibot.creditplus.de https://www.ssllabs.com/ssltest/analyze.html?d=sixxs.net they both have two certificate paths, especially the of sixxs.net would be interesting if someone can explain, one path has 3 certs and the other path 4 certs ... >> now my question how would it be possible to generate a SSL certificate that >> can be used with two different certificate paths? > There are two versions of one of the issuer certificates. the certificate that issued the SSL cert. is the same in both samples above; only the root CA cert is different, how would I generate such a situation? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From bhat.jayalakshmi at gmail.com Mon Dec 7 05:18:23 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Sun, 6 Dec 2015 22:18:23 -0700 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> Message-ID: Hi All, Is there inputs or suggestions. Thanks and Regards Jaya On Fri, Dec 4, 2015 at 11:37 AM, Jayalakshmi bhat < bhat.jayalakshmi at gmail.com> wrote: > Hi Matt, > > s3_cbc.c uses the function constant_time_eq_8. I pulled only this > function definition from OpenSSL 1.0.1e into OpenSSL 1.0.2d. I renamed > this function as constant_time_eq_8_local and used it in s3_cbc.c instead > of constant_time_eq_8. This renaming was just to avoid > multiple definitions. > > OpenSSL 1.0.1e has the function constant_time_eq_8 defined as below: > > *#define DUPLICATE_MSB_TO_ALL(x) ( (unsigned)( (int)(x) >> > (sizeof(int)*8-1) ) )#define DUPLICATE_MSB_TO_ALL_8(x) ((unsigned > char)(DUPLICATE_MSB_TO_ALL(x)))* > > *static unsigned char constant_time_eq_8(unsigned a, unsigned b)* > * {* > * unsigned c = a ^ b;* > * c--;* > * return DUPLICATE_MSB_TO_ALL_8(c);* > * }* > > OpenSSL 1.0.2d has the function constant_time_eq_8 defined as below. > > static inline unsigned int constant_time_msb(unsigned int a) > { > return 0 - (a >> (sizeof(a) * 8 - 1)); > } > > static inline unsigned int constant_time_is_zero(unsigned int a) > { > return constant_time_msb(~a & (a - 1)); > } > > static inline unsigned int constant_time_eq(unsigned int a, unsigned int b) > { > return constant_time_is_zero(a ^ b); > } > > static inline unsigned char constant_time_eq_8(unsigned int a, unsigned > int b) > { > return (unsigned char)(constant_time_eq(a, b)); > } > > > Regards > Jaya > > On Fri, Dec 4, 2015 at 7:04 PM, Matt Caswell wrote: > >> >> >> On 04/12/15 11:31, Jayalakshmi bhat wrote: >> > Hi Matt, >> > >> > Thanks a lot for the response. >> > >> > Is your application a client or a server? Are both ends using >> > OpenSSL 1.0.2d? If not, what is the other end using? >> >>>Our device has both TLS client,server apps. As client, device >> communicates with radius server, LDAP server etc.As >> > server device is accessed using various web browsers. >> > Hence both the end will not be OpenSSL 1.0.2d. >> > >> > How exactly are you doing that? Which specific cipher are you seeing >> fail? >> >>> We have provided user option to select TLS protocol versions similar >> to the browsers. Depending upon the user configurations we set the protocol >> flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL >> context using SSL_CTX_clear_options/SSL_CTX_set_options. >> >>> We have provided user option to chose ciphers as well. >> > All these are in the application space,no changes have been done and >> > they have been working good with OpenSSL 1.0.1c. Only the library is >> > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers >> > and with both the ciphers issue is seen. >> > >> > Are you able to provide a packet capture? >> >>> Please find the attached traces for server mode. >> > What O/S is this on? >> >>>This is built for WinCE and Vxworks >> >> Thanks. Please could you also send the exact patch that you applied that >> resolved the issue? >> >> Matt >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nounou.dadoun at avigilon.com Mon Dec 7 05:26:11 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Mon, 7 Dec 2015 05:26:11 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> , Message-ID: <8149AB08BCB1F54F92680ED6104891A0DFF81C@mbx027-w1-ca-4.exch027.domain.local> I have to do some testing tomorrow and I'll post my results and a packet capture .. N ________________________________ From: openssl-users [openssl-users-bounces at openssl.org] on behalf of Jayalakshmi bhat [bhat.jayalakshmi at gmail.com] Sent: December 6, 2015 9:18 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d Hi All, Is there inputs or suggestions. Thanks and Regards Jaya On Fri, Dec 4, 2015 at 11:37 AM, Jayalakshmi bhat > wrote: Hi Matt, s3_cbc.c uses the function constant_time_eq_8. I pulled only this function definition from OpenSSL 1.0.1e into OpenSSL 1.0.2d. I renamed this function as constant_time_eq_8_local and used it in s3_cbc.c instead of constant_time_eq_8. This renaming was just to avoid multiple definitions. OpenSSL 1.0.1e has the function constant_time_eq_8 defined as below: #define DUPLICATE_MSB_TO_ALL(x) ( (unsigned)( (int)(x) >> (sizeof(int)*8-1) ) ) #define DUPLICATE_MSB_TO_ALL_8(x) ((unsigned char)(DUPLICATE_MSB_TO_ALL(x))) static unsigned char constant_time_eq_8(unsigned a, unsigned b) { unsigned c = a ^ b; c--; return DUPLICATE_MSB_TO_ALL_8(c); } OpenSSL 1.0.2d has the function constant_time_eq_8 defined as below. static inline unsigned int constant_time_msb(unsigned int a) { return 0 - (a >> (sizeof(a) * 8 - 1)); } static inline unsigned int constant_time_is_zero(unsigned int a) { return constant_time_msb(~a & (a - 1)); } static inline unsigned int constant_time_eq(unsigned int a, unsigned int b) { return constant_time_is_zero(a ^ b); } static inline unsigned char constant_time_eq_8(unsigned int a, unsigned int b) { return (unsigned char)(constant_time_eq(a, b)); } Regards Jaya On Fri, Dec 4, 2015 at 7:04 PM, Matt Caswell > wrote: On 04/12/15 11:31, Jayalakshmi bhat wrote: > Hi Matt, > > Thanks a lot for the response. > > Is your application a client or a server? Are both ends using > OpenSSL 1.0.2d? If not, what is the other end using? >>>Our device has both TLS client,server apps. As client, device communicates with radius server, LDAP server etc.As > server device is accessed using various web browsers. > Hence both the end will not be OpenSSL 1.0.2d. > > How exactly are you doing that? Which specific cipher are you seeing fail? >>> We have provided user option to select TLS protocol versions similar to the browsers. Depending upon the user configurations we set the protocol flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL context using SSL_CTX_clear_options/SSL_CTX_set_options. >>> We have provided user option to chose ciphers as well. > All these are in the application space,no changes have been done and > they have been working good with OpenSSL 1.0.1c. Only the library is > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers > and with both the ciphers issue is seen. > > Are you able to provide a packet capture? >>> Please find the attached traces for server mode. > What O/S is this on? >>>This is built for WinCE and Vxworks Thanks. Please could you also send the exact patch that you applied that resolved the issue? Matt _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Mon Dec 7 05:43:48 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Sun, 6 Dec 2015 22:43:48 -0700 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5661888F.7090201@wisemo.com> References: <56615D97.7050306@openssl.org> <5661888F.7090201@wisemo.com> Message-ID: Hi Jakob, Here are more details, OS WinCE 6.0 CPU ARMARCH4. Family ARM Compiler ARM CC Version Microsoft (R) C/C++ Optimizing Compiler Version 14.01.60511 for ARM Regards Jaya On Fri, Dec 4, 2015 at 5:35 AM, Jakob Bohm wrote: > For clarity, which version of WinCE, and which CPU (Arm, > MIPS, PPC, x86, SH3, SH4, ...)? > > Which Microsoft Compiler version (EVC3, EVC4, one of the > Visual Studio projects, 3rd party compiler) and which > exact compiler version (reported by running the compiler > executable (named according to CPU) with no arguments. > > I ask because your proposed fix may be affected by compiler and/or CPU > quirks. > > On 04/12/2015 12:31, Jayalakshmi bhat wrote: > > Hi Matt, > > Thanks a lot for the response. > > Is your application a client or a server? Are both ends using OpenSSL 1.0.2d? > If not, what is the other end using? > >>Our device has both TLS client,server apps. As client, device > communicates with radius server, LDAP server etc.As server device is > accessed using various web browsers. > Hence both the end will not be OpenSSL 1.0.2d. > > How exactly are you doing that? Which specific cipher are you seeing fail? > >> We have provided user option to select TLS protocol versions similar to > the browsers. Depending upon the user configurations we set the protocol > flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL > context using SSL_CTX_clear_options/SSL_CTX_set_options. > >> We have provided user option to chose ciphers as well. > All these are in the application space,no changes have been done and they > have been working good with OpenSSL 1.0.1c. Only the library is upgraded to > OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers and with > both the ciphers issue is seen. > > Are you able to provide a packet capture? > >> Please find the attached traces for server mode. > What O/S is this on? > >>This is built for WinCE and Vxworks > > Regards > Jaya > > > > On Fri, Dec 4, 2015 at 3:02 PM, Matt Caswell wrote: > >> Hello Jaya >> >> We're going to need some more information. There isn't a generic problem >> with CBC ciphers and TLS1.0 in 1.0.2d (it's working fine for me) - so >> there is something specific about your environment that is causing the >> issue. Comments inserted below. >> >> On 04/12/15 06:53, Jayalakshmi bhat wrote: >> > Hi All, >> > >> > >> > >> > Recently we have ported OpenSSL 1.0.2d. Everything works perfect except >> > the below explained issue. >> >> Is your application a client or a server? Are both ends using OpenSSL >> 1.0.2d? If not, what is the other end using? >> >> >> > When we enable only TLS 1.0 protocol and select CBC ciphers, >> >> How exactly are you doing that? Which specific cipher are you seeing fail? >> >> >> > Now my question is whatever I did is it correct? >> >> That would not be a recommended solution >> >> > Or Do need to replace >> > complete s3_cbc.c with OpenSSL 1.0.1e? >> >> No. You cannot just copy and paste stuff from 1.0.1 to 1.0.2. >> >> Some other questions: >> >> Are you able to provide a packet capture? >> How did you build OpenSSL...i.e. what "Configure" options did you use? >> What O/S is this on? >> >> 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 > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronc at lanl.gov Mon Dec 7 19:22:19 2015 From: ronc at lanl.gov (Ron Croonenberg) Date: Mon, 7 Dec 2015 12:22:19 -0700 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <5660F620.3070409@wisemo.com> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <5660D1BA.8030404@lanl.gov> <5660F620.3070409@wisemo.com> Message-ID: <5665DC6B.7070808@lanl.gov> Yes I think that probably would be the case. on EDR HTTPS vs HTTP I loose about 15-20GB/s, almost half that is why am trying to do HTTPS for the authentication only On 12/03/2015 07:10 PM, Jakob Bohm wrote: > On 04/12/2015 03:03, Michael Wojcik wrote: >>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >>> Of Ron Croonenberg >>> Sent: Thursday, December 03, 2015 18:35 >>> To: openssl-users at openssl.org >>> Subject: Re: [openssl-users] explicitly including other ciphers. >>> >>> The network is isolated from the outside worl, BUT we still need >>> authentication because different users are using it. >>> >>> So what I preferably want is sort of a set up where, >>> authentication is done the "standard way" and after that just use the >>> https connection without the overhead of actually encrypting anything. >>> (and the lesss modifications and recompiling the better) >> So rather than connecting directly to Apache, how about connecting to >> a TLS proxy like stunnel, which would then connect to Apache over >> vanilla HTTP. Configure Apache to only bind to loopback addresses >> (127/8 and/or ::1), so no one can bypass the proxy. >> >> That's assuming stunnel doesn't also play silly buggers with the >> cipher suite list. >> > Wouldn't that extra hop via stunnel cost performance > (noting that Ron is apparently running at faster than > gigabit speed). > > Enjoy > > Jakob From ronc at lanl.gov Mon Dec 7 19:24:06 2015 From: ronc at lanl.gov (Ron Croonenberg) Date: Mon, 7 Dec 2015 12:24:06 -0700 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <5660D1BA.8030404@lanl.gov> Message-ID: <5665DCD6.8000904@lanl.gov> if the proxy is another host, I'd probably loose too much bandwith On 12/03/2015 07:03 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Ron Croonenberg >> Sent: Thursday, December 03, 2015 18:35 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] explicitly including other ciphers. >> >> The network is isolated from the outside worl, BUT we still need >> authentication because different users are using it. >> >> So what I preferably want is sort of a set up where, >> authentication is done the "standard way" and after that just use the >> https connection without the overhead of actually encrypting anything. >> (and the lesss modifications and recompiling the better) > > So rather than connecting directly to Apache, how about connecting to a TLS proxy like stunnel, which would then connect to Apache over vanilla HTTP. Configure Apache to only bind to loopback addresses (127/8 and/or ::1), so no one can bypass the proxy. > > That's assuming stunnel doesn't also play silly buggers with the cipher suite list. > From ronc at lanl.gov Mon Dec 7 19:27:32 2015 From: ronc at lanl.gov (Ron Croonenberg) Date: Mon, 7 Dec 2015 12:27:32 -0700 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <5660F650.80307@wisemo.com> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <5660D1BA.8030404@lanl.gov> <5660F650.80307@wisemo.com> Message-ID: <5665DDA4.5050606@lanl.gov> That is something we have been considering, but someone is going to bring up the fact that passwords would be in the clear. It would be an option to have some sort of encrypted authentication 'thing' over HTTP No it is strictly for having users, on front ends authenticate so they will only have access to their own data/objects On 12/03/2015 07:11 PM, Jakob Bohm wrote: > Since the network is (as I understand it) physically secure > against wiretapping, how about using plain http with http auth? > > Or are you trying to protect against TCP connection hijacks by > other computers/processes on the "secure" network? > > On 04/12/2015 00:35, Ron Croonenberg wrote: >> The network is isolated from the outside worl, BUT we still need >> authentication because different users are using it. >> >> So what I preferably want is sort of a set up where, >> >> authentication is done the "standard way" and after that just use the >> https connection without the overhead of actually encrypting anything. >> (and the lesss modifications and recompiling the better) >> >> thanks, >> >> Ron >> >> >> On 12/03/2015 02:50 PM, Richard Moore wrote: >>> >>> >>> On 2 December 2015 at 17:53, Ron Croonenberg >> > wrote: >>> >>> So the idea is to use an object store on an isolated network and >>> push and get objects out of it using https. >>> >>> >>> ???If network is fully isolated you could use plain text. Using 'https' >>> and null encryption is basically just pretending to do security. >>> > > > Enjoy > > Jakob From Michael.Wojcik at microfocus.com Mon Dec 7 19:33:45 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 7 Dec 2015 19:33:45 +0000 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: <5665DCD6.8000904@lanl.gov> References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <5660D1BA.8030404@lanl.gov> <5665DCD6.8000904@lanl.gov> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Ron Croonenberg > Sent: Monday, December 07, 2015 14:24 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] explicitly including other ciphers. > > if the proxy is another host, I'd probably loose too much bandwith As I described it, it wouldn't be on another host. From my previous message: "Configure Apache to only bind to loopback addresses (127/8 and/or ::1), so no one can bypass the proxy." If the proxy is connecting to Apache over the loopback interface, by definition it's running on the same system. There might still be an unacceptable performance hit, of course. It wouldn't be due to an additional physical network leg (because there wouldn't be any), but you'd have some processing overhead, an extra set of copies for every packet, and some time spent in the proxy connecting to Apache - though depending on the requirements of the application and the capabilities of the proxy, that might be amortized over long-running connections. Conversely, if your application can benefit from caching, you might gain some performance in actually serving content. It's impossible to guess without knowing more about the application and its behavior. (And you mean "lose", not "loose".) -- Michael Wojcik Technology Specialist, Micro Focus From ronc at lanl.gov Mon Dec 7 19:53:20 2015 From: ronc at lanl.gov (Ron Croonenberg) Date: Mon, 7 Dec 2015 12:53:20 -0700 Subject: [openssl-users] explicitly including other ciphers. In-Reply-To: References: <565E2061.30302@lanl.gov> <20151202014623.GR18315@mournblade.imrryr.org> <565F2B39.6090506@lanl.gov> <7900b5f4e24c42fb899c74f4f4810dc6@usma1ex-dag1mb1.msg.corp.akamai.com> <565F3017.60703@lanl.gov> <5660D1BA.8030404@lanl.gov> <5660F620.3070409@wisemo.com> Message-ID: <5665E3B0.9020307@lanl.gov> well... the performance loss would be high, I know that from other applications. Also, each server (there are 50) would need it's own 'proxy' that probably is a little impractical. We're moving a lot of data... machines that cache run out of memory to actually cache in no time. caching would only work with little bits of data. On 12/03/2015 10:32 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Jakob Bohm >> Sent: Thursday, December 03, 2015 21:11 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] explicitly including other ciphers. >> >> On 04/12/2015 03:03, Michael Wojcik wrote: >>> So rather than connecting directly to Apache, how about connecting to a >> TLS proxy like stunnel, which would then connect to Apache over vanilla >> HTTP. Configure Apache to only bind to loopback addresses (127/8 and/or >> ::1), so no one can bypass the proxy. >>> >> Wouldn't that extra hop via stunnel cost performance >> (noting that Ron is apparently running at faster than >> gigabit speed). > > Yes, but depending on the actual application behavior, it might be negligible compared to the cost of certificate validation and the like. I don't know enough about the situation to guess whether the impact would be an issue, so I thought I'd propose this as one possible alternative. > > The application might even be such that a caching proxy could be used in front of Apache for a performance gain - for example if the same content is re-read frequently and the HTTP cache control mechanisms allow it to be usefully cached. > From softeng979 at gmail.com Mon Dec 7 20:43:05 2015 From: softeng979 at gmail.com (Software Engineer 979) Date: Mon, 7 Dec 2015 14:43:05 -0600 Subject: [openssl-users] Question about TLS record length limitations Message-ID: Hello, I'm currently developing an data transfer application using OpenSSL. The application is required to securely transfer large amounts of data over a low latency/high bandwidth network. The data being transferred lives in a 3rd part application that uses 1 MB buffer to transfer data to my application. When I hook OpenSSL into my application I notice an appreciable decline in network throughput. I've traced the issue the default TLS record size of 16K. The smaller record size causes the 3rd party application's buffer to be segmented into 4 16K buffers per write and the resulting overhead considerably slows things down. I've since modified the version of OpenSSL that I'm using to support an arbitrary TLS record size allowing OpenSSL to scale up to 1MB or larger TLS record size. Since this change, my network throughput has dramatically increased (187% degradation down to 33%). I subsequently checked the TLS RFC to determine why a 16K record size was being used, and all could find was the following: length The length (in bytes) of the following TLSCompressed.fragment. The length MUST NOT exceed 2^14 + 1024. The language here is pretty explicit stating that the length must not exceed 16K (+ some change).Does anyone know the reason for this? Is there a cryptographic reason why we shouldn't exceed this message size? Based on my limited experiment, it would appear that a larger record size would benefit low latency/high bandwidth networks. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Dec 7 20:45:47 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 7 Dec 2015 20:45:47 +0000 Subject: [openssl-users] Question about TLS record length limitations In-Reply-To: References: Message-ID: <99c364bb310840d3a82b8580b565b760@usma1ex-dag1mb1.msg.corp.akamai.com> I suggest you ask on the TLS mailing list, tls at ietf.org /r$ -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Mon Dec 7 20:46:13 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 7 Dec 2015 14:46:13 -0600 Subject: [openssl-users] Question about TLS record length limitations In-Reply-To: References: Message-ID: <5665F015.8060608@akamai.com> On 12/07/2015 02:43 PM, Software Engineer 979 wrote: > Hello, > > I'm currently developing an data transfer application using OpenSSL. > The application is required to securely transfer large amounts of data > over a low latency/high bandwidth network. The data being transferred > lives in a 3rd part application that uses 1 MB buffer to transfer data > to my application. When I hook OpenSSL into my application I notice an > appreciable decline in network throughput. I've traced the issue the > default TLS record size of 16K. The smaller record size causes the 3rd > party application's buffer to be segmented into 4 16K buffers per > write and the resulting overhead considerably slows things down. I've > since modified the version of OpenSSL that I'm using to support an > arbitrary TLS record size allowing OpenSSL to scale up to 1MB or > larger TLS record size. Since this change, my network throughput has > dramatically increased (187% degradation down to 33%). > > I subsequently checked the TLS RFC to determine why a 16K record size > was being used, and all could find was the following: > > length > The length (in bytes) of the following TLSCompressed.fragment. > The length MUST NOT exceed 2^14 + 1024. > > The language here is pretty explicit stating that the length must not > exceed 16K (+ some change).Does anyone know the reason for this? Is > there a cryptographic reason why we shouldn't exceed this message > size? Based on my limited experiment, it would appear that a larger > record size would benefit low latency/high bandwidth networks. > The peer is required to buffer the entire record before processing it, at at that point the data could be from an untrusted party/attacker. So the limit is for protection against denial-of-service via resource exhaustion. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From nounou.dadoun at avigilon.com Mon Dec 7 22:46:26 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Mon, 7 Dec 2015 22:46:26 +0000 Subject: [openssl-users] Failed TLSv1.2 handshake Message-ID: <8149AB08BCB1F54F92680ED6104891A0DFF96A@mbx027-w1-ca-4.exch027.domain.local> Hi folks, running into a failed handshake problem - Although we upgraded to openssl 1.0.2d last summer, we had never changed our context setup from accepting any version other than TLSv1, i.e. (in boost) m_context(pIoService->GetNative(), boost::asio::ssl::context::tlsv1) When we recently changed to accepting other versions (didn't matter if we disabled sslv2 and sslv3) to (in boost): m_context(pIoService->GetNative(), boost::asio::ssl::context::sslv23) our ssl handshakes started failing with "decryption failed or bad record mac" I've attached a packet capture, the client does a TLSv1.2 CLIENT HELLO and offers up 72 cipher suites. The server responds with the SERVER HELLO, CERTIFICATE, SERVER HELLO DONE and appears to select Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) The Client does the CLIENT KEY EXCHANGE, CHANGE CIPHER SPEC, ENCRYPTED HANDSHAKE MESSAGE and then the exchange appears to finish with the above error in the server log. The cipher setting on the server is: SSL_CTX_set_cipher_list(pSslContext->GetNativeRef().impl(), "ALL:SEED:!EXPORT:!LOW:!DES:!RC4"); Any suggestions? Is it possible that we've selected a cipher setting which is not compiled in? Thanks in advance for any help ... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. -------------- next part -------------- A non-text attachment was scrubbed... Name: failed_tls1.2_handshake.pcapng Type: application/octet-stream Size: 28676 bytes Desc: failed_tls1.2_handshake.pcapng URL: From openssl-users at dukhovni.org Tue Dec 8 01:49:24 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 8 Dec 2015 01:49:24 +0000 Subject: [openssl-users] Failed TLSv1.2 handshake In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0DFF96A@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0DFF96A@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <20151208014924.GD12639@mournblade.imrryr.org> On Mon, Dec 07, 2015 at 10:46:26PM +0000, Nounou Dadoun wrote: > The cipher setting on the server is: > SSL_CTX_set_cipher_list(pSslContext->GetNativeRef().impl(), "ALL:SEED:!EXPORT:!LOW:!DES:!RC4"); Note, your cipher setting is likely not what you intend it to be, instead try: "DEFAULT:!EXPORT:!LOW:!RC4:+SEED" Unless you know what you're doing in enabling anonymous ciphers. Also note the difference between ":SEED" and ":+SEED". You're also using a version 1 server certificate with a public exponent of "3". This is a really bad idea. You've not defined any DH or ECDH parameters, so the cipher selected uses RSA key transport, not a good idea, but should work barring bugs on either side. > Any suggestions? Is it possible that we've selected a cipher setting which is not compiled in? No, that gives you plenty of ciphers (more than you need). Perhaps the client is buggy. Have you tried OpenSSL 1.0.2e? What software is the client running? In any case, there are enough red flags all over the place that make it likely that other mistakes are being made. -- Viktor. From imjebran at gmail.com Tue Dec 8 06:18:24 2015 From: imjebran at gmail.com (Mohammad Jebran) Date: Tue, 8 Dec 2015 11:18:24 +0500 Subject: [openssl-users] sign sub CA issue Message-ID: I have to sign a sub-CA through my current root CA using openSSLeverything I have configured as per instructions but still getting an error that "stateorProvanceName field needed to be the same" As mentioned below. *root at machine:~/ImportantCACerts/intermediate# openssl ca -configopenssl.cnf -extensions v3_intermediate_ca -days 3650 -notext -md sha256 -in csr/subca2.csr -out certs/subca2.crt* *Using configuration from openssl.cnf* *Check that the request matches the signature* *Signature ok* *The stateOrProvinceName field needed to be the same in the* *CA certificate (HK) and the request (HK)* *Thanks & Regards,Jebran.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Dec 8 10:57:24 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 8 Dec 2015 10:57:24 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> Message-ID: <5666B794.2080304@openssl.org> On 07/12/15 05:18, Jayalakshmi bhat wrote: > Hi All, > > Is there inputs or suggestions. Have you run the tests on this platform? i.e. "make test" I'm particular interested to know if the constant_time_test passed. Matt > > Thanks and Regards > Jaya > > On Fri, Dec 4, 2015 at 11:37 AM, Jayalakshmi bhat > > wrote: > > Hi Matt, > > s3_cbc.c uses the function constant_time_eq_8. I pulled only this > function definition from OpenSSL 1.0.1e into OpenSSL 1.0.2d. I > renamed this function as constant_time_eq_8_local and used it in > s3_cbc.c instead of constant_time_eq_8. This renaming was just to > avoid multiple definitions. > > OpenSSL 1.0.1e has the function constant_time_eq_8 defined as below: > * > * > * > #define DUPLICATE_MSB_TO_ALL(x) ( (unsigned)( (int)(x) >> > (sizeof(int)*8-1) ) ) > #define DUPLICATE_MSB_TO_ALL_8(x) ((unsigned > char)(DUPLICATE_MSB_TO_ALL(x))) > * > * > * > *static unsigned char constant_time_eq_8(unsigned a, unsigned b)* > *{* > *unsigned c = a ^ b;* > *c--;* > *return DUPLICATE_MSB_TO_ALL_8(c);* > *}* > > OpenSSL 1.0.2d has the function constant_time_eq_8 defined as below. > > static inline unsigned int constant_time_msb(unsigned int a) > { > return 0 - (a >> (sizeof(a) * 8 - 1)); > } > > static inline unsigned int constant_time_is_zero(unsigned int a) > { > return constant_time_msb(~a & (a - 1)); > } > > static inline unsigned int constant_time_eq(unsigned int a, unsigned > int b) > { > return constant_time_is_zero(a ^ b); > } > > static inline unsigned char constant_time_eq_8(unsigned int a, > unsigned int b) > { > return (unsigned char)(constant_time_eq(a, b)); > } > > > Regards > Jaya > > On Fri, Dec 4, 2015 at 7:04 PM, Matt Caswell > wrote: > > > > On 04/12/15 11:31, Jayalakshmi bhat wrote: > > Hi Matt, > > > > Thanks a lot for the response. > > > > Is your application a client or a server? Are both ends using > > OpenSSL 1.0.2d? If not, what is the other end using? > >>>Our device has both TLS client,server apps. As client, device communicates with radius server, LDAP server etc.As > > server device is accessed using various web browsers. > > Hence both the end will not be OpenSSL 1.0.2d. > > > > How exactly are you doing that? Which specific cipher are you seeing fail? > >>> We have provided user option to select TLS protocol versions similar to the browsers. Depending upon the user configurations we set the protocol flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL context using SSL_CTX_clear_options/SSL_CTX_set_options. > >>> We have provided user option to chose ciphers as well. > > All these are in the application space,no changes have been done and > > they have been working good with OpenSSL 1.0.1c. Only the library is > > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers > > and with both the ciphers issue is seen. > > > > Are you able to provide a packet capture? > >>> Please find the attached traces for server mode. > > What O/S is this on? > >>>This is built for WinCE and Vxworks > > Thanks. Please could you also send the exact patch that you > applied that > resolved the issue? > > 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 softeng979 at gmail.com Tue Dec 8 13:37:42 2015 From: softeng979 at gmail.com (Software Engineer 979) Date: Tue, 8 Dec 2015 07:37:42 -0600 Subject: [openssl-users] Question about TLS record length limitations In-Reply-To: <5665F015.8060608@akamai.com> References: <5665F015.8060608@akamai.com> Message-ID: Ben, I'm pretty new to TLS, so please bear with me. I was thinking through what you said and I had a few questions. Couldn't you pull off the same DOS attack using the existing 16K message size today. The scale of the DOS attack would have to be larger as the packet size is smaller, but the vector of attack still exists today correct? On Mon, Dec 7, 2015 at 2:46 PM, Benjamin Kaduk wrote: > On 12/07/2015 02:43 PM, Software Engineer 979 wrote: > > Hello, > > I'm currently developing an data transfer application using OpenSSL. The > application is required to securely transfer large amounts of data over a > low latency/high bandwidth network. The data being transferred lives in a > 3rd part application that uses 1 MB buffer to transfer data to my > application. When I hook OpenSSL into my application I notice an > appreciable decline in network throughput. I've traced the issue the > default TLS record size of 16K. The smaller record size causes the 3rd > party application's buffer to be segmented into 4 16K buffers per write and > the resulting overhead considerably slows things down. I've since modified > the version of OpenSSL that I'm using to support an arbitrary TLS record > size allowing OpenSSL to scale up to 1MB or larger TLS record size. Since > this change, my network throughput has dramatically increased (187% > degradation down to 33%). > > I subsequently checked the TLS RFC to determine why a 16K record size was > being used, and all could find was the following: > > length > The length (in bytes) of the following TLSCompressed.fragment. > > The length MUST NOT exceed 2^14 + 1024. > > The language here is pretty explicit stating that the length must not > exceed 16K (+ some change).Does anyone know the reason for this? Is there a > cryptographic reason why we shouldn't exceed this message size? Based on my > limited experiment, it would appear that a larger record size would benefit > low latency/high bandwidth networks. > > > The peer is required to buffer the entire record before processing it, at > at that point the data could be from an untrusted party/attacker. So the > limit is for protection against denial-of-service via resource exhaustion. > > -Ben > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Dec 8 17:16:25 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 8 Dec 2015 18:16:25 +0100 Subject: [openssl-users] OPENSSL_VERSION_NUMBER and TLSv1_1 & TLSv1_2 supports In-Reply-To: <566564F9.3070004@orange.fr> References: <55FC3656.9080506@orange.fr> <55FC4B33.8030902@wisemo.com> <566564F9.3070004@orange.fr> Message-ID: <56671069.3040202@wisemo.com> On 07/12/2015 11:52, zosrothko wrote: > Hi Jacob > > Le 18/09/2015 19:34, Jakob Bohm a ?crit : >> On 18/09/2015 18:05, zosrothko wrote: >>> Hi >>> >>> is there a way to know the supported TLS protocols from the >>> OPENSSL_VERSION_NUMBER (specifically, the TLSv1_1 and TLSv1_2? >>> >>> For exemple, I have a code that is using TLSv1_1_client_method & >>> TLSv1_1_server_method for a OPENSSL_VERSION_NUMBER = 0x1000201fL, but >>> I need to protect those TLSv1_1 and TLSv1_2 entry points references >>> when my code is ported toward a previous version of OpenSSL that does >>> not support those TLS versions as the 1.0.0k version . >>> >>> Since there is no OPEN_SSL_NO_TLSv1_1 constant nor >>> OPEN_SSL_NO_TLSv1_2 constant in the ssl.h(1.0.0k), I would like to >>> use the OPENSSL_VERSION_NUMBER to protect the references. >>> >> The numeric value of OPENSSL_VERSION_NUMBER maps directly >> to the textual version number ("1.0.0k"), a look in the >> official changelogs for each branch (0.9.8, 1.0.0, 1.0.1, >> 1.0.2, 1.1.0 etc.) to see at which comparison limits any given >> feature was installed. >> >> Or, since you are using the version number of the header >> files, not the version of the runtime shared library, you >> can simply use ifdef tests for relevant defines existing, >> e.g. >> >> #if defined(SSL_OP_NO_TLSv1_1) && !defined(OPENSSL_NO_TLS1) >> /* SSL_OP_NO_TLSv1_1 is defined in ssl.h if the library version >> * supports TLSv1.1 . >> * >> * OPENSSL_NO_TLS1 is defined in opensslconf.h or on the >> * compiler command line if TLS1.x was removed at OpenSSL >> * library build time via Configure options. >> */ >> /* Code that requires headers from a TLSv1.1 capable OpenSSL >> * goes here. >> */ >> #endif > I saw that in ssl.h, the 'NO' particule means no support of as for example > /* Don't use RFC4507 ticket extension */ > # define SSL_OP_NO_TICKET 0x00004000L > > What does mean the 'NO' in SSL_OP_NO_TLSv1_1? Should not be the test > reversed as below? > The define is for a flag that can be passed to some other SSL functions to turn off the TLSv1_1 support during a single execution, hence the "NO" in its name. Because those flags are only defined in OpenSSL versions that include the thing to turn off (at least if not disabled when compiling OpenSSL itself), I suggested using the very existence of the flag definition as a way to determine if the thing is included in the OpenSSL version where the copy of "ssl.h" was taken from. > #if !defined(SSL_OP_NO_TLSv1_1) && !defined(OPENSSL_NO_TLS1) 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 jb-openssl at wisemo.com Tue Dec 8 17:27:00 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 8 Dec 2015 18:27:00 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5666B794.2080304@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> Message-ID: <566712E4.4010503@wisemo.com> On 08/12/2015 11:57, Matt Caswell wrote: > On 07/12/15 05:18, Jayalakshmi bhat wrote: >> Hi All, >> >> Is there inputs or suggestions. > Have you run the tests on this platform? i.e. "make test" > > I'm particular interested to know if the constant_time_test passed. He can't. WinCE is not a self-hosting platform, everything is done by cross-compiling on a PC. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nounou.dadoun at avigilon.com Tue Dec 8 19:44:19 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Tue, 8 Dec 2015 19:44:19 +0000 Subject: [openssl-users] Failed TLSv1.2 handshake In-Reply-To: <20151208014924.GD12639@mournblade.imrryr.org> References: <8149AB08BCB1F54F92680ED6104891A0DFF96A@mbx027-w1-ca-4.exch027.domain.local> <20151208014924.GD12639@mournblade.imrryr.org> Message-ID: <8149AB08BCB1F54F92680ED6104891A0DFFAD4@mbx027-w1-ca-4.exch027.domain.local> Hi Viktor, thanks very much for taking a look, my plan now is to experiment disabling ciphers until I figure out which one is causing some kind of mismatch in TLS_RSA_WITH_AES_256_GCM_SHA384 Unlikely to be the RSA so I'll poke at disabling the aes-gcm and sha384 respectively. BTW, the client uses OpenSSL 1.0.1h, in boost it's configured with: SslContextPtr_t pSslContext = std::make_shared(pIoService, boost::asio::ssl::context::sslv23); With no other options. Client-side configure header is: VERSION=1.0.1h MAJOR=1 MINOR=0.1 SHLIB_VERSION_NUMBER=1.0.0 SHLIB_VERSION_HISTORY= SHLIB_MAJOR=1 SHLIB_MINOR=0.0 SHLIB_EXT= PLATFORM=VC-WIN64A OPTIONS=enable-rsa enable-md5 enable-sha enable-sha1 enable-dsa enable-des enable-rc4 enable-dh no-bf no-camellia no-cast no-ec_nistp_64_gcc_128 no-gmp no-idea no-jpake no-krb5 no-md2 no-md4 no-mdc2 no-rc2 no-rc5 no-rfc3779 no-ripemd no-sctp no-shared no-store no-zlib no-zlib-dynamic CONFIGURE_ARGS=no-idea no-rc5 enable-rsa no-md2 no-md4 enable-md5 enable-sha enable-sha1 enable-dsa no-ripemd enable-des enable-rc4 no-rc2 no-bf no-camellia no-cast no-mdc2 enable-dh VC-WIN64A SHLIB_TARGET= And as I mentioned earlier, the server uses OpenSSL 1.0.2d which makes for an unusual interop problem! Thanks again ... N Nou Dadoun Senior Firmware Developer, Security Specialist -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Monday, December 07, 2015 5:49 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Failed TLSv1.2 handshake On Mon, Dec 07, 2015 at 10:46:26PM +0000, Nounou Dadoun wrote: > The cipher setting on the server is: > SSL_CTX_set_cipher_list(pSslContext->GetNativeRef().impl(), > "ALL:SEED:!EXPORT:!LOW:!DES:!RC4"); Note, your cipher setting is likely not what you intend it to be, instead try: "DEFAULT:!EXPORT:!LOW:!RC4:+SEED" Unless you know what you're doing in enabling anonymous ciphers. Also note the difference between ":SEED" and ":+SEED". You're also using a version 1 server certificate with a public exponent of "3". This is a really bad idea. You've not defined any DH or ECDH parameters, so the cipher selected uses RSA key transport, not a good idea, but should work barring bugs on either side. > Any suggestions? Is it possible that we've selected a cipher setting which is not compiled in? No, that gives you plenty of ciphers (more than you need). Perhaps the client is buggy. Have you tried OpenSSL 1.0.2e? What software is the client running? In any case, there are enough red flags all over the place that make it likely that other mistakes are being made. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From nounou.dadoun at avigilon.com Tue Dec 8 21:22:09 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Tue, 8 Dec 2015 21:22:09 +0000 Subject: [openssl-users] Failed TLSv1.2 handshake In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0DFFAD4@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0DFF96A@mbx027-w1-ca-4.exch027.domain.local> <20151208014924.GD12639@mournblade.imrryr.org> <8149AB08BCB1F54F92680ED6104891A0DFFAD4@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <8149AB08BCB1F54F92680ED6104891A0DFFB03@mbx027-w1-ca-4.exch027.domain.local> I had an offline exchange with someone who pointed out the Bignum bug in 1.0.2? (https://www.openssl.org/news/vulnerabilities.html#2015-3193) How does this bug manifest itself? In my context, some RSA-based connections (those with tslv1) seem to work. Could this be related? Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun Sent: Tuesday, December 08, 2015 11:44 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Failed TLSv1.2 handshake Hi Viktor, thanks very much for taking a look, my plan now is to experiment disabling ciphers until I figure out which one is causing some kind of mismatch in TLS_RSA_WITH_AES_256_GCM_SHA384 Unlikely to be the RSA so I'll poke at disabling the aes-gcm and sha384 respectively. BTW, the client uses OpenSSL 1.0.1h, in boost it's configured with: SslContextPtr_t pSslContext = std::make_shared(pIoService, boost::asio::ssl::context::sslv23); With no other options. Client-side configure header is: VERSION=1.0.1h MAJOR=1 MINOR=0.1 SHLIB_VERSION_NUMBER=1.0.0 SHLIB_VERSION_HISTORY= SHLIB_MAJOR=1 SHLIB_MINOR=0.0 SHLIB_EXT= PLATFORM=VC-WIN64A OPTIONS=enable-rsa enable-md5 enable-sha enable-sha1 enable-dsa enable-des enable-rc4 enable-dh no-bf no-camellia no-cast no-ec_nistp_64_gcc_128 no-gmp no-idea no-jpake no-krb5 no-md2 no-md4 no-mdc2 no-rc2 no-rc5 no-rfc3779 no-ripemd no-sctp no-shared no-store no-zlib no-zlib-dynamic CONFIGURE_ARGS=no-idea no-rc5 enable-rsa no-md2 no-md4 enable-md5 enable-sha enable-sha1 enable-dsa no-ripemd enable-des enable-rc4 no-rc2 no-bf no-camellia no-cast no-mdc2 enable-dh VC-WIN64A SHLIB_TARGET= And as I mentioned earlier, the server uses OpenSSL 1.0.2d which makes for an unusual interop problem! Thanks again ... N Nou Dadoun Senior Firmware Developer, Security Specialist -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Monday, December 07, 2015 5:49 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Failed TLSv1.2 handshake On Mon, Dec 07, 2015 at 10:46:26PM +0000, Nounou Dadoun wrote: > The cipher setting on the server is: > SSL_CTX_set_cipher_list(pSslContext->GetNativeRef().impl(), > "ALL:SEED:!EXPORT:!LOW:!DES:!RC4"); Note, your cipher setting is likely not what you intend it to be, instead try: "DEFAULT:!EXPORT:!LOW:!RC4:+SEED" Unless you know what you're doing in enabling anonymous ciphers. Also note the difference between ":SEED" and ":+SEED". You're also using a version 1 server certificate with a public exponent of "3". This is a really bad idea. You've not defined any DH or ECDH parameters, so the cipher selected uses RSA key transport, not a good idea, but should work barring bugs on either side. > Any suggestions? Is it possible that we've selected a cipher setting which is not compiled in? No, that gives you plenty of ciphers (more than you need). Perhaps the client is buggy. Have you tried OpenSSL 1.0.2e? What software is the client running? In any case, there are enough red flags all over the place that make it likely that other mistakes are being made. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Tue Dec 8 23:26:05 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 8 Dec 2015 23:26:05 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <566712E4.4010503@wisemo.com> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> Message-ID: <5667670D.2040402@openssl.org> On 08/12/15 17:27, Jakob Bohm wrote: > On 08/12/2015 11:57, Matt Caswell wrote: >> On 07/12/15 05:18, Jayalakshmi bhat wrote: >>> Hi All, >>> >>> Is there inputs or suggestions. >> Have you run the tests on this platform? i.e. "make test" >> >> I'm particular interested to know if the constant_time_test passed. > He can't. WinCE is not a self-hosting platform, > everything is done by cross-compiling on a PC. Can we copy the text exe across? Matt From xxiao8 at fosiao.com Wed Dec 9 04:25:42 2015 From: xxiao8 at fosiao.com (xxiao8) Date: Tue, 8 Dec 2015 22:25:42 -0600 Subject: [openssl-users] force to use /dev/random for openssl fips module In-Reply-To: References: Message-ID: <5667AD46.6050208@fosiao.com> I don't know how critical is the DEVRANDOM for openssl-fips, in e_os.h I saw this: ---- #define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom" ---- we have a hardware RNG that is feeding /dev/random via: ---- /sbin/rngd -r /dev/hwrng -W 4000 ---- so the /dev/random will never block, I thus change e_os.h to force usage of /dev/random(per our fips code reviewer's request, who thinks I need change that for fips): ---- #define DEVRANDOM "/dev/random" ---- this looks fine, however I don't know if it's really the right thing to do, after this change my system starts to have issues(silent reboot), changing this line back everything runs normally. any help is appreciated. xxiao From xxiao8 at fosiao.com Wed Dec 9 05:06:38 2015 From: xxiao8 at fosiao.com (xxiao8) Date: Tue, 8 Dec 2015 23:06:38 -0600 Subject: [openssl-users] openssl fipsalgtest In-Reply-To: References: Message-ID: <5667B6DE.3090808@fosiao.com> I'm trying to run the algorithm tests under linux for fips 2.0.10 + openssl 1.0.1e, using the fips-2.0-tv.tar.gz from openssl website, and saw quite some errors, anything am I missing? Thanks, xxiao ---- perl fipsalgtest.pl --dir=/tmp/tv ---- WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/DRBG800-90/req/Dual_EC_DRBG.req WARNING: bogus file /tmp/tv/OSF_2464_OE4/DRBG800-90/resp/Dual_EC_DRBG.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TOFBMonte1.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TOFBMMT1.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TCBCMonte1.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TCFB8Monte1.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TECBMMT1.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TCBCMMT1.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TCFB8MMT1.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TCFB64MMT1.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TCFB1Monte1.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TECBMonte1.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TCFB1MMT1.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/TDES/resp/TCFB64Monte1.rsp WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TOFBMMT1.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TCFB64MMT1.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TECBMonte1.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TCFB64Monte1.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TCFB1Monte1.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TCFB8MMT1.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TOFBMonte1.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TECBMMT1.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TCBCMMT1.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TCFB1MMT1.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TCFB8Monte1.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/TDES/req/TCBCMonte1.req WARNING: bogus file /tmp/tv/OSF_2464_OE4/DSA/resp/PQGGen.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/DSA/resp/SigGen.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/DSA/resp/KeyPair.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/DSA/resp/SigVer.rsp WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/DSA/req/KeyPair.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/DSA/req/SigVer.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/DSA/req/PQGGen.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/DSA/req/SigGen.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/ECDSA/req/SigVer.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/ECDSA/req/PKV.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/ECDSA/req/SigGen.req WARNING: unrecognized filename /tmp/tv/OSF_2464_OE4/ECDSA/req/KeyPair.req WARNING: bogus file /tmp/tv/OSF_2464_OE4/ECDSA/resp/SigGen.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/ECDSA/resp/PKV.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/ECDSA/resp/SigVer.rsp WARNING: bogus file /tmp/tv/OSF_2464_OE4/ECDSA/resp/KeyPair.rsp ERROR: 42 bogus or duplicate request and response files From mofassir_haque at yahoo.com Wed Dec 9 06:05:24 2015 From: mofassir_haque at yahoo.com (Mofassir Ul Haque) Date: Wed, 9 Dec 2015 06:05:24 +0000 (UTC) Subject: [openssl-users] Result for "SigGen15_186-3.req" Test vector (RSA Signature Generation) References: <913303332.17676069.1449641124935.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <913303332.17676069.1449641124935.JavaMail.yahoo@mail.yahoo.com> I am using OpenSSL version "1.0.2d-fips 9 Jul 2015". I am running OpenSSL test vectors (2015) using "fips_algvs fips_rsastest" for "SigGen931_186-3.req" , "SigGen15_186-3.req" and "SigGenPSS_186-3.req" to check conformance with FIPS PUB 186-4. After running test on request file, I am getting same response file for "SigGen15_186-3.req" (as provided by OpenSSL) and different reponse files for "SigGen931_186-3.req" and "SigGenPSS_186-3.req". However, all response files pass verification test if I run "fips_algvs fips_rsavtest" test.? Shouldn't all files be getting different response files because of use of RNG ? Are these results valid ? (I am getting different response files for NIST vectors) Any help will be greatly appreciated ! Thanks, Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter.verhelst at fedict.be Wed Dec 9 09:05:18 2015 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Wed, 9 Dec 2015 10:05:18 +0100 Subject: [openssl-users] OCSP signature verification In-Reply-To: <314AD38167954C4BBE91263CA425506D577EFDB231@MAIL2K7CL.yourict.net> References: <314AD38167954C4BBE91263CA425506D577EFDB231@MAIL2K7CL.yourict.net> Message-ID: <5667EECE.30205@fedict.be> On 01-12-15 14:58, Verhelst Wouter (Consultant) wrote: > Hi folks, > > I'm trying to write an application that needs to verify the validity of data on a smartcard. That data is signed with an RSA key for which a certificate exists on the card; but if the card is stolen or lost, the certificate will be revoked, so I want to ensure that the certificate is valid. I'm doing an OCSP request to take care of that. > > Since OpenSSL's own OCSP_sendreq_* functions don't support HTTP proxies, I'm currently using libcurl to send the request to the OCSP endpoint. This seems to work; when I get the reply and use d2i_OCSP_RESPONSE(), then with things like OCSP_response_status() and OCSP_resp_find_status() and friends I can manage to get the status of the request and a given certificate. > > However, that doesn't do signature verification. I believe that I should use OCSP_basic_verify() for that, but I'm not entirely sure whether that is the case, and if so whether I would need to do some additional checks beforehand. Unfortunately, I can't find any documentation on OCSP_basic_verify(). > > I should note that due to the nature of my needs, I have a rather huge set of valid intermediate CAs, but a fairly limited set of root CAs that can be used for valid cards (that is, if the signature validates but it wasn't signed by any of the CAs under one of my limited set of roots, the card is a forgery and should be rejected as invalid). > > A few questions: > - Am I right in assuming that OCSP_basic_verify will check the signature on the OCSP request? > - In "OCSP_basic_verify(OCSP_BASICRESP *bs, STACK_OF(X509) *certs, X509_STORE *st, unsigned long flags)", I'm not entirely certain of what the "st" argument is meant to contain, and can't figure out the "certs" one. Pouring over the code, I believe the "st" argument should allow me to limit validation to my set of root certificates, but I could be mistaken. As for the "certs" one, I can't understand that one at all. The only thing I can think of is that maybe it should contain the issuer certificate that I used for the original request, but then why is it a STACK_OF(X509)* and not just an X509*? What am I missing? > > Thanks for any help, Ping. Anyone? If this is documented somewhere, feel free to point me to the documentation... -- Wouter Verhelst From emilia at openssl.org Wed Dec 9 11:15:45 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Wed, 9 Dec 2015 12:15:45 +0100 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <56582015.7010109@cryptsoft.com> References: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <201511210210.tAL2AvJi030500@d23av02.au.ibm.com> <56535644.3010002@wisemo.com> <56582015.7010109@cryptsoft.com> Message-ID: To close off this thread: OpenSSL will not be making any changes. The team voted on moving a set of algorithms to maintenance mode, and removing the corresponding assembly implementations from libcrypto, but the vote did not pass. Emilia On Fri, Nov 27, 2015 at 10:19 AM, Tim Hudson wrote: > On 24/11/2015 4:09 AM, Jakob Bohm wrote: > > But they care very much if Cisco AnyConnect (or any other > > OpenSSL using program they may need) stops working or > > becomes insecure because the OpenSSL team is breaking > > stuff just because it is not needed in their own handful > > of example uses. > > The OpenSSL team (like most open source projects) is made up of > individuals that have widely varying backgrounds and experiences - and > those experiences lead to different view points on a lot of fairly > fundamental topics. This is a good thing - as frankly a project that > doesn't have a mix of view points tends to not last. > > Between the OpenSSL team members our experiences cover a very wide range > of uses and many of us have been working on the code base for 17+ years > and have worked in areas that are certainly well outside the average or > common uses. However despite that experience we certainly don't think > that we know what all the users of the code base are doing. > > Increasingly we are making sure any debate on project direction where > there are mixed view points within the team brings in the openssl-users > and/or openssl-dev lists so we get to have input from a wider set of > people - who may or may not represent uses that we don't already know > about. > > All the view points being expressed are valid and there are good reasons > why we could as a team head in either direction (dropping out code or > keeping everything or anything along that spectrum) and what is > important is to listen to the input and see the varying points of view > and add that into the decision making process. > > So if you have a use of OpenSSL that you think the team might not know > about then please express that clearly on the list. View points on what > has been proposed are also welcome - but I think you'll find increasing > the awareness of the team about what our users are doing is the more > important of the two objectives in seeking feedback. > > Tim. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Wed Dec 9 11:44:15 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Wed, 9 Dec 2015 04:44:15 -0700 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5667670D.2040402@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> Message-ID: Hi Matt, I could build and execute the constant_time_test. I have attached the .c file and test results. 34 tests have failed. All failures are around constant_time_eq_8. This is the function I had mentioned in the earlier mails. Regards Jaya On Tue, Dec 8, 2015 at 4:26 PM, Matt Caswell wrote: > > > On 08/12/15 17:27, Jakob Bohm wrote: > > On 08/12/2015 11:57, Matt Caswell wrote: > >> On 07/12/15 05:18, Jayalakshmi bhat wrote: > >>> Hi All, > >>> > >>> Is there inputs or suggestions. > >> Have you run the tests on this platform? i.e. "make test" > >> > >> I'm particular interested to know if the constant_time_test passed. > > He can't. WinCE is not a self-hosting platform, > > everything is done by cross-compiling on a PC. > > Can we copy the text exe across? > > 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: test_result.zip Type: application/zip Size: 13739 bytes Desc: not available URL: From jb-openssl at wisemo.com Wed Dec 9 12:59:11 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 9 Dec 2015 13:59:11 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> Message-ID: <5668259F.9020406@wisemo.com> Could you extract the disassembly of one of the failed calls to constant_time_eq_8() in the test program, perhaps the compiler generates incorrect code for this deeply nested group of near-edge arithmetic operations? On 09/12/2015 12:44, Jayalakshmi bhat wrote: > Hi Matt, > > I could build and execute the constant_time_test. I have attached the > .c file and test results. 34 tests have failed. All failures are > around constant_time_eq_8. This is the function I had mentioned in the > earlier mails. > > On Tue, Dec 8, 2015 at 4:26 PM, Matt Caswell > wrote: > > > > On 08/12/15 17:27, Jakob Bohm wrote: > > On 08/12/2015 11:57, Matt Caswell wrote: > >> On 07/12/15 05:18, Jayalakshmi bhat wrote: > >>> Hi All, > >>> > >>> Is there inputs or suggestions. > >> Have you run the tests on this platform? i.e. "make test" > >> > >> I'm particular interested to know if the constant_time_test passed. > > He can't. WinCE is not a self-hosting platform, > > everything is done by cross-compiling on a PC. > > Can we copy the text exe across? > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From marquess at openssl.com Wed Dec 9 13:03:40 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 9 Dec 2015 08:03:40 -0500 Subject: [openssl-users] openssl fipsalgtest In-Reply-To: <5667B6DE.3090808@fosiao.com> References: <5667B6DE.3090808@fosiao.com> Message-ID: <566826AC.2010008@openssl.com> On 12/09/2015 12:06 AM, xxiao8 wrote: > I'm trying to run the algorithm tests under linux for fips 2.0.10 + > openssl 1.0.1e, using the fips-2.0-tv.tar.gz from openssl website, and > saw quite some errors, anything am I missing? fipsalgtest.pl is a utility of value only for performing formal CAVP algorithm testing. Unfortunately the CAVP is constantly changing the format of the algorithm test files ("test vectors"), so by the time you try to use fipsalgtest.pl on a newly obtained set of test vectors for your validation attempt it probably won't exactly match. You'll need to dig in and figure out the discrepancies. Also note it's not at all unusual to receive incorrect test vectors (the CAVS tool that generates them is very labor intensive and it's all too easy for the test lab to miss a checkbox or whatever). Figuring out whether a discrepancy is due to a legitimate format change or outright error, and then convincing the test lab and CAVP of the latter, can be fun. We developed this tool because we were doing platform tests by the hundreds. For a one-off validation you may want to consider just hand-jamming the "--generate-script" file. I'll also note that sorting out the algorithm tests will be relatively trivial compared to hacking the OpenSSL FIPS Object Module v2.0 code to meet all the new requirements that have accumulated since that validation was obtained. You'll want to do those mods before the algorithm testing. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From ant.rao at gmail.com Wed Dec 2 08:49:26 2015 From: ant.rao at gmail.com (Anty Rao) Date: Wed, 2 Dec 2015 16:49:26 +0800 Subject: [openssl-users] Response from server is lost on close Message-ID: Hi : ALL Using non-blocking openssl , after detecting underlying TCP is broken, i invoke SSL_read to attempting reading response. *sometimes* response from server is lost, sometimes not. But tcpdump show that response is always send back to me. what is special is that RST packages come next the response. Can someone shed some light on me, Thanks.Here is the result of tcpdump: > 22:29:52.284797 IP 17.143.162.202.2195 > xx.xx.xx.xx.49038: Flags [FP.], seq 4801:4838, ack 4158, win 340, option > s [nop,nop,TS val 1184022887 ecr 2339879379], length 37 > 0x0000: 4500 0059 dcdb 4000 2e06 021a 118f a2ca E..Y.. at ......... > 0x0010: b73c 0214 0893 bf8e 93b8 7466 2b1b 88c2 .<........tf+... > 0x0020: 8019 0154 faed 0000 0101 080a 4692 c167 ...T........F..g > 0x0030: 8b77 b9d3 1503 0100 2006 f287 45d4 311e .w..........E.1. > 0x0040: e3fe 5cfc 9904 b7a6 2e7e 1221 9967 fdd3 ..\......~.!.g.. > 0x0050: 5314 a007 f48d 7490 d6 S.....t..22:29:52.284802 IP xx.xx.xx.xx.49038 > 17.143.162.202.2195: Flags [.], ack 4764, win 15, options [nop,nop,TS val2339879429 ecr 1184022886,nop,nop,sack 1 {4801:4839}], length 0 > 0x0000: 4500 0040 c041 4000 4006 0ccd b73c 0214 E.. at .A@. at ....<.. > 0x0010: 118f a2ca bf8e 0893 2b1b cca2 93b8 7441 ........+.....tA > 0x0020: b010 000f ad39 0000 0101 080a 8b77 ba05 .....9.......w.. > 0x0030: 4692 c166 0101 050a 93b8 7466 93b8 748c F..f......tf..t.22:29:52.483487 IP 17.143.162.202.2195 > xx.xx.xx.xx.49038: Flags [R], seq 2478339137, win 0, length 0 > 0x0000: 4500 0028 0000 4000 2e06 df26 118f a2ca E..(.. at ....&.... > 0x0010: b73c 0214 0893 bf8e 93b8 7441 0000 0000 .<........tA.... > 0x0020: 5004 0000 721b 0000 0000 0000 0000 P...r.........------------------------------------------------------------------------------------ > another : > 16:18:00.168274 IP 17.143.161.207.2195 > xx.xxx.xx.xx.43361: Flags [P.], seq 4764:4801, ack 37462, win 432, option > s [nop,nop,TS val 1248125705 ecr 2355901348], length 37 > 0x0000: 4500 0059 c936 4000 3006 14ba 118f a1cf E..Y.6 at .0....... > 0x0010: b73c 0214 0893 a961 1e10 133f 2197 3724 .<.....a...?!.7$ > 0x0020: 8018 01b0 245e 0000 0101 080a 4a64 e309 ....$^......Jd.. > 0x0030: 8c6c 33a4 1503 0100 2012 a99f e30c 37aa .l3...........7. > 0x0040: eda1 e24a 1819 74cb 1a73 2396 f76e b9fa ...J..t..s#..n.. > 0x0050: 293b 8625 8a9d 09a7 30 );.%....016:18:00.168326 IP 17.143.161.207.2195 > xx.xxx.xx.xx.43361: Flags [R.], seq 4801, ack 37462, win 498, options [no > p,nop,TS val 1248125705 ecr 2355901348], length 0 > 0x0000: 4500 0034 c937 4000 3006 14de 118f a1cf E..4.7 at .0....... > 0x0010: b73c 0214 0893 a961 1e10 1364 2197 3724 .<.....a...d!.7$ > 0x0020: 8014 01f2 de75 0000 0101 080a 4a64 e309 .....u......Jd.. > 0x0030: 8c6c 33a4 .l3. > > -- Anty Rao -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Dec 9 14:19:31 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 9 Dec 2015 14:19:31 +0000 Subject: [openssl-users] Response from server is lost on close In-Reply-To: References: <565F5FBB.2040706@wisemo.com> Message-ID: (Sorry for the delay in replying - I was tied up with other things.) Yes, you're correct. I was misremembering, and should have checked references first. The BSD implementation that Gary Wright and Rich Stevens describe in TCP/IP Illustrated v. 2 drops queued outbound data (on both sides) and queued out-of-order segments waiting for reassembly on the receiving side when an RST is received. But it doesn't appear to drop queued in-order, ACK'd data. And I think that's the correct behavior. If the side that receives the RST has ACK'd some data, then it should hang onto that data for the application to receive it. It should only report the error (ECONNRESET) when the application has successfully read the queued data. So I suspect what you're seeing is OpenSSL behavior. It's likely reading ahead, seeing the ECONNRESET, and discarding the received data. But I haven't had a chance to look at the OpenSSL code in question. In some cases OpenSSL will have to read ahead. It needs to receive the complete SSL/TLS/DTLS record before processing it, for example; and if that record is broken up into multiple TCP segments (because the path MTU is smaller than the record size) then it could have a partial record when it receives the RST. I can't tell if that situation is present in your case (without manually decoding the tcpdump trace, which I don't have time to do at the moment). Michael Wojcik Technology Specialist, Micro Focus -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Dec 9 23:04:35 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 9 Dec 2015 23:04:35 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> Message-ID: <5668B383.1060100@openssl.org> On 09/12/15 11:44, Jayalakshmi bhat wrote: > Hi Matt, > > I could build and execute the constant_time_test. I have attached the .c > file and test results. 34 tests have failed. All failures are > around constant_time_eq_8. This is the function I had mentioned in the > earlier mails. Not quite all. There is also a failure right at the beginning of your log in constant_time_is_zero_8. Although it looks very similar to the constant_time_eq_8 failure. As to the failure it is very strange. This is the function doing the test: int test_binary_op_8(unsigned char (*op) (unsigned int a, unsigned int b), const char *op_name, unsigned int a, unsigned int b, int is_true) { unsigned char c = op(a, b); if (is_true && c != CONSTTIME_TRUE_8) { printf( "Test failed for %s(%du, %du): expected %u " "(TRUE), got %u at line %d\n", op_name, a, b, CONSTTIME_TRUE_8, c,__LINE__); return 1; } else if (!is_true && c != CONSTTIME_FALSE_8) { printf( "Test failed for %s(%du, %du): expected %u " "(FALSE), got %u at line %d\n", op_name, a, b, CONSTTIME_FALSE_8, c,__LINE__); return 1; } printf( "Test passed for %s(%du, %du): expected %u got %u at line %d with %s\n", op_name, a, b, CONSTTIME_TRUE_8, c,__LINE__,is_true?"TRUE":"FALSE"); return 0; } and the output we see in the log file is: Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got 4294967295 at line 85 That big number in the output is actually 0x7FFFFFFF in hex. The variable that it is printing here is "c" which is declared as an "unsigned char". Please someone correct me if I'm wrong but doesn't the C spec guarantee that a "char" is 8 bits? In which case how can the value of "c" be greater than 255????? Am I missing something? BTW can we modify the code above to print the value of sizeof(c)? Matt From bkaduk at akamai.com Wed Dec 9 23:13:32 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 9 Dec 2015 17:13:32 -0600 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5668B383.1060100@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> Message-ID: <5668B59C.60106@akamai.com> On 12/09/2015 05:04 PM, Matt Caswell wrote: > > On 09/12/15 11:44, Jayalakshmi bhat wrote: >> Hi Matt, >> >> I could build and execute the constant_time_test. I have attached the .c >> file and test results. 34 tests have failed. All failures are >> around constant_time_eq_8. This is the function I had mentioned in the >> earlier mails. > Not quite all. There is also a failure right at the beginning of your > log in constant_time_is_zero_8. Although it looks very similar to the > constant_time_eq_8 failure. > > As to the failure it is very strange. This is the function doing the test: > > int test_binary_op_8(unsigned > char (*op) (unsigned int a, unsigned int b), > const char *op_name, unsigned int a, > unsigned int b, int is_true) > { > unsigned char c = op(a, b); > if (is_true && c != CONSTTIME_TRUE_8) { > printf( "Test failed for %s(%du, %du): expected %u " > "(TRUE), got %u at line %d\n", op_name, a, b, > CONSTTIME_TRUE_8, c,__LINE__); > return 1; > } else if (!is_true && c != CONSTTIME_FALSE_8) { > printf( "Test failed for %s(%du, %du): expected %u " > "(FALSE), got %u at line %d\n", op_name, a, b, > CONSTTIME_FALSE_8, c,__LINE__); > return 1; > } > printf( "Test passed for %s(%du, %du): expected %u got %u at line %d > with %s\n", op_name, a, b, CONSTTIME_TRUE_8, > c,__LINE__,is_true?"TRUE":"FALSE"); > return 0; > } > > > and the output we see in the log file is: > > Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got > 4294967295 at line 85 > > That big number in the output is actually 0x7FFFFFFF in hex. The > variable that it is printing here is "c" which is declared as an > "unsigned char". > > Please someone correct me if I'm wrong but doesn't the C spec guarantee > that a "char" is 8 bits? In which case how can the value of "c" be > greater than 255????? C does not make such a guarantee, though recent-ish POSIX does. (This system is a windows one, thought, right?) In any case, due to C's type promotion rules, it's very difficult to actually use types narrower than 'int', since integers get auto-promoted to int at integer conversion time. This has extra-fun interactions with varargs functions, depending on the platform ABI in use. (Always cast NULL to a pointer type when passing to a varargs function; this does cause real bugs.) Since c is unsigned, it is odd to see it get promoted to (int)-1, since C type conversions are supposed to be value-preserving, but it is certainly possible that the windows ABI is doing something I don't expect. Adjusting things so that the format specifier and the type passed to printf match (whether by casting c to int or qualifying the format specifier) might help. -Ben > Am I missing something? > > BTW can we modify the code above to print the value of sizeof(c)? > > Matt > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From ant.rao at gmail.com Thu Dec 10 01:49:38 2015 From: ant.rao at gmail.com (Anty Rao) Date: Thu, 10 Dec 2015 09:49:38 +0800 Subject: [openssl-users] Response from server is lost on close In-Reply-To: References: <565F5FBB.2040706@wisemo.com> Message-ID: Hi Michael, Thanks for your reply, and appreciate your answer which clear many of my doubts. Currently i'm stuck with this problem, can't find a way out,let me give more context of my problem. I use non-blocking openssl to interact with Apple's APNS server to send notifications to Iphone devices. According to protocol of APNS server, most of the time, there is no response from server; nevertheless ,if bad things happens, server will send a reply and close the underlying connection.The reply, which is very short, should be fit in one TCP segment.This can be confirmed by result of tcpdump, which i post at the beginning in this thread. So I always write to server until write operation fails, then i try to read the reply. There is one observation when doing test, if i throttle write speed to some extent, response can be successfully fetched. However, if i speed up write speed, response will be lost most likely. Hopely you can look at this when you have time ,Thanks. Thanks. Anty. On Wed, Dec 9, 2015 at 10:19 PM, Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > (Sorry for the delay in replying - I was tied up with other things.) > > > > Yes, you're correct. I was misremembering, and should have checked > references first. > > > > The BSD implementation that Gary Wright and Rich Stevens describe in *TCP/IP > Illustrated* v. 2 drops queued outbound data (on both sides) and queued > out-of-order segments waiting for reassembly on the receiving side when an > RST is received. But it doesn't appear to drop queued in-order, ACK'd data. > > > > And I think that's the correct behavior. If the side that receives the RST > has ACK'd some data, then it should hang onto that data for the application > to receive it. It should only report the error (ECONNRESET) when the > application has successfully read the queued data. > > > > So I suspect what you're seeing is OpenSSL behavior. It's likely reading > ahead, seeing the ECONNRESET, and discarding the received data. But I > haven't had a chance to look at the OpenSSL code in question. > > > > In some cases OpenSSL will have to read ahead. It needs to receive the > complete SSL/TLS/DTLS record before processing it, for example; and if that > record is broken up into multiple TCP segments (because the path MTU is > smaller than the record size) then it could have a partial record when it > receives the RST. I can't tell if that situation is present in your case > (without manually decoding the tcpdump trace, which I don't have time to do > at the moment). > > > > Michael Wojcik > Technology Specialist, Micro Focus > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- Anty Rao -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Dec 10 04:47:18 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 10 Dec 2015 04:47:18 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5668B383.1060100@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> Message-ID: <20151210044718.GE11836@mournblade.imrryr.org> On Wed, Dec 09, 2015 at 11:04:35PM +0000, Matt Caswell wrote: > unsigned char c = op(a, b); > if (is_true && c != CONSTTIME_TRUE_8) { > printf( "Test failed for %s(%du, %du): expected %u " > "(TRUE), got %u at line %d\n", op_name, a, b, > CONSTTIME_TRUE_8, c,__LINE__); It is best to not leave "c" to the vagaries of stdarg argument handling. Rather, it would better to explicitly convert it to an unsigned long, and print that. > Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got > 4294967295 at line 85 > That big number in the output is actually 0x7FFFFFFF in hex. Actually it is 0xffffffff, that is a 32-bit "-1". > Please someone correct me if I'm wrong but doesn't the C spec guarantee > that a "char" is 8 bits? In which case how can the value of "c" be > greater than 255????? Well, it isn't greater, but the integral promotion for printf seems to forget that c is unsigned. > BTW can we modify the code above to print the value of sizeof(c)? That is 1 by definition. What we don't know on sufficiently odd systems is whether a char is 8 bits or not. The unit for sizeof is chars not bytes. So there's no point printing that. You might be interested in the CHAR_BIT macro from instead, but I don't think that's relevant at this time. -- Viktor. From zosrothko at orange.fr Thu Dec 10 09:30:49 2015 From: zosrothko at orange.fr (zosrothko) Date: Thu, 10 Dec 2015 10:30:49 +0100 Subject: [openssl-users] OPENSSL_VERSION_NUMBER and TLSv1_1 & TLSv1_2 supports In-Reply-To: <56671069.3040202@wisemo.com> References: <55FC3656.9080506@orange.fr> <55FC4B33.8030902@wisemo.com> <566564F9.3070004@orange.fr> <56671069.3040202@wisemo.com> Message-ID: <56694649.1030100@orange.fr> Le 08/12/2015 18:16, Jakob Bohm a ?crit : > On 07/12/2015 11:52, zosrothko wrote: >> Hi Jacob >> I saw that in ssl.h, the 'NO' particule means no support of as for >> example >> /* Don't use RFC4507 ticket extension */ >> # define SSL_OP_NO_TICKET 0x00004000L >> >> What does mean the 'NO' in SSL_OP_NO_TLSv1_1? Should not be the test >> reversed as below? >> > > The define is for a flag that can be passed to some other SSL functions > to turn off the TLSv1_1 support during a single execution, hence the > "NO" in its name. > > Because those flags are only defined in OpenSSL versions that include > the thing to turn off (at least if not disabled when compiling OpenSSL > itself), I suggested using the very existence of the flag definition > as a way to determine if the thing is included in the OpenSSL version > where the copy of "ssl.h" was taken from. Thanks for your explanation which makes your proposal clearer for any newcomer of OpenSSL > From matt at openssl.org Thu Dec 10 09:41:07 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 10 Dec 2015 09:41:07 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <20151210044718.GE11836@mournblade.imrryr.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <20151210044718.GE11836@mournblade.imrryr.org> Message-ID: <566948B3.8000800@openssl.org> On 10/12/15 04:47, Viktor Dukhovni wrote: > On Wed, Dec 09, 2015 at 11:04:35PM +0000, Matt Caswell wrote: > >> unsigned char c = op(a, b); >> if (is_true && c != CONSTTIME_TRUE_8) { >> printf( "Test failed for %s(%du, %du): expected %u " >> "(TRUE), got %u at line %d\n", op_name, a, b, >> CONSTTIME_TRUE_8, c,__LINE__); > > It is best to not leave "c" to the vagaries of stdarg argument > handling. Rather, it would better to explicitly convert it to an > unsigned long, and print that. > >> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got >> 4294967295 at line 85 > >> That big number in the output is actually 0x7FFFFFFF in hex. > > Actually it is 0xffffffff, that is a 32-bit "-1". Doh! Thanks. Looks like a bug in the online converter I was using: http://www.binaryhexconverter.com/decimal-to-hex-converter Matt From matt at openssl.org Thu Dec 10 09:48:08 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 10 Dec 2015 09:48:08 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5668B59C.60106@akamai.com> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> Message-ID: <56694A58.4060006@openssl.org> On 09/12/15 23:13, Benjamin Kaduk wrote: > On 12/09/2015 05:04 PM, Matt Caswell wrote: >> >> On 09/12/15 11:44, Jayalakshmi bhat wrote: >>> Hi Matt, >>> >>> I could build and execute the constant_time_test. I have attached the .c >>> file and test results. 34 tests have failed. All failures are >>> around constant_time_eq_8. This is the function I had mentioned in the >>> earlier mails. >> Not quite all. There is also a failure right at the beginning of your >> log in constant_time_is_zero_8. Although it looks very similar to the >> constant_time_eq_8 failure. >> >> As to the failure it is very strange. This is the function doing the test: >> >> int test_binary_op_8(unsigned >> char (*op) (unsigned int a, unsigned int b), >> const char *op_name, unsigned int a, >> unsigned int b, int is_true) >> { >> unsigned char c = op(a, b); >> if (is_true && c != CONSTTIME_TRUE_8) { >> printf( "Test failed for %s(%du, %du): expected %u " >> "(TRUE), got %u at line %d\n", op_name, a, b, >> CONSTTIME_TRUE_8, c,__LINE__); >> return 1; >> } else if (!is_true && c != CONSTTIME_FALSE_8) { >> printf( "Test failed for %s(%du, %du): expected %u " >> "(FALSE), got %u at line %d\n", op_name, a, b, >> CONSTTIME_FALSE_8, c,__LINE__); >> return 1; >> } >> printf( "Test passed for %s(%du, %du): expected %u got %u at line %d >> with %s\n", op_name, a, b, CONSTTIME_TRUE_8, >> c,__LINE__,is_true?"TRUE":"FALSE"); >> return 0; >> } >> >> >> and the output we see in the log file is: >> >> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got >> 4294967295 at line 85 >> >> That big number in the output is actually 0x7FFFFFFF in hex. The >> variable that it is printing here is "c" which is declared as an >> "unsigned char". >> >> Please someone correct me if I'm wrong but doesn't the C spec guarantee >> that a "char" is 8 bits? In which case how can the value of "c" be >> greater than 255????? > > C does not make such a guarantee, though recent-ish POSIX does. (This > system is a windows one, thought, right?) > > In any case, due to C's type promotion rules, it's very difficult to > actually use types narrower than 'int', since integers get auto-promoted > to int at integer conversion time. This has extra-fun interactions with > varargs functions, depending on the platform ABI in use. (Always cast > NULL to a pointer type when passing to a varargs function; this does > cause real bugs.) Since c is unsigned, it is odd to see it get promoted > to (int)-1, since C type conversions are supposed to be > value-preserving, but it is certainly possible that the windows ABI is > doing something I don't expect. Adjusting things so that the format > specifier and the type passed to printf match (whether by casting c to > int or qualifying the format specifier) might help. Thanks Ben. It's not 100% clear to me that we are dealing with a system where a char has more than 8 bits, but it certainly seems like a plausible explanation for what is going on. Especially when you look at the implementation of constant_time_eq_8: static inline unsigned char constant_time_eq_8(unsigned int a, unsigned int b) { return (unsigned char)(constant_time_eq(a, b)); } The function "constant_time_eq" here returns an "unsigned int". The whole purpose of "constant_time_eq_8" is to provide a convenience function to create an 8 bit mask. If the number of bits in an unsigned char > 8 then this code is going to fail! Jaya - please could you try the attached patch to see if that resolves the problem. Please try re-executing both your SSL/TLS tests and the constant_time test. Let me know how you get on. Thanks Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: char-not-8-bits.patch Type: text/x-patch Size: 2842 bytes Desc: not available URL: From bhat.jayalakshmi at gmail.com Thu Dec 10 11:55:29 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Thu, 10 Dec 2015 04:55:29 -0700 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <56694A58.4060006@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> Message-ID: Hi Matt, Thanks for the patch. Unfortunately patch did not work. I continued debugging and found that issue was in constant_time_msb. static inline unsigned int constant_time_msb(unsigned int a) { - *return 0 - (a >> (sizeof(a) * 8 - 1));* + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); } Changed constant_time_msb implementation as shown above. All the tests passed. I have attached the dis-assembly of the code for both successful case and failure case. This was requested by Jakob. Regards Jaya On Thu, Dec 10, 2015 at 2:48 AM, Matt Caswell wrote: > > > On 09/12/15 23:13, Benjamin Kaduk wrote: > > On 12/09/2015 05:04 PM, Matt Caswell wrote: > >> > >> On 09/12/15 11:44, Jayalakshmi bhat wrote: > >>> Hi Matt, > >>> > >>> I could build and execute the constant_time_test. I have attached the > .c > >>> file and test results. 34 tests have failed. All failures are > >>> around constant_time_eq_8. This is the function I had mentioned in the > >>> earlier mails. > >> Not quite all. There is also a failure right at the beginning of your > >> log in constant_time_is_zero_8. Although it looks very similar to the > >> constant_time_eq_8 failure. > >> > >> As to the failure it is very strange. This is the function doing the > test: > >> > >> int test_binary_op_8(unsigned > >> char (*op) (unsigned int a, unsigned int b), > >> const char *op_name, unsigned int a, > >> unsigned int b, int is_true) > >> { > >> unsigned char c = op(a, b); > >> if (is_true && c != CONSTTIME_TRUE_8) { > >> printf( "Test failed for %s(%du, %du): expected %u " > >> "(TRUE), got %u at line %d\n", op_name, a, b, > >> CONSTTIME_TRUE_8, c,__LINE__); > >> return 1; > >> } else if (!is_true && c != CONSTTIME_FALSE_8) { > >> printf( "Test failed for %s(%du, %du): expected %u " > >> "(FALSE), got %u at line %d\n", op_name, a, b, > >> CONSTTIME_FALSE_8, c,__LINE__); > >> return 1; > >> } > >> printf( "Test passed for %s(%du, %du): expected %u got %u at line > %d > >> with %s\n", op_name, a, b, CONSTTIME_TRUE_8, > >> c,__LINE__,is_true?"TRUE":"FALSE"); > >> return 0; > >> } > >> > >> > >> and the output we see in the log file is: > >> > >> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got > >> 4294967295 at line 85 > >> > >> That big number in the output is actually 0x7FFFFFFF in hex. The > >> variable that it is printing here is "c" which is declared as an > >> "unsigned char". > >> > >> Please someone correct me if I'm wrong but doesn't the C spec guarantee > >> that a "char" is 8 bits? In which case how can the value of "c" be > >> greater than 255????? > > > > C does not make such a guarantee, though recent-ish POSIX does. (This > > system is a windows one, thought, right?) > > > > In any case, due to C's type promotion rules, it's very difficult to > > actually use types narrower than 'int', since integers get auto-promoted > > to int at integer conversion time. This has extra-fun interactions with > > varargs functions, depending on the platform ABI in use. (Always cast > > NULL to a pointer type when passing to a varargs function; this does > > cause real bugs.) Since c is unsigned, it is odd to see it get promoted > > to (int)-1, since C type conversions are supposed to be > > value-preserving, but it is certainly possible that the windows ABI is > > doing something I don't expect. Adjusting things so that the format > > specifier and the type passed to printf match (whether by casting c to > > int or qualifying the format specifier) might help. > > Thanks Ben. > > It's not 100% clear to me that we are dealing with a system where a char > has more than 8 bits, but it certainly seems like a plausible > explanation for what is going on. Especially when you look at the > implementation of constant_time_eq_8: > > static inline unsigned char constant_time_eq_8(unsigned int a, unsigned > int b) > { > return (unsigned char)(constant_time_eq(a, b)); > } > > The function "constant_time_eq" here returns an "unsigned int". The > whole purpose of "constant_time_eq_8" is to provide a convenience > function to create an 8 bit mask. If the number of bits in an unsigned > char > 8 then this code is going to fail! > > Jaya - please could you try the attached patch to see if that resolves > the problem. Please try re-executing both your SSL/TLS tests and the > constant_time test. Let me know how you get on. > > Thanks > > 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: changes.7z Type: application/octet-stream Size: 4540 bytes Desc: not available URL: From openssl at openssl.org Thu Dec 10 15:01:50 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 10 Dec 2015 15:01:50 +0000 Subject: [openssl-users] OpenSSL version 1.1.0 pre release 1 published Message-ID: <20151210150150.GA30915@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0 pre release 1 (alpha) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 1 has now been made available. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.1.0-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The alpha release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0-pre1.tar.gz Size: 4990889 SHA1 checksum: a058b999e17e0c40988bd7b9b280c9876f62684e SHA256 checksum: 79da49c38464a19d1b328c2f4a3661849bd2eb3d54a37fdb6a56d9b8a18e87bd The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0-pre1.tar.gz openssl sha256 openssl-1.1.0-pre1.tar.gz Please download and check this alpha release as soon as possible. Bug reports should go to rt at openssl.org. Please check the release notes and mailing lists to avoid duplicate reports of known issues. Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWaYrRAAoJENnE0m0OYESRh5gIAJ8WrkPPV8CW2xWmtyIjAxpz 7FvvpxBWHaBgJcCrvNomh2JJupXa+enWCTsskIyH0+FtS85VeOKNvQg68xbCOvLl I0dWxMNb8SCxuagvEje8xGEnf8by8pZdYaK8ERASlNoGVIgN8CwppiKnY8c1yRYn Ti0dUZLyVZvT5Qm2Q3k4pOvfS/+rvFjHiuUllFzfHlp6mdk4573w5eneoTINQvRK OC8iAnSiINQWQvuiavLVIgw7VFBD1WC2iKWuSA3+31YuM8CUpvbbnJHh2QUfGkIw oNTkflxgQJhk/txwqvCSzZsVddhvQLZtiRZYQcG4WUuskygCENeieJGPOXN6ioI= =LY4X -----END PGP SIGNATURE----- From danbryan80 at gmail.com Thu Dec 10 15:27:10 2015 From: danbryan80 at gmail.com (daniel bryan) Date: Thu, 10 Dec 2015 15:27:10 +0000 Subject: [openssl-users] OCSP service dependant on time valid CRLs Message-ID: Hello, I was researching how expired CRLs affect revocation checking via openssl. * TEST #1: *The first test was to find out what status is returned when i verify a certificate against the CRL: [dan at canttouchthis PKI]$ openssl verify -CAfile CAS/cabundle.pem -CRLfile CRLS/ABC-expired.crl -crl_check CERTS/0x500c8bd-revoked.pem *CERTS/0x500c8bd-revoked.pem: C = us, O = ORG, OU = LAB, OU = ABC, OU = D002, CN = test error 12 at 0 depth lookup:CRL has expiredC = us, O = ORG, OU = LAB, OU = ABC, OU = D002, CN = test error 23 at 0 depth lookup:certificate revoked* as you can see the client *WAS* informed the certificate was *revoked*, even though the CRL was expired. *TEST #2: *Next test was using OCSP: [dan at canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080 *Response verify OK CERTS/0x500c8bd-revoked.pem: unknown This Update: Dec 9 20:48:26 2015 GMT* as you can see the client *was NOT *informed the certificate was revoked. We are using a 3rd party vendors OCSP service, and I am of the opinion that an OCSP service should provide a revoked response regardless of the time validity of the CRL. I have read RFC 2560 & 6960 many times, and have not been able to find explicit guidance on this scenario. I am interested in the community opinion on this issue, and any pertinent mandatory guidance. My end goal is either to convince our vendor to provide a revoked status regardless of the CRLs expiration OR justify why an OCSP service should ignore issuers with expired CRLs. I'm looking forward to any feedback provided. --Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Walter.H at mathemainzel.info Thu Dec 10 16:35:25 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Thu, 10 Dec 2015 17:35:25 +0100 Subject: [openssl-users] OCSP service dependant on time valid CRLs In-Reply-To: References: Message-ID: <5669A9CD.109@mathemainzel.info> Hi Dan, On 10.12.2015 16:27, daniel bryan wrote: > *TEST #2: *Next test was using OCSP: > > [dan at canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile > VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert > CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080 > > /Response verify OK > CERTS/0x500c8bd-revoked.pem: *unknown* > This Update: Dec 9 20:48:26 2015 GMT/ > > as you can see the client *was NOT *informed the certificate was revoked. and also that it is not good -> unknown, revoked and good are the 3 values ... > > We are using a 3rd party vendors OCSP service, and I am of the opinion > that an OCSP service should provide a revoked response regardless of > the time validity of the CRL. does the OCSP responder cert be the signing cert itself or was it signed by the same signing cert that signed the cert you want to validate? or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)? > Walter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From matt at openssl.org Thu Dec 10 16:53:50 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 10 Dec 2015 16:53:50 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> Message-ID: <5669AE1E.7090003@openssl.org> On 10/12/15 11:55, Jayalakshmi bhat wrote: > Hi Matt, > > Thanks for the patch. Unfortunately patch did not work. I continued > debugging and found that issue was in constant_time_msb. > > static inline unsigned int constant_time_msb(unsigned int a) { > - *return 0 - (a >> (sizeof(a) * 8 - 1));* > + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); > } Thanks. Have you analysed why the original version failed? Both versions look reasonable to me (ignoring the hardcoded 8 - implying a char is 8 bits). I'd really like to understand that before replacing it with something else which apparently does the same thing. Perhaps you could post some sample values for "a" and the return value, before and after your change. Thanks Matt From noloader at gmail.com Thu Dec 10 16:58:30 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 10 Dec 2015 11:58:30 -0500 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> Message-ID: On Thu, Dec 10, 2015 at 6:55 AM, Jayalakshmi bhat wrote: > Hi Matt, > > Thanks for the patch. Unfortunately patch did not work. I continued > debugging and found that issue was in constant_time_msb. > > static inline unsigned int constant_time_msb(unsigned int a) { > - return 0 - (a >> (sizeof(a) * 8 - 1)); > + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); > } Forgive me for commenting... That looks questionable to me. C has some non-intuitive rules, and usually one casts to an unsigned type during shifts to avoid undefined behavior. I would definitely build out a test case for it. Ensure the test cases include a value with and without the high bit set on a 2's compliment machine. Then, run it under GCC or Clang's Undefined Behavior sanitizer. For GCC you need 4.9 or above. For Clang, you need 3.2 or above. I *think* Ben or Richard has a test build configuration that applies the sanitizers. Jeff From bkaduk at akamai.com Thu Dec 10 17:04:18 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 10 Dec 2015 11:04:18 -0600 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> Message-ID: <5669B092.7030609@akamai.com> On 12/10/2015 05:55 AM, Jayalakshmi bhat wrote: > Hi Matt, > > Thanks for the patch. Unfortunately patch did not work. I continued > debugging and found that issue was in constant_time_msb. > > static inline unsigned int constant_time_msb(unsigned int a) { > - *return 0 - (a >> (sizeof(a) * 8 - 1));* > + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); Hmm, right-shifting a negative value is implementation-defined behavior, so I don't think that this construct would necessarily be portable to all systems. It's not clear to me what purpose the "0 - " was supposed to perform in the original version, though. In any case, it seems that the '8' literal there ought to be CHAR_BIT (). I am curious what value CHAR_BIT has in the environment that Jaya is running in. -Ben > } > > Changed constant_time_msb implementation as shown above. All the tests > passed. I have attached the dis-assembly of the code for both > successful case and failure case. This was requested by Jakob. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Dec 10 17:10:12 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 10 Dec 2015 17:10:12 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5669B092.7030609@akamai.com> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <5669B092.7030609@akamai.com> Message-ID: <5669B1F4.3090301@openssl.org> On 10/12/15 17:04, Benjamin Kaduk wrote: > On 12/10/2015 05:55 AM, Jayalakshmi bhat wrote: >> Hi Matt, >> >> Thanks for the patch. Unfortunately patch did not work. I continued >> debugging and found that issue was in constant_time_msb. >> >> static inline unsigned int constant_time_msb(unsigned int a) { >> - *return 0 - (a >> (sizeof(a) * 8 - 1));* >> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); > > Hmm, right-shifting a negative value is implementation-defined behavior, > so I don't think that this construct would necessarily be portable to > all systems. It's not clear to me what purpose the "0 - " was supposed > to perform in the original version, though. This function is supposed to copy the msb of the input to all of the other bits...so the return value should either be one of 0x00000000 or 0xffffffff (obviously dependent on how big an int is). In the original version the shift would give you just the msb, i.e. a value of 0 or 1. After the "0 -" you get 0 or -1 (0xffffffff). Interestingly I just checked the header file where this function is defined and found this: /* * Returns the given value with the MSB copied to all the other * bits. Uses the fact that arithmetic shift shifts-in the sign bit. * However, this is not ensured by the C standard so you may need to * replace this with something else on odd CPUs. */ This doesn't match up with the implementation - so I suspect the comment predates the implementation - but Jaya's fix would put it back that way. Matt From openssl-users at dukhovni.org Thu Dec 10 17:33:17 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 10 Dec 2015 17:33:17 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> Message-ID: <20151210173317.GL11836@mournblade.imrryr.org> On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote: > static inline unsigned int constant_time_msb(unsigned int a) { > - return 0 - (a >> (sizeof(a) * 8 - 1)); > + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); > } The replacement is not right. This function is supposed to return 0xfffffff for inputs with the high bit set, and 0x0000000 for inputs with the high bit not set. Could you try: static inline unsigned int constant_time_msb(unsigned int a) { return 0 - (a >> ((int)(sizeof(a) * 8 - 1))); } Just in case the compiler is promoting "a" to the (larger?) size of sizeof(a), which would cause an unsigned "a" to get a zero MSB, while a signed "a" would be promoted "correctly". -- Viktor. From jb-openssl at wisemo.com Thu Dec 10 17:38:44 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 10 Dec 2015 18:38:44 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5669AE1E.7090003@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <5669AE1E.7090003@openssl.org> Message-ID: <5669B8A4.3080803@wisemo.com> On 10/12/2015 17:53, Matt Caswell wrote: > On 10/12/15 11:55, Jayalakshmi bhat wrote: >> Hi Matt, >> >> Thanks for the patch. Unfortunately patch did not work. I continued >> debugging and found that issue was in constant_time_msb. >> >> static inline unsigned int constant_time_msb(unsigned int a) { >> - *return 0 - (a >> (sizeof(a) * 8 - 1));* >> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); >> } > Thanks. Have you analysed why the original version failed? Both versions > look reasonable to me (ignoring the hardcoded 8 - implying a char is 8 > bits). I'd really like to understand that before replacing it with > something else which apparently does the same thing. Perhaps you could > post some sample values for "a" and the return value, before and after > your change. Looking at the provided disassembly, it looks like the 1.0.2 version triggers a compiler bug which (at least) forgets to mask the result down to 8 bits after inlining in test_is_zero_8(). The missing mask with FF occurs in multiple functions in the disassembly. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Dec 10 17:45:01 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 10 Dec 2015 18:45:01 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <20151210173317.GL11836@mournblade.imrryr.org> References: <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <20151210173317.GL11836@mournblade.imrryr.org> Message-ID: <5669BA1D.8090502@wisemo.com> On 10/12/2015 18:33, Viktor Dukhovni wrote: > On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote: > >> static inline unsigned int constant_time_msb(unsigned int a) { >> - return 0 - (a >> (sizeof(a) * 8 - 1)); >> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); >> } > The replacement is not right. This function is supposed to return > 0xfffffff for inputs with the high bit set, and 0x0000000 for inputs > with the high bit not set. Could you try: > > static inline unsigned int constant_time_msb(unsigned int a) { > return 0 - (a >> ((int)(sizeof(a) * 8 - 1))); > } > > Just in case the compiler is promoting "a" to the (larger?) size > of sizeof(a), which would cause an unsigned "a" to get a zero MSB, > while a signed "a" would be promoted "correctly". Look again, he is casting a to signed, then doing an arithmetic right shift to extend the msb (sign bit) to the rest of the word. This works on 3 conditions: 1. The platform is actually using twos complement. 2. The signed right shift function invoked by the C compiler is a sign-preserving ("arithmetic") shift. 3. The compiler wasn't written by a fanatic who put the "right shift of negative signed values is undefined" rule above common sense. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Thu Dec 10 17:48:22 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 10 Dec 2015 11:48:22 -0600 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5669BA1D.8090502@wisemo.com> References: <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <20151210173317.GL11836@mournblade.imrryr.org> <5669BA1D.8090502@wisemo.com> Message-ID: <5669BAE6.1030204@akamai.com> On 12/10/2015 11:45 AM, Jakob Bohm wrote: > 3. The compiler wasn't written by a fanatic who put > the "right shift of negative signed values is > undefined" rule above common sense. This is only implementation-defined behavior, not undefined behavior. It is not permitted to crash the system or launch the missiles. (n1256.pdf 6.5.7 paragraph 5.) -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Dec 10 18:09:50 2015 From: openssl-users at dukhovni.org (openssl-users at dukhovni.org) Date: Thu, 10 Dec 2015 13:09:50 -0500 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5669BA1D.8090502@wisemo.com> References: <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <20151210173317.GL11836@mournblade.imrryr.org> <5669BA1D.8090502@wisemo.com> Message-ID: <5D826CBF-2065-4527-B36E-614023F88C7D@dukhovni.org> > On Dec 10, 2015, at 12:45 PM, Jakob Bohm wrote: > > On 10/12/2015 18:33, Viktor Dukhovni wrote: >> On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote: >> >> >>> static inline unsigned int constant_time_msb(unsigned int a) { >>> - return 0 - (a >> (sizeof(a) * 8 - 1)); >>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); >>> } >>> >> The replacement is not right. This function is supposed to return >> 0xfffffff for inputs with the high bit set, and 0x0000000 for inputs >> with the high bit not set. Could you try: >> >> static inline unsigned int constant_time_msb(unsigned int a) { >> return 0 - (a >> ((int)(sizeof(a) * 8 - 1))); >> } >> >> Just in case the compiler is promoting "a" to the (larger?) size >> of sizeof(a), which would cause an unsigned "a" to get a zero MSB, >> while a signed "a" would be promoted "correctly". >> > Look again, he is casting a to signed, then doing an > arithmetic right shift to extend the msb (sign bit) > to the rest of the word. This works on 3 conditions: I saw what he's doing. casting (a) to an int, instead of leaving it unsigned is not an improvement. On the assumption that it made a difference for this compiler, I proposed an alternative that tests whether promotion to the type of the shift's right operand is taking place. It would be good to know whether explicitly casting the shift width to an int helps. Also that 8 could be replaced by CHAR_BIT just in case. -- Viktor. From bkaduk at akamai.com Thu Dec 10 18:13:13 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 10 Dec 2015 12:13:13 -0600 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5D826CBF-2065-4527-B36E-614023F88C7D@dukhovni.org> References: <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <20151210173317.GL11836@mournblade.imrryr.org> <5669BA1D.8090502@wisemo.com> <5D826CBF-2065-4527-B36E-614023F88C7D@dukhovni.org> Message-ID: <5669C0B9.10901@akamai.com> On 12/10/2015 12:09 PM, openssl-users at dukhovni.org wrote: >> On Dec 10, 2015, at 12:45 PM, Jakob Bohm wrote: >> >> On 10/12/2015 18:33, Viktor Dukhovni wrote: >>> On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote: >>> >>> >>>> static inline unsigned int constant_time_msb(unsigned int a) { >>>> - return 0 - (a >> (sizeof(a) * 8 - 1)); >>>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); >>>> } >>>> >>> The replacement is not right. This function is supposed to return >>> 0xfffffff for inputs with the high bit set, and 0x0000000 for inputs >>> with the high bit not set. Could you try: >>> >>> static inline unsigned int constant_time_msb(unsigned int a) { >>> return 0 - (a >> ((int)(sizeof(a) * 8 - 1))); >>> } >>> >>> Just in case the compiler is promoting "a" to the (larger?) size >>> of sizeof(a), which would cause an unsigned "a" to get a zero MSB, >>> while a signed "a" would be promoted "correctly". >>> >> Look again, he is casting a to signed, then doing an >> arithmetic right shift to extend the msb (sign bit) >> to the rest of the word. This works on 3 conditions: > I saw what he's doing. casting (a) to an int, instead of leaving > it unsigned is not an improvement. On the assumption that it made > a difference for this compiler, I proposed an alternative that tests > whether promotion to the type of the shift's right operand is taking > place. It would be good to know whether explicitly casting the shift > width to an int helps. Also that 8 could be replaced by CHAR_BIT > just in case. > Yeah, sizeof returning a size_t that is wider than int, causing promotion of the left argument of the shift operator prior to evaluation seems a plausible explanation for this behavior. -Ben From danbryan80 at gmail.com Thu Dec 10 17:29:54 2015 From: danbryan80 at gmail.com (socket) Date: Thu, 10 Dec 2015 10:29:54 -0700 (MST) Subject: [openssl-users] OCSP service dependant on time valid CRLs In-Reply-To: <5669A9CD.109@mathemainzel.info> References: <5669A9CD.109@mathemainzel.info> Message-ID: Hi Walter, I agree with your addition regarding the fact that it is not saying the cert is good, it's saying unknown. However, my understanding of the RFC is that unknown should be returned when the OCSP service does not know about the certificate issuer. I'm not sure that's the case. Regarding the response verification, we are used the CA Designated Responder (Authorized Responder). meaning that the issuer of serial 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing shows that this only affects the "response verification (OK/FAILED)" not the certificate status returned (good/revoked/unknown). --Dan On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] < ml-node+s6102n61605h91 at n7.nabble.com> wrote: > Hi Dan, > > On 10.12.2015 16:27, daniel bryan wrote: > > *TEST #2: *Next test was using OCSP: > > [dan at canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile > VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert > CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080 > > > > *Response verify OK CERTS/0x500c8bd-revoked.pem: unknown This Update: Dec > 9 20:48:26 2015 GMT* > > as you can see the client *was NOT *informed the certificate was revoked. > > and also that it is not good -> unknown, revoked and good are the 3 values > ... > > > We are using a 3rd party vendors OCSP service, and I am of the opinion > that an OCSP service should provide a revoked response regardless of the > time validity of the CRL. > > does the OCSP responder cert be the signing cert itself or was it signed > by the same signing cert that signed the cert you want to validate? > > or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both > CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)? > > > Walter > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > *smime.p7s* (5K) Download Attachment > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61605.html > To start a new topic under OpenSSL - User, email > ml-node+s6102n3h29 at n7.nabble.com > To unsubscribe from OpenSSL - User, click here > > . > NAML > > -- View this message in context: http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61622.html Sent from the OpenSSL - User mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Dec 10 19:04:05 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 10 Dec 2015 20:04:05 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5669C0B9.10901@akamai.com> References: <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <20151210173317.GL11836@mournblade.imrryr.org> <5669BA1D.8090502@wisemo.com> <5D826CBF-2065-4527-B36E-614023F88C7D@dukhovni.org> <5669C0B9.10901@akamai.com> Message-ID: <5669CCA5.80907@wisemo.com> On 10/12/2015 19:13, Benjamin Kaduk wrote: > On 12/10/2015 12:09 PM, openssl-users at dukhovni.org wrote: >>> On Dec 10, 2015, at 12:45 PM, Jakob Bohm wrote: >>> >>> On 10/12/2015 18:33, Viktor Dukhovni wrote: >>>> On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote: >>>> >>>> >>>>> static inline unsigned int constant_time_msb(unsigned int a) { >>>>> - return 0 - (a >> (sizeof(a) * 8 - 1)); >>>>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); >>>>> } >>>>> >>>> The replacement is not right. This function is supposed to return >>>> 0xfffffff for inputs with the high bit set, and 0x0000000 for inputs >>>> with the high bit not set. Could you try: >>>> >>>> static inline unsigned int constant_time_msb(unsigned int a) { >>>> return 0 - (a >> ((int)(sizeof(a) * 8 - 1))); >>>> } >>>> >>>> Just in case the compiler is promoting "a" to the (larger?) size >>>> of sizeof(a), which would cause an unsigned "a" to get a zero MSB, >>>> while a signed "a" would be promoted "correctly". >>>> >>> Look again, he is casting a to signed, then doing an >>> arithmetic right shift to extend the msb (sign bit) >>> to the rest of the word. This works on 3 conditions: >> I saw what he's doing. casting (a) to an int, instead of leaving >> it unsigned is not an improvement. On the assumption that it made >> a difference for this compiler, I proposed an alternative that tests >> whether promotion to the type of the shift's right operand is taking >> place. It would be good to know whether explicitly casting the shift >> width to an int helps. Also that 8 could be replaced by CHAR_BIT >> just in case. >> > Yeah, sizeof returning a size_t that is wider than int, causing > promotion of the left argument of the shift operator prior to evaluation > seems a plausible explanation for this behavior. Please stop the misinformed guesswork and read the disassembly posted. The compiler in question gets confused by the long sequence of nested inline expressions and looses the truncation from 32 bit unsigned to 8 bit unsigned char in the shuffle. Changing back to the old form of constant_time_msb simplifies the parse tree just enough to avoid the bug. Unfortunately, as a comment in the 1.0.2 source code explains, the old form relies on a language feature not guaranteed by the C standard, which is probably why the implementation was changed to the one currently in 1.0.2. And to those who still don't understand how the old implementation worked: 1. By casting the unsigned a to a signed int, the msb of interest becomes the sign bit. 2. By shifting right the 2's complement signed int by the number of non-sign bits (31 on this target), the sign bit gets replicated to the other bits so negative values (those with the msb set) become -1, while positive values (those with the msb clear) become +0. 3. Casting back to unsigned int results in the desired value of 0xFFFFFFFF or 0x00000000 . On the ARM platform, shifting right by 31 bits can be done to the second input of any arithmetic instruction, thus making it execute in 0.5 instruction time if combined with some other operation. Thus the compiler moves the shift backwards through some arithmetic steps in the zero testing, resulting in the code you see in the posted disassembly. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Erwann.Abalea at docusign.com Thu Dec 10 18:58:23 2015 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Thu, 10 Dec 2015 18:58:23 +0000 Subject: [openssl-users] OCSP service dependant on time valid CRLs In-Reply-To: References: <5669A9CD.109@mathemainzel.info> Message-ID: Bonsoir, The OCSP responder can respond ? unknown ? if it doesn?t know the status of the requested certificate. ? Unknown ? can generally not be used when the issuer is not known, because such a response is signed, and if the responder doesn?t know about the issuer, it can?t choose its own certificate to use to sign the response. If your OCSP responder is CRL based, and the CRL is not valid (badly encoded, wrong signature, incomplete in scope, expired, whatever?), ? unknown ? is a correct answer. ? revoked ? is also a correct answer if an expired CRL is found declaring the requested certificate as revoked. ? tryLater ? is also a correct answer, even ? internalError ? if we consider the CRL as part of the internal state of the responder. Erwann Abalea erwann.abalea at docusign.com Le 10 d?c. 2015 ? 18:29, socket > a ?crit : Hi Walter, I agree with your addition regarding the fact that it is not saying the cert is good, it's saying unknown. However, my understanding of the RFC is that unknown should be returned when the OCSP service does not know about the certificate issuer. I'm not sure that's the case. Regarding the response verification, we are used the CA Designated Responder (Authorized Responder). meaning that the issuer of serial 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing shows that this only affects the "response verification (OK/FAILED)" not the certificate status returned (good/revoked/unknown). --Dan On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <[hidden email]> wrote: Hi Dan, On 10.12.2015 16:27, daniel bryan wrote: TEST #2: Next test was using OCSP: [dan at canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080 Response verify OK CERTS/0x500c8bd-revoked.pem: unknown This Update: Dec 9 20:48:26 2015 GMT as you can see the client was NOT informed the certificate was revoked. and also that it is not good -> unknown, revoked and good are the 3 values ... We are using a 3rd party vendors OCSP service, and I am of the opinion that an OCSP service should provide a revoked response regardless of the time validity of the CRL. does the OCSP responder cert be the signing cert itself or was it signed by the same signing cert that signed the cert you want to validate? or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)? Walter -------------- next part -------------- An HTML attachment was scrubbed... URL: From danbryan80 at gmail.com Thu Dec 10 19:07:43 2015 From: danbryan80 at gmail.com (socket) Date: Thu, 10 Dec 2015 12:07:43 -0700 (MST) Subject: [openssl-users] OCSP service dependant on time valid CRLs In-Reply-To: References: <5669A9CD.109@mathemainzel.info> Message-ID: Thanks for chiming in Erwann. This OCSP service is CRL based. The software I am using has a "default signing certificate". I also have #X CA specific signing certificates for each CA in our lab PKI. It chooses to use the default signing certificate for all unknown issuers (like if someone explicitly queries the service for a microsoft timestamp certificate). I appreciate your definitive response regarding that the correct answer in this situation is to return unknown. I recognize your name as an authority in pkix, but is this documented anywhere? I would like to be able to justify to my customer that this is indeed the correct response. Also, it seems weird to me that validating this certificate against the expired CRL returns a status of revoked, but when validating this same certificate against the OCSP service it says unknown. I guess i just have to get over that they are different and that a certificate can have a different status depending on who you ask. Looking forward to any follow on thoughts... --Dan On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] < ml-node+s6102n61627h73 at n7.nabble.com> wrote: > Bonsoir, > > The OCSP responder can respond ? unknown ? if it doesn?t know the status > of the requested certificate. ? Unknown ? can generally not be used when > the issuer is not known, because such a response is signed, and if the > responder doesn?t know about the issuer, it can?t choose its own > certificate to use to sign the response. > > If your OCSP responder is CRL based, and the CRL is not valid (badly > encoded, wrong signature, incomplete in scope, expired, whatever?), > ? unknown ? is a correct answer. ? revoked ? is also a correct answer if an > expired CRL is found declaring the requested certificate as revoked. > ? tryLater ? is also a correct answer, even ? internalError ? if we > consider the CRL as part of the internal state of the responder. > > Erwann Abalea > [hidden email] > > Le 10 d?c. 2015 ? 18:29, socket <[hidden email] > > a ?crit : > > Hi Walter, > > I agree with your addition regarding the fact that it is not saying the > cert is good, it's saying unknown. However, my understanding of the RFC is > that unknown should be returned when the OCSP service does not know about > the certificate issuer. I'm not sure that's the case. > > Regarding the response verification, we are used the CA Designated > Responder (Authorized Responder). meaning that the issuer of serial > 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV). > However, my testing shows that this only affects the "response verification > (OK/FAILED)" not the certificate status returned (good/revoked/unknown). > > --Dan > > > On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] < href="x-msg://5/user/SendEmail.jtp?type=node&node=61622&i=0" > target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote: > >> Hi Dan, >> >> On 10.12.2015 16:27, daniel bryan wrote: >> >> *TEST #2: *Next test was using OCSP: >> >> [dan at canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile >> VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert >> CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080 >> >> >> >> *Response verify OK CERTS/0x500c8bd-revoked.pem: unknown This Update: Dec >> 9 20:48:26 2015 GMT* >> >> as you can see the client *was NOT *informed the certificate was revoked. >> >> and also that it is not good -> unknown, revoked and good are the 3 >> values ... >> >> >> We are using a 3rd party vendors OCSP service, and I am of the opinion >> that an OCSP service should provide a revoked response regardless of the >> time validity of the CRL. >> >> does the OCSP responder cert be the signing cert itself or was it signed >> by the same signing cert that signed the cert you want to validate? >> >> or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both >> CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)? >> >> >> Walter >> >> > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > If you reply to this email, your message will be added to the discussion > below: > > http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61627.html > To start a new topic under OpenSSL - User, email > ml-node+s6102n3h29 at n7.nabble.com > To unsubscribe from OpenSSL - User, click here > > . > NAML > > -- View this message in context: http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61628.html Sent from the OpenSSL - User mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan.rahn at gmail.com Thu Dec 10 21:06:00 2015 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Thu, 10 Dec 2015 13:06:00 -0800 Subject: [openssl-users] force to use /dev/random for openssl fips module In-Reply-To: <5667AD46.6050208@fosiao.com> References: <5667AD46.6050208@fosiao.com> Message-ID: xxiao, have you changed the code to also increase the timeout and not try to use other devices to get entropy? If /dev/random is blocking at the time, it may run into issues trying to look for other sources of entropy than giving up. On Tue, Dec 8, 2015 at 8:25 PM, xxiao8 wrote: > I don't know how critical is the DEVRANDOM for openssl-fips, in e_os.h I > saw this: > ---- > #define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom" > ---- > we have a hardware RNG that is feeding /dev/random via: > ---- > /sbin/rngd -r /dev/hwrng -W 4000 > ---- > so the /dev/random will never block, I thus change e_os.h to force usage > of /dev/random(per our fips code reviewer's request, who thinks I need > change that for fips): > ---- > #define DEVRANDOM "/dev/random" > ---- > this looks fine, however I don't know if it's really the right thing to > do, after this change my system starts to have issues(silent reboot), > changing this line back everything runs normally. > > any help is appreciated. > > xxiao > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nounou.dadoun at avigilon.com Thu Dec 10 21:45:10 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Thu, 10 Dec 2015 21:45:10 +0000 Subject: [openssl-users] Failed TLSv1.2 handshake In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0DFFAD4@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0DFF96A@mbx027-w1-ca-4.exch027.domain.local> <20151208014924.GD12639@mournblade.imrryr.org> <8149AB08BCB1F54F92680ED6104891A0DFFAD4@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <8149AB08BCB1F54F92680ED6104891A0E00233@mbx027-w1-ca-4.exch027.domain.local> Update: after I disabled aes-gcm the server selected TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) and the connection succeeded (disabling aes-gcm also disabled the available ciphers with SHA384 so it's not clear whether that was the culprit or not). So things are working again but still not sure what the interop problem was, thanks for the help ... N Nou Dadoun Senior Firmware Developer, Security Specialist From kurt at roeckx.be Thu Dec 10 23:16:08 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 11 Dec 2015 00:16:08 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5668B59C.60106@akamai.com> References: <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> Message-ID: <20151210231608.GA17931@roeckx.be> On Wed, Dec 09, 2015 at 05:13:32PM -0600, Benjamin Kaduk wrote: > C does not make such a guarantee, though recent-ish POSIX does. (This > system is a windows one, thought, right?) There are DSPs that only support 32 bit, they don't have a concept of 8 bit. But I think there is various code that assumes that char is 8 bit, and I doubt you can get OpenSSL working on such a system. Kurt From kurt at roeckx.be Thu Dec 10 23:28:04 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 11 Dec 2015 00:28:04 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> Message-ID: <20151210232804.GA17434@roeckx.be> On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote: > Hi Matt, > > Thanks for the patch. Unfortunately patch did not work. I continued > debugging and found that issue was in constant_time_msb. > > static inline unsigned int constant_time_msb(unsigned int a) { > - *return 0 - (a >> (sizeof(a) * 8 - 1));* > + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); > } This looks a revert of commit d2fa182988afa33d9e950358de406cc9fb36d000 It was changed because of the implementation defined behaviour, and we would like to avoid that. See RT ticket #3558. Kurt From jb-openssl at wisemo.com Fri Dec 11 02:14:55 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 11 Dec 2015 03:14:55 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <20151210231608.GA17931@roeckx.be> References: <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <20151210231608.GA17931@roeckx.be> Message-ID: <566A319F.5030105@wisemo.com> On 11/12/2015 00:16, Kurt Roeckx wrote: > On Wed, Dec 09, 2015 at 05:13:32PM -0600, Benjamin Kaduk wrote: >> C does not make such a guarantee, though recent-ish POSIX does. (This >> system is a windows one, thought, right?) > There are DSPs that only support 32 bit, they don't have a concept > of 8 bit. But I think there is various code that assumes that > char is 8 bit, and I doubt you can get OpenSSL working on such a > system. > Target in question is traditional 32 bit ARM with 32 bit instructions and 8 bit char. Looks like a hard to fix compiler bug to me. 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 Michal.Trojnara at mirt.net Fri Dec 11 11:28:59 2015 From: Michal.Trojnara at mirt.net (Michal Trojnara) Date: Fri, 11 Dec 2015 12:28:59 +0100 Subject: [openssl-users] stunnel 5.28 released Message-ID: <566AB37B.3020501@mirt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Users, I have released version 5.28 of stunnel. This is a bugfix release. I highly recommend upgrading your stunnel. The ChangeLog entry: Version 5.28, 2015.12.11, urgency: HIGH * New features - Build matrix (.travis.yml) extended with ./configure options. - mingw.mak updated to build tstunnel.exe (thx to Jose Alf.). * Bugfixes - Fixed incomplete initialization. - Fixed UCONTEXT threading on OSX. - Fixed exit codes for information requests (as in "stunnel -version" or "stunnel -help"). Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 9a25b87b1ef0c08fa3d796edce07b4408e6a8acece23de2eb7ee9285b78852b5 stunnel-5.28.tar.gz 020b5bd8a97a1da91e9b379c0d2fa8a14606402e2b0c1eb9191fe99c7f4665f9 stunnel-5.28-installer.exe 0af65879343b37bcda89dbbde51f6cfde016a044a533f7bdec229f4e1ec25eb9 stunnel-5.28-android.zip Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWarN7AAoJEC78f/DUFuAUKhcQAJ62DQW+GMpAmtggO42LhaEj NcAdpgYvCAJnemRnTj+YMHHAGGIn7MY7VQZVzIIHL0y4CS6yy8kg1WVQeDgxS7PM zil/CViLayNQUnEaUSpoD3yFlb5i6wqofPa5/ohObAvUwTejN/XtOlyT6OMTEovF ZWWLsqYnVTCkbrY1Usu9DNRlSWaCgGeqL5ZqhbiJHk7hDHIH5Yy8KXKw3dVuOxBZ 86uYNH0WW3qNHKJrI1z70cA+18c6Kab5/4NnzzmWG+TyYCVVLL8JVkahEHhCX5mc yBYcMyBrSkrUoS++IdEZtOKYjwxfiEFdre0junC1m5DqtbOc+vWcvqZRGUfCszHK bg4LlCoNs6VhaAFzY9dyXKWqFP+HvH1cqcVcagCaofcdAEaFrwP4dqwUUBKCT44z JNhEzyrI6+coGq92SZUeSiko2bj+rQWDf3s5pY+zWQVvUe12rTo427Mhbge3sBhQ QykwMsihtrP9s25YkDQHqlpBV85W3axq/O2veb15QlbETDM6eGfnMCFjqhxpBBMO sSgHOr9E1E4pxN4kcokPhwKizxSe0EHVQYM27qGfNXJkzVAvHE+mz0WR2kMPpjT5 N6th9lOMgrjXGo6aTBQO3DIEkw+BB0C9OVWnNXMWqmUnsKp80QVeZKZXgK5c2t1y Y8e0W7HH2xdaQemUQp+n =GrPO -----END PGP SIGNATURE----- From Erwann.Abalea at docusign.com Fri Dec 11 14:15:01 2015 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Fri, 11 Dec 2015 14:15:01 +0000 Subject: [openssl-users] OCSP service dependant on time valid CRLs In-Reply-To: References: <5669A9CD.109@mathemainzel.info> Message-ID: <2B0F71E7-CDBA-49F1-A56A-F8356BF82035@docusign.com> Bonjour, The problem with signing with a default certificate is that the response certainly won?t be accepted by the client (see RFC6960 section 4.2.2.2, this responder certificate doesn?t follow criteria 1 and 2, and certainly not criteria 3), so you?re performing a signature knowing it will be rejected by a compliant client. It is also unwise from your side, because anybody can send a request for free, and as a result you?ll perform a signature: non negligible CPU cost and the response is larger than the request. An unsigned error message may be better. ? Unknown ? is *a* correct answer in that specific case, not the only correct one. ? tryLater ? and ? internalError ? are equivalently correct answers. ? Good ?, ? malformedRequest ?, and ? sigRequired ? are NOT correct answers. ? unauthorized ? may also be considered a correct answer, but others may disagree. ? Revoked ? may seem a correct answer also, but not quite (see below). The meaning of those different results is explained in RFC6960 and RFC5019. Of course, if you?re using CRLs as an authoritative source of certificate status, RFC5280 is to be read also. Reading the algorithm described in RFC5280 section 6.3.3 to perform a CRL validation, you?ll see that: - at step (a)(1)(ii), you don?t get a newer CRL, so you can?t continue the algorithm - after the algorithm, reasons_masks is still the empty set, and cert_status still has the value UNREVOKED, so the revocation status has NOT been determined - last paragraph of 6.3.3 tells you that in the end, if the revocation status has not been determined, return a cert_status UNDETERMINED. An OCSP service based on a CRL, given an expired CRL, running this normative algorithm, will get a cert_status ? UNDETERMINED ?, and not a value stating that it?s revoked. Such an OCSP service, responding ? Revoked ?, wouldn?t be strictly compliant. Erwann Abalea erwann.abalea at docusign.com Le 10 d?c. 2015 ? 20:07, socket > a ?crit : Thanks for chiming in Erwann. This OCSP service is CRL based. The software I am using has a "default signing certificate". I also have #X CA specific signing certificates for each CA in our lab PKI. It chooses to use the default signing certificate for all unknown issuers (like if someone explicitly queries the service for a microsoft timestamp certificate). I appreciate your definitive response regarding that the correct answer in this situation is to return unknown. I recognize your name as an authority in pkix, but is this documented anywhere? I would like to be able to justify to my customer that this is indeed the correct response. Also, it seems weird to me that validating this certificate against the expired CRL returns a status of revoked, but when validating this same certificate against the OCSP service it says unknown. I guess i just have to get over that they are different and that a certificate can have a different status depending on who you ask. Looking forward to any follow on thoughts... --Dan On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] <[hidden email]> wrote: Bonsoir, The OCSP responder can respond ? unknown ? if it doesn?t know the status of the requested certificate. ? Unknown ? can generally not be used when the issuer is not known, because such a response is signed, and if the responder doesn?t know about the issuer, it can?t choose its own certificate to use to sign the response. If your OCSP responder is CRL based, and the CRL is not valid (badly encoded, wrong signature, incomplete in scope, expired, whatever?), ? unknown ? is a correct answer. ? revoked ? is also a correct answer if an expired CRL is found declaring the requested certificate as revoked. ? tryLater ? is also a correct answer, even ? internalError ? if we consider the CRL as part of the internal state of the responder. Erwann Abalea [hidden email] Le 10 d?c. 2015 ? 18:29, socket <[hidden email]> a ?crit : Hi Walter, I agree with your addition regarding the fact that it is not saying the cert is good, it's saying unknown. However, my understanding of the RFC is that unknown should be returned when the OCSP service does not know about the certificate issuer. I'm not sure that's the case. Regarding the response verification, we are used the CA Designated Responder (Authorized Responder). meaning that the issuer of serial 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing shows that this only affects the "response verification (OK/FAILED)" not the certificate status returned (good/revoked/unknown). --Dan On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <[hidden email]> wrote: Hi Dan, On 10.12.2015 16:27, daniel bryan wrote: TEST #2: Next test was using OCSP: [dan at canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080 Response verify OK CERTS/0x500c8bd-revoked.pem: unknown This Update: Dec 9 20:48:26 2015 GMT as you can see the client was NOT informed the certificate was revoked. and also that it is not good -> unknown, revoked and good are the 3 values ... We are using a 3rd party vendors OCSP service, and I am of the opinion that an OCSP service should provide a revoked response regardless of the time validity of the CRL. does the OCSP responder cert be the signing cert itself or was it signed by the same signing cert that signed the cert you want to validate? or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)? Walter _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users If you reply to this email, your message will be added to the discussion below: http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61627.html To start a new topic under OpenSSL - User, email [hidden email] To unsubscribe from OpenSSL - User, click here. NAML ________________________________ View this message in context: Re: OCSP service dependant on time valid CRLs Sent from the OpenSSL - User mailing list archive at Nabble.com. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From imjebran at gmail.com Fri Dec 11 14:18:00 2015 From: imjebran at gmail.com (Mohammad Jebran) Date: Fri, 11 Dec 2015 19:18:00 +0500 Subject: [openssl-users] sign sub CA issue In-Reply-To: References: Message-ID: Please can I have some advise on this query. Regards, Jebran. On Tue, Dec 8, 2015 at 11:18 AM, Mohammad Jebran wrote: > I have to sign a sub-CA through my current root CA using openSSLeverything > I have configured as per instructions but still getting an error that > "stateorProvanceName field needed to be the same" As mentioned below. > > > > > > *root at machine:~/ImportantCACerts/intermediate# openssl ca > -configopenssl.cnf -extensions v3_intermediate_ca -days 3650 -notext -md > sha256 -in csr/subca2.csr -out certs/subca2.crt* > > *Using configuration from openssl.cnf* > > *Check that the request matches the signature* > > *Signature ok* > > *The stateOrProvinceName field needed to be the same in the* > > *CA certificate (HK) and the request (HK)* > > > > > > > *Thanks & Regards,Jebran.* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at an3k.de Fri Dec 11 14:33:51 2015 From: ben at an3k.de (Ben Humpert) Date: Fri, 11 Dec 2015 15:33:51 +0100 Subject: [openssl-users] sign sub CA issue In-Reply-To: References: Message-ID: Tell the person who created the CSR that the value of the stateOrProvinceName field has to be HK. If that is not possible because the subCA is in a different country you can change your openssl.cnf to allow different values in that field so instead of stateOrProvinceName = match you have to use at least stateOrProvinceName = supplied 2015-12-11 15:18 GMT+01:00 Mohammad Jebran : > Please can I have some advise on this query. > > Regards, > Jebran. > > On Tue, Dec 8, 2015 at 11:18 AM, Mohammad Jebran wrote: >> >> I have to sign a sub-CA through my current root CA using openSSLeverything >> I have configured as per instructions but still getting an error that >> "stateorProvanceName field needed to be the same" As mentioned below. >> >> >> >> >> >> root at machine:~/ImportantCACerts/intermediate# openssl ca >> -configopenssl.cnf -extensions v3_intermediate_ca -days 3650 -notext -md >> sha256 -in csr/subca2.csr -out certs/subca2.crt >> >> Using configuration from openssl.cnf >> >> Check that the request matches the signature >> >> Signature ok >> >> The stateOrProvinceName field needed to be the same in the >> >> CA certificate (HK) and the request (HK) >> >> >> >> >> >> Thanks & Regards, >> Jebran. > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From jb-openssl at wisemo.com Fri Dec 11 15:14:54 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 11 Dec 2015 16:14:54 +0100 Subject: [openssl-users] sign sub CA issue In-Reply-To: References: Message-ID: <566AE86E.5090206@wisemo.com> 1. Check if the certificate for your root CA specifies any "path restrictions" or similar that says that it cannot validly sign certificates outside some state or province. Having such restrictions in a root CA is GOOD whenever possible, because it limits the damage that can be done if the CA security is compromised, and because it limits the reasons other people might not want to install your root CA into their browsers/mail programs/computers. 2. Check if the settings in your openssl.cnf file specify that the "StateOrProvince" field needs to have a specific value when running the CA command. If #1 is the issue, you cannot change it without regenerating the self-signed root CA cert (using the same key etc. for an easier transition) and then install the new version of this cert in all the computers and programs where the old version was installed. If #2 is the issue, all you need to do is to find and change that line in openssl.cnf . That line almost certainly says "StateOrProvince" on it, so it should be easy to find. On 11/12/2015 15:18, Mohammad Jebran wrote: > Please can I have some advise on this query. > > Regards, > Jebran. > > On Tue, Dec 8, 2015 at 11:18 AM, Mohammad Jebran > wrote: > > I have to sign a sub-CA through my current root CA using > openSSLeverything I have configured as per instructions but still > getting an error that "stateorProvanceName field needed to be the > same" As mentioned below. > > /root at machine:~/ImportantCACerts/intermediate# openssl ca > -configopenssl.cnf -extensions v3_intermediate_ca -days 3650 > -notext -md sha256 -in csr/subca2.csr -out certs/subca2.crt/ > > /Using configuration from openssl.cnf/ > > /Check that the request matches the signature/ > > /Signature ok/ > > /The stateOrProvinceName field needed to be the same in the/ > > /CA certificate (HK) and the request (HK)/ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Fri Dec 11 14:59:50 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 11 Dec 2015 15:59:50 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <566A319F.5030105@wisemo.com> References: <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <20151210231608.GA17931@roeckx.be> <566A319F.5030105@wisemo.com> Message-ID: <566AE4E6.5070605@openssl.org> >>> C does not make such a guarantee, though recent-ish POSIX does. (This >>> system is a windows one, thought, right?) >> There are DSPs that only support 32 bit, they don't have a concept >> of 8 bit. But I think there is various code that assumes that >> char is 8 bit, and I doubt you can get OpenSSL working on such a >> system. >> > Target in question is traditional 32 bit ARM with 32 bit > instructions and 8 bit char. > > Looks like a hard to fix compiler bug to me. While assessment that code presented in disassembler output lacks a number of &0xFF is absolutely correct, it's not *necessarily* proof of a compiler bug (but read to the end, please). Trouble is that since functions are static compiler is free to trim them as it suits local goal in any given module. For example consider disassembler output for constant_time_eq_8 from x86_64 test/constant_time_test.o compiled by gcc 4.8: : xor %esi,%edi lea -0x1(%rdi),%eax not %edi and %edi,%eax sar $0x1f,%eax retq Note no mask either! [Note that it even replaced 0-(a>>(sizeof(a)*8-1)) with arithmetic shift!] However! This does *not* mean that suggestion about compiler bug is rejected, it only means that you can't use lack of &0xFF in presented disassembler output as definitive proof. constant_time_msb was pinpointed as culprit. But I can certify that binary code generated for 0 - (a >> (sizeof(a) * 8 - 1)) *alone* is actually correct. It should be and is mov rX, rY, lsr #31 rsb rZ, rX, #0 [Unless compiler recognizes it as equivalent of arithmetic shift, like gcc did above]. But as it gets inlined in *real* usage cases, compiler will subject it to all possible kind of optimizations and in process can loose track of things, which would be definition of compiler bug. In other words one can't dismiss the suggestion that it is a compiler bug... More reliable to way to tell if it's indeed a compiler bug is to disable optimizations. So I'd suggest to do that. Not to do that and leave it like that if it works, but to *determine* if we are looking at compiler bug or not. From appro at openssl.org Fri Dec 11 15:06:43 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 11 Dec 2015 16:06:43 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5669AE1E.7090003@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <5669AE1E.7090003@openssl.org> Message-ID: <566AE683.80801@openssl.org> >> static inline unsigned int constant_time_msb(unsigned int a) { >> - *return 0 - (a >> (sizeof(a) * 8 - 1));* >> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); >> } > > > ... Both versions > look reasonable to me (ignoring the hardcoded 8 - implying a char is 8 > bits). Hardcoded 8 is not reference to char C type, but to units in which sizeof(variable) is measured. For example when we say ILP32 or LP64, what do we mean and what role does 8 play in the drama? From razikak at gmail.com Fri Dec 11 15:46:23 2015 From: razikak at gmail.com (Abdul Razik) Date: Fri, 11 Dec 2015 09:46:23 -0600 Subject: [openssl-users] Build failure with OpenSSL version 1.0.2e in Win32 platform Message-ID: Hello Can someone please help with this issue? I am trying to build version 1.0.2e with VS 2015 and got the following build error with 32 bit, 64 bit builds fine , searching online it seems to have been resolved, not sure how to get the fix and which files are affected by the fix. Can someone please help with this? perl crypto\sha\asm\sha1-586.pl win32 /MT /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_C RT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES _ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE >tmp32\sha1-586.asm ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32\sha1-586.obj tmp32\sha1-586.asm Assembling: tmp32\sha1-586.asm tmp32\sha1-586.asm(1432) : error A2070:invalid instruction operands tmp32\sha1-586.asm(1576) : error A2070:invalid instruction operands NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\ml.EXE"' : return code '0x1' Stop. Thanks Razik -- Abdul Razik Mobile: 512 550 4282 From matt at openssl.org Fri Dec 11 15:51:13 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 11 Dec 2015 15:51:13 +0000 Subject: [openssl-users] Build failure with OpenSSL version 1.0.2e in Win32 platform In-Reply-To: References: Message-ID: <566AF0F1.5040301@openssl.org> On 11/12/15 15:46, Abdul Razik wrote: > Hello > > Can someone please help with this issue? I am trying to build version > 1.0.2e with VS 2015 and got the following build error with 32 bit, 64 > bit builds fine , > > searching online it seems to have been resolved, not sure how to get > the fix and which files are affected by the fix. Can someone please > help with this? >From INSTALL.W32: - Netwide Assembler, a.k.a. NASM, available from http://nasm.sourceforge.net/ is required if you intend to utilize assembler modules. Note that NASM is now the only supported assembler. See the instructions later in that file for how to use it to build OpenSSL. Matt From imjebran at gmail.com Fri Dec 11 16:00:17 2015 From: imjebran at gmail.com (Mohammad Jebran) Date: Fri, 11 Dec 2015 21:00:17 +0500 Subject: [openssl-users] sign sub CA issue In-Reply-To: References: Message-ID: Thanks guys, Its done. ? Regards, Jebran. On Fri, Dec 11, 2015 at 7:18 PM, Mohammad Jebran wrote: > Please can I have some advise on this query. > > Regards, > Jebran. > > On Tue, Dec 8, 2015 at 11:18 AM, Mohammad Jebran > wrote: > >> I have to sign a sub-CA through my current root CA using openSSLeverything >> I have configured as per instructions but still getting an error that >> "stateorProvanceName field needed to be the same" As mentioned below. >> >> >> >> >> >> *root at machine:~/ImportantCACerts/intermediate# openssl ca >> -configopenssl.cnf -extensions v3_intermediate_ca -days 3650 -notext -md >> sha256 -in csr/subca2.csr -out certs/subca2.crt* >> >> *Using configuration from openssl.cnf* >> >> *Check that the request matches the signature* >> >> *Signature ok* >> >> *The stateOrProvinceName field needed to be the same in the* >> >> *CA certificate (HK) and the request (HK)* >> >> >> >> >> >> >> *Thanks & Regards,Jebran.* >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Dec 11 16:31:32 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 11 Dec 2015 16:31:32 +0000 Subject: [openssl-users] OSTIF Message-ID: <566AFA64.9030400@openssl.org> Hi all I've had some emails recently from Derek at OSTIF who has been talking to me about their plans to do an audit (separate to the current CII one) of OpenSSL next year. OSTIF is not associated or affiliated with OpenSSL, but if you're interested you can learn more here: https://ostif.org/ Regards Matt From Michael.Wojcik at microfocus.com Fri Dec 11 16:41:44 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 11 Dec 2015 16:41:44 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <566AE683.80801@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <5669AE1E.7090003@openssl.org> <566AE683.80801@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Andy Polyakov > Sent: Friday, December 11, 2015 10:07 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in > OpenSSL 1.0.2d > > >> static inline unsigned int constant_time_msb(unsigned int a) { > >> - *return 0 - (a >> (sizeof(a) * 8 - 1));* > >> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); > >> } > > > > > > ... Both versions > > look reasonable to me (ignoring the hardcoded 8 - implying a char is 8 > > bits). > > Hardcoded 8 is not reference to char C type, but to units in which > sizeof(variable) is measured. For example when we say ILP32 or LP64, > what do we mean and what role does 8 play in the drama? The distinction you're drawing is meaningless. The result of the sizeof operator is defined in terms of the C char type. Please refer to the C specification. For example, referring to ISO 9899:1999 (because C11 is not widely used), please see 6.5.3.4, "The sizeof operator", items 2 and 3, and particularly the first sentence of #3: "When applied to an operand that has type char, unsigned char, or signed char, (or a qualified version thereof) the result is 1." sizeof(any-char-type) is ALWAYS 1, by definition. Also note, from 6.5.3.4 #2: "The sizeof operator yields the size (in bytes) of its operand". In C, "byte" is a synonym for "char". It is NOT a synonym for "octet". The number of bits in a char (or byte) in C is specified by CHAR_BIT in . CHAR_BIT must be >= 8. (See 5.42.4.2.1, etc.) Using a literal 8 here assumes CHAR_BIT == 8. It would be better, in terms of portability, to include and use CHAR_BIT here. However, my guess is that getting OpenSSL working on platforms where CHAR_BIT > 8 would require substantial effort and would likely be pointless; if no one's asking for it, no one's likely to use it. (Also, such platforms are generally DSPs which are not likely to be able to run OpenSSL anyway.) All of these points have already been made in this thread, except for the C&V citations (and with occasional errors such as "the unit for sizeof is chars not bytes" - that's a contradictory statement, since "byte" is a term of art in the C specification and is identical to "char"). -- Michael Wojcik Technology Specialist, Micro Focus From appro at openssl.org Fri Dec 11 16:48:20 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 11 Dec 2015 17:48:20 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <566AE683.80801@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <5669AE1E.7090003@openssl.org> <566AE683.80801@openssl.org> Message-ID: <566AFE54.3040900@openssl.org> >>> static inline unsigned int constant_time_msb(unsigned int a) { >>> - *return 0 - (a >> (sizeof(a) * 8 - 1));* >>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); >>> } >> >> >> ... Both versions >> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8 >> bits). > > Hardcoded 8 is not reference to char C type, but to units in which > sizeof(variable) is measured. For example when we say ILP32 or LP64, > what do we mean and what role does 8 play in the drama? Well, one can argue that language standard doesn't actually dictate the unit of sizeof(variable) to be 8-bit wide (only that it's *at least* 8, right?), but we do so to say live in an "ILP" world and 8 is ubiquitous. From appro at openssl.org Fri Dec 11 17:40:19 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 11 Dec 2015 18:40:19 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <5669AE1E.7090003@openssl.org> <566AE683.80801@openssl.org> Message-ID: <566B0A83.5010801@openssl.org> On 12/11/15 17:41, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Andy Polyakov >> Sent: Friday, December 11, 2015 10:07 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in >> OpenSSL 1.0.2d >> >>>> static inline unsigned int constant_time_msb(unsigned int a) { >>>> - *return 0 - (a >> (sizeof(a) * 8 - 1));* >>>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); >>>> } >>> >>> >>> ... Both versions >>> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8 >>> bits). >> >> Hardcoded 8 is not reference to char C type, but to units in which >> sizeof(variable) is measured. For example when we say ILP32 or LP64, >> what do we mean and what role does 8 play in the drama? > > The distinction you're drawing is meaningless. Right, I've let practical myself talk too soon, sorry. Yet we do adhere to ILP notion when describing platform requirement, so 8 is kind of implied anyway. But in case one chooses to switch to CHAR_BIT. I want to remind that not all platforms OpenSSL [still] supports are sufficiently standard compliant. There are platforms that are *partially* compliant or stuck between standards. But I'd say that it would be safe to assume that if CHAR_BIT is not defined, then it's 8. > (Also, such platforms are generally DSPs which are not likely to be > able to run OpenSSL anyway.) As fun fact, OpenSSL does run on TI C6000 series DSP and even optimized for C64x+ and forward. Anyway, this has little to do with problem at hand, as all assumptions made implicitly or explicitly do apply to the platform in question. If it turns to be compiler bug, then no argument about standard compliance would justify it. And we'll face the usual dilemma, do we give in and arrange a kludge (e.g. with #ifdef _MSC_VER), or send user to said compiler vendor... Latter is kind of counter-productive, former is ... From noloader at gmail.com Fri Dec 11 18:30:59 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 11 Dec 2015 13:30:59 -0500 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <5669BAE6.1030204@akamai.com> References: <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <20151210173317.GL11836@mournblade.imrryr.org> <5669BA1D.8090502@wisemo.com> <5669BAE6.1030204@akamai.com> Message-ID: > 3. The compiler wasn't written by a fanatic who put > the "right shift of negative signed values is > undefined" rule above common sense. > > This is only implementation-defined behavior, not undefined behavior. It is > not permitted to crash the system or launch the missiles. (n1256.pdf 6.5.7 > paragraph 5.) The potential problem with implementation defined is its not guaranteed to produce consistent results. Different compilers or different versions of the same compiler may arrive at different results. In this light, the crash might be welcomed to make it easy to find the trouble spot :) From teddy at teddy.ch Sat Dec 12 21:23:38 2015 From: teddy at teddy.ch (Dominik Mahrer (Teddy)) Date: Sat, 12 Dec 2015 22:23:38 +0100 Subject: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16) Message-ID: <566C905A.7080709@teddy.ch> Hi everyone My question is: How can I set up a bundle of commercial root CA certificates? Exactly this the same question I found as FAQ # 16 (User). But as answer there is only explained that openssl will not serve a bundle. But it is not explained how to set up a bundle - but exactly this I would like to know. Thanks in advice Teddy -- Teddy Engineering GmbH http://www.teddy.ch/ Lettenmattstrasse 5 mailto:teddy at teddy.ch 8903 Birmensdorf ZH +41 32 511 07 48 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3790 bytes Desc: S/MIME Cryptographic Signature URL: From ben at an3k.de Sat Dec 12 21:50:18 2015 From: ben at an3k.de (Ben Humpert) Date: Sat, 12 Dec 2015 22:50:18 +0100 Subject: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16) In-Reply-To: <566C905A.7080709@teddy.ch> References: <566C905A.7080709@teddy.ch> Message-ID: Hi, so if I understand you correctly you want to create one file that contains more than one CA certificate and can be installed onto Windows, Mac, etc.? You only can do that if you create a p12 file and that must contain a leaf certificate and its private key. openssl pkcs12 -export -in out/X.crt -inkey out/X.key -chain -out out/X.p12 You can check the openssl pkcs12 help for more arguments. Best regards, Ben 2015-12-12 22:23 GMT+01:00 Dominik Mahrer (Teddy) : > Hi everyone > > My question is: > How can I set up a bundle of commercial root CA certificates? > Exactly this the same question I found as FAQ # 16 (User). But as answer > there is only explained that openssl will not serve a bundle. But it is not > explained how to set up a bundle - but exactly this I would like to know. > > Thanks in advice > Teddy > > -- > Teddy Engineering GmbH http://www.teddy.ch/ > Lettenmattstrasse 5 mailto:teddy at teddy.ch > 8903 Birmensdorf ZH +41 32 511 07 48 > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From kurt at roeckx.be Sat Dec 12 22:17:59 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 12 Dec 2015 23:17:59 +0100 Subject: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16) In-Reply-To: <566C905A.7080709@teddy.ch> References: <566C905A.7080709@teddy.ch> Message-ID: <20151212221759.GA23983@roeckx.be> On Sat, Dec 12, 2015 at 10:23:38PM +0100, Dominik Mahrer (Teddy) wrote: > Hi everyone > > My question is: > How can I set up a bundle of commercial root CA certificates? > Exactly this the same question I found as FAQ # 16 (User). But as answer > there is only explained that openssl will not serve a bundle. But it is not > explained how to set up a bundle - but exactly this I would like to know. Why do you think you need a bundle? How will this bundle then be used? An answer could be that you just cat all the pem files into 1 large file. Kurt From openssl-users at dukhovni.org Sun Dec 13 02:53:45 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 12 Dec 2015 21:53:45 -0500 Subject: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16) In-Reply-To: <566C905A.7080709@teddy.ch> References: <566C905A.7080709@teddy.ch> Message-ID: <815FB1AE-E35B-4514-BBAC-9FC7FC3EC9F6@dukhovni.org> > On Dec 12, 2015, at 4:23 PM, Dominik Mahrer (Teddy) wrote: > > How can I set up a bundle of commercial root CA certificates? > Exactly this the same question I found as FAQ # 16 (User). But as answer there is only explained that openssl will not serve a bundle. But it is not explained how to set up a bundle - but exactly this I would like to know. To populate OpenSSL's trust-anchor set (which ships empty), you first need to determine the OpenSSL configuration directory, which is reported by (e.g. on my NetBSD system): $ openssl version -d OPENSSLDIR: "/usr/pkg/etc/openssl" OpenSSL looks for certificates at that location, specifically: X509_CERT_DIR OPENSSLDIR "/certs" X509_CERT_FILE OPENSSLDIR "/cert.pem" In other words, you can concatenate all the trusted root CA certs into the "cert.pem" file in that directory, but this has a performance cost, as all the certificates are loaded into memory and parse even though most go unused. Alternatively, you can put one certificate per-file into the "certs/" sub-directory, and run c_rehash, to create the necessary symlinks that it possible for OpenSSL to find the certificate for a given issuer DN. Some O/S distributions automatically populate the above file and/or directory as part of installing OpenSSL, with whatever trust-anchors (root CAs) they think are broadly applicable. OpenSSL upstream does not make that choice. -- Viktor. From ben at an3k.de Sun Dec 13 10:34:34 2015 From: ben at an3k.de (Ben Humpert) Date: Sun, 13 Dec 2015 11:34:34 +0100 Subject: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16) In-Reply-To: <815FB1AE-E35B-4514-BBAC-9FC7FC3EC9F6@dukhovni.org> References: <566C905A.7080709@teddy.ch> <815FB1AE-E35B-4514-BBAC-9FC7FC3EC9F6@dukhovni.org> Message-ID: 2015-12-13 3:53 GMT+01:00 Viktor Dukhovni : > > In other words, you can concatenate all the trusted root CA > certs into the "cert.pem" file in that directory, but this > has a performance cost, as all the certificates are loaded > into memory and parse even though most go unused. Alternatively, The problem with concatenating certs into one file is that at least Windows does not understand that format and just reads the first certificate but ignores all following. From Walter.H at mathemainzel.info Sun Dec 13 12:16:56 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Sun, 13 Dec 2015 13:16:56 +0100 Subject: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16) In-Reply-To: References: <566C905A.7080709@teddy.ch> <815FB1AE-E35B-4514-BBAC-9FC7FC3EC9F6@dukhovni.org> Message-ID: <566D61B8.2000504@mathemainzel.info> On 13.12.2015 11:34, Ben Humpert wrote: > 2015-12-13 3:53 GMT+01:00 Viktor Dukhovni: >> In other words, you can concatenate all the trusted root CA >> certs into the "cert.pem" file in that directory, but this >> has a performance cost, as all the certificates are loaded >> into memory and parse even though most go unused. Alternatively, > The problem with concatenating certs into one file is that at least > Windows does not understand that format and just reads the first > certificate but ignores all following. > then create a pkcs7 container openssl crl2pkcs7 -nocrl -certfile cert1.pem -certfile cert2.pem -certfile cert3.pem -out bundle.p7b -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From bhat.jayalakshmi at gmail.com Sun Dec 13 18:13:42 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Sun, 13 Dec 2015 11:13:42 -0700 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <20151210173317.GL11836@mournblade.imrryr.org> <5669BA1D.8090502@wisemo.com> <5669BAE6.1030204@akamai.com> Message-ID: Hi All, Thanks for all the responses. As mentioned by Matt in the discussion thread,constant_time_msb performs the copy the msb of the input to all of the other bits so the return value should either be one of 0x00000000 or 0xffffffff. I found another interesting thing,constant_time_msb worked as it is without any changes, after I added a printf in constant_time_is_zero_8 test routine to print the return value. I added the printf just before comparing the return value with the expected value. I have confirmed the failures by removing the printf and printing any thing else other than the returned value. Now based on the discussions here and print results I am thinking, after constant_time_msb operation probably overflow bit is set in case of 0xffffffff. And it is not cleared before comparing, hence compare fails. When I add a printf to print the return value probably overflow flag got cleared and things worked. I am planning to attach the debugger to check the flags. I will get back with debugger results. I have attached the test file. Regards Jaya On Fri, Dec 11, 2015 at 11:30 AM, Jeffrey Walton wrote: > > 3. The compiler wasn't written by a fanatic who put > > the "right shift of negative signed values is > > undefined" rule above common sense. > > > > This is only implementation-defined behavior, not undefined behavior. > It is > > not permitted to crash the system or launch the missiles. (n1256.pdf > 6.5.7 > > paragraph 5.) > > The potential problem with implementation defined is its not > guaranteed to produce consistent results. Different compilers or > different versions of the same compiler may arrive at different > results. > > In this light, the crash might be welcomed to make it easy to find the > trouble spot :) > _______________________________________________ > 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: constant_time_test.7z Type: application/octet-stream Size: 1661 bytes Desc: not available URL: From openssl-users at dukhovni.org Sun Dec 13 19:27:40 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 13 Dec 2015 14:27:40 -0500 Subject: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16) In-Reply-To: References: <566C905A.7080709@teddy.ch> <815FB1AE-E35B-4514-BBAC-9FC7FC3EC9F6@dukhovni.org> Message-ID: <5118B2BA-62DD-4C77-9DEA-5AC2BF39B17F@dukhovni.org> > On Dec 13, 2015, at 5:34 AM, Ben Humpert wrote: > > 2015-12-13 3:53 GMT+01:00 Viktor Dukhovni : >> >> In other words, you can concatenate all the trusted root CA >> certs into the "cert.pem" file in that directory, but this >> has a performance cost, as all the certificates are loaded >> into memory and parse even though most go unused. Alternatively, > > > The problem with concatenating certs into one file is that at least > Windows does not understand that format and just reads the first > certificate but ignores all following. This is both wrong and irrelevant. The OP should proceed as instructed. OpenSSL's CAfile feature reads multiple certificates from a single file. -- Viktor. From danbryan80 at gmail.com Sun Dec 13 19:55:34 2015 From: danbryan80 at gmail.com (daniel bryan) Date: Sun, 13 Dec 2015 19:55:34 +0000 Subject: [openssl-users] OCSP service dependant on time valid CRLs In-Reply-To: <2B0F71E7-CDBA-49F1-A56A-F8356BF82035@docusign.com> References: <5669A9CD.109@mathemainzel.info> <2B0F71E7-CDBA-49F1-A56A-F8356BF82035@docusign.com> Message-ID: Thanks Erwann, I appreciate your point regarding the cost of a signing operation. I plan to take action on this. Pointing out RFC 5280 in regards to what status it will return when it fails to download a fresh CRL helped a lot. I now see that revoked is not "a" correct response according to the logic defined in the RFC. I do feel that since a certificate can not be unrevoked (with the exception of "on hold") that if an OCSP service learns that serial #X was once revoked with a reason code of (anything bit on hold), therefor it must still be revoked. Am I wrong in thinking this? Is it more safe to completely disregard an expired CRLs? --Dan On Fri, Dec 11, 2015 at 9:15 AM Erwann Abalea wrote: > Bonjour, > > The problem with signing with a default certificate is that the response > certainly won?t be accepted by the client (see RFC6960 section 4.2.2.2, > this responder certificate doesn?t follow criteria 1 and 2, and certainly > not criteria 3), so you?re performing a signature knowing it will be > rejected by a compliant client. It is also unwise from your side, because > anybody can send a request for free, and as a result you?ll perform a > signature: non negligible CPU cost and the response is larger than the > request. An unsigned error message may be better. > > ? Unknown ? is *a* correct answer in that specific case, not the only > correct one. ? tryLater ? and ? internalError ? are equivalently correct > answers. ? Good ?, ? malformedRequest ?, and ? sigRequired ? are NOT > correct answers. ? unauthorized ? may also be considered a correct answer, > but others may disagree. ? Revoked ? may seem a correct answer also, but > not quite (see below). > The meaning of those different results is explained in RFC6960 and RFC5019. > Of course, if you?re using CRLs as an authoritative source of certificate > status, RFC5280 is to be read also. > > Reading the algorithm described in RFC5280 section 6.3.3 to perform a CRL > validation, you?ll see that: > - at step (a)(1)(ii), you don?t get a newer CRL, so you can?t continue the > algorithm > - after the algorithm, reasons_masks is still the empty set, and > cert_status still has the value UNREVOKED, so the revocation status has NOT > been determined > - last paragraph of 6.3.3 tells you that in the end, if the revocation > status has not been determined, return a cert_status UNDETERMINED. > > An OCSP service based on a CRL, given an expired CRL, running this > normative algorithm, will get a cert_status ? UNDETERMINED ?, and not a > value stating that it?s revoked. Such an OCSP service, responding ? > Revoked ?, wouldn?t be strictly compliant. > > Erwann Abalea > erwann.abalea at docusign.com > > Le 10 d?c. 2015 ? 20:07, socket a ?crit : > > Thanks for chiming in Erwann. This OCSP service is CRL based. The > software I am using has a "default signing certificate". I also have #X CA > specific signing certificates for each CA in our lab PKI. It chooses to use > the default signing certificate for all unknown issuers (like if someone > explicitly queries the service for a microsoft timestamp certificate). > > I appreciate your definitive response regarding that the correct answer > in this situation is to return unknown. I recognize your name as an > authority in pkix, but is this documented anywhere? I would like to be able > to justify to my customer that this is indeed the correct response. > > Also, it seems weird to me that validating this certificate against the > expired CRL returns a status of revoked, but when validating this same > certificate against the OCSP service it says unknown. I guess i just have > to get over that they are different and that a certificate can have a > different status depending on who you ask. > > Looking forward to any follow on thoughts... > > --Dan > > On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] <[hidden > email]> wrote: > > Bonsoir, >> >> The OCSP responder can respond ? unknown ? if it doesn?t know the status >> of the requested certificate. ? Unknown ? can generally not be used when >> the issuer is not known, because such a response is signed, and if the >> responder doesn?t know about the issuer, it can?t choose its own >> certificate to use to sign the response. >> >> If your OCSP responder is CRL based, and the CRL is not valid (badly >> encoded, wrong signature, incomplete in scope, expired, whatever?), >> ? unknown ? is a correct answer. ? revoked ? is also a correct answer if an >> expired CRL is found declaring the requested certificate as revoked. >> ? tryLater ? is also a correct answer, even ? internalError ? if we >> consider the CRL as part of the internal state of the responder. >> >> Erwann Abalea >> [hidden email] >> >> Le 10 d?c. 2015 ? 18:29, socket <[hidden email] >> > a ?crit : >> >> Hi Walter, >> >> I agree with your addition regarding the fact that it is not saying the >> cert is good, it's saying unknown. However, my understanding of the RFC is >> that unknown should be returned when the OCSP service does not know about >> the certificate issuer. I'm not sure that's the case. >> >> Regarding the response verification, we are used the CA Designated >> Responder (Authorized Responder). meaning that the issuer of serial >> 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV). >> However, my testing shows that this only affects the "response verification >> (OK/FAILED)" not the certificate status returned (good/revoked/unknown). >> >> --Dan >> >> >> On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <> target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote: >> >>> Hi Dan, >>> >>> On 10.12.2015 16:27, daniel bryan wrote: >>> >>> *TEST #2: *Next test was using OCSP: >>> >>> [dan at canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile >>> VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert >>> CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080 >>> >>> >>> >>> *Response verify OK CERTS/0x500c8bd-revoked.pem: unknown This Update: >>> Dec 9 20:48:26 2015 GMT* >>> >>> as you can see the client *was NOT *informed the certificate was >>> revoked. >>> >>> and also that it is not good -> unknown, revoked and good are the 3 >>> values ... >>> >>> >>> We are using a 3rd party vendors OCSP service, and I am of the opinion >>> that an OCSP service should provide a revoked response regardless of the >>> time validity of the CRL. >>> >>> does the OCSP responder cert be the signing cert itself or was it signed >>> by the same signing cert that signed the cert you want to validate? >>> >>> or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both >>> CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)? >>> >>> >>> Walter >>> >>> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> >> If you reply to this email, your message will be added to the discussion >> below: >> >> http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61627.html >> > To start a new topic under OpenSSL - User, email [hidden email] >> > To unsubscribe from OpenSSL - User, click here. >> NAML >> >> > ------------------------------ > View this message in context: Re: OCSP service dependant on time valid > CRLs > > Sent from the OpenSSL - User mailing list archive > at Nabble.com. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at an3k.de Sun Dec 13 21:55:08 2015 From: ben at an3k.de (Ben Humpert) Date: Sun, 13 Dec 2015 22:55:08 +0100 Subject: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16) In-Reply-To: <5118B2BA-62DD-4C77-9DEA-5AC2BF39B17F@dukhovni.org> References: <566C905A.7080709@teddy.ch> <815FB1AE-E35B-4514-BBAC-9FC7FC3EC9F6@dukhovni.org> <5118B2BA-62DD-4C77-9DEA-5AC2BF39B17F@dukhovni.org> Message-ID: 2015-12-13 20:27 GMT+01:00 Viktor Dukhovni : > > This is both wrong and irrelevant. The OP should proceed as instructed. > OpenSSL's CAfile feature reads multiple certificates from a single file. Exactly that is the point. Only "linux based" tools will be able to read such a pem file. Windows certificate tools are not able to do so. And we don't know on which client OP will have to use that pem file, thus give advise that works on all clients, not just OpenSSL or GnuTLS or whatever. From rsalz at akamai.com Sun Dec 13 21:57:37 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 13 Dec 2015 21:57:37 +0000 Subject: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16) In-Reply-To: References: <566C905A.7080709@teddy.ch> <815FB1AE-E35B-4514-BBAC-9FC7FC3EC9F6@dukhovni.org> <5118B2BA-62DD-4C77-9DEA-5AC2BF39B17F@dukhovni.org> Message-ID: <1082e877ec82466f80e90ef3f8f311f5@usma1ex-dag1mb1.msg.corp.akamai.com> > And we don't know on which client OP will have to use that pem file, thus > give advise that works on all clients, not just OpenSSL or GnuTLS or whatever. It is quite reasonable to give openssl-specific answers on the openssl-users mailing list, isn?t it? From ben at an3k.de Mon Dec 14 11:39:39 2015 From: ben at an3k.de (Ben Humpert) Date: Mon, 14 Dec 2015 12:39:39 +0100 Subject: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16) In-Reply-To: <1082e877ec82466f80e90ef3f8f311f5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <566C905A.7080709@teddy.ch> <815FB1AE-E35B-4514-BBAC-9FC7FC3EC9F6@dukhovni.org> <5118B2BA-62DD-4C77-9DEA-5AC2BF39B17F@dukhovni.org> <1082e877ec82466f80e90ef3f8f311f5@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: 2015-12-13 22:57 GMT+01:00 Salz, Rich : > >> And we don't know on which client OP will have to use that pem file, thus >> give advise that works on all clients, not just OpenSSL or GnuTLS or whatever. > > It is quite reasonable to give openssl-specific answers on the openssl-users mailing list, isn?t it? All given answers are openssl-specific (OP uses OpenSSL to CREATE the bundle but likely not to READ / USE the created bundle). You are intelligent enough to understand the difference, aren't you? The problem with Viktor Dukhovni is that he acts like THE AUTHORITY; saying all other given answers are wrong (actually none is). Additionally his solution is complicated and only works with OpenSSL. Since Windows, Mac, GnuTLS, OpenSSL, Android, iPhone, etc. understand a pkcs7 container and since nobody knows on what clients the bundle will be used Walter Hs answer is the best solution. You know encryption but obviously not that there is a world beyond OpenSSL. And as I already wrote: If you want to use the bundle on Windows you CANNOT simply concatenate all the certs into one certs.pem because Windows (and various other Operating Systems) does not understand that format. From marquess at openssl.com Mon Dec 14 13:23:39 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 14 Dec 2015 08:23:39 -0500 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses In-Reply-To: <565F1966.7060303@openssl.com> References: <565F1966.7060303@openssl.com> Message-ID: <566EC2DB.5020308@openssl.com> On 12/02/2015 11:16 AM, Steve Marquess wrote: > If you don't know or care what FIPS 140-2 is, be very glad this isn't > your problem and turn your charitable attentions to some worthy cause. > > The CMVP has introduced a new policy that will result in the effective > termination of many extant validations if they are not updated by > January 31 2016[1]. That update is a pure paper shuffle -- adding > politically correct verbiage to the Security Policy document -- but > without it the CMVP will "de-list" the validation. The original OpenSSL > FIPS Object Module validations (#1747, #2398, #2473) and all validations > based on them -- which is a lot of validations -- are affected. > > I'll be doing the labor to prepare the revised Security Policy documents > for all the validations that have been performed by OSF, both the well > known open source based ones and also "private label" ones, and the test > labs for some of those validations are also doing their part pro bono. > However, the test lab we used for the original open source based > validations (#1747, #2398, #2473) is charging $1250 for those three > related validations of the same module. Note this is not unreasonable as > these updates involve a non-trivial amount of work. > > ... I'm pleased to report that this $1250 cost to paper-shuffle the #1747/#2398/#2473 validations has been covered, by Datagravity Inc. Within minutes of hearing of the issue for the first time the the CEO, Paula Long, not only had a check en route to the test lab but also sent a scan of the check and envelope as a heads-up for the lab. It's refreshing to encounter a company, and not a tiny one at that, which can complete the see-decide-act cycle in Internet time, when others would just be warming up for a days or weeks long odyssey through the bowels of an in-house corporate bureaucratic process. In covering this cost Datagravity has not only addressed direct impacts to their business from the threatened de-listing, but has also bailed out the hundreds of commercial vendors and government agencies using those validations. Note it is still possible that those validations may still be briefly de-listed, as the paperwork hasn't been submitted yet. Hopefully that will happen this week, but the CMVP backlog for acting on such submissions is typically several months and the deadline for de-listing is only six weeks away during a time of year when the CMVP tends to move at less than breakneck speed. I do not know for sure that they will defer that when the requisite paperwork is sitting unreviewed in their inbox. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jb-openssl at wisemo.com Mon Dec 14 16:00:10 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 14 Dec 2015 17:00:10 +0100 Subject: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16) In-Reply-To: <566C905A.7080709@teddy.ch> References: <566C905A.7080709@teddy.ch> Message-ID: <566EE78A.9060601@wisemo.com> On 12/12/2015 22:23, Dominik Mahrer (Teddy) wrote: > Hi everyone > > My question is: > How can I set up a bundle of commercial root CA certificates? > Exactly this the same question I found as FAQ # 16 (User). But as > answer there is only explained that openssl will not serve a bundle. > But it is not explained how to set up a bundle - but exactly this I > would like to know. > Returning to the original question (please ignore the silly discussion others are having about file formats). There are the following options: A. (Best, most costly). Set up direct business relationships with each relevant CA and use that business relastionship to obtain both "known good" copies of the applicable root certs *and* detailed written proof that the CA is doing everything necessary to avoid issuing bad/fake certificates. This is what Mozilla, Microsoft and apparently Oracle do. Some major Linux distribution may doing this too. B. (Somewhat lazy). Obtain known good verified and digitally signed copies of the lists of trusted certificates published by a vendor you trust to do this right, extract the certificates from their software and use that. C. Wing it and download the root CA's from the homepages of each CA, taking care that you have some way of making sure you are not getting a fake copy from someone attacking the CA's (or your own) Internet connection. For example, the CA may publish the root cert or a strong fingerprint of it on a HTTPS protected URL whose certificate is itself signed by another CA you already trust. Either way, you then need to convert this bundle of collected CA root certs to a common format and install those converted files in a way supported by the relevant software (for example, OpenSSL 1.0.x can use the hashed directory layout produced by c_rehash from OpenSSL 1.0.x, while OpenSSL 0.9.8 can do the same with the similar but different layout produced by c_rehash from OpenSSL 0.9.8, either OpenSSL version can alternatively use a concatenation of all the certs in PEM format). 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 bhat.jayalakshmi at gmail.com Tue Dec 15 10:53:22 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Tue, 15 Dec 2015 03:53:22 -0700 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <20151210173317.GL11836@mournblade.imrryr.org> <5669BA1D.8090502@wisemo.com> <5669BAE6.1030204@akamai.com> Message-ID: Hi All, 1. With compiler optimization disabled, OpenSSL 1.0.2d function worked as it is. 2. Looks like in the below functions, typecast to unsigned char to is not going well when compiler optimization is enabled. Hence functions are modified to assign the return value to a volatile unsigned char and then return the volatile value. Things worked fine. static inline unsigned char constant_time_lt_8(unsigned int a, unsigned int b) static inline unsigned char constant_time_ge_8(unsigned int a, unsigned int b) static inline unsigned char constant_time_is_zero_8(unsigned int a) static inline unsigned char constant_time_eq_8(unsigned int a, unsigned int b) static inline unsigned char constant_time_eq_int_8(int a, int b) static inline unsigned char constant_time_select_8(unsigned char mask, Matt, Jakob, Andy your explanations were really useful to route cause the issue to compiler specific. Thanks every one for the valuable time and fruitful discussion. Regards Jaya On Sun, Dec 13, 2015 at 11:13 AM, Jayalakshmi bhat < bhat.jayalakshmi at gmail.com> wrote: > Hi All, > > > > Thanks for all the responses. As mentioned by Matt in the discussion > thread,constant_time_msb performs the copy the msb of the input to all of > the other bits so the return value should either be one of 0x00000000 or > 0xffffffff. > > > > I found another interesting thing,constant_time_msb worked as it is > without any changes, after I added a printf in constant_time_is_zero_8 test > routine to print the return value. I added the printf just before comparing > the return value with the expected value. > > > > I have confirmed the failures by removing the printf and printing any > thing else other than the returned value. > > > > Now based on the discussions here and print results I am thinking, after > constant_time_msb operation probably overflow bit is set in case of > 0xffffffff. And it is not cleared before comparing, hence compare fails. > When I add a printf to print the return value probably overflow flag got > cleared and things worked. > > > > I am planning to attach the debugger to check the flags. I will get back > with debugger results. > > > > I have attached the test file. > > > > Regards > > Jaya > > > > On Fri, Dec 11, 2015 at 11:30 AM, Jeffrey Walton > wrote: > >> > 3. The compiler wasn't written by a fanatic who put >> > the "right shift of negative signed values is >> > undefined" rule above common sense. >> > >> > This is only implementation-defined behavior, not undefined behavior. >> It is >> > not permitted to crash the system or launch the missiles. (n1256.pdf >> 6.5.7 >> > paragraph 5.) >> >> The potential problem with implementation defined is its not >> guaranteed to produce consistent results. Different compilers or >> different versions of the same compiler may arrive at different >> results. >> >> In this light, the crash might be welcomed to make it easy to find the >> trouble spot :) >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Tue Dec 15 13:56:08 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 15 Dec 2015 16:56:08 +0300 Subject: [openssl-users] Engines mess Message-ID: Hello, Could you explain the engine management in the openssl 1.0.2e? I load an engine via openssl config specifying the path using the dynamic_path directive and provide some engine-specific directives. When I call the dgst command dgst -sha1 -engine myengine -keyform engine -sign mykey -out signature I see that the ENGINE_free function is not called after the setup_engine() call from line 220 of dgst.c. It's the 4th call to the ENGINE_free function, there was a call to ENGINE_free for my engine and 2 calls to ENGINE_free to the dynamic engine. Here I get the fields struct_ref = 4, funct_ref = 3, and it seems strange to me. It also seems to me that it should be a call to ENGINE_free at the end of openssl app call to free the resources (e.g. engine error strings), but there is no one. Could you explain my mistakes? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Tue Dec 15 16:02:56 2015 From: appro at openssl.org (Andy Polyakov) Date: Tue, 15 Dec 2015 17:02:56 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <20151210173317.GL11836@mournblade.imrryr.org> <5669BA1D.8090502@wisemo.com> <5669BAE6.1030204@akamai.com> Message-ID: <567039B0.2080200@openssl.org> > 1. With compiler optimization disabled, OpenSSL 1.0.2d function worked > as it is. Another indication in favour of compiler bug is that it worked when you added printf. It's similar to quantum physics when by measuring you force particle to specific state. But understand me correctly. I'm not saying that quantum physics apply in this case, it's just a *fun* way to look at it. As compiler doesn't know what printf does, it's forced to normalize value for "measurement". Same essentially applies to volatilization. I mean variables declared volatile are meant for *external* consumption/"measurement". From jlbrown at bordo.com.au Wed Dec 16 00:31:49 2015 From: jlbrown at bordo.com.au (James Brown) Date: Wed, 16 Dec 2015 11:31:49 +1100 Subject: [openssl-users] Errors building 1.0.2e on Mac OS X 10.7.5 Message-ID: <8E96DC36-BA84-4559-8DDE-E4ED583044F3@bordo.com.au> I know the OS is a bit old, but thought I?d better upgrade OpenSSL on it in now. To configure I used: ./Configure --prefix=/usr/local shared darwin64-x86_64-cc Running make gives lots of errors like this: cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o md5-x86_64.o md5-x86_64.s ar r ../../libcrypto.a md5_dgst.o md5_one.o md5-x86_64.o /usr/bin/ranlib: file: ../../libcrypto.a(ebcdic.o) has no symbols /usr/bin/ranlib: file: ../../libcrypto.a(fips_ers.o) has no symbols /usr/bin/ranlib ../../libcrypto.a || echo Never mind. /usr/bin/ranlib: file: ../../libcrypto.a(ebcdic.o) has no symbols /usr/bin/ranlib: file: ../../libcrypto.a(fips_ers.o) has no symbols making all in crypto/sha? before ending: x86_64-mont.s:957:2: error: invalid instruction mnemonic 'adoxq' adoxq %r15,%r10 ^~~~~ x86_64-mont.s:959:2: error: invalid instruction mnemonic 'adcxq' adcxq %rax,%r10 ^~~~~ x86_64-mont.s:960:2: error: invalid instruction mnemonic 'adoxq' adoxq %r15,%r11 ^~~~~ x86_64-mont.s:962:2: error: invalid instruction mnemonic 'adcxq' adcxq %rax,%r11 ^~~~~ x86_64-mont.s:963:2: error: invalid instruction mnemonic 'adoxq' adoxq %r15,%r12 ^~~~~ x86_64-mont.s:966:2: error: invalid instruction mnemonic 'adcxq' adcxq %rax,%r12 ^~~~~ x86_64-mont.s:967:2: error: invalid instruction mnemonic 'adoxq' adoxq %r15,%r13 ^~~~~ x86_64-mont.s:972:2: error: invalid instruction mnemonic 'adcxq' adcxq %rax,%r13 ^~~~~ x86_64-mont.s:973:2: error: invalid instruction mnemonic 'adoxq' adoxq %rbp,%r15 ^~~~~ make[2]: *** [x86_64-mont.o] Error 1 make[1]: *** [subdirs] Error 1 make: *** [build_crypto] Error 1 This worked with 1.0.1 versions. Any suggestions? Thanks, James. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3630 bytes Desc: not available URL: From martin at black-sheep-research.com Wed Dec 16 18:23:25 2015 From: martin at black-sheep-research.com (Martin Brampton) Date: Wed, 16 Dec 2015 18:23:25 +0000 Subject: [openssl-users] Find size of available data prior to ssl_read Message-ID: <5671AC1D.8000100@black-sheep-research.com> Is there a way to obtain the amount of data available to be read? I'm working with a system that operates in non-blocking mode using epoll. When an EPOLLIN event is received the aim is to read the data. For the non-SSL case, the amount of data can be obtained using ioctl FIONREAD. This is used to malloc a suitable sized buffer, followed by read the data into the buffer. How should the SSL version of our code work? At present it is using the sum of the number obtained from ioctl FIONREAD (which seems suspect when SSL is in use and appears to be always too large) and the number from ssl_pending (which seems to be zero). The buffer then has to be truncated. Can this approach work? Could it be improved? Or is there some fundamental problem with operating in this way? From Michael.Wojcik at microfocus.com Wed Dec 16 20:00:39 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 16 Dec 2015 20:00:39 +0000 Subject: [openssl-users] Find size of available data prior to ssl_read In-Reply-To: <5671AC1D.8000100@black-sheep-research.com> References: <5671AC1D.8000100@black-sheep-research.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Martin Brampton > Sent: Wednesday, December 16, 2015 13:23 > > Is there a way to obtain the amount of data available to be read? > > I'm working with a system that operates in non-blocking mode using > epoll. When an EPOLLIN event is received the aim is to read the data. > For the non-SSL case, the amount of data can be obtained using ioctl > FIONREAD. This is used to malloc a suitable sized buffer, followed by > read the data into the buffer. > > How should the SSL version of our code work? At present it is using the > sum of the number obtained from ioctl FIONREAD (which seems suspect > when > SSL is in use and appears to be always too large) and the number from > ssl_pending (which seems to be zero). The buffer then has to be truncated. TCP is a stream service. It may deliver (to the application, which in this case means to OpenSSL) part of an SSL/TLS record, a single complete record, multiple records... In some situations, you may reliably receive one TLS record at a time. You can't assume that will be the general case, particularly for application protocols that aren't simple alternating request-response pairs, or over long network paths, or with large blocks of application data, or if the recipient's stack is squeezed for resources. FIONREAD will show the amount of data available from the stack. SSL_pending will show the amount of application data from complete records OpenSSL has already received and processed that the application has not read from OpenSSL yet. Per above, the former can represent less than one record to multiple records and possibly a partial one at the end. The latter may well not be zero, for example if the peer does multiple sends, or sends a block of data large enough that it gets chunked into multiple TLS records; then OpenSSL may read data from the stack and get multiple complete records, in which case SSL_pending will be > 0. Note that nothing in the OpenSSL API gives you the number of bytes of a partial record that OpenSSL has received from the stack. Even in the ideal case where exactly a single TLS record is sitting in the stack's buffers, FIONREAD will be larger than the size of the application data, because it's a TLS record, which has non-zero overhead. Specifically it has a header containing type, version, and length, and a footer with MAC and padding. The application only gets the application data, so it must get fewer than FIONREAD bytes. Unless I'm forgetting something, since Open SSL will only deliver application data to the caller, and only from a complete record, then: - If, when the application obtains the values from FIONREAD + ssl_pending (call this sum N), at least one complete TLS record has been received by the stack and not read by the application, then the amount of data the application gets from SSL_read will be strictly less than N - Otherwise, in the case where the application gets those values too early, N will be less than the size of the record OpenSSL will eventually assemble, the amount of application data *may* be greater than, equal to (unlikely), or less than N. In this case there's simply no way for the application to know. > Can this approach work? No. OpenSSL doesn't know how much data is in a TLS record until it's processed it, and it doesn't know that until it has the complete record. (It could assume the record is valid before it has the complete record and look at the length field, but it doesn't know how long the padding is until it has the very last byte. And assuming the record is valid is a Bad Idea.) Consequently, your application can't know that either. Looking at the amount of data buffered by the stack is pointless, for the reasons discussed above. > Could it be improved? Or is there some > fundamental problem with operating in this way? The fundamental problem is that you don't know how much data is going to be available from whatever complete records OpenSSL has received, and you don't even know that OpenSSL has received a complete record. The sender could be dribbling data to you one byte at a time. (This would be perverse, but what if some MITM is mucking about with your window announcements? Note those are at the TCP protocol level and so are not protected by TLS.) You might want to look at something like this: - Use non-blocking sockets. When you get a POLLIN event, try SSL_read with a small fixed buffer. If it returns SSL_WANT_READ, you don't have a complete record yet. - Set the read-ahead flag with SSL_CTX_set_read_ahead (before creating your SSL objects), so that OpenSSL will grab all available data off the wire when you call SSL_read; that will reduce useless POLLIN events. - When you have a successful SSL_read, use SSL_pending to get the number of application-data bytes remaining. Allocate a buffer of fixed-small-buffer-size + value-from-SSL_pending. Copy in the small fixed buffer, then SSL_read into the tail of the allocated buffer. - If SSL_read returns SSL_WANT_READ, loop back to poll. The call to SSL_read (with read-ahead set in the SSL object via the context) should have grabbed the available data from the socket, so the socket will no longer be readable unless something else has arrived in the meantime. Disclaimer: I haven't tried this. -- Michael Wojcik Technology Specialist, Micro Focus From kurt at roeckx.be Thu Dec 17 00:00:45 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 17 Dec 2015 01:00:45 +0100 Subject: [openssl-users] Find size of available data prior to ssl_read In-Reply-To: <5671AC1D.8000100@black-sheep-research.com> References: <5671AC1D.8000100@black-sheep-research.com> Message-ID: <20151217000044.GA21397@roeckx.be> On Wed, Dec 16, 2015 at 06:23:25PM +0000, Martin Brampton wrote: > Is there a way to obtain the amount of data available to be read? > > I'm working with a system that operates in non-blocking mode using epoll. > When an EPOLLIN event is received the aim is to read the data. For the > non-SSL case, the amount of data can be obtained using ioctl FIONREAD. This > is used to malloc a suitable sized buffer, followed by read the data into > the buffer. > > How should the SSL version of our code work? At present it is using the sum > of the number obtained from ioctl FIONREAD (which seems suspect when SSL is > in use and appears to be always too large) and the number from ssl_pending > (which seems to be zero). The buffer then has to be truncated. Please note that SSL_pending() returns the data about already processed / decrypted TLS records. If the record is not complete it's not processed and we won't tell how big it is. This means that it's possible for SSL_pending() to return 0 and that receiving a single byte for the kernel might make the whole packet available. If you then go and only read 1 byte, calling SSL_pending() will actually tell you how many other bytes are still has available for you that already passed all the checks. So the library can have unprocessed bytes from a TLS record in it's internal buffer, but it's not going to tell you much about it. SSL / TLS also has overhead, the data might also not even be application data. Also, some ciphers work in blocks so there might be added padding for those blocks. So there are various reasons why you might receive less data too. If you always call SSL_read() on the boundaries of the records you'll always get less data, but there is really no way for you to see that. It might be that in your application this is always what happens, but I wouldn't rely on it. If you don't call in on the boundaries there is little you can predict about the size you're going to get. Kurt From rsalz at akamai.com Thu Dec 17 09:28:28 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 17 Dec 2015 09:28:28 +0000 Subject: [openssl-users] Changing malloc/debug stuff Message-ID: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> I want to change the memory alloc/debug things. Right now there are several undocumented functions to allow you to swap-out the malloc/realloc/free routines, wrappers that call those routines, debug versions of those wrappers, and functions to set the set-options versions of those functions. Yes, really :) Is anyone using that stuff? I want to change the model so that there are three wrappers around malloc/realloc/free, and that the only thing you can do is change that wrapper. This is vastly simpler and easier to understand. I also documented it. A version can be found at https://github.com/openssl/openssl/pull/450 I've posted about this before. But I'm asking again if this kind of change will cause problems for anyone. Thanks. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at black-sheep-research.com Thu Dec 17 09:36:40 2015 From: martin at black-sheep-research.com (counterpoint) Date: Thu, 17 Dec 2015 02:36:40 -0700 (MST) Subject: [openssl-users] Find size of available data prior to ssl_read In-Reply-To: <20151217000044.GA21397@roeckx.be> References: <5671AC1D.8000100@black-sheep-research.com> <20151217000044.GA21397@roeckx.be> Message-ID: <1450345000336-61733.post@n7.nabble.com> Thanks to Michael and Kurt for explanatory comments. Is there an available setting that gives the upper limit on the amount of data that will be obtained by a single ssl_read()? The data stream is SQL requests, and often these are quite small, but they can run to megabytes. I need to malloc a buffer for the data. If it is too small, that will impose extra processing overheads in the rest of the system. If it is too large, it will impose memory wastage on the rest of the system. The system has an upper limit of 32 KB on the initial size of a buffer for reading, but that is way above the typical SQL request. So, accepting that I can't set the size precisely, if there is a limit for SSL data reads that is significantly lower than 32 KB then that might be a feasible fixed buffer size. If that isn't possible, maybe it will have to be a tunable configuration value. Any comments? -- View this message in context: http://openssl.6102.n7.nabble.com/Find-size-of-available-data-prior-to-ssl-read-tp61722p61733.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From martin at black-sheep-research.com Thu Dec 17 09:51:16 2015 From: martin at black-sheep-research.com (counterpoint) Date: Thu, 17 Dec 2015 02:51:16 -0700 (MST) Subject: [openssl-users] Find size of available data prior to ssl_read In-Reply-To: <1450345000336-61733.post@n7.nabble.com> References: <5671AC1D.8000100@black-sheep-research.com> <20151217000044.GA21397@roeckx.be> <1450345000336-61733.post@n7.nabble.com> Message-ID: <1450345876971-61734.post@n7.nabble.com> Although maybe the simple answer is to read into a temporary 32 KB buffer and then malloc and copy. -- View this message in context: http://openssl.6102.n7.nabble.com/Find-size-of-available-data-prior-to-ssl-read-tp61722p61734.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From jb-openssl at wisemo.com Thu Dec 17 15:55:12 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 17 Dec 2015 16:55:12 +0100 Subject: [openssl-users] Changing malloc/debug stuff In-Reply-To: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <5672DAE0.3010202@wisemo.com> On 17/12/2015 10:28, Salz, Rich wrote: > > I want to change the memory alloc/debug things. > > Right now there are several undocumented functions to allow you to > swap-out the malloc/realloc/free routines, wrappers that call those > routines, debug versions of those wrappers, and functions to set the > set-options versions of those functions. Yes, really J Is anyone > using that stuff? > > I want to change the model so that there are three wrappers around > malloc/realloc/free, and that the only thing you can do is change that > wrapper. This is vastly simpler and easier to understand. I also > documented it. A version can be found at > https://github.com/openssl/openssl/pull/450 > > I?ve posted about this before. But I?m asking again if this kind of > change will cause problems for anyone. > I don't need it so I don't object. But if anyone objects, you could write a compatibility module that can be called to use the new interface to change in a compatible variant of the old wrappers, which would then provide the old hooks/facilities when needed while staying out of the way (not even being linked into static programs) for the rest of us. I guess this is because that interface is not a part of a commercial grade full featured SSL/TLS and general purpose crypto library, it is just a means to do quality assurance on said library. Enjoy and Merry Christmas Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From Michael.Wojcik at microfocus.com Thu Dec 17 16:03:17 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 17 Dec 2015 16:03:17 +0000 Subject: [openssl-users] Find size of available data prior to ssl_read In-Reply-To: <1450345876971-61734.post@n7.nabble.com> References: <5671AC1D.8000100@black-sheep-research.com> <20151217000044.GA21397@roeckx.be> <1450345000336-61733.post@n7.nabble.com> <1450345876971-61734.post@n7.nabble.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of counterpoint > Sent: Thursday, December 17, 2015 04:51 > > Although maybe the simple answer is to read into a temporary 32 KB buffer and > then malloc and copy. That, more or less, was my recommendation in my previous post. The optimal size of the temporary buffer depends on factors we don't know. If most of your messages fit in 32KB, then that may save you extra calls to SSL_read. On the other hand, it could mean excessive copying - it might be better to use a smaller buffer to reduce the size of the additional copy operation, even at the cost of an extra call to SSL_read. (Obviously some copying is happening in the SSL/TLS processing anyway, and the cost of such copying is small relative to the cost of decryption and other compute-intensive operations. But if your application deals with a high transaction rate then cutting down that extra copy may be worthwhile anyway.) If your application is single-threaded, you can make that a static buffer; if not, it needs to go on the stack, which could be a problem if your threads are stack-constrained. That's another argument (if it applies to your case) for using a smaller initial buffer. If the first chunk of your message tells you how large the entire message will be, then this approach means only one call to the allocator per message received, which is good. And it means the same code path for every message regardless of size, which is good for program correctness and maintainability. Based on what you've told us, this is the approach I'd recommend. The only question is the size of that initial buffer, and you're in a better position to determine that. -- Michael Wojcik Technology Specialist, Micro Focus From jb-openssl at wisemo.com Thu Dec 17 16:05:26 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 17 Dec 2015 17:05:26 +0100 Subject: [openssl-users] Find size of available data prior to ssl_read In-Reply-To: <1450345000336-61733.post@n7.nabble.com> References: <5671AC1D.8000100@black-sheep-research.com> <20151217000044.GA21397@roeckx.be> <1450345000336-61733.post@n7.nabble.com> Message-ID: <5672DD46.4000202@wisemo.com> On 17/12/2015 10:36, counterpoint wrote: > Thanks to Michael and Kurt for explanatory comments. > > Is there an available setting that gives the upper limit on the amount of > data that will be obtained by a single ssl_read()? > > The data stream is SQL requests, and often these are quite small, but they > can run to megabytes. I need to malloc a buffer for the data. If it is too > small, that will impose extra processing overheads in the rest of the > system. If it is too large, it will impose memory wastage on the rest of the > system. The system has an upper limit of 32 KB on the initial size of a > buffer for reading, but that is way above the typical SQL request. > > So, accepting that I can't set the size precisely, if there is a limit for > SSL data reads that is significantly lower than 32 KB then that might be a > feasible fixed buffer size. If that isn't possible, maybe it will have to > be a tunable configuration value. Any comments? The current SSL/TLS standards limits the per record data size to 16K exactly, see for example RFC5246 section 6.2.1. However the data you want in your (higher level) code probably has a completely different natural size limit/unit which may be larger and smaller. For SQL there is no natural limit however, unless your SQL parser happens to fail on statements above some arbitrary size. Enjoy and Merry Christmas 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at black-sheep-research.com Thu Dec 17 16:35:13 2015 From: martin at black-sheep-research.com (counterpoint) Date: Thu, 17 Dec 2015 09:35:13 -0700 (MST) Subject: [openssl-users] Find size of available data prior to ssl_read In-Reply-To: References: <5671AC1D.8000100@black-sheep-research.com> <20151217000044.GA21397@roeckx.be> <1450345000336-61733.post@n7.nabble.com> <1450345876971-61734.post@n7.nabble.com> Message-ID: <1450370113228-61741.post@n7.nabble.com> Thanks, that makes sense. My ability to optimise is constrained - the system is a product so I do not know what the actual pattern of usage will be. But there is a limit on buffer size within the system. It's a defined symbol, so can be altered from the default of 32 KB, but only by recompiling the system. I rely on a working assumption that people who change definitions and recompile know what they're doing. The system is threaded, but it is designed to operate with a relatively small number of highly active threads, so grabbing 32 KB on the stack for a short period shouldn't be too much of an issue. It would be much harder to figure out the actual message size because the calls to SSL are taking place in a generic core, whereas the protocol is in a different layer of code. There are ways it could be done, but I'm inclined to leave that for a future optimisation. That leaves me feeling that the fixed buffer on the stack is the cleanest solution, involving simple code. The copying overhead is there, but looks hard to eliminate, and as you say there is plenty of other overhead. I'm not sure that the small initial buffer offers me much gain, although it might help in some situations. (Personally I'm inclined to use SSH tunnels rather than SSL for SQL traffic, but that's another story!). One remaining point leaves me uncertain. Supposing an SSL write gets the response SSL_ERROR_WANT_READ. Then there is a POLLIN event. I take it the first thing that must happen is a retry of the write. Assuming that works, do I need to assume that there could be data to be read? Or will a further event occur, so that I should return to looking out for events? I guess the answer to the last question is probably no, but am unsure. -- View this message in context: http://openssl.6102.n7.nabble.com/Find-size-of-available-data-prior-to-ssl-read-tp61722p61741.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From Michael.Wojcik at microfocus.com Thu Dec 17 18:00:45 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 17 Dec 2015 18:00:45 +0000 Subject: [openssl-users] Find size of available data prior to ssl_read In-Reply-To: <1450370113228-61741.post@n7.nabble.com> References: <5671AC1D.8000100@black-sheep-research.com> <20151217000044.GA21397@roeckx.be> <1450345000336-61733.post@n7.nabble.com> <1450345876971-61734.post@n7.nabble.com> <1450370113228-61741.post@n7.nabble.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of counterpoint > Sent: Thursday, December 17, 2015 11:35 > > Thanks, that makes sense. My ability to optimise is constrained - the system > is a product so I do not know what the actual pattern of usage will be. But > there is a limit on buffer size within the system. It's a defined symbol, so > can be altered from the default of 32 KB, but only by recompiling the > system. I rely on a working assumption that people who change definitions > and recompile know what they're doing. Fair enough. > The system is threaded, but it is designed to operate with a relatively > small number of highly active threads, so grabbing 32 KB on the stack for a > short period shouldn't be too much of an issue. It's not really a matter of how many threads there are (except indirectly), or of how long the item is on the stack. It's a question of how much space is available on the thread's stack when you try to allocate the buffer (which, assuming we're talking C or C++, is when you enter the function / method). A thread's stack size is typically set at creation time, with a default that may be fixed in the threading implementation or set at link time. How much space is available when you allocate that 32 KB buffer depends on how deep your call chain is and how much data each of those frames adds to the stack. If the stack is too small to accommodate the buffer and can't be expanded, you'll get some kind of run-time failure, like a Windows exception or a UNIX signal. Note that stack space is an address-space resource, not (generally) a virtual memory one - that is, stack-space is unlikely to be constrained because the system is running short on virtual memory. It'll happen because most language implementations use contiguous stacks for performance (rather than, say, displays or other non-contiguous structures), and if the stack runs into something else in the process address space, it can't grow any further. So if your process is 64-bit, you should be able to specify ridiculously large thread stacks and not worry about it. If the process is 32-bit, take a look at your thread stack sizes and do a quick estimate on how much space you expect will be there. You can determine this for a specific thread, in a specific run, in a debugger by looking at the address of an automatic variable at the bottom of the thread's stack (in the thread's initial function) and the address of one in your data-receiving function. (Technically comparing those addresses isn't authorized by the language standard, but it's valid on most of the platforms OpenSSL supports.) So I'd say try it in some test runs and see if it looks like stack space might be getting tight; if so, you can likely increase the stack size you specify when creating your threads, since you don't have many of them. > One remaining point leaves me uncertain. Supposing an SSL write gets the > response SSL_ERROR_WANT_READ. Then there is a POLLIN event. I take it > the > first thing that must happen is a retry of the write. Assuming that works, > do I need to assume that there could be data to be read? Or will a further > event occur, so that I should return to looking out for events? I guess the > answer to the last question is probably no, but am unsure. There could be data to be read. Consider this scenario: 1. The peer decides it wants to renegotiate during the conversation. 2. In the middle of the handshake, you call SSL_write. The handshake hasn't completed, and the local side is waiting for a message from the peer, so SSL_write returns SSL_ERROR_WANT_READ. 3. You wait for POLLIN, then call SSL_write again. 4. Before SSL_write returns, the peer has time to respond to the request you just sent. Or it sends something else immediately after completing the handshake, if your application doesn't use a strict switched-duplex request-response protocol. So I'd recommend going ahead and trying a non-blocking SSL_read at that point. The overhead is tiny and you won't miss any inbound-data events. -- Michael Wojcik Technology Specialist, Micro Focus From rsalz at akamai.com Thu Dec 17 18:03:27 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 17 Dec 2015 18:03:27 +0000 Subject: [openssl-users] Changing malloc/debug stuff In-Reply-To: <5672DAE0.3010202@wisemo.com> References: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> <5672DAE0.3010202@wisemo.com> Message-ID: > I don't need it so I don't object. But if anyone objects, you could write a ... Good point! > I guess this is because that interface is not a part of a commercial grade full > featured SSL/TLS and general purpose crypto library, it is just a means to do > quality assurance on said library. That seems to be the main usage, yes. I think it had more uses in the early days such as on old windows/msdos? > Enjoy and Merry Christmas And a happy new year. Or bah, humbug :) /r$ From jb-openssl at wisemo.com Thu Dec 17 18:23:37 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 17 Dec 2015 19:23:37 +0100 Subject: [openssl-users] Changing malloc/debug stuff In-Reply-To: References: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> <5672DAE0.3010202@wisemo.com> Message-ID: <5672FDA9.1080702@wisemo.com> On 17/12/2015 19:03, Salz, Rich wrote: >> I don't need it so I don't object. But if anyone objects, you could write a ... > Good point! > >> I guess this is because that interface is not a part of a commercial grade full >> featured SSL/TLS and general purpose crypto library, it is just a means to do >> quality assurance on said library. > That seems to be the main usage, yes. I think it had more uses in the early days such as on old windows/msdos? Old Windows/msdos was the most widespread platform where the compiler provided malloc/free tended to be crap and had to be overridden in a compiler specific way to make it work reasonably. Note that this was a *compiler* specific issue and tended to depend on both the brand, version and sometimes even command line options of the compiler. However even for Win16, MS-DOS and OS/2 16-bit, the ability to redirect all memory calls through a user provided set of malloc/free/realloc/msize functions would do the job. The hard part was writing those override functions, even with a your copies of TAOCP and K&R (2nd ed) handy. A completely different use for special memory allocation work would be to take advantage of algorithm specific knowledge to optimize allocation and system call patterns, such as keeping all the small allocations for a decoded X.509 certificate or all the intermediaries for an RSA calculation together. Enjoy and Merry Christmas 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at black-sheep-research.com Thu Dec 17 17:42:22 2015 From: martin at black-sheep-research.com (counterpoint) Date: Thu, 17 Dec 2015 10:42:22 -0700 (MST) Subject: [openssl-users] Find size of available data prior to ssl_read In-Reply-To: References: <5671AC1D.8000100@black-sheep-research.com> <20151217000044.GA21397@roeckx.be> <1450345000336-61733.post@n7.nabble.com> <1450345876971-61734.post@n7.nabble.com> <1450370113228-61741.post@n7.nabble.com> Message-ID: <1450374142939-61746.post@n7.nabble.com> Thanks, very helpful. We only support 64 bit. -- View this message in context: http://openssl.6102.n7.nabble.com/Find-size-of-available-data-prior-to-ssl-read-tp61722p61746.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rsalz at akamai.com Thu Dec 17 20:16:50 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 17 Dec 2015 20:16:50 +0000 Subject: [openssl-users] [openssl-dev] Changing malloc/debug stuff In-Reply-To: <20151217201341.GL8156@localhost> References: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> <20151217201341.GL8156@localhost> Message-ID: <21fa57e661474b2ca5cb81b8072295a5@usma1ex-dag1mb1.msg.corp.akamai.com> > > https://github.com/openssl/openssl/pull/450 > > This seems much more sane. I'll settle for less insane :) From jonetsu at teksavvy.com Thu Dec 17 21:26:21 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Thu, 17 Dec 2015 16:26:21 -0500 Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 Message-ID: Hello, I have read about the use of?FIPS_rsa_x931_generate_key_ex() for 186-4 compliance. ?We are using OpenSSL 1.0.1e with the?fips-2.0.9 module. ? ?Would it make functional sense using those versions to patch?RSA_generate_key_ex() (../crypto/rsa/rsa_gen.c) to have:? #ifdef OPENSSL_FIPS if (FIPS_mode()) ? ? return FIPS_rsa_x931_generate_key_ex(rsa, bits, e_value, cb); #endif Instead of using?FIPS_rsa_generate_key_ex() (and also adding the prototype for?FIPS_rsa_x931_generate_key_ex() earlier in rsa_gen.c) Thanks. From meissner at suse.de Thu Dec 17 21:35:41 2015 From: meissner at suse.de (Marcus Meissner) Date: Thu, 17 Dec 2015 22:35:41 +0100 Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 In-Reply-To: References: Message-ID: <20151217213541.GK26314@suse.de> On Thu, Dec 17, 2015 at 04:26:21PM -0500, jonetsu wrote: > Hello, > > > I have read about the use of?FIPS_rsa_x931_generate_key_ex() for 186-4 compliance. ?We are using OpenSSL 1.0.1e with the?fips-2.0.9 module. ? ?Would it make functional sense using those versions to patch?RSA_generate_key_ex() (../crypto/rsa/rsa_gen.c) to have:? > > > #ifdef OPENSSL_FIPS > if (FIPS_mode()) > ? ? return FIPS_rsa_x931_generate_key_ex(rsa, bits, e_value, cb); > #endif > > > Instead of using?FIPS_rsa_generate_key_ex() > > > (and also adding the prototype for?FIPS_rsa_x931_generate_key_ex() earlier in rsa_gen.c) I do not think this x931 RSA key generation is 186-4 compliant. Ciao, Marcus From nico at cryptonector.com Thu Dec 17 22:37:56 2015 From: nico at cryptonector.com (Nico Williams) Date: Thu, 17 Dec 2015 16:37:56 -0600 Subject: [openssl-users] [openssl-dev] Changing malloc/debug stuff In-Reply-To: <21fa57e661474b2ca5cb81b8072295a5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> <20151217201341.GL8156@localhost> <21fa57e661474b2ca5cb81b8072295a5@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20151217223755.GM8156@localhost> On Thu, Dec 17, 2015 at 08:16:50PM +0000, Salz, Rich wrote: > > > https://github.com/openssl/openssl/pull/450 > > > > This seems much more sane. > > I'll settle for less insane :) That is, I think, the best you can do. Some allocations might have taken place by the time a wrapper or alternative allocator is installed, in which case something bad will happen. In the case of alternative allocators the something bad is "it blows up", while in the case of a wrapper the something bad is "some state/whatever will be off". A fully sane approach would be to have every allocated object internally point to its destructor, and then always destroy by calling that destructor instead of a global one. (Or call a global one that knows how to find the object's private destructor pointer, and then calls that.) If you wish, something more OO-ish. But for many allocations that's not possible because they aren't "objects" in the sense that matters. You could always wrap allocations so that they always have room at the front for the corresponding destructor, then return the offset of the end of that pointer, but this will be very heavy-duty for many allocations. So, all in all, I like and prefer your approach. Nico -- From alex.william21 at outlook.com Fri Dec 18 06:00:01 2015 From: alex.william21 at outlook.com (Alex william) Date: Fri, 18 Dec 2015 10:00:01 +0400 Subject: [openssl-users] Segfault in libcrypto.so Message-ID: Hello, I have been trying to install a product named wanguard and each time am starting a collector I receive this error message: segfault at efe000 ip 00007ffb571e479c sp 00007ffced00dcf0 error 4 in libcrypto.so.1.0.0[7ffb57166000+1cb000] And the collector stops immediately. Has anyone encountered this error or can someone help please? Thanks. Regards, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico at cryptonector.com Thu Dec 17 20:13:43 2015 From: nico at cryptonector.com (Nico Williams) Date: Thu, 17 Dec 2015 14:13:43 -0600 Subject: [openssl-users] Changing malloc/debug stuff In-Reply-To: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20151217201341.GL8156@localhost> On Thu, Dec 17, 2015 at 09:28:28AM +0000, Salz, Rich wrote: > I want to change the memory alloc/debug things. > > Right now there are several undocumented functions to allow you to > swap-out the malloc/realloc/free routines, wrappers that call those > routines, debug versions of those wrappers, and functions to set the > set-options versions of those functions. Yes, really :) Is anyone > using that stuff? This is another one of those things that isn't easy to deal with sanely the way OpenSSL is actually used (i.e., by other libraries as well as by apps). > I want to change the model so that there are three wrappers around > malloc/realloc/free, and that the only thing you can do is change that > wrapper. This is vastly simpler and easier to understand. I also > documented it. A version can be found at > https://github.com/openssl/openssl/pull/450 This seems much more sane. Nico -- From kgoldman at us.ibm.com Fri Dec 18 14:22:04 2015 From: kgoldman at us.ibm.com (Ken Goldman) Date: Fri, 18 Dec 2015 09:22:04 -0500 Subject: [openssl-users] Segfault in libcrypto.so In-Reply-To: References: Message-ID: On 12/18/2015 1:00 AM, Alex william wrote: > I receive this error message: > segfault at efe000 ip 00007ffb571e479c sp 00007ffced00dcf0 error 4 in > libcrypto.so.1.0.0[7ffb57166000+1cb000] > And the collector stops immediately. > > Has anyone encountered this error or can someone help please? In my experience, when a working program begins to segfault, it's usually that it was built with one version of openssl but is linking with a different version. You may even have two versions of openssl installed. Try cleaning up you openssl install as needed, and then rebuilding the program. From jonetsu at teksavvy.com Fri Dec 18 16:03:17 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 18 Dec 2015 09:03:17 -0700 (MST) Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 In-Reply-To: <20151217213541.GK26314@suse.de> References: <20151217213541.GK26314@suse.de> Message-ID: <1450454597628-61769.post@n7.nabble.com> Is there any current solution to have RSA 186-4 in OpenSSL FIPS (now, even if this means an upgrade ?) Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-and-FIPS-186-4-in-OpenSSL-1-0-1e-fips-2-0-9-tp61753p61769.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From marquess at openssl.com Fri Dec 18 17:25:36 2015 From: marquess at openssl.com (Steve Marquess) Date: Fri, 18 Dec 2015 12:25:36 -0500 Subject: [openssl-users] OpenSSL FIPS Object Module 2.011 approved Message-ID: <56744190.9040903@openssl.com> The 2.0.11 revision of the OpenSSL FIPS Object Module v2.0 has been approved: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2398 Note that this is the same module as for the #1747 and #2374 validations; the proliferation of validation numbers is due to the "hostage" situation[1]. The 2.0.11 revision introduces support for eleven new platforms. It will build and execute correctly for any platforms supported by the 2.0.10 or earlier revisions of that module, for either the #1747 or #2473 validations, but a module built from the 2.0.11 tarball will not be righteous for any platform not listed in the #2398 validation. Even though that module will be functionally identical; yes that's confusing as we now have multiple flavors of magical pixie dust. So the rule of thumb is use the 2.0.11 tarball only for the platforms listed with the #2398 validation, even though it will work for any of the platforms included with any of the validations. Use the 2.0.10 tarball for everything else. Note this latest validation update does not address the "X9.31 RNG transition"; that paperwork is pending at the test lab for the OpenSSL FIPS module and its three validations (#1747, #2398, #2473). -Steve M. [1] For masochists only: http://openssl.com/fips/aftermath.html -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marquess at openssl.com Fri Dec 18 17:28:32 2015 From: marquess at openssl.com (Steve Marquess) Date: Fri, 18 Dec 2015 12:28:32 -0500 Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 In-Reply-To: <1450454597628-61769.post@n7.nabble.com> References: <20151217213541.GK26314@suse.de> <1450454597628-61769.post@n7.nabble.com> Message-ID: <56744240.1030704@openssl.com> On 12/18/2015 11:03 AM, jonetsu wrote: > Is there any current solution to have RSA 186-4 in OpenSSL FIPS (now, even if > this means an upgrade ?) We aren't allowed to update existing validations to include that type of "cryptographically significant" change, just like we aren't allowed to fix vulnerabilities (e.g. Lucky 13). So no. We will address all new FIPS 140-2 requirements, and known vulnerabilities, and support of OpenSSL 1.1, if and when we're in a position to pursue a new open source based validation to succeed the current #1747/#2398/#2473. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jonetsu at teksavvy.com Fri Dec 18 17:21:13 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 18 Dec 2015 10:21:13 -0700 (MST) Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 In-Reply-To: <56744240.1030704@openssl.com> References: <20151217213541.GK26314@suse.de> <1450454597628-61769.post@n7.nabble.com> <56744240.1030704@openssl.com> Message-ID: <1450459273948-61772.post@n7.nabble.com> What would then be the permitting conditions to pursue a new validation ? If you don't mind me asking. I have read several notes you have on the subject and I agree that the whole thing is of Dedalus proportions. In a nutshell what would be these conditions ? Thanks, much appreciated. -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-and-FIPS-186-4-in-OpenSSL-1-0-1e-fips-2-0-9-tp61753p61772.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rsalz at akamai.com Fri Dec 18 18:10:43 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 18 Dec 2015 18:10:43 +0000 Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 In-Reply-To: <1450459273948-61772.post@n7.nabble.com> References: <20151217213541.GK26314@suse.de> <1450454597628-61769.post@n7.nabble.com> <56744240.1030704@openssl.com> <1450459273948-61772.post@n7.nabble.com> Message-ID: <269627c543524b50ae6528aa3a1efdd4@usma1ex-dag1mb1.msg.corp.akamai.com> > What would then be the permitting conditions to pursue a new validation ? > If you don't mind me asking. I have read several notes you have on the > subject and I agree that the whole thing is of Dedalus proportions. In a > nutshell what would be these conditions ? In a nutshell: someone willing to spend the money (low six figures) without adding requirements that violates the spirit of our open source philosophy, and while knowing that the project might fail for non-technical reasons. From jonetsu at teksavvy.com Fri Dec 18 17:27:20 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 18 Dec 2015 10:27:20 -0700 (MST) Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 In-Reply-To: <56744240.1030704@openssl.com> References: <20151217213541.GK26314@suse.de> <1450454597628-61769.post@n7.nabble.com> <56744240.1030704@openssl.com> Message-ID: <1450459640184-61774.post@n7.nabble.com> Sorry, I forgot: What about the code itself, if we do not mind the validation ? Is the 185-4 RSA compatible code present in any OpenSSL/FIPS module ? -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-and-FIPS-186-4-in-OpenSSL-1-0-1e-fips-2-0-9-tp61753p61774.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From marquess at openssl.com Fri Dec 18 18:21:36 2015 From: marquess at openssl.com (Steve Marquess) Date: Fri, 18 Dec 2015 13:21:36 -0500 Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 In-Reply-To: <269627c543524b50ae6528aa3a1efdd4@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151217213541.GK26314@suse.de> <1450454597628-61769.post@n7.nabble.com> <56744240.1030704@openssl.com> <1450459273948-61772.post@n7.nabble.com> <269627c543524b50ae6528aa3a1efdd4@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <56744EB0.1070801@openssl.com> On 12/18/2015 01:10 PM, Salz, Rich wrote: >> What would then be the permitting conditions to pursue a new >> validation ? If you don't mind me asking. I have read several >> notes you have on the subject and I agree that the whole thing is >> of Dedalus proportions. In a nutshell what would be these >> conditions ? > > In a nutshell: someone willing to spend the money (low six figures) > without adding requirements that violates the spirit of our open > source philosophy, and while knowing that the project might fail for > non-technical reasons. I'll also note that each of the previous five open source based validations had one or more U.S. government sponsors with an interest in a successful outcome. I believe that interest, expressed and exercised in ways I was not fully privy to, was the key element in those successful outcomes. We will undertake another tilt a the windmill with the prerequisites Rich noted above, but I think a successful outcome for the sixth such validation will also require the engagement of politically adept stakeholders. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jonetsu at teksavvy.com Fri Dec 18 17:58:40 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 18 Dec 2015 10:58:40 -0700 (MST) Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 In-Reply-To: <56744EB0.1070801@openssl.com> References: <20151217213541.GK26314@suse.de> <1450454597628-61769.post@n7.nabble.com> <56744240.1030704@openssl.com> <1450459273948-61772.post@n7.nabble.com> <269627c543524b50ae6528aa3a1efdd4@usma1ex-dag1mb1.msg.corp.akamai.com> <56744EB0.1070801@openssl.com> Message-ID: <1450461520618-61776.post@n7.nabble.com> Fair enough (in this context). But what about the code itself, is it ready to be RSA 186-4 compliant ? And, if we go through a validation, can OpenSSL benefit from it ? -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-and-FIPS-186-4-in-OpenSSL-1-0-1e-fips-2-0-9-tp61753p61776.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From marquess at openssl.com Fri Dec 18 18:58:52 2015 From: marquess at openssl.com (Steve Marquess) Date: Fri, 18 Dec 2015 13:58:52 -0500 Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 In-Reply-To: <1450461520618-61776.post@n7.nabble.com> References: <20151217213541.GK26314@suse.de> <1450454597628-61769.post@n7.nabble.com> <56744240.1030704@openssl.com> <1450459273948-61772.post@n7.nabble.com> <269627c543524b50ae6528aa3a1efdd4@usma1ex-dag1mb1.msg.corp.akamai.com> <56744EB0.1070801@openssl.com> <1450461520618-61776.post@n7.nabble.com> Message-ID: <5674576C.9060405@openssl.com> On 12/18/2015 12:58 PM, jonetsu wrote: > Fair enough (in this context). But what about the code itself, is it ready > to be RSA 186-4 compliant ? We think we know how to write the code that would be necessary, for FIPS 186-4 and all the other new requirements, though you can never be sure until *your* specific module has been formally validated. Given the capriciousness of the FIPS 140-2 validation process, which I've commented on frequently, the fact that someone else did something in *their* validation doesn't necessarily mean a lot for *your* validation. But, without an open source based validation in which such code would have any general utility, we see no point in writing FIPS specific code. We're not in the business of doing speculative software development. > > And, if we go through a validation, can OpenSSL benefit from it ? By "we" do you mean some sort of proprietary commercial validation? Those don't contribute at all to the availability of a no-cost open source validated module; code is worthless (even "open source" code) for the purposes of satisfying the USG/DoD FIPS 140-2 procurement requirements if it hasn't been sprinkled with the magical pixie dust of FIPS 140-2 validation. Writing the code isn't trivial, but that has never been the hard part... -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From aerowolf at gmail.com Fri Dec 18 21:13:43 2015 From: aerowolf at gmail.com (Kyle Hamilton) Date: Fri, 18 Dec 2015 13:13:43 -0800 Subject: [openssl-users] Segfault in libcrypto.so In-Reply-To: References: Message-ID: <56747707.9040109@gmail.com> I think you would probably do better to contact support for wanguard than for openssl. Possible issues could involve ABI incompatibility or library selection incompatibility; since there's no way for us to know how wanguard is structured (we can't track every product that uses openssl), they're more familiar with its error modes and how to work through them. -Kyle H On 12/17/2015 10:00 PM, Alex william wrote: > Hello, > > I have been trying to install a product named wanguard and each time > am starting a collector I receive this error message: > segfault at efe000 ip 00007ffb571e479c sp 00007ffced00dcf0 error 4 in > libcrypto.so.1.0.0[7ffb57166000+1cb000] > And the collector stops immediately. > > Has anyone encountered this error or can someone help please? > > Thanks. > > Regards, > Alex > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcosbontempo at hotmail.com Sat Dec 19 12:20:39 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Sat, 19 Dec 2015 10:20:39 -0200 Subject: [openssl-users] FIPS 140-2 library Message-ID: Hello, I'm using the OpenSSL FIPS object module and I have to program a C code that sets FIPS 140-2 level 3. Is there a function in the C library that sets it? How can I set the FIPS protected directory, so I can store my private key? Any tip will be very helpful,Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Sat Dec 19 12:40:44 2015 From: marquess at openssl.com (Steve Marquess) Date: Sat, 19 Dec 2015 07:40:44 -0500 Subject: [openssl-users] FIPS 140-2 library In-Reply-To: References: Message-ID: <5675504C.8050600@openssl.com> On 12/19/2015 07:20 AM, Marcos Bontempo wrote: > Hello, > > I'm using the OpenSSL FIPS object module and I have to program a C code > that sets FIPS 140-2 level 3. Is there a function in the C library that > sets it? How can I set the FIPS protected directory, so I can store my > private key? > > Any tip will be very helpful, > Thanks. > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > Are you referring to a "FIPS 140-2 Level 3" validation?: https://en.wikipedia.org/wiki/FIPS_140-2#Level_3 The OpenSSL FIPS Object Module v.20 validations are Level 1, as is the case with all software-only validations. The higher level validations are much more closely tied to specific hardware devices. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marcosbontempo at hotmail.com Sat Dec 19 13:19:38 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Sat, 19 Dec 2015 11:19:38 -0200 Subject: [openssl-users] FIPS 140-2 library In-Reply-To: <5675504C.8050600@openssl.com> References: , <5675504C.8050600@openssl.com> Message-ID: Thanks for the quick answer! And about specifying a FIPS protected directory, is there a function in the C library? I need to save my private key in a FIPS protected directory. > To: openssl-users at openssl.org > From: marquess at openssl.com > Date: Sat, 19 Dec 2015 07:40:44 -0500 > Subject: Re: [openssl-users] FIPS 140-2 library > > On 12/19/2015 07:20 AM, Marcos Bontempo wrote: > > Hello, > > > > I'm using the OpenSSL FIPS object module and I have to program a C code > > that sets FIPS 140-2 level 3. Is there a function in the C library that > > sets it? How can I set the FIPS protected directory, so I can store my > > private key? > > > > Any tip will be very helpful, > > Thanks. > > > > > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > Are you referring to a "FIPS 140-2 Level 3" validation?: > > https://en.wikipedia.org/wiki/FIPS_140-2#Level_3 > > The OpenSSL FIPS Object Module v.20 validations are Level 1, as is the > case with all software-only validations. The higher level validations > are much more closely tied to specific hardware devices. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Sat Dec 19 13:22:47 2015 From: marquess at openssl.com (Steve Marquess) Date: Sat, 19 Dec 2015 08:22:47 -0500 Subject: [openssl-users] FIPS 140-2 library In-Reply-To: References: <5675504C.8050600@openssl.com> Message-ID: <56755A27.2040705@openssl.com> On 12/19/2015 08:19 AM, Marcos Bontempo wrote: > Thanks for the quick answer! And about specifying a FIPS protected > directory, is there a function in the C library? I need to save my > private key in a FIPS protected directory. I have no idea what the term "FIPS protected directory" means. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marcosbontempo at hotmail.com Sat Dec 19 13:28:37 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Sat, 19 Dec 2015 11:28:37 -0200 Subject: [openssl-users] FIPS 140-2 library In-Reply-To: <56755A27.2040705@openssl.com> References: , <5675504C.8050600@openssl.com> ,<56755A27.2040705@openssl.com> Message-ID: I want to exclude the private key if there is an attempt to violation. Has FIPS this functionality? > To: openssl-users at openssl.org > From: marquess at openssl.com > Date: Sat, 19 Dec 2015 08:22:47 -0500 > Subject: Re: [openssl-users] FIPS 140-2 library > > On 12/19/2015 08:19 AM, Marcos Bontempo wrote: > > Thanks for the quick answer! And about specifying a FIPS protected > > directory, is there a function in the C library? I need to save my > > private key in a FIPS protected directory. > > I have no idea what the term "FIPS protected directory" means. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Sat Dec 19 13:56:22 2015 From: marquess at openssl.com (Steve Marquess) Date: Sat, 19 Dec 2015 08:56:22 -0500 Subject: [openssl-users] FIPS 140-2 library In-Reply-To: References: <5675504C.8050600@openssl.com> <56755A27.2040705@openssl.com> Message-ID: <56756206.5070804@openssl.com> On 12/19/2015 08:28 AM, Marcos Bontempo wrote: > I want to exclude the private key if there is an attempt to violation. > Has FIPS this functionality? I think you have some misconceptions about what FIPS 140-2 is and isn't. It is "magical pixie dust", not a technique or some specific type of functionality. FIPS 140-2 validation is a paper intensive formal process by which specific implementations (software and/or devices) are given an official government blessing (the "pixie dust"). FIPS 140-2 validated products are *not* more secure or better, by any real-world metric, than equivalent non-validated products. In fact they are rather manifestly *less* secure, in the sense of resistance to malicious or accidental compromise. You can't do anything with FIPS 140-2 validated products you can do without, except for the entirely non-technical objective of satisfying formal policy requirements. So if you aren't forced to use validated products, just ask "how can I do X securely" and leave FIPS 140-2 out of it. If you do need validated products, then that requirement drives and constrains your choices and real-world security is a secondary consideration, instead you must ask "is there a validated product available that will allow X"? You can't code your way to FIPS 140-2 validated status, you have to find and use something that is already validated. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marcosbontempo at hotmail.com Sat Dec 19 14:23:21 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Sat, 19 Dec 2015 12:23:21 -0200 Subject: [openssl-users] FIPS 140-2 library In-Reply-To: <56756206.5070804@openssl.com> References: , <5675504C.8050600@openssl.com> ,<56755A27.2040705@openssl.com> , <56756206.5070804@openssl.com> Message-ID: Thanks for the help! I really have misconceptions about FIPS 140-2. I was instructed to compile and install this module: http://openssl.com/fips/. But I cannot understand how can I use it. Can you explain its functionalities? Sorry for the dummie questions. > To: openssl-users at openssl.org > From: marquess at openssl.com > Date: Sat, 19 Dec 2015 08:56:22 -0500 > Subject: Re: [openssl-users] FIPS 140-2 library > > On 12/19/2015 08:28 AM, Marcos Bontempo wrote: > > I want to exclude the private key if there is an attempt to violation. > > Has FIPS this functionality? > > I think you have some misconceptions about what FIPS 140-2 is and isn't. > It is "magical pixie dust", not a technique or some specific type of > functionality. > > FIPS 140-2 validation is a paper intensive formal process by which > specific implementations (software and/or devices) are given an official > government blessing (the "pixie dust"). > > FIPS 140-2 validated products are *not* more secure or better, by any > real-world metric, than equivalent non-validated products. In fact they > are rather manifestly *less* secure, in the sense of resistance to > malicious or accidental compromise. You can't do anything with FIPS > 140-2 validated products you can do without, except for the entirely > non-technical objective of satisfying formal policy requirements. > > So if you aren't forced to use validated products, just ask "how can I > do X securely" and leave FIPS 140-2 out of it. If you do need validated > products, then that requirement drives and constrains your choices and > real-world security is a secondary consideration, instead you must ask > "is there a validated product available that will allow X"? You can't > code your way to FIPS 140-2 validated status, you have to find and use > something that is already validated. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > 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 Sat Dec 19 14:29:33 2015 From: matt at openssl.org (Matt Caswell) Date: Sat, 19 Dec 2015 14:29:33 +0000 Subject: [openssl-users] FIPS 140-2 library In-Reply-To: References: <5675504C.8050600@openssl.com> <56755A27.2040705@openssl.com> <56756206.5070804@openssl.com> Message-ID: <567569CD.6070505@openssl.org> On 19/12/15 14:23, Marcos Bontempo wrote: > Thanks for the help! I really have misconceptions about FIPS 140-2. I > was instructed to compile and install this module: > http://openssl.com/fips/. But I cannot understand how can I use it. Can > you explain its functionalities? Sorry for the dummie questions. Start by reading the user guide available here: https://openssl.org/docs/fips/UserGuide-2.0.pdf Matt From martin at black-sheep-research.com Sat Dec 19 15:00:05 2015 From: martin at black-sheep-research.com (counterpoint) Date: Sat, 19 Dec 2015 08:00:05 -0700 (MST) Subject: [openssl-users] Problem with not knowing how much data is available to read Message-ID: <1450537205095-61790.post@n7.nabble.com> This is a further question, related to my earlier question "Find size of available data prior to ssl_read". The conclusion seemed to be that there isn't a reliable way to know how much data can be requested with ssl_read. I guess there's still something wrong with my understanding. My code now reads data into a fixed sized buffer, and keeps reading until no data is received. But the problem is, the last read gets an SSL_ERROR_WANT_READ error. That seems to imply that I can't do any more reads or writes until the read is successfully retried, but being prevented from writing will block the system because the client is expecting a reply (which has to be written) before sending anything more for me to read. Do I really need to suppress writes while waiting for a retry of a read that encountered SSL_ERROR_WANT_READ, or is that a misunderstanding on my part? (In many cases, I can tell there is no more data because the value returned by ssl_read is less than the size of the buffer. But there must be the case when the data received exactly fills the buffer, and then it is only by reading again that I discover there is no more data). -- View this message in context: http://openssl.6102.n7.nabble.com/Problem-with-not-knowing-how-much-data-is-available-to-read-tp61790.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From sugu.ece28 at gmail.com Sun Dec 20 13:38:55 2015 From: sugu.ece28 at gmail.com (suguacl28) Date: Sun, 20 Dec 2015 06:38:55 -0700 (MST) Subject: [openssl-users] Need to store RSA Structure in Sqlite database Message-ID: <1450618735243-61793.post@n7.nabble.com> Hi, I am new to openssl. In my developement i need to store the RSA Public and Private keys into sqlite database. For storing a RSA public and private keys, i need to convert it into to buffer and when i need them again buffer to PEM form i am planning to store the generated RSA struct directly into sqlite database as a buffer. Is it Possible??? Please help me. -- View this message in context: http://openssl.6102.n7.nabble.com/Need-to-store-RSA-Structure-in-Sqlite-database-tp61793.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rsalz at akamai.com Sun Dec 20 15:01:36 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 20 Dec 2015 15:01:36 +0000 Subject: [openssl-users] Need to store RSA Structure in Sqlite database In-Reply-To: <1450618735243-61793.post@n7.nabble.com> References: <1450618735243-61793.post@n7.nabble.com> Message-ID: > I am new to openssl. In my developement i need to store the RSA Public and > Private keys into sqlite database. Convert to DER and then perhaps base-64 encode it. From marcosbontempo at hotmail.com Sun Dec 20 16:47:29 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Sun, 20 Dec 2015 14:47:29 -0200 Subject: [openssl-users] undefined reference to `FIPS_mode' Message-ID: Hello, I'm programming an application that only gets and sets FIPS mode. Here is my Makefile: -------------------------------------------------------------------------------------------------------------------------------------------TOOLCHAIN:=/home/marcos/work/nitere/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin:$PATHCROSS_COMPILE:=arm-linux-gnueabihf- OPENSSLDIR = /usr/local/ssl#INCLUDES = -I$(OPENSSLDIR)/include -I$(OPENSSLDIR)/fips-2.0/include -I$(OPENSSLDIR)/libINCLUDES = -I$(OPENSSLDIR)/include -I$(OPENSSLDIR)/fips-2.0/includeLIBS= -Lcrypto PATH:=${TOOLCHAIN}:${PATH} all: ${CROSS_COMPILE}gcc fipsctl.c -o fipsctl $(INCLUDES) $(LIBS) clean: rm -Rf *.o fipsctl------------------------------------------------------------------------------------------------------------------------------------------- And here is my code: -------------------------------------------------------------------------------------------------------------------------------------------#include #include int main ( int argc, char *argv[] ){ if(argv[0] == "get") { int mode = FIPS_mode(); if(mode == 0) { printf("*** FIPS module is disabled. ***"); } if(mode == 1) { printf("*** FIPS module is enabled. ***"); } } else if(argv[0] == "set") { printf("*** Enabling FIPS module. ***"); } else { printf("*** Error: unsupported option. ***"); }} ------------------------------------------------------------------------------------------------------------------------------------------- When I try to cross-compile, I get this error: marcos at marcos-X450LD:~/work/nitere/app/nitere$ makearm-linux-gnueabihf-gcc fipsctl.c -o fipsctl -I/usr/local/ssl/include -I/usr/local/ssl/fips-2.0/include -Lcrypto/tmp/ccSQhRme.o: In function `main':fipsctl.c:(.text+0x1a): undefined reference to `FIPS_mode'collect2: error: ld returned 1 exit statusmake: *** [all] Error 1 Does anybody know why I'm getting this error? Any tip will be very helpful,Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahodardev at gmail.com Mon Dec 21 00:18:12 2015 From: mahodardev at gmail.com (Mahoda Ratnayaka) Date: Mon, 21 Dec 2015 13:18:12 +1300 Subject: [openssl-users] Trouble compiling openssl with no-tsl Message-ID: Hi, I'm using openssl version 1.0.2d, and I'm trying to compile it with no-tls options. Unfortunately, every time I try to do this, I get the following error messages: openssl: In file included from s2_meth.c:59:0: openssl: ssl_locl.h:567:5: error: unknown type name ?custom_ext_add_cb? openssl: ssl_locl.h:568:5: error: unknown type name ?custom_ext_free_cb? openssl: ssl_locl.h:570:5: error: unknown type name ?custom_ext_parse_cb? Has anyone encountered this error or can someone help please? Thanks, Mahoda -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.william21 at outlook.com Mon Dec 21 05:28:02 2015 From: alex.william21 at outlook.com (Alex william) Date: Mon, 21 Dec 2015 09:28:02 +0400 Subject: [openssl-users] Segfault in libcrypto.so In-Reply-To: <56747707.9040109@gmail.com> References: <56747707.9040109@gmail.com> Message-ID: Hello Kyle, Thanks for your reply. Well will let them check it out. Regards, Kaviraj De : openssl-users on behalf of Kyle Hamilton R?pondre ? : Date : Saturday, 19 December 2015 at 01:13 ? : Objet : Re: [openssl-users] Segfault in libcrypto.so I think you would probably do better to contact support for wanguard than for openssl. Possible issues could involve ABI incompatibility or library selection incompatibility; since there's no way for us to know how wanguard is structured (we can't track every product that uses openssl), they're more familiar with its error modes and how to work through them. -Kyle H On 12/17/2015 10:00 PM, Alex william wrote: > > Hello, > > > > > I have been trying to install a product named wanguard and each time am > starting a collector I receive this error message: > > segfault at efe000 ip 00007ffb571e479c sp 00007ffced00dcf0 error 4 in > libcrypto.so.1.0.0[7ffb57166000+1cb000] > > And the collector stops immediately. > > > > > Has anyone encountered this error or can someone help please? > > > > > Thanks. > > > > > Regards, > > Alex > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Dec 21 12:06:33 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 21 Dec 2015 13:06:33 +0100 Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 In-Reply-To: <5674576C.9060405@openssl.com> References: <20151217213541.GK26314@suse.de> <1450454597628-61769.post@n7.nabble.com> <56744240.1030704@openssl.com> <1450459273948-61772.post@n7.nabble.com> <269627c543524b50ae6528aa3a1efdd4@usma1ex-dag1mb1.msg.corp.akamai.com> <56744EB0.1070801@openssl.com> <1450461520618-61776.post@n7.nabble.com> <5674576C.9060405@openssl.com> Message-ID: <5677EB49.1050304@wisemo.com> On 18/12/2015 19:58, Steve Marquess wrote: > On 12/18/2015 12:58 PM, jonetsu wrote: >> Fair enough (in this context). But what about the code itself, is it ready >> to be RSA 186-4 compliant ? > We think we know how to write the code that would be necessary, for FIPS > 186-4 and all the other new requirements, though you can never be sure > until *your* specific module has been formally validated. Given the > capriciousness of the FIPS 140-2 validation process, which I've > commented on frequently, the fact that someone else did something in > *their* validation doesn't necessarily mean a lot for *your* validation. > > But, without an open source based validation in which such code would > have any general utility, we see no point in writing FIPS specific code. > We're not in the business of doing speculative software development. > >> And, if we go through a validation, can OpenSSL benefit from it ? > By "we" do you mean some sort of proprietary commercial validation? > Those don't contribute at all to the availability of a no-cost open > source validated module; code is worthless (even "open source" code) for > the purposes of satisfying the USG/DoD FIPS 140-2 procurement > requirements if it hasn't been sprinkled with the magical pixie dust of > FIPS 140-2 validation. > > Writing the code isn't trivial, but that has never been the hard part... Maybe he is asking that if "they" contribute the code, could this ease the (non-bureaucratic) work that OpenSSL would need to do for that future "version 3" FIPS module? Enjoy and Merry Christmas 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 marcosbontempo at hotmail.com Mon Dec 21 12:31:15 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Mon, 21 Dec 2015 10:31:15 -0200 Subject: [openssl-users] undefined reference to `FIPS_mode' In-Reply-To: References: Message-ID: Hello, I resolved the error after compiling FIPS with ./config fips shared. I also needed to export LD_LIBRARY_PATH=/usr/local/ssl/lib:$LD_LIBRARY_PATH. Now I have a new problem. I executed this code to set the FIPS mode and no error is prompted: result = FIPS_mode_set(1); if(result != 1) { ERR_load_crypto_strings(); printf("*** Failed to enable FIPS module. ***\n"); printf("%s\n", ERR_error_string(ERR_get_error(), NULL)); } But when I check the FIPS mode I still get mode 0. mode = FIPS_mode(); if(mode == 0) { printf("*** FIPS module is disabled. ***\n"); } if(mode == 1) { printf("*** FIPS module is enabled. ***\n"); } When I execute the code as sudo, I get this error: error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported Does anybody know why it is happening? Thanks. From: marcosbontempo at hotmail.com To: openssl-users at openssl.org Date: Sun, 20 Dec 2015 14:47:29 -0200 Subject: [openssl-users] undefined reference to `FIPS_mode' Hello, I'm programming an application that only gets and sets FIPS mode. Here is my Makefile: -------------------------------------------------------------------------------------------------------------------------------------------TOOLCHAIN:=/home/marcos/work/nitere/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin:$PATHCROSS_COMPILE:=arm-linux-gnueabihf- OPENSSLDIR = /usr/local/ssl#INCLUDES = -I$(OPENSSLDIR)/include -I$(OPENSSLDIR)/fips-2.0/include -I$(OPENSSLDIR)/libINCLUDES = -I$(OPENSSLDIR)/include -I$(OPENSSLDIR)/fips-2.0/includeLIBS= -Lcrypto PATH:=${TOOLCHAIN}:${PATH} all: ${CROSS_COMPILE}gcc fipsctl.c -o fipsctl $(INCLUDES) $(LIBS) clean: rm -Rf *.o fipsctl------------------------------------------------------------------------------------------------------------------------------------------- And here is my code: -------------------------------------------------------------------------------------------------------------------------------------------#include #include int main ( int argc, char *argv[] ){ if(argv[0] == "get") { int mode = FIPS_mode(); if(mode == 0) { printf("*** FIPS module is disabled. ***"); } if(mode == 1) { printf("*** FIPS module is enabled. ***"); } } else if(argv[0] == "set") { printf("*** Enabling FIPS module. ***"); } else { printf("*** Error: unsupported option. ***"); }} ------------------------------------------------------------------------------------------------------------------------------------------- When I try to cross-compile, I get this error: marcos at marcos-X450LD:~/work/nitere/app/nitere$ makearm-linux-gnueabihf-gcc fipsctl.c -o fipsctl -I/usr/local/ssl/include -I/usr/local/ssl/fips-2.0/include -Lcrypto/tmp/ccSQhRme.o: In function `main':fipsctl.c:(.text+0x1a): undefined reference to `FIPS_mode'collect2: error: ld returned 1 exit statusmake: *** [all] Error 1 Does anybody know why I'm getting this error? Any tip will be very helpful,Thanks. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Mon Dec 21 13:18:55 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 21 Dec 2015 08:18:55 -0500 Subject: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9 In-Reply-To: <5677EB49.1050304@wisemo.com> References: <20151217213541.GK26314@suse.de> <1450454597628-61769.post@n7.nabble.com> <56744240.1030704@openssl.com> <1450459273948-61772.post@n7.nabble.com> <269627c543524b50ae6528aa3a1efdd4@usma1ex-dag1mb1.msg.corp.akamai.com> <56744EB0.1070801@openssl.com> <1450461520618-61776.post@n7.nabble.com> <5674576C.9060405@openssl.com> <5677EB49.1050304@wisemo.com> Message-ID: <5677FC3F.6010104@openssl.com> On 12/21/2015 07:06 AM, Jakob Bohm wrote: > On 18/12/2015 19:58, Steve Marquess wrote: >> On 12/18/2015 12:58 PM, jonetsu wrote: >>> Fair enough (in this context). But what about the code itself, is it >>> ready >>> to be RSA 186-4 compliant ? >> We think we know how to write the code that would be necessary, for FIPS >> 186-4 and all the other new requirements, though you can never be sure >> until *your* specific module has been formally validated. Given the >> capriciousness of the FIPS 140-2 validation process, which I've >> commented on frequently, the fact that someone else did something in >> *their* validation doesn't necessarily mean a lot for *your* validation. >> >> But, without an open source based validation in which such code would >> have any general utility, we see no point in writing FIPS specific code. >> We're not in the business of doing speculative software development. >> >>> And, if we go through a validation, can OpenSSL benefit from it ? >> By "we" do you mean some sort of proprietary commercial validation? >> Those don't contribute at all to the availability of a no-cost open >> source validated module; code is worthless (even "open source" code) for >> the purposes of satisfying the USG/DoD FIPS 140-2 procurement >> requirements if it hasn't been sprinkled with the magical pixie dust of >> FIPS 140-2 validation. >> >> Writing the code isn't trivial, but that has never been the hard part... > Maybe he is asking that if "they" contribute the code, could this > ease the (non-bureaucratic) work that OpenSSL would need to do for > that future "version 3" FIPS module? No, because my colleagues have very specific and detailed ideas on how the new FIPS specific code would be implemented; as with many contributions the effort of adapting a third party contribution would be as much or more work than writing it from scratch. Availability of code isn't the obstacle here. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marquess at openssl.com Mon Dec 21 13:20:47 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 21 Dec 2015 08:20:47 -0500 Subject: [openssl-users] undefined reference to `FIPS_mode' In-Reply-To: References: Message-ID: <5677FCAF.1060600@openssl.com> On 12/21/2015 07:31 AM, Marcos Bontempo wrote: > Hello, > > I resolved the error after compiling FIPS with ./config fips shared. I > also needed to export LD_LIBRARY_PATH=/usr/local/ssl/lib:$LD_LIBRARY_PATH. > > Now I have a new problem. > > I executed this code to set the FIPS mode and no error is prompted: > > result = FIPS_mode_set(1); > if(result != 1) > { > ERR_load_crypto_strings(); > printf("*** Failed to enable FIPS module. ***\n"); > printf("%s\n", ERR_error_string(ERR_get_error(), NULL)); > } > > But when I check the FIPS mode I still get mode 0. > > mode = FIPS_mode(); > if(mode == 0) > { > printf("*** FIPS module is disabled. ***\n"); > } > if(mode == 1) > { > printf("*** FIPS module is enabled. ***\n"); > } > > When I execute the code as sudo, I get this error: > > error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not > supported Your specific platform isn't supported. The OpenSSL FIPS module doesn't run on as many platforms as OpenSSL proper. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marcosbontempo at hotmail.com Mon Dec 21 13:39:25 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Mon, 21 Dec 2015 11:39:25 -0200 Subject: [openssl-users] undefined reference to `FIPS_mode' In-Reply-To: <5677FCAF.1060600@openssl.com> References: , , <5677FCAF.1060600@openssl.com> Message-ID: I did the tests in a Ubuntu 14.04. Is there a problem with this version? > To: openssl-users at openssl.org > From: marquess at openssl.com > Date: Mon, 21 Dec 2015 08:20:47 -0500 > Subject: Re: [openssl-users] undefined reference to `FIPS_mode' > > On 12/21/2015 07:31 AM, Marcos Bontempo wrote: > > Hello, > > > > I resolved the error after compiling FIPS with ./config fips shared. I > > also needed to export LD_LIBRARY_PATH=/usr/local/ssl/lib:$LD_LIBRARY_PATH. > > > > Now I have a new problem. > > > > I executed this code to set the FIPS mode and no error is prompted: > > > > result = FIPS_mode_set(1); > > if(result != 1) > > { > > ERR_load_crypto_strings(); > > printf("*** Failed to enable FIPS module. ***\n"); > > printf("%s\n", ERR_error_string(ERR_get_error(), NULL)); > > } > > > > But when I check the FIPS mode I still get mode 0. > > > > mode = FIPS_mode(); > > if(mode == 0) > > { > > printf("*** FIPS module is disabled. ***\n"); > > } > > if(mode == 1) > > { > > printf("*** FIPS module is enabled. ***\n"); > > } > > > > When I execute the code as sudo, I get this error: > > > > error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not > > supported > > Your specific platform isn't supported. The OpenSSL FIPS module doesn't > run on as many platforms as OpenSSL proper. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Mon Dec 21 14:06:01 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 21 Dec 2015 09:06:01 -0500 Subject: [openssl-users] undefined reference to `FIPS_mode' In-Reply-To: References: <5677FCAF.1060600@openssl.com> Message-ID: <56780749.9040400@openssl.com> On 12/21/2015 08:39 AM, Marcos Bontempo wrote: > I did the tests in a Ubuntu 14.04. Is there a problem with this version? You're cross compiling ... to what target platform I don't know. That target platform is what needs to be supported, and both the FIPS module and "FIPS enabled" OpenSSL need to be built for that target platform, not the build system. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From Michael.Wojcik at microfocus.com Mon Dec 21 14:07:50 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 21 Dec 2015 14:07:50 +0000 Subject: [openssl-users] Problem with not knowing how much data is available to read In-Reply-To: <1450537205095-61790.post@n7.nabble.com> References: <1450537205095-61790.post@n7.nabble.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of counterpoint > Sent: Saturday, December 19, 2015 10:00 > > This is a further question, related to my earlier question "Find size of > available data prior to ssl_read". The conclusion seemed to be that there > isn't a reliable way to know how much data can be requested with ssl_read. > > I guess there's still something wrong with my understanding. My code now > reads data into a fixed sized buffer, and keeps reading until no data is > received. But the problem is, the last read gets an SSL_ERROR_WANT_READ > error. That seems to imply that I can't do any more reads or writes until > the read is successfully retried, but being prevented from writing will > block the system because the client is expecting a reply (which has to be > written) before sending anything more for me to read. Do I really need to > suppress writes while waiting for a retry of a read that encountered > SSL_ERROR_WANT_READ, or is that a misunderstanding on my part? Not as I understand it. An SSL_ERROR_WANT_READ from SSL_read means that SSL_read can't return any more application data until the socket is readable (and possibly not then, but that's what's obstructing SSL_read at this point). Go ahead and call SSL_write if you have data to send. What happens then depends on various factors: - If SSL_read returned SSL_ERROR_WANT_READ because it doesn't have a complete TLS record, or because it's given you all the application data from all the TLS records it's seen so far, then that's irrelevant to SSL_write. TCP is full-duplex, and so is TLS, provided the conversation is in the appropriate state (not negotiating or in error). Nothing says you can't write while you're waiting to read. SSL_write may still fail at this point, of course. You might get SSL_ERROR_WANT_WRITE from it, if the peer has advertised a zero window (i.e. it's not read to receive at the stack level). Or there might be communications errors. - If SSL_read returned SSL_ERROR_WANT_READ because your TLS connection is in the middle of renegotiation and you're waiting for data from the peer, then SSL_write will also return SSL_ERROR_WANT READ. However, in that case OpenSSL is NOT waiting for application data; it's waiting for TLS negotiation, which doesn't involve your application (modulo any callbacks you hooked into the negotiation process), so it doesn't matter if the application is waiting for application data. Your error is the statement "I can't do any more reads or writes". Reading and writing application data are independent of one another. Reading and writing can become coupled at the TLS layer due to renegotiation, but that's independent of application reads and writes. In short: - If a function, whether it's SSL_read or SSL_write, returns SSL_ERROR_WANT_READ, then retry it when the socket becomes readable. - If a function returns SSL_ERROR_WANT_WRITE, then retry it when the socket becomes writable. - In the meantime, if you know you're in WANT_READ state and you want to try to write something, or vice versa, go ahead. The worst that will happen is that you'll get WANT_* back. - Note that it's possible to be in both WANT_READ and WANT_WRITE, for example if there's no data available from the peer and the peer has advertised a zero window. So you have two bits of state to keep track of there, plus information about whatever pending operations you have. You might have a structure along these lines: struct IOState { int WantRead; /* waiting for socket to become readable */ int WantWrite; /* waiting for it to become writable */ size_t BytesToRead; /* how many bytes to try to read; 0 if we're not looking for data now */ size_t BytesToWrite; /* data waiting to be written */ ... }; plus your socket descriptor/handle, your buffers, your SSL*, etc. Then when you're setting up your multiplexed I/O lists (select, poll, WaitForMultipleObjects, whatever mechanism you use), you'd use the WantRead and WantWrite fields/members to decide whether to include the socket for that type of I/O. And when it pops, if the socket is available, you can try to read and/or write, depending on the BytesTo* fields/members. It'd be a bit more optimal to separately track the WANT_* state for both reading and writing, but in practice it's unlikely to make much of a difference unless you're really performance-critical. There are enough separate states here that it's possible to get the code in quite a mess, so it's probably worth sketching out the state machine on paper first, to help you create a clean, consistent implementation. -- Michael Wojcik Technology Specialist, Micro Focus From luiz.laranjeira at gmail.com Mon Dec 21 15:12:32 2015 From: luiz.laranjeira at gmail.com (Luiz Laranjeira) Date: Mon, 21 Dec 2015 13:12:32 -0200 Subject: [openssl-users] Doubt about the CMS_sign() function (in file openssl/crypto/cms/cms_smime.c) Message-ID: Hi folks, My name is Luiz Laranjeira. I am an associate professor of software engineering with the University of Brasilia, Brazil. I have a group that is developing a signer and validator according to RFC 5652 (CMS/PKCS#7) and we are using OpenSSL. I would like to ask your help concerning a doubt we have: Does the CMS_sign(...) function return a full CMS/PKCS#7 object coded in ASN1 according to RFC 5652 or does it return simply the digital signature field (encrypted hash of the data plus the signed attributes) in ASN1 format? I'd appreciate your assistance with this issue. Best regards, Luiz Laranjeira -------------- next part -------------- An HTML attachment was scrubbed... URL: From Imran.Ali at enghouse.com Tue Dec 22 00:02:27 2015 From: Imran.Ali at enghouse.com (Imran Ali) Date: Tue, 22 Dec 2015 00:02:27 +0000 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses Message-ID: <9253b763fa2f4b289a1b56d1c6f9d90d@UK-MAIL-001.edge.local> Hi Steve, Just want to confirm on this item. Are we saying that to get openssl back to be FIPS compliance is just a paper shuffle. If so is there any expected eta on it as our team is using openssl version for a security project and we need a fips compliance library. Regards, Imran -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcosbontempo at hotmail.com Tue Dec 22 00:28:12 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Mon, 21 Dec 2015 22:28:12 -0200 Subject: [openssl-users] undefined reference to `FIPS_mode' In-Reply-To: <56780749.9040400@openssl.com> References: , <5677FCAF.1060600@openssl.com>, , <56780749.9040400@openssl.com> Message-ID: I'm cross-compiling to a ARMv4 processor, the same used in the BeagleBone. Do you know if this platform is supported? > To: openssl-users at openssl.org > From: marquess at openssl.com > Date: Mon, 21 Dec 2015 09:06:01 -0500 > Subject: Re: [openssl-users] undefined reference to `FIPS_mode' > > On 12/21/2015 08:39 AM, Marcos Bontempo wrote: > > I did the tests in a Ubuntu 14.04. Is there a problem with this version? > > You're cross compiling ... to what target platform I don't know. That > target platform is what needs to be supported, and both the FIPS module > and "FIPS enabled" OpenSSL need to be built for that target platform, > not the build system. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > 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 Tue Dec 22 02:32:08 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 22 Dec 2015 02:32:08 +0000 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses In-Reply-To: <9253b763fa2f4b289a1b56d1c6f9d90d@UK-MAIL-001.edge.local> References: <9253b763fa2f4b289a1b56d1c6f9d90d@UK-MAIL-001.edge.local> Message-ID: > Just want to confirm on this item. Are we saying that to get openssl back to be FIPS compliance is just a paper shuffle. If so is there any expected eta on it as our team is using openssl version for a security project and we need a fips compliance library. No. We have answered this many times, but perhaps the messages were too long and confusing. We are not doing any work on adding new platforms at this time. If you cannot use one of the existing platforms, then there is no FIPS support available "for free." We are not taking on a new validation with new algorithms, etc., unless we get one or more sponsors who are willing to contribute a significant amount of money, among other things. From s.kou at outlook.com Tue Dec 22 05:29:03 2015 From: s.kou at outlook.com (Stephen Kou) Date: Mon, 21 Dec 2015 21:29:03 -0800 Subject: [openssl-users] Checking if an EVP_PKEY* contains a private key Message-ID: OpenSSL has the higher-level EVP_PKEY_* functions which work abstracts the public key cryptography algorithms. However, sometimes a EVP_PKEY* only has a public key. How could I check if a given EVP_PKEY* contains a private key? I could use EVP_PKEY_decrypt_init and see if it returns an error, but that seems to be quite heavy-handed for what seems to be a simple check. The other option is to go through the EVP_PKEY_get0_* functions and investigate the underlying mechanism directly (e.g. EVP_PKEY_get0_RSA and checking the RSA*'s private exponent is NULL), but that is also clumsy as I'll have to write code for every possible algorithm. Thanks Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitus at wagner.pp.ru Tue Dec 22 07:35:36 2015 From: vitus at wagner.pp.ru (Victor Wagner) Date: Tue, 22 Dec 2015 10:35:36 +0300 Subject: [openssl-users] Checking if an EVP_PKEY* contains a private key In-Reply-To: References: Message-ID: <20151222103536.4901be77@fafnir.local.vm> On Mon, 21 Dec 2015 21:29:03 -0800 Stephen Kou wrote: > OpenSSL has the higher-level EVP_PKEY_* functions which work > abstracts the public key cryptography algorithms. However, sometimes > a EVP_PKEY* only has a public key. How could I check if a given > EVP_PKEY* contains a private key? I could use EVP_PKEY_decrypt_init > and see if it returns an error, but that seems to be quite > heavy-handed for what seems to be a simple check. The other option > is to go through the EVP_PKEY_get0_* functions and investigate the > underlying mechanism directly (e.g. EVP_PKEY_get0_RSA and checking > the RSA*'s private exponent is NULL), but that is also clumsy as I'll > have to write code for every possible algorithm. You cannot use EVP_PKEY_decrypt_init if you want code, which works for for every possible algorithm, because every possible public key algorithm doesn't required to support encrypt/decrypt operation. For instance, DSA supports only sign/verify, DH - derive, EC_KEY - both of them, but not encrypt/decrypt. From openssl-users at dukhovni.org Tue Dec 22 08:26:52 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 22 Dec 2015 08:26:52 +0000 Subject: [openssl-users] Checking if an EVP_PKEY* contains a private key In-Reply-To: References: Message-ID: <20151222082652.GI18704@mournblade.imrryr.org> On Mon, Dec 21, 2015 at 09:29:03PM -0800, Stephen Kou wrote: > OpenSSL has the higher-level EVP_PKEY_* functions which work abstracts > the public key cryptography algorithms. However, sometimes a EVP_PKEY* > only has a public key. How could I check if a given EVP_PKEY* contains > a private key? len = i2d_PrivateKey(key, NULL); if (len <= 0) { /* No private key, or error determining its DER length */ } else { /* Private key available */ } -- Viktor. From noloader at gmail.com Tue Dec 22 11:58:28 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 22 Dec 2015 06:58:28 -0500 Subject: [openssl-users] undefined reference to `FIPS_mode' In-Reply-To: References: <5677FCAF.1060600@openssl.com> <56780749.9040400@openssl.com> Message-ID: On Mon, Dec 21, 2015 at 7:28 PM, Marcos Bontempo wrote: > I'm cross-compiling to a ARMv4 processor, the same used in the BeagleBone. > Do you know if this platform is supported? Check the OpenSSL Security Policy at https://www.openssl.org/docs/fips/SecurityPolicy-2.0.10.pdf. The table of support platforms starts on page 10 and runs through page 14. It may be supported (entries 68 and 69), but I think you need to match the board to the operational environment that was validated. Its not obvious to me which one that was. Also, you need a Ubuntu 13 image, and not a Debian image. I'm not aware of any Ubuntu images for BBB. (Also see http://beagleboard.org/latest-images and http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Releases). Finally, I can't really tell if the processor is part of the validated operational environment based on the Debian 8.2 4g-flash image. The processor is only listed as AM33XX, while the validated one is AM335x: $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 2 (v7l) BogoMIPS : 996.14 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part : 0xc08 CPU revision : 2 Hardware : Generic AM33XX (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000 Jeff From marcosbontempo at hotmail.com Tue Dec 22 12:35:56 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Tue, 22 Dec 2015 10:35:56 -0200 Subject: [openssl-users] undefined reference to `FIPS_mode' In-Reply-To: <56780749.9040400@openssl.com> References: , <5677FCAF.1060600@openssl.com>, , <56780749.9040400@openssl.com> Message-ID: Thanks for the answers! I read that it could be a ld problem. So, I executed these commands: echo '/usr/local/ssl/lib/' > fips_openssl.confsudo mv fips_openssl.conf /etc/ld.so.conf.d/.sudo ldconfig Now I get this error: error:00000000:lib(0):func(0):reason(0) Does anybody know how can I correct it? > To: openssl-users at openssl.org > From: marquess at openssl.com > Date: Mon, 21 Dec 2015 09:06:01 -0500 > Subject: Re: [openssl-users] undefined reference to `FIPS_mode' > > On 12/21/2015 08:39 AM, Marcos Bontempo wrote: > > I did the tests in a Ubuntu 14.04. Is there a problem with this version? > > You're cross compiling ... to what target platform I don't know. That > target platform is what needs to be supported, and both the FIPS module > and "FIPS enabled" OpenSSL need to be built for that target platform, > not the build system. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Tue Dec 22 12:36:14 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 22 Dec 2015 12:36:14 +0000 Subject: [openssl-users] Checking if an EVP_PKEY* contains a private key In-Reply-To: <20151222082652.GI18704@mournblade.imrryr.org> References: <20151222082652.GI18704@mournblade.imrryr.org> Message-ID: <20151222123614.GA12756@openssl.org> On Tue, Dec 22, 2015, Viktor Dukhovni wrote: > On Mon, Dec 21, 2015 at 09:29:03PM -0800, Stephen Kou wrote: > > > OpenSSL has the higher-level EVP_PKEY_* functions which work abstracts > > the public key cryptography algorithms. However, sometimes a EVP_PKEY* > > only has a public key. How could I check if a given EVP_PKEY* contains > > a private key? > > len = i2d_PrivateKey(key, NULL); > if (len <= 0) { > /* No private key, or error determining its DER length */ > } else { > /* Private key available */ > } > Interesting idea but that may actually work in some cases due to the "NULL is absent" rule. Encoding the key to a buffer and then attempting to decode it should be more reliable: any absent components will cause a parsing error. However even that wont work in general because the EVP_PKEY structure might come from an engine which doesn't set the private key components. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From marquess at openssl.com Tue Dec 22 13:08:04 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 22 Dec 2015 08:08:04 -0500 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses In-Reply-To: References: <9253b763fa2f4b289a1b56d1c6f9d90d@UK-MAIL-001.edge.local> Message-ID: <56794B34.2070204@openssl.com> On 12/21/2015 09:32 PM, Salz, Rich wrote: > >> Just want to confirm on this item. Are we saying that to get >> openssl back to be FIPS compliance is just a paper shuffle. If so >> is there any expected eta on it as our team is using openssl >> version for a security project and we need a fips compliance >> library. > > No. > > We have answered this many times, but perhaps the messages were too > long and confusing. Yes indeed (mea culpa). It's such a mess I don't know how to address it succinctly. Part of the problem is that there are multiple intertwined issues. I think the term "paper shuffle" in this context refers to the "X9.31 RNG transition" issue which is (hopefully) a one shot aberration, one pothole in the vast wasteland of FIPS 140-2 validations. That is (mostly) addressed, in that a benefactor has come forward (Datagravity, Inc.) to pay the test lab fees necessary for filing the necessary paperwork. That has been done and now we are just waiting on the usual slow bureaucratic process. I'll make an announcement when that paper shuffle is complete. > > We are not doing any work on adding new platforms at this time. If > you cannot use one of the existing platforms, then there is no FIPS > support available "for free." No "freebies". However, we are continuing to perform *sponsored* (some one pays for it) "change letter" additions of new platforms to the *existing* OpenSSL FIPS module (validations #1747/#2398/#2473). We will continue to do so for as long as such updates are technically and economically feasible. Just last week eleven new platforms were added to that module this way, and more platforms are pending. Those aren't free in that some sponsor needs to fund them initially, but once done those platforms are available to everyone. That is the collaborative process by which the OpenSSL FIPS module has grown to support some 120 platforms, more by far than for any other FIPS 140-2 validated module. > We are not taking on a new validation with new algorithms, etc., > unless we get one or more sponsors who are willing to contribute a > significant amount of money, among other things. Correct ... we are eager to do so but lack the opportunity at present. I remain hopeful that we will be able to attempt this at some point. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From Imran.Ali at enghouse.com Tue Dec 22 14:32:20 2015 From: Imran.Ali at enghouse.com (Imran Ali) Date: Tue, 22 Dec 2015 14:32:20 +0000 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses In-Reply-To: <56794B34.2070204@openssl.com> References: <9253b763fa2f4b289a1b56d1c6f9d90d@UK-MAIL-001.edge.local> <56794B34.2070204@openssl.com> Message-ID: Thanks Steve, I was more concerned on the news that openssl may not be FIPS compliant because of: 'sunsetting' older FIPS validations and the reasoning behind the change has to do with the Random Number Generators (RNG). As of December 31, 2015, ANSI X9.31 and X9.62 RNG's will no longer be allowed for use in FIPS mode, leaving us the Random Bit Generators (RBG) of NIST SP 800-90 My understanding based on this is that any applications using ANSI X9.31 and X9.62 functions under FIPS mode will no longer be compliant however the whole openssl will still be FIPS compliant but need paper-shuffle to mark these changes. Am I correct with my assumption on this? Regards, Imran -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess Sent: 22 December 2015 13:08 To: openssl-users at openssl.org Subject: Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses On 12/21/2015 09:32 PM, Salz, Rich wrote: > >> Just want to confirm on this item. Are we saying that to get openssl >> back to be FIPS compliance is just a paper shuffle. If so is there >> any expected eta on it as our team is using openssl version for a >> security project and we need a fips compliance library. > > No. > > We have answered this many times, but perhaps the messages were too > long and confusing. Yes indeed (mea culpa). It's such a mess I don't know how to address it succinctly. Part of the problem is that there are multiple intertwined issues. I think the term "paper shuffle" in this context refers to the "X9.31 RNG transition" issue which is (hopefully) a one shot aberration, one pothole in the vast wasteland of FIPS 140-2 validations. That is (mostly) addressed, in that a benefactor has come forward (Datagravity, Inc.) to pay the test lab fees necessary for filing the necessary paperwork. That has been done and now we are just waiting on the usual slow bureaucratic process. I'll make an announcement when that paper shuffle is complete. > > We are not doing any work on adding new platforms at this time. If > you cannot use one of the existing platforms, then there is no FIPS > support available "for free." No "freebies". However, we are continuing to perform *sponsored* (some one pays for it) "change letter" additions of new platforms to the *existing* OpenSSL FIPS module (validations #1747/#2398/#2473). We will continue to do so for as long as such updates are technically and economically feasible. Just last week eleven new platforms were added to that module this way, and more platforms are pending. Those aren't free in that some sponsor needs to fund them initially, but once done those platforms are available to everyone. That is the collaborative process by which the OpenSSL FIPS module has grown to support some 120 platforms, more by far than for any other FIPS 140-2 validated module. > We are not taking on a new validation with new algorithms, etc., > unless we get one or more sponsors who are willing to contribute a > significant amount of money, among other things. Correct ... we are eager to do so but lack the opportunity at present. I remain hopeful that we will be able to attempt this at some point. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From marquess at openssl.com Tue Dec 22 15:06:07 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 22 Dec 2015 10:06:07 -0500 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses In-Reply-To: References: <9253b763fa2f4b289a1b56d1c6f9d90d@UK-MAIL-001.edge.local> <56794B34.2070204@openssl.com> Message-ID: <567966DF.8070200@openssl.com> On 12/22/2015 09:32 AM, Imran Ali wrote: > Thanks Steve, > > I was more concerned on the news that openssl may not be FIPS > compliant because of: > > 'sunsetting' older FIPS validations and the reasoning behind the > change has to do with the Random Number Generators (RNG). As of > December 31, 2015, ANSI X9.31 and X9.62 RNG's will no longer be > allowed for use in FIPS mode, leaving us the Random Bit Generators > (RBG) of NIST SP 800-90 That's the "paper shuffle" referenced earlier, and in this earlier post in this same thread: https://mta.openssl.org/pipermail/openssl-users/2015-December/002562.html Thanks to Datagravity that "paper shuffle" is being addressed. The test lab has the necessary paperwork and there is nothing more we can do other than wait on the process. > My understanding based on this is that any applications using ANSI > X9.31 and X9.62 functions under FIPS mode will no longer be compliant > however the whole openssl will still be FIPS compliant but need > paper-shuffle to mark these changes. Am I correct with my assumption > on this? Kinda-sorta. The "sunset" issue isn't *use* of X9.31, which is not the default for the OpenSSL FIPS Object Module and not used anywhere with the module as far as I know. The issue is that any validations that implement *both* X9.31 RNG *and* one or more DRBGs will be yanked without the paper shuffle, regardless of any actual use of X9.31 with those modules. The paper shuffle basically consists of removing most mentions of X9.31 RNG from the Security Policy document. Any application that has deliberately and explicitly enabled a non-default use of the X9.31 RNG would need to be changed, independently of the paper shuffle, but I doubt there are any such applications. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marquess at openssl.com Tue Dec 22 15:57:25 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 22 Dec 2015 10:57:25 -0500 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses In-Reply-To: <566EC2DB.5020308@openssl.com> References: <565F1966.7060303@openssl.com> <566EC2DB.5020308@openssl.com> Message-ID: <567972E5.9040103@openssl.com> On 12/14/2015 08:23 AM, Steve Marquess wrote: > On 12/02/2015 11:16 AM, Steve Marquess wrote: >> If you don't know or care what FIPS 140-2 is, be very glad this isn't >> your problem and turn your charitable attentions to some worthy cause. >> >> The CMVP has introduced a new policy that will result in the effective >> termination of many extant validations if they are not updated by >> January 31 2016[1]. That update is a pure paper shuffle -- adding >> politically correct verbiage to the Security Policy document -- but >> without it the CMVP will "de-list" the validation. The original OpenSSL >> FIPS Object Module validations (#1747, #2398, #2473) and all validations >> based on them -- which is a lot of validations -- are affected. >> >> I'll be doing the labor to prepare the revised Security Policy documents >> for all the validations that have been performed by OSF, both the well >> known open source based ones and also "private label" ones, and the test >> labs for some of those validations are also doing their part pro bono. >> However, the test lab we used for the original open source based >> validations (#1747, #2398, #2473) is charging $1250 for those three >> related validations of the same module. Note this is not unreasonable as >> these updates involve a non-trivial amount of work. >> >> ... > > I'm pleased to report that this $1250 cost to paper-shuffle the > #1747/#2398/#2473 validations has been covered, by Datagravity Inc. > Within minutes of hearing of the issue for the first time the the CEO, > Paula Long, not only had a check en route to the test lab but also sent > a scan of the check and envelope as a heads-up for the lab. > > ... Three companies answered this call to cover the cost of the "X9.31 RNG transition" paper shuffle. Datagravity (http://datagravity.com/) acted quickly and decisively, and the requisite paperwork has begun its journey through the bowels of the FIPS 140-2 bureaucracy. I would like to note that another company, Niksun (https://niksun.com/) also contacted the test lab to make arrangement for payment of that fee. If not for Datagravity beating them to the punch they would have been the benefactor for this very necessary action. The third company (not named here by request) was vigorously pursuing an in-house approvals process and would also have covered this effort. I thank all three for volunteering to bail out the entire community of OpenSSL FIPS module users. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marcosbontempo at hotmail.com Wed Dec 23 00:26:26 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Tue, 22 Dec 2015 22:26:26 -0200 Subject: [openssl-users] FIPS_check_incore_fingerprint: fingerprint does not match Message-ID: Hello, I'm getting this error when call the function FIPS_mode_set(1): error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match Does anybody know how to correct it? Any tip will be very helpful,Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Dec 23 01:58:22 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 23 Dec 2015 02:58:22 +0100 Subject: [openssl-users] FIPS_check_incore_fingerprint: fingerprint does not match In-Reply-To: References: Message-ID: <5679FFBE.3060803@wisemo.com> On 23/12/2015 01:26, Marcos Bontempo wrote: > Hello, > > I'm getting this error when call the function FIPS_mode_set(1): > > error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint > does not match > > Does anybody know how to correct it? > You forgot to run the special "FIPS" linker script on your application, which sets the value of that fingerprint based on the load address and relocations of your application. Note, that this means that the design of the FIPS module security policy is incompatible with ASLR on almost every operating system having that feature. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcosbontempo at hotmail.com Wed Dec 23 10:25:41 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Wed, 23 Dec 2015 08:25:41 -0200 Subject: [openssl-users] FIPS_check_incore_fingerprint: fingerprint does not match In-Reply-To: <5679FFBE.3060803@wisemo.com> References: , <5679FFBE.3060803@wisemo.com> Message-ID: Thanks for the answer! I searched about the FIPS linker script but I couldn't find any content. Can you tell how can I run it? To: openssl-users at openssl.org From: jb-openssl at wisemo.com Date: Wed, 23 Dec 2015 02:58:22 +0100 Subject: Re: [openssl-users] FIPS_check_incore_fingerprint: fingerprint does not match On 23/12/2015 01:26, Marcos Bontempo wrote: Hello, I'm getting this error when call the function FIPS_mode_set(1): error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match Does anybody know how to correct it? You forgot to run the special "FIPS" linker script on your application, which sets the value of that fingerprint based on the load address and relocations of your application. Note, that this means that the design of the FIPS module security policy is incompatible with ASLR on almost every operating system having that feature. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayadev.kumar at gmail.com Wed Dec 23 15:20:50 2015 From: jayadev.kumar at gmail.com (Jayadev Kumar) Date: Wed, 23 Dec 2015 20:50:50 +0530 Subject: [openssl-users] openssl-101m server and openssl-101q client TLS1.2 failure Message-ID: Hi, When i run openssl-1.0.1m server with ./openssl101m s_server -accept 443 -msg and openssl-1.0.1q client with following command ./openssl101q s_client -connect x.x.x.x:443 I see server is failing with error >>> TLS 1.2 Handshake [length 0004], ServerHelloDone 0e 00 00 00 <<< TLS 1.2 Alert [length 0002], fatal handshake_failure 02 28 ERROR 140005164332736:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1289:SSL alert number 40 shutting down SSL This is not see when both client and server uses 'openssl' binary from 'openssl-1.0.1m'. Is this a known issue ? Any workarounds known ? Thanks, Jayadev M. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Dec 23 15:25:30 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 23 Dec 2015 15:25:30 +0000 Subject: [openssl-users] openssl-101m server and openssl-101q client TLS1.2 failure In-Reply-To: References: Message-ID: Try https://groups.google.com/forum/#!topic/node-apn/H1B6iCJlZYo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayadev.kumar at gmail.com Wed Dec 23 15:44:40 2015 From: jayadev.kumar at gmail.com (Jayadev Kumar) Date: Wed, 23 Dec 2015 21:14:40 +0530 Subject: [openssl-users] openssl-101m server and openssl-101q client TLS1.2 failure In-Reply-To: References: Message-ID: Thanks for responding. But In my case replacing the client side binary built with openssl-101m this issue goes away. So wondering could this be a bug in openssl code ? On Wed, Dec 23, 2015 at 8:55 PM, Salz, Rich wrote: > Try https://groups.google.com/forum/#!topic/node-apn/H1B6iCJlZYo > > > > _______________________________________________ > 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 Wed Dec 23 15:46:25 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 23 Dec 2015 15:46:25 +0000 Subject: [openssl-users] openssl-101m server and openssl-101q client TLS1.2 failure In-Reply-To: References: Message-ID: <60013c5255da4e57b96256a9d4963f34@usma1ex-dag1mb1.msg.corp.akamai.com> >But In my case? replacing the client side binary built with openssl-101m this issue > goes away.? So wondering could this be a bug in openssl code ? Very very doubtful. From matt at openssl.org Wed Dec 23 15:49:57 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 23 Dec 2015 15:49:57 +0000 Subject: [openssl-users] openssl-101m server and openssl-101q client TLS1.2 failure In-Reply-To: References: Message-ID: <567AC2A5.9040800@openssl.org> On 23/12/15 15:20, Jayadev Kumar wrote: > Hi, > > When i run openssl-1.0.1m server with > > ./openssl101m s_server -accept 443 -msg > > and openssl-1.0.1q client with following command > > ./openssl101q s_client -connect x.x.x.x:443 > > I see server is failing with error > >>>> TLS 1.2 Handshake [length 0004], ServerHelloDone > 0e 00 00 00 > <<< TLS 1.2 Alert [length 0002], fatal handshake_failure > 02 28 > ERROR > 140005164332736:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert > handshake failure:s3_pkt.c:1289:SSL alert number 40 > shutting down SSL > > > This is not see when both client and server uses 'openssl' binary from > 'openssl-1.0.1m'. Is this a known issue ? Any workarounds known ? Do you get an error printed on the client side? If so what is it? Matt From jayadev.kumar at gmail.com Wed Dec 23 15:54:09 2015 From: jayadev.kumar at gmail.com (Jayadev Kumar) Date: Wed, 23 Dec 2015 21:24:09 +0530 Subject: [openssl-users] openssl-101m server and openssl-101q client TLS1.2 failure In-Reply-To: <567AC2A5.9040800@openssl.org> References: <567AC2A5.9040800@openssl.org> Message-ID: Here is the error i got in s_client: 97 8d e5 1f ad a8 35 e9 48 cd 09 bd 69 8d 40 d5 fd 05 e2 66 7c 50 d5 41 7a 51 d0 6b 08 dd 37 2e fd 17 32 ca be b8 c1 d5 3a f0 ad 21 32 29 ae 2c 1d ba dd 8f 18 25 94 4d dd 0a 30 35 dc a6 79 52 70 67 f4 37 72 97 c4 e8 16 e0 fd e0 3d 16 92 >>> TLS 1.2 Alert [length 0002], fatal handshake_failure 02 28 140066827908800:error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3415: --- Certificate chain 0 s:/C=UK/O=OpenSSL Group/OU=FOR TESTING PURPOSES ONLY/CN=Test Server Cert i:/C=UK/O=OpenSSL Group/OU=FOR TESTING PURPOSES ONLY/CN=OpenSSL Test Intermediate CA Thanks, Jayadev. On Wed, Dec 23, 2015 at 9:19 PM, Matt Caswell wrote: > > > On 23/12/15 15:20, Jayadev Kumar wrote: > > Hi, > > > > When i run openssl-1.0.1m server with > > > > ./openssl101m s_server -accept 443 -msg > > > > and openssl-1.0.1q client with following command > > > > ./openssl101q s_client -connect x.x.x.x:443 > > > > I see server is failing with error > > > >>>> TLS 1.2 Handshake [length 0004], ServerHelloDone > > 0e 00 00 00 > > <<< TLS 1.2 Alert [length 0002], fatal handshake_failure > > 02 28 > > ERROR > > 140005164332736:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert > > handshake failure:s3_pkt.c:1289:SSL alert number 40 > > shutting down SSL > > > > > > This is not see when both client and server uses 'openssl' binary from > > 'openssl-1.0.1m'. Is this a known issue ? Any workarounds known ? > > Do you get an error printed on the client side? If so what is it? > > 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 Wed Dec 23 16:04:22 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 23 Dec 2015 16:04:22 +0000 Subject: [openssl-users] openssl-101m server and openssl-101q client TLS1.2 failure In-Reply-To: References: <567AC2A5.9040800@openssl.org> Message-ID: <567AC606.5020209@openssl.org> On 23/12/15 15:54, Jayadev Kumar wrote: > routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3415: Ah. The above line is the critical bit. This is as a result of the logjam protections that were part of 1.0.1n. See: https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ 1.0.1m s_server uses DH parameters that are too small by default. You can generate new ones using: $ openssl dhparam -out dhparam.pem 2048 Then start s_server using: $ openssl s_server -msg -dhparam dhparam.pem You should find that 1.0.1q client can interoperate with the above just fine. Matt From jayadev.kumar at gmail.com Wed Dec 23 16:07:58 2015 From: jayadev.kumar at gmail.com (Jayadev Kumar) Date: Wed, 23 Dec 2015 21:37:58 +0530 Subject: [openssl-users] openssl-101m server and openssl-101q client TLS1.2 failure In-Reply-To: <567AC606.5020209@openssl.org> References: <567AC2A5.9040800@openssl.org> <567AC606.5020209@openssl.org> Message-ID: Thanks Matt. Jayadev. On Wed, Dec 23, 2015 at 9:34 PM, Matt Caswell wrote: > > > On 23/12/15 15:54, Jayadev Kumar wrote: > > routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3415: > > Ah. The above line is the critical bit. This is as a result of the > logjam protections that were part of 1.0.1n. See: > https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ > > 1.0.1m s_server uses DH parameters that are too small by default. You > can generate new ones using: > > $ openssl dhparam -out dhparam.pem 2048 > > Then start s_server using: > > $ openssl s_server -msg -dhparam dhparam.pem > > You should find that 1.0.1q client can interoperate with the above just > fine. > > Matt > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidboulding at hotmail.com Sun Dec 27 02:41:58 2015 From: davidboulding at hotmail.com (David Boulding) Date: Sun, 27 Dec 2015 02:41:58 +0000 Subject: [openssl-users] v1.1.0-pre1 - Trouble compiling with (1) no-threads and (2) no-psk no-srp Message-ID: v1.1.0-pre1 on linux (1) Compiling with "no-threads " gives error on lines 173 and 379 in async.c. possible cause: async_fibre_makecontext() function async_posix.h @ line 57: #if defined(OPENSSL_SYS_UNIX) && defined(OPENSSL_THREADS) seems threads is required? (2) Compiling with no-psk and no-srp gives error on line 1692 in statem_clnt.c possible cause: with no-psk and no-srp nop'd out by #ifndef's above, line 1692 starts with "else if" instead of "if" Neither of these errors occurred in 1.0.2e. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcosbontempo at hotmail.com Sun Dec 27 18:08:42 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Sun, 27 Dec 2015 16:08:42 -0200 Subject: [openssl-users] FIPS_check_incore_fingerprint: fingerprint does not match In-Reply-To: References: , <5679FFBE.3060803@wisemo.com>, Message-ID: I changed my Makefile to use fipsld, but I'm still getting the same error. Before compiling, I run this script:______________________________________________________________#! /bin/bash ################################# OpenSSL directory if [ -z $OPENSSLDIR ] && [ -d /usr/local/ssl ]; then OPENSSLDIR=/usr/local/sslfi if [ -z "$OPENSSLDIR" ]; then echo "Could not locate OpenSSL installation directory"fi ################################# OpenSSL and fipsld export FIPS_SIG=`find $OPENSSLDIR/fips-2.0 -iname incore 2>/dev/null`export FIPSLIBDIR=`find $OPENSSLDIR/fips-2.0 -iname lib 2>/dev/null` if [ -z "$FIPS_SIG" ]; then echo "Could not locate 'incore' in $OPENSSLDIR/fips-2.0"fi if [ -z "$FIPSLIBDIR" ]; then echo "Could not locate 'FIPS library directory' in $OPENSSLDIR/fips-2.0"fi set -x______________________________________________________________ Here is my Makefile: ______________________________________________________________CC=gccOPENSSLDIR=/usr/local/sslLIBS=$(OPENSSLDIR)/lib/libcrypto.a $(OPENSSLDIR)/lib/libssl.a -ldlFIPSLIBDIR=$(OPENSSLDIR)/libINCLUDES=-I$(OPENSSLDIR)/includeCMD=fipsctl OBJS=$(CMD).o $(CMD): $(OBJS) FIPSLD_CC=$(CC) $(OPENSSLDIR)/bin/fipsld -o $(CMD) $(OBJS) \ $(LIBS) $(OBJS): $(CMD).c $(CC) -c $(CMD).c $(INCLUDES) clean: rm -Rf *.o $(CMD)______________________________________________________________ What is wrong? I only want to build the simplest application using FIPS. From: marcosbontempo at hotmail.com To: openssl-users at openssl.org Subject: RE: [openssl-users] FIPS_check_incore_fingerprint: fingerprint does not match Date: Wed, 23 Dec 2015 08:25:41 -0200 Thanks for the answer! I searched about the FIPS linker script but I couldn't find any content. Can you tell how can I run it? To: openssl-users at openssl.org From: jb-openssl at wisemo.com Date: Wed, 23 Dec 2015 02:58:22 +0100 Subject: Re: [openssl-users] FIPS_check_incore_fingerprint: fingerprint does not match On 23/12/2015 01:26, Marcos Bontempo wrote: Hello, I'm getting this error when call the function FIPS_mode_set(1): error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match Does anybody know how to correct it? You forgot to run the special "FIPS" linker script on your application, which sets the value of that fingerprint based on the load address and relocations of your application. Note, that this means that the design of the FIPS module security policy is incompatible with ASLR on almost every operating system having that feature. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcosbontempo at hotmail.com Sun Dec 27 19:30:25 2015 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Sun, 27 Dec 2015 17:30:25 -0200 Subject: [openssl-users] FIPS_mode_set(1) error:00000000:lib(0):func(0):reason(0) Message-ID: Hello, I'm trying to enable FIPS mode with this code:__________________________________________________________________#include #include #include int main ( int argc, char *argv[] ){#ifdef OPENSSL_FIPS int mode, result; // Get FIPS mode if(strcmp("get",argv[1]) == 0) { mode = FIPS_mode(); if(mode == 0) { printf("*** FIPS module is disabled. ***\n"); } if(mode == 1) { printf("*** FIPS module is enabled. ***\n"); } } // Set FIPS mode else if(strcmp("set",argv[1]) == 0) { if(strcmp("0",argv[2]) == 0) { printf("*** Disabling FIPS module. ***\n"); result = FIPS_mode_set(0); if(result != 1) { ERR_load_crypto_strings(); printf("*** Failed to disable FIPS module. ***\n"); printf("%s\n", ERR_error_string(ERR_get_error(), NULL)); return 1; } } else if (strcmp("1",argv[2]) == 0) { printf("*** Enabling FIPS module. ***\n"); result = FIPS_mode_set(1); if(result != 1) { ERR_load_crypto_strings(); printf("*** Failed to enable FIPS module. ***\n"); printf("%s\n", ERR_error_string(ERR_get_error(), NULL)); return 1; } } else { printf("*** Error: unsupported option. ***\n"); return 1; } } // Unsupported option else { printf("*** Error: unsupported option. ***\n"); return 1; } return 0; #else printf("OPENSSL_FIPS is not defined"); #endif //OPENSSL_FIPS } __________________________________________________________________ And with this Makefile: __________________________________________________________________CC=gccOPENSSLDIR=/usr/local/sslLIBS=$(OPENSSLDIR)/lib/libcrypto.a $(OPENSSLDIR)/lib/libssl.a -ldl INCLUDES=-I$(OPENSSLDIR)/includeCMD=fipsctl OBJS=$(CMD).o $(CMD): $(OBJS) FIPSLD_CC=$(CC) $(OPENSSLDIR)/bin/fipsld -o $(CMD) $(OBJS) -ldl \ $(LIBS) $(OBJS): $(CMD).c $(CC) -c $(CMD).c $(INCLUDES) clean: rm -Rf *.o $(CMD)__________________________________________________________________ It compiles without errors. When I try to enable FIPS mode, I get this output: arm:~/nitere/new$ ./fipsctl set 1*** Enabling FIPS module. ****** Failed to enable FIPS module. ***error:00000000:lib(0):func(0):reason(0) But FIPS is still disabled: arm:~/nitere/new$ ./fipsctl get*** FIPS module is disabled. *** Does somebody knows what is wrong? Any tip will be very helpful,Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Tue Dec 29 01:57:15 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 28 Dec 2015 20:57:15 -0500 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition submitted Message-ID: <5681E87B.9050509@openssl.com> If you're not aware of or anxious about the "X9.31 RNG transition", rejoice. You live in a saner world that those of us who do have to worry about it. The test lab has informed me that the formal "change letter" submission to address the "X9.31 RNG transition" for the OpenSSL FIPS Object Module v2.0, validation(s) #1747/#2398/#2474, was submitted to the CMVP as of last Wednesday, 2015-12-23. The test lab fees for this submission were paid for by DataGravity, Inc., thereby avoiding further delays that would have impacted the many vendors using the OpenSSL FIPS module. I'm already getting queries about the status of this submission. Now that it is in the hands of the CMVP I have no visibility whatsoever into its fate (or fates plural, as the CMVP will undoubtedly treat it as three separate submissions even though all three validations are for the same cryptographic module). I check the NIST CMVP web site[*] every day to see what they have or haven't done in the last 24 hours, and will announce any results here if and when there is anything to announce. -Steve M. [*] http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From sugu.ece28 at gmail.com Tue Dec 29 09:27:43 2015 From: sugu.ece28 at gmail.com (suguacl28) Date: Tue, 29 Dec 2015 02:27:43 -0700 (MST) Subject: [openssl-users] RSA Public Encryption and Decryption Message-ID: <1451381263400-61935.post@n7.nabble.com> Hi, Lets assume i have a RSA public key file (xyz_file.pem) and cipher text that is encrypted using same RSA public key file (xyz_file.pem) now i want to decrypt the cipher text using same RSA public key file (xyz_file.pem). Ya i know its not a correct way of encryption and decryption concept. Just i need to know the security vulnerability in this concept!!! -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-Public-Encryption-and-Decryption-tp61935.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From breimer273 at gmail.com Tue Dec 29 13:00:05 2015 From: breimer273 at gmail.com (Bill Reimer) Date: Tue, 29 Dec 2015 08:00:05 -0500 Subject: [openssl-users] RSA Public Encryption and Decryption In-Reply-To: <1451381263400-61935.post@n7.nabble.com> References: <1451381263400-61935.post@n7.nabble.com> Message-ID: What you are describing is not even how RSA works. You would be describing symmetrical encryption, whereas RSA is asymmetrical. There is no inherent vulnerability with symmetrical encryption assuming you keep the key private. The idea behind RSA is that you can share your public key and only the private key can decrypt that text, using a different key for encryption and decryption is asymmetrical. For further reading refer to: https://en.wikipedia.org/wiki/Symmetric-key_algorithm and https://en.wikipedia.org/wiki/Public-key_cryptography On Tue, Dec 29, 2015 at 4:27 AM, suguacl28 wrote: > Hi, > > Lets assume i have a RSA public key file (xyz_file.pem) and cipher text > that > is encrypted using same RSA public key file (xyz_file.pem) now i want to > decrypt the cipher text using same RSA public key file (xyz_file.pem). > > Ya i know its not a correct way of encryption and decryption concept. > Just i need to know the security vulnerability in this concept!!! > > > > -- > View this message in context: > http://openssl.6102.n7.nabble.com/RSA-Public-Encryption-and-Decryption-tp61935.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sugu.ece28 at gmail.com Tue Dec 29 12:58:51 2015 From: sugu.ece28 at gmail.com (suguacl28) Date: Tue, 29 Dec 2015 05:58:51 -0700 (MST) Subject: [openssl-users] RSA Public Encryption and Decryption In-Reply-To: References: <1451381263400-61935.post@n7.nabble.com> Message-ID: <1451393931633-61937.post@n7.nabble.com> Ya i know it. Actually i need to transfer the symmetric key to client. That symmetric key is encrypted using RSA public key of client which is transferred manually to server. Now i want to decrypt the package with same RSA public key of client. Now my doubt is, for decryption we must use private key of client or we can also use client public key?? -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-Public-Encryption-and-Decryption-tp61935p61937.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From breimer273 at gmail.com Tue Dec 29 13:50:37 2015 From: breimer273 at gmail.com (Bill Reimer) Date: Tue, 29 Dec 2015 08:50:37 -0500 Subject: [openssl-users] RSA Public Encryption and Decryption In-Reply-To: <1451393931633-61937.post@n7.nabble.com> References: <1451381263400-61935.post@n7.nabble.com> <1451393931633-61937.post@n7.nabble.com> Message-ID: If I understand you correctly, yes you must use the private key to decrypt the symmetric key which has been encrypted using RSA and the client's public key. There is no way (theoretically) to decrypt using only the public key. On Tue, Dec 29, 2015 at 7:58 AM, suguacl28 wrote: > Ya i know it. Actually i need to transfer the symmetric key to client. That > symmetric key is encrypted using RSA public key of client which is > transferred manually to server. Now i want to decrypt the package with > same > RSA public key of client. > > Now my doubt is, for decryption we must use private key of client or we can > also use client public key?? > > > > -- > View this message in context: > http://openssl.6102.n7.nabble.com/RSA-Public-Encryption-and-Decryption-tp61935p61937.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sugu.ece28 at gmail.com Tue Dec 29 13:20:35 2015 From: sugu.ece28 at gmail.com (suguacl28) Date: Tue, 29 Dec 2015 06:20:35 -0700 (MST) Subject: [openssl-users] RSA Public Encryption and Decryption In-Reply-To: References: <1451381263400-61935.post@n7.nabble.com> <1451393931633-61937.post@n7.nabble.com> Message-ID: <1451395235628-61939.post@n7.nabble.com> Yes understanding is correct. Just i want know public key decryption is possible or not. Now i got it. Thanks for your information. -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-Public-Encryption-and-Decryption-tp61935p61939.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From felix at kngnt.org Tue Dec 29 19:35:49 2015 From: felix at kngnt.org (Felix Rubio Dalmau) Date: Tue, 29 Dec 2015 20:35:49 +0100 Subject: [openssl-users] Openssl not sending "client hello" request Message-ID: <2580476.uZjsrlHnGz@polaris> Hi all, I have been searching for some time for a solution and I can not manage to solve my problem. I have a computer that can not connect to some sites, e.g. github, by using openssl. I am running a debian testing with all the updates available as of today, and libssl used is v1.0.2. If I execute: > openssl s_client -connect github.com:443 The only answer I get is: > CONNECTED(00000003) > 140058172421776:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > protocol:s23_clnt.c:794: --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 315 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: 1451415453 > Timeout : 300 (sec) > Verify return code: 0 (ok) > > --- I have created a network namespace and executed the program inside while sniffing the traffic with tcpdump (See attached file). If I execute ***the same*** openssl binary on my arch linux, the program works flawlessly. If I obtain also the traffic on the arch, I see a difference: in my debian there is no clienthello sent to the server, whereas in arch linux it is. I would consider, under these circumstances, that is an environment problem in my debian. Therefore I have executed the same command on a completely fresh bash, without any strange environment vars, obtaining the same result. Then I thought it could be related to any configuration file, but... I have not been able to find any :S Can somebody give any hint? I would really appreciate it. thank you! Felix -------------- next part -------------- A non-text attachment was scrubbed... Name: not_working.cap Type: application/vnd.tcpdump.pcap Size: 1815 bytes Desc: not available URL: From felix at kngnt.org Tue Dec 29 19:11:59 2015 From: felix at kngnt.org (Felix Rubio Dalmau) Date: Tue, 29 Dec 2015 20:11:59 +0100 Subject: [openssl-users] Openssl not sending "client hello" request Message-ID: <3359041.zbmPLlVNxp@polaris> Hi all, I have been searching for some time for a solution and I can not manage to solve my problem. I have a computer that can not connect to some sites, e.g. github, by using openssl. I am running a debian testing with all the updates available as of today, and libssl used is v1.0.2. If I execute: > openssl s_client -connect github.com:443 The only answer I get is: > CONNECTED(00000003) > 140058172421776:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > protocol:s23_clnt.c:794: --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 315 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: 1451415453 > Timeout : 300 (sec) > Verify return code: 0 (ok) > > --- I have created a network namespace and executed the program inside while sniffing the traffic with tcpdump (See attached file). If I execute ***the same*** openssl binary on my arch linux, the program works flawlessly. If I obtain also the traffic on the arch, I see a difference: in my debian there is no clienthello sent to the server, whereas in arch linux it is. I would consider, under these circumstances, that is an environment problem in my debian. Therefore I have executed the same command on a completely fresh bash, without any strange environment vars, obtaining the same result. Then I thought it could be related to any configuration file, but... I have not been able to find any :S Can somebody give any hint? I would really appreciate it. thank you! Felix -------------- next part -------------- A non-text attachment was scrubbed... Name: not_working.cap Type: application/vnd.tcpdump.pcap Size: 1815 bytes Desc: not available URL: From kurt at roeckx.be Wed Dec 30 13:08:19 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 30 Dec 2015 14:08:19 +0100 Subject: [openssl-users] Openssl not sending "client hello" request In-Reply-To: <2580476.uZjsrlHnGz@polaris> References: <2580476.uZjsrlHnGz@polaris> Message-ID: <20151230130819.GA9243@roeckx.be> On Tue, Dec 29, 2015 at 08:35:49PM +0100, Felix Rubio Dalmau wrote: > Hi all, > > I have been searching for some time for a solution and I can not manage to > solve my problem. I have a computer that can not connect to some sites, e.g. > github, by using openssl. I am running a debian testing with all the updates > available as of today, and libssl used is v1.0.2. If I execute: > > > openssl s_client -connect github.com:443 The trace file you attached, which claims to go github.com:443, did send a Client Hello. However the reply is a plain text "400 Bad Request". It looks like you connected to port 80 and not 443 for some reason. I suspect something is broken in your network. Kurt From doctor at doctor.nl2k.ab.ca Wed Dec 30 16:35:21 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 30 Dec 2015 09:35:21 -0700 Subject: [openssl-users] Openssl 1.1 Message-ID: <20151230163521.GA8088@doctor.nl2k.ab.ca> All right, I did get this to start working on my 'ancient' BSD box. Couple of issues did catch my attention. Are Openssh, DNS developers, SMTP/POP3/IMAP developers, FTP devleopers, HTTPD developers and LDAP developers aware of changes coming down the pipe? If not, they should be informed. Also the libraries for libcrypto and libssl are suffixed as 1.1 instead of 1.1.0 any reason? Finally for the Configurations/10-main.conf I propose a slight amendment to the bsdi section "bsdi-elf-gcc" => { inherit_from => [ asm("x86_elf_asm") ], cc => "gcc", cflags => "-DPERL5 -DL_ENDIAN -fomit-frame-pointer -O2 -march =i486 -Wall", thread_cflag => "(unknown)", lflags => "-ldl", bn_ops => "BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}", dso_scheme => "dlfcn", shared_target => "bsd-gcc-shared", shared_cflag => "-fPIC", shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", }, "debug-bsdi-x86-elf" => { inherit_from => [ asm("x86_elf_asm") ], cc => "gcc", cflags => "-DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g", thread_cflag => "-pthread -D_THREAD_SAFE -D_REENTRANT", lflags => "-ldl -lgmp -lm -lc -lz", bn_ops => "THIRTY_TWO_BIT_LONG RC4_CHUNK BN_LLONG ${x86_gcc_d es} ${x86_gcc_opts}", dso_scheme => "dlfcn", shared_target => "bsd-gcc-shared", shared_cflag => "-fPIC", shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", }, -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Happy Christmas 2015 and Merry New Year 2016 -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Happy Christmas 2015 and Merry New Year 2016 From rsalz at akamai.com Wed Dec 30 17:02:14 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Dec 2015 17:02:14 +0000 Subject: [openssl-users] [openssl-dev] Openssl 1.1 In-Reply-To: <20151230163521.GA8088@doctor.nl2k.ab.ca> References: <20151230163521.GA8088@doctor.nl2k.ab.ca> Message-ID: <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> > Are Openssh, DNS developers, SMTP/POP3/IMAP developers, FTP > devleopers, HTTPD developers and LDAP developers aware of changes > coming down the pipe? > > If not, they should be informed. We've posted about it several times. We're making explicit pre-release testing versions available. We've seen other folks (e.g., CURL) post about their experiences. Do you have any suggestions? We'd hate for 'surprises' to delay people to start using it. From doctor at doctor.nl2k.ab.ca Wed Dec 30 17:23:42 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 30 Dec 2015 10:23:42 -0700 Subject: [openssl-users] [openssl-dev] Openssl 1.1 In-Reply-To: <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151230163521.GA8088@doctor.nl2k.ab.ca> <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20151230172342.GA17006@doctor.nl2k.ab.ca> On Wed, Dec 30, 2015 at 05:02:14PM +0000, Salz, Rich wrote: > > Are Openssh, DNS developers, SMTP/POP3/IMAP developers, FTP > > devleopers, HTTPD developers and LDAP developers aware of changes > > coming down the pipe? > > > > If not, they should be informed. > > We've posted about it several times. We're making explicit pre-release testing versions available. We've seen other folks (e.g., CURL) post about their experiences. Do you have any suggestions? We'd hate for 'surprises' to delay people to start using it. > We do our best to get this informing done. I do not know why yet, but I had a problem with openssh. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Happy Christmas 2015 and Merry New Year 2016 From rsalz at akamai.com Wed Dec 30 17:30:59 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Dec 2015 17:30:59 +0000 Subject: [openssl-users] [openssl-dev] Openssl 1.1 In-Reply-To: <20151230172342.GA17006@doctor.nl2k.ab.ca> References: <20151230163521.GA8088@doctor.nl2k.ab.ca> <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> <20151230172342.GA17006@doctor.nl2k.ab.ca> Message-ID: <285dbe4193af455786778e300987b8ca@usma1ex-dag1mb1.msg.corp.akamai.com> > We do our best to get this informing done. > > I do not know why yet, but I had a problem with openssh. Thank you very much for your help! Happy New Year. From gareth at garethwilliams.me.uk Thu Dec 31 16:56:08 2015 From: gareth at garethwilliams.me.uk (Gareth Williams) Date: Thu, 31 Dec 2015 16:56:08 +0000 Subject: [openssl-users] openssl verify and alt_chains Message-ID: <56855E28.9020900@garethwilliams.me.uk> Hi, I've just installed openssl version 1.1.0-pre2-dev in my home directory on a Fedora box in order to see the new alt chain building in operation. I'm testing this in a lab environment by initially generating a straight hierarchy of root CA, policy CA, issuing CA and end-entity (a web server) all with a really original naming convention as follows: Gareth Williams Root CA Gareth Williams Policy CA Gareth Williams Issuing CA office.garethwilliams.me.uk (test webserver) I've concatenated the policy CA and issuing CA certificate into a single file, and running: openssl verify -trusted Gareth_Williams_Root_CA.crt -untrusted chain.crt office.garethwilliams.me.uk works. I now try to cross-certify by adding another Root CA (Example Root CA) and use that to sign the original Gareth Williams Policy CA certificate signing request, then add this new certificate to the chain.crt file: Gareth Williams Root CA Example Root CA | | Gareth Williams Policy CA Gareth Williams Policy CA | | +----------------+------------------+ | Gareth Williams Issuing CA | office.garethwilliams.me.uk When I run the openssl verify command above again, I get different results depending on the order of the (now) two Gareth Williams Policy CA certificates in the chain file: With -trusted Gareth_Williams_Root_CA and a chain.crt as follows (from openssl x509 -noout -subject -subject_hash -issuer -issuer_hash), openssl successfully verifies. subject= /C=GB/O=Gareth Williams/CN=Gareth Williams Policy CA ec2241cd issuer= /C=GB/O=Example/CN=Example Root CA 83507648 subject= /C=GB/O=Gareth Williams/CN=Gareth Williams Policy CA ec2241cd issuer= /C=GB/O=Gareth Williams/CN=Gareth Williams Root CA fb71fe2c subject= /C=GB/O=Gareth Williams/CN=Gareth Williams Issuing CA d4f031ac issuer= /C=GB/O=Gareth Williams/CN=Gareth Williams Policy CA ec2241cd However, if I swap the order of the two Gareth Williams Policy CA certificate OR change -trusted to Example_Root_CA.crt then openssl verify fails. It seems as if order matters in the collection of certificates passed using the -untrusted option. I was under the impression that the whole idea of this alternative chain building algorithm was that it would just figure it out itself. I've confirmed the chain works fine by configuring apache with the end-entity certificate/key and the chain certificate file at which point Firefox happily chains up to either root certificate (I installed/uninstalled each root in turn). It seems that only openssl verify complains. I believe this is identical to the issue reported and resolved in bug: https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3621 but doesn't seem to be working for me. So the million dollar question is: What's happening? Is it A) There's a regression here? B) I'm a biff? I'd go for B) myself. If you do agree with me (option B) then could someone please explain what's happening and/or what should be happening. Thanks in advance, Gareth -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4175 bytes Desc: S/MIME Cryptographic Signature URL: From openssl-users at dukhovni.org Thu Dec 31 17:12:20 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 31 Dec 2015 17:12:20 +0000 Subject: [openssl-users] openssl verify and alt_chains In-Reply-To: <56855E28.9020900@garethwilliams.me.uk> References: <56855E28.9020900@garethwilliams.me.uk> Message-ID: <20151231171220.GK18704@mournblade.imrryr.org> On Thu, Dec 31, 2015 at 04:56:08PM +0000, Gareth Williams wrote: > I now try to cross-certify by adding another Root CA (Example Root CA) and > use that to sign the original Gareth Williams Policy CA certificate signing > request, then add this new certificate to the chain.crt file: > > Gareth Williams Root CA Example Root CA > | | > Gareth Williams Policy CA Gareth Williams Policy CA > | | > +----------------+------------------+ > | > Gareth Williams Issuing CA > | > office.garethwilliams.me.uk You're not supposed to create two different untrusted intermediate certificates, include both and hope for a good outcome. OpenSSL does not try all possible untrusted intermediates at every depth in the chain, that has exponential cost in the chain depth. The alternate chain is built only when (by default) not doing "trusted first", and drops one of the previously selected untrusted certificates at a time (from the top of the chain) and looks for a match in the *trust* store. This never looks at alternative untrusted certificates. Cross-sign a roots, not an intermediates, and include the cross-signed root in the trust store. Then if a user happens to include the root CA in the chain that is not trusted but the trust store contains a cross-signed intermediate, you win. -- Viktor. From jb-openssl at wisemo.com Thu Dec 31 17:55:20 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 31 Dec 2015 18:55:20 +0100 Subject: [openssl-users] openssl verify and alt_chains In-Reply-To: <20151231171220.GK18704@mournblade.imrryr.org> References: <56855E28.9020900@garethwilliams.me.uk> <20151231171220.GK18704@mournblade.imrryr.org> Message-ID: <56856C08.30707@wisemo.com> On 31/12/2015 18:12, Viktor Dukhovni wrote: > On Thu, Dec 31, 2015 at 04:56:08PM +0000, Gareth Williams wrote: > >> I now try to cross-certify by adding another Root CA (Example Root CA) and >> use that to sign the original Gareth Williams Policy CA certificate signing >> request, then add this new certificate to the chain.crt file: >> >> Gareth Williams Root CA Example Root CA >> | | >> Gareth Williams Policy CA Gareth Williams Policy CA >> | | >> +----------------+------------------+ >> | >> Gareth Williams Issuing CA >> | >> office.garethwilliams.me.uk > You're not supposed to create two different untrusted intermediate > certificates, include both and hope for a good outcome. OpenSSL > does not try all possible untrusted intermediates at every depth > in the chain, that has exponential cost in the chain depth. I believe it would be at worst linear in the number of offered/loaded certificates, and in practice limited to much less by the number of certificates actually having multiple candidates. The other X509 libraries in common use (such as NSS) seem to cope just fine, and have presumably managed to arrange their search algorithms to not be subject to remote denial of service via combinatorial explosion. > The alternate chain is built only when (by default) not doing > "trusted first", and drops one of the previously selected untrusted > certificates at a time (from the top of the chain) and looks for > a match in the *trust* store. This never looks at alternative > untrusted certificates. > > Cross-sign a roots, not an intermediates, and include the cross-signed > root in the trust store. Then if a user happens to include the > root CA in the chain that is not trusted but the trust store contains > a cross-signed intermediate, you win. > And how would the code cope with a root that was cross signed by two other roots, and was not itself on the trust list? Wouldn't that be indistinguishable from the OP's test scenario? 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 openssl-users at dukhovni.org Thu Dec 31 18:16:54 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 31 Dec 2015 13:16:54 -0500 Subject: [openssl-users] openssl verify and alt_chains In-Reply-To: <56856C08.30707@wisemo.com> References: <56855E28.9020900@garethwilliams.me.uk> <20151231171220.GK18704@mournblade.imrryr.org> <56856C08.30707@wisemo.com> Message-ID: > On Dec 31, 2015, at 12:55 PM, Jakob Bohm wrote: > >> You're not supposed to create two different untrusted intermediate >> certificates, include both and hope for a good outcome. OpenSSL >> does not try all possible untrusted intermediates at every depth >> in the chain, that has exponential cost in the chain depth. > I believe it would be at worst linear in the number of offered/loaded > certificates, and in practice limited to much less by the number of > certificates actually having multiple candidates. I there the depth is N, and the wire chain includes 2N certificates, 2 possibilities for the issuer at each depth, then the number of potential chains is 2^N. > The other X509 libraries in common use (such as NSS) seem to cope just > fine, and have presumably managed to arrange their search algorithms to > not be subject to remote denial of service via combinatorial explosion. The other libraries run in browsers where the trust store has many intermediate certificates in it, not just the trust-anchor roots. >> Cross-sign roots, not an intermediates, and include the cross-signed >> root in the trust store. Then if a user happens to include the >> root CA in the chain that is not trusted but the trust store contains >> a cross-signed intermediate, you win. > And how would the code cope with a root that was cross signed by two > other roots, and was not itself on the trust list? Wouldn't that be > indistinguishable from the OP's test scenario? If the wire chain, possibly truncated is issued by some root or intermediate from the trust store, it works. The browsers have a suitably comprehensive trust store. In any case, there is no regression in 1.1.0, it works the same way as 1.0.2. Perhaps the algorithm could handle more cases, but that would be a new feature. -- Viktor. From gareth at garethwilliams.me.uk Thu Dec 31 21:28:44 2015 From: gareth at garethwilliams.me.uk (Gareth Williams) Date: Thu, 31 Dec 2015 21:28:44 +0000 Subject: [openssl-users] openssl verify and alt_chains In-Reply-To: References: <56855E28.9020900@garethwilliams.me.uk> <20151231171220.GK18704@mournblade.imrryr.org> <56856C08.30707@wisemo.com> Message-ID: <56859E0C.5060504@garethwilliams.me.uk> Thank you both for your responses. I changed to cross-certifying at the root and it worked as expected. However, cross-certification doesn't have to be at the root, going by RFC 4949's definition. Neither do any of my text books on the subject state that it has to be at the root CA level. Now, as Chrome on Android uses OpenSSL does this mean that this browser behaves differently to the mainstream browsers when it come across some cross-certified CAs? Namely, those who cross-certify at policy or issuing CA level? Gareth On 31/12/15 18:16, Viktor Dukhovni wrote: >> On Dec 31, 2015, at 12:55 PM, Jakob Bohm wrote: >> >>> You're not supposed to create two different untrusted intermediate >>> certificates, include both and hope for a good outcome. OpenSSL >>> does not try all possible untrusted intermediates at every depth >>> in the chain, that has exponential cost in the chain depth. >> I believe it would be at worst linear in the number of offered/loaded >> certificates, and in practice limited to much less by the number of >> certificates actually having multiple candidates. > I there the depth is N, and the wire chain includes 2N certificates, > 2 possibilities for the issuer at each depth, then the number of > potential chains is 2^N. > >> The other X509 libraries in common use (such as NSS) seem to cope just >> fine, and have presumably managed to arrange their search algorithms to >> not be subject to remote denial of service via combinatorial explosion. > The other libraries run in browsers where the trust store has many > intermediate certificates in it, not just the trust-anchor roots. > >>> Cross-sign roots, not an intermediates, and include the cross-signed >>> root in the trust store. Then if a user happens to include the >>> root CA in the chain that is not trusted but the trust store contains >>> a cross-signed intermediate, you win. >> And how would the code cope with a root that was cross signed by two >> other roots, and was not itself on the trust list? Wouldn't that be >> indistinguishable from the OP's test scenario? > If the wire chain, possibly truncated is issued by some root or > intermediate from the trust store, it works. The browsers have > a suitably comprehensive trust store. > > In any case, there is no regression in 1.1.0, it works the same > way as 1.0.2. Perhaps the algorithm could handle more cases, but > that would be a new feature. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4175 bytes Desc: S/MIME Cryptographic Signature URL: From bhat.jayalakshmi at gmail.com Thu Dec 10 11:50:15 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Thu, 10 Dec 2015 11:50:15 -0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <56694A58.4060006@openssl.org> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> Message-ID: Hi Matt Thanks for the patch. Unfortunately patch did not work. I continued debugging and found that issue was in constant_time_msb. static inline unsigned int constant_time_msb(unsigned int a) { - *return 0 - (a >> (sizeof(a) * 8 - 1));* + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); } Changed constant_time_msb implementation as shown above. All the tests passed. I have attached the dis-assembly of the code for both successful case and failure case. This was requested by Jakob. Please let me know your suggestions and inputs Regards Jaya On Thu, Dec 10, 2015 at 2:48 AM, Matt Caswell wrote: > > > On 09/12/15 23:13, Benjamin Kaduk wrote: > > On 12/09/2015 05:04 PM, Matt Caswell wrote: > >> > >> On 09/12/15 11:44, Jayalakshmi bhat wrote: > >>> Hi Matt, > >>> > >>> I could build and execute the constant_time_test. I have attached the > .c > >>> file and test results. 34 tests have failed. All failures are > >>> around constant_time_eq_8. This is the function I had mentioned in the > >>> earlier mails. > >> Not quite all. There is also a failure right at the beginning of your > >> log in constant_time_is_zero_8. Although it looks very similar to the > >> constant_time_eq_8 failure. > >> > >> As to the failure it is very strange. This is the function doing the > test: > >> > >> int test_binary_op_8(unsigned > >> char (*op) (unsigned int a, unsigned int b), > >> const char *op_name, unsigned int a, > >> unsigned int b, int is_true) > >> { > >> unsigned char c = op(a, b); > >> if (is_true && c != CONSTTIME_TRUE_8) { > >> printf( "Test failed for %s(%du, %du): expected %u " > >> "(TRUE), got %u at line %d\n", op_name, a, b, > >> CONSTTIME_TRUE_8, c,__LINE__); > >> return 1; > >> } else if (!is_true && c != CONSTTIME_FALSE_8) { > >> printf( "Test failed for %s(%du, %du): expected %u " > >> "(FALSE), got %u at line %d\n", op_name, a, b, > >> CONSTTIME_FALSE_8, c,__LINE__); > >> return 1; > >> } > >> printf( "Test passed for %s(%du, %du): expected %u got %u at line > %d > >> with %s\n", op_name, a, b, CONSTTIME_TRUE_8, > >> c,__LINE__,is_true?"TRUE":"FALSE"); > >> return 0; > >> } > >> > >> > >> and the output we see in the log file is: > >> > >> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got > >> 4294967295 at line 85 > >> > >> That big number in the output is actually 0x7FFFFFFF in hex. The > >> variable that it is printing here is "c" which is declared as an > >> "unsigned char". > >> > >> Please someone correct me if I'm wrong but doesn't the C spec guarantee > >> that a "char" is 8 bits? In which case how can the value of "c" be > >> greater than 255????? > > > > C does not make such a guarantee, though recent-ish POSIX does. (This > > system is a windows one, thought, right?) > > > > In any case, due to C's type promotion rules, it's very difficult to > > actually use types narrower than 'int', since integers get auto-promoted > > to int at integer conversion time. This has extra-fun interactions with > > varargs functions, depending on the platform ABI in use. (Always cast > > NULL to a pointer type when passing to a varargs function; this does > > cause real bugs.) Since c is unsigned, it is odd to see it get promoted > > to (int)-1, since C type conversions are supposed to be > > value-preserving, but it is certainly possible that the windows ABI is > > doing something I don't expect. Adjusting things so that the format > > specifier and the type passed to printf match (whether by casting c to > > int or qualifying the format specifier) might help. > > Thanks Ben. > > It's not 100% clear to me that we are dealing with a system where a char > has more than 8 bits, but it certainly seems like a plausible > explanation for what is going on. Especially when you look at the > implementation of constant_time_eq_8: > > static inline unsigned char constant_time_eq_8(unsigned int a, unsigned > int b) > { > return (unsigned char)(constant_time_eq(a, b)); > } > > The function "constant_time_eq" here returns an "unsigned int". The > whole purpose of "constant_time_eq_8" is to provide a convenience > function to create an 8 bit mask. If the number of bits in an unsigned > char > 8 then this code is going to fail! > > Jaya - please could you try the attached patch to see if that resolves > the problem. Please try re-executing both your SSL/TLS tests and the > constant_time test. Let me know how you get on. > > Thanks > > 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: changes.zip Type: application/zip Size: 21559 bytes Desc: not available URL: From luiz.laranjeira at gmail.com Sun Dec 27 15:01:37 2015 From: luiz.laranjeira at gmail.com (Luiz Laranjeira) Date: Sun, 27 Dec 2015 13:01:37 -0200 Subject: [openssl-users] Trouble compiling in version 0.9.8h Message-ID: I am getting the errors below. Anyone can help? Line 282 of file pkcs7.h = DECLARE_ASN1_FUNCTIONS(PKCS7_ISSUER_AND_SERIAL) 1>------ Build started: Project: OpenSSL, Configuration: Debug Win32 ------ 1> tls_srp.c 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2055: expected formal parameter list, not a type list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2085: 'PKCS7_ISSUER_AND_SERIAL_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2085: 'PKCS7_ISSUER_AND_SERIAL_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2085: 'd2i_PKCS7_ISSUER_AND_SERIAL' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2085: 'i2d_PKCS7_ISSUER_AND_SERIAL' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2085: 'PKCS7_ISSUER_AND_SERIAL_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(286): error C2085: 'PKCS7_ISSUER_AND_SERIAL_digest' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(288): error C2085: 'd2i_PKCS7_fp' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(289): error C2085: 'i2d_PKCS7_fp' : not in formal parameter list ...... 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(291): error C2085: 'PKCS7_dup' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(292): error C2085: 'd2i_PKCS7_bio' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(293): error C2085: 'i2d_PKCS7_bio' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(296): error C2085: 'PKCS7_SIGNER_INFO_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(296): error C2085: 'PKCS7_SIGNER_INFO_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(296): error C2085: 'd2i_PKCS7_SIGNER_INFO' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(296): error C2085: 'i2d_PKCS7_SIGNER_INFO' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(296): error C2085: 'PKCS7_SIGNER_INFO_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(297): error C2085: 'PKCS7_RECIP_INFO_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(297): error C2085: 'PKCS7_RECIP_INFO_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(297): error C2085: 'd2i_PKCS7_RECIP_INFO' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(297): error C2085: 'i2d_PKCS7_RECIP_INFO' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(297): error C2085: 'PKCS7_RECIP_INFO_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(298): error C2085: 'PKCS7_SIGNED_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(298): error C2085: 'PKCS7_SIGNED_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(298): error C2085: 'd2i_PKCS7_SIGNED' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(298): error C2085: 'i2d_PKCS7_SIGNED' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(298): error C2085: 'PKCS7_SIGNED_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(299): error C2085: 'PKCS7_ENC_CONTENT_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(299): error C2085: 'PKCS7_ENC_CONTENT_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(299): error C2085: 'd2i_PKCS7_ENC_CONTENT' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(299): error C2085: 'i2d_PKCS7_ENC_CONTENT' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(299): error C2085: 'PKCS7_ENC_CONTENT_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(300): error C2085: 'PKCS7_ENVELOPE_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(300): error C2085: 'PKCS7_ENVELOPE_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(300): error C2085: 'd2i_PKCS7_ENVELOPE' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(300): error C2085: 'i2d_PKCS7_ENVELOPE' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(300): error C2085: 'PKCS7_ENVELOPE_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(301): error C2085: 'PKCS7_SIGN_ENVELOPE_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(301): error C2085: 'PKCS7_SIGN_ENVELOPE_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(301): error C2085: 'd2i_PKCS7_SIGN_ENVELOPE' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(301): error C2085: 'i2d_PKCS7_SIGN_ENVELOPE' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(301): error C2085: 'PKCS7_SIGN_ENVELOPE_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(302): error C2085: 'PKCS7_DIGEST_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(302): error C2085: 'PKCS7_DIGEST_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(302): error C2085: 'd2i_PKCS7_DIGEST' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(302): error C2085: 'i2d_PKCS7_DIGEST' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(302): error C2085: 'PKCS7_DIGEST_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(303): error C2085: 'PKCS7_ENCRYPT_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(303): error C2085: 'PKCS7_ENCRYPT_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(303): error C2085: 'd2i_PKCS7_ENCRYPT' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(303): error C2085: 'i2d_PKCS7_ENCRYPT' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(303): error C2085: 'PKCS7_ENCRYPT_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(304): error C2085: 'PKCS7_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(304): error C2085: 'PKCS7_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(304): error C2085: 'd2i_PKCS7' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(304): error C2085: 'i2d_PKCS7' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(304): error C2085: 'PKCS7_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(306): error C2085: 'PKCS7_ATTR_SIGN_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(307): error C2085: 'PKCS7_ATTR_VERIFY_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(309): error C2085: 'i2d_PKCS7_NDEF' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(311): error C2085: 'PKCS7_ctrl' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(313): error C2085: 'PKCS7_set_type' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(314): error C2085: 'PKCS7_set0_type_other' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(315): error C2085: 'PKCS7_set_content' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(317): error C2085: 'PKCS7_SIGNER_INFO_set' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(318): error C2085: 'PKCS7_add_signer' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(319): error C2085: 'PKCS7_add_certificate' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(320): error C2085: 'PKCS7_add_crl' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(321): error C2085: 'PKCS7_content_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(323): error C2085: 'PKCS7_dataVerify' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(325): error C2085: 'PKCS7_signatureVerify' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(327): error C2085: 'PKCS7_dataInit' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(328): error C2085: 'PKCS7_dataFinal' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(329): error C2085: 'PKCS7_dataDecode' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(333): error C2085: 'PKCS7_add_signature' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(334): error C2085: 'PKCS7_cert_from_signer_info' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(335): error C2085: 'PKCS7_set_digest' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(336): error C2085: 'PKCS7_get_signer_info' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(338): error C2085: 'PKCS7_add_recipient' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(339): error C2085: 'PKCS7_add_recipient_info' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(340): error C2085: 'PKCS7_RECIP_INFO_set' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(341): error C2085: 'PKCS7_set_cipher' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(343): error C2085: 'PKCS7_get_issuer_and_serial' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(344): error C2085: 'PKCS7_digest_from_attributes' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(346): error C2085: 'PKCS7_add_signed_attribute' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(348): error C2085: 'PKCS7_add_attribute' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(349): error C2085: 'PKCS7_get_attribute' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(350): error C2085: 'PKCS7_get_signed_attribute' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(352): error C2085: 'PKCS7_set_signed_attributes' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(353): error C2085: 'PKCS7_set_attributes' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(357): error C2085: 'PKCS7_sign' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(359): error C2085: 'PKCS7_verify' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(360): error C2085: 'PKCS7_get0_signers' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(362): error C2085: 'PKCS7_encrypt' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(363): error C2085: 'PKCS7_decrypt' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(366): error C2085: 'PKCS7_add_attrib_smimecap' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(367): error C2085: 'PKCS7_get_smimecap' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(368): error C2085: 'PKCS7_simple_smimecap' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(370): error C2085: 'SMIME_write_PKCS7' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(371): error C2085: 'SMIME_read_PKCS7' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(372): error C2085: 'SMIME_crlf_copy' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(372): fatal error C1003: error count exceeds 100; stopping compilation On Sun, Dec 27, 2015 at 12:41 AM, David Boulding wrote: > v1.1.0-pre1 on linux > > > (1) Compiling with "no-threads " gives error on lines 173 and 379 > in async.c. > > possible cause: async_fibre_makecontext() function > > async_posix.h @ line 57: #if defined(OPENSSL_SYS_UNIX) && > defined(OPENSSL_THREADS) > > seems threads is required? > > > > (2) Compiling with no-psk and no-srp gives error on line 1692 in > statem_clnt.c > > possible cause: with no-psk and no-srp nop'd out by #ifndef's above, line > 1692 starts with "else if" instead of "if" > > > > Neither of these errors occurred in 1.0.2e. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: