Иногда возникает ошибка cURL 35: Неизвестная ошибка протокола SSL при подключении к API Twitter

Мы пытаемся связать пользователя с его учетной записью в Твиттере, позволяя этому пользователю твитить с нашего сайта. Мы получаем ошибку «cURL error 35», но только иногда. Ошибка направляет нас на страницу, в которой говорится, что мы должны увидеть, что находится в буфере ошибок, но, поскольку мы используем Socialite, я не знаю, как получить к нему доступ?

Я обнаружил различные параметры cURL, позволяющие увеличить объем вывода, но не могу ли я хоть сколько-нибудь определить, как заставить светскую львицу использовать их? Кажется, что пакет поставщика (socialite) вызывает пакет поставщика (guzzle), который вызывает curlFactory, и мне нужно сообщить этому последнему пакету поставщика, чтобы он выводил более подробные ошибки в какой-то файл журнала?

В настоящее время используются: Laravel 5.4, laravel-socialite 3, socialiteproviders/twitter 3.

Полная ошибка:

Ошибка cURL 35: неизвестная ошибка протокола SSL при подключении к api.twitter.com:443 (см. http://curl.haxx.se/libcurl/c/libcurl-errors.html)

Будем очень благодарны любой помощи.

[EDIT] Мы сузили эту проблему до конфигурации на стороне сервера. Выполнение этой команды:

curl 'https://api.twitter.com/oauth2/token'

с сервера в конечном итоге приводит к ошибке cURL 35. Но! Мы запускаем одну и ту же команду внутри наших бродячих машин, и она работает в 100% случаев.

Версия cURL 7.38 на рабочем сервере, но 7.35 внутри моей бродячей машины.

[ОБНОВИТЬ]

Администрация нашего сервера то и дело сталкивалась с этим в течение последних нескольких дней. Он сообщает, что до сих пор не может заставить это работать. Он даже откатился до 7.35, которая работала на нашем предыдущем сервере безрезультатно. Похоже, что пакеты cURL в целом плохо работают с Debian 8 и php7.

Кто-нибудь во всем мире и любой инопланетянин, шпионящий за нами, знает, что происходит?? Мы пытаемся работать с социальными сетями, и это огромная боль, когда ВСЕ говорят использовать cURL.

[ОБНОВЛЕНИЕ 2]

Я нашел похожие сообщения на форумах разработчиков твиттера. От сотрудника твиттера:

Twitter supports TLS 1.2 - SSLv3 was withdrawn some time ago3. I doubt 
this is the specific reason for the error you are seeing - that's more 
likely to be possibly related to routing between datacenters, I 
imagine. Hard to say what the specific issue here is. 7 out of 10 
failing calls does sound unusually high, but then the timeouts are a 
bit surprising too.

Честно говоря, было бы здорово, если бы эти сообщения на форуме отображались в Google при поиске этой ошибки.

Пока мы ждем, пока наш серверный парень проверит TLS, мы пытаемся связаться с Twitter. Обновлю этот пост, если что-то случится с любым из этих маршрутов.

[ОБНОВЛЕНИЕ 3]

Этому посту официально месяц, и не повезло! Вот последние шаги, которые предпринял наш администратор сервера:

Updated all root certs in our server

Added twitter specific digi-cert (downloaded and added as files, made the SSL system look for it)

confirmed our cipher match twitters requested ciphers

Scanned our server with ssllabs.com (scans entire system and outputs details about cypers and ssl cert.) - We passed no issues found

CLI output says SHA2, the error in the Laravel stack trace says SHA1

DNS Caching issue, added DNS caching to server (there wasn't any before)

way to tell curl what cert to use, manually told it to use twitters cert, no clear problem reported, wasn't getting expected responses though.

insured certs are not expired.

3 common SSL issues with cURL:  destination does not like cypher, does not like protocol, private key has expired.

Sever admin went through all twitter dev info.  (https://developer.twitter.com/en/docs/basics/authentication/guides/tls)

Мы запустили cURL в CLI с включенным подробным режимом, когда он ПРОЙДЕТ, вывод выглядит так:

curl -v 'https://api.twitter.com/oauth2/token'

* Hostname was NOT found in DNS cache
*   Trying 104.244.42.130...
* Connected to api.twitter.com (104.244.42.130) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to api.twitter.com:443 
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to api.twitter.com:443

И когда он проходит, это выглядит так:

* Hostname was NOT found in DNS cache
*   Trying 104.244.42.2...
* Connected to api.twitter.com (104.244.42.2) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
*    subject: C=US; ST=California; L=San Francisco; O=Twitter, Inc.; OU=Twitter Security; CN=api.twitter.com
*    start date: 2016-06-29 00:00:00 GMT
*    expire date: 2019-09-19 12:00:00 GMT
*    subjectAltName: api.twitter.com matched
*    issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
*    SSL certificate verify ok.
> GET /oauth2/token HTTP/1.1
> User-Agent: curl/7.38.0
> Host: api.twitter.com
> Accept: */*
> 
< HTTP/1.1 400 Bad Request
< allow: POST
< cache-control: no-cache
< content-length: 0
< content-security-policy: default-src 'none'; connect-src 'self'; font-src https://abs.twimg.com https://abs-0.twimg.com data:; frame-src 'self' twitter:; img-src https://abs.twimg.com https://*.twimg.com https://pbs.twimg.com data:; media-src 'none'; object-src 'none'; script-src https://abs.twimg.com https://abs-0.twimg.com https://twitter.com https://mobile.twitter.com; style-src https://abs.twimg.com https://abs-0.twimg.com; report-uri https://twitter.com/i/csp_report?a=NVQWGYLXFVWG6Z3JNY%3D%3D%3D%3D%3D%3D&ro=false;
< date: Thu, 21 Dec 2017 17:40:24 GMT
* Server tsa_b is not blacklisted
< server: tsa_b
< set-cookie: personalization_id="v1_Txp6AuuonT7REMqCB7vkzg=="; Expires=Sat, 21 Dec 2019 17:40:24 UTC; Path=/; Domain=.twitter.com
< set-cookie: guest_id=v1%3A151387802465523279; Expires=Sat, 21 Dec 2019 17:40:24 UTC; Path=/; Domain=.twitter.com
< status: 400 Bad Request
< strict-transport-security: max-age=631138519
< x-connection-hash: a5a497e59a35ec28ab7fae706c69598b
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-response-time: 5
< x-transaction: 006fdc83002993a0
< x-xss-protection: 1; mode=block
< 
* Connection #0 to host api.twitter.com left intact

Элемент трассировки стека верхнего уровня от Laravel, когда это не удается, выглядит так:

TwitterOAuthException
Unknown SSL protocol error in connection to api.twitter.com:443

in TwitterOAuth.php (line 440)
at TwitterOAuth->request('https://api.twitter.com/oauth/access_token', 
'POST', 'Authorization: OAuth oauth_version="1.0", 
oauth_nonce="a93b697784a0b2d3ceaaf203d4d9aff8", 
oauth_timestamp="1513875885", 
oauth_consumer_key="T79KMPJi0Wx64fbmwoa606gut", 
oauth_verifier="5ZKcm8A2VN6muXFwOBOdTaFRGyPnA9bi", 
oauth_signature_method="HMAC-SHA1", 
oauth_signature="Q4DkMhNz3eImT9T%2BbbDxgVZyRno%3D"', array())
in TwitterOAuth.php (line 357)

В трассировке стека вы видите: oauth_signature_method="HMAC-SHA1",

И в успешном выводе CLI вы видите

CN=DigiCert SHA2

Ключ? У нашего администратора сервера есть почти точный клон нашего сервера, и у него нет проблемы, у моей локальной системы Ubuntu 17 нет проблемы, и когда я ssh вхожу в бродягу в моей локальной системе, запускаю какой-то скотч-бокс, я не нет проблемы.

Я почти уверен, что упоминал ранее в этом посте, НО на форуме разработчиков твиттера есть конкретные проблемы, связанные с ошибкой curl 35, каждая из которых не имеет решения. Ни один из них не должен появляться, когда вы ищете эту проблему в Google.

[Обновление от 26 января 2018 г.]

Наконец-то у нас появилась конкретная информация.

Сейчас у нас 2 сервера. Один в кластере на восточном побережье и один в другом кластере на западе. У администратора нашего сервера был клон нашего сервера в одном из тех же кластеров, в котором мы находились, и он утверждал, что не может его воспроизвести. Что ж, он перешел к тому, что в конечном итоге стало проблемным кластером, и, конечно же, проблема с curl 35 начала проявляться.

В настоящее время мы открываем диалог с нашим хостом и переносим наш сервер в работающий кластер.

На данный момент кажется довольно ясным, что точки, которые нам иногда подбрасывал twitter API, включали точку, которой не нравилось, откуда исходит вызов. Что мы ничего не могли изменить в коде или конфигурации сервера, что могло бы решить эту проблему.

Подобных сообщений на форумах твиттера много, и все они заходят в тупик. Попытка связаться с твиттером приводит к разговору с каким-то ботом в чате. Так что, к сожалению, я не думаю, что твиттер предпримет какие-либо шаги по исправлению этого, если они еще этого не сделали.

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