Light

Episode #936 Quiz

When Heuristics Backfire
Date: 2023-08-22 | Length: 2 hrs | Episode page at twit.tv

About this episode

This episode covered real-world security failures: defective SanDisk/Western Digital SSD firmware corrupting data, YouTube “made for kids” tracking violating COPPA expectations, crypto wallet MPC/TSS flaws enabling theft, Chrome’s HTTPS-first upgrades and extension warnings, WinRAR RCE fixes, and Microsoft’s Secure Time Seeding heuristic, which misreads random TLS timestamp data and skews clocks.

Your name and email are stored only in your browser local storage for convenience. They are not retained server-side.

NameEmail

Question 1: What change did Microsoft make in 2016 that later proved able to reset Windows clocks to wildly incorrect values?

Question 1

What change did Microsoft make in 2016 that later proved able to reset Windows clocks to wildly incorrect values?

A network time fallback that queried public NTP pools without authentication A certificate-renewal scheduler that adjusted time when local certs expired A hardware RTC calibration routine that sampled battery-backed CMOS drift A heuristic time-seeding feature derived from SSL handshake metadata

Question 2: Why did the Windows Secure Time Seeding heuristic sometimes become "highly confident" about a wrong time?

Question 2

Why did the Windows Secure Time Seeding heuristic sometimes become "highly confident" about a wrong time?

It merged randomized ServerUnixTime values with OCSP validity data It used the earliest certificate issuance date as the system clock It averaged timestamps from all local application logs It trusted only the most recent NTP response from a domain controller

Question 3: What did Microsoft recommend to affected administrators as the practical mitigation for Secure Time Seeding problems?

Question 3

What did Microsoft recommend to affected administrators as the practical mitigation for Secure Time Seeding problems?

Disable Secure Time Seeding when NTP time is already reliable Increase the confidence threshold so more handshakes are required Replace SSL certificates with shorter-lived keys on all servers Force all servers to synchronize only with remote OCSP responders

Question 4: What specific OpenSSL behavior did the episode identify as the source of the misleading time data consumed by STS?

Question 4

What specific OpenSSL behavior did the episode identify as the source of the misleading time data consumed by STS?

It omitted the certificate chain from every handshake It returned the client’s local time to the server in cleartext It populated the ServerUnixTime field with random data It encrypted the timestamp with an unsupported cipher suite

Question 5: How did Steve say STS should have been protected against the bad conclusions produced by its heuristic?

Question 5

How did Steve say STS should have been protected against the bad conclusions produced by its heuristic?

By applying sanity checks to reject ridiculous or impossible results By trusting only the first SSL handshake observed on each server By removing all heuristic logic and using only manual operator input By refusing to use any certificate-related metadata in the calculation

Cancel

My Data//Security & Privacy//Clear Local Data

© 2026 Ken ArmstrongSecurity Now™ is a trademark of TWiT LLC. All trademarks and copyrights of the Security Now podcast are respected and reserved to their respective holders.
This is a hobby project made with love and admiration for what Steve Gibson and Leo Laporte have built over 20 years.