Dans un long billet technique, Facebook explique les travaux entrepris depuis plus d’un an sur un protocole de communication capable de réduire la latence. Baptisé Zero, il permet d'accélérer les connexions sécurisées.

Le travail réalisé par Facebook s’inscrit dans un cadre particulier. Les connexions à ses serveurs sont très nombreuses et ne font qu’augmenter, ne serait-ce qu’à travers son service de connexion unifiée. L’éditeur cherche donc par tous les moyens à réduire la latence lors des échanges.

La problématique de Facebook : les performances des connexions

Toutes les applications Facebook utilisent une pile réseau maison. Nommée Mobile Proxygen, elle se présente sous la forme d’un client HTTP multiplateforme écrit en C++ 14, basé sur la bibliothèque Proxygen. Celle-ci utilise TLS 1.2 via OpenSSL pour établir les connexions sécurisées. C’est ici que se concentre la problématique.

Cette phase d’établissement prend du temps, comme tout ce qui touche aux connexions sécurisées : il faut négocier avec le serveur, échanger les clés, chiffrer le contenu, etc. Facebook indique avoir accéléré autant que possible ces étapes via différentes techniques (réutilisation des connexions HTTP/2, reprise de sessions, démarrage spéculatif des connexions, suites cryptographiques récentes, …), mais la grande majorité des connexions TLS nécessitent au moins un round-trip (1-RTT).

La notion de RTT (round-trip time) est cruciale. Elle définit le nombre d’étapes entre la requête d’un client et ce qui est réceptionné en retour. Ce nombre a un impact sur la latence de connexion, puisque qu’avec l’augmentation de ces étapes, le client attend davantage avant que des données lui soient effectivement envoyées. L’objectif de Facebook ? Le 0-RTT, d’où le nom de son protocole : Zero.

Négocier au plus vite pour échanger plus tôt

Le sujet intéresse Facebook depuis longtemps, même si l’entreprise est loin d’être la première à travailler sur un tel protocole. En fait, TLS 1.3 dispose effectivement d’un mode 0-RTT. Cependant, le protocole n’est pas finalisé, Facebook indiquant d’ailleurs qu’au début du travail sur Zero, l’état de TLS 1.3 ne permettait pas de se baser sur le brouillon.

L’entreprise s’est donc appuyée sur un protocole existant, nommé QUIC. Il a fallu en modifier de nombreux aspects, dont le principal : QUIC est conçu pour les connexions UDP, alors que Facebook communique avec TCP. Le principe général reste toutefois le même.

Ainsi, lors de la toute première connexion d’un client vers le serveur, il y a négociation complète. Le client garde alors en cache un message, Server Config (SCFG), qui contient toutes les informations sur le protocole d'échange de clés Diffie-Hellman. Toutes les connexions ultérieures l’utiliseront pour obtenir des clés dérivées et ainsi commencer immédiatement à échanger des données. On peut parler en fait de connexions « pré-négociées ».

Des soucis particuliers, mais des gains réels

Bien entendu, les détails sont nettement plus complexes et de nombreux ajustements ont dû être faits, tant pour améliorer les performances que pour appréhender des problématiques de sécurité spécifiques au 0-RTT. Par exemple, Facebook limite la durée pendant laquelle une configuration serveur (SCFG) est valide, pour éviter que sa fuite ne permette son imitation. De même, les propriétés de sécurité des données 0-RTT sont particulières. Si aucune barrière n’était mise en place, elles pourraient être « rejouées » sans limite par des pirates, comme dans le cas de requêtes HTTP POST.

Actuellement, le protocole Zero est déployé dans les applications mobiles de Facebook et est utilisé en interne pour la répartition de charge entre les serveurs. Les bénéfices sont bien présents selon l’éditeur : en moyenne, 41 % de réduction sur la latence des connexions, un gain plus que notable donc. Toutes les requêtes n’en profitent cependant pas de la même manière. Celles établies quand l’application se lance et ne peut pas réutiliser une connexion existante (mais que les données SCFG sont toujours valables) sont particulièrement accélérées par exemple. Le réseau social indique d'ailleurs que le démarrage à froid des applications s'en trouve raccourci.

Facebook veut montrer son implication

Cependant, si Facebook aborde ces questions maintenant, c’est bien pour faire la démonstration de son implication sur ce type de problématique.

Ainsi, tout le travail effectué sur Zero a été communiqué au groupe concerné au sein de l’IETF tout au long de l’année écoulée. Plusieurs aspects du futur standard sont en fait déjà inspirés du protocole de Facebook, comme la durée de vie des tickets. Les échanges ont permis de souligner des problèmes potentiels, notamment l’influence du 0-RTT sur les navigateurs.

Qu’en sera-t-il alors de Zero quand TLS 1.3 arrivera ? Facebook travaille en fait déjà sur son implémentation du protocole, en utilisant les derniers brouillons. Il agira comme un surensemble de Zero et l’englobera entièrement. Facebook ne tarit d’ailleurs pas d’éloges sur le standard en devenir : plus sécurisé, modèle beaucoup plus simple, avec de meilleures performances.

Le protocole Zero ne disparaîtra cependant pas. Facebook continuera de le développer dans un cadre expérimental, pour comparer les résultats obtenus à ceux de TLS 1.3. L’éditeur avoue d’ailleurs que travailler sur Zero lui a permis de mieux saisir les tenants et aboutissants du 0-RTT permis par TLS 1.3. Il recommande finalement à tous ceux qui sont intéressés par la sécurité et les performances de se pencher sur le standard.