[wp-trac] [WordPress Trac] #34794: CURLOPT_SSL_VERIFYHOST should be set to 2 or not be set at all

[WordPress Trac]

#34794: CURLOPT_SSL_VERIFYHOST should be set to 2 or not be set at all
--------------------------+-----------------------------
 Reporter:  FriendlyGreg  |       Owner:  johnbillion
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  Future Release
Component:  HTTP API      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+-----------------------------

Comment (by rmccue):

 Replying to [comment:10 FriendlyGreg]:
 > @rmccue, the script you mentioned won't reveal the problem except in the
 case of connecting back locally to the same server, but in that specific
 case, yes, it replicates the issue exactly as described.

 As far as I can see, there's nothing special about the loopback
 connection, apart from being able to control the server? The client should
 still be connecting via HTTP + SSL over port 443 for remote and loopback
 connections; I don't think the system does any optimisation there.

 > Since the code appears to have been meant to be advisory rather than
 fatal, I'm not sure whether this is a PHP problem or an oversight in
 Darwin.

 From what I can see, the code indicates that the SSL handling code either
 hasn't run the handshake properly (and needs to complete it), or the
 socket has been exhausted and needs to be reinitialised via another
 handshake.

 My theory of why this is happening: if both peer and host verification are
 off, the socket doesn't get initialised correctly. Either of these being
 on would initiate the handshake (and both would do it once), but both
 being off causes the handshake to never take place. My bet is on this
 being a bug in cURL, but it's possible this is a problem in
 SecureTransport/OSX (as evidenced by RC4 affecting it).

 (In either case, I'll report this upstream to cURL.)

 > The good news, however, is that restoring local verification will solve
 the problem. For those users like me who only shut it off in the first
 place because WordPress 4.3 introduced problems for Server 4 when it
 incorrectly set CAINFO, we can switch it back on when running Server 5,
 and bunnies are happy everywhere.

 Given this, should we fix it here, or simply recommend verification is
 left on (in your opinion)?

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