Zum Hauptinhalt springen

7. Sicherheitserwägungen

Da dieses Dokument nur ein Format zur Darstellung von Datum und Uhrzeit spezifiziert, beschränken sich die hier diskutierten Sicherheitsprobleme auf die Auswirkungen, die unsynchronisierte Uhren auf Sicherheitsfunktionen haben.

Sicherheitsrisiken unsynchronisierter Uhren​

1. Zertifikatsvalidierungsfehler​

Unsynchronisierte Uhren können dazu führen, dass Zertifikate fälschlicherweise als abgelaufen oder noch nicht gültig erscheinen.

Risikobeispiel:

Client-Uhr: 2002-07-14T10:00:00Z (1 Tag voraus)
Zertifikatsgültigkeit:
  Not Before: 2002-07-15T00:00:00Z
  Not After:  2003-07-15T23:59:59Z

Ergebnis: Client lehnt gültiges Zertifikat ab ❌

Umgekehrter Fall:

Client-Uhr: 2003-07-20T10:00:00Z (2 Jahre zurück)
Zertifikatsgültigkeit:
  Not After: 2003-07-15T23:59:59Z (bereits abgelaufen)

Ergebnis: Client akzeptiert abgelaufenes Zertifikat ⚠️ Sicherheitsrisiko!

2. Zeitstempel-Verifikations-Bypass​

Viele Sicherheitsprotokolle verlassen sich auf Zeitstempel, um Replay-Angriffe zu verhindern.

Replay-Angriff Beispiel:

Legitime Anfrage, vom Angreifer abgefangen:
POST /transfer HTTP/1.1
Timestamp: 2002-07-15T10:00:00Z
Amount: $1000
Signature: valid_signature

Wenn die Server-Uhr 1 Stunde zurück ist, kann der Angreifer diese Anfrage wiederholen

3. Unzuverlässige Audit-Logs​

Wenn Log-Zeitstempel ungenau sind, werden Sicherheitsaudit und forensische Analyse unmöglich oder unzuverlässig.

Problemszenario:

Server A Logs: 2002-07-15T10:00:00Z - Einbruch erkannt
Server B Logs: 2002-07-15T09:45:00Z - Abnormale Anmeldung (tatsächlich später als A, aber Uhr ist zurück)

Kann keine genaue Angriffs-Zeitleiste erstellen ❌

Schutzempfehlungen​

Verwenden Sie NTP (Network Time Protocol)​

Alle mit dem Internet verbundenen Systeme sollten (SHOULD) NTP oder ähnliche Zeitsynchronisationsprotokolle verwenden.

NTP-Konfigurationsbeispiel:

# NTP-Server konfigurieren
ntpdate -u time.nist.gov

# ntpd-Daemon aktivieren
systemctl enable ntpd
systemctl start ntpd

# Synchronisationsstatus überprüfen
ntpq -p

Zeitstempel-Toleranz​

Implementieren Sie vernünftige Toleranzfenster bei der Validierung von Zeitstempeln.

Implementierungsbeispiel:

def is_timestamp_valid(timestamp, max_age_seconds=300):
    """Überprüfen, ob Zeitstempel innerhalb akzeptabler Zeitfenster liegt"""
    now = datetime.now(timezone.utc)
    tolerance = timedelta(seconds=max_age_seconds)
    
    # ±5 Minuten Uhrenabweichung erlauben
    if abs(now - timestamp) > tolerance:
        return False
    return True

Verwenden Sie vertrauenswürdige Zeitquellen​

Empfohlene öffentliche NTP-Server:

time.nist.gov        (US-amerikanisches Nationales Institut für Standards und Technologie)
time.google.com      (Google)
time.apple.com       (Apple)
time.cloudflare.com  (Cloudflare)
pool.ntp.org         (NTP Pool Projekt)

Beste Praktiken zur Zertifikatsvalidierung​

# Uhrenabweichung bei der Zertifikatsvalidierung berücksichtigen
def verify_certificate(cert, clock_tolerance=timedelta(minutes=5)):
    now = datetime.now(timezone.utc)
    
    # Not Before nachsichtig prüfen
    if now < (cert.not_before - clock_tolerance):
        raise CertificateNotYetValid()
    
    # Not After streng prüfen (Sicherheit zuerst)
    if now > cert.not_after:
        raise CertificateExpired()

Zeitzonen-bezogene Sicherheitsprobleme​

1. Zeitzonen-Verwirrungsangriffe​

Inkonsistente Zeitzonenbehandlung kann zu Sicherheitsumgehungen führen.

Schwachstellenbeispiel:

Benutzereinreichung: 2002-07-15T23:00:00-08:00
System A parst als: 2002-07-16T07:00:00Z (korrekt)
System B parst als: 2002-07-15T23:00:00Z (inkorrekt, ignoriert Zeitzone)

Wenn System B für Zugriffskontrollentscheidungen verwendet wird, kann unbefugter Zugriff erlaubt werden

2. Sommerzeit-Grenzen​

Mehrdeutigkeiten oder Sicherheitsprobleme können bei Sommerzeitübergängen auftreten.

Risiko-Momente:

10. März 2002 2:00 → 3:00 (1 Stunde überspringen)
Problem: 2:30 existiert nicht, wie soll dieser Zeitstempel behandelt werden?

3. November 2002 2:00 → 1:00 (1 Stunde wiederholen)
Problem: 1:30 tritt zweimal auf, welches ist korrekt?

RFC 3339 Lösung: UTC-Offset verwenden, um Mehrdeutigkeit zu beseitigen:

✅ 2002-11-03T01:30:00-05:00  (EDT, vor Ende der Sommerzeit)
✅ 2002-11-03T01:30:00-04:00  (EST, nach Ende der Sommerzeit)

Sicherheitsauswirkungen von Schaltsekunden​

Obwohl selten, kann eine unsachgemäße Behandlung von Schaltsekunden Probleme verursachen.

Potenzielle Probleme:

1990-12-31T23:59:60Z  (Schaltsekunde)

Wenn das System Schaltsekunden nicht unterstützt:
- Kann gültige Zeitstempel ablehnen
- Kann Sortierfehler verursachen
- Kann 1-Sekunden-Zeitunterschiede verursachen

Empfehlung:

# Schaltsekunden nachsichtig behandeln
def parse_timestamp(ts_string):
    try:
        return datetime.fromisoformat(ts_string)
    except ValueError as e:
        # Prüfen, ob es eine Schaltsekunde ist (Sekunde ist 60)
        if ':60Z' in ts_string or ':60+' in ts_string or ':60-' in ts_string:
            # 60 Sekunden in 00 Sekunden der nächsten Minute konvertieren
            ts_string = ts_string.replace(':60', ':59')
            return datetime.fromisoformat(ts_string) + timedelta(seconds=1)
        raise

Sicherheits-Checkliste​

Bei der Implementierung von RFC 3339-Zeitstempeln sicherstellen:

  • Systemuhren mit NTP synchronisieren
  • Immer UTC für interne Speicherung und Vergleich verwenden
  • Angemessene Toleranz bei der Validierung von Zeitstempeln implementieren
  • Zeitzonen-Offsets korrekt behandeln
  • Alle zeitbezogenen Sicherheitsereignisse protokollieren
  • Systemuhr-Genauigkeit regelmäßig überprüfen
  • Uhrenabweichung bei Zertifikatsvalidierung berücksichtigen
  • Replay-Angriffs-Schutz implementieren (Nonce + Zeitstempel)
  • Nachsichtig parsen, streng generieren
  • Grenzfälle testen (Schaltsekunden, Schaltjahre, Monatsenden)

Schlüsselprinzip: Verlassen Sie sich nicht auf vom Client bereitgestellte Zeitstempel für kritische Sicherheitsentscheidungen. Verwenden Sie immer serverseitige vertrauenswürdige Zeitquellen.

Letztes Update am