Hi Broadcom team,
In this thread: https://community.broadcom.com/thread/6760?start=15&tstart=0
I have reported the WICED device cannot connect to
(Note, the server already change settings to avoid SNI issue)
In this case, it fails at the 3rd time calling ssl_handshake_client_async().
Fails in both sdk-3.1.2 and sdk-3.5.2.
I have done more testing today by comparing the TLS handshake of WICED and
wget/curl tools. Then I found it looks like WICED always send the maximum
supported version (0x0303) in record layer version number. But wget/curl
tools send the minimum supported version (0x0301) in record layer version number.
i.e. The WICED device sends 0x0303 in both Record Layer version and hadshake protocol version.
The wget/curl sends:
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301) <<<< Here the minimum supported version
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Version: TLS 1.2 (0x0303) <<<< Here the maximum supported version
Note, setting record layer version number to 0x0303 can be problematic with some server implementation.
Since the BESL is binary release, I cannot change the behaviour to test.
However, for testing purpose, I change tls_maximum_version to TLS1_0/TLS1_1.
So the WICED device send 0x0301 or 0x0302 for both Record Layer version and handshake protocol version.
Then it don't fail at the 3rd time calling ssl_handshake_client_async().
In SDK-3.1.2, the device still got error at the 4th time calling ssl_handshake_client_async() with error code 65249.
In SDK-3.5.2, the https_client works.
So I think the BESL code needs fix to send minimum supported version for Record Layer Version.
Then backport the fixes in SDK-3.5.2 to SDK-3.1.2.
We already have thousands of devices depolyed all over the world, so please help to provide the fix for us.
Note, the shipped devices are using SDK-3.1.2.
Please let me know who should we contact to get the fix.
Looking forward your feedback.