...

Sicurezza Paypal TLS 1.2 e http/1.1 con sistemi operativi più vecchi

Per molti mesi ci sono state ripetute richieste da parte di Paypal agli utenti delle interfacce fornite per aggiornare i loro sistemi alle versioni attuali o per stabilire connessioni solo attraverso i protocolli attuali. In linea di principio, questo non è un problema, perché la maggior parte dei sistemi operativi, anche quelli di diversi anni, possono supportare questo senza problemi.

Potete testare il vostro sistema, ad esempio, con il seguente comando:

php -r '$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://tlstest.paypal.com/"); var_dump(curl_exec($ch)); var_dump(curl_error($ch));'

Il valore di ritorno è

PayPal_Connessione_OKbool(true)
stringa(0) "

o se non funziona:

bool(falso)
stringa(17) "SSL connect error"

Quest'ultimo errore si verifica, ad esempio, sotto Redhat/Centos6.

In linea di principio, il collegamento con Redhat6 funziona anche sotto tls 1.2 ma purtroppo il programma usato "curl" non negozia automaticamente questa connessione con tls1.2. Questo bug è stato aggiornato da Redhat in maggio e sarà presto disponibile anche per Centos6. Come operatore di webserver dovreste quindi aggiornare tutti i pacchetti all'ultima versione e soprattutto usare curl dalla versione 7.19.7-52. Redhat

Fino ad allora si dovrebbe chiedere a Curl di utilizzare la versione attuale, ad esempio con :

php -r '$ch = curl_init(); curl_setopt($ch, CURLOPT_SSLVERSION, 6); curl_setopt($ch, CURLOPT_URL, "https://tlstest.paypal.com/"); var_dump(curl_exec($ch)); var_dump(curl_error($ch));".

Ma non c'è bisogno di farsi prendere dal panico. A causa della pigrizia nell'aggiornamento della maggior parte degli utenti, Paypal ha prorogato il termine per la modifica dei protocolli o la disattivazione dei vecchi protocolli di 1 anno al 30.6.2017.

Articoli attuali

Distribuzione centralizzata delle patch con gruppi scaglionati per diversi server di hosting
Sicurezza

KernelCare ePortal per infrastrutture di hosting di grandi dimensioni

KernelCare ePortal centralizza la distribuzione e l'approvazione delle patch live in grandi parchi di sistemi Linux. L'articolo illustra quando vale la pena utilizzare questa piattaforma aggiuntiva e come gestire in modo controllato i cicli di patch, lo mirroring, la replica e i controlli di sicurezza.

Rappresentazione concettuale di un proxy inverso NGINX con cache del resolver DNS e indirizzi backend variabili.
Server web Plesk

Configurare correttamente la cache del resolver di NGINX

Ecco come configurare il resolver NGINX per i backend dinamici: TTL DNS, valid, resolver_timeout, destinazioni proxy_pass variabili e upstream dinamici chiaramente distinti l'uno dall'altro.