The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
This would require SSL support, which is not available for the smaller NETMF boards like Netduino (NETMF supports OpenSSL, but this is about an order of magnitude too large for single-chip microcontrollers).
The best solution could be using MQTT client on Netduino like my M2Mqtt library (http://m2mqtt.codeplex.com) but for now Service Bus doesn't support MQTT. I hope it will support MQTT very soon ! :-)
I did a Netduino -> Azure Service Bus project, but due to the lack of SSL I ended up proxying the connection with a WebAPI that I spun up on Azure Web Sites. So, unfortunately I was stuck doing message-level encryption for the trip to the web service. Once the web service picked it up, it then async added the message to Service Bus. Worked out nice, just needed that broker/proxy service to work as the middleman.
Wasn't thrilled about message-level encryption, really would love to see /some/ minimal SSL support on the Netduino at some point. At least enough for basic client interactions (maybe even with a reduced version support, ie TLS only)
Hi Chad,
You are right....we need SSL for communication in the IoT world from Netduino. All the protocols use it for encryption (MQTT, AMQP,...).
Good exercise to connect Netduino to Web API but you haven't connected Netduino to Service Bus because you can't due to lack on SSL. However, good work !
Wasn't thrilled about message-level encryption, really would love to see /some/ minimal SSL support on the Netduino at some point. At least enough for basic client interactions (maybe even with a reduced version support, ie TLS only)
I'd like to see a good (i.e., not OpenSSL) and light-weight (i.e., not OpenSSL) open source TLS implementation for NETMF boards like the Netduino as well. Maybe a future revision of TLS will allow for lighter-weight algorithms, as Google proposed here:
Since our latest Mountaineer firmware release, we support the NaCl primitives, which include Poly1305. Adding ChaCha20 wouldn't be that hard. As it is, our library at least supports efficient message-level encryption, which is sometimes necessary anyway if end-to-end security is desired. Our NaCl implementation will later become open source, once the beta cycle for the firmware is over:
I'd like to see a good (i.e., not OpenSSL) and light-weight (i.e., not OpenSSL) open source TLS implementation for NETMF boards like the Netduino as well.
No, unfortunately not. They seem like good candidates. PolarSSL in particular appears to have a good reputation regarding code readability, systematic testing etc. And I´ve just seen that they have a FOSS license exception that mentions Apache 2.0 as a compatible license, so this would be ok for NETMF, at least for open source projects. I don´t know what commercial conditions it has. Nor do I know how CyaSSL compares.
Even if code quality is good, license terms are ok both for open source and commercial projects, and footprint in terms of RAM and Flash is small, speed would remain an important question for me. I know of SSL stacks (on ARM7 cores, though) that take two minutes to open a connection...
If anyone has solid information regarding these two stacks, this would be extremely interesting. (Maybe this is premature, but I´ve lost interest in MatrixSSL after reading some rather negative remarks regarding its code readability.)
I am also working on a project where i have to put a message on a Azure Service Bus Queue. I think i am almost there. The only problem i have is that i need to get a token from Azure accesscontrol over https. I have the code working using HttpWebRequest on a normal C# code. The code is ported to microframework and compiles. But when i do the webrequest i always get a System.NotSupportedException. Is this because of the lack of SSL Support on netduino, are there any workarounds ?
If not, then it's simple not possible even with the REST Azure API to connect from netduino.
there isn't a workaround for it. The lack of SSL support on Netduino already blocked me to develop a Service Bus client for Netduino using HTTP REST interface.
Well the workaround could be to write a cloud sevice webapi that receives a POST and then makes a service bus request - without SSL you would have to rely on encryping the message payload on the netduino and decrypting the payload in the Web API
In this way you are developing a bridge but not direct connection to the Service Bus.
Of course, it is a workaround due to SSL lack but in this case I would not use an "heavy" protocol as HTTP but a more lightweight protocol like MQTT and develop an MQTT-ServiceBus bridge in the Cloud.
A quick hack for me: an OpenWRT router in the home network and it help proxying to SSL services. There are cheap palm-sized USB-powered Wi-Fi routers that can be easily "patched" to OpenWRT, about $35-40.