Expired HTTPS certificates and incorrect clocks
1,335 views
Skip to first unread message
craig....@gmail.com
Dec 12, 2014, 8:36:32 AM12/12/14
to securi...@chromium.org
A common bit of feedback I receive from customers is that they see the "certificate has expired" error message.
Every time I have been able to check, it is because their computers clock is out... typically by several days, months, or even years (and yes, I would have thought that Windows and OSX would have solved this now with NTP).
Amazingly they continue though to the online shop, place an order (with credit card details), and only mention this afterwards.
I assume they see these errors so frequently they just ignore them?
---
So should the browser make a callback to a server, just to ask for the rough date/time?
It doesn't need the accuracy of NTP, to the nearest hour would be enough... then the error message could explain what is wrong.
Two points to keep in mind though...
- Some people might have problems with their browser calling home (to find out the time), so probably best to be very transparent, and possibly only when a certificate expired error occurs.
- The website providing the time probably cannot use HTTPS, as its verification will probably fail as well... so maybe use some form of public-key cryptography that allows the servers private-key to encrypt the date/time, and the browser can use the public-key to find out the value and verify that it came from a valid source (not that I can imagine anyone would try to do something malicious with it).
Craig
Every time I have been able to check, it is because their computers clock is out... typically by several days, months, or even years (and yes, I would have thought that Windows and OSX would have solved this now with NTP).
Amazingly they continue though to the online shop, place an order (with credit card details), and only mention this afterwards.
I assume they see these errors so frequently they just ignore them?
---
So should the browser make a callback to a server, just to ask for the rough date/time?
It doesn't need the accuracy of NTP, to the nearest hour would be enough... then the error message could explain what is wrong.
Two points to keep in mind though...
- Some people might have problems with their browser calling home (to find out the time), so probably best to be very transparent, and possibly only when a certificate expired error occurs.
- The website providing the time probably cannot use HTTPS, as its verification will probably fail as well... so maybe use some form of public-key cryptography that allows the servers private-key to encrypt the date/time, and the browser can use the public-key to find out the value and verify that it came from a valid source (not that I can imagine anyone would try to do something malicious with it).
Craig
Hanno Böck
Dec 12, 2014, 8:44:46 AM12/12/14
to securi...@chromium.org
Just two notes on this:
a) This problem is likely going to increase because of ocsp stapling.
The stapled ocsp responses have much shorter validity timespans. (I
already had one customer where this was likely the issue.)
b) Wrong clocks can also be a security issue. MitM attacks on NTP can
circumvent HSTS. See
https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf
https://github.com/PentesterES/Delorean
A time sanity check in the browser could be a good idea. I already
thought of that after the blackhat/hsts talk.
Chrome is already probably doing connects to some google domains on
startup to check for updates, blacklists, ... - it could throw a
warning if the timestamp of the https reply differs significantly from
the system time.
To fully protect against the HSTS attack it would however also have to
monitor unusual time changes at runtime.
Appart from that: NTP needs to die and be replaced with secure
solutions (tlsdate is a good choice). But that's out of scope for a
browser.
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
a) This problem is likely going to increase because of ocsp stapling.
The stapled ocsp responses have much shorter validity timespans. (I
already had one customer where this was likely the issue.)
b) Wrong clocks can also be a security issue. MitM attacks on NTP can
circumvent HSTS. See
https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf
https://github.com/PentesterES/Delorean
A time sanity check in the browser could be a good idea. I already
thought of that after the blackhat/hsts talk.
Chrome is already probably doing connects to some google domains on
startup to check for updates, blacklists, ... - it could throw a
warning if the timestamp of the https reply differs significantly from
the system time.
To fully protect against the HSTS attack it would however also have to
monitor unusual time changes at runtime.
Appart from that: NTP needs to die and be replaced with secure
solutions (tlsdate is a good choice). But that's out of scope for a
browser.
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
Adrienne Porter Felt
Dec 12, 2014, 10:22:34 AM12/12/14
to Hanno Böck, security-dev
As of Chrome 40, there is a time sanity check in the browser. If that fails, Chrome will show a message telling you your clock is wrong & linking to the date/time setup (instead of a security error).
I do wish we had a way to securely verify the clock for reals. However the browser keepings its own separate time apart from the OS in a way that can't be MITMed...starts to get complex.
Craig Francis
Dec 12, 2014, 11:47:25 AM12/12/14
to Adrienne Porter Felt, Hanno Böck, security-dev
On 12 Dec 2014, at 15:22, Adrienne Porter Felt <fe...@chromium.org> wrote:
> As of Chrome 40, there is a time sanity check in the browser. If that fails, Chrome will show a message telling you your clock is wrong & linking to the date/time setup (instead of a security error).
>
> I do wish we had a way to securely verify the clock for reals. However the browser keepings its own separate time apart from the OS in a way that can't be MITMed...starts to get complex.
Thats great news... thanks for having already implemented it :-)
> As of Chrome 40, there is a time sanity check in the browser. If that fails, Chrome will show a message telling you your clock is wrong & linking to the date/time setup (instead of a security error).
>
> I do wish we had a way to securely verify the clock for reals. However the browser keepings its own separate time apart from the OS in a way that can't be MITMed...starts to get complex.
And yes, I wouldn't want the browser implementing its own time, that should be for the OS to deal with... even if NTP has a few issues that need resolving (thanks for highlighting that Hanno).
Craig
Chris Palmer
Dec 12, 2014, 2:34:28 PM12/12/14
to Adrienne Porter Felt, Anthony LaForge, Hanno Böck, security-dev
Anthony was telling me that Chrome already securely retrieves the date
for other reasons (I think it was field trials? component updater?).
He wanted us to see if there is a way we can leverage that to get a
correct time in Chrome.
We know that tons of people have computers with incorrect clocks, and
that they are getting the warning interstitials a lot. We've improved
the warning, but I think it's time to look into seriously having
Chrome know the time on its own. Especially if we are indeed already
doing that...
> To unsubscribe from this group and stop receiving emails from it, send an
> email to security-dev...@chromium.org.
for other reasons (I think it was field trials? component updater?).
He wanted us to see if there is a way we can leverage that to get a
correct time in Chrome.
We know that tons of people have computers with incorrect clocks, and
that they are getting the warning interstitials a lot. We've improved
the warning, but I think it's time to look into seriously having
Chrome know the time on its own. Especially if we are indeed already
doing that...
> email to security-dev...@chromium.org.
Chris Bentzel
Dec 12, 2014, 2:44:52 PM12/12/14
to Chris Palmer, Nicolas Zea, Adrienne Porter Felt, Anthony LaForge, Hanno Böck, security-dev
+zea
akalin@ and zea@ at one point were looking at network time for sync.
Not sure what happened with that.
akalin@ and zea@ at one point were looking at network time for sync.
Not sure what happened with that.
Adam Langley
Dec 12, 2014, 2:52:00 PM12/12/14
to Chris Bentzel, Chris Palmer, Nicolas Zea, Adrienne Porter Felt, Anthony LaForge, Hanno Böck, security-dev
On Fri, Dec 12, 2014 at 11:44 AM, Chris Bentzel <cben...@chromium.org> wrote:
> +zea
>
> akalin@ and zea@ at one point were looking at network time for sync.
> Not sure what happened with that.
ChromeOS uses the timestamp in the server_nonce of TLS handshakes with
> +zea
>
> akalin@ and zea@ at one point were looking at network time for sync.
> Not sure what happened with that.
Google to set its clock. That's pretty good but there is a bit of
circularity in that you validate the TLS connection using certificates
for which you need a clock to consider expiry.
I've long pondered setting up a UDP service that signs submitted
nonces (perhaps with batching for overload) as a secure, rough version
of NTP. The problem is that it's another service to run and using a
TLS connection has firewall advantages.
Cheers
AGL
Anthony LaForge
Dec 12, 2014, 3:05:36 PM12/12/14
to Adam Langley, Marc-Andre Decoste, Chris Bentzel, Chris Palmer, Nicolas Zea, Adrienne Porter Felt, Hanno Böck, security-dev
Adding Marc-Andre, who did the implementation.
Kind Regards,
Anthony Laforge
Technical Program Manager
Mountain View, CA
Anthony Laforge
Technical Program Manager
Mountain View, CA
Marc-Andre Decoste
Dec 12, 2014, 3:20:50 PM12/12/14
to Anthony LaForge, Adam Langley, Chris Bentzel, Chris Palmer, Nicolas Zea, Adrienne Porter Felt, Hanno Böck, security-dev
The outdated build bubble check uses the network time tracker that was written by zea@ and hashimoto@... If this fails (for whatever reason), we fall back to OS current time...
Nicolas Zea
Dec 12, 2014, 5:22:38 PM12/12/14
to Marc-Andre Decoste, Anthony LaForge, Adam Langley, Chris Bentzel, Chris Palmer, Adrienne Porter Felt, Hanno Böck, security-dev
NetworkTimeTracker was implemented based on http://www.chromium.org/developers/design-documents/sane-time. It looks like the outdated build check is the only thing currently using the network time tracker. We were originally going to use it for history sync as well, but that was eventually dropped (from what I recall it involved needing to track two sets of timestamps for each navigation, which was too expensive). The network time tracker should still be working though (run with --vmodule="*network_time_tracker*"=1 to see the updates).
The source for the network time is a timestamp pulled either off a sync server response (for users with sync enabled) or from the finch server response. We then basically save the current base::TimeTicks time associated with that network time, and use that as a delta for future calculations.
The goal of all this isn't necessarily super-accurate network time, but "accurate enough", so we can have some confidence we're close to the "real" time. We don't attempt to account for bad clocks that introduce further discrepancies before we can acquire a new "trusted" time pair.
-Nicolas
Reply all
Reply to author
Forward
0 new messages