Sometimes get "cURL error 35: Unknown SSL protocol error" when connecting to twitter API

We are trying to link a user to their twitter account letting that user tweet from our site. We get the “cURL error 35” error, but only sometimes. The error directs us to a page that states we should see what is in the error buffer but because we are using socialite, I am unsure how to access that?

I have discovered various cURL options to enable more output, but can’t for the life of me determine how to get socialite to use those? It seems that a vendor package (socialite) is calling a vendor package (guzzle) that is calling curlFactory and I need to tell that last vendor package to output more verbose errors, to some log file somewhere?

Currently using: Laravel 5.4, laravel-socialite 3, socialiteproviders/twitter 3.

The full error:

cURL error 35: Unknown SSL protocol error in connection to api.twitter.com:443 (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

Any assistance would be greatly appreciated.

[EDIT] We have narrowed this issue down to a server side configuration. Running this command:

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

from the server eventually leads to the cURL 35 error. But! We run the same command from inside our vagrant machines and it works 100% of the time.

cURL version is 7.38 on the production server, but is 7.35 inside my vagrant machine.

[UPDATE]

Our Server admin has been dealing with this on and off for the past few days. He reports that he still cannot get this to work. He even downgraded to 7.35, which worked on our previous server to no avail. It seems that the cURL packages in general are not playing nice with Debian 8 and php7.

Does anyone, in the whole wide world, and any ET’s out there spying on us have any idea what is going on?? We are trying to work with Social Networks and it is a huge pain when EVERYONE says use cURL.

[UPDATE 2]

I have found similar posts on the twitter developer forums. From a twitter staff member:

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.

Honestly would have been great if these forum posts showed in google when searching for this error.

While we wait for our server guy to look into TLS, we are making attempts to contact twitter. Will update this post if anything comes of either of these routes.

[UPDATE 3]

This post is officially a month old and no luck! Here are the latest steps our server admin has tried:

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)

We have ran cURL in the CLI with verbose mode on, when it PASSES the output looks like:

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

And when it passes, it looks like:

* 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

The top level stack trace item from Laravel when this fails looks like:

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)

In the stack trace you see:
oauth_signature_method=”HMAC-SHA1″,

And in the CLI success output, you see

CN=DigiCert SHA2

A clue? Our Server Admin has an almost exact clone of our server and he doesn’t have the issue, my local Ubuntu 17 system doesn’t have the issue, and when I ssh into vagrant on my local system, running some scotch-box I don’t have the issue.

I’m pretty sure I mentioned earlier in this post, BUT, there are exact issues on the twitter developer forum pertaining to curl 35 errors, each with no solution. None of which should up when you are searching for this issue on google.

[Jan 26th 2018 Update]

Well, we finally have some concrete information.

We currently have 2 servers. One in a cluster on the east coast, and one in another cluster on the west. Our server admin had a clone of our server, on one of the same clusters we were on and claimed he could not reproduce it. Well, he moved to what ended up being the problematic cluster and sure enough, the curl 35 issue started showing up.

We are currently opening up a dialog with our Host, and we are migrating our server to the cluster that is working.

At this point it seems pretty clear that the points the twitter API was bouncing us to occasionally included a point that didn’t like where the call was coming from. That there wasn’t anything we could change in the code, or the server configuration that would fix this issue.

There are many similar posts in the twitter forums, and they all come to dead ends. Trying to contact twitter leads you to talking to some bot in a chat. So unfortunately I don’t think twitter will make any moves towards fixing this if they have not already.

I will of course update this post if this ends up being the solution, and marking this post as solved.