Users who have manually changed their clock cannot connect to mqtt(short issue description)

[kimdanielarthur-cowlabs]

Describe the bug

When a user has changed the time on their device they are not able to connect to the mqtt

Expected Behavior

Expect some way to override the checking of current time on device ala correctClockSkew

Current Behavior

Have not seen any options to set the correctClockSkew for the iot-device-sdk v1 or v2

Reproduction Steps

1. Change time on your device to be out of sync with actual time
2. Try to connect to the mqttt
3. See that connection fails

Possible Solution

Allow to forcibly override the checks on users local device time

Additional Information/Context

No response

SDK version used

v1.16.0

Environment details (OS name and version, etc.)

android/ios react native

[yasminetalby]

Hello @kimdanielarthur-cowlabs ,

Thank you very much for your submission.

The SDK is currently behaving as expected. This would be more of a feature-request for the aws-iot-device-sdk-js-v2.
We are currently in discussion with the team regarding the potential implementation of this feature. I will keep you updated on here.

Thank you very much for your feedback and collaboration.

Best regards,

Yasmine

[kimdanielarthur-cowlabs]

Ok great thank you!

…

On Tue, 29 Aug 2023 at 14:19, Yasmine Talby ***@***.***> wrote: Hello @kimdanielarthur-cowlabs <https://github.com/kimdanielarthur-cowlabs> , Thank you very much for your submission. The SDK is currently behaving as expected. This would be more of a feature-request for the aws-iot-device-sdk-js-v2. We are currently in discussion with the team regarding the potential implementation of this feature. I will keep you updated on here. Thank you very much for your feedback and collaboration. Best regards, Yasmine — Reply to this email directly, view it on GitHub <#422 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBTCLT6EA6AK2RS7NHJALYDXXXM3NANCNFSM6AAAAAA37H6GOM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bretambrose]

Spent a little time looking into this. In your case, you're using the browser implementation and unfortunately I'm hitting a roadblock there that may prevent a nice solution. As near as I can tell, the websocket implementation (and mqtt-js) do not surface any information about the failing http response sent by AWS when the websocket handshake upgrade is signed by a skewed timestamp (the core problem here). Without the date header sent by IoT Core, we have no way to automatically calculate what the skew adjustment should be.

A less-nice alternative is for us to provide an optional callback that lets you adjust the timestamp used in signing. It's more work for you, but your application could hit some kind of trusted time service and inject that result into the signing process.

[kimdanielarthur-cowlabs]

Thanks for looking deeper at it!

Yes I was thinking it could be a workaround to even have an option to pass some timeOffset to the client on construction and it would use that offset for all underlying requests within the sdk?

Kim

[bretambrose]

Well, the problem just becomes yours now, as it's not clear how you can get a trustworthy timestamp in the browser (ie no NTP). Any calculation error that results in a timestamp off by more than 15 minutes is a sigv4 signing failure and complete connectivity lockout.

Another possibility I should mention: if you set up custom authentication to IoT Core then the connection process does not need an accurate timestamp (because sigv4 signing isn't used), only one good enough to do x509 cert chain validation for TLS.

[kimdanielarthur-cowlabs]

Thanks will look into the custom authentication. For valid time in our case we already make a request to our servers to retrieve endpointurl and authentication details for the mqtt. So in theory we could ourselves calculate any time offset before the client authenticates with mqtt? Without having ntp locally in client.

…

On Wed, 30 Aug 2023 at 16:19, Bret Ambrose ***@***.***> wrote: Well, the problem just becomes yours now, as it's not clear how you can get a trustworthy timestamp in the browser (ie no NTP). Another possibility I should mention: if you set up custom authentication to IoT Core <https://github.com/aws/aws-iot-device-sdk-js-v2/tree/main/samples/browser/custom_authorizer_connect> then the connection process does not need an accurate timestamp (because sigv4 signing isn't used), only one good enough to do x509 cert chain validation for TLS. — Reply to this email directly, view it on GitHub <#422 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBTCLT7VPPEUXYBI6GTWR53XX5DWFANCNFSM6AAAAAA37H6GOM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bretambrose]

That route might work, but I don't know if it's possible to access the raw http response where the Date header would sit.

[kimdanielarthur-cowlabs]

Awesome if the SDK just magically solves it of course :D

[jmklix]

This isn't something that we plan on adding to this sdk, so I'll be closing this issue. As @bretambrose mentioned above it's not possible to access the raw http response with the date header when running js in browser applications.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.