ANNEXE 2
IMPLÉMENTATION ET RESTRICTION D'ACCÈS DE L'API
1. Spécifications de l'implémentation de l'API
- l'API écoute uniquement en HTTPS, sur le port TCP 443 ou sur le port spécifié par l'opérateur dans l'URL. L'API ne répond pas sur une connexion HTTP sans couche de chiffrement TLS ;
- la connexion HTTPS utilisée pour l'API doit utiliser TLS 1.2 et/ou une version plus récente ;
- le certificat TLS est valide, il est donc nécessaire de régulièrement pousser un nouveau certificat, pour ne pas disposer uniquement d'un certificat expiré ;
- l'API écoute uniquement sur le LAN. L'API ne répond pas aux requêtes qui pourraient provenir d'Internet ;
- le format de sortie de l'API est un fichier JSON (JavaScript Object Notation) ;
- l'API est activée par défaut sans intervention de l'utilisateur. L'opérateur peut, de manière facultative, proposer une option dans l'interface de la box pour désactiver ou paramétrer l'API ;
- l'API est joignable par un (ou deux) nom(s) de domaine(s) par opérateur (un opérateur correspond à un AS ou " système autonome "). Il est recommandé que ce(s) nom(s) de domaine(s) soi(en)t résolu(s) par le DNS public, afin de ne pas bloquer les navigateurs utilisant DNS over HTTPS ou un serveur DNS tiers (exemple : adresse IP unique de loopback qui permet de joindre l'API, quel que soit l'IP de la box sur le LAN) ;
- l'opérateur peut restreindre momentanément l'accès à l'API, en cas de révélation d'une faille de sécurité ou d'un bug majeur sur la box. L'opérateur informe alors l'ARCEP sans délai des problèmes, ainsi que de la progression dans la correction de ceux-ci ;
- d'éventuelles évolutions fonctionnelles de l'API se feront en concertation avec les acteurs.
2. Restriction d'accès via CORS
Le " cross-origin resource sharing " (CORS) ou " partage des ressources entre origines multiples " (en français, moins utilisé) est un mécanisme qui consiste à ajouter des en-têtes HTTP afin de permettre à une application web d'accéder à des ressources d'un serveur situé sur une autre origine que le site courant. Une application web réalise une requête HTTP multi-origine (cross-origin) lorsqu'elle demande une ressource provenant d'un domaine, d'un protocole ou d'un port différent de ceux utilisés pour la page courante.
Techniquement, le nom de domaine de l'outil de mesure de la qualité de service internet doit être présent dans le champ d'en-tête HTTP nommé " Access-Control-Allow-Origin " envoyé par le serveur web intégré dans la box. Cela permet de limiter l'accès de l'API aux seuls sites web autorisés : si le nom de domaine n'est pas présent, le navigateur web bloque l'accès à l'API.
Le World Wide Web Consortium explique cependant qu'il n'est pas possible d'intégrer plusieurs nom de domaine dans un même en-tête : " Note that it is not possible to grant access to multiple specific sites, nor use a partial wildcard match. It is also not possible to specify more than one Access-Control-Allow-Origin header. " (8).
Pour pouvoir donner l'accès à plusieurs outils, il convient de n'envoyer qu'un champ d'en-tête HTTP nommé " Access-Control-Allow-Origin " qui contienne le nom de domaine appelant, s'il est autorisé. La liste des noms de domaines autorisés est alors conservée dans le serveur web et n'est pas envoyée en totalité : seul le " Access-Control-Allow-Origin " correspondant à la source est envoyé, sous réserve que la source soit dans la liste des noms de domaines autorisés. Si la source n'est pas autorisée, le serveur web ne renvoie aucun champ d'en-tête HTTP nommé " Access-Control-Allow-Origin " et le navigateur web bloque la requête.
3. Restriction d'accès via OAuth 2.0 avec un token à validité de 15 minutes
Le token est un identifiant utilisé par un outil pour accéder à l'API valable 15 minutes. Chaque outil à son propre token, permettant ainsi de retirer les accès à un outil sans impacter les autres.
La fourniture du token informe l'API que le porteur du token a été autorisé à accéder à l'API et permet d'associer à chaque accédant un champ d'action.
Il est envisagé d'avoir un schéma d'autorisation serveur à serveur pour obtenir le token d'accès, c'est-à-dire que l'outil de mesure obtiendrait le token auprès des opérateurs sans action nécessaire de l'utilisateur. L'outil utiliserait alors ce token pour accéder à l'API.
Ce mécanisme nécessite la mise en place d'une infrastructure à clés publiques (PKI (9)) pour renouveler les tokens et transférer ces informations entre acteurs de manière sécurisée, en utilisant de la cryptographie asymétrique.
Le serveur d'autorisation OAuth 2.0 peut être directement sur l'IAD ou en central, selon le choix de l'opérateur et les outils de mesure de la qualité de service internet doivent savoir gérer les deux cas.
Les opérateurs ont la possibilité de limiter le nombre de tokens signés par outil.
(8) https://www.w3.org/wiki/CORS_Enabled.
(9) Public Key Infrastructure.