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.

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.

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.

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.

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

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?

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...

I'm just curious why the default response is still to reach for an Arduino--much more powerful SoC chips are cheap these days.

For us, the reason is that my co-founder and I (both are not hardware guys) were able to build a proof of concept in my garage and Arduino seemed like the best (easiest) choice. Since then, we hired a hardware guy who designed a custom PCB etc. HTTPS would be great but we don't transmit any personal data so it's not a high priority right now.

> HTTPS would be great but we don't transmit any personal data so it's not a high priority right now.

You are sending people's orders around the web. I'd consider that "personal".

None-the-less, use SSL, there is little reason not to use it these days. And as others have pointed out, it's the only good and easy way to guarantee what you send to one of these printers is what it actually received (no carrier tampering of your packets, etc).

Just use SSL.

If SSL isn't supported by the Arduino chipset, then that sounds like more than a "little" reason not to use it. That sounds like it might be an "it would be a whole lot of work" reason not to use it.

(I don't actually know how much work would be involved, but goleksiak says they would really like to use it, so I assume it's not trivial.)

SSL on the Arduino--usually a little 8-bit (!) chip--is a bit resource intensive, in both memory and processing time.

Hey, no worries. Real artists ship. :)

One reason to still use an Arduino is realtime. The arduino's minimalist OS is realtime by default, but the BBB runs non-realtime Debian. They might need RT timings for the printer interface? You can add realtime linux extensions to BBB, but it's not a beginner task -- basically rolling your own Linux installation and writing your app as a kernel module. You can also use the PRU on the BBB to get insane RT performance, but you'll have to code it in assembly. I love the BBB, but Arduino is still an easier package for simple realtime.

Yeah, like any number of Olimex parts. Or a Raspberry Pi Model A.

larger pool of cheap developers, and a hook onto an ongoing popular trend (arduino gizmodery), cheap prototyping.

if you buy a batch of beaglebones from adafruit.com or another, perhaps larger mid-tier distributor, you can likely get a discount per unit.

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

Sounds right. I also found this:

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

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

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?

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.