Re: openssl-1.0.0a and glibc detected sthg ;)
is the certificate at http://marc.info/?l=openssl-dev&m=128118163216952&w=2 (with the malformed key) *syntactically* correct modulo the bad self signature? with 1.0.0a ~/local/bin/openssl verify -check_ss_sig -CAfile /tmp/CA-P.cert /tmp/CA-P.cert /tmp/CA-P.cert: CN = CA error 7 at 0 depth lookup:certificate signature failure 139828504536744:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100: 139828504536744:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:699: 139828504536744:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:184: echo $? 0 i would expect an error about bad self signature, not format stuff. the private key was generated by a python wrapper, the cert was generated with ubuntu's 0.9.8k 25 Mar 2009 On Sun, Aug 08, 2010 at 03:21:34PM +0200, Mounir IDRASSI wrote: __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2315] PSS certificates with keysize n*8+1 don't validate
Hi, I was not able to reproduce your problem using the same snapshot. I run your commands a dozen times with no error. Tested under Linux 32-bit (Centos 5, gcc 4.1.2) and Linux 64-bit (Debian 5, gcc 4.3.2). What platform/compiler are you using? How does your openssl.cnf look like? In my tests, I use the one installed by the snapshot build. Is anyone else able to reproduce this problem? -- Mounir IDRASSI IDRIX http://www.idrix.fr On 8/8/2010 9:40 PM, Hanno Boeck via RT wrote: > It seems that openssl has a problem with pss certificates and uncommon rsa key > sizes. For all keysizes with "keysize mod 8 = 1" (or keysize = n*8+1), > verification of a self-signed test cert fails. > > I've not yet investigated if it's the generation or the verification code that > is wrong, it's probably related to the emBits variable from the emsa-pss- > verify/encode-code. > > Check with this: > openssl genrsa 2007> test.key > openssl req -batch -new -x509 -sigopt rsa_padding_mode:pss -nodes -days 9 > -key test.key> test.crt > openssl verify -check_ss_sig -CAfile test.crt test.crt > > Output of the last command is: > 139831192893096:error:0407E06D:rsa routines:RSA_verify_PKCS1_PSS:data too > large:rsa_pss.c:127: > 139831192893096:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP > lib:a_verify.c:215: > > > Tested with openssl-SNAP-20100808. > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2315] PSS certificates with keysize n*8+1 don't validate
Hi, I was not able to reproduce your problem using the same snapshot. I run your commands a dozen times with no error. Tested under Linux 32-bit (Centos 5, gcc 4.1.2) and Linux 64-bit (Debian 5, gcc 4.3.2). What platform/compiler are you using? How does your openssl.cnf look like? In my tests, I use the one installed by the snapshot build. Is anyone else able to reproduce this problem? -- Mounir IDRASSI IDRIX http://www.idrix.fr On 8/8/2010 9:40 PM, Hanno Boeck via RT wrote: It seems that openssl has a problem with pss certificates and uncommon rsa key sizes. For all keysizes with "keysize mod 8 = 1" (or keysize = n*8+1), verification of a self-signed test cert fails. I've not yet investigated if it's the generation or the verification code that is wrong, it's probably related to the emBits variable from the emsa-pss- verify/encode-code. Check with this: openssl genrsa 2007> test.key openssl req -batch -new -x509 -sigopt rsa_padding_mode:pss -nodes -days 9 -key test.key> test.crt openssl verify -check_ss_sig -CAfile test.crt test.crt Output of the last command is: 139831192893096:error:0407E06D:rsa routines:RSA_verify_PKCS1_PSS:data too large:rsa_pss.c:127: 139831192893096:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:215: Tested with openssl-SNAP-20100808. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2315] PSS certificates with keysize n*8+1 don't validate
It seems that openssl has a problem with pss certificates and uncommon rsa key sizes. For all keysizes with "keysize mod 8 = 1" (or keysize = n*8+1), verification of a self-signed test cert fails. I've not yet investigated if it's the generation or the verification code that is wrong, it's probably related to the emBits variable from the emsa-pss- verify/encode-code. Check with this: openssl genrsa 2007 > test.key openssl req -batch -new -x509 -sigopt rsa_padding_mode:pss -nodes -days 9 -key test.key > test.crt openssl verify -check_ss_sig -CAfile test.crt test.crt Output of the last command is: 139831192893096:error:0407E06D:rsa routines:RSA_verify_PKCS1_PSS:data too large:rsa_pss.c:127: 139831192893096:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:215: Tested with openssl-SNAP-20100808. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2314] [PATCH] fix double free in ssl3_get_key_exchange in case of error
Hi, This patch corrects a double free bug in ssl3_get_key_exchange (s3_clnt.c) when an error happens during the connection to a server. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr --- E:/dev/libraries/openssl-1.0.latest/ssl/s3_clnt.c.original Sun Feb 28 01:24:24 2010 +++ E:/dev/libraries/openssl-1.0.latest/ssl/s3_clnt.c Sun Aug 8 14:49:30 2010 @@ -1508,6 +1508,7 @@ s->session->sess_cert->peer_ecdh_tmp=ecdh; ecdh=NULL; BN_CTX_free(bn_ctx); + bn_ctx = NULL; EC_POINT_free(srvr_ecpoint); srvr_ecpoint = NULL; }
Re: [openssl-dev] Re: How to locate the X.509 specifications
Hodie VII Id. Aug. MMX, David Shambroom scripsit: > See: > > http://www.ietf.org/rfc/rfc5280.txt RFC5280 is only a profile for X.509 certificates and CRLs, just were RFC3280 and RFC2459 before it. Hopefully, RFC5280 is of better quality than its predecessors, but doesn't replace the standard at all. It adds more constraints, some of them are unnecessary (for example an organizationName or a commonName limited to 64 characters). RFC acts on top of X.509, and only for public key certificates (i.e. not attribute certificates). > Kyle Hamilton wrote: > >I was asked this morning where to find the X.509 specification, > >since http://itu.int/ is such a messy website. It's sad the 2008 version is only available for a fee. I always thought the free 2005 version (and corresponding X.5xx standards covering other important aspects) was a good thing to help development. -- Erwann ABALEA Département R&D KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com - scanf() is evil. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl-1.0.0a and glibc detected sthg ;)
Hi, You are right : there is a double free bug in the function *ssl3_get_key_exchange* which leads to crash if an error occurs. The bug is in line 1510 of s3_clnt.c where we forget to set the variable bn_ctx to NULL after freeing it and this leads to the double free error when BN_CTX_free is called a second time on line 1650. I'm attaching a patch against the latest source that corrects this. I'll also send to RT. Thanks for the report. -- Mounir IDRASSI IDRIX http://www.idrix.fr On 8/8/2010 3:04 PM, Georgi Guninski wrote: i was pointing out this: ~/local/bin/openssl s_client -connect localhost: depth=0 CN = CA verify return:1 *** glibc detected *** /home/build/local/bin/openssl: double free or corruption (fasttop): 0x00979300 *** the glibc message means that the current heap operation is on invalid pointer. the testcase crashed browser links on arch linux too (when trying to connect to s_server -www). btw, it seems *important* to use |s_server| from *1.0.0a* On Sat, Aug 07, 2010 at 02:21:09PM +0300, Georgi Guninski wrote: openssl-1.0.0a on ubuntu, debian and arch. attached a private key and a cert. ~/local/bin/openssl s_server -www -accept -cert /tmp/CA.cert -key /tmp/CA.key ~/local/bin/openssl s_client -connect localhost: depth=0 CN = CA verify return:1 *** glibc detected *** /home/build/local/bin/openssl: double free or corruption (fasttop): 0x00979300 *** __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org --- E:/dev/libraries/openssl-1.0.latest/ssl/s3_clnt.c.original Sun Feb 28 01:24:24 2010 +++ E:/dev/libraries/openssl-1.0.latest/ssl/s3_clnt.c Sun Aug 8 14:49:30 2010 @@ -1508,6 +1508,7 @@ s->session->sess_cert->peer_ecdh_tmp=ecdh; ecdh=NULL; BN_CTX_free(bn_ctx); + bn_ctx = NULL; EC_POINT_free(srvr_ecpoint); srvr_ecpoint = NULL; }
Re: openssl-1.0.0a and glibc detected sthg ;)
i was pointing out this: ~/local/bin/openssl s_client -connect localhost: depth=0 CN = CA verify return:1 *** glibc detected *** /home/build/local/bin/openssl: double free or corruption (fasttop): 0x00979300 *** the glibc message means that the current heap operation is on invalid pointer. the testcase crashed browser links on arch linux too (when trying to connect to s_server -www). btw, it seems *important* to use |s_server| from *1.0.0a* On Sat, Aug 07, 2010 at 02:21:09PM +0300, Georgi Guninski wrote: > openssl-1.0.0a on ubuntu, debian and arch. > attached a private key and a cert. > > ~/local/bin/openssl s_server -www -accept -cert /tmp/CA.cert -key > /tmp/CA.key > > ~/local/bin/openssl s_client -connect localhost: > > depth=0 CN = CA > verify return:1 > *** glibc detected *** /home/build/local/bin/openssl: double free or > corruption (fasttop): 0x00979300 *** > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to locate the X.509 specifications
See: http://www.ietf.org/rfc/rfc5280.txt Kyle Hamilton wrote: I was asked this morning where to find the X.509 specification, since http://itu.int/ is such a messy website. I'll point you to the general location, because it's a better piece of information to have than the exact location. (There are other recommendations that X.509 refers to, and being able to find *all* of them is key to being able to understand the spec.) The sector that we are interested in is called "ITU-T, Standardization" (as opposed to ITU-R, Radiocommunications). http://www.itu.int/en/ITU-T/publications/Pages/recs.aspx To get to X.509 from there, click the 'X' (above Y and Z), for 'Data networks, open system communications and security". That'll take you to: http://www.itu.int/itu-t/recommendations/index.aspx?ser=X . This is a tree view; you want the node labelled 'X.500-X.599: Directory'. Then, select X.509 (it's the third in the tree). The 11/2008 version (Edition 6) is only available for a fee (85 Swiss Francs), and so the version that I work from is Edition 5 (which is available for no fee). And, according to XE.com, CHF 1,00 represents USD $0.9626 at midmarket rates today (2010/08/07). -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org