[wp-trac] [WordPress Trac] #34794: CURLOPT_SSL_VERIFYHOST should be set to 2 or not be set at all
WordPress Trac
noreply at wordpress.org
Tue Dec 1 01:09:52 UTC 2015
#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
More information about the wp-trac
mailing list