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

 Replying to [comment:11 rmccue]:

 > 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.

 Well, I can't suss why, but there ''does'' seem to be something different
 about the loopback connection; the connection only ever fails when it's
 back to the same machine.

 > My theory of why this is happening: if both peer and host verification
 are off, the socket doesn't get initialised correctly.

 We can leave peer verification switched on, though -- it's only when
 switching off host verification that the problem crops up. (I realise that
 makes no sense when the host and the peer are the same...)

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

 Cool -- thank you very much for that. Fingers crossed that something
 worthwhile may yet come from my initial hair-pulling with this; I don't
 have a lot to spare.

 > > 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)?

 (I just need to correct what I said above about having switched off local
 verification due to the CAINFO problem: it was necessary to shut it off
 with earlier WP versions when using Server 4 on Yosemite, and it was the
 CAINFO problem in 4.3 which actually broke that as a fix, requiring
 backporting of the 4.4 code I mentioned at the start of this ticket in
 order to fix the fix.)

 People hosting WordPress on OS X have been in for a rough ride the during
 the last two versions, as various bits and pieces changing in the HTTP API
 class, combined with the ongoing expunging of OpenSSL from OS X, have
 created one problem after another. But in this case, I think it would be
 best just to recommend that folks keep local verification on, even at the
 cost of leaving a (hopefully narrow) set of users out in the cold.

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