Intent to implement: secure network time for SSL “bad clock” interstitials

157 views
Skip to first unread message

Matt Braithwaite

unread,
Feb 17, 2016, 12:22:33 PM2/17/16
to chromi...@chromium.org, est...@chromium.org

Contact emails

est...@chromium.org, m...@google.com

Summary

A common cause of SSL errors is wrong clocks.  Chrome detects this by comparing the system clock to the build timestamp, and showing a bad clock interstitial if the system clock is wrong.  In order to show the interstitial in more cases, we will change it to call NetworkTimeTracker to validate the system clock.


We’ll change NetworkTimeTracker to query a new (temporary, we hope) time service, using a protocol similar to Omaha.  We’ll also add a method to ask whether Δsystem-clock ≈ Δtick-clock since the last network time query.  If this condition is not met, is it likely that the system clock has been reset or the machine has been suspended and resumed, and therefore that network time cannot be trusted until re-queried.


A certificate’s validity will continue to be judged entirely according to the system clock.

Ongoing technical constraints

None.

Tracking bug

None yet.  This net-dev thread has more discussion.


Reply all
Reply to author
Forward
0 new messages