Problems selecting cipher suites about ubxlib HOT 16 CLOSED

That was fast 😀
I will close this issue as I know how to proceed and thanks again for your effort

from ubxlib.

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:

<legacy_cs>=100 is the "add cipher suite" operation; without it the ubxlib code can only do <legacy_cs>=99 which replaces the single cipher suite with the one specified (this is not very clear in the AT manual, you have to infer it from the fact that the words "list of" appear in the bit about 100 but not in the bit about 99):

We could make this clearer by adding a function bool uCellSecTlsMoreThanOneCipherSuite() which the uSecurity API could call to see if more than one is supported, then it could return an error to you rather than blindly replacing one with the next. I will do that.

Doesn't help you of course, not sure what to suggest.

from ubxlib.

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?
This isn't a behavior I expected, but it is what it is. Any chance this will be changed with a future software update of the modem?

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 👍

from ubxlib.

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...

from ubxlib.

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

from ubxlib.

wireshark.log

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 ATI9, should be queried and printed-out by ubxlib near boot)?

from ubxlib.

At the moment we have the FW version 00.12,A00.00.

ATI9

00.12,A00.00

OK

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.
The modem will send the list of 37 supported suites and when these don't match with the server the connection will be terminated by the server. All the other supported cipher suites by the modem will never be used as long as they are not included in the client hello. The server has to assume the client only supports the 37 listed.

from ubxlib.

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.

from ubxlib.

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... .

from ubxlib.

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.

from ubxlib.

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.

from ubxlib.

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.

from ubxlib.

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

from ubxlib.

Ok, thanks for the update. Then we have to implement the proposed workaround.
Do you have any plans on when the proposed API change will be implemented? Maybe we can additionally update the ubxlib in this step.

Regarding the update. I have an old modem with 00B hardware on my desk which can't be updated to my knowledge.
But a colleague of mine tested it with the 01B hardware and the problem remains.

Thanks for your support!

from ubxlib.

But a colleague of mine tested it with the 01B hardware and the problem remains.

Understood. The API change has been tested and is in review now, should be here very shortly.

from ubxlib.

Now pushed to master here in commit 27c75a8 with a comment-only update to the same code in commit b747695.

from ubxlib.