While working on a secure cloud for the gang of the esp8266 based devices we are developing we need SSL – real and secure.

And this August is the month of the SSL issues , it seems , but thankful to the Espressifs’ quick support they are on the way out.

SSL Memory Leak

The latest SDK v1.3.0 introduced a bug that simply didn’t call the disconnect callback of esp connections under some circumstances and that in turn leaked memory. It’s not clarified but the case was when you had a tcp listener and ssl connection after the ssl connection is over, your tcp listener connections did receive disconnect callbacks anymore. You can get the fix from bbs.espressif.cn

Server Certificate Verification

Recent memory optimizations gave enough memory to turn on server certificate validation. But hit the next bug – it fails

Still in progress but you can watch the development of the resolving on the forum: SSL CA Issue

Current state is that if you do not provide the two level chain, i.e. certificate and issuer certificate the connections is established ok.

During the past weeks i’ve worked on getting the FOTA upgrades work on the 2MB boards by Olimex.

The wonderful esp-link project by Thorsten von Eicken was a great example of two things:

How to concatenate the espfs filesystem image with the firmware images.

How to properly write a new image to the flash.

It was a nice example to start with.

So after a lot of fiddling with Makefiles, cgi routines and esptool – i’ve finally got the OTA working.

Gotchas:

esptool.py modifies the images when writting – you have to pass the correct options for the flash split you want to use. Why on earth it modifies a already correctly build images with app_genbin.py, when not requested too is subject to be discussed in another post.

When using 512 KB or 1024 KB flash the two firmware images are both mapped at 0x40200000 so when using user2.bin you need correct offset + 0x8000 for the 512KB case.

When using 1024KB images you do not need offset – second MB of the flash is mapped at 0x40200000 too. So no need to have offset and essentially that makes the user1.bin same as user2.bin /not tested yet/. But this means doing less builds and if you plan to distribute upgrades less content.

I’ve added ESP_FLASH_SIZE variable to build correct linker scripts and flash commands. I’m working on a template project which will be available on github. But you’ve got the idea of how to do it. One nice addition i’m working on is the ability to have different output directories.

The other minor modification you will need is to properly initialize EspFs in your user_main and link the espfs_img.o in your final linking step.

Now there are two upgrade scenarios – user initiated for consumer devices and automatic for industrial deployment. And the two transports for them HTTP and MQTT. HTTP was easy, MQTT is next – stay tuned.

One big con is that the mqtt user name and password can be sniffed and used to connect to the cloud. But that’s easy solvable, if they don’t speak right, disconnect them and force password change.

Secure Firmware upgrades

Only local and only user initiated, user must see and check the result of the upgrade – Any other option introduces big risk for the system and the user.

Data – What to protect and what not?

It’s well know that all encryption is value versus time. So do you really want to hide what was the temperature at your house 5 minutes ago? – May be, if you are paranoid, but you definitely want to lock the access to your internet enabled door locks.

So all the actuators must be crypto protected – they do things. While sensors can be divided into two types – sensitive and non-sensitive. For example – house alarm state is sensitive, just like house human presence . But the outdoor temperature is not sensitive, you can get it N+1 ways.