Как исправить завиток: (35) Нельзя безопасно связываться со сверстниками: нет общего алгоритма шифрования (ов)

Я пытаюсь получить доступ и загрузить некоторые .torrent файлы с https://torrage.com используя php curl . Но ничего не происходит, curl_error($ch) дает

 $ch = curl_init ('https://torrage.com/torrent/640FE84C613C17F663551D218689A64E8AEBEABE.torrent'); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0'); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true); curl_setopt($ch, CURLOPT_VERBOSE,true); $data = curl_exec($ch); $error = curl_error($ch); curl_close ($ch); echo $error; 

это дает.

 Cannot communicate securely with peer: no common encryption algorithm(s). 

Если я попробую из оболочки, как это

 [root@prod1 yum.repos.d]# curl -I https://torrage.com curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s). 

в подробном режиме

 [root@prod1 yum.repos.d]# curl -v https://torrage.com * Rebuilt URL to: https://torrage.com/ * Trying 81.17.30.48... * Connected to torrage.com (81.17.30.48) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP) * Cannot communicate securely with peer: no common encryption algorithm(s). * Closing connection 0 curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s). 

информация о системе centos 7. x86_64

 [root@prod1 yum.repos.d]# uname -a Linux prod1.localdomain 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux 

свернутая версия

 [root@prod1 yum.repos.d]# curl -V curl 7.29.0 (x86_64-redhat-linux-gnu) 

openssl, уже исправлен.

 [root@prod1 yum.repos.d]# openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Mon Jun 15 18:39:20 UTC 2015 platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/etc/pki/tls" engines: dynamic 

проверка правки openssl исправлена ​​или нет.

 [root@prod1 yum.repos.d]# rpm -q --changelog openssl | grep CVE-2014-0224 - fix CVE-2014-0224 fix that broke EAP-FAST session resumption support - fix CVE-2014-0224 - SSL/TLS MITM vulnerability 

Что я пробовал:

1) Я попытался использовать HTTP insted HTTPS, но сайт заставляет использовать HTTPS. например

 [root@prod1 yum.repos.d]# curl -I http://torrage.com HTTP/1.1 301 Moved Permanently Server: nginx/1.9.0 Date: Mon, 29 Jun 2015 04:13:17 GMT Content-Type: text/html Content-Length: 184 Connection: keep-alive Location: https://torrage.com/ 

2) обновление ca-bundle.crt

 cp /etc/pki/tls/certs/ca-bundle.crt /root/backup/ curl http://curl.haxx.se/ca/cacert.pem -o /etc/pki/tls/certs/ca-bundle.crt 

3) Обновление Curl до последней версии 7.43.0

 nano /etc/yum.repos.d/city-fan-for-curl.repo 

с этим репо.

 [CityFanforCurl] name=City Fan Repo baseurl=http://www.city-fan.org/ftp/contrib/yum-repo/rhel7/x86_64/ enabled=0 gpgcheck=0 

и затем

 yum update curl --enablerepo=CityFanforCurl 

затем проверить версию curl

 [root@prod1 yum.repos.d]# curl -V curl 7.43.0 (x86_64-redhat-linux-gnu) libcurl/7.43.0 NSS/3.18 Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.6.0 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets Metalink 

4) Я попробовал это, чтобы проверить, устал ли мой завиток или нет.

ссылка: https://unix.stackexchange.com/questions/162816/disable-sslv3-in-curl

 [root@prod1 yum.repos.d]# curl -1IsS --ciphers ecdhe_ecdsa_aes_128_sha https://sslspdy.com HTTP/1.1 200 OK Server: nginx centminmod Content-Type: text/html; charset=utf-8 Connection: close Vary: Accept-Encoding Strict-Transport-Security: max-age=31536000; includeSubdomains Date: Mon, 12 Jan 1970 23:00:11 GMT X-Page-Speed: ngx_pagespeed Cache-Control: max-age=0, no-cache 

Как я могу исправить проблему? и загружать файлы с Torrage.com с помощью PHP Curl ?

* Я не могу использовать file_get_contents, поскольку я использую curl_multi для одновременной загрузки.


Обновление 1:

Как полагает Стеффен-Уллрих

 [root@prod1 randoadmin]# curl --ciphers ecdhe_rsa_aes_128_gcm_sha_256 -I https://torrage.com HTTP/1.1 200 OK Server: nginx/1.9.0 Date: Mon, 29 Jun 2015 05:54:17 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Expires: Mon, 26 Jul 1997 05:00:00 GMT Last-Modified: Mon, 29 Jun 2015 05:50:40 GMT Cache-Control: no-store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding, Accept-Encoding Strict-Transport-Security: max-age=31536000 X-Frame-Options: DENY X-Content-Type-Options: nosniff 

но thats with shell, как я могу реализовать его с помощью PHP-curl ?

Обновление 2:

Я использовал модифицированный код и определенный шифр для использования при использовании завитка.

 $ch = curl_init ('https://torrage.com/torrent/640FE84C613C17F663551D218689A64E8AEBEABE.torrent'); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0'); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_SSL_CIPHER_LIST, 'ecdhe_rsa_aes_128_gcm_sha_256'); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true); curl_setopt($ch, CURLOPT_VERBOSE,true); $data = curl_exec($ch); $error = curl_error($ch); curl_close ($ch); echo $error; echo $data ; 

Он отлично работает. Проблема решила много благодаря steffen -ullrich .

Сервер поддерживает только шифры ECC (ECDHE- *). Версия curl построена с помощью библиотеки NSS на Redhat / CentOS. Существует сообщение об ошибке, что Redhat / CentOS переопределяет настройки завитка и отключает шифры ECC по умолчанию . Поскольку, таким образом, нет шифров ECC, предлагаемых клиентом, но только шифры ECC поддерживаются сервером, соединение будет терпеть неудачу.

Вы можете попытаться явно предоставить шифр, т. Е.

 curl --ciphers ecdhe_rsa_aes_128_gcm_sha_256 ... 

Обратите внимание, что обновление OpenSSL не помогло бы, потому что curl не был построен с использованием бэкэнда OpenSSL. Кроме того, это не помогает отключить проверку сертификатов (в любом случае, плохая идея) или изменить корневой центр сертификации, поскольку проблема не связана с проверкой сертификата вообще.

Попытка явно дать шифр с помощью --ciphers ecdhe_ecdsa_aes_128_sha поскольку шифр для решения проблемы идет в правильном направлении, но в этом случае не поможет, поскольку это не один из шифров, поддерживаемых серверами. Сервер поддерживает только различные шифры ECDHE-RSA- *, но не ECDHE-ECDSA- *. См. SSLLabs для получения дополнительной информации.

Если вы работаете в CentOS 7 и получаете эти ошибки при использовании yum, обновление nss nss-util nss-sysinit nss-tools исправит его.

Существует также возможность проверить

на unix (выигрыш в надежде также):

 > curl -v https://www.youtube.com > test.html 

примечание : замените « https://www.youtube.com » на домен с протоколом

Направляя вывод на test.html, мы будем видеть только желаемую информацию на экране

результат:

 * Rebuilt URL to: https://www.youtube.com/ * Hostname was NOT found in DNS cache % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 2404:6800:4005:80d::200e... * Trying 216.58.221.238... 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to www.youtube.com (2404:6800:4005:80d::200e) port 443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs/ * SSLv3, TLS Unknown, Unknown (22): } [data not shown] * SSLv3, TLS handshake, Client hello (1): } [data not shown] * SSLv2, Unknown (22): { [data not shown] * SSLv3, TLS handshake, Server hello (2): { [data not shown] * SSLv2, Unknown (22): { [data not shown] * SSLv3, TLS handshake, CERT (11): { [data not shown] * SSLv2, Unknown (22): { [data not shown] * SSLv3, TLS handshake, Server key exchange (12): { [data not shown] * SSLv2, Unknown (22): { [data not shown] * SSLv3, TLS handshake, Server finished (14): { [data not shown] * SSLv2, Unknown (22): } [data not shown] * SSLv3, TLS handshake, Client key exchange (16): } [data not shown] * SSLv2, Unknown (20): } [data not shown] * SSLv3, TLS change cipher, Client hello (1): } [data not shown] * SSLv2, Unknown (22): } [data not shown] * SSLv3, TLS handshake, Finished (20): } [data not shown] * SSLv2, Unknown (20): { [data not shown] * SSLv3, TLS change cipher, Client hello (1): { [data not shown] * SSLv2, Unknown (22): { [data not shown] * SSLv3, TLS handshake, Finished (20): { [data not shown] * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.google.com * start date: 2017-11-29 09:44:32 GMT * expire date: 2018-02-21 09:37:00 GMT * subjectAltName: www.youtube.com matched * issuer: C=US; O=Google Inc; CN=Google Internet Authority G2 * SSL certificate verify ok. * SSLv2, Unknown (23): } [data not shown] > GET / HTTP/1.1 > User-Agent: curl/7.37.0 > Host: www.youtube.com > Accept: */* > * SSLv2, Unknown (23): { [data not shown] < HTTP/1.1 200 OK < Content-Type: text/html; charset=utf-8 < X-XSS-Protection: 1; mode=block; report=https://www.google.com/appserve/security-bugs/log/youtube < X-Content-Type-Options: nosniff < X-Frame-Options: SAMEORIGIN < Expires: Tue, 27 Apr 1971 19:44:06 EST < Strict-Transport-Security: max-age=31536000 < P3P: CP="This is not a P3P policy! See http://support.google.com/accounts/answer/151657?hl=uk for more info." < Cache-Control: no-cache < Date: Tue, 26 Dec 2017 12:26:21 GMT * Server YouTube Frontend Proxy is not blacklisted < Server: YouTube Frontend Proxy < Set-Cookie: YSC=lkUUrudTNJM; path=/; domain=.youtube.com; httponly < Set-Cookie: PREF=f1=50000000; path=/; domain=.youtube.com; expires=Mon, 27-Aug-2018 00:19:21 GMT < Set-Cookie: VISITOR_INFO1_LIVE=Qo2rlICrfJM; path=/; domain=.youtube.com; expires=Mon, 27-Aug-2018 00:19:21 GMT; httponly < Alt-Svc: hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35" < Accept-Ranges: none < Vary: Accept-Encoding < Transfer-Encoding: chunked < { [data not shown] 100 152 0 152 0 0 114 0 --:--:-- 0:00:01 --:--:-- 114* SSLv2, Unknown (23): { [data not shown] * SSLv2, Unknown (23): { [data not shown] * SSLv2, Unknown (23): { [data not shown] * SSLv2, Unknown (23): .......... many-other-same-not-interesting-rows ......... { [data not shown] * SSLv2, Unknown (23): { [data not shown] 100 425k 0 425k 0 0 113k 0 --:--:-- 0:00:03 --:--:-- 113k * Connection #0 to host www.youtube.com left intact 

Видеть:

* Подключение SSL с использованием TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256

и использовать:

 curl_setopt($ch, CURLOPT_SSL_CIPHER_LIST, 'ECDHE-ECDSA-AES128-GCM-SHA256'); 

Ни один из вышеперечисленных не работал для меня. Я подозревал, что это связано с версией Curl. Curl_version(); вернулся 7.29, а на сервере я установил 7.49.1, что, вероятно, устраняло эти проблемы SSL.

Внезапно я вспомнил о Cloudflare и отключил CDN на всякий случай. Керл начал работать. Затем я переключился на PHP 7, и Curl начал работать даже с Cloudflare CDN. Curl_version(); начал возвращаться 7.49.1.

Я не знаю, как это работает и что именно произошло, но после неустанных часов поиска решения это было тем, что я нашел.