[wp-trac] [WordPress Trac] #36320: PayPal 2016 merchant security upgrades - Core defaults need to be changed

[WordPress Trac]

#36320: PayPal 2016 merchant security upgrades - Core defaults need to be changed
--------------------------+------------------------
 Reporter:  reidbusi      |       Owner:
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  HTTP API      |     Version:  4.4.2
 Severity:  major         |  Resolution:  duplicate
 Keywords:                |     Focuses:
--------------------------+------------------------

Comment (by reidbusi):

 Replying to [comment:17 rmccue]:

 I agree @rmccue, after having noted @mozzak's results with the streams
 transport. Thus my current solution looks like this (only affecting
 connections to paypal):

 {{{#!php
 <?php
 /*
 Plugin Name: Merchant Security Upgrades 2016 PayPal Fix for WordPress
 Description: Corrects WordPress functions to allow the PayPal Standard
 gateway for WooCommerce to work with PayPal's new security restrictions.
 Requires TLS 1.2 and HTTP/1.1 to be working in PHP/curl on your server.
 Author: reidbusi
 Version: 1.1
 */

 if ( ! defined( 'ABSPATH' ) ) {
         exit;
 }

 function rbst_http_api_curl( &$cr ) {

         $cr_url = curl_getinfo( $cr, CURLINFO_EFFECTIVE_URL );
         $cr_url_parts = parse_url( $cr_url );
         if ( $cr_url_parts['scheme'] == 'https' ) {
                 if ( $cr_url_parts['host'] == 'www.paypal.com' ||
 $cr_url_parts['host'] == 'www.sandbox.paypal.com' ) {
                         curl_setopt( $cr, CURLOPT_HTTP_VERSION,
 CURL_HTTP_VERSION_1_1 );
                         curl_setopt( $cr, CURLOPT_SSLVERSION, 6);
                 }
         }

 }
 add_action( 'http_api_curl', 'rbst_http_api_curl', 9999, 1 );
 }}}

 I would have passed and used the $r and $url params as provided by:
 {{{#!php
 <?php
 do_action_ref_array( 'http_api_curl', array( &$handle, $r, $url ) );
 }}}

 ... but they don't really work - it appears wp-cron uses curl to talk to
 itself and can run at any time on any request and interferes with using
 the $url parameter to detect the url, where using curl_getinfo() to get
 the url works consistently.

 The most reliable way around this that I can envision is to somehow re-
 implement TLS 1.2 in php to make WordPress independent of OpenSSL and/or
 cURL. Since we cannot know what the status of OpenSSL or cURL is on any
 particular host, the only reliable solution is to DIY. Not sure how to
 achieve this, or if it would even be possible, but it is the right way as
 I see it. fsockopen() depends on OpenSSL for tls, so that's out...

 PHP sockets might be workable, but again, we cannot know if any particular
 host as built php with --enable-sockets.

 I'll dig around a bit and see if it might be possible to create a host
 independent TLS 1.2 solution for php.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36320#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform