till today my facebook api under PHP worked well.
I did not change anything. But from today on i get the following error:
facebook failed: "error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
/usr/bin/php /var/www/pas/www/cronjobs/cronjob.channelsActions.php
Has anybody got an idea, how i could solve that error?
It's because of the POODLE: SSLv3.0 vulnerability (CVE-2014-3566).
After this vulnerability was announced today, many services disabled SSLv3 completely for the time being, including Facebook, and it happens that Facebook uses SSLv3 in their PHP SDK.
I am not sure if you have the same Facebook PHP SDK version as me, but if you have the base_facebook.php file, find the line:
$opts[CURLOPT_SSLVERSION] = 3;
And change it to a value that does not allow SSLv3 any longer (find all constants listed):
$opts[CURLOPT_SSLVERSION] = CURL_SSLVERSION_DEFAULT;
or:
$opts[CURLOPT_SSLVERSION] = CURL_SSLVERSION_TLSv1;
or:
$opts[CURLOPT_SSLVERSION] = CURL_SSLVERSION_TLSv1_0;
This way the Facebook API calls will use TLSv1.0 instead of SSLv3.
In my case this line is in the "makeRequest($url, $params, $ch=null)" function at line 963, but depending on the version of the PHP SDK you're using it may differ.
Facebook made the decision to drop support for SSL 3.0 across Facebook properties, including the Facebook Platform API and the Real-Time Updates API, after a serious vulnerability in the protocol was revealed publicly on October 14, 2014 (http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html). This change helps protect people’s information.
Older versions of our PHP SDK (Facebook PHP SDK 3.1.1 and older) that used SSL 3.0 will no longer work. All developers should upgrade to a version of our SDK that uses TLS - Facebook SDK 3.2.3 or greater. We recommend that developers upgrade to our latest SDK, SDK 4.0.0.
PHP SDK 3.2.3: https://developers.facebook.com/docs/reference/php/3.2.3
PHP SDK 4.0.0: https://developers.facebook.com/docs/reference/php/4.0.0
Dev Doc: https://developers.facebook.com/docs/apps/changelog#disable-ssl-v30F
My server has not upgraded to PHP 5.5 or 5.6, the version which includes CURL_SSLVERSION_TLSv1_0.
The fix, with older PHP versions, is to comment out the line:
$opts[CURLOPT_SSLVERSION$
Related
Thanks in advance for the help.
I received an email from Google Platform notifying me of the following
Our records show that you own projects with App Engine applications or Cloud Functions that are still calling the pre-GA v0.1 and v1beta1 endpoints of the App Engine and Cloud Functions metadata server. After September 30, 2020, requests to the v0.1 and v1beta1 endpoints will no longer be supported, and may return HTTP 404 NOT FOUND responses. As a result, before September 30, 2020, you will need to update your requests to use the v1 endpoint, which was available starting in 2016.
After investigation, it turns out I'm using these endpoints indirectly as a result of "using an old Google client library which is making requests to the legacy endpoints".
I believe I've followed the instructions to upgrade all the old Google client libraries to address this problem, but I'm not positive. How can I confirm that my application is no longer using these legacy endpoints indirectly? I don't want my application to stop working on September 30th, but I have no way to know if I've successfully migrated.
I am getting below error when accessing the stripe API using ColdFusion.
Stripe no longer supports API requests made with TLS 1.0. Please initiate HTTPS connections with TLS 1.2 or later.'
This is related JRE issue in coldfusion. Most of the payment gateways doesn't support TLS 1.0. So, we need to update the Java JRE in our coldfusion server.
How to fix:
Upgrade to Java 8.
Login to ColdFusion Administrator > Java JVM
Change the path of the JVM to the new installed path (defaults to: C:\Program Files\Java\jre1.8.0_102 in windows. )
Restart ColdFusion Server - Service.
Re-Test.. it should work now..
Please bear with me. I'm no SSL encrpytion expert. I just want to make connections to a server, using their API. I am unable to. When I use this api as indicated in the documentation, the following error occurs:
[Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
This API seems to be hosted on an AWS server somewhere, and the support person for it has referred me to this AWS document with the added information that their server uses TLSv1_2016. I'm not sure that that's correct, but that's what I was told.
This version of TLS is not supported by the OpenSSL that ships with Ubuntu 14.0.4 (openssl v1.0.1f). Version 1.2 IS supported. I upgrade my system on a regular basis, and it doesn't seem that there is any approved Ubuntu release that supports this protocol. I've been advised to upgrade, but it's not clear to what.
This is all Greek to me. Can someone tell me what upgrade I might be able to do my system to solve this?
UPDATE problem persists after installing Ubuntu-18.04, which comes with openssl 1.1.0g.
Answer mostly from comments.
The problem is apparently that the server, like many SSL/TLS servers today especially those handling multiple domains like Cloudfront, requires the SNI (Server Name Indication) extension in SSL/TLS. This was (and easily is) checked with openssl s_client which (unlike most programs) has an option that controls whether to send SNI.
You didn't previously say that this code is Python. It is Python that links to and invokes OpenSSL. (The OS is not involved in SSL/TLS, only in the lower-level TCP/IP protocols.) According to http://docs.python-requests.org/en/master/community/faq/ (at the bottom)
Python3 and Python 2.7.9+ include native support for SNI in their SSL modules. For information on using SNI with Requests on Python < 2.7.9 refer to this Stack Overflow answer.
linking to using requests with TLS doesn't give SNI support which has several answers that appear to consist mostly of updating various things (and I am not in a position to test even if you gave details of your Python and Requests which you didn't).
I have a web service which i need to access through https. We have a workbout pro 4 with win ce 6.0 running on it. When we were developing our app we had tested it through http. wihtout any problem. When we went live and needed access to https based server we have received the error stated on subject field under VS 2008 Smart Device Project. On the device we receive an error "could not display..." . We have tried to import the standard certificate issued by global si. We still have no success accessing the web service. We can acces the web service on phone, tablet, pc but not with Pro 4:). It would be kind if anyone can share his/her experience with https based web service access or can guide us to over come our problem.
Secure connection is not implemented on CE fully. Something to do with cert management. Here is what i am considering for my project and it gives a little more info what the issue is. http://labs.rebex.net/HTTPS
Here is some quotes from the site in case its down or something.
.NET Compact Framework does not support TLS 1.2, 1.1, SNI or SHA-2
based certificates.
.NET CF's HttpWebRequest is outdated. It does not support TLS 1.2 or
1.1, it doesn't support Server Name Identification (SNI), and it does not support SHA-2 in X509 certificates. It also suffers from several
authentication-related bugs with no known workaround. This makes it
unusable in a growing number of scenarios, and Microsoft will never
fix this because it no longer cares about these legacy platforms.
Fortunately, it's now possible to work around these shortcomings using
a beta version of Rebex HTTPS library. It features a HttpWebRequest
replacement object for .NET Compact Framework that plugs into the
existing .NET CF WebRequest API and provides the features the default
HTTP/HTTPS provider lacks. Most importantly, it adds support for TLS
1.2, TLS 1.1, SNI and SHA-2, it works even on old devices based on Windows CE 5.0 and it makes it simple to add TLS 1.2 support to
existing SOAP web service clients.
We had a similar issue on CE 7.0.
HTTPS connections using SHA1 certificates would work, however ones with SHA2 certificates would return the error
Could not establish trust relationship with remote server
If possible, try testing your code against a host that uses a SHA1 certificate to see if the issue might be related to missing SHA2 support in CE 6.0.
I should mention that we never formally approached Microsoft to get confirmation on whether SHA2 was supported or not in CE 6.0/7.0, it was just our conclusion after numerous tests that it wasn't.
There appears to be something wrong with the Google Admin SDK Channel Stop endpoint affecting all the language libraries. At least Node, Ruby and PHP.
I'm having the issue with "directory"…
It should be: https://www.googleapis.com/admin/directory/v1/channels/stop (404)
This works: https://www.googleapis.com/admin/directory_v1/channels/stop
This is generated: https://www.googleapis.com/admin/directory/v1//admin/directory_v1/channels/stop (404)
Someone else if having the problem with "reports"…
Stop watching google push notifications
Ruby library issue…
https://github.com/google/google-api-ruby-client/issues/251
Node client: https://github.com/google/google-api-nodejs-client/blob/1c0407e56e12a05ec8fa7679df19bdd2436969f5/apis/admin/directory_v1.js
Ruby client: https://github.com/google/google-api-ruby-client/blob/41d9d66e8190c8ced331fcc5e156c5123941d713/generated/google/apis/admin_directory_v1/service.rb
PHP client: https://github.com/google/google-api-php-client/blob/da350e19472f5711703a68a77c6df8d1f5ed4fd4/src/Google/Service/Directory.php
Yes, this appears to be a bug in our API serving system that only affects the Admin SDK Directory and Reports APIs. I'm working with the team to find a resolution.