-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems selecting cipher suites #211
Comments
Hi, and thanks for posting. Unfortunately I think you're issue is likely that SARA-R422S only supports setting of a single user-configurable cipher suite. From the interface manual:
We could make this clearer by adding a function Doesn't help you of course, not sure what to suggest. |
Thank you very much for the blazing fast response. That is indeed unfortunate news. So for my understanding, the modem supports a list of cipher suites by default, but doesn't support a custom list. Then only one cipher suite is support at the same time? Do you see any other way than trying to connect with one cipher suites all by one until one works? Maybe caching the result could help for the next connection. In addition, I think your proposed change of the API is a good idea 👍 |
Now you're getting into the sticky details of TLS negotiation, which I can't say I'm 100% sure of. I would have thought that the set of "automatically" supported cipher suites would be sent to the server in the "Client Hello" and, if there were some cross-over between what your server supports and the ones in that list, then it would propose those back again and things would work. I guess from what you're saying that is not the case. I can probably run Wireshark on our test echo server and run a TLS test with SARA-R422S to find out what does happen, will take a look. I will also see if I can't rustle up someone who actually knows what they are talking about... |
I already did the Wireshark capture. By default our modem sends these 37 cipher suites in the client hello: These are also mentioned in the AT commands manual and marked with and (D) for the SARA-R422S modem. As these default ones don't overlap with the desired server (server is not in our control) the TLS handshake failes because no shared cipher was found |
Aha, yes, just did that same thing and obtained the Wireshark log [attached] from our echo server, which indeed looks the same as yours. Darn. Is your server newer or older, i.e. might there be a chance that a later FW revision of SARA-R422S happens to pick up later cipher suites which might work? What FW version do you have (response to |
At the moment we have the FW version
The server is rather new. Assuming the default cipher suites mentioned in the manual don't change, I don't see how a update could fix this. |
Indeed, it would have to be the default set that was changed or expanded to help you out. I assume it is not viable to find one single cipher suite which you know your server supports and so could choose just that? I guess that would be a bit risky anyway, should a flaw be found in that suite and you are left without a choice. |
Problem is, we have to connect to different servers. I could check whether we have and match between those, but that's not really a future prove option. These cipher suites can change at any time on the server side assuming they might me considered insecure in the future or any other reason... . |
Understood. I've asked the application engineer internally who owns SARA-R422 if he knows of any ways this might be made to work; will get back to you. |
Perfect, thank you very much. When there is no other way we might have to implement some kind of mechanism on our side to try out the cipher suites one by one in every connect as mention above. |
The application engineer confirms that you would need to try your list of cipher suites one at a time with the server to determine which is acceptable. I guess the "acceptable" cipher suite could be cached so that you don't try unacceptable ones again needlessly for a given server but it is, unfortunately, a pain. |
Oh, and he doesn't believe the set of initial cipher suites have changed but he does recommend using the latest module FW, which can be found here: https://www.u-blox.com/en/product/sara-r4-series?legacy=Current#Documentation-&-resources |
Ok, thanks for the update. Then we have to implement the proposed workaround. Regarding the update. I have an old modem with 00B hardware on my desk which can't be updated to my knowledge. Thanks for your support! |
Understood. The API change has been tested and is in review now, should be here very shortly. |
That was fast 😀 |
Hello, we are using a SARA-R422S modem.
When connecting to a server we need to modify the supported cipher suites on the modem as our server doesn't support the default ones by the modem. Unfortunately we can't get it to work.
First we created our own default security TLS settings based on
U_SECURITY_TLS_SETTINGS_DEFAULT
from ubxlib:To increase the array of
uSecurityTlsCipherSuiteIana_t
inuSecurityTlsCipherSuites_t
we increased the defineU_SECURITY_TLS_MAX_NUM_CIPHER_SUITES
accordingly.Based on our custom default tls settings we now try to connect to a server: (Simplified code snipped)
AT log for
uSockSecurity()
:When sniffing our connection with wireshark we noticed the client hello only includes the last cipher suite in the list
U_SECURITY_TLS_CIPHER_SUITE_RSA_PSK_WITH_AES_256_GCM_SHA384
and not the whole list:How do we properly setup the cipher suite list on our modem?
Thank you very much in advance for the help.
The text was updated successfully, but these errors were encountered: