--- 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
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 ---
-
On Sat, Sep 21, 2013 at 10:18 PM, Daniel Lowrey rdlow...@gmail.com 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
Hi Bryan,
On Thu, Sep 19, 2013 at 9:29 PM, Bryan C. Geraghty br...@ravensight.orgwrote:
-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
On Sep 18, 2013 6:07 PM, Tjerk Anne Meesters datib...@php.net wrote:
On Thu, Sep 19, 2013 at 8:33 AM, Ángel González keis...@gmail.com wrote:
On 16/09/13 15:58, Daniel Lowrey wrote:
More generally, PHP's stream encryption aspects are quite poorly
documented. For example, https://
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 mean
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
On Thu, Sep 19, 2013 at 2:07 AM, Tjerk Anne Meesters
tjerk.meest...@gmail.com 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
On Thu, Sep 19, 2013 at 2:02 PM, Pierre Joye pierre@gmail.com wrote:
On Sep 18, 2013 6:07 PM, Tjerk Anne Meesters datib...@php.net wrote:
On Thu, Sep 19, 2013 at 8:33 AM, Ángel González keis...@gmail.com
wrote:
On 16/09/13 15:58, Daniel Lowrey wrote:
More generally, PHP's
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
tjerk.meest...@gmail.com 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
-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
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
On 19 September 2013 10:52, Daniel Lowrey rdlow...@gmail.com 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
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/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
On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey ahar...@php.net wrote:
On 19 September 2013 10:52, Daniel Lowrey rdlow...@gmail.com 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
On 19 September 2013 17:31, Pierre Joye pierre@gmail.com wrote:
On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey ahar...@php.net 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
On Thu, Sep 19, 2013 at 5:38 PM, Adam Harvey ahar...@php.net wrote:
On 19 September 2013 17:31, Pierre Joye pierre@gmail.com wrote:
On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey ahar...@php.net wrote:
As for the CA bundle side of things, I wonder if this is one of those
rare times where an
On 19 September 2013 17:41, Pierre Joye pierre@gmail.com 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,
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
Á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 Thu, Sep 19, 2013 at 8:33 AM, Ángel González keis...@gmail.com 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
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 options
23 matches
Mail list logo
