É seguro usar o sslverify = true com wp_remote_get / wp_remote_post

16

Eu normalmente uso esse argumento para evitar erros com wp_remote_get e wp_remote_post

array(
    'sslverify' => false
)

Por motivos de segurança, gostaria de defini-lo como true (ou removê-lo, pois o padrão é verdadeiro).

Devo esperar algum problema ao fazer isso?

    
por Xaver 09.11.2014 / 10:47

3 respostas

21

TL; DR: Sim, remova essa configuração no WordPress 3.7 ou posterior.

No passado, muitas pessoas adicionavam o parâmetro sslverify = false especificamente porque a instalação do PHP não era capaz de verificar corretamente o certificado.

Normalmente, isso ocorre porque a instalação do PHP não foi atualizada com a cópia mais recente dos Certificados Raiz da CA. Os certificados de raiz mudam de vez em quando, e normalmente você não percebe essa mudança porque isso acontece nas atualizações normais do navegador. Bem, quando você tem o PHP agindo como um navegador para recuperar URLs https, ele também precisa dessas atualizações do certificado raiz. E a maioria dos hosts nunca atualiza o PHP, nem atualiza qualquer parte específica dele (como o arquivo de certificados).

Quando o WordPress implementou a atualização automática na versão 3.7, foi determinado que seria necessário atualizar as APIs do WordPress.org para exigir comunicação segura. No momento, o WordPress começou a incluir uma cópia do próprio arquivo de certificados raiz da CA, originado da Mozilla. Desde o WordPress 3.7, portanto, as funções da API WP_HTTP usam este arquivo para fazer a verificação do certificado, e não qualquer versão antiga ou desatualizada é empacotada com a sua instalação do PHP.

Portanto, sim, com o WordPress 3.7 ou posterior, é aconselhável remover o parâmetro sslverify e permitir que as funções http executem a verificação adequada do certificado. Qualquer servidor moderno que execute SSL com uma chave assinada por uma das CAs conhecidas será verificado corretamente. O WP_HTTP deve ter uma cópia dos certificados raiz mais recentes, e o projeto principal atualizará esse arquivo de certificados no WordPress junto com as atualizações normais.

    
por Otto 09.11.2014 / 22:39
8

Existem vários motivos pelos quais uma verificação de SSL pode falhar. Começando de muitos redirecionamentos para .ini files / setups errados ou simplesmente perdendo certificados ou sub-domínios. Em qualquer caso, você precisará pesquisar o motivo para isso e corrigi-lo . Não há nenhum meio de contorno.

Mas para resolver temporariamente esse problema (digamos que você precise desenvolver mais o seu código e corrigir o erro SSL mais tarde), você pode usar um filtro:

add_filter( 'https_ssl_verify', '__return_false' );

Como você está executando isso durante uma solicitação remota, você deve envolvê-lo em um retorno de chamada anexado a um filtro que é acionado durante uma solicitação HTTP. Certifique-se de verificar se você realmente está removendo a verificação para o caso correto - e certifique-se de executar apenas uma vez para não desabilitar outras solicitações.

add_filter( 'http_request_args', function( $params, $url )
{
    // find out if this is the request you are targeting and if not: abort
    if ( 'foo' !== $params['foo'] )
         return $params;

    add_filter( 'https_ssl_verify', '__return_false' );

    return $params;
}, 10, 2 );

Se esse for um plug-in distribuído publicamente, convém anexá-lo a uma opção simples que o usuário pode ativar ou desativar. Você também pode tentar a solicitação verificada primeiro e, se não (e se o usuário tiver optado por uma solicitação não assinada), alterne para uma solicitação potencialmente insegura.

  

Regra geral:

     

Não faça nunca executar uma solicitação não segura até que o usuário tenha concordado com   faça isso e saiba dos riscos.

    
por kaiser 09.11.2014 / 14:46
3

O WordPress pode contar com o software de servidor subjacente (normalmente cURL) para executar solicitações de rede. Em suma, porque é o que esse software é bom e está lá para.

Em alguns servidores, devido a vários motivos (nunca me preocupei em investigar a mim mesmo), é bastante comum que o software de servidor não consiga "verificar" conexões seguras, produzindo esses erros.

Então:

  • se for um código privado nos servidores que você controla, verifique se os servidores estão fazendo solicitações corretamente e se essa configuração não está desativada
  • se esse for o código para distribuição pública, você provavelmente não desejará desativá-lo também, mas se ele for popular o suficiente, ele terminará em servidores em que ele está quebrado em algum momento e você terá que suportar isso de alguma forma ( de dizer às pessoas que a configuração adequada deve fornecer a configuração para desativá-lo para suas solicitações, e assim por diante)
por Rarst 09.11.2014 / 12:49