我们开始在PHP中使用Guzzle,其代码调用各种不同的API,其中一些不支持TLSv1.2,其中一些需要TLSv1.2.
迫使Guzzle使用最新协议的最佳方法是什么,除非我们知道它不会被识别?
解决方法:
它简单易行.
$client = new Client();
$guzzle = new GuzzleClient('https://www.yourweb.com', array(
'curl.options' => array(
CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2
)
));
$client->setClient($guzzle);
...
在Guzzle 3.0中(根据@limos的评论更新):
'curl' => array(
CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2
)
可以在官方cURL页面找到可能的CURLOPT_SSLVERSION选项:http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html
—更新(根据评论)—
选择正确的SSL协议版本不仅涉及CURLOPT_SSLVERSION设置,还涉及更多cURL设置.所期望的重要结果称为“最大前向保密”.
这不仅适用于cURL!
你不能使用多个CURLOPT_SSLVERSION参数(至少,我没有在Guzzle文档中找到这样的选项).当您定义CURLOPT_SSLVERSION时,cURL将尝试使用该SSL版本 – 来自cURL文档(上面提供的有关CURLOPT_SSLVERSION的链接) – “传递一个长参数来控制尝试使用哪个版本的SSL / TLS”.
您可以定义多个安全密码,但只能定义一个SSL版本参数.我不会早于TLS 1.1使用任何东西.任何早期的SSL版本都容易受到攻击.版本TLS 1.1也很容易受到攻击,但如果你走这条路,你可能会遇到1.2的客户端兼容性问题.唯一安全(目前,直到他们发现一些漏洞)是TLS 1.2.
如果安全性是最重要的,请使用最高可用的TLS版本(TLS1.2).当存在服务提供商安全责任时,客户端兼容性不是您的问题.
如果安全性很重要,可以参考以下其他cURL选项:
> CURLOPT_SSL_VERIFYHOST
> CURLOPT_SSL_VERIFYPEER
> CURLOPT_CAINFO(cURL在其网站CA CERTs提供)
> CURLOPT_SSL_CIPHER_LIST
设置正确的CURLOPT_SSL_VERIFYHOST和CURLOPT_SSL_VERIFYPEER将防止MITM攻击.
CURLOPT_CAINFO – 修复错误:35 – 连接中的未知SSL协议错误.提高最大前向保密性.
这是一个包含cURL密码(CURLOPT_SSL_CIPHER_LIST)的列表,可以提高最大前向保密性:
'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'
根据强大的Qualys SSL Labs列表(2014)检查了这些密码,并删除了弱密码.随意添加/删除任何密码.
如果您仍想要追求多个CURLOPT_SSLVERSION选项,我会编写一个脚本来执行此操作(我认为这不是一个好习惯或必要).但是,如果您决定出于任何原因继续使用该功能,请编写一些代码,尝试使用最强的SSL加密,然后回退到下一个版本,如果它无法连接.
>在您做出决定之前,请先查看Qualys SSL Labs的projects有关安全性的信息.
>看看this SSL Labs’ article关于完美的前瞻性保密和最佳实践.
>使用SSL Labs’ web tool测试您的客户端(Web浏览器)是否存在任何漏洞.这将让您了解在服务器和应用程序上要查看的内容以及改进和保护的内容.
>使用Qualys的SSL Labs SSL tool测试您的网站/ Web服务.
漏洞和攻击:Longjam,FREAK,POODLE,你的名字!谁知道其他攻击或漏洞未被发现?是!它们都会影响您选择的SSL / TLS连接.
您无法控制客户端(除非您开发它),但您可以控制服务器和服务器 – 客户端协商.
无论您构建什么应用程序,都应该根据自己的需要和每个案例来查看最佳实践,您应该决定以下选项:
>安全
>兼容性
>可维护性
>复杂性
如果安全性如此重要,请至少使用TLS1.1.
看看密码列表,我不会忽略那一部分.
这也是你的应用程序周围的一个不错的OWASP guide for creating a secure layer.
OWASP和Qualys SSL实验室是很好的资源.我甚至会对cURL和OpenSSL进行一些研究,以熟悉弱点,可能的安全选项和最佳实践.
有安全点,我没有提及,但缺少,但我们无法涵盖一切.这只是冰山一角.
这里没有提到的任何东西供你研究.
祝好运!
如果可以的话,我会回答任何问题.