Est-il prudent d'utiliser sslverify = true avec wp_remote_get / wp_remote_post

16

J'utilise normalement cet argument pour éviter les erreurs avec wp_remote_get et wp_remote_post

array(
    'sslverify' => false
)

Pour des raisons de sécurité, j'aimerais le définir sur true (ou le supprimer car la valeur par défaut est true).

Dois-je m'attendre à des problèmes en faisant cela?

    
posée Xaver 09.11.2014 - 10:47

3 réponses

21

TL; DR: Oui, supprimez ce paramètre à partir de WordPress 3.7 ou version ultérieure.

Auparavant, de nombreuses personnes ajoutaient le paramètre sslverify = false spécifiquement parce que leur installation de PHP ne permettait pas de vérifier correctement le certificat.

En règle générale, cela était dû au fait que l'installation de PHP n'avait pas été mise à jour avec la dernière copie des certificats racine de l'autorité de certification. Les certificats racine changent de temps en temps et normalement, vous ne remarquerez pas ce changement, car il se produit dans les mises à jour normales du navigateur. Eh bien, lorsque PHP agit comme un navigateur pour récupérer des URL https, il a également besoin de ces mises à jour du certificat racine. Et la plupart des hôtes ne mettent jamais à jour PHP, ni aucune partie spécifique de celui-ci (comme le fichier de certificats).

Lorsque WordPress a implémenté la mise à jour automatique dans la version 3.7, il a été jugé nécessaire de mettre à niveau les API WordPress.org pour exiger une communication sécurisée. À ce moment, WordPress a commencé à inclure une copie du fichier de certificats de racine de CA lui-même, provenant de Mozilla. Par conséquent, depuis WordPress 3.7, les fonctions de l’API WP_HTTP utilisent ce fichier pour effectuer la vérification du certificat, et non la version ancienne ou obsolète fournie avec votre installation PHP.

Par conséquent, avec WordPress version 3.7 ou ultérieure, il est conseillé de supprimer le paramètre sslverify et de permettre aux fonctions http de procéder à la vérification appropriée des certificats. Tout serveur moderne exécutant SSL avec une clé signée par l'une des autorités de certification connues sera correctement vérifié. WP_HTTP doit avoir une copie des derniers certificats racine et le projet principal mettra à jour ce fichier de certificats dans WordPress avec les mises à jour normales.

    
réponse donnée Otto 09.11.2014 - 22:39
8

Il existe une multitude de raisons qui peuvent laisser une vérification SSL échouer. En partant d'un trop grand nombre de redirections vers les mauvais fichiers / configurations .ini ou tout simplement les certificats ou sous-domaines manquants. Dans tous les cas, vous devrez rechercher la raison et y remédier . Il n'y a pas de contournement.

Mais pour temporairement contourner ce problème (supposons que vous deviez développer votre code et réparer l'erreur SSL ultérieurement), vous pouvez utiliser un filtre:

add_filter( 'https_ssl_verify', '__return_false' );

Comme vous l'exécutez lors d'une requête distante, vous devez l'envelopper dans un rappel attaché à un filtre déclenché lors d'une telle requête HTTP. Assurez-vous de vérifier si vous supprimez réellement la vérification du cas correct - et assurez-vous de ne l'exécuter que une fois pour ne pas non plus sécuriser les autres requêtes.

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

S'il s'agit d'un plugin distribué publiquement, vous voudrez peut-être l'associer à une simple option que l'utilisateur peut activer ou désactiver. Vous pouvez également essayer d’abord la demande vérifiée et si ce n’est pas le cas (et si l’utilisateur a choisi une demande non signée), passez ensuite à une demande potentiellement non sécurisée.

  

Règle générale:

     

Ne jamais exécutez une demande non sécurisée tant que l'utilisateur n'a pas accepté   faites-le et connaissez les risques.

    
réponse donnée kaiser 09.11.2014 - 14:46
3

WordPress peut s’appuyer sur le logiciel serveur sous-jacent (généralement cURL) pour effectuer les requêtes réseau. En un mot, c’est ce que ce logiciel est bon et fait pour.

Sur certains serveurs, pour diverses raisons (je ne me suis jamais soucié de mon état personnel), il est très courant que les logiciels de serveur ne puissent pas "vérifier" les connexions sécurisées, ce qui produit les erreurs en question.

Donc:

  • s'il s'agit d'un code privé sur les serveurs que vous contrôlez, vous devez vous assurer que les serveurs effectuent les demandes correctement et que ce paramètre n'est pas désactivé
  • si c'est du code pour distribution publique, vous ne voudrez probablement pas le désactiver non plus, mais s'il est assez populaire, il se retrouvera sur des serveurs où il est cassé à un moment donné et vous devrez le supporter sous une forme ou une autre ( de dire aux gens qu’une configuration appropriée est censée fournir un paramètre permettant de la désactiver pour vos demandes , etc.)
réponse donnée Rarst 09.11.2014 - 12:49

Lire d'autres questions sur les étiquettes