Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72755 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76014 invoked from network); 22 Feb 2014 08:30:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Feb 2014 08:30:15 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.54 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.216.54 mail-qa0-f54.google.com Received: from [209.85.216.54] ([209.85.216.54:33560] helo=mail-qa0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C9/80-00531-61068035 for ; Sat, 22 Feb 2014 03:30:15 -0500 Received: by mail-qa0-f54.google.com with SMTP id i13so4467651qae.13 for ; Sat, 22 Feb 2014 00:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rVpX0lOZ1/sml6GIxlybzJRMEYCcgFR+zIGTRT1bC/w=; b=KTWexecT8MDABqMlnh5aZnraVXqBCumkzEuKYZLc7S17G4w6+Ld0tnKXV7E8duFXBW 8qC/QLoM/Mg6/pj7jAtqNEY0gCdufdh21NhxsthqIbTLGrvuKERQAU6BYMqa/Wcn2ivR FzOMrSHO8TtRu5GjRelykbaIfdNh85bcVHYV+nkNCDphosMaBHQGRcGA17lbpaDUuLVF maNa8LfHTezAuTxjpuwMlgMGsA8bt1pCSFzEnI5nNuc9jIgcW0mnY2U36JsxQ0dvQrVe QO/lnO7CcKTy8DsrUWQKNVOeNB5vUa98enF73RH0qM6OC/cZ6M0aNkmhsDRK6T3rPm4t dhAQ== MIME-Version: 1.0 X-Received: by 10.224.11.196 with SMTP id u4mr16125762qau.4.1393057811811; Sat, 22 Feb 2014 00:30:11 -0800 (PST) Received: by 10.140.18.145 with HTTP; Sat, 22 Feb 2014 00:30:11 -0800 (PST) In-Reply-To: References: Date: Sat, 22 Feb 2014 09:30:11 +0100 Message-ID: To: Chris Wright Cc: Daniel Lowrey , Ferenc Kovacs , =?UTF-8?Q?P=C3=A1draic_Brady?= , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Windows Peer Verification From: pierre.php@gmail.com (Pierre Joye) hi Chris! On Sat, Feb 22, 2014 at 1:31 AM, Chris Wright wrote: > Following on from this thread and Daniel's excellent work on TLS > improvements, and liaising heavily with Daniel off-list, I have > created a PR [1] of some work I have done to get peer verification > working with Windows native certificate store. Very good job! I like it! Thanks. > This is by far and away the most preferable option as it gives "out of > the box" support for peer verification by default on Windows, and does > not require any additional certificate bundles or configuration. It > also allows us to take advantage of trust updates rolled out via MS > update systems. > > The implementation is complete in that it supports all existing > features, although it needs a little polishing and some edge cases > covering before it can be merged. The only definite known issue at the > time of writing is that the method for fetching the CN from the > certificate incorrectly assumes that the returned data will always be > UTF-8 encoded, a solution for this is planned and will be implemented > in the next day or two. > > I am by no means an expert on the subject matter here in any respect, > so I encourage ruthless code review. > > Note that there are no new features here, it is simply looking to fill > in the gaps in the recent work by providing consistency on Windows. I have however some doubts about doing that now (not sure if I raised these points already). Using Windows CA store is a good thing, from a theoretical point of view. However it brings a couple of issues with it. The 1st one is compatibility, it is a different system using different methods to store, add or manage certificate. One of the key point we try to keep in PHP is almost 100% compatibility between Windows and other platforms. That's one of the main reasons why I did not implement SSL support using WInSSL APIs back then for 5.3.0. I am also not sure about the impact this change will have on existing code using more advanced features (context, environment customization, etc) of openssl, be with stream or with openssl only. It may impact performance as well a little bit but I need to test it first to compare, did you try to see if there are performance regressions? At the end, I would prefer to have full support of the Windows Crypto APIs and OpenSSL using one single and unified APIs. The new crypto APIs could be a good base for that. We can then provide two builds, one for openssl and one for the Windows Crypto API support. This is what we do in Curl for example. I hope you do not take this reply as a bad reply, I really appreciate this patch and the effort you put in it. But I have to say that I am not in favor of doing that in 5.6.0 and not only for this area in any other major version. A more global approach will be more beneficial and may bring less confusion to our users. It will also reduce support requests from windows users as well, who are following the numerous documentation out there about working with openssl on windows, from various areas. Cheers, -- Pierre @pierrejoye | http://www.libgd.org