HTTPS & TLS support


#21

will try!


#22

@mterrill

Just wondering if you’ve checked out the Real Time Logic library?
https://realtimelogic.com/products/sharkssl/

I’m getting pretty close to buying a license (the price they gave me is not magnitudes larger than your bounty offer above). Can you think of any reason why this wouldn’t work on top of the photon/electron TCP stack?


#23

Hi there, apologies for delay.

The TLS tcpclient library did work, we were able to connect it to the AWS HTTPS API gateway. The downside is that every single publish it incurs the overhead of setting up a HTTPS TCP based session. So it works, but its pretty ugly! The real solution is TLS MQTT which is pretty much the best pub/sub protocol out there and is extremely lightweight.

Point to point comms you could use CoAP, which is what I believe the particle actually uses. From arms length inspection it has some interesting peculiarities as the docu suggests it was designed for client to server publishing and client subscription to hear from the server is a bit of a hack.

On the other hand, MQTT was designed ground up for subscription (of multiple parties if you like) and its what AWS has chosen as a protocol choice for their IOT as a service platform.

However, the photon doesn’t have the memory to deal with those libraries, and likely doesn’t have the cpu grunt if you’re intending on doing some sensor work/calculations, some form of local webserver API with the customer smartphone or sensors and running MQTT etc. Unless it’s refreshed then ESP32 seems the best forward direction, IBM Watson folk published some example code running MQTT to their cloud platform on ESP32. Neat.


#24

MatrixSSL sounds like what everyone needs here; ultra-high speed, quality and feature set, designed specifically for low-power devices in the first place. No bloat, no external mess needed.


#25

Apart from the vulnerabilities flagged in 10/2016 & 6/2017


#26

Hello @mterrill -

Your post suggests that TLSTCPCLIENT worked with the AWS HTTPS API gateway… can you cite any examples of this? I’ve got an API standing up and I’ve yet to connect with any success. I was trying the glowfish client <httpsclient-particle.h> to no avail. (httpsclient-particle.h)

Thanks in advance!


#27

Hi, apologies for slow reply. It did work, the trick is it sets up the full https connection each time it posts. That’s a lot of data / power if you’re running a constrained system.
I was looking into it because webhooks had a rough patch of performance/reliability. They’re much better now, can’t fault it, its stable! So the much easier way of doing things is to use AWS lambda or Google cloud functions as your webhook endpoint.


#28

No worries @mterrill -

There’s a working port of the WolfSSL client that has been repo’d on Github and the Particle libraries. I’ve got my Photon successfully running with AWS IoT on version 0.0.1 , and the latest version 0.0.2 also supports direct connect to AWS API. @cermak has made major inroads and has documented has summarized his exploits here:


#29

@jimini I had a go at getting the WolfSSL client up and running with AWS IoT. There’s quite a lot missing to get this working in the latest public version? I’m very curious to know what additions you did to get AWS communication up and running.


#30

Lambda only requires the AWS CA certificate. IoT requires three certs one being the CA and the other two for the thing.

There are some internidate steps for setup. Working on a hackster.io post to go with the example code.


#31

It works straight away for me and is operationally on-premise. There are a few caveats which may be snag points, but they’re all outside of the TLS client port itself:

  • Spinning up the AWS IoT backend and cloud facing endpoint including MQTT topics and rules
  • Accurately embedding your certs, authentication key and endpoint URL for your Photon build
  • Building your project locally (no Web IDE)

There’s a number of .ino examples on the GitHub repo.

I’ve yet to retry a direct API/Lambda access, but I have no doubt that’s ready to go should I need to operate outside of the IoT sphere of 512 bytes per message.