Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47012 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67559 invoked from network); 21 Feb 2010 13:51:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Feb 2010 13:51:23 -0000 Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.219 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.219.219 mail-ew0-f219.google.com Received: from [209.85.219.219] ([209.85.219.219:65399] helo=mail-ew0-f219.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/20-00376-85A318B4 for ; Sun, 21 Feb 2010 08:51:20 -0500 Received: by ewy19 with SMTP id 19so1579152ewy.1 for ; Sun, 21 Feb 2010 05:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=t9g9lVFgy6zpnEf+97he+nIWedVaEY5JBemp9nAJ0A4=; b=nbmGPLNxjhj5svprUuB61UJxr+5KP4pCfRkMGyLMJ8DPgcnOAMIL6sCqlWzqMkGfeK W1mz36Pwz8m76x0ZMeBKVlBgTkd67DFg7Nk1U4lK+hhLbxYRnBhW4r/PColc6mSvkTSq feSgP9C3kX08RdyH8SlvSRPagDYgcObh+Tcn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rq0/+3egeh6QXOAXPINNm6e0LNiu0eolILLHBKJu0B8mV9dbo75bsSnx+QguxjfFFj EiY5VvawJZmUQ+ZwahgsU3cNJG7+ruVrMezEg3ldOzMWglzAhrvHt6pxGL6ssOQnWhXW kO6NUezkmeUZsmLLOnmo2IDDwQVRoXyh9KSeE= MIME-Version: 1.0 Received: by 10.216.91.6 with SMTP id g6mr193540wef.37.1266760276671; Sun, 21 Feb 2010 05:51:16 -0800 (PST) In-Reply-To: <7b9883441002201747w5fb878ebu7ae880b3628f1e83@mail.gmail.com> References: <7b9883441002201156i462221ccked6f1c0aa0b49b56@mail.gmail.com> <7b9883441002201645u70965031jb7fd3098324a00db@mail.gmail.com> <7b9883441002201747w5fb878ebu7ae880b3628f1e83@mail.gmail.com> Date: Sun, 21 Feb 2010 14:51:16 +0100 Message-ID: To: Bostjan Skufca Cc: internals@lists.php.net, wez@php.net, kingwez@gmail.com, pajoye@php.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Patch for ext/openssl to support CN_match with asterisk From: pierre.php@gmail.com (Pierre Joye) hi, can you run it through valgrind and paste the output in a new bug report pl= ease? Cheers, On Sun, Feb 21, 2010 at 2:47 AM, Bostjan Skufca wrote: > a) If you would like to see an example of memory leak, here is how I > reproduce it. > > 1. Clone this git repository: > http://github.com/bostjan/PHP-application-server > > 2. Copy/move/Symlink contents to /opt/daemons/AppSrv > > 3. cd to /opt/daemons/AppSrv/demos/demo_https > > 4. start the daemon: ./demo -d5 > - binds and listens on port 30000 > - does not fork into background > 7. execute ./client_openssl_nocert > > 5. with another shell go to: /opt/daemons/AppSrv/demos/demo_https > > 6. execute this: while (true); do ./client_curl; done > > 7. start another shell and watch increasing residental memory of PHP > server process > > > > b) If you would like to see an example of stale openssl_x509 resource > bug, here is how I reproduce it. > Follow the steps 1-5 above > > 6. execute ./client_openssl > - make some input, double return > - watch at server console how correct CN appears two times > > 7. execute ./client_openssl_nocert > - watch at server console how STALE CN from previous connection appears > > 8. execute ./client_openssl_nocert > - and the bug is gone to hiding > > 9. If you repeat steps 6-8 bug reappears/redissapears. > > > > I hope this helps, > b. > > > > On 21 February 2010 01:45, Bostjan Skufca wrote: >> The patch includes code which is very similar but it's functionality >> goes just the other way around. >> >> The original code takes remote CN and if that contains asterisk, it >> tries to 'limited-wildcard-match' of CN_match against remote CN >> (remote CN is the pattern in this case, if you will). >> >> On the other hand, added code checks if CN_match contains asterisk and >> if so, it does 'limited-wildcard-match' of REMOTE CN against CN_match >> pattern. >> >> >> The original version 'could' be enough if you are only considering PHP >> as a SSL client. >> >> >> Now, what I am trying to achieve is a whole standalone application >> server written in PHP. That is, whole forking/process management etc >> stuff. And I would like to set it up like this: >> - it has a SSL listening socket >> - set CN_match for listening socket to '*.example.org' >> - create listening socket with stream_socket_server >> All above in order to accept connections only from clients which >> present themselves with appropriate certificate (based on cacert check >> which works OK) and appropriate CN. >> >> To illustrate the desired functionality: >> - CNs host1.example.org and host2.example.org are OK, >> - but not CN host3.otherdomain.org, even if it presents a certificate >> from the same CA as the two above. >> >> >> Was I clear enough now? :) >> b. >> >> >> >> PS: I've just discovered another issue. In the context of creating >> listening socket with stream_socket_create, again. >> >> If a preceeding SSL client has introduced itself with client >> certificate, and the current client does not, the >> [ssl][peer_certificate] of the new socket's context options still >> contains a reference to a resource of preceeding client's certificate. >> Later, subsequent client connections without certificate do not >> exhibit the same behaviour. >> If the pattern reoccurs (... ---> client-with-cert =A0---> followed by >> client-without-cert), the story repeats. >> >> There is also a memory leak in this - when I looped the client to >> establish hundreds of sequential SSL connections, the residental >> memory footprint of php server process was ever increasing. When I >> switched my App server to HTTP protocol and repeated the test the >> memory leak was not present anymore. And I did openssl_x509_free() >> call on peer_certificate resource upon client disconnect. >> >> >> >> >> >> On 21 February 2010 00:05, Pierre Joye wrote: >>> hi, >>> >>> Is it not suppose to work already? As your patch basically does what >>> is done earlier in the code if match fails. If there is a bug in this >>> area, we should fix instead of adding the same thing later :) >>> >>> I will check this issue next week. >>> >>> Btw, there is no chance to get this in 5.2.13 or 5.3.2 at this stage, >>> it is too late in the process. >>> >>> Thanks for your work! >>> >>> Cheers, >>> >>> On Sat, Feb 20, 2010 at 8:56 PM, Bostjan Skufca wrote: >>>> Hi! >>>> >>>> I've created a patch that enables PHP to do "limited wildcard >>>> matching" if CN_match option in stream context is specified as >>>> '*.example.org'. >>>> Also I have filled a bug report for this, here: >>>> http://bugs.php.net/bug.php?id=3D51100 >>>> >>>> Patch is here: >>>> http://source.a2o.si/php/php-ext-openssl-CN_match-wildcard.diff >>>> >>>> It was made against 5.2.12 but I checked it with SVN: >>>> - for 5.2 branch the offset is only +6 lines >>>> - for trunk it is cca +800 lines >>>> >>>> Can you include it in 5.2.13 release and 5.3? I know the former is >>>> already in RC stage but this does can't break anything I believe. >>>> >>>> Best regards, >>>> b. >>>> >>>> -- >>>> PHP Internals - PHP Runtime Development Mailing List >>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>> >>>> >>> >>> >>> >>> -- >>> Pierre >>> >>> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >>> >> > --=20 Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org