A list of the conversations with wolfSSL support about this issue:-> to wolfSSL
We have a problem with a demo intermittently failing the TLS negotiation when The returned error in Firefox (Windows 10, Firefox 77.0.1 64-bit) is: PR_END_OF_FILE_ERROR
The test is done using the net 3.5.1 Harmony package, meaning that it uses:
<Dependency name="wolfssl" version="v4.1.0"/>
The demo is reported by a customer, please see the post and history:https://www.microchip.com/forums/m1143893.aspx
I've attached the log that shows an VERSION_ERROR - that's the only error printed by the wolfSSL log, as far as I can tell.
Please help understand what exactly is going on and why the negotiation fails.
A similar error is returned by Chrome: ERR_TIMED_OUT.
firefox_log.txt <- from wolfSSL
Thank you so much for reaching out to wolfSSL support. I downloaded the wireshark capture and around packet 333 that the user noted there is a client hello for TLS v1. This is likely due to Firefox (depending on the version) attempting to do a TLS v1.3 connection. In some draft forms of TLS 1.3 TLSv1 was used in the client hello packet to initiate a TLS 1.3 connection (this was later changed to TLS v1.2 for obvious reasons, many servers had deprecated TLSv1 and seeing that type in a client hello was problematic for easy adoption).
If Firefox is either attempting a TLS 1.3 draft-18 connection or a TLSv1 connection it might be helpful to have the customer use the wolfSSLv23_server_method() instead of wolfTLSv1_2_server_method_(), this will allow the server to at least attempt to negotiate a different protocol version with Firefox. If they continue to have issue they can try enabling old tls version by making sure NO_OLD_TLS is not defined and they can enable TLS v1.3 draft version one at a time to see if this is a draft form of TLS 1.3. wolfSSL supports both draft 18 and the final draft of TLS 1.3.
If you enjoy working with wolfSSL please leave us a star on our github repository https://github.com/wolfSSL/wolfssl!-> to wolfSSL
Before posting your response to the forum, I’ve read it again to understand if there’s something that needs to be done from the Harmony TCP/IP stack point of view.
But there is one thing that is not clear to me, please excuse my ignorance as I’m no longer up to speed with the latest TLS developments:
How come this error is just occasional?
Is it possible that the same version of FFox uses TLSv1 or TLSv1.3 alternatively?
Not sure it makes sense.
The customer also notes that a similar behavior is noticed on Chrome, although less frequent.
So how come it works so many times and then it fails?
Adrian. <- from wolfSSL
That is a great question that I do not know the answer to unfortunately. I do not know why a browser such as chrome or Firefox would randomly try to do a TLSv1 handshake. Like I hinted at I don't actually know if this is truly a TLSv1 handshake or a drafter version of TLS 1.3 that sends a TLSv1 client hello to initiate the TLSv1.3 handshake. We would have to investigate to make that determination.
I think the chrome or Firefox developers would be best to answer that question. It might be a downgrade attack (user might have someone tampering with his traffic) trying to force a weaker protocol version or it might just be Chrome/Firefox doing their thing and maybe trying to see if a TLS 1.3 draft is available. I am not sure.
What I can say with certainty is that using the wolfSSLv23_server_method() to handle client connections that are prone to change which protocol version is used will allow wolfSSL to at least try and negotiate a different protocol version. wolfSSLv23_server_method() will start with the highest level protocol that is enabled and if a client requests a lower protocol version and that version is enabled in the wolfSSL build then wolfSSL will use the version requested by the client. In most cases users prefer to reject such connections (the current behavior) but if your customer wants it to be allowed they should use the server method that allows protocol version to be negotiated by the client rather than stipulated by the server.
If you enjoy working with wolfSSL please leave us a star on our github repository https://github.com/wolfSSL/wolfssl!<- from wolfSSL
I can now confirm that packet causing the error is a TLS v1.3 client hello. Can you have the customer try turning on support for TLS 1.3 with these settings and using the wolfSSLv23_server_method() should fix this issue for them.
If you enjoy working with wolfSSL please leave us a star on our github repository https://github.com/wolfSSL/wolfssl!