In the previous post (post #6), we got mbedTLS working and it delivered content to us from a server using SSL/TLS. However, in the code, you should have noticed a line saying that in real life we should bail out when the certificate verification fails
SSL has since been succeeded and superseded by TLS and in the rest of this post, I do not use SSL but instead TLS. However, TLS was built on top of SSL and as such the two are used interchangeably.
As pointed out, I am not an expert in informational security so I have to use a built library (or set of APIs) for performing these security operations. But even using libraries or APIs is not an easy task. This is especially the case for security related ones. Even if they are documented, they tend to have a lot of elements in them that you may get lost in the abbreviations, acronyms, internet standards etc. The SSL/TLS libraries are no exception. The libraries get complicated because the need to support several features due to possible scenarios such as:
There is really a lot of talk about IoT and how many billion dollars it will be worth in the future. However, unless we solve actual problems that we face, that might be a dream that will only connect a bunch of toys to the internet without much of information for our use. One of those problems is connectivity.
Most examples available online from hardware manufacturers, for development kits, and from cloud service providers will only describe the connection to the internet via ethernet. If they do not show ethernet, the application is most likely a Bluetooth Smart client app that does not connect directly to the internet but via a host like a mobile phone. Using a mobile phone is not always the best option unless it is a wearable. There are many of those nowadays. You also cannot use ethernet everywhere you want. Your piece of hardware is grounded.