MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

STS - Secure Time Seeding

Eine aktuelle Uhrzeit ist wichtig, z.B. weil Zugriffstokens und Zertifikate nur einen gewissen Gültigkeitszeitraum haben und auch Zeitstempel in Messagetrackinglogs, Eventlogs und SIEM-Logs möglichst zutreffend sein sollten. Daher sorgt Windows Active Directory schon seit Windows 2000 mit einem eingebauten NTP-Client/Server-Modell (Zeitsynchronisation in Netzwerken) für einen korrekte synchrone Uhrzeit. Für hochgenauer Zeiten, deren Schwerpunkt weniger auf der korrekten Zeit sondern mehr auf der synchronen Zeit liegt, gibt es mit dem PTP - Precision Time Protocol. Da kann es schon verwirren, das es mit STS noch ein drittes Protokoll gibt.

Kurzform: Windows 2016/Windows 10 Nov 2015 und neuer nutzen manchmal wohl einen Zeitstempel eines TLS-Handshare zum Uhrzeitabgleich und das ist keine gute Idee. Wer ein valides NTP-Setup hat, sollte STS mittels Registry-Key abschalten.

STS - Zeit per TLS-Handshake

Der Einsatz von PTP - Precision Time Protocol macht in normalen Netzwerken keinen Sinn, denn kaum jemand braucht eine Genauigkeit von wenigen Millisekunden oder noch weniger. Für die meisten Netzwerk-Clients reicht es, wenn von allen die korrekte Zeit genutzt wird und die Abweichung zwischen den verschiedenen Clients im Bereich von wenigen Sekunden liegt. auch per NTP lassen sich in einem Netzwerk Genauigkeiten von wenigen Millisekunden erreichen. Messen Sie einfach die Round Trip Time des Clients zum NTP-Server. Das ist die Hälfte davon die theoretisch maximale Abweichung. Selbst über das Internet sind Latenzzeiten von <100 ms auf dem gleichen Kontinent normal und mit max. 50ms Unterschied haben die meisten Systeme kein Problem.

Die Funktion von NTP basiert auf einfachen UDP-Pakete, des Clients an einen NTP-Server und der passenden Antwort. Das ist insofern problemtisch, da die Pakete weder verschlüsselt noch gegen Veränderungen geschützt sind. Nun muss die Zeit natürlich nicht "geschützt" werden aber als Client sollten Sie schon wissen, ob sie dem Zeitserver vertrauen können. Manchmal ist aber auch UDP gesperrt.

Microsoft ist mit Windows 10 (Nov 2015) und Windows 2016 auf die Idee gekommen, eine andere Quelle für die Uhrzeit zu nutzen. Wenn ein Client eine TLS-Verbindung z.B. zu einem Webserver aufbaut, dann wird im Rahmen des TLS-Handshake eine Zeit vom Client zum Server übertragen.


Quelle: RFC2246 The TLS Protocol Version 1.0  ietf.org/rfc/rfc2246.txt oder https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.1.2

Das Feld wurde mit SSL3 eingeführt und über TLS 1.0 bis 1.2 weiter unverändert in der RFC mitgeführt. Allerdings die Struktur mit 32bit Unix-Zeit und 28 Byte (=32 Bytes) nie für einen Zeitabgleich genutzt, sondern eigentlich nur für eine "Zufallszahl", die mit der Uhrzeit auch bei schlechten "Zufallszahlengeneratoren" eine Veränderung liefern soll.

Wenn Sie aber z.B. mit Wireshark einen TLS-Aufbau anschauen, dann sehen Sie, dass bei TLS 1.2 die Versionsangabe schon depreciated ist aber das darunter liegende "RANDOM"-Feld gar nicht mehr decodiert wird.

Auch bei der Antwort des Server (Server Hello)  enthält laut Wireshark keine Zeit mehr.

 

Als Gegenprobe habe ich dann noch einmal eine TLS-Verbindung per PowerShell zur WebUI eines älteren Audiocodes 420HD-Telefons gestartet:

Invoke-Webrequest -Method POST "https://192.168.178.212"

Im "Client Hello" sehen wir hier eine Uhrzeit, die natürlich gar nicht passt. Schon das Jahr 2084 ist definitiv ungültig. 

 

Aber auch die Rückantwort des Telefons, welches eigentlich intern die richtige Uhrzeit per NTP bekommen hat. ist mit dem Jahr 2076 auch weit in der Zukunft.

Mit jeder weiteren Abfrage haben sich die Zeiten weiter sprunghaft verändert.

Wenn hier nun mein Client bei Zugriff per TLS auf das Telefon wirklich die gelieferte Zeit "übernehmen" würde, dann sind Probleme sicher.

Die Zeit im TLS-Handshake hat nichts damit zu tun, wie die Endpunkte die Gültigkeit der Zertifikate prüfen. Das wäre ja auch kontraproduktiv, wenn ein Server nicht nur ein veraltetes Zertifikat sondern zugleich die passende Zeit mitliefern könnte.

Bitte schalten Sie STS ab!

Wenn aber STS eh nicht mehr da ist, warum muss ich als Admin dann vielleicht dennoch aufpassen? Es gibt berichte, dass Server und Client manchmal die Zeit wechseln und größere Sprünge vollziehen. Das ist natürlich nicht nur störend sondern auch gefährlich für Systeme, die auf einer halbwegs akkuraten Zeit basieren, z.B.: AD-Replikation oder Exchange Cluster. Wenn STS auf einem Server aktiv ist, dann kann es sein, dass der W32TIME-Dienst bei einer TLS-Verbindung zu einem falsch laufenden Server einen entsprechenden Sprung hinlegt. Das könnte auch für Angreifer zumindest Störpotential sein, wenn ich einen Server mit falscher Zeit aufsetze und dann dem Client zu einer TLS-Verbindung provozieren kann.

Auch Microsoft empfiehlt mittlerweile die Abschaltung der Funktion  

Auch im Microsoft 365-AdminCenter gibt es im Mai 2025 eine entsprechende Meldung:

MC1085489: Take action: Disable Secure Time Seeding (STS) in Windows Server 2016 and later | May 30
Microsoft recommends disabling the Secure Time Seeding (STS) in Windows Server 2016, Windows Server 2019, Windows Server 2022, and Windows Server 2025 due to reported timekeeping issues.Additionally, organizations should review and ensure proper time synchronization and monitoring on critical servers.When will this happen:Microsoft recommends applying this disablement as soon as possible.

Eine dankbare Quelle zur Auswertung ist der Event "260" im Eventlog "Microsoft\Windows\Time-Service\Operational.

Suchen Sie hier einfach nach "UtilizeSslTimeData". Wenn der Wert auf "1" steht, dann ist die Funktion beim Client noch aktiv.

Die Funktion ist über die Registrierung abschaltbar und damit sowohl per Kommandozeile, PowerShell oder Gruppenrichtlinie steuerbar

reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config" /v "UtilizeSslTimeData" /t REG_DWORD /d 0 /f

Oder per REG-Datei

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
"UtilizeSslTimeData"=dword:00000000


Quelle: Windows Time service tools and settings
https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings?tabs=config#windows-time-registry-reference

Einschätzung

Ich bin etwas verwundert, warum Microsoft den Default nicht einfach angepasst hat. Sie haben mit Windows 10 15H2/Windows 2016 die Funktion ja auch ohne große Ankündigung ins Betriebssystem gebracht. Die meisten Firmen werden ja wohl NTP konfiguriert haben oder die Systeme holen sich die Zeit per NTP von time.windows.com oder einer anderen Quelle.

Auch die Information über ein Blog und im Microsoft 365 Admin Portal wird ganz viele Administratoren vermutlich nicht erreichen. Ich kann nur hoffen, dass nur wenige Server auf diese Probleme stoßen oder davon betroffen sind.

Allerdings finde ich es schon befremdlich, warum Microsoft im Jahr 2015 überhaupt diese STS-Funktion ins Windows Betriebssystem aufgenommen hat. Dann hätte ich auch gleich eine Abfrage der Zeit per HTTP von einem WebServer implementieren können.

(Invoke-WebRequest -Uri https://www.microsoft.com).headers.date

Dessen Zeit ist  vermutlich nicht schlechter aber würde man dennoch nicht machen. Seit Windows 2000 funktioniert die Zeitsynchronisation mittels NTP bei den meisten Firmen ohne Problem und sie müssen nur den PDC-Emulator mit einer aktuellen Zeiten versorgen. Viele Firmen nutzen dazu einfach NTP aus dem Internet oder eine Funkuhr.

Weitere Links