Résumé

  • ALPN a placé le choix du protocole applicatif dans le handshake TLS afin d’éviter un aller-retour supplémentaire lorsque plusieurs protocoles partagent le même port.
  • Le client présente une liste ordonnée, mais le serveur choisit un seul identifiant dans l’intersection selon sa propre préférence. Sans intersection, l’alerte fatale est le résultat correct.
  • Le choix vaut pour une connexion et non pour la session TLS reprise. Un ticket, un certificat ou un identifiant enregistré ne constituent ni une autorisation applicative ni une preuve de déploiement.

Une reprise pouvait aboutir sur une préférence différente

Une équipe déploie HTTP/2 progressivement. La moitié des nœuds préfère h2, l’autre conserve http/1.1 en tête. Un client établit une première connexion, reçoit h2 et conserve un ticket de session. Lorsqu’il revient, le répartiteur l’envoie vers un autre nœud. Le ticket est accepté, mais la préférence locale n’est plus la même.

Si le protocole applicatif appartenait au ticket, la reprise devrait imposer l’ancien choix au nouveau nœud. Si le protocole appartenait simplement au port 443, les deux choix seraient invisibles. ALPN retient une troisième solution : le ticket peut contribuer à la reprise cryptographique tandis que la nouvelle connexion négocie de nouveau sa grammaire.

RFC 7301 dit que l’extension établit une propriété de la connexion, non de la session. Lorsqu’une session ou un ticket est repris, le contenu ALPN précédent n’a plus d’autorité ; seules les valeurs du nouveau handshake comptent.

Cette phrase transforme un détail d’implémentation en frontière d’exploitation. Une ferme peut changer de préférence, retirer un protocole ou révéler une divergence sans falsifier l’histoire du ticket. La continuité cryptographique n’efface pas la pluralité des nœuds qui prennent la décision présente.

Un port commun avait besoin d’un choix explicite

Le numéro de port a longtemps servi d’indice sur la grammaire située au-dessus du transport. TLS a permis à de nombreuses applications de partager une infrastructure protégée, notamment le port 443. L’indice devenait insuffisant au moment même où ce partage rendait l’établissement plus efficace.

Une négociation après TLS aurait ajouté un aller-retour. Une détection par les premiers octets aurait demandé à un serveur de faire parler plusieurs parseurs sur le même flux, avec des erreurs tardives et des risques de confusion. ALPN insère donc l’offre et la réponse dans l’échange déjà nécessaire à TLS.

L’histoire de transition racontée par RFC 8170 rattache ce besoin à HTTP/2. Pour la variante protégée, ALPN évitait un aller-retour ; Upgrade restait le mécanisme de la variante non protégée. Le texte observe ensuite qu’ALPN est devenu la voie principale pour négocier les versions HTTP futures.

Il ne s’agit pas du même moment constitutionnel qu’un 101 Switching Protocols. Upgrade commence en HTTP, obtient une réponse applicative puis change la grammaire d’une connexion déjà ouverte. ALPN choisit avant les données applicatives, dans le handshake qui crée la connexion protégée.

Deux ordres de préférence, une seule intersection

La liste du client contient des chaînes d’octets opaques, non vides et non tronquées. Elle est classée selon la préférence du client. Ce classement ne donne pas au premier élément un droit sur le serveur.

Le serveur possède son propre ensemble et son propre ordre. RFC 7301 lui demande de choisir le protocole qu’il préfère parmi ceux également offerts. L’intersection limite son pouvoir : il ne peut pas annoncer une grammaire que le client n’a pas déclarée. Mais, à l’intérieur de cette intersection, sa politique locale reste déterminante.

Cette asymétrie explique pourquoi une mesure agrégée peut tromper. « Le client offrait h2 » ne prouve pas que le serveur devait le choisir. « Le serveur supporte h2 » ne prouve pas que ce client l’avait offert. Il faut conserver les deux listes pertinentes, leur ordre, la version de politique et l’instance qui a répondu.

La réponse ne contient qu’un protocole. Une fois annoncé, il est définitif pour la connexion. Le serveur ne peut pas nommer une grammaire puis en utiliser une autre. Le choix n’est donc pas une publicité de capacité générale ; c’est un engagement sur la façon d’interpréter le flux qui va suivre.

L’absence d’intersection devait rester un échec

Quand aucune valeur n’est commune, le serveur envoie l’alerte fatale no_application_protocol. Une stratégie de disponibilité pourrait être tentée de choisir silencieusement un défaut. Elle remplacerait cependant une panne visible par une divergence de parseurs.

Le client saurait ce qu’il a proposé. Il ne saurait pas si l’extension a été ignorée, si un ancien serveur a répondu ou si un intermédiaire a changé le chemin. Le serveur, lui, pourrait attendre des octets selon une grammaire que le client n’a jamais acceptée. Le chiffrement de la connexion ne réconcilie pas ces attentes.

Les recommandations modernes de RFC 9325 exigent la prise en charge d’ALPN dans les implémentations TLS et insistent sur l’application stricte de la liste offerte. Elles relient cette discipline aux attaques interprotocoles : des données valides dans une grammaire peuvent produire un effet inattendu si un autre service les interprète.

ALPN n’autorise pas la requête et ne garantit pas que le programme choisi est sûr. Il empêche plus modestement le serveur de prétendre qu’un protocole non offert était un accord.

La visibilité a changé sans devenir absolue

Dans la conception TLS de 2014, le client présentait sa liste dans ClientHello et le serveur plaçait son choix dans ServerHello. RFC 7301 assumait que cette indication restait visible, notamment pour des équipements différenciant les flux lorsque le port ne suffisait plus. Le document avertissait aussi que des identifiants trop révélateurs pouvaient faciliter le profilage.

TLS 1.3, RFC 8446, a déplacé la réponse du serveur vers EncryptedExtensions. Ce message est protégé par les clés de trafic du handshake. L’offre du client demeure dans le ClientHello ordinaire.

Une équipe ne doit donc pas résumer la situation par « ALPN est en clair » ou « ALPN est caché ». Elle doit noter la version TLS, le côté observé et la phase du handshake. La sélection du serveur a gagné une protection dans TLS 1.3 ; la liste initiale du client ne devient pas secrète par cette seule évolution.

HTTP/2 séparait sélection et confirmation

RFC 9113 attribue h2 à HTTP/2 sur TLS et impose ALPN. L’identifiant h2c décrit au contraire une variante sans TLS ; il ne doit pas être proposé ou choisi dans ALPN sur TLS.

Après la négociation TLS, les deux extrémités doivent encore envoyer une préface HTTP/2. ALPN choisit la grammaire autorisée ; la préface confirme que les octets suivants l’emploient et installe les premiers paramètres. Un h2 sélectionné suivi d’une préface invalide reste une erreur de protocole. Une préface observée sans trace du handshake ne prouve pas que le pair avait accepté h2 sous TLS.

Cette double preuve est utile pendant un déploiement hétérogène. Le compteur de sélections décrit la politique de handshake. Les erreurs de préface décrivent l’entrée effective dans l’application. Les fondre dans un indicateur « HTTP/2 actif » supprime précisément l’étape qui permet de localiser la rupture.

Les données précoces dépendaient du nouveau choix

TLS 1.3 permet, sous conditions, d’envoyer des données 0-RTT lors d’une reprise. Ces octets peuvent partir avant que le nouveau handshake soit achevé. Ils sont donc préparés sous une attente de protocole qui doit être vérifiée.

RFC 8446 interdit à l’implémentation TLS de les retransmettre automatiquement si la connexion négociée ne choisit pas le même protocole ALPN. Le ticket ne peut pas justifier le passage d’octets HTTP/2 vers une connexion désormais affectée à HTTP/1.1, ou l’inverse.

Le même identifiant ne garantit toutefois pas l’innocuité d’une répétition. L’application doit encore juger l’idempotence, l’état du serveur, les identifiants d’opération et l’autorisation. ALPN fournit une condition de cohérence grammaticale, non une promesse d’exécution unique.

QUIC a rendu l’accord indispensable

Dans QUIC, TLS ne protège pas simplement un flux TCP déjà constitué. Il participe directement à l’établissement d’un transport dont l’application doit être connue. RFC 9001 demande une négociation applicative authentifiée, normalement avec ALPN, et la fermeture immédiate si aucun protocole n’est obtenu.

Le protocole choisi doit aussi être compatible avec la version QUIC sélectionnée. Un serveur ne peut pas sauver une intersection nominale en associant une application à un transport qu’elle ne sait pas utiliser. Le client doit lui aussi rejeter cette incohérence.

ALPN apparaît ici comme un lien entre trois politiques : ce que le client peut parler, ce que le serveur veut servir et ce que cette instance de transport peut porter. Aucun registre central n’effectue le choix pour la connexion. La norme fixe les règles qui permettent aux deux opérateurs de prendre ce choix localement et de faire de l’échec un résultat commun.

Le registre ne mesure ni la flotte ni le trafic

Le registre IANA des extensions TLS et identifiants ALPN stabilise les chaînes d’octets opaques sous Expert Review. Il recense notamment http/1.1, h2, h3 et la réservation h2c assortie de son interdiction dans TLS ALPN.

Une ligne résout une collision de nommage. Elle ne prouve pas qu’un navigateur propose la valeur, qu’un serveur la choisit, qu’un nœud l’applique correctement ou qu’un trafic actuel l’utilise. La preuve de déploiement appartient aux handshakes observés et aux applications qui suivent.

Le ticket repris, lui aussi, est une preuve bornée. Il peut attester qu’une reprise cryptographique est acceptable selon la politique TLS. Il ne devient pas le registre privé de l’ancienne grammaire. La décision qui interprète les nouveaux octets doit être prise par la nouvelle connexion.

Sources

Ces textes établissent des règles, une histoire normative et un registre. Ils ne constituent pas un recensement actuel des déploiements.