Stiamo iniziando a utilizzare Guzzle in PHP con codice che chiama una varietà di API diverse, alcune delle quali non supportano TLSv1.2 e alcune richiedono TLSv1.2.Come specifichiamo le opzioni TLS/SSL in Guzzle?
Qual è il modo migliore per forzare Guzzle a utilizzare il protocollo più recente disponibile, tranne nei casi in cui sappiamo che non verrà riconosciuto?
È semplice e facile.
$client = new Client();
$guzzle = new GuzzleClient('https://www.yourweb.com', array(
'curl.options' => array(
CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2
)
));
$client->setClient($guzzle);
...
In Guzzle 3.0+ (aggiornamento come da commento @limos'):
'curl' => array(
CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2
)
Le possibili opzioni CURLOPT_SSLVERSION si possono trovare presso la pagina ufficiale cURL: http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html
--- UPDATE (in base ai commenti) ---
La scelta della versione del protocollo SSL corretta non implica solo l'impostazione CURLOPT_SSLVERSION, ma molte più impostazioni CURL. Il risultato desiderato e importante è chiamato "Maximum forward secret". Questo è valido non solo per cURL!
Non è possibile utilizzare più parametri CURLOPT_SSLVERSION (almeno, non ho trovato tale opzione nella documentazione di Guzzle). Quando si definisce CURLOPT_SSLVERSION, cURL tenterà di utilizzare quella versione SSL, dalla documentazione di cURL (il collegamento fornito in precedenza su CURLOPT_SSLVERSION) - "Passa un lungo parametro per controllare quale versione di SSL/TLS tentare di utilizzare."
È possibile definire più crittografi sicuri, ma solo un parametro di versione SSL. Non userei niente prima di TLS 1.1. Qualsiasi versione precedente di SSL è vulnerabile agli attacchi. Anche la versione TLS 1.1 è vulnerabile, ma in questo caso è possibile che si verifichino problemi di compatibilità con il client alla 1.2, se si segue questa strada. L'unico sicuro (per ora, finché non scoprono qualche vulnerabilità) è TLS 1.2.
Se la sicurezza è la priorità, andare con la versione TLS disponibile più alta (TLS1.2). La compatibilità del client non è un problema quando esiste una responsabilità per la sicurezza del fornitore di servizi.
Se la sicurezza è importante, qui altre opzioni curl per guardare:
Impostazione corretta CURLOPT_SSL _VERIFYHOST e CURLOPT_SSL_VERIFYPEER prevengono gli attacchi MITM.
CURLOPT_CAINFO - Errore di correzione: 35 - Errore del protocollo SSL sconosciuto nelle connessioni. Migliora la massima segretezza in avanti.
Ecco una lista con gli algoritmi Curl (CURLOPT_SSL_CIPHER_LIST) di esaminare, che permetterà di migliorare la massima segretezza in avanti:
'DHE-RSA-AES256-SHA',
'DHE-DSS-AES256-SHA',
'AES256-SHA',
'ADH-AES256-SHA',
'KRB5-DES-CBC3-SHA',
'EDH-RSA-DES-CBC3-SHA',
'EDH-DSS-DES-CBC3-SHA',
'DHE-RSA-AES128-SHA',
'DHE-DSS-AES128-SHA',
'ADH-AES128-SHA',
'AES128-SHA',
'KRB5-DES-CBC-SHA',
'EDH-RSA-DES-CBC-SHA',
'EDH-DSS-DES-CBC-SHA:DES-CBC-SHA',
'EXP-KRB5-DES-CBC-SHA',
'EXP-EDH-RSA-DES-CBC-SHA',
'EXP-EDH-DSS-DES-CBC-SHA',
'EXP-DES-CBC-SHA'
Queste cifre sono state controllate contro il forte lista Qualys SSL Labs (2014) e cifrari deboli sono stati rimossi . Sentiti libero di aggiungere/rimuovere qualsiasi cifra.
Se si desidera continuare con più opzioni CURLOPT_SSLVERSION, scriverei uno script per farlo (che, non penso sia una buona pratica o necessaria). Tuttavia, se si decide di perseguire tale funzionalità per qualsiasi motivo, scrivere un codice che tenterà di utilizzare la crittografia SSL più potente possibile e quindi eseguire il fallback alla versione successiva, se non riesce a connettersi.
Vulnerabilità e attacchi: Longjam, FREAK, POODLE, è il nome! Chissà quali altri attacchi o vulnerabilità non sono stati scoperti? Sì! Influiscono tutti sulla scelta della connessione SSL/TLS.
Non si ha alcun controllo sul client (a meno che non lo si sviluppi), ma si ha il controllo sulle negoziazioni server e server-cliente.
Non importa quale applicazione si costruisce, si dovrebbe guardare a best practice, a seconda delle vostre esigenze e per ogni caso, si dovrebbe decidere sulle seguenti opzioni:
Se la sicurezza è così importante, andare con TLS1.1 al minimo. Guarda anche le liste di codici, non trascurerei quella parte.
Ecco anche un bel OWASP guide for creating a secure layer intorno all'app.
OWASP e Qualys SSL Labs sono ottime risorse per iniziare. Vorrei anche fare qualche ricerca su cURL e OpenSSL per familiarizzare con i punti deboli, le possibili opzioni di sicurezza e le migliori pratiche.
Ci sono punti di sicurezza, che non sto menzionando e mancano, ma non possiamo coprire tutto. Questa è solo la punta dell'iceberg. Qualsiasi cosa non menzionata qui è per voi per la ricerca.
Buona fortuna!
Sarò qui per rispondere a qualsiasi domanda, se posso.
In Guzzle 5.3, ho dovuto usare la seguente sintassi:
$guzzle = new \GuzzleHttp\Client([
'defaults' => [
'config' => [
'curl' => [
CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2
]
]
]
]);
OK, in modo che possiamo avere o negoziazione automatica (default) o impostare una sola versione del protocollo di accettare? Speravo che potesse esserci un modo per dargli un set di versioni di protocollo e fargli scegliere il più recente. – MattC
Corretto, non è possibile utilizzare più parametri CURLOPT_SSLVERSION (almeno, non ho trovato tale opzione nella documentazione di Guzzle).Quando definisci CURLOPT_SSLVERSION, cURL tenterà di utilizzare quella versione SSL. Dalla documentazione di cURL (il link fornito) "Passa un lungo parametro per controllare quale versione di SSL/TLS tentare di utilizzare." È possibile definire più crittografi sicuri, ma solo un parametro di versione ssl. Non userei niente prima di TLS 1.1. Qualsiasi versione precedente di SSL è vulnerabile agli attacchi. Anche la v1.1 è vulnerabile, ma poi ci imbattiamo in problemi di compatibilità con il client in 1.2 – GTodorov
Ho deciso di aggiornare la mia risposta, perché non c'è una risposta semplice alla tua domanda. – GTodorov