CURLOPT_SSL_VERIFYHOST Should use 2 instead of true

[sivel]

CURLOPT_SSL_VERIFYHOST Should use an integer of 2 instead of true to enforce proper SSL verification. Setting to true acts like 1, which only checks for the existence of a common name, and not that the common name matches the requested hostname.

This was reported in another ticket #16855

[hakre]

Found by cogmios

[hakre]

​Related Comment

No need to be that strict on the evaluation of $ssl_verify btw.

[hakre]

Make setting more visible.

[hakre]

Hmm, I just ran over the fact that any (bool) is infact an (int), if it's TRUE it is (int) 1, if it is false, it is (int) 0.

So in case we don't change the current implementation, users of the cUrl transport are able to additionally specify 2 here, which is also (bool) TRUE for the second setting. Same for 1, it's (bool) TRUE for the second setting as well.

The unpatched code:

   curl_setopt( $handle, CURLOPT_SSL_VERIFYHOST, $ssl_verify ); 
   curl_setopt( $handle, CURLOPT_SSL_VERIFYPEER, $ssl_verify );

Forcing $ssl_verify to result in either 2 or 0 for CURLOPT_SSL_VERIFYHOST will remove the possibility to set the value to 1.

[hakre]

Hmm, and then there is the Streams context:

'ssl' => array(
		'verify_peer' => $ssl_verify,
		'verify_host' => $ssl_verify
)

I can not find the verify_host ​documented.

It's probably worth to list parameters and their current meaning.

With such a list we could more easily say which feature should be supported on the abstracted transports interface.

[sivel]

Replying to hakre:

​Related Comment

No need to be that strict on the evaluation of $ssl_verify btw.

In general we do try to be that strict with our checks in the HTTP API. We want to expect very specific values.

[dd32]

(In [17616]) Verify certificate matches both the common name and the provided hostname. WP_HTTP_Curl requires CURLOPT_SSL_VERIFYHOST be either 2 or false. Props sivel. Fixes #16904