Sending TLS Packets

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 ( 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!)


Project Update

Things have been a little quiet on the blog lately; that’s mainly because the past week or so have been used to do some research into the security landscape, and to figure out the exact direction of this project.

As it stands, this project is going to have a more definite focus on security, specifically implementing some form of TLS, as well as addressing the chromecast vulnerability.

The initial focus will be to implement TLS, starting off with a basic implementation that achieves encrypted communications, which will then be developed to produce an implementation of TLS that could be considered secure. The initial implementation won’t use TLS records, but these will be implemented.

A tested version of AES will be implemented. Different implementations are being looked at at the moment, such as these:

The initial basic implementation will feature Basic TLS handshake, with self-signed certificate, and allow sending encrypted messages. Following this, a mock CA will be created, and authenticating the server, and possibly the WiFi chip will be implemented.