Re: [openssl.org #3002] Communication problems with 1.0.1e
Actually my intention was to test if the problem can be reproduced with *same binary*. That's why I suggested that you, Kurt, compile one and hand it to user. Other way around would also work, i.e. user hands over the binary. This is because I don't exclude possibility for compiler bug... Note that Debian is a binary distribution. So all users were already running the same binary that I build. Yet some people see the problem while most don't. I understand that, but it simply sounded that user at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702635#50 built own binaries. I probably make too many assumptions and should stop doing that. Anyway, other users confirm that http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9ab3ce124616cb12bd39c6aa1e1bde0f46969b29 solves the problem. Thanks for additional information. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3005] Invalid cpuid on Cyrix
As soon as user can confirm that http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=5702e965d759dde8a098d8108660721ba2b93a7d does the trick, it goes to stable branches. Yes, the user confirmed that this fixed the issue. Populated. For reference. Original report effectively said it's CyrixInstead and ecx is 0x64616574. Note that in ASCII ecx reads tead or last four characters of CPU name. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3004] Intermittent MASM compilation failures in OpenSSL 1.0.1e VC-WIN64A build
The commit has a typo, the second line should read *STDOUT=*OUT;. The fix works, thanks! Yes, it was fixed few minutes after. Dismissing the case. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3020] openssl hang
Hello! I'm using OpenSSL 1.0.1c on a 64bit Gentoo Linux, and there is a server which hangs after sending the first packet. The server does not support TLS 1.1 or 1.2, only 1.0. Opera with TLS 1.2 enabled, and Internet Explorer with TLS 1.2 enabled does not hang. Test code: $ echo -en 'GET /scripts/zanox.js HTTP/1.0\r\nHost: static.zanox.com\r\n\r\n' | openssl s_client -debug -tlsextdebug -tls1_2 -connect static.zanox.com:https -ign_eof CONNECTED(0003) write to 0x41192a07730 [0x41192a11263] (322 bytes = 322 (0x142)) - 16 03 01 01 3d 01 00 01-39 03 03 51 47 41 4b e7 =...9..QGAK. 0010 - 3c 72 9c 22 37 9a 34 5b-be 06 71 35 6d ee b5 68 r.7.4[..q5m..h 0020 - 7c 3a 47 25 dd 49 82 25-2e a6 17 00 00 a0 c0 30 |:G%.I.%...0 0030 - c0 2c c0 28 c0 24 c0 14-c0 0a c0 22 c0 21 00 a3 .,.(.$..!.. 0040 - 00 9f 00 6b 00 6a 00 39-00 38 00 88 00 87 c0 32 ...k.j.9.8.2 0050 - c0 2e c0 2a c0 26 c0 0f-c0 05 00 9d 00 3d 00 35 ...*=.5 0060 - 00 84 c0 12 c0 08 c0 1c-c0 1b 00 16 00 13 c0 0d 0070 - c0 03 00 0a c0 2f c0 2b-c0 27 c0 23 c0 13 c0 09 ./.+.'.# 0080 - c0 1f c0 1e 00 a2 00 9e-00 67 00 40 00 33 00 32 .g.@.3.2 0090 - 00 9a 00 99 00 45 00 44-c0 31 c0 2d c0 29 c0 25 .E.D.1.-.).% 00a0 - c0 0e c0 04 00 9c 00 3c-00 2f 00 96 00 41 00 07 /...A.. 00b0 - c0 11 c0 07 c0 0c c0 02-00 05 00 04 00 15 00 12 00c0 - 00 09 00 14 00 11 00 08-00 06 00 03 00 ff 02 01 00d0 - 00 00 6f 00 0b 00 04 03-00 01 02 00 0a 00 34 00 ..o...4. 00e0 - 32 00 0e 00 0d 00 19 00-0b 00 0c 00 18 00 09 00 2... 00f0 - 0a 00 16 00 17 00 08 00-06 00 07 00 14 00 15 00 0100 - 04 00 05 00 12 00 13 00-01 00 02 00 03 00 0f 00 0110 - 10 00 11 00 23 00 00 00-0d 00 22 00 20 06 01 06 #.. ... 0120 - 02 06 03 05 01 05 02 05-03 04 01 04 02 04 03 03 0130 - 01 03 02 03 03 02 01 02-02 02 03 01 01 00 0f 00 0140 - 01 01 .. connection hangs at this point smime.p7s Description: S/MIME cryptographic signature
[openssl.org #3020] openssl hang
On Mon Mar 18 20:37:23 2013, zhala...@loginet.hu wrote: Hello! I'm using OpenSSL 1.0.1c on a 64bit Gentoo Linux, and there is a server which hangs after sending the first packet. The server does not support TLS 1.1 or 1.2, only 1.0. Opera with TLS 1.2 enabled, and Internet Explorer with TLS 1.2 enabled does not hang. This is a known bug in some servers, see PR#2771. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] Shouldn't CSRs automatically add default version?
On Mon, Mar 18, 2013 at 5:42 AM, Erwann Abalea
erwann.aba...@keynectis.com wrote:
That CSR is clearly invalid, because one of its objects isn't properly DER
encoded.
This is precisely my point. All of the OpenSSL calls I make succeed
including PEM_write_X509_REQ. Either,
- the call to PEM_write_X509_REQ should fail indicating that it can't
construct valid ASN.1 because the structure lacks a version
- or the X509_REQ should encode a default version of 0 in the event
the user failed to specify.
As it stands, it is possible to sail through successful calls to the
OpenSSL API and end up with something invalid. This violates the the
principle of least surprise.
:{
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: OpenSSL server downtime
On 03/17/2013 04:15 PM, David Woodhouse wrote: On Fri, 2013-03-15 at 17:17 +0100, Lutz Jaenicke wrote: The new server currently hosting the www, git, rt, ftp, and cvs services is going to be moved within the installation of our hoster. As a consequence, the system will be assigned a new IP address. Old: 178.16.220.54 New: 185.9.166.106 Still only Legacy IP and not IPv6? Any plans to join us in the 21st century? (Although I am thankful that at least the version control has done so :) As you already pointed out, the OpenSSL team is able to perform a major change or two within a decade. Hence, there is still hope. Seriously: our admin resources (that's mostly me with the help of Steve Marquess :-) are somewhat limited and I still have two major tasks open: migrate the mailing lists (which are obviously vital for our community) and finally move over the name server. I would not like the idea to bring up IPv6 as another complication before this is finished. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Adding support to verify TPM certificates with AKID serial mismatches
Hello openssl-dev. I've run into an issue using OpenSSL to verify a certificate chain from an Infineon TPM endorsement key. This is not an OpenSSL bug, but rather an issue handling certificates deployed in the wild. I believe Infineon may have published intermediate certificates with an invalid serial number in the X509v3 Authority Identifier. These are being properly rejected in X509_check_akid(). Unfortunately, I'm stuck using these certificates and would like to continue using OpenSSL to verify them. I've written a small change (see below) to handle this, but is there any recommended workaround? Infineon's EK intermediate certificates (e.g. IFX08.pem), their root certificate (IFX-root.pem), and their issuer Verisign's certificate (VRSN-root.pem) are posted on this page: http://www.infineon.com/cms/en/product/chip-card-and-security-ics/embedded-security/trusted-computing/trusted-platform-module-tpm1.2-pc/channel.html?channel=ff80808112ab681d0112ab6921ae011f#db3a304412b407950112b4165f462052 I've attached these as files in this message as well. You can see that the AKID in IFX08 is: X509v3 Authority Key Identifier: keyid:56:EB:91:44:85:63:D6:72:B3:AE:D4:45:96:0B:F7:94:0E:54:42:A6 DirName:/C=DE/ST=Bavaria/O=Infineon Technologies AG/OU=AIM/CN=IFX TPM EK Root CA serial:03 The authority keyid matches the IFX-root key's SKID. However, the 03 serial number doesn't appear to be correct and is rejected by X509_check_akid. This same problem has apparently come up for people with other certificates, e.g.: http://www.mail-archive.com/openssl-users@openssl.org/msg62131.html As a workaround, I added a flag to make check_issuer more lenient and ignore issuer serial mismatches. See the attached patch. The usage is as follows: $ openssl verify -CApath /path/to/my/certs IFX08.pem IFX08.pem: C = DE, ST = Saxony, O = Infineon Technologies AG, OU = AIM, CN = IFX TPM EK Intermediate CA 08 error 20 at 0 depth lookup:unable to get local issuer certificate $ openssl verify -ignore_akid_issuer_serial_mismatch -CApath /path/to/my/certs IFX08.pem IFX08.pem: OK Thanks for any help or suggestions. IFX08.pem Description: Binary data IFX-root.pem Description: Binary data VRSN-root.pem Description: Binary data lenient-x509-check.patch Description: Binary data
