SSL Validation Issue (Error -40) to deny.io
Opened this issue · 15 comments
Originally reported on the forums, sending a request to deny.io throws an error on Tessel but completes in Node. Code and Error are below.
https.js
var https = require('https');
var options = {
hostname: 'deny.io',
port: 443,
path: '/',
method: 'GET'
};
var req = https.request(options, function(res) {
console.log("statusCode: ", res.statusCode);
console.log("headers: ", res.headers);
res.on('data', function(d) {
process.stdout.write(d);
});
});
req.end();
req.on('error', function(e) {
console.error(e);
});Response:
➜ sandbox tessel run https.js
TESSEL! Connected to TM-00-04-f000da30-00584f36-4aa02586.
INFO Bundling directory /Users/Jon/Work/technical/sandbox (~2.75 MB)
INFO Deploying bundle (3.53 MB)...
INFO Running script...
Error: Could not validate SSL request (error -40)
stack traceback:
[T]:src/colony/modules/dns.js:30: in function <[T]:src/colony/modules/dns.js:17>
I have a similar issue with the https module when using it with tessel.
My code is practically identical to what was posted above. Only that for my server, the error code is "-256":
Error: Could not validate SSL request (error -256)
stack traceback:
[T]:src/colony/modules/dns.js:26: in function <[T]:src/colony/modules/dns.js:17>
When running this directly in nodejs, it works just fine.
I am seeing a similar error when making https PUT calls to myjson.com after several iterations (~18) once a minute apart.
Error: Could not validate SSL request (error -256)
stack traceback:
[T]:src/colony/modules/dns.js:30: in function <[T]:src/colony/modules/dns.js:17>
Happening for me as well trying to POST using https library to Parse:
Error: Could not validate SSL request (error -178)
at _new (src/colony/lua/colony-init.lua:493)
at createSession ([T]:src/colony/modules/net.js:274)
at <anonymous> ([T]:src/colony/modules/net.js:249)
Based on a short investigation, it looks like these errors are happening because the SSL library Tessel uses (axtls) may be too old to support newer forms of cryptography.
@johnnyman727 - I am running into this issue as well with my Tessel board. Do you folks have a plan to upgrade the SSL library ?
@amitm94305, currently, we don't have plans to upgrade the SSL library but we will be releasing a proxy server solution soon which should get around this issue.
@johnnyman727 - Any update on when you will have a solution to this issue ?
@amitm94305 Unfortunately, I don't have a definitive answer of when we'll have the proxy server readily available. If you'd like to do some beta testing, you can check out this branch and give it a try. We aren't fully supporting the proxy server at the moment but it should be more or less functional.
Wait... Honestly? You don't have plans to upgrade the SSL library? Isn't one of the major advantages of the Tessel that it has good WiFi support? And with the SSL Everywhere movement, and old protocols quickly being deprecated, that means I really can't do any useful calls with the Tessel?
A proxy server isn't really a solution. It will still have to be using an old SSL method, which means all of the data sent from my Tessel is insecure...
Is there a good reason not to update the SSL library? It seems to me that you're essentially removing the capability for any internet-dependent projects.
@josephwegner Wifi has never worked as well on Tessel as we would have liked, mainly due to our poor choice of using the CC3000 wifi chip. There are multiple issues with the chip's firmware that I won't go into here. TI, the chip manufacturer, has also stopped recommending the CC3000 for any new designs, and there hasn't been a firmware update fixing any of the issues we've reported.
At this point we're focusing our efforts on Tessel 2, which was designed with a chip used in wifi routers and doesn't have any of the issues that Tessel 1 does with wifi support.
There were plans to replace axTLS with PolarSSL / MbedTLS when it was announced that it would be relicensed from GPL to Apache, but that version is still not available.
SSL is one of many reasons Tessel 2 runs Linux, with standard Node and OpenSSL.
This happens when calling an AWS service, which seems like a pretty big deal. :/
@felixalias it's a big enough deal that we built Tessel 2 :)
@johnnyman727 which I ordered and am a customer of, but I'm worried about what happens when something like this breaks there as well. My Tessel 1 is now firmly embedded in a physical device that I can't really rip it out of, so as the APIs I was using go HTTPS-only, my device is now left dead. I'm not saying you have to support old versions forever, but the 2 hasn't even shipped yet and it seems like support for the 1 is done.
Worse, I'd been wanting to do a larger-scale deployments of Tessels, but since the 2 is still not yet GA and the 1 isn't being sold, I'm being forced to find alternate boards. I hate that. I love the Tessel, and I don't think other dev boards come close to the experience it offers. However, if it can't meet my requirement of needing to talk to modern APIs, I'm kind of out of options.
@johnnyman727 which I ordered and am a customer of, but I'm worried about what happens when something like this breaks there as well.
I'm glad you ordered it! Something like this won't break on Tessel 2 because it's running regular Node.js which is a project with much more developer resources at its disposal. With Tessel 1, we were forced to find a tiny library in C (because it was a microcontroller) with MIT/APACHE 2.0 licensing because we are an open source project. There was only one SSL library that fit that bill at it wasn't supported well (hence this problem on T1). In general, because the Tessel 2 takes advantage of existing, healthy open source projects it's unlikely to hit a problem that is completely Tessel-specific without any developers willing to fix them.
I'm not saying you have to support old versions forever, but the 2 hasn't even shipped yet and it seems like support for the 1 is done.
I understand where you're coming from here but we don't have enough contributors to work on two projects at once. After spending over a year trying to get Tessel 1 to work as intended, we decided that we had an architectural problem on our hands and spending time trying to fix individual issues was a black hole. Building Tessel 2 was a far better solution and we would not be able to do that without pooling our resources.
Worse, I'd been wanting to do a larger-scale deployments of Tessels, but since the 2 is still not yet GA and the 1 isn't being sold, I'm being forced to find alternate boards. I hate that.
I hate that too and we never intended it to happen that way. There were a lot of unexpected issues that we had minimal control over like customs delays and internet-availability issues at our factory in China that widened the gap between cancellation of T1 and release of T2. Fortunately, most international T2 orders have been sent out and most US orders will be sent out next week (assuming our DHL truck doesn't drive off into the abyss).