Este sigur să folosim sslverify => true pentru wp_remote_get/wp_remote_post

Question

Este sigur să folosim sslverify => true pentru wp_remote_get/wp_remote_post

9 nov. 2014, 11:47:00

Vizualizări: 25.9K

Voturi: 27

În mod normal folosesc acest argument pentru a preveni erorile cu wp_remote_get și wp_remote_post

array(
    'sslverify' => false
)

Din motive de securitate aș dori să îl setez la true (sau să-l elimin deoarece valoarea implicită este true).

Ar trebui să mă aștept la probleme făcând acest lucru?

Xaver

1.04K

ssl curl wp-remote-request

Toate răspunsurile la întrebare

Comentarii

Mulțumesc Otto, cred că acest lucru ajută foarte mult. Voi face o verificare condiționată în plugin-ul meu

Xaver

10 nov. 2014 14:17:37

Există o mulțime de motive care pot duce la eșecul verificării SSL. De la prea multe redirectări până la fișiere/configurări greșite în .ini sau pur și simplu certificate sau subdomenii lipsă. În orice caz, va trebui să cauți motivul și să îl rezolvi. Nu există nicio soluție ocolitoare.

Dar pentru a temporar ocoli această problemă (de exemplu, dacă ai nevoie să continui dezvoltarea codului și să repari eroarea SSL mai târziu), poți folosi un filtru:

add_filter( 'https_ssl_verify', '__return_false' );

Deoarece această comandă rulează în timpul unei cereri externe, ar trebui să o înfășori într-un callback atașat unui filtru declanșat în timpul unei astfel de cereri HTTP. Asigură-te că elimini verificarea doar pentru cazul corect — și că rulezi acest cod doar o singură dată, pentru a nu compromite alte cereri.

add_filter( 'http_request_args', function( $params, $url )
{
    // verifică dacă aceasta este cerinta țintă și, dacă nu, întrerupe
    if ( 'foo' !== $params['foo'] )
         return $params;

    add_filter( 'https_ssl_verify', '__return_false' );

    return $params;
}, 10, 2 );

Dacă acesta este un plugin distribuit public, atunci poți atașa acest cod unei opțiuni simple pe care utilizatorul o poate activa sau dezactiva. De asemenea, poți încerca mai întâi cererea verificată și, dacă nu funcționează (iar utilizatorul a optat pentru o cerere nesemnată), să treci la o cerere potențial nesigură.

Regulă generală:

Nu efectua niciodată o cerere nesecurizată până când utilizatorul tău nu a dat acordul și este conștient de riscuri.

kaiser

50.8K

9 nov. 2014 15:46:06

Comentarii

Mulțumesc, caut acum problema pe mediul meu local

Xaver

10 nov. 2014 14:18:19

WordPress se poate baza pe software-ul de server subiacent (de obicei cURL) pentru a efectua cereri de rețea. Pe scurt, pentru că acest software este bun la asta și există special pentru acest scop.

Pe unele servere, din diverse motive (pe care nu m-am obosit niciodată să le investighez), este destul de obișnuit ca software-ul de server să nu poată "verifica" conexiunile securizate, generând erorile menționate.

Deci:

dacă este vorba de cod privat pe servere pe care le controlezi, ar trebui să te asiguri că serverele efectuează cererile corect și că această setare nu este dezactivată
dacă este vorba de cod destinat distribuției publice, probabil că nici tu nu dorești să îl dezactivezi, dar dacă devine suficient de popular, va ajunge la un moment dat pe servere unde nu funcționează corect și va trebui să oferi suport într-o formă sau alta (de la a le spune oamenilor că se așteaptă o configurare corectă până la a oferi o setare pentru a-l dezactiva doar pentru cererile tale, și așa mai departe)

Rarst

100K

9 nov. 2014 13:49:55

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

TL;DR: Da, eliminați această setare începând cu WordPress 3.7 sau versiuni ulterioare.

În trecut, mulți oameni au adăugat parametrul sslverify=false în mod specific deoarece instalarea lor de PHP nu era capabilă să verifice corect certificatul.

De obicei, acest lucru se întâmpla deoarece instalarea PHP nu fusese actualizată cu cea mai recentă copie a Certificatele Root CA. Certificatele root se schimbă din când în când, iar în mod normal nu observați această schimbare deoarece are loc prin actualizările normale ale browserului. Ei bine, când PHP acționează ca un browser pentru a prelua URL-uri https, atunci are nevoie și de acele actualizări ale certificatele root. Iar majoritatea gazdelor nu actualizează niciodată PHP, nici nu actualizează nicio parte specifică a acestuia (cum ar fi fișierul de certificate).

Când WordPress a implementat actualizările automate în versiunea 3.7, s-a considerat necesar să se facă upgrade la API-urile WordPress.org pentru a necesita comunicare securizată. În acest moment, WordPress a început să includă o copie a fișierului Certificatele Root CA, preluată de la Mozilla. Prin urmare, începând cu WordPress 3.7, funcțiile API WP_HTTP folosesc acest fișier pentru a face verificarea certificatelor, și nu orice versiune veche sau învechită care este inclusă în instalarea dvs. PHP.

Prin urmare, da, cu WordPress 3.7 sau versiuni ulterioare, este recomandat să eliminați parametrul sslverify și să permiteți funcțiilor http să facă verificarea corectă a certificatelor. Orice server modern care rulează SSL cu o cheie semnată de unul dintre CA-urile cunoscute va fi verificat corect. WP_HTTP ar trebui să aibă o copie a celor mai recente certificate root, iar proiectul de bază va actualiza acel fișier de certificate în WordPress împreună cu actualizările normale.