--- SSL/TLS security progress update ---
All previously discussed aspects of secure-by-default stream encryption are
now implemented and tested. There are some other significant improvements
including but not limited to full TLSv1.1+TLSv1.2 support and simplified
peer fingerprint verification. As
On Sat, Sep 21, 2013 at 10:18 PM, Daniel Lowrey wrote:
> Hello security-conscious internals people!
>
> I've got (what believe to be) a pretty good working solution for the
> problem of insecure-by-default stream encryption. I need to do some more
> thorough testing before pushing it upstream to
Hello security-conscious internals people!
I've got (what believe to be) a pretty good working solution for the
problem of insecure-by-default stream encryption. I need to do some more
thorough testing before pushing it upstream to a public fork but here's the
quick and dirty:
--- Summary ---
-
Hi Bryan,
On Thu, Sep 19, 2013 at 9:29 PM, Bryan C. Geraghty wrote:
> -Original Message-
> From: tjerk.meest...@gmail.com [mailto:tjerk.meest...@gmail.com] On Behalf
> Of Tjerk Anne Meesters
> Sent: Thursday, September 19, 2013 4:01 AM
>
> > My point is that you need a reasonably up-to-da
On 19 September 2013 17:41, Pierre Joye wrote:
> It does when you use curl's win32 SSL support. That makes my previous
> point wrong as we do not compile it with this option but openssl (for
> cross platform compatibility reasons). But as the curl's ca file works
> just fine, everything is good.
>
On Thu, Sep 19, 2013 at 5:38 PM, Adam Harvey wrote:
> On 19 September 2013 17:31, Pierre Joye wrote:
>> On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey wrote:
>>> As for the CA bundle side of things, I wonder if this is one of those
>>> rare times where an ini setting might make sense, as opposed t
On 19 September 2013 17:31, Pierre Joye wrote:
> On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey wrote:
>> As for the CA bundle side of things, I wonder if this is one of those
>> rare times where an ini setting might make sense, as opposed to actual
>> bundling — that would allow distros to point t
On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey wrote:
> On 19 September 2013 10:52, Daniel Lowrey wrote:
>>> *I consider this a bug* I understand that it's easier to code not verifying
>>> the
>>> peer, and the hostname may not be available when you are stacking ssl over
>>> a stream.
>>> But fil
On 19/09/13 23:41, Adam Harvey wrote:
As for the CA bundle side of things, I wonder if this is one of those
rare times where an ini setting might make sense, as opposed to actual
bundling — that would allow distros to point to their packaged bundles
without needing to patch php-src, and we could
> I think we should do this in 5.6.
+1 ... a renewed "emphasis on security" makes a good selling point when
answering the "why should I upgrade" questions. At the same time, targeting
the next minor version gives people ample time to plan/test/document
changes. Secure stream encryption settings by
On 19 September 2013 10:52, Daniel Lowrey wrote:
>> *I consider this a bug* I understand that it's easier to code not verifying
>> the
>> peer, and the hostname may not be available when you are stacking ssl over a
>> stream.
>> But file_get_contents("https://...";) is *precisely* the case that
> If a subjectAltName extension of type dNSName is present, that MUST
> be used as the identity. Otherwise, the (most specific) Common Name
> field in the Subject field of the certificate MUST be used. Although
> the use of the Common Name is existing practice, it is deprecated and
> Certification
-Original Message-
From: tjerk.meest...@gmail.com [mailto:tjerk.meest...@gmail.com] On Behalf
Of Tjerk Anne Meesters
Sent: Thursday, September 19, 2013 4:01 AM
> My point is that you need a reasonably up-to-date certs bundle to enable
verification by default.
Actually, you don't. There is
On Thu, Sep 19, 2013 at 09:58:59AM +0100, Chris Wright wrote:
> On Thu, Sep 19, 2013 at 2:07 AM, Tjerk Anne Meesters
> wrote:
> > To be practical, verifying certificates requires an up-to-date CA bundle
> > to be shipped with PHP; perhaps this is a simple thing to do, I'm not
> > sure.
>
> Unfort
On Thu, Sep 19, 2013 at 2:02 PM, Pierre Joye wrote:
>
> On Sep 18, 2013 6:07 PM, "Tjerk Anne Meesters" wrote:
> >
> > On Thu, Sep 19, 2013 at 8:33 AM, Ángel González
> wrote:
> >
> > > On 16/09/13 15:58, Daniel Lowrey wrote:
> > >
> > >> More generally, PHP's stream encryption aspects are quite
On Thu, Sep 19, 2013 at 2:07 AM, Tjerk Anne Meesters
wrote:
> To be practical, verifying certificates requires an up-to-date CA bundle
> to be shipped with PHP; perhaps this is a simple thing to do, I'm not
> sure.
Unfortunately it isn't. It's easily possible to ship a current CA bundle
*at the p
> To be clear, I *don't* mean SNI, I mean subjectAltName (SAN) validation.
Ah, apologies for the SNI/SAN confusion. However, I still cannot reproduce
this failure when verifying peers with certs utilizing the SAN extension. Could
you supply a code snippet demonstrating this failure?
On Thu, Sep
Daniel Lowrey wrote:
> This is incorrect. PHP has supported both the "SNI_enabled" and
> "SNI_server_name"
> SSL context options since 5.3. Anything older than 5.3 is not remotely
> worth worrying over. You can verify this for yourself using the following
> code:
To be clear, I *don't* mean SNI, I
On Sep 18, 2013 6:07 PM, "Tjerk Anne Meesters" wrote:
>
> On Thu, Sep 19, 2013 at 8:33 AM, Ángel González wrote:
>
> > On 16/09/13 15:58, Daniel Lowrey wrote:
> >
> >> More generally, PHP's stream encryption aspects are quite poorly
> >> documented. For example, https:// streams disable peer veri
> While we're on the topic, it's actually worse than that. Even if you
> turn peer validation and name checking on, PHP can't handle
> subjectAltNames in certificates, which causes quite a few failures.
This is incorrect. PHP has supported both the "SNI_enabled" and
"SNI_server_name"
SSL context o
On Thu, Sep 19, 2013 at 8:33 AM, Ángel González wrote:
> On 16/09/13 15:58, Daniel Lowrey wrote:
>
>> More generally, PHP's stream encryption aspects are quite poorly
>> documented. For example, https:// streams disable peer verification by
>> default. While I understand that this is necessary to
Ángel González wrote:
> On 16/09/13 15:58, Daniel Lowrey wrote:
>> More generally, PHP's stream encryption aspects are quite poorly
>> documented. For example, https:// streams disable peer verification by
>> default. While I understand that this is necessary to provide the easiest
>> possible user
On 16/09/13 15:58, Daniel Lowrey wrote:
More generally, PHP's stream encryption aspects are quite poorly
documented. For example, https:// streams disable peer verification by
default. While I understand that this is necessary to provide the easiest
possible user experience for things like `file_
23 matches
Mail list logo
