Re: [openssl.org #3571] Re: [PATCH] Segfault in 1.0.1j BIO_reset() compiled with no-ssl2 no-ssl3
On Fri, 17 Oct 2014 21:17:49 +0200, The default queue via RT wrote On Thu, 16 Oct 2014 16:33:28 +0200, Frank Schmirler wrote I get the following segfault when trying to send an SSLv3 request to the reverse proxy pound, running on openssl-1.0.1j with SSLv2/3 disabled: Program received signal SIGSEGV, Segmentation fault. 0xb77498fa in ssl_ctrl (b=0xb7001010, cmd=1, num=0, ptr=0x0) at bio_ssl.c:312 312 if (ssl-handshake_func == ssl-method-ssl_connect) Problem is that ssl23_get_server_method(SSL3_VERSION) returns NULL when compiled with no-ssl3, setting ssl-method to NULL. The attached patch adds a define to ssl23_get_client_hello(...) to treat the no- ssl3 just like the SSL_OP_NO_SSLv3 flag. The same problem will also occur in an SSLv2 style handshake. Find attached an extended patch. Works without problems now. Regards, Frank openssl-1.0.1j-no_ssl3.patch Description: application/download
x86gas.pl, 1.0.1j, MacOSX, x86 assembler, .comm directive
Hi folks
I have been building OpenSSL 1.0.1j on assorted MacOSX releases of
various ages, and encountered a failure
=-=-=-=-=-=-=-=-=-=-=
x86cpuid.s:327:Rest of line ignored. 1st junk character valued 44 (,).
=-=-=-=-=-=-=-=-=-=-=
when building on 10.4.11/ppc, cross-compiling for i386, when using
gcc 4.0.1. Comparable failures did not occur when building on 10.6.8/
x86_64 or 10.8.5/x86_64 for either i386 or x86_64 using gcc 4.2, or
when building OpenSSL 0.9.8zc.
I have traced this to openssl-1.0.1j/crypto/perlasm/x86gas.pl
=-=-=-=-=-=-=-=-=-=-=
sub ::file_end
{ if ($::macosx)
{ if (%non_lazy_ptr)
{ push(@out,.section
__IMPORT,__pointers,non_lazy_symbol_pointers\n);
foreach $i (keys %non_lazy_ptr)
{ push(@out,$non_lazy_ptr{$i}:\n.indirect_symbol\t$i\n.long\t0
\n); }
}
}
if (grep {/\b${nmdecor}OPENSSL_ia32cap_P\b/i} @out) {
my $tmp=.comm\t${nmdecor}OPENSSL_ia32cap_P,8;
if ($::macosx) { push (@out,$tmp,2\n); }
elsif ($::elf) { push (@out,$tmp,4\n); }
else{ push (@out,$tmp\n); }
}
push(@out,$initseg) if ($initseg);
}
=-=-=-=-=-=-=-=-=-=-=
At some point, which in my ignorance I believe to be http://
git.openssl.org/gitweb/?
p=openssl.git;a=commitdiff;h=4a5397fb68279702e6e0b20c514ff18713bdd38b ,
sub ::file_end was modified so that on Darwin/i386, openssl-1.0.1j/
crypto/x86cpuid.s would end
=-=-=-=-=-=-=-=-=-=-=
.section __IMPORT,__pointers,non_lazy_symbol_pointers
L_OPENSSL_ia32cap_P$non_lazy_ptr:
.indirect_symbol _OPENSSL_ia32cap_P
.long 0
-.comm _OPENSSL_ia32cap_P,8
+.comm _OPENSSL_ia32cap_P,8,2
.mod_init_func
.align 2
.long _OPENSSL_cpuid_setup
=-=-=-=-=-=-=-=-=-=-=
and that does not sit well with the documentation for MacOSX i386
assembler:
https://developer.apple.com/library/mac/documentation/DeveloperTools/
Reference/Assembler/040-Assembler_Directives/asm_directives.html
suggesting that the .comm directive takes two operands, while .lcomm
takes an optional third operand.
Other documentation https://sourceware.org/binutils/docs/as/Comm.html
states When using ELF or (as a GNU extension) PE, the .comm
directive takes an optional third argument. 32-bit MacOSX uses
neither ELF nor PE. The third argument ought to be redundant here;
the default natural alignment as described in the Apple developer
documentation ought to be adequate.
It's not clear to me that me ought to do anything; this is a problem
only when building using compilers for MacOSX releases that have long
since been EOLed.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Cannot retrieve embedded signer certificate from CMS message
Hello, I have a signing certificate with which I sign a message with openssl command line. I do NOT use -nocerts option, so the signing certificate should be embedded in the CMS message. I verify that it exists by retrieving it with command: openssl cms -verify -in infile.ini -certsout cert_to_test.pem and I test the certificate and it works. Now I want to retrieve the certificate in C, using openssl library. I read the CMS message file, then I read the SMIME and trz to get the signer. Here is the function called: pBioFile= BIO_new_file(file, r); pCms = SMIME_read_CMS(pBioFile, NULL); pCms_signer = CMS_get0_SignerInfos(pCms); sk_CMS_SignerInfo_num(pskCms_signer ) - return 0 meaning no certificates were found. Can anyone help with what am I doing wrong? Thanks, Rares __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3575] [BUG] FALLBACK_SCSV early in the cipher list breaks handshake
Hi, Using OpenSSL 1.0.1j 15 Oct 2014 on a GNU/Linux machine, I observe that if openssl s_server receives a ClientHello with FALLBACK_SCSV before the actual ciphersuites, it breaks the handshake with a fatal handshake_failure(40) alert, regardless of whether the version is the highest supported or not. % openssl s_server -www -cert some.crt -key some.key -debug Using default temp DH parameters Using default temp ECDH parameters ACCEPT read from 0x20531d0 [0x20588c0] (11 bytes = 11 (0xB)) - 16 03 01 00 89 01 00 00-85 03 03 ... read from 0x20531d0 [0x20588ce] (131 bytes = 131 (0x83)) - 54 44 ed 69 3a 59 5f dd-0b 5c 68 89 9c 6f e5 32 TD.i:Y_..\h..o.2 0010 - 58 5c 31 e0 6f 6b e8 b6-c8 c9 a4 6d 90 af f0 db X\1.ok.m 0020 - 00 00 06 00 ff 56 00 c0-09 01 00 00 56 00 00 00 .V..V... 0030 - 0e 00 0c 00 00 09 6c 6f-63 61 6c 68 6f 73 74 00 ..localhost. 0040 - 0d 00 1a 00 18 06 01 05-01 04 01 03 01 02 01 01 0050 - 01 06 03 05 03 04 03 03-03 02 03 01 03 00 0a 00 0060 - 18 00 16 00 19 00 1c 00-18 00 1b 00 17 00 16 00 0070 - 1a 00 15 00 14 00 13 00-12 00 0b 00 02 01 00 00 0080 - 23# 0083 - SPACES/NULS write to 0x20531d0 [0x20623b0] (7 bytes = 7 (0x7)) - 15 03 03 00 02 02 28 ..( 140292492379792:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1360: ACCEPT (Ciphersuite list starts as 0x23 with EMPTY_RENEGOTIATION_INFO, followed by FALLBACK_SCSV, then TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA, which is supported.) The expected behaviour would be the one that happens when the SCSV is placed after the actual ciphersuites. Indeed, the draft does not mandate that the SCSV be at the end of the list, it merely states it will generally happen this way. Manuel. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3575] [BUG] FALLBACK_SCSV early in the cipher list breaks handshake
Sorry, my fault. I'll fix this. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3575] [BUG] FALLBACK_SCSV early in the cipher list breaks handshake
The fix will be in the next version. Note that OpenSSL servers aren't expected to see TLS_FALLBACK_SCSV in normal operation (the code is sufficiently version tolerant, etc.), and if you've enabled TLS 1.2, there isn't even a higher protocol version that the client could be falling back from, so the impact of this bug is really low. It's just bad for testing. Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3575] [BUG] FALLBACK_SCSV early in the cipher list breaks handshake
The fix will be in the next version. Note that OpenSSL servers aren't expected to see TLS_FALLBACK_SCSV in normal operation (the code is sufficiently version tolerant, etc.), and if you've enabled TLS 1.2, there isn't even a higher protocol version that the client could be falling back from, so the impact of this bug is really low. It's just bad for testing. Bodo
Re: [openssl.org #3571] Re: [PATCH] Segfault in 1.0.1j BIO_reset() compiled with no-ssl2 no-ssl3
On Mon, Oct 20, 2014 at 11:10:51AM +0200, Frank Schmirler via RT wrote:
On Fri, 17 Oct 2014 21:17:49 +0200, The default queue via RT wrote
On Thu, 16 Oct 2014 16:33:28 +0200, Frank Schmirler wrote
I get the following segfault when trying to send an SSLv3 request to
the reverse proxy pound, running on openssl-1.0.1j with SSLv2/3
disabled:
Program received signal SIGSEGV, Segmentation fault.
0xb77498fa in ssl_ctrl (b=0xb7001010, cmd=1, num=0, ptr=0x0) at
bio_ssl.c:312
312 if (ssl-handshake_func ==
ssl-method-ssl_connect)
Problem is that ssl23_get_server_method(SSL3_VERSION) returns NULL when
compiled with no-ssl3, setting ssl-method to NULL. The attached
patch adds a define to ssl23_get_client_hello(...) to treat the no-
ssl3 just like the SSL_OP_NO_SSLv3 flag.
The same problem will also occur in an SSLv2 style handshake. Find attached an
extended patch. Works without problems now.
Can you try the attached patch instead?
Kurt
diff --git a/ssl/s23_srvr.c b/ssl/s23_srvr.c
index 93ca7d5..de909b1 100644
--- a/ssl/s23_srvr.c
+++ b/ssl/s23_srvr.c
@@ -602,12 +602,14 @@ int ssl23_get_client_hello(SSL *s)
if ((type == 2) || (type == 3))
{
/* we have SSLv3/TLSv1 (type 2: SSL2 style, type 3: SSL3/TLS style) */
-s-method = ssl23_get_server_method(s-version);
- if (s-method == NULL)
+ const SSL_METHOD *new_method;
+ new_method = ssl23_get_server_method(s-version);
+ if (new_method == NULL)
{
SSLerr(SSL_F_SSL23_GET_CLIENT_HELLO,SSL_R_UNSUPPORTED_PROTOCOL);
goto err;
}
+ s-method = new_method;
if (!ssl_init_wbio_buffer(s,1)) goto err;
RE: [PATCH] Suppress unused value warnings casue by HOST_cl2
It will go into master, post-1.0.2 -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl- d...@openssl.org] On Behalf Of Doug Kwan (???) Sent: Monday, October 20, 2014 8:50 PM To: openssl-dev@openssl.org Subject: Re: [PATCH] Suppress unused value warnings casue by HOST_cl2 ping? On Mon, Oct 13, 2014 at 3:57 PM, Doug Kwan (關振德) dougk...@google.com wrote: On Fri, Oct 10, 2014 at 2:39 PM, Salz, Rich rs...@akamai.com wrote: Let's fix it the right way. :) -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz I changed the definitions of HOST_c2l on different platforms and removed the unneeded void casts. This is tested on Linux running on x86_64, powerpc64le and aarch64. -Doug __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org :��IϮ��r�m (Z+�7�zZ)���1���x ��hW^��^��%�� ��jם.+-1�ځ��j:+v���h�
RE: Patch to mitigate CVE-2014-3566 (POODLE)
This patch seems to be the cause of a failure in ‘make errors’: /usr/bin/perl util/ck_errf.pl -strict */*.c */*/*.c /usr/bin/perl util/mkerr.pl -recurse -write Invalid error code SEGMENT_SIZE Invalid error code PRIME_SANITY_LIMIT !! ERROR: SSL reason code 373 assigned twice (collision at SSL_R_RFC5430_CURVE_MISMATCH) I’m guessing this patch (or part of it) was incorporated into 1.0.1j, because this error, and the causal code, showed up after we synced to 1.0.1j. The problem is that both SSL_R_INAPPROPRIATE_FALLBACK (added in this patch) and SSL_R_RFC5430_CURVE_MISMATCH are set to 373. I think the solution is to change the value of SSL_R_INAPPROPRIATE_FALLBACK to 374 (which appears nowhere in openssl/ssl/ssl.h. From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Bodo Moeller Sent: Tuesday, October 14, 2014 7:47 PM To: openssl-us...@openssl.org; openssl-dev@openssl.org Subject: Patch to mitigate CVE-2014-3566 (POODLE) Here's a patch for the OpenSSL 1.0.1 branch that adds support for TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack (CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf). Note well that this is not about a bug in OpenSSL -- it's a protocol issue. If SSL 3.0 is disabled in either the client or in the server, that is completely sufficient to avoid the POODLE attack. (Also, there's only a vulnerability if the client actively falls back to SSL 3.0 in case that TLS connections don't work -- but many browsers still do that to ensure interoperability with broken legacy servers.) If you can't yet disable SSL 3.0 entirely, TLS_FALLBACK_SCSV can help avoid the attack, if both the client and the server support it. Server-side TLS_FALLBACK_SCSV support is automatically provided if you use the patch. Clients that do fallback connections downgrading the protocol version should use SSL_set_mode(ssl, SSL_MODE_SEND_FALLBACK_SCSV) for such downgraded connections. The OpenSSL team will follow up with official releases that will include TLS_FALLBACK_SCSV support. Meanwhile, if you can't simply disable SSL 3.0, you may want to use this patch. Bodo
Re: Patch to mitigate CVE-2014-3566 (POODLE)
On 20/10/14 20:30, Andrew Felsher (afelsher) wrote: I’m guessing this patch (or part of it) was incorporated into 1.0.1j, because this error, and the causal code, showed up after we synced to 1.0.1j. The problem is that both SSL_R_INAPPROPRIATE_FALLBACK (added in this patch) and SSL_R_RFC5430_CURVE_MISMATCH are set to 373. I think the solution is to change the value of SSL_R_INAPPROPRIATE_FALLBACK to 374 (which appears nowhere in openssl/ssl/ssl.h. This patch (well a later version of it) was indeed incorporated into 1.0.1j...so there is no need to apply this patch to that version. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3576] Speed up AES-256 key expansion by 1.9x
Use aesenclast to do key expansion for AES-256 rather than aeskeygenassist. Shay Gueron gives the technique in his AES-NI whitepaper; I discovered, after implementing my own version (and looking for places to patch), that he and Vlad Krasnov had already implemented this technique in NSS. Relative speedup (key expansion microbenchmark): 1.9x Relative speedup, AES-256-GCM seal of 16B messages (BoringSSL tool/bssl speed): 1.17x This can obviously be extended to other key-lengths; but since I don't think people should be using AES-128, and no one uses AES-192, I see little point in doing so. License for patch: CC0. 0001-Speedup-AES-256-key-expansion-by-1.92x.patch Description: Binary data
[openssl.org #3577] Crash bug in latest openssl versions due to ssl_st.method==NULL
From an examination, this is at worst a null pointer dereference, and
it's readily inferred from a ticket on our public bugtracker, so I'm
sending this in the clear.
Because of patch 26a59d9b46574e457870197dffa802871b4c8fc7 from Geoff
Thorpe (hi!) , if openssl is built with no-ssl3, and you connect to it
with SSL v3, then the s-method pointer is set to NULL. This can
cause a variety of functions to crash if you call them on your error
path, since nearly everything expects s-method to be set and doesn't
check it.
In Tor's case, the crash happens in a bit of code in our cleanup
function that does SSL_set_tlsext_host_name(... , NULL); to work
around the bug that Ben fixed in
241d088156cdd12bce84b26dbc9060972ef73d96. But probably this kind of
thing can happen to other programs too.
I'd suggest that the code in ssl23_get_client_hello() should instead
do something like this:
SSL_METHOD *new_method = ssl23_get_server_method(s-version);
if (new_method == NULL)
{
SSLerr(SSL_F_SSL23_GET_CLIENT_HELLO,SSL_R_UNSUPPORTED_PROTOCOL);
goto err;
}
else
s-method = new_method;
Does that seem sensible? I might well be missing something; my
understanding of this code is shallow.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
RE: [openssl.org #3576] Speed up AES-256 key expansion by 1.9x
AES 128 is worth supporting. I agree that AES 192 is not.
Re: [openssl.org #3576] Speed up AES-256 key expansion by 1.9x
On Mon, Oct 20, 2014 at 04:40:09PM -0400, Salz, Rich wrote: AES 128 is worth supporting. I agree that AES 192 is not. Isn't AES-192 part of Suite-B? Which OpenSSL supports, and it presumably would be used in CMS, if not TLS. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3576] [PATCH] Speed up AES-256 key expansion by 1.9x
On Mon, Oct 20, 2014 at 4:40 PM, Salz, Rich rs...@akamai.com wrote: AES 128 is worth supporting. Not for me; doing this strictly for fun. Note: With this patch, expanding an AES-256 key is faster than expanding an AES-128 key. So why not just use those saved cycles to switch to AES-256? Cf. djb's matching AES security, http://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3576] Speed up AES-256 key expansion by 1.9x
On Mon, Oct 20, 2014 at 6:03 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: Isn't AES-192 part of Suite-B? No. No one implemented AES-192 in hardware, so it got dropped in favor of AES-256. https://www.nsa.gov/ia/programs/suiteb_cryptography/ (And, while you marvel at the NSA serving its homepage using TLS 1.2 -- and a certain CDN -- note that [t]he connection is encrypted using AES_256_CBC[.]) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3576] Speed up AES-256 key expansion by 1.9x
On Mon, Oct 20, 2014 at 08:20:00PM -0400, David Leon Gil wrote: No one implemented AES-192 in hardware, so it got dropped in favor of AES-256. https://www.nsa.gov/ia/programs/suiteb_cryptography/ Indeed, my information was stale. So now we have a peculiar imbalance in the Suite-B algorithms. The ECDH, ECDSA and Digest for TOP SECRET all provide 192-bit security, but the bulk crypto is AES-256. (And, while you marvel at the NSA serving its homepage using TLS 1.2 -- and a certain CDN -- note that [t]he connection is encrypted using AES_256_CBC[.]) Well, that's to be expected, there are no TLS code points for AES-192. So given that AES-192 lost the popularity contest to AES-256, perhaps you can skip it after all. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
