Since I got everything up and running a few weeks ago, I’ve been trying to start making a TLS implementation.
This is effectively using the same setup as before, where the ESP8266 is connected by Serial to a computer, and wirelessly connects to a Raspberry Pi access point for packet capture.
First off, I found a neat little AES -128 encryption implementation that works with only a little modification! In fact, it seems to take under a second to encrypt a 64-byte string, so sending periodic sensor readings shouldn’t prove too troublesome.
Next I started trying to initiate a TLS handshake by sending a ClientHello packet over TCP. This proved tricky at first, particularly because I was using the client.print() method (for strings) instead of client.write() (for sending bytes of data).
At the moment, when I send and capture the packets (see previous post), Wireshark recognizes them as valid TLS packets, but the server I’m sending them to (data.sparkfun.com) keeps returning TLS alert packets, saying that there was a decode error. This, apparently can either be attributed to some problem with the packet, for instance a “length” field not correctly stating the length of the packet, or potentially because this method could be an explicit handshake, for which the server is not configured. (source: streamsec forum post ).
While I could continue trying to solve this particular problem, I think my next step will be to try using DTLS, or Datagram TLS, which is effectively TLS over UDP instead of TCP. Because UDP is connectionless, sending a DTLS datagram manually (i.e. with a predefined packet for testing purposes) should, in theory, be indistinguishable from one sent from a client that already has a fully-functioning DTLS implementation (e.g. anything with OpenSSL).
If the problem persists after trying this, it’ll have to be a problem with the way my packets are composed. (although I’m about 80% sure this isn’t the case!)