[openssl.org #2728] [Bug] Regression in OpenSSL 1.0.0e causes bad_record_mac with the padlock engine set
The regression remains in OpenSSL 1.0.1-beta3. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Accessing ENGINESDIR value
Hi Dmitry, Dmitry Belyavsky wrote: Greetings! What is the correct way to get the ENGINESDIR value It is defined in opensslconf.h but it is not enough to include opensslconf.h to get it defined. Why engine directory for openssl configuration is so important ? Engine installation may depend from additional libraries . If dependent libraries are in /usr file system engine cannot be installed in root fs. Also at run time path could be overridden by OPENSSL_ENGINES environment variable. Roumen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Accessing ENGINESDIR value
Greetings! On Sat, Feb 25, 2012 at 4:23 PM, Roumen Petrov open...@roumenpetrov.info wrote: Hi Dmitry, Dmitry Belyavsky wrote: Greetings! What is the correct way to get the ENGINESDIR value It is defined in opensslconf.h but it is not enough to include opensslconf.h to get it defined. Why engine directory for openssl configuration is so important ? Engine installation may depend from additional libraries . If dependent libraries are in /usr file system engine cannot be installed in root fs. Also at run time path could be overridden by OPENSSL_ENGINES environment variable. We are going to place one corresponding file near our engine. But unfortunately we can not find the build-dependent engines dir. We can use dladdr() func to find the engine location but it seems to be wrong way :-) -- SY, Dmitry Belyavsky __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2731] Bug in OpenSSL 1.0.0g
The header file crypto/pem/pem.h is missing the empty macro: DECLARE_PEM_write_fp_const(name, type) /**/ It should be on line 328. crypto/cryptlib.c fails to compile if no-fp_api is configured due to it's reliance on stderr. crypto/des/read2pwd.c fails to compile if no-fp_api is configured due to it's reliance on BUFSIZ. The header file crypto/pem/pem.h is missing the empty macro: DECLARE_PEM_write_fp_const(name, type) /**/It should be on line 328. crypto/cryptlib.c fails to compile if no-fp_api is configured due to its reliance on stderr. crypto/des/read2pwd.c fails to compile if no-fp_api is configured due to its reliance on BUFSIZ.
[openssl.org #2732] Bug: verification fails if muliple certification path (EV/Verisign)
Hi, we get the following verification problem in our product, because some servers like signin.ebay.de, comdirect.de or meine.deutsche-bank.de add additional certicates to the chain, which are needed for some clients but not for others. Unfortunatly these are not minor companies and all of the certificates are EV. Tests done with various openssl versions from 0.9.7j up to 1.0.0a on OpenBSD and 1.0.0e and 1.0.1beta2 on Ubuntu 11.10. Details: The server sends 3 certificates (cert3, cert2 and cert1) while the client has certB and/or certR as a trusted root certificate. certR signs cert1, while certB signs cert2 by using the same public key as cert1. The certificate hierarchy as a picture: - | Cert3 | | | | | Cert2 -- | | || | Cert1 || |___|___|| || || CertR -\ CertB -\ || || cert3.pem - ..CN=meine.deutsche-bank.de - SHA1 Fingerprint=6C:F2:11:14:DC:4F:77:95:1A:67:63:E1:64:2B:AE:2F:DF:33:EB:BC cert2.pem - ..CN=VeriSign Class 3 Extended Validation SSL SGC CA - SHA1 Fingerprint=B1:80:39:89:98:31:F1:52:61:46:67:CF:23:FF:CE:A2:B0:E7:3D:AB cert1.pem - ..CN=VeriSign Class 3 Public Primary Certification Authority - G5 - SHA1 Fingerprint=29:B7:3D:9F:75:01:B8:C0:AD:FD:5E:43:37:A3:90:D1:AD:20:5F:48 certB.pem - ..CN=VeriSign Class 3 Public Primary Certification Authority - G5 - SHA1 Fingerprint=4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5 - this has the same public key as cert1, but is self signed certR.pem - C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority - SHA1 Fingerprint=74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2 - this is very old but still valid, but MD2/RSA signed and thus probably not added in some products (it's not in /etc/ssl/certs on Ubuntu 11.10) The following tests will be done - openssl verify -verbose -CAfile chain21.pem cert3.pem cat cert2.pem cert1.pem chain21.pem will FAIL because neither certB nor certR are present and so no root is found - openssl verify -verbose -CAfile chain21R.pem cert3.pem cat cert2.pem cert1.pem certR.pem chain21R.pem will SUCCEED because a complete hierarchy to the root can be found: cert3 - cert2 - cert1 - certR - openssl verify -verbose -CAfile chain2B.pem cert3.pem cat cert2.pem certB.pem chain2B.pem will SUCCEED because a complete hierarchy to the root can be found: cert3 - cert2 - certB so far everything is like expected, but it gets interesting if we have both cert1 and certB. Note that cert1 has the same public key as certB so that both certificates sign cert2. - openssl verify -verbose -CAfile chain21B.pem cert3.pem cat cert2.pem cert1.pem certB.pem chain21B.pem The expected thing is, that it will succeed because it can verify cert3 - cert2 - cert B and just ignore cert1. But it FAILs because it tries cert3 - cert2 - cert1 - .. and then it is missing certR - openssl verify -verbose -CAfile chain2B1.pem cert3.pem cat cert2.pem certB.pem cert1.pem chain2B1.pem same certificates as last test, but this time certB is before cert1. I would expect, that the order does not matter, but this SUCCEEDs because of cert3 - cert2 - certB and it ignores cert1 And this is where the bug is: one should expect, that it ignores an the unneeded cert1 in both cases, but the behavior depends on the order of the certicates in the chain. The bug causes konqueror (using openssl) to fail on certificate check, while Chrome and firefox (using NSS) succeed. At least FF seems to have certR too, but uses certB, probably because the trust chain is shorter. Opera on Linux and MSIE8 on Windows XP succeed too, also using certB and not certR for verification. A similar problem was already reported, but w/o response: http://rt.openssl.org/Ticket/Display.html?id=2634 and maybe http://rt.openssl.org/Ticket/Display.html?id=1851 is also related. If you need more information or tests please let me know. Regards, Steffen Ullrich -- GeNUA Gesellschaft für Netzwerk - und Unix-Administration mbH Domagkstr. 7, D-85551 Kirchheim. http://www.genua.de Tel: (089) 99 19 50-0, Fax: (089) 99 10 50 - 999 Geschäftsführer: Dr. Magnus Harlander, Dr. Michaela Harlander, Bernhard Schneck. Amtsgericht München HRB 98238 Certificate: Data: Version: 3 (0x2) Serial Number: 57:bf:fb:03:fb:2c:46:d4:e1:9e:ce:e0:d7:43:7f:13 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Validity Not Before: Nov 8 00:00:00 2006 GMT Not After : Nov 7 23:59:59 2021 GMT Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
Re: [openssl.org #2730] [PATCH] solving #2670 BUG
On Feb 25, 2012, at 12:01 AM, Arpadffy Zoltan wrote: Hello, BTW: Isn't SCTP support off by default (at least this is what is intended)? No, it is unfortunately not off by default. ... but applying the following patch OPENSSL_NO_SCTP is easily made default. File DKA400:[ZOLI.OPENSSL-101-BETA3]MAKEVMS.COM;2 506 $ WRITE H_FILE /* STCP support comes with TCPIP 5.7 ECO 2 507 $ WRITE H_FILE * enable on newer systems / 2012-02-24 arpadffy */ 508 $ WRITE H_FILE #define OPENSSL_NO_SCTP 509 $ WRITE H_FILE ** File DKA400:[ZOLI.OPENSSL-101-BETA3]MAKEVMS.COM;1 506 $ WRITE H_FILE OK, I must admit that we have never touched the makevms.com file (we also don't have a VMS system for testing). You are right, OPENSSL_NO_SCTP has to be defined in that file. Not sure if it is better to file a bug report through the RT tracker to make sure that a fix like yours makes it into 1.0.1. Best regards Michael Regards, Z From: Michael Tuexen [michael.tue...@lurchi.franken.de] Sent: Friday, February 24, 2012 7:49 PM To: openssl-dev@openssl.org Subject: Re: [openssl.org #2730] [PATCH] solving #2670 BUG On Feb 24, 2012, at 5:47 PM, Arpadffy Zoltan via RT wrote: Hello, Please find the included patch that solves [openssl.org #2670] [BUG] OpenSSL 1.0.1 beta 1 released (on VMS FAILED) TITAN2_ZAY $ diff USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;1 USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRY PTO.BIOBIO.H;4 File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;1 72 #include stdint.h 73 #endif ** File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;4 72 # ifndef VMS 73 # include stdint.h 74 # else 75 # include inttypes.h 76 # endif 77 #endif Also, OpenSSL version 1.0.1 Beta 3 is tested and it works very well, except that I have been forced to set #define OPENSSL_NO_SCTP BTW: Isn't SCTP support off by default (at least this is what is intended)? Best regards Michael ...because SCTP comes with TCPIP 5.7 ECO 2 and I do not have access to those systems. Regards, Z -Original Message- From: OpenSSL [mailto:open...@master.openssl.org] Sent: den 24 februari 2012 00:27 To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; openssl-us...@master.openssl.org Subject: OpenSSL 1.0.1 beta 3 released -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1 Beta 3 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The third beta is now released. This is expected to be the final beta depending on the number of bugs reported. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-1.0.1-beta3.tar.gz Size: 4451351 MD5 checksum: dc141587e0d374bdb0c7b97f770fff5e SHA1 checksum: 32105cbcc1bc6bc959102b2d70eb16ed1da732ce The checksums were calculated using the following command: openssl md5 openssl-1.0.1-beta3.tar.gz openssl sha1 openssl-1.0.1-beta3.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 55 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Also check the latest snapshots at ftp://ftp.openssl.org/snapshot/ or CVS (see http://www.openssl.org/source/repos.html) to avoid reporting previously fixed bugs. Since the second beta the following has happened: - Improved TLS v1.2 client authentication interop. - MDC2 signature format compatibility fix. - ABI compatibility fixes. - Other fixes. Reports and patches should be sent to openssl-b...@openssl.org. Discussions around the development of OpenSSL should be sent to openssl-dev@openssl.org. Anything else should go to openssl-us...@openssl.org. The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBT0bJ2qLSm3vylcdZAQJv1Qf9G5Vf7BgbdhHW+psSd3s6Z8zeijxSkZl1 cue84LkJEDRr7Tkbyk2eGuLR5cNiuH5u9waPlf31zCWsoh2cOl2fMDm+3LTB6Wqk 9zU8gkaarUFZxYxbRJa2VVDTOEzbW/qO/Gabjt/dkh/0xb2iKZvTVGr8G8xK0PVN aYhehHEHl6yxJv2V8uPZgxOC0KIMRXIj3zy/Db/Aeu9FRH1vFCHg4o+HjvaMfXRd
