[goleksiak]

We would really like to use HTTPS but it's not supported by the Arduino chipset as I understand it. Though I'm not the hardware guy here at eatabit...

[linuxlizard]

Why not ROT13? Or a simple substitution cypher?

Not trying to be silly. But if the only goal is to prevent man-in-the-middle attacks such as someone mangling the data, why not "corrupt" the data such that the phone company in the middle can't read it?

You control both ends. You can make your own "security".

You're not explicitly worried about security. You're not worried about Evil Person reading your messages. You just want your carrier to stop f'ing with your data.

If the data is slightly corrupted so the carrier's crappy software can't recognize it as http headers then the carrier's software (hopefully) won't fck with it.

[MichaelGG]

They could try a different port - some systems won't bother.

They might also use TLS with null cipher. That should be not-so-intensive, even on a tiny processor. And it could be enough to defeat some packet-modifiers (they may notice it's TLS and not analyze), while maintaining HTTPS compatibility.

[lnanek2]

Last I checked, you have to use some sort of special sockets add on to use raw TCP instead of HTTP over TCP with heroku. So you are making your heroku setup more complicated and potentially more expensive since they sometimes charge for add ons. It may disable some of their routing and load balancing capability as well. It is kind of silly to start rewriting standard transport layers anyway since you are going to spend a long time doing that instead of working on your product.

[swordswinger12]

You guys build all the hardware - why not just use one of the pre-shared key TLS ciphersuites? No expensive public-key crypto required, just AES and SHA.

[lmb]

Last time I checked (about a year ago), support for PSK was pretty abysmal on the server side of things.

[angersock]

Why don't you guys just use a Beaglebone Black ($50), M2M cape (http://www.yantrr.com/products/m2m-cape-for-beaglebone), and a thermal printer (https://www.sparkfun.com/products/10438). BOM for that, plus project enclosure, is like $200. That's also just after a bit of quick googling...there's bound to be a much cheaper solution.

What's your price point for hardware?

[goleksiak]

We are at about $200 now for hardware. We have a custom PCB and 3d printed case. We also have an LCD and some control knobs in the mix. Checking out the Beaglebone stuff now...very interesting since there is basically no 3G/4G modems for Arduino right now...

[tedchs]

SPDY is an alternative to HTTP that avoids at least Verizon's carrier shenanigans.

[scottlinux]

Sounds right. I also found this:

http://stackoverflow.com/questions/15830333/arduino-due-http...

[sitkack]

Your network stack is being handled by a GSM/GPRS module, it might support SSL. Using Arduino was easy in this case, but I would have gone with something a little more substantial like an STM32F4

[Filligree]

Then, don't use SSL if it's too heavyweight.

I know everyone will tell you not to roll your own cryptosystem, but rolling your own is superior to having no encryption or authentication, and so long as you're sane about it the result should be no worse than passing plaintext.

Your messages are small. Encrypt (or maybe just sign) them with RSA and call it a day. You don't really need to use port 80 and a HTTP preface at all, do you?

[lmb]

That is pretty bad advice. RSA is slow, needs a lot of memory and is difficult to get right. Just go with AES in CTR mode if you absolutely have to. And remember that encryption != authentication.