So I have been having an issue while evaluating cyassl security stack that now comes native to the MQX 4.2.0 RTOS. The problem that I have been seeing is that after I load our products' https’ main page and establish a separate SSL connection (non https, generic secure connection that has a proprietary app layer that rides immediately on top of cyassl secure layer) I then click on another link on the web page I get a bad mac error.
What I mean by the non https connection is that I have written firmware so that it is also listening on port 2000 where the unit accepts secure connections, this kind of acts like SSH but much simpler. After I connect to the generic ssl secure socket using a popular ssl terminal program (openssl s_client app as seen below) I then click on a link on the web page (keep in mind this happens a few seconds after the connection has been successfully established with openssl) although it doesn't load. The web page will load if I simply retry, so the good news is that we always seem to recover from this but I don't want to have a product where the customer needs to constantly retry loading web pages if they don't load the first time. BTW, I have tried this on chrome, IE, and Firefox and they all show the same symptom.
To repeat the error this what I did:
- Loaded our main page:
2. I then successfully established a connection on port 2000 using openssl s_client application as seen below.
3. I then clicked on configuration button as seen below.
4. After I clicked on the link, I get the following error from firefox.
5. While all of this is happening I have a wireshark trace running, below is where I think the error is happening. I have attached the wireshark trace to this email, if you didn’t get it please let me know as soon as possible.
FYI, MQX http stack opens and immediately closes an http session after it has load the page on the client side hence why you might notice that there are multiple ssl session happening consecutively.
I have dug deep into MQX’s implementation of CYASSL and it appears that they have wrapped the CYASSL API with a module called rtcs_ssl, I have attached the module for your reference. My generic p2000 tcp server code also uses the same module. At first I suspected something wrong with how the rtcs_ssl uses one mutex for all ssl objects and for ssl context although after a lot of testing and instances of where I created debug code so that each ssl object gets their own mutex I got nowhere on this particular issue. BTW, I have backed off all of my changes to rtcs_ssl so I’m pretty much back to exactly what mqx gave me. I made sure to follow cyassl’s manual suggestions on thread safety. After thinking about this further, the test that I have just described should not run into the issues that I thought were happening in regards to thread safety, i.e., after I have established a p2000 connection using openssl s_client app the https has already closed the previous session and should simply allow a new session to start after I click on the link. I have debugged the MQX rtos code with my debugger in that I made sure that the http stack was calling rtcs_shutdown (which internally calls cyassl_free()) and that it closes the socket using the appropriate calls. I’m not convinced that MQX http stack is good, from looking at the wireshark trace I’m starting to suspect that something went wrong with the encrypted handshake hence why my pc sent a bad mac alert which caused my firmware to send a RST packet (i.e., reset) as seen below.
Also, I have thought about upgrading cyassl that now comes with mqx 4.2 because that version is at 3.3 and from what I understand is that wolfssl is now at 3.6.6 which indicates that we are behind by quite a bit. Would upgrading help or solve my situation? Any help on this issue would be greatly appreciated.