PhantomJS will fail to load many HTTPS urls by default, but you can get many of them to work by adding some command line flags like --ignore-ssl-errors=true and --ssl-protocol=any. However I'm finding some sites that fail even when these flags are enabled; for example try the following code snippet:
var page = require('webpage').create();
page.onResourceError = function(e){
console.log("Page resource failed to load. Reason: "+e.errorString);
}
page.open("https://www.bluehaven.com/pool-remodeling/", function(status){
console.log("Load status: "+status);
});
When I run this script with those two flags enabled, I get the following output:
$ phantomjs --ignore-ssl-errors=true --ssl-protocol=any lib/test_phantom.js
Page resource failed to load. Reason: SSL handshake failed
Load status: fail
I've googled quite a bit and the discussions around PhantomJS and SSL failures all recommend using the above two command flags, or suggest that this is due to a bug in PhantomJS that isn't likely to get fixed anytime soon.
Does anyone here on SO have different ideas on how I can get PhantomJS to load the above URL (and any other sites where the same HTTPS errors occur)? My plan B is to try out SlimerJS as I understand it doesn't share this SSL error, but that will involve some risk and I'd rather not do it unless absolutely needed.
The program works fine on Ubuntu 14.04 with phantomjs 1.9.0.
Since the server only supports ECDHE ciphers I would assume that you are using an old version of OpenSSL with no support for these ciphers on your system.
Related
The issue:
Python 3.10 increased the default security settings of the TLS stack. Awesome. I have a legacy application running something that theses settings do not like. I don't know what exactly. How do tweak these settings to let my request through?
The story:
I'm writing a small script to extract some information from a Jazz RTC instance running on premise. It clearly has a... problematic ssl certificate. Nothing that a "verify=False" shouldn't fix. Well, it does not.
When I run the following code in python 3.10...
if __name__ == '__main__':
headers = {'Content-Type': 'application/x-www-form-urlencoded'}
data = {
'j_username': username,
'j_password': password
}
result = requests.post(url, data=data, headers=headers, verify=False).json
print(result)
... i get this handshake error.
requests.exceptions.SSLError: HTTPSConnectionPool(host='...', port=...): Max retries exceeded with url: /ccm/authenticated/j_security_check (Caused by SSLError(SSLError(1, '[SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:997)'))
BUT, it works without a problem on Python 3.9. Looking around for an answer, I found out about the heightened security defaults added to python 3.10, like this question... but nothing on how to tweak them to make this work with my requests.
The details:
This is what the browser developer tools report
As usual, this is a very limited enterprise environment. I can't do
much. No admin privileges.
The department responsible for that host, as expected, says it can't be fixed, giving some shallow excuses.
"If it works on 3.9, why not use it?" - Well, several reasons. The major one being 3.10 is the version accepted for use in the company environment. If they even find out I sneaked in a conda 3.9 venv to test stuff, I'll get a mean lecture.
Any help is appreciated! o/
#PatrickMevzek 's comment led me to other queries and this question.
Which showed me how to change the used ciphers AND security level. The following snippet from #bgoeman worked for my environment:
import urllib3
requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS = 'ALL:#SECLEVEL=1'
Obviously, in general THIS SHOULD NOT BE USED. This will allow for man-in-the-middle attacks and other nasty things. Be careful and mindful when changing these settings.
I'm having problems enabling TLS in Elasticsearch 7.1.1 running on Windows 7.
I have a single node with certificates created as
elasticsearch-certutil ca
elasticsearch-certutil cert --ca elastic-stack-ca.p12
The elasticsearch.yml file has the following settings
node.name: node1
discovery.type: single-node
xpack.security.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: 'C:\elasticsearch-7.1.1\config\certs\elastic-certificates.p12'
xpack.security.transport.ssl.truststore.path: 'C:\elasticsearch-7.1.1\config\certs\elastic-certificates.p12'
This works fine but when I add the below
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: 'C:\elasticsearch-7.1.1\config\certs\elastic-certificates.p12'
xpack.security.http.ssl.truststore.path: 'C:\elasticsearch-7.1.1\config\certs\elastic-certificates.p12'
and start up elasticsearch I see the following error
[2019-06-25T07:34:19,659][WARN ][o.e.h.AbstractHttpServerTransport]
[node1] caught exception while handling client http traffic, closing
connection Netty4HttpChannel{localAddress=0.0.0.0/0.0.0.0:9200,
remoteAddress=/127.0.0.1:6757}
io.netty.handler.codec.DecoderException:
io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record:
This is repeated every 10-15 seconds.
https is enabled though and I can access the node using https://localhost:9200
I don't know why I receive the above error though as nothing else is running and accessing elasticsearch.
Any help would be much appreciated.
Thanks heaps
It was pointed out to me, on the elastic forum, that the above is a warning and not an error. I still couldn't understand what was causing it as I wasn't running any service or anything else that could be causing it but eventually found something called heartbeat that was running. This was obviously setup in an earlier version/previous installation of Kibana and this was still running, making a call using http and thus causing the above error (this is used for creating dummy data to use for/by to demo Kibana).
I came across this problem too. And IF you have previously installed Elastic Search then high chance you got some residual indices with "red" status, which makes the process of enabling TLS unsuccessful.
Try this command to verify your indices and their statuses
curl -XGET https://localhost:9200/_cat/indices
then delete those with red status.
SCENARIO
My rails application has a page that tooks a considerable amount of time to load. In order to increase our users' experience we decided to (firstly) only show a loader with an indication of how much of processing has been completed (instead of let them waiting blindly the response from server). That indication is shown with the helping of rails 5 ActionCable tool and once processing is completed the content is shown.
Obviously, in order to make it possible, a subscription to a channel is made as soon as page loads so that server can report the processing status and the final result.
GOAL
Generate a PDF from that page so that we can email users with that file attached.
PROBLEM
wkhtmltopdf is being used to generated the PDF but when accessing the page it isn't being able to handshake with ActionCable's websocket.
The following message is raised:
Warning: http://localhost:3000:0 Error during WebSocket handshake: protocol mismatch: actioncable-v1-json,actioncable-unsupported !=
The above message intrigued me because it's like the protocol it'd accept for handshaking should be... blank?!! :O (notice the right hand of the operator != - there is nothing there!).
Under the hood I know wkhtmltopdf uses qt webkit browser. I suppose the solution for this problem would be related to some configuration within webkit (but I don't know how - neither where - to set it from wkhtmltopdf).
System Stack
Linux (Ubuntu) 16.04
rails 5 + ActionCable
wkhtmltopdf 0.12.3 (with patched qt)
I have implemented FCM for web using fcm documentation.
Everything'll be fine if I set url like : 'http://xxx' I have no error.
But when I set url : 'https://xxx..', I get error:
"Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script."
code: "messaging/failed-serviceworker-registration"
"Messaging: We are unable to register the default service worker. Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script. (messaging/failed-serviceworker-registration)."
Can anyone show me how to fix this error?
This is a general problem when wanting to test service workers in a local development environment without proper SSL certificates. It is not specific to Firebase Messaging but pertains to Service Workers in general.
Here is the solution I found when using Google Chrome: Testing Service workers locally with self-signed certificates
Unfortunately, I don't know yet how to circument the issue with other browsers, but probably there must be similar ways.
For Chrome, you need to start a new instance of Chrome, with some flags telling it to ignore SSL certificate errors for your local origin:
In Linux (and maybe Mac):
google-chrome --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://127.0.0.1 --user-data-dir=/tmp/foo
The https://127.0.0.1 here is the location where your app (and service worker) is hosted locally. You might need to adjust this to use the appropriate port, if serving on a different port than the standard HTTPS port 443, e.g. https://127.0.0.1:3000, when serving your app over HTTPS on port 3000.
The --user-data-dir=/tmp/foo is necessary to start a new instance, with a new user profile, if another instance of Chrome is already running.
In Windows (might vary, depending on where your chrome.exe is):
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:1123
Again, you might have to adjust the port.
Easier method that worked for me:
Just paste chrome://flags/#allow-insecure-localhost in your chrome browser, and Enable the setting that says something like "Allow invalid certificates for resources loaded from localhost."
When I try to ping Solr, I get a failure only in IE.
if (!$solr->ping()) {
echo 'service not available';
}
The connection is identical when using var_dump in both IE and other browsers. It's running on the standard Solr port, localhost, and the path is correct. Unsure how a different browser would affect a connection to Solr.
Solr Specification Version: 1.4.1.2011.09.12.09.25.21
Oddly enough, it seems that allow_url_fopen not being enabled was the root cause of this issue. Unrelated, seemingly, so I'd assume the issue was with the WordPress plugin used. I'd have to guess some odd implementation made this fail silently and cause issues only in IE.
Probably too specific to my case to help others, but thought I'd share.