9. Considérations de sécurité
9.1. Changement de ports
L'utilisation d'un service alternatif implique l'accès aux ressources d'une origine sur un port alternatif, au minimum. Par conséquent, un attaquant capable d'injecter des services alternatifs et d'écouter sur le port annoncé est capable de détourner une origine. Sur certains serveurs, il est normal que les utilisateurs puissent contrôler certaines pages personnelles disponibles sur un port partagé et également accepter des demandes sur des ports moins privilégiés.
Par exemple, un attaquant capable d'ajouter des champs d'en-tête de réponse HTTP à certaines pages peut rediriger le trafic pour toute une origine vers un port différent sur le même hôte en utilisant le champ d'en-tête Alt-Svc ; si ce port est sous le contrôle de l'attaquant, il peut ainsi se faire passer pour le serveur HTTP.
Ce risque est atténué par les exigences de la Section 2.1.
Sur les serveurs, ce risque peut également être réduit en restreignant la capacité d'annoncer des services alternatifs, et en restreignant qui peut ouvrir un port pour l'écoute sur cet hôte.
9.2. Changement d'hôtes
Lorsque l'hôte est modifié en raison de l'utilisation d'un service alternatif, cela présente une opportunité pour les attaquants de détourner la communication vers une origine.
Par exemple, si un attaquant peut convaincre un agent utilisateur d'envoyer tout le trafic pour "innocent.example.org" vers "evil.example.com" en l'associant avec succès en tant que service alternatif, il peut se faire passer pour cette origine. Cela peut être fait localement (voir les atténuations dans la Section 9.1) ou à distance (par exemple, par un intermédiaire en tant qu'attaque de l'homme du milieu).
C'est la raison de l'exigence de la Section 2.1 selon laquelle les clients doivent avoir des assurances raisonnables que le service alternatif est sous le contrôle de et valide pour l'ensemble de l'origine ; par exemple, la présentation d'un certificat pour l'origine prouve que le service alternatif est autorisé à servir le trafic pour l'origine.
Notez que cette assurance n'est aussi forte que la méthode utilisée pour authentifier le service alternatif. En particulier, lorsque l'authentification TLS est utilisée pour ce faire, il existe des exploits bien connus pour faire apparaître le certificat d'un attaquant comme légitime.
Les services alternatifs pourraient être utilisés pour faire persister une telle attaque. Par exemple, un intermédiaire pourrait intercepter la communication protégée par TLS vers une cible, puis diriger tout le trafic vers un service alternatif avec une longue durée de fraîcheur afin que l'agent utilisateur continue de diriger le trafic vers l'attaquant même lorsqu'il n'utilise pas l'intermédiaire.
Les implémentations DOIVENT effectuer toute validation d'épinglage de certificat (comme [RFC7469]) sur les services alternatifs tout comme elles le feraient sur les connexions directes à l'origine. Les implémentations peuvent également choisir d'ajouter d'autres exigences concernant les certificats acceptables pour les services alternatifs.
9.3. Changement de protocoles
Lorsque le protocole ALPN est modifié en raison de l'utilisation d'un service alternatif, les propriétés de sécurité de la nouvelle connexion à l'origine peuvent être différentes de celles de la connexion "normale" à l'origine, car l'identifiant de protocole lui-même l'implique.
Par exemple, si un URI "https://" a un protocole annoncé qui n'utilise pas une forme de chiffrement de bout en bout (très probablement TLS), cela viole les attentes de sécurité que le schéma URI implique. Par conséquent, les clients ne peuvent pas utiliser les services alternatifs aveuglément, mais doivent plutôt évaluer l'option ou les options présentées pour s'assurer que les exigences de sécurité et les attentes des spécifications, des implémentations et des utilisateurs finaux sont satisfaites.
9.4. Suivi des clients utilisant des services alternatifs
Le choix d'un service alternatif implique de se connecter à un nouveau nom d'hôte fourni par le serveur. En utilisant des noms uniques, les serveurs pourraient concevablement suivre les demandes des clients. Un tel suivi pourrait suivre les utilisateurs à travers plusieurs réseaux, lorsque le drapeau "persist" est utilisé.
Les clients qui souhaitent empêcher la corrélation des demandes peuvent décider de ne pas utiliser de services alternatifs pour plusieurs demandes qui ne seraient autrement pas autorisées à être corrélées.
Dans un agent utilisateur, toute information de service alternatif DOIT être supprimée lorsque les données spécifiques à l'origine sont effacées (généralement, lorsque les cookies [RFC6265] sont effacés).
9.5. Confusion concernant le schéma de demande
Certaines applications HTTP côté serveur font des hypothèses sur la sécurité basée sur le contexte de connexion ; par exemple, assimiler le fait d'être servi sur le port 443 à l'utilisation d'un URI "https://" et aux diverses propriétés de sécurité que cela implique.
Cela affecte non seulement les propriétés de sécurité de la connexion elle-même, mais aussi l'état du client à l'autre extrémité de celle-ci ; par exemple, un navigateur Web traite les URI "https://" différemment des URI "http://" de bien des façons, pas seulement à des fins de gestion de protocole.
Étant donné que l'une des utilisations des Services Alternatifs est de permettre la migration d'une connexion vers un protocole et un port différents, ces applications peuvent devenir confuses quant aux propriétés de sécurité d'une connexion donnée, envoyant des informations (par exemple, des cookies et du contenu) destinées à un contexte sécurisé (tel qu'un URI "https://") à un client qui ne le traite pas comme tel.
Ce risque peut être atténué dans les serveurs en utilisant le schéma URI explicitement transporté par le protocole (tel que ":scheme" dans HTTP/2 ou la "forme absolue" de la cible de la demande dans HTTP/1.1) comme indication du contexte de sécurité, au lieu d'autres propriétés de connexion ([RFC7540], Section 8.1.2.3 et [RFC7230], Section 5.3.2).
Lorsque le protocole ne transporte pas explicitement le schéma (comme c'est généralement le cas pour HTTP/1.1 sur TLS), les serveurs peuvent atténuer ce risque soit en supposant que toutes les demandes ont un contexte non sécurisé, soit en s'abstenant d'annoncer des services alternatifs pour des schémas non sécurisés (par exemple, HTTP).