EHS5-E, A-Rev 00.000.42 with TLS error | Telit Cinterion IoT Developer Community
April 15, 2021 - 2:40pm, 2903 views
Hello,
We have several older EHS5 devices already installed and would like to activate TLS/SSL via a software update. However, there seems to be a problem with the firmware /A-revision in use.
I think we have exactly the same issue as described here: https://iot-developer.thalesgroup.com/threads/problem-aws-and-esh5
We are running on our own servers. Not aws.
I know that a firmware update would fix the issue. For devices with newer revisions, different chip, etc. it's already working as it should.
Unfortunately, it would not be profitable to start a recall here after all this time for a "free update" and I think there is no solution to update the firmware remotely?
I am currently looking for details about the problem. Where can I find release notes for the A-Rev?
I hope that we can possibly make an adjustment on the server side to be able to establish an encrypted connection without a firmware update (limiting the SSL/TLS version, ciphersuites,...).
Has anyone here had any success and can give me some hints?
The goal is to have a working MQTT connection over TLS.
We did already some tests on the server side. I can see the connect but for the most common cipher suites we don't receive anything in our application. Sometimes it works (just a message or two) with "TLS_RSA_WITH_AES_128_CBC_SHA"
Thanks in advance and sorry for digging up such an old problem.
BR
Kris
Hello,
There were updates in the SSL libraries and that is why the newer firmware versions may work with your server while the older may not.
The supported cipher suites are listed in the Java User's Guide document released for the particular firmware version or versions. You should be able to find it here: https://iot-developer.thalesgroup.com/documentation/download-documentati...
Best regards,
Bartłomiej
Hi Bartłomiej,
thank you for you response. I already have the list of supported cipher suites.
The problem is, that the old firmware is not able to connect while newer firmware versions are working fine. For example "TLS_RSA_WITH_AES_128_CBC_SHA" is supported according to Java User's Guide but the device is not sending any data after connection.
So I suspect that the firmware update either added cipher suites or there were problems with some actual supported cipher suites that were fixed.
I have already spent a lot of time on the problem. The problem is that I am pretty much in the dark as to the cause of the problems. I have already tested about 20 cipher suites with different TLS versions. unfortunately without success. I really hope that the information about what has been changed from a-Rev. 42 to 51 will help me to test specifically.
I've seen, that you were answering to the original thread:
> The newer version contains updated ssl libraries and should be working with AWS.
Do you know what was changed in ssl libraries to support AWS?
I know that the problem is very old and I also understand that a product with an old version cannot be supported indefinitely. But the devices are installed and a recall makes no sense at this point. If I don't find a solution, we will have to stop the update support. I would really hate to do that.
Sincerely
Kris Budde
Hello,
I don't have any detailed information about what exactly was changed.
There was a general update of the libraries responsible for TLS. So there may have been changes in behavior other than cipher suites.
Besides that the problem you are facing might also be related to some extensions like elliptic curves.
You probably have a full control on the server if you can change the cipher suites. Are you also able to see TCP traces? Please check the TLS handshake to be sure what parameters were selected for the connection. BTW module also sends the supported cipher suite lists in Client Hello message.
As for the remote firmware update - it is possible and can be controlled with AT commands or SMS. It could work if your application was able to configure it with AT^SJOTAP command. Then you only need an http server to download the firmware from.
Best regards,
Bartłomiej
Hi,
I'm a little ashamed that I haven't created a TCPDump yet.
I now have the first data from an old box. So far it looks normal (client Hello, Server Hello). But I will create more traces and compare them with working connections.
But it sounds like we maybe able to update the devices. Our software can issue AT^SJOTAP commands. How does it work? I was under the impression that firmware updates are quite complicated and are not using the common OTAP mechanism.
Can you provide me the firmware and point me to the right documentation? This sounds to me like a much better solution.
Best regards
Kris
Hello,
I'm sorry I mixed up a bit. SJOTAP command is for userware update (MIDlets). But it still could be useful in a way.
Firmware update is not automated that much and requires some implementation on the customer application side.
For firmware update you need from us a usf file which contains the firmware image and JRC MIDlet which should also be updated with the usf file. We provide the AT^SFDL command which can perform the usf update. But your application ***** to download the file and store it on the module's file system (can also be done with AT commands). Then JRC ***** to be downloaded by the application and also stored on the module and installed with AT commands.
If your solution includes MIDlet application you probably have our development environment installed. If so you probably have a bunch of demo MIDlets also on your PC. We have a demo FotaMIDlet which implements the firmware update solution. Once installed on a device (for instance with OTAP) it can perform the firmware and JRC download and update. It is triggered by SMS messages as I remember.
For more information about OTAP and Java MIDlets you can refer to the Java User's Guide document. You can find one here: https://iot-developer.thalesgroup.com/documentation/download-documentati...
Best regards,
Bartłomiej
Hi Bartłomiej,
I give up configuring the server to support old firmware. I see the same data but different behavior. So I fear we cannot solve it.
So I'll focus on firmware updates. Can you provide me usf file and midlet for running the update?
Thank you for your valuable help.
Best regards,
Kris
Hello,
I have sent you an email.
I agree that if firmware update is feasible it would be a better solution.
Best regards,
Bartłomiej