[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 rmccue):

 Replying to [comment:23 mikejolley]:
 > @reidbusi not using constants is kinda hacky. Our code does check
 CURL_SSLVERSION_TLSv1 is defined before using it. You could set this
 constant to avoid needing to change core.

 In cURL-land, it's not terribly hacky, as the constant values are defined
 as part of the cURL API. The corresponding integer for TLS negotiation is
 `1`, for reference.

 Replying to [comment:24 reidbusi]:
 > Hacky or not, it is required on Hostgator shared hosting. I suppose I
 could define CURL_SSLVERSION_TLSv1_2 (there would be no point in defining
 CURL_SSLVERSION_TLSv1 for us, since our servers cannot negotiate a TLS
 connection via cURL). I don't see much point in defining
 CURL_SSLVERSION_TLSv1_2 in my plugin to use it three lines later either
 (I'd need to check if the define exists too). Thanks for the suggestion
 anyway.

 When your host says their SSL client code (presumably OpenSSL) doesn't
 support SSL negotiation, that sounds to me like it doesn't support
 v2/v3/TLS negotiation specifically, however I think it should correctly
 support TLS v1 subversion negotiation, based on my reading of the code,
 and also as mentioned in the RHEL bug:

 > With el6 libcurl, CURL_SSLVERSION_TLSv1_2 means "TLS 1.2 only" whereas
 CURL_SSLVERSION_TLSv1 means "TLS 1.x".  Both of them are known to work.

 Is it possible to try this set to `1` specifically (the value of
 `CURL_SSLVERSION_TLSv1` if it existed)? If that fixes the issue, we should
 be fine to ship this in core per #34924.

 > I still think the right answer is to re-implement TLS 1.2 in php somehow
 to remove all external dependencies that we just cannot assume are
 present. Nuke it from orbit - it's the only way to be sure.

 TLS is mostly not possible in PHP itself without reimplementing something
 like OpenSSL in userland, which is just a terrible idea, as it'd mean we
 need to maintain crypto code ourselves in WordPress. (I've attempted this
 before just to see if it were possible, and it's also extremely hard to
 get right.)

 At some point, there are times where we need to say that we don't support
 server configurations. If this is one of them, so be it. Let's make sure
 we've exhausted all of our options first.

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