close-circle
Close

Security and HTTP protocol

A project log for HTTaP

Test Access Port over HTTP

Yann Guidon / YGDES 05/08/2017 at 11:290 Comments

I have already addressed security in a different post but on a different, related project: Security and sandboxing

Today I address "antipatterns" as described in https://blog.cloudflare.com/iot-security-anti-patterns/


Let's review the 4 points that are raised :

HTTP Pub/Sub

There is no such thing in the basic HTTaP protocol. There is no redirection or even mention of a third-party URL in the server because the whole thing is meant to be self-contained and autonomous.

DOS is prevented through several passive means:

IoT Device as TLS Server

Encryption is a difficult thing to do, particularly for this class of devices where most corners are cut.

Encryption is not required for now and I don't think I'll use a library, at least for the final version. This is a server-side requirement, since most HTTP clients transparently manage HTTPS.

The suggestion to use a 3rd party server for authentication actually helps a lot, to separate the authentication nightmare from the protocol itself. The HTTaP server can inquire or refresh a key once it starts, which helps a lot when several HTTaP servers are running in parallel (easier and dynamic key management, no more one-configuration-file-per-server nightmare).

But that's for a v2 of the protocol.

Unencrypted Bootloader

This is out of the scope of the protocol.

Database-as-IPC

The HTTaP server can be seen as a sort of database, in a way... but the protocol itself shields against backend implementation variations and their effects.


Note : for security over unreliable networks, whitequark suggests using a nginx layer in this minimalist Python server. I'm not fluent with cryptography and security protocols so I can't devise the best approach...

Discussions