V0.6.3 — Sécurisation d'ONVIF

Modifié en V0.7.0 (#96) — Lancement
Avant : Clone obligatoire, build: seul
Après : Clone pour construire ; Site Ubuntu sans sources

Pourquoi

Depuis la 0.6.0, l’Administrateur règle une Caméra (Incrustations, Horloge) par ONVIF, mais ArgOS lui parlait en HTTP : qui écoutait le réseau des caméras capturait l’empreinte WS-Security du mot de passe (SHA-1, imposé par la norme, cassable hors ligne s’il est faible), lisait et modifiait les réglages au passage, et rien ne prouvait à ArgOS qu’il parlait à la bonne caméra. Avec l’authentification des Flux (0.6.2), c’était le dernier préalable à une installation sur de vraies caméras.

Ce qu’on peut faire maintenant

• Les Réglages d'une caméra qui propose HTTPS passent en HTTPS. ArgOS mémorise la clé de son certificat au premier contact et l'affiche (« Échange chiffré (HTTPS). Certificat de l'Appareil xxxx xxxx xxxx xxxx, mémorisé le … »), avec l'empreinte entière au survol. Rien n'est redemandé ensuite.

  

• Si la caméra présente une autre clé, ArgOS s'arrête avant d'envoyer ses identifiants. Il montre le certificat mémorisé et le certificat présenté, ainsi que les causes possibles. L'Administrateur tranche : Faire confiance au nouveau certificat, puis Confirmer la confiance.

  
  

• Une caméra déjà réglée en HTTPS qui ne répond plus qu'en HTTP n'est jamais réglée en clair. Oublier le certificat de cette caméra la fait repartir de zéro.

  

• Une caméra sans HTTPS n'est réglée en clair qu'après l'accord de l'Administrateur (Régler quand même en clair), une fois par Caméra. Un bandeau le rappelle ensuite, et Retirer l'accord ONVIF en clair revient en arrière.

  
  

• Clé, port et accord sont gardés quand on ne change que le mot de passe ou le chemin de l'URL. Ils repartent de zéro quand on change l'hôte.

• À l'ajout, un mot de passe de caméra de moins de 12 caractères est signalé sous les champs, sans bloquer l'ajout.

  

• Un refus de sécurité ne bloque que les Réglages de cette Caméra : le Live et l'état continuent.

  

• Chaque refus et chaque décision laisse une ligne dans les journaux de l'API (docker compose logs api | grep ONVIF), sans identifiant ni URL.

• Une caméra qui ne parle qu’un TLS ancien (1.0 / 1.1) reste réglée en HTTPS, signalée « TLS ancien » dans ses Réglages : un TLS faible avec une clé mémorisée vaut mieux que du clair.

• La Caméra simulée 2 répond désormais en ONVIF HTTPS sur 443 (HTTP gardé sur 8899) : on joue en dev le cas d’une caméra qui propose HTTPS ; la 4 reste en HTTP seul, pour l’ONVIF en clair.

• Les # NOSONAR laissés en 0.6.0 ne renvoient plus à cette version : il ne reste que des justifications définitives (repli HTTP consenti, SHA-1 de WS-Security, TLS ancien).

Historique des tickets

• PR : #85
• Commits : https://github.com/UlyssouLV/ArgOS/pull/85/commits

Tickets (Fixes) : #76 #77 #78 #79 #80 #81 #82 #83 #84

Hors périmètre

• Isolement du réseau des caméras (VLAN, sans internet), dans la procédure d’installation (0.7.2).
• Identifiants ONVIF distincts de ceux du Flux (Plus tard).
• RTSP vers les caméras (Flux, sonde, Détection, essai), qui reste en clair ; RTSPS.
• Passerelle chiffrante devant une caméra sans HTTPS.
• Recherche ONVIF par WS-Discovery ; réglages image et vidéo (0.6.4).
• Bug connu, trouvé aux tests humains : modifier l’URL d’une Caméra sans retaper son mot de passe enregistre *** comme mot de passe (#86, Plus tard).

Spec : https://github.com/UlyssouLV/ArgOS/blob/v0.6.3/docs/specs/v0.6.3-securisation-d-onvif.md

ADRs de cette version (liens sur ce tag, pas main) :

• https://github.com/UlyssouLV/ArgOS/blob/v0.6.3/docs/adr/0007-onvif-en-https-par-cle-memorisee.md

Issues laissées de côté (PR / spec hors périmètre) : #86.