¿Es seguro usar sslverify => true con wp_remote_get/wp_remote_post?

Question

¿Es seguro usar sslverify => true con wp_remote_get/wp_remote_post?

9 nov 2014, 11:47:00

Vistas: 25.9K

Votos: 27

Normalmente uso este argumento para prevenir errores con wp_remote_get y wp_remote_post

array(
    'sslverify' => false
)

Por razones de seguridad, me gustaría establecerlo a true (o eliminarlo ya que el valor predeterminado es true).

¿Debería esperar algún problema al hacer esto?

Xaver

1.04K

ssl curl wp-remote-request

Todas las respuestas a la pregunta

Comentarios

Gracias Otto, creo que esto ayuda mucho. Haré una verificación condicional en mi plugin

Xaver

10 nov 2014 14:17:37

Hay muchas razones por las que puede fallar la verificación SSL. Desde demasiadas redirecciones hasta archivos/configuraciones .ini incorrectos o simplemente certificados o subdominios faltantes. En cualquier caso, necesitarás buscar la razón de ello y solucionarlo. No hay manera de evitarlo.

Pero para temporalmente sortear ese problema (digamos que necesitas seguir desarrollando tu código y solucionar el error SSL más adelante), puedes usar un filtro:

add_filter( 'https_ssl_verify', '__return_false' );

Como estás ejecutando esto durante una solicitud remota, deberías envolverlo en una devolución de llamada adjunta a un filtro que se active durante dicha solicitud HTTP. Asegúrate de verificar si realmente estás eliminando la verificación para el caso correcto - y asegúrate de que solo lo ejecutes una vez para no comprometer la seguridad de otras solicitudes.

add_filter( 'http_request_args', function( $params, $url )
{
    // averigua si esta es la solicitud que estás buscando y si no: aborta
    if ( 'foo' !== $params['foo'] )
         return $params;

    add_filter( 'https_ssl_verify', '__return_false' );

    return $params;
}, 10, 2 );

Si se trata de un plugin distribuido públicamente, entonces podrías adjuntarlo a una opción simple que el usuario pueda activar o desactivar. También podrías intentar primero la solicitud verificada y si no (y si el usuario ha optado por una solicitud no firmada), entonces cambiar a una solicitud potencialmente insegura.

Regla general:

Nunca realices una solicitud insegura hasta que tu usuario haya aceptado hacerlo y conozca los riesgos.

kaiser

50.8K

9 nov 2014 15:46:06

Comentarios

Gracias, ahora estoy buscando el problema en mi entorno local

Xaver

10 nov 2014 14:18:19

WordPress puede depender del software del servidor subyacente (normalmente cURL) para realizar solicitudes de red. En resumen, porque es para lo que ese software es bueno y está ahí.

En algunos servidores, debido a varias razones (nunca me he molestado en investigarlo personalmente), es bastante típico que el software del servidor no pueda "verificar" las conexiones seguras, produciendo dichos errores.

Así que:

si se trata de código privado en servidores que controlas, deberías asegurarte de que los servidores realicen las solicitudes correctamente y que esta configuración no esté desactivada
si se trata de código para distribución pública, probablemente tampoco quieras desactivarlo, pero si es lo suficientemente popular, terminará en servidores donde esté roto en algún momento y tendrás que dar soporte de alguna forma (desde decirle a la gente que se espera una configuración adecuada hasta proporcionar un ajuste para desactivarlo para tus solicitudes, y así sucesivamente)

Rarst

100K

9 nov 2014 13:49:55

Otto 32.8K · Accepted Answer · 2014-11-09T23:39:46Z

TL;DR: Sí, elimina esa configuración a partir de WordPress 3.7 o versiones posteriores.

En el pasado, muchas personas añadían el parámetro sslverify=false específicamente porque su instalación de PHP no podía verificar correctamente el certificado.

Normalmente, esto se debía a que la instalación de PHP no se había actualizado con la última copia de los Certificados Raíz de CA. Los certificados raíz cambian de vez en cuando, y normalmente no te das cuenta de este cambio porque ocurre durante las actualizaciones normales del navegador. Bueno, cuando PHP actúa como un navegador para recuperar URLs https, también necesita esas actualizaciones de certificados raíz. Y la mayoría de los hosts nunca actualizan PHP, ni ninguna parte específica de él (como el archivo de certificados).

Cuando WordPress implementó las actualizaciones automáticas en la versión 3.7, se determinó que era necesario actualizar las APIs de WordPress.org para requerir comunicación segura. En ese momento, WordPress comenzó a incluir una copia del archivo de Certificados Raíz de CA, obtenido de Mozilla. Desde WordPress 3.7, por lo tanto, las funciones de la API WP_HTTP utilizan este archivo para realizar la verificación de certificados, y no la versión antigua o desactualizada que pueda estar empaquetada con tu instalación de PHP.

Por lo tanto, sí, con WordPress 3.7 o versiones posteriores, es recomendable eliminar el parámetro sslverify y permitir que las funciones http realicen la verificación adecuada de certificados. Cualquier servidor moderno que ejecute SSL con una clave firmada por una de las CAs conocidas se verificará correctamente. WP_HTTP debería tener una copia de los últimos certificados raíz, y el proyecto principal actualizará ese archivo de certificados en WordPress junto con las actualizaciones normales.