问题描述
我正在使用CURL通过SSL请求URI的PHP组件遇到以下错误:
I am running into the following error from a PHP component that uses CURL to request a URI via SSL:
cURL error 35: gnutls_handshake() failed: A TLS packet with unexpected length was received.
此错误在travis-ci.org环境中发生，但在我们的任何测试环境中均未发生.请参阅travis-ci构建 144663700 .
This error occurs in the travis-ci.org environment, but not in any of our test environments. See travis-ci build 144663700.
我发现Travis worker中运行的PHP版本在"Ubuntu 12.04.5 LTS"上重新编译为"GnuTLS/2.12.14"，或者在"Ubuntu 14.04.3 LTS"上重新编译为"GnuTLS/2.12.23".
I have found out that the PHP version running in the Travis worker is compiled again "GnuTLS/2.12.14" on "Ubuntu 12.04.5 LTS" or with "GnuTLS/2.12.23" on "Ubuntu 14.04.3 LTS".
在我们的开发环境中，我们使用在Debian(各种版本)上针对"OpenSSL/1.0.1t"编译的标准软件包.
In our development environments, we use standard packages compiled against "OpenSSL/1.0.1t" on Debian (various versions).
因此，我认为问题与"GnuTLS/2.12.14"或"GnuTLS/2.12.23"或与它们一起被编译的参数有关.
Therefore, I assume the problem is related to "GnuTLS/2.12.14" or "GnuTLS/2.12.23", or the parameters with which they have been compiled.
我尝试使用CURL常量CURLOPT_SSLVERSION限制SSL版本，但这不能解决问题.
I have tried limiting the SSL versions with the CURL constant CURLOPT_SSLVERSION, but that does not solve the problem.
根据www.ssllabs.com，有问题的主机api.reporting.cloud支持TLS 1.2，TLS 1.1和TLS 1.0.
According to www.ssllabs.com the host in question - api.reporting.cloud - supports TLS 1.2, TLS 1.1 and TLS 1.0.
有人对我有任何提示或指示吗?
Would anyone have any hints or pointers for me?
推荐答案
此问题的一种解决方法是将travis-ci配置为使用标准的Ubuntu Trusty php5-cli和php5-curl软件包.标准软件包提供了CURL_SSLVERSION_TLSv1_1常量.
A workaround to this problem is to configure travis-ci to use the standard Ubuntu Trusty php5-cli and php5-curl packages. The standard packages offer the CURL_SSLVERSION_TLSv1_1 constant.
.travis.yml文件如下所示:
The .travis.yml file looks like this:
sudo: required
dist: trusty
language: php
before_install:
- sudo apt-get -y install git zip php5-cli php5-curl
before_script:
- php -r "printf('PHP %s', phpversion());"
- composer self-update
- composer install --no-interaction
script:
- mkdir -p ./build/logs
- ./vendor/bin/phpunit
在PHP源代码中，在travis-ci执行PHP代码的情况下，只需设置上述常量即可.
In the PHP source, it is then simply a matter of setting the aforementioned constant in the case of the PHP code being executed by travis-ci:
if (getenv('TRAVIS')) {
$options['curl'][CURLOPT_SSLVERSION] = CURL_SSLVERSION_TLSv1_1;
}
此解决方法的缺点是，它仅适用于Ubuntu Trusty提供的特定PHP版本(PHP 5.5).考虑到PHP 5.5于2016年7月10日到期，该解决方案是不可接受的.
This workaround has the disadvantage that it only works on the specific PHP version that Ubuntu Trusty offers (PHP 5.5). Considering PHP 5.5 reached end of life on July 10, 2016, this solution is not acceptable.
将travis-ci更新到Ubuntu 16.04 LTS是理想的选择，但是travis-ci的基础架构经理Brandon Burton 写于2016年2月28日:
It would be ideal for travis-ci to update to Ubuntu 16.04 LTS, but Brandon Burton, Infrastructure Manager at travis-ci wrote on February 28, 2016:
因此，似乎我们对Ubuntu Trusty停留了一段时间.
Therefore, it would seem we are stuck with Ubuntu Trusty for a while.
此问题的根源是从travis-ci上运行的PHP版本是从2011年开始使用gnutls-cli(GnuTLS)2.12.23编译的.此gnutls-cli的特定版本存在一些问题(但不是全部))TLS 1.2连接.
The root of this problem is that the PHP version that runs on travis-ci was compiled with gnutls-cli (GnuTLS) 2.12.23, from 2011. This specific version of gnutls-cli has problems with some (but not all) TLS 1.2 connections.
@ travis-ci:是否可以针对更现代的GnuTLS版本重新编译您使用的PHP版本-或至少一个更好地支持TLS 1.2的版本?
@travis-ci: Would it be possible to re-compile the PHP versions you use against a more modern version of GnuTLS -- or at least one that better supports TLS 1.2?
这篇关于cURL错误35:gnutls_handshake()失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！