SSL/TLS connections in Sketches using the Oak

[wickwire]

Hi,

After much reading about this issue and not having found a definitive answer, I though I'd post the question:

Does the Oak (v.1.0.6 for example, as it is the latest stable) support SSL/TLS connections?

I tried using this generic sketch from Arduino ESP8266:

ESP8266WiFi\HTTPSRequest.ino

And over serial, just after "connecting to api.github.com" I get an ax_port_malloc error on WifiClientSecure and then a kernel panic - I also built and deployed the sketch with either 80MHz or 160MHz, as I read somewhere that for SSL support, overclocking would be required...

I also checked the SSL fingerprint for github and it's good (in any case, should it fail, the sketch has validation for that)

My ultimate goal is to connect the Oak to an MQTT broker using SSL - similarly to the https example by using the fingerprint function, I have already got the correct fingerprint for the MQTT broker, however I ended up getting this ax_port_malloc error and kernel panic as well, so I decided to try a more "tried and true" sketch like HTTPSRequest.ino

Also, I own a few ESP8266-12 modules and running NodeMCU on those, I'm able to connect to MQTT over SSL.

[PeterF]

I see you opened an issue on GitHub for this a few days ago, so hopefully you'll get an authoritative answer there from Erik soon.

My 2 cents worth though (and also a reply so you don't think you're being ignored :-D), although I haven't used SSL on the Oak, is that the problems you are having is probably something to do with changes in the wifi stack, and how Particle is integrated in the background. Hence, I don't think you'll get it as easily as bumping up the arduino core files (although it would be nice if you can get away with that). There is an long-term goal of merging the Oak core into the ESP8266 Arduino core, but it will be a while before that happens I think.

[wickwire]

Hi PeterF,

Thank you for replying!

I've been at it for a while now and thought I would post my findings here - I guess the Github issue might have been premature/misplaced perhaps, but still while it is there as well, the issue is at least "around" to be cleared.

I've had some ESP8266-01 and ESP8266-12 modules for some months now, I found out about them when I first pledged for the Oak project and while the Oak was being worked on, so I spent some time messing with them while waiting for the Oak.

At the time, I found out about the NodeMCU project and headed in that direction, then MQTT and making stuff work by remote controlling a couple of relays to power on/off a 3D printer I own as well as the LED lighting I also installed in the setup.

The project kind of slowed down once I got a pretty decent stable behaviour from the ESP module (using the 12 variant later on), at which point I should focus on the client/UI part of the project in order to control the relays.

At the time - almost a year ago - I was going for MEAN.js in order to develop the webapp which allow me to control the ESP and I got it to work, along with some webcams to monitor print jobs and everything - but I started lacking the time to move the project forward and since it was just something for personal use, I pretty much left it in working condition and didn't develop it further.

Around May this year I got my Oak batch. At the time I was already sold on my ESP8266 modules (cheaper and doing the job) so I decided to have a look at the Oak as an alternative not just from the OTA perspective but also code development, since I hadn't used Arduino ESP8266 at all with any of the ESP modules I already had and the Oak ended up being an ESP8266 based solution as well.

Add to that the fact that picking up the webapp I had with MEAN.js also meant upgrading several nodeJS/angularJS dependencies which was turning out to be a pain, and I decided to leave v0.1 of my project as it was and just go explore other alternatives.

I found out about Crouton (https://github.com/edfungus/Crouton) to which I started contributing on Github as a replacement for my MEAN.js webapp and picked up one of the ESP8266-12 modules I still had around to replicate the desired behavior of controlling the relays.

Using NodeMCU 0.9 again it was fairly straight forward to come up with a working solution using Crouton's MQTT message/topic architecture and once I had it up and running, I went on to getting SSL to work both in Crouton and on the ESP/NodeMCU.

Back to the Oak. The OTA update solution looks awesome to me and I thought I could really take advantage of it when programming any unit. I later found out that the Arduino ESP8266 project seems to also have some along those lines, however I was very impressed on how things were with the Oak.

So I thought I would work my v0.2 of the project around MQTT, Crouton and the Oak, get a feel for the Arduino development solution instead of NodeMCU and Lua and draw some final conclusions from that.

In order to keep going, connecting the Oak to the CloudMQTT broker I'm using over SSL isn't a blocker, since I still have to get the Oak to talk nicely with Crouton's MQTT message structure - but it would be nice to either have the same functionality I already have with the ESP/NodeMCU approach regarding SSL, or if there's some sort of limitation at the moment, identify it and if it would be something I could help with, fix it.

Comparing the variants I planned on using - ESP/NodeMCU, ESP/Arduino ESP8266, Oak/Acorn - at this point I'm seeing the added value of the Oak project and considering investing more time on this one rather than the other solutions. 

[wickwire]

Still stuck on this issue, updated https://github.com/digistump/OakCore/issues/71 on github with the code I used to test SSL with MQTT with both a generic ESP8266 and the Oak, hopefully someone can shed some light on this.

Meanwhile, the code I needed to get to work with the Oak seems to be running fine now, using MQTT but still not with SSL.