Aller au contenu principal

7. Considérations de sécurité

Étant donné que ce document spécifie uniquement un format pour représenter les dates et les heures, les problèmes de sécurité discutés ici se limitent à l'impact que les horloges non synchronisées ont sur les fonctionnalités de sécurité.

Risques de sécurité des horloges non synchronisées​

1. Échecs de validation de certificat​

Les horloges non synchronisées peuvent faire apparaître incorrectement les certificats comme expirés ou pas encore valides.

Exemple de risque :

Horloge client : 2002-07-14T10:00:00Z (1 jour en avance)
Validité du certificat :
  Not Before : 2002-07-15T00:00:00Z
  Not After :  2003-07-15T23:59:59Z

Résultat : Le client rejette un certificat valide ❌

Cas opposé :

Horloge client : 2003-07-20T10:00:00Z (2 ans en retard)
Validité du certificat :
  Not After : 2003-07-15T23:59:59Z (déjà expiré)

Résultat : Le client accepte un certificat expiré ⚠️ Risque de sécurité !

2. Contournement de vérification d'horodatage​

De nombreux protocoles de sécurité s'appuient sur des horodatages pour prévenir les attaques par rejeu.

Exemple d'attaque par rejeu :

Requête légitime interceptée par l'attaquant :
POST /transfer HTTP/1.1
Timestamp : 2002-07-15T10:00:00Z
Amount : $1000
Signature : valid_signature

Si l'horloge du serveur a 1 heure de retard, l'attaquant peut rejouer cette requête

3. Journaux d'audit non fiables​

Si les horodatages des journaux sont inexacts, l'audit de sécurité et l'analyse forensique deviennent impossibles ou peu fiables.

Scénario problématique :

Journaux du serveur A : 2002-07-15T10:00:00Z - Intrusion détectée
Journaux du serveur B : 2002-07-15T09:45:00Z - Connexion anormale (en fait plus tard que A, mais horloge en retard)

Impossible d'établir une chronologie d'attaque précise ❌

Recommandations de protection​

Utiliser NTP (Network Time Protocol)​

Tous les systèmes connectés à Internet devraient (SHOULD) utiliser NTP ou des protocoles similaires de synchronisation de l'heure.

Exemple de configuration NTP :

# Configurer le serveur NTP
ntpdate -u time.nist.gov

# Activer le démon ntpd
systemctl enable ntpd
systemctl start ntpd

# Vérifier l'état de synchronisation
ntpq -p

Tolérance d'horodatage​

Implémenter des fenêtres de tolérance raisonnables lors de la validation des horodatages.

Exemple d'implémentation :

def is_timestamp_valid(timestamp, max_age_seconds=300):
    """Vérifier que l'horodatage est dans une fenêtre temporelle acceptable"""
    now = datetime.now(timezone.utc)
    tolerance = timedelta(seconds=max_age_seconds)
    
    # Permettre ±5 minutes de décalage d'horloge
    if abs(now - timestamp) > tolerance:
        return False
    return True

Utiliser des sources de temps fiables​

Serveurs NTP publics recommandés :

time.nist.gov        (Institut national des normes et de la technologie des États-Unis)
time.google.com      (Google)
time.apple.com       (Apple)
time.cloudflare.com  (Cloudflare)
pool.ntp.org         (Projet NTP Pool)

Meilleures pratiques de validation de certificat​

# Considérer le décalage d'horloge lors de la validation des certificats
def verify_certificate(cert, clock_tolerance=timedelta(minutes=5)):
    now = datetime.now(timezone.utc)
    
    # Vérifier Not Before avec indulgence
    if now < (cert.not_before - clock_tolerance):
        raise CertificateNotYetValid()
    
    # Vérifier Not After strictement (sécurité d'abord)
    if now > cert.not_after:
        raise CertificateExpired()

Problèmes de sécurité liés au fuseau horaire​

1. Attaques par confusion de fuseau horaire​

Un traitement incohérent des fuseaux horaires peut conduire à des contournements de sécurité.

Exemple de vulnérabilité :

Soumission utilisateur : 2002-07-15T23:00:00-08:00
Système A analyse comme : 2002-07-16T07:00:00Z (correct)
Système B analyse comme : 2002-07-15T23:00:00Z (incorrect, ignore le fuseau horaire)

Si le système B est utilisé pour les décisions de contrôle d'accès, peut permettre un accès non autorisé

2. Limites de l'heure d'été​

Des ambiguïtés ou des problèmes de sécurité peuvent survenir lors des transitions vers l'heure d'été.

Moments à risque :

10 mars 2002 2:00 → 3:00 (saut d'1 heure)
Problème : 2:30 n'existe pas, comment gérer cet horodatage ?

3 novembre 2002 2:00 → 1:00 (répétition d'1 heure)
Problème : 1:30 se produit deux fois, lequel est correct ?

Solution RFC 3339 : Utiliser le décalage UTC pour éliminer l'ambiguïté :

✅ 2002-11-03T01:30:00-05:00  (EDT, avant la fin de l'heure d'été)
✅ 2002-11-03T01:30:00-04:00  (EST, après la fin de l'heure d'été)

Impact sécuritaire des secondes intercalaires​

Bien que rares, une mauvaise gestion des secondes intercalaires peut causer des problèmes.

Problèmes potentiels :

1990-12-31T23:59:60Z  (seconde intercalaire)

Si le système ne prend pas en charge les secondes intercalaires :
- Peut rejeter des horodatages valides
- Peut causer des erreurs de tri
- Peut causer des différences de temps d'1 seconde

Recommandation :

# Gérer les secondes intercalaires avec indulgence
def parse_timestamp(ts_string):
    try:
        return datetime.fromisoformat(ts_string)
    except ValueError as e:
        # Vérifier si c'est une seconde intercalaire (seconde est 60)
        if ':60Z' in ts_string or ':60+' in ts_string or ':60-' in ts_string:
            # Convertir 60 secondes en 00 secondes de la minute suivante
            ts_string = ts_string.replace(':60', ':59')
            return datetime.fromisoformat(ts_string) + timedelta(seconds=1)
        raise

Liste de contrôle de sécurité​

Lors de l'implémentation des horodatages RFC 3339, s'assurer de :

  • Synchroniser les horloges système avec NTP
  • Toujours utiliser l'UTC pour le stockage et la comparaison internes
  • Implémenter une tolérance raisonnable lors de la validation des horodatages
  • Gérer correctement les décalages de fuseau horaire
  • Enregistrer tous les événements de sécurité liés au temps
  • Auditer régulièrement la précision de l'horloge système
  • Considérer le décalage d'horloge dans la validation de certificat
  • Implémenter la protection contre les attaques par rejeu (nonce + horodatage)
  • Analyser avec indulgence, générer strictement
  • Tester les cas limites (secondes intercalaires, années bissextiles, fins de mois)

Principe clé : Ne pas s'appuyer sur des horodatages fournis par le client pour des décisions de sécurité critiques. Toujours utiliser des sources de temps fiables côté serveur.

Dernière mise à jour le