RE: OCB Authenticated Encryption
There are actually two licenses. The second allows all software (even closed), but only for non-military use. I would say that's still a problem. For example, we could use OpenSSL on our network to provide acceleration for public DoD sites. Is that military use? Suppose it's for use on a CIA extranet? Suppose it's for use on an internal FBI network linking field offices to HQ? To the CIA doing the same thing internationally? How do I decide? How does the OpenSSL team set things up so that their (yes, yes, non-paying) customers don't do the wrong thing by default? If you want to limit the use of your invention, which is entirely your right, it is best to distribute it yourself. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OCB Authenticated Encryption
On 02/06/2013 09:43 AM, Salz, Rich wrote: There are actually two licenses. The second allows all software (even closed), but only for non-military use. I would say that's still a problem. For example, we could use OpenSSL on our network to provide acceleration for public DoD sites. Is that military use? Suppose it's for use on a CIA extranet? Suppose it's for use on an internal FBI network linking field offices to HQ? To the CIA doing the same thing internationally? How do I decide? How does the OpenSSL team set things up so that their (yes, yes, non-paying) customers don't do the wrong thing by default? If you want to limit the use of your invention, which is entirely your right, it is best to distribute it yourself. +1. The intent is noble but the practical implications get messy very quickly. For better or worse OpenSSL is very widely used, for good as well as evil, and the licensing situation is muddled enough as it is. Personally I think the existence and unrestricted availability of OpenSSL benefits the good far more than evil. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Major OpenSSL 1.0.1d regression from 1.0.1c
It appears there is a major regression with OpenSSL 1.0.1d over 1.0.1c. I've narrowed it down to setting a custom cipher list I think as if I do not set a cipher list, the issue does not occur. I have reproduced the issue with the openssl s_server/s_client command line utility. You can see my full procedure below. In short, it appears SSL negotiation succeeds, but as soon as data is sent from the client to the server, the server spits out: 67397216:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:482: And does NOT receive the data sent from the client side. Infact, I'm seeing some very strange behavior indeed. For whatever reason, if I run it under valgrind, it consistently gives that error (yet valgrind reports nothing), but if I do NOT run it under valgrind, sometimes I receive CORRUPT data and no error message is reported at all. I should also note that currently I am using OpenSSL 1.0.1d-fips 5 Feb 2013 On an Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz running Ubuntu 12.04 64bit (so presumably I'm using AES-NI ... noticed changes to that in the changelog). I have not yet tried to compile it in non-FIPS mode to rule that out, but I am not running it in an active FIPS mode. I have reproduced this issue on Linux x64 and Windows x86 thus far, I haven't tested it on any other system. == CERTIFICATE GEN == $ ./openssl genrsa 2048 mycert.key Generating RSA private key, 2048 bit long modulus ..+++ +++ $ ./openssl req -new -key mycert.key mycert.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Florida Locality Name (eg, city) []:Gainesville Organization Name (eg, company) [Internet Widgits Pty Ltd]:TEST Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []:localhost Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: $ ./openssl req -x509 -key mycert.key -in mycert.csr mycert.crt == SERVER == $ ./openssl s_server -cipher 'TLSv1+HIGH:@STRENGTH' -key ./mycert.key -cert ./mycert.crt -no_ssl2 -no_ticket Using default temp DH parameters Using default temp ECDH parameters ACCEPT -BEGIN SSL SESSION PARAMETERS- MHUCAQECAgMDBALAFAQgont/MsqFPRiz/6fzhDSnmb5Cqw9V8oHUy68q6J1KFIsE MLxPYXZPn/SKgGWxbiqLLJVmb+oNNvRNc6B/HpWl8zTs9TLTxVqiDdOft4OGH2XJ jqEGAgRREpCKogQCAgEspAYEBAE= -END SSL SESSION PARAMETERS- Shared ciphers:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:SRP-AES-256-CBC-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:AECDH-DES-CBC3-SHA:SRP-3DES-EDE-CBC-SHA:ADH-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:SRP-AES-128-CBC-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-SHA:CAMELLIA128-SHA CIPHER is ECDHE-RSA-AES256-SHA Secure Renegotiation IS supported ERROR 67397216:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:482: shutting down SSL CONNECTION CLOSED ACCEPT == CLIENT == $ echo Hello World | ./openssl s_client -connect localhost:4433 -cipher 'TLSv1+HIGH:@STRENGTH' CONNECTED(0003) depth=0 C = US, ST = Florida, L = Gainesville, O = TEST, CN = localhost verify error:num=18:self signed certificate verify return:1 depth=0 C = US, ST = Florida, L = Gainesville, O = TEST, CN = localhost verify return:1 --- Certificate chain 0 s:/C=US/ST=Florida/L=Gainesville/O=TEST/CN=localhost i:/C=US/ST=Florida/L=Gainesville/O=TEST/CN=localhost --- Server certificate -BEGIN CERTIFICATE- MIIDgzCCAmugAwIBAgIJAJKZKgvR+qGgMA0GCSqGSIb3DQEBBQUAMFgxCzAJBgNV BAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRQwEgYDVQQHDAtHYWluZXN2aWxsZTEN MAsGA1UECgwEVEVTVDESMBAGA1UEAwwJbG9jYWxob3N0MB4XDTEzMDIwNjE3MTcw OVoXDTEzMDMwODE3MTcwOVowWDELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExFDASBgNVBAcMC0dhaW5lc3ZpbGxlMQ0wCwYDVQQKDARURVNUMRIwEAYDVQQD
Re: Major OpenSSL 1.0.1d regression from 1.0.1c
On 02/06/2013 12:30 PM, Brad House wrote: ...snip... I should also note that currently I am using OpenSSL 1.0.1d-fips 5 Feb 2013 On an Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz running Ubuntu 12.04 64bit (so presumably I'm using AES-NI ... noticed changes to that in the changelog). I have not yet tried to compile it in non-FIPS mode to rule that out, but I am not running it in an active FIPS mode. I have reproduced this issue on Linux x64 and Windows x86 thus far, I haven't tested it on any other system. ...snip... I have reproduced the issue with a stock build as well following the procedure below. The stock build does seem to have a couple of behavioral differences. First, I can reproduce the issue now on the server side without specifying the cipher as long as the client side does specify the cipher suite. Next, I can only get the actual error message to be reported when running under valgrind... however, the corruption is ALWAYS there when not running under valgrind. I can see it exhibited by a random character before the word DONE on the server side after my Hello World is printed out that was sent from the client side. Using older versions did not exhibit this behavior. Perhaps the issue is in the ECDHE-RSA-AES256-SHA cipher suite which is being chosen... when it uses ECDHE-RSA-AES256-GCM-SHA384 when no cipher suite is specified, everything is OK (e.g. no valgrind errors and no random character). Here are examples of that random corruption character I see before the word DONE: = Secure Renegotiation IS supported Hello World JDONE shutting down SSL = Secure Renegotiation IS supported Hello World �DONE shutting down SSL = Secure Renegotiation IS supported Hello World 2DONE shutting down SSL = Secure Renegotiation IS supported Hello World PDONE shutting down SSL = Here's how the binary was built: cd /tmp \ wget http://www.openssl.org/source/openssl-1.0.1d.tar.gz \ tar -zxvpf openssl-1.0.1d.tar.gz \ cd openssl-1.0.1d \ ./config threads shared --prefix=/usr/local/ssl-1.0.1d \ make \ make test \ sudo make install \ rm -rf openssl-1.0.1d openssl-1.0.1d.tar.gz $ ldd /usr/local/ssl-1.0.1d/bin/openssl linux-vdso.so.1 = (0x7fffec5ff000) libssl.so.1.0.0 = /usr/local/ssl-1.0.1d/lib/libssl.so.1.0.0 (0x7f79cdf97000) libcrypto.so.1.0.0 = /usr/local/ssl-1.0.1d/lib/libcrypto.so.1.0.0 (0x7f79cdbbc000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f79cd7dd000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f79cd5d9000) /lib64/ld-linux-x86-64.so.2 (0x7f79ce203000) $ /usr/local/ssl-1.0.1d/bin/openssl version OpenSSL 1.0.1d 5 Feb 2013 Thanks. -Brad __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Major OpenSSL 1.0.1d regression from 1.0.1c
On Wed, Feb 06, 2013, Brad House wrote: On 02/06/2013 12:30 PM, Brad House wrote: ...snip... I should also note that currently I am using OpenSSL 1.0.1d-fips 5 Feb 2013 On an Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz running Ubuntu 12.04 64bit (so presumably I'm using AES-NI ... noticed changes to that in the changelog). I have not yet tried to compile it in non-FIPS mode to rule that out, but I am not running it in an active FIPS mode. I have reproduced this issue on Linux x64 and Windows x86 thus far, I haven't tested it on any other system. ...snip... I have reproduced the issue with a stock build as well following the procedure below. The stock build does seem to have a couple of behavioral differences. First, I can reproduce the issue now on the server side without specifying the cipher as long as the client side does specify the cipher suite. Next, I can only get the actual error message to be reported when running under valgrind... however, the corruption is ALWAYS there when not running under valgrind. I can see it exhibited by a random character before the word DONE on the server side after my Hello World is printed out that was sent from the client side. Using older versions did not exhibit this behavior. Perhaps the issue is in the ECDHE-RSA-AES256-SHA cipher suite which is being chosen... when it uses ECDHE-RSA-AES256-GCM-SHA384 when no cipher suite is specified, everything is OK (e.g. no valgrind errors and no random character). A possibility is the AESNI+SHA1 stitched code which is handled as a special case. You'd only see that with AES+SHA1 ciphersuites on AES-NI supporting processors. Try disabling AES-NI with OPENSSL_ia32cap=~0x202 also try entering FIPS mode for a FIPS build with OPENSSL_FIPS=1. Finally you could try reverting the last changes to e_aes_cbc_hmac_sha1.c for test purposes: note this will also make you vulnerable to CVE-2013-0169 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: Major OpenSSL 1.0.1d regression from 1.0.1c
On 02/06/2013 01:37 PM, Dr. Stephen Henson wrote: A possibility is the AESNI+SHA1 stitched code which is handled as a special case. You'd only see that with AES+SHA1 ciphersuites on AES-NI supporting processors. DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be a -SHA issue as the only -SHA cipher I've gotten to work so far is RC4-SHA. Note though the TLSv1.2+HIGH ciphers that use SHA256 and greater look fine. Try disabling AES-NI with OPENSSL_ia32cap=~0x202 also try entering FIPS mode for a FIPS build with OPENSSL_FIPS=1. The OPENSSL_ia32cap appears to make it return the error message instead of corruption all the time even when not under valgrind. OPENSSL_FIPS=1 doesn't appear to do anything different (except if I try to use the DHE-RSA-CAMELLIA256-SHA as the ciphersuite it doesn't let me in FIPS mode ... guess that's expected). Finally you could try reverting the last changes to e_aes_cbc_hmac_sha1.c for test purposes: note this will also make you vulnerable to CVE-2013-0169 I copied that file over from OpenSSL 1.0.1c's tarball and just overwrote the 1.0.1d version and rebuilt. No change. Have you not been able to reproduce this issue? I've seen it on more than one machine. Thanks. -Brad __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Major OpenSSL 1.0.1d regression from 1.0.1c
On Wed, Feb 06, 2013, Brad House wrote: On 02/06/2013 01:37 PM, Dr. Stephen Henson wrote: A possibility is the AESNI+SHA1 stitched code which is handled as a special case. You'd only see that with AES+SHA1 ciphersuites on AES-NI supporting processors. DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be a -SHA issue as the only -SHA cipher I've gotten to work so far is RC4-SHA. Note though the TLSv1.2+HIGH ciphers that use SHA256 and greater look fine. Hmmm... if it's a problem with the CVE-2013-0169 it would appear when you select a ciphersuites using a block cipher. So AES would exhibit it but not RC4 and not AES-GCM. Possibly a problem with the constant time SHA1 code but then shouldn't get that in FIPS mode weird. In ssl/s3_cbc.c and the function ssl3_cbc_record_digest_supported try setting it to return 0 when NID_sha1 is passed. Have you not been able to reproduce this issue? I've seen it on more than one machine. I've not seen it yet, no. Do you get the same problem with OpenSSL 1.0.0k? 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
1.0.1d broke startTLS with LDAP
After rebuilding my OpenLDAP servers against 1.0.1d, my perl scripts can no longer negotiate startTLS with the OpenLDAP server, and hang infinitely. This is a major regression vs 1.0.1c. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Major OpenSSL 1.0.1d regression from 1.0.1c
* Dr. Stephen Henson st...@openssl.org [2013-02-06 20:14]: On Wed, Feb 06, 2013, Brad House wrote: DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be a -SHA issue as the only -SHA cipher I've gotten to work so far is RC4-SHA. Note though the TLSv1.2+HIGH ciphers that use SHA256 and greater look fine. Hmmm... if it's a problem with the CVE-2013-0169 it would appear when you select a ciphersuites using a block cipher. I'm (most probably) seeing the same issue with the pre-shared key cipher suites PSK-AES256-CBC-SHA, PSK-AES128-CBC-SHA, and PSK-3DES-EDE-CBC-SHA. PSK-RC4-SHA works fine. As git bisect revealed, the culprit is indeed commit 125093b59f3c. Reverting it fixes the issue. In ssl/s3_cbc.c and the function ssl3_cbc_record_digest_supported try setting it to return 0 when NID_sha1 is passed. This doesn't help. Do you get the same problem with OpenSSL 1.0.0k? No. Holger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Major OpenSSL 1.0.1d regression from 1.0.1c
On 02/06/2013 02:14 PM, Dr. Stephen Henson wrote: On Wed, Feb 06, 2013, Brad House wrote: On 02/06/2013 01:37 PM, Dr. Stephen Henson wrote: A possibility is the AESNI+SHA1 stitched code which is handled as a special case. You'd only see that with AES+SHA1 ciphersuites on AES-NI supporting processors. DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be a -SHA issue as the only -SHA cipher I've gotten to work so far is RC4-SHA. Note though the TLSv1.2+HIGH ciphers that use SHA256 and greater look fine. Hmmm... if it's a problem with the CVE-2013-0169 it would appear when you select a ciphersuites using a block cipher. So AES would exhibit it but not RC4 and not AES-GCM. Possibly a problem with the constant time SHA1 code but then shouldn't get that in FIPS mode weird. In ssl/s3_cbc.c and the function ssl3_cbc_record_digest_supported try setting it to return 0 when NID_sha1 is passed. I'll try modifying ssl/s3_cbc.c in 1.0.1d in a follow-up. Have you not been able to reproduce this issue? I've seen it on more than one machine. I've not seen it yet, no. Do you get the same problem with OpenSSL 1.0.0k? I just tried 1.0.0k, it is fine. No issues there. -Brad __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Major OpenSSL 1.0.1d regression from 1.0.1c
On 02/06/2013 03:07 PM, Holger Weiß wrote: * Dr. Stephen Henson st...@openssl.org [2013-02-06 20:14]: On Wed, Feb 06, 2013, Brad House wrote: DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be a -SHA issue as the only -SHA cipher I've gotten to work so far is RC4-SHA. Note though the TLSv1.2+HIGH ciphers that use SHA256 and greater look fine. Hmmm... if it's a problem with the CVE-2013-0169 it would appear when you select a ciphersuites using a block cipher. I'm (most probably) seeing the same issue with the pre-shared key cipher suites PSK-AES256-CBC-SHA, PSK-AES128-CBC-SHA, and PSK-3DES-EDE-CBC-SHA. PSK-RC4-SHA works fine. As git bisect revealed, the culprit is indeed commit 125093b59f3c. Reverting it fixes the issue. I'll revert 125093b59f3c and test as well. In ssl/s3_cbc.c and the function ssl3_cbc_record_digest_supported try setting it to return 0 when NID_sha1 is passed. This doesn't help. I agree, just tried it, still see the corruption symptom. -Brad __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Major OpenSSL 1.0.1d regression from 1.0.1c
On 02/06/2013 03:21 PM, Brad House wrote: On 02/06/2013 03:07 PM, Holger Weiß wrote: * Dr. Stephen Henson st...@openssl.org [2013-02-06 20:14]: On Wed, Feb 06, 2013, Brad House wrote: DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be a -SHA issue as the only -SHA cipher I've gotten to work so far is RC4-SHA. Note though the TLSv1.2+HIGH ciphers that use SHA256 and greater look fine. Hmmm... if it's a problem with the CVE-2013-0169 it would appear when you select a ciphersuites using a block cipher. I'm (most probably) seeing the same issue with the pre-shared key cipher suites PSK-AES256-CBC-SHA, PSK-AES128-CBC-SHA, and PSK-3DES-EDE-CBC-SHA. PSK-RC4-SHA works fine. As git bisect revealed, the culprit is indeed commit 125093b59f3c. Reverting it fixes the issue. I'll revert 125093b59f3c and test as well. Yes, this did work to revert the entire commit. There were 4 files modified in the commit: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=125093b59f3c2a2d33785b5563d929d0472f1721 crypto/evp/c_allc.c crypto/evp/e_aes_cbc_hmac_sha1.c ssl/s3_cbc.c ssl/ssl_algs.c If I revert all the files _except_ crypto/evp/e_aes_cbc_hmac_sha1.c, we're still in a good state so the issue doesn't appear to be in that file. Then if I revert everything _except_ ssl/s3_cbc.c I get 140331120088736:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:482: So I'm thinking the issue is in that file, ssl/s3_cbc.c ... -Brad __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
iOS Embed Fingerprint error
Hi, I'm trying to build my xcode project linked to the FIPS capable library. I followed the instructions available at http://www.openssl.org/docs/fips/UserGuide-2.0.pdf for iOS The last step is to add a build phase script on the application target to embed the Module signature. After adding this script /usr/local/bin/incore_macho -exe $CONFIGURATION_BUILD_DIR/$EXECUTABLE_PATH i get this error: Not a FIPS executable (FINGERPRINT_ascii_value not found) Anyone has some suggestions on how to solve it? p.s. the xcode sample project archive provided here http://www.openssl.com/fips/2.0/platforms/ios/ is corrupted or incomplete, so it's not possible to look at the example project at all. -- View this message in context: http://openssl.6102.n7.nabble.com/iOS-Embed-Fingerprint-error-tp43525.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
make test_ssl failure with openssl-1.0.1d
Hi, when I configure openssl-1.0.1d as follows: ./Configure zlib shared linux-x86_64 make test_ssl fails with the following errors snip TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done dh test tls1 with 1024bit anonymous DH, multiple handshakes Available compression methods: 1: zlib compression ERROR in SERVER 140133790832296:error:1408F06B:SSL routines:SSL3_GET_RECORD:bad decompression:s3_pkt.c:498: ERROR in SERVER 140133790832296:error:140A4044:SSL routines:SSL_clear:internal error:ssl_lib.c:212: 140133790832296:error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message:s3_both.c:485: ERROR in SERVER 140133790832296:error:140A4044:SSL routines:SSL_clear:internal error:ssl_lib.c:212: 140133790832296:error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message:s3_both.c:485: ERROR in SERVER 140133790832296:error:140A4044:SSL routines:SSL_clear:internal error:ssl_lib.c:212: 140133790832296:error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message:s3_both.c:485: ERROR in SERVER 140133790832296:error:140A4044:SSL routines:SSL_clear:internal error:ssl_lib.c:212: 140133790832296:error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message:s3_both.c:485: ERROR in SERVER 140133790832296:error:140A4044:SSL routines:SSL_clear:internal error:ssl_lib.c:212: 140133790832296:error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message:s3_both.c:485: ERROR in SERVER 140133790832296:error:140A4044:SSL routines:SSL_clear:internal error:ssl_lib.c:212: 140133790832296:error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message:s3_both.c:485: ERROR in SERVER 140133790832296:error:140A4044:SSL routines:SSL_clear:internal error:ssl_lib.c:212: ERROR in SERVER 140133790832296:error:140A4044:SSL routines:SSL_clear:internal error:ssl_lib.c:212: ERROR in SERVER 140133790832296:error:140A4044:SSL routines:SSL_clear:internal error:ssl_lib.c:212: 10 handshakes of 256 bytes done The tests pass when I omit the zlib parameter to Configure. I know better than to use compression but the library happened to be configured this way and it appears to be a regression. System details Linux 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) zlib-devel 1.2.3 Please let me know if I've made an error or you need more details. Thanks -Alan Frindell
[openssl.org #2973] patch for c_rehash to accept more filename extensions
hi openssl community maintainers, I found the original patch was created a few years ago: http://rt.openssl.org/Ticket/Display.html?id=1325user=guestpass=guest But it's still not push into the upstream repo. I made the patch work with openssl-1.0.0e. If you don't mind, please put it into the upstream. We received some bug reports from openSUSE users. We hope it could be patched in the upstream, which means one patch can fix them all;-) Thanks! -- GNU powered it... GPL protect it... God blessing it... regards Shawn openssl-1.0.0-c_rehash_accept_file_exts.patch Description: Binary data
[openssl.org #2974] OpenSSL 0.9.8y compilation error on Windows
Configured and built openssl on Windows with: perl Configure VC-WIN32 ms\do_nasm nmake -f ms\ntdll.mak Building OpenSSL cl /Fotmp32dll\s3_cbc.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 /W3 /WX / Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DD SO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DOPENSSL_CPUID_ OBJ -DOPENSSL_IA32_SSE2 -DAES_ASM -DBN_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL _BN_ASM_MONT -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_USE_APPLINK -I. /Fdout3 2dll -DOPENSSL_NO_CAMELLIA -DOPENSSL_NO_SEED -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_CMS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_KRB5 -DOPE NSSL_NO_DYNAMIC_ENGINE -D_WINDLL -DOPENSSL_BUILD_SHLIBSSL -c .\ssl\s3_cbc.c s3_cbc.c .\ssl\s3_cbc.c(315) : warning C4761: integral size mismatch in argument; convers ion supplied .\ssl\s3_cbc.c(315) : error C2220: warning treated as error - no object file gen erated .\ssl\s3_cbc.c(644) : warning C4761: integral size mismatch in argument; convers ion supplied .\ssl\s3_cbc.c(644) : warning C4761: integral size mismatch in argument; convers ion supplied .\ssl\s3_cbc.c(645) : warning C4761: integral size mismatch in argument; convers ion supplied .\ssl\s3_cbc.c(645) : warning C4761: integral size mismatch in argument; convers ion supplied NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Thanks __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2975] [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream
A serious regression was introduced in 1.0.1d that corrupts the data stream under certain circumstances. Firefox requests to an Apache server running on Linux/X86_64 with OpenSSL-1.0.1d result in 501 Server Error responses. OpenSSL versions 1.0.1c and earlier are not affected. i686 (32 bit) versions are also not affected. An excerpt from the Apache log with 1.0.1c, showing correct behavior: 10.1.2.3 - - [05/Feb/2013:23:06:59 -0500] GET / HTTP/1.1 200 203 - Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0 10.1.2.3 - - [05/Feb/2013:23:30:39 -0500] GET / HTTP/1.1 304 - - Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0 An excerpt from the Apache log with 1.0.1d, clearly showing the invalid request: 10.1.2.3 - - [05/Feb/2013:22:47:02 -0500] G\xedET / HTTP/1.1 501 932 - Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0 10.1.2.3 - - [05/Feb/2013:23:04:03 -0500] GET / HTTP/1.1 501 932 - Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0 A look at the ssl-request log from Apache is also interesting, as Firefox sees corruption (first log line) but Links (text-based web browser, second log line) does not. This hints at it being cipher-specific: 10.1.2.3 TLSv1 ECDHE-RSA-AES256-SHA G\xedET / HTTP/1.1 932 10.1.2.3 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 GET / HTTP/1.1 203 I haven't had a chance (yet?) to bisect the code to find the culprit, but I can take a stab at it if a developer doesn't know off the top of their head just where it might be. The OS here is Slackware-64. Compiler is gcc-4.7.2, binutils 2.23.51.0.6, glibc 2.15. A portion of the output of configure is: Configuring for linux-x86_64 no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-store[experimental] OPENSSL_NO_STORE (skip dir) IsMK1MF=0 CC=gcc CFLAG =-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -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 EX_LIBS =-ldl CPUID_OBJ =x86_64cpuid.o BN_ASM=x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o modexp512-x86_64.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o BF_ENC=bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM =md5-x86_64.o SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o RMD160_OBJ_ASM= CMLL_ENC =cmll-x86_64.o cmll_misc.o MODES_OBJ =ghash-x86_64.o ENGINES_OBJ = PROCESSOR = RANLIB=/usr/bin/ranlib ARFLAGS = PERL =/usr/bin/perl SIXTY_FOUR_BIT_LONG mode DES_UNROLL used DES_INT used RC4_CHUNK is unsigned long Best regards, Kris Karas __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2974] AutoReply: OpenSSL 0.9.8y compilation error on Windows
I forgot to mention in my original e-mail that remove /WX from CFLAGS allows this to compile. Andy On 02/06/2013 03:59 PM, The default queue via RT wrote: Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: OpenSSL 0.9.8y compilation error on Windows, a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #2974]. Please include the string: [openssl.org #2974] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, r...@openssl.org - Configured and built openssl on Windows with: perl Configure VC-WIN32 ms\do_nasm nmake -f ms\ntdll.mak Building OpenSSL cl /Fotmp32dll\s3_cbc.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 /W3 /WX / Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DD SO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DOPENSSL_CPUID_ OBJ -DOPENSSL_IA32_SSE2 -DAES_ASM -DBN_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL _BN_ASM_MONT -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_USE_APPLINK -I. /Fdout3 2dll -DOPENSSL_NO_CAMELLIA -DOPENSSL_NO_SEED -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_CMS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_KRB5 -DOPE NSSL_NO_DYNAMIC_ENGINE -D_WINDLL -DOPENSSL_BUILD_SHLIBSSL -c .\ssl\s3_cbc.c s3_cbc.c .\ssl\s3_cbc.c(315) : warning C4761: integral size mismatch in argument; convers ion supplied .\ssl\s3_cbc.c(315) : error C2220: warning treated as error - no object file gen erated .\ssl\s3_cbc.c(644) : warning C4761: integral size mismatch in argument; convers ion supplied .\ssl\s3_cbc.c(644) : warning C4761: integral size mismatch in argument; convers ion supplied .\ssl\s3_cbc.c(645) : warning C4761: integral size mismatch in argument; convers ion supplied .\ssl\s3_cbc.c(645) : warning C4761: integral size mismatch in argument; convers ion supplied NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Thanks __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Major OpenSSL 1.0.1d regression from 1.0.1c
Hi, FIPS enabled build fail at same line. Brad House wrote: It appears there is a major regression with OpenSSL 1.0.1d over 1.0.1c. I've narrowed it down to setting a custom cipher list I think as if I do not set a cipher list, the issue does not occur. I have reproduced the issue with the openssl s_server/s_client command line utility. You can see my full procedure below. In short, it appears SSL negotiation succeeds, but as soon as data is sent from the client to the server, the server spits out: 67397216:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:482: And does NOT receive the data sent from the client side. [SNIP] test sslv2/sslv3 w/o DHE via BIO pair *** IN FIPS MODE *** Available compression methods: 1: zlib compression ERROR in CLIENT 140602657330880:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:482: TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA 1 handshakes of 256 bytes done make[1]: *** [test_ssl] Error 1 Roumen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Major OpenSSL 1.0.1d regression from 1.0.1c
On Wed, Feb 06, 2013, Dr. Stephen Henson wrote: On Wed, Feb 06, 2013, Brad House wrote: In ssl/s3_cbc.c and the function ssl3_cbc_record_digest_supported try setting it to return 0 when NID_sha1 is passed. Have you not been able to reproduce this issue? I've seen it on more than one machine. I've not seen it yet, no. Do you get the same problem with OpenSSL 1.0.0k? I can reproduce it now, looking into it. 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
[openssl.org #2975] [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream
On Wed Feb 06 23:01:25 2013, bugs-...@moonlit-rail.com wrote: I haven't had a chance (yet?) to bisect the code to find the culprit, but I can take a stab at it if a developer doesn't know off the top of their head just where it might be. Stop gap measure for now is to revert commit 125093b59f3c We're looking into the proper fix. 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 Security Advisory
On Tue, Feb 05, 2013 at 03:18:28PM +0100, OpenSSL wrote: OpenSSL Security Advisory [05 Feb 2013] SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169) Nadhem Alfardan and Kenny Paterson have discovered a weakness in the handling of CBC ciphersuites in SSL, TLS and DTLS. Their attack exploits timing differences arising during MAC processing. Details of this attack can be found at: http://www.isg.rhul.ac.uk/tls/ All versions of OpenSSL are affected including 1.0.1c, 1.0.0j and 0.9.8x Note: this vulnerability is only partially mitigated when OpenSSL is used in conjuction with the OpenSSL FIPS Object Module and the FIPS mode of operation is enabled. Thanks go to Nadhem J. AlFardan and Kenneth G. Paterson of the Information Security Group Royal Holloway, University of London for discovering this flaw. An initial fix was prepared by Adam Langley a...@chromium.org and Emilia K??sper ekas...@google.com of Google. Additional refinements were added by Ben Laurie, Andy Polyakov and Stephen Henson of the OpenSSL group. Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y Looking at the diff for 1.0.0k it seems to be missing commits from the 1.0.1d version: I believe the following commits in the 1.0.1 branch are part of the fix: 2ee798880a246d648ecddadc5b91367bee4a5d98 e130841bccfc0bb9da254dc84e23bc6a1c78a64e 6cb19b7681f600b2f165e4adc57547b097b475fd 9f27de170d1b7bef3d46d41382dc4dafde8b3900 014265eb02e26f35c8db58e2ccbf100b0b2f0072 b908e88ec15aa0a74805e3f2236fc4f83f2789c2 81ce0e14e72e8e255ad1bd9c7cfaa47a6291919c 34ab3c8c711ff79c2b768f0b17e4b2a78fd1df5d cab13fc8473856a43556d41d8dac5605f4ba1f91 36260233e7e3396feed884d3f501283e0453c04f d5371324d978e4096bf99b9d0fe71b2cb65d9dc8 04e45b52ee3be81121359cc1198fd01e38096e9f 8bfd4c659f180a6ce34f21c0e62956b362067fba / ec07246a0835a36af9d892f1e28b594018be6da1 The 1.0.0 branch has those commits: 9c00a950604aca819cee977f1dcb4b45f2af3aa6 (from 2ee798880a246d648ecddadc5b91367bee4a5d98) e5420be6cd09af2550b128575a675490cfba0483 (from e130841bccfc0bb9da254dc84e23bc6a1c78a64e) f852b60797dc68aa86c99c4f7b905488d1538d99 (from 014265eb02e26f35c8db58e2ccbf100b0b2f0072) 080f39539295d2c7c932e79dd670526b90a215a8 610dfc3ef4c4019394534023115226f4ed0e7204 (from 6cb19b7681f600b2f165e4adc57547b097b475fd) b23da2919b332fd83fa6de87caacb0651f64a3f5 (from 9f27de170d1b7bef3d46d41382dc4dafde8b3900) 3cdaca2436643908863c6a62918b0d9703477655 (from cab13fc8473856a43556d41d8dac5605f4ba1f91) 11c48a0fd20d2ec091fde218449f3ba0ff1cf672 (from 36260233e7e3396feed884d3f501283e0453c04f) 33f44acbbe83ab718ae15c0d2c6a57e802705a36 (from d5371324d978e4096bf99b9d0fe71b2cb65d9dc8) c6b82f7ee9434d81ccbb30d4cf3126a23398d6c7 (from 81ce0e14e72e8e255ad1bd9c7cfaa47a6291919c) That would mean the following aren't in the 1.0.0 branch: commit b908e88ec15aa0a74805e3f2236fc4f83f2789c2 Author: Dr. Stephen Henson st...@openssl.org Date: Tue Jan 29 14:44:36 2013 + Timing fix mitigation for FIPS mode. We have to use EVP in FIPS mode so we can only partially mitigate timing differences. Make an extra call to EVP_DigestSignUpdate to hash additonal blocks to cover any timing differences caused by removal of padding. commit 34ab3c8c711ff79c2b768f0b17e4b2a78fd1df5d Author: Dr. Stephen Henson st...@openssl.org Date: Thu Jan 31 23:04:39 2013 + typo. commit 04e45b52ee3be81121359cc1198fd01e38096e9f Author: Dr. Stephen Henson st...@openssl.org Date: Fri Feb 1 13:53:43 2013 + Don't access EVP_MD_CTX internals directly. commit 8bfd4c659f180a6ce34f21c0e62956b362067fba Author: Andy Polyakov ap...@openssl.org Date: Fri Feb 1 15:31:50 2013 +0100 ssl/*: remove SSL3_RECORD-orig_len to restore binary compatibility. Kludge alert. This is arranged by passing padding length in unused bits of SSL3_RECORD-type, so that orig_len can be reconstructed. (The RedHat bug fails to mention c6b82f7ee9434d81ccbb30d4cf3126a23398d6c7 for the 1.0.0 branch, but it's not going to build without that.) I think the first 2 just don't apply to the 1.0.0 branch, the 3rd isn't important, but I'm worried about the last commit since it talks about binary compatibility. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
