using local system time to sign AWS requests

[mistrmistr]

AWS request signatures include the request time, and many AWS services will refuse a request if that signature indicates a time that is more than 5 minutes off from the service's time. The AWS C++ SDK signs these requests using local system time and on some devices, particularly PCs, it is probably not a good idea to trust system time. It would be nice to have an option that syncs with ntp or some other trusted source upon SDK initialization and uses that for request signing, or allow us to more easily provide our own time function (which can be done now, I believe, by implementing your own signer but you need to implement that entire class).

[bretambrose]

I've added an internal task for this.

[webcoyote]

This problem manifests when the system clock is incorrect. While this is an infrequent problem for online services using the SDK it is a problem for end-user applications where mis-configuration of personal computers is more common. Further, end-users may not be able to easily correct this problem, as for example when running as a limited user without permissions to re-synchronize the system clock.

I'd like to suggest that the SDK enable the caller to override std::chrono::system_clock::now so that the user can provide a different time value based on user-level time-synchronization with an external time source other than NTP.

Overriding the time function would allow the user-code to receive a timestamp from a server, compute the delta from current time, and provide modified time-stamps back to the AWS SDK for signature-creation purposes.

This change would not create a security hole because the user code already has the capability to effectuate a similar change using API hooking or similar code-modification techniques.

[Bu11etmagnet]

Instead of overriding std::chrono::system_clock::now, the signing algorithm should accept a DateTime parameter (possibly with a defaulted value of DateTime::Now()). It would be the caller's responsibility to call DateTime::Now() and pass the result to the signer .

[avargaskun]

I would suggest instead of passing a DateTime to allow caller to provide an offset to be applied by SDK every time it queries std::chrono::system_clock::now. Similar behavior as in aws-sdk-js: aws/aws-sdk-js@3b14ada

Even better would be to have an option to automatically correct failed requests due to clock skew within the SDK itself without the client having to calculate and specify an offset, again similar to aws-sdk-js: aws/aws-sdk-js#706

[mmustafa-hp]

In my observation of this failure, the PC clock may be correct but the Local & TimeZone settings cause the signature time to be off by an hour or two and induce the failure.

[JonathanHenson]

We shouldn't be concerned about time zones since we pull the gmt time. Do you think this is a case of a user adjusting the time to their time zone instead of setting their timezone?

Sent from my iPhone

On Sep 16, 2016, at 2:06 PM, mmustafa-hp notifications@github.com wrote:

In my observation of this failure, the PC clock may be correct but the Local & TimeZone settings cause the signature time to be off by an hour or two and induce the failure.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[mmustafa-hp]

Not really sure what is causing it. We are seeing instances in many countries as well. So your guess is good. Some users in countries with multiple time zones may be setting the time zone and adjusting the clock.

[JonathanHenson]

I just pushed a fix for this. The way it works is as follows. If we recieve a signing error, we check the date header returned from the server. If it's off, we automatically adjust the clock skew and retry the request. Once it is adjusted the first time, the client will have the correct timestamp. This should happen invisibly to the user without any errors surfacing.

Feel free to reopen if you still have problems or have any further questions.

[mmustafa-hp]

Thank you. We will integrate and test.

[cyberfox1]

Does anyone know if the AWS Amplify handles clock skew like this, i.e. transparent adjustment?