> 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 since 5.3. Anything older than 5.3 is not remotely worth worrying over. You can verify this for yourself using the following code: <?php // reference: http://php.net/manual/en/context.ssl.php $ctx = stream_context_create(['ssl' => [ 'verify_peer' => TRUE, 'cafile' => '/path/to/cacert.pem', // <-- change to point to an actual CA file 'SNI_enabled' => TRUE ]]); $uri = https://sni.velox.ch/ // <--- A test site using SNI certs $result = file_get_contents($uri, FALSE, $ctx); P.S. Thank you to whomever updated http://php.net/manual/en/context.ssl.phpto reflect the "disable_compression" SSL stream context option (and subsidized my laziness) :) On Wed, Sep 18, 2013 at 9:06 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:// streams disable peer verification by >>> default. While I understand that this is necessary to provide the easiest >>> possible user experience for things like `file_get_contents(" >>> https://somesite.com";)`, it's also horribly insecure. 99% of people >>> using >>> tools like this won't know anything about this "feature" and won't >>> realize >>> that their stream transfers are totally vulnerable to Man-in-the-Middle >>> attacks by default. >>> >> Count me as one of those that didn't know https:// streams didn't verify >> certificates. :) >> *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 >> should work right >> out of the box. > > > 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. > This is an oft seen scenario for cURL; the developer would see the > certificate issue, search online and continue with `CURLOPT_VERIFY_PEER => > 0`. That said, at least cURL is configured to check the certificate by > default. > > > >> >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > -- > -- > Tjerk >
