RE: [Patch] ALPN Implementation for OpenSSL
Hi, I realize it has only been a few days since we originally posted this patch for Application Layer Protocol Negotiation (ALPN) support. I just wanted to expand on why we think this is an important patch for OpenSSL. The latest HTTP/2.0 draft specifies support for a TLS extension called ALPN to negotiate HTTP/2.0 within the TLS handshake: http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-01 As I wrote in the original message [ http://www.mail-archive.com/openssl-dev@openssl.org/msg32630.html ] - More background is available at http://tools.ietf.org/html/draft-ietf-httpbis-http2-03#section-2.3, but for your convenience here goes the relevant snippet: 2.3. Starting HTTP/2.0 for https: URIs A client that makes a request to an https: URI without prior knowledge about support for HTTP/2.0 uses TLS [RFC5246] with the application layer protocol negotiation extension [TLSALPN]. Once TLS negotiation is complete, both the client and the server send a connection header (Section 3.2). The good news is we've already implemented it. We really want to work with you to get this patch into OpenSSL to help developers of HTTP/2.0 draft implementations. We welcome your assistance to review this patch. -- Parashuram __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3077] rbuf_freelist and wbuf_freelist corrupted.
I am using openssl-1.0.1 in my 32bit app on 64bit Windows, I got a crash in ssleay32!freelist_extract(See Call Stack in the OTHER INFO section as follow), it is not easy to recreate it and we cannot find a stable way to recreate it, but it happened several times. After looking into the dump file and analyzing the heap, now I suspect it is a potential bug in OpenSSL, here is my analysis: 1.I check the local variables in frame ssleay32!freelist_extract+0x3c and found the structure of free list rbuf_freelist was corrupted, The length of the list is 10 (the value of len is 0xa), but there is only one valid node in the list -- the head, the next pointer of head is pointing to some invalid memory. The free list for write, wbuf_freelist, got the same problem (length is 10, but only one valid node, next pointer of head points to invalid memory). so we can reach the conclusion that the heap memory which the head pointer points to was corrupted.(See Call Stack and Local variables for frame: ssleay32!freelist_extract+0x3c below) 2.From the corrupt pattern -- the next pointer (the first 4 bytes of the user accessible part of the heap block) was corrupted, but the 8 bytes metadata of the heap block was not. It looks like the pointer points to the user accessible part of the heap block was still in use after the buffer had been released (e.g. by calling ssl3_release_read_buffer(...)), or caused by some other similar mistakes. 3.From the corrupt pattern, I think the possibility that it is caused by memory overrun/underrun is very low. AND given that there are 2 lists (rbuf_freelist wbuf_freelist) experiencing the same issue, the possibility become much lower. 4.I think it is unlikely that the root cause of this issue is in my own code, since the rbuf_freelist and wbuf_freelist are internal structures in OpenSSL, my own code does not access these internal structures directly. OTHER INFO: -- OpenSSL version, extracted from the README file -- OpenSSL 1.0.1 14 Mar 2012 -- OS version and platform: -- Windows Server 2008 R2 Enterprise Edition 6.1 SP 1. VMware Virtual Platform. -- Compiler: -- VC8.0 （VS2005） -- Local variables for frame: ssleay32!freelist_extract+0x3c -- ctx |- method |- wbuf_freelist |-chucklen (0x44b0) |-len (0xa) |-head (0x00dd1098) |-next (0x17dd1098) |-next (Memory access error) |-next (Memory access error) |-next (Memory access error) ... |- rbuf_freelist |-chucklen (0x4548) |-len (0xa) |-head (0x00d84a20) |-next (0x17000316) |-next (Memory access error) |-next (Memory access error) |-next (Memory access error) ... for_read (0n1) sz (0n17736) -- Call Stack: -- ntdll!NtWaitForMultipleObjects+0x15 KERNELBASE!WaitForMultipleObjectsEx+0x100 kernel32!WaitForMultipleObjectsExImplementation+0xe0 kernel32!WaitForMultipleObjects+0x18 kernel32!WerpReportFaultInternal+0x186 kernel32!WerpReportFault+0x70 kernel32!BasepReportFault+0x20 kernel32!UnhandledExceptionFilter+0x1af ntdll!__RtlUserThreadStart+0x62 ntdll!_EH4_CallFilterFunc+0x12 ntdll!_except_handler4+0x8e ntdll!ExecuteHandler2+0x26 ntdll!ExecuteHandler+0x24 ntdll!RtlDispatchException+0x127 ntdll!KiUserExceptionDispatcher+0xf ssleay32!freelist_extract+0x3c [...\openssl\ssl\s3_both.c @ 691] ssleay32!ssl3_setup_read_buffer+0x7b [...\openssl\ssl\s3_both.c @ 760] ssleay32!ssl3_setup_buffers+0xb [...\openssl\ssl\s3_both.c @ 817] ssleay32!ssl23_get_client_hello+0x34 [...\openssl\ssl\s23_srvr.c @ 266] ssleay32!ssl23_accept+0x16e [...\openssl\ssl\s23_srvr.c @ 210] ssleay32!SSL_accept+0x1d [...\openssl\ssl\ssl_lib.c @ 938] (stacks in my code have been removed)
Re: [Patch] ALPN Implementation for OpenSSL
Hi, We really want to work with you to get this patch into OpenSSL to help developers of HTTP/2.0 draft implementations. We welcome your assistance to review this patch. What really makes this patch unusable (at least for us) is this snippet: +#if !defined(OPENSSL_NO_NEXTPROTONEG) !defined(OPENSSL_NO_ALPN) +#error Cannot define both NPN and ALPN +#endif We simply cannot drop support for NPN (i.e. SPDY) just to add support for ALPN. IMHO, the correct solution would be to always prefer and offer ALPN, unless client announced only NPN support in Client Hello. Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [Patch] ALPN Implementation for OpenSSL
-Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Piotr Sikora Sent: Thursday, June 20, 2013 10:41 AM To: openssl-dev@openssl.org Subject: Re: [Patch] ALPN Implementation for OpenSSL We simply cannot drop support for NPN (i.e. SPDY) just to add support for ALPN. The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this in the patch yet. Thanks, Jeff Mendoza __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Patch] ALPN Implementation for OpenSSL
Hey Jeff, The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this in the patch yet. Yeah, my point was that in the perfect world, you'd support both at runtime (at least on the server-side) and either ALPN or NPN could be used. I want to have a library that supports both, not either-or. Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [Patch] ALPN Implementation for OpenSSL
Yeah, my point was that in the perfect world, you'd support both at runtime (at least on the server-side) and either ALPN or NPN could be used. I want to have a library that supports both, not either-or. Yes, supporting both at runtime would be best. But having a compile-time option now, and defaulting to NPN should keep this from being a blocking issue with the patch, correct? Thanks, Jeff Mendoza __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Patch] ALPN Implementation for OpenSSL
Hey, Yes, supporting both at runtime would be best. But having a compile-time option now, and defaulting to NPN should keep this from being a blocking issue with the patch, correct? It would also make it kind of useless, at least from my non-authoritative point of view. Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Patch] ALPN Implementation for OpenSSL
On Thu, Jun 20, 2013 at 09:30:32PM +, Jeff Mendoza (MS OPEN TECH) wrote: Yeah, my point was that in the perfect world, you'd support both at runtime (at least on the server-side) and either ALPN or NPN could be used. I want to have a library that supports both, not either-or. Yes, supporting both at runtime would be best. But having a compile-time option now, and defaulting to NPN should keep this from being a blocking issue with the patch, correct? I don't speak for the OpenSSL project, but I'd suggest they should treat it as one. It positively reeks of embrace and extend. After all, the effect is to force all build systems producing system default packages of OpenSSL to pick one way or the other, ensuring that both won't work at the same time. Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Patch] ALPN Implementation for OpenSSL
On 20 June 2013 21:46, Jeff Mendoza (MS OPEN TECH) jemen...@microsoft.com wrote: -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Piotr Sikora Sent: Thursday, June 20, 2013 10:41 AM To: openssl-dev@openssl.org Subject: Re: [Patch] ALPN Implementation for OpenSSL We simply cannot drop support for NPN (i.e. SPDY) just to add support for ALPN. The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this in the patch yet. That doesn't make any sense. How would a server serve both NPN and ALPN? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
