Toutefois, si vous avez porté une attention particulière au comportement de vos applications, vous avez peut-être remarqué les améliorations suivantes :
* Temps de chargement plus rapides
* Assistance spdy
* moins de poignées de main TLS
* Prise en charge d'IPv6
* de meilleurs chiffrements TLS
* Sécurité stricte des transports
* Plus de ressources grâce à la compression gzip
* Prise en charge des WebSockets

Dans cet article, je vais passer en revue certains de ces changements et expliquer les technologies qui les sous-tendent.

Aperçu de l'architecture HTTP

Vos requêtes HTTP sont transmises via une connexion TCP, elle-même établie par un répartiteur de charge TCP vers l'un de nos serveurs web. Ce serveur web effectue deux opérations :
* Gérer les protocoles SSL/TLS
* faire transiter les requêtes HTTP par le serveur d'application

Ainsi, chaque centre de données comprend un équilibreur de charge TCP, un petit nombre de serveurs web et un grand nombre de serveurs d'applications.

IPv6

Comme vous le savez peut-être, le nombre d'adresses IPv4 (Internet Protocol version 4) avoisine les 4 milliards. Cela paraît énorme, jusqu'à ce qu'on réalise qu'idéalement, n'importe quel appareil pourrait communiquer directement avec n'importe quel autre via Internet, qu'il y a plus de 7 milliards d'êtres humains et que, dans le monde occidental, chaque personne possède en moyenne 5 appareils connectés à Internet. Alors, pourquoi cela pose-t-il problème ? Imaginez que vous postiez un colis et que vous ne puissiez indiquer que le code postal et le numéro de la maison comme destinataire. Impossible d'ajouter les noms, les services, etc. Comment feriez-vous parvenir ce colis à un service précis dans une entreprise, ou une carte d'anniversaire au bon membre de la famille ? Supposons que le père de famille du 15, rue Principale, dise : « Faisons comme si j'habitais au 15a, ma mère au 15b, notre fils au 15c et notre fille au 15d, mais nous continuerons à utiliser la même boîte aux lettres : la n° 15. » La réaction appropriée serait : « Quelle idée stupide ! » Bien sûr, ça fonctionne, mais ce n'est pas à ça que servent les suffixes de lettres dans les numéros de maison ! Ils servent lorsqu'une maison est divisée en plusieurs adresses et qu'on ne veut pas que les voisins aient l'adresse 19 au lieu de 17.

Néanmoins, c'est la solution standard sur Internet. On l'appelle la traduction d'adresses réseau (NAT) : vous partagez une même adresse IP entre plusieurs appareils et vous utilisez le numéro de port pour identifier le destinataire. Ainsi, pour accéder à un appareil spécifique derrière votre routeur, vous pourriez rediriger le port 8080 vers cette machine. Cela peut sembler une bonne idée, mais malheureusement, les numéros de port, comme les suffixes alphabétiques, sont déjà utilisés à d'autres fins. Les ports servent à spécifier le type de service que vous souhaitez utiliser sur un appareil, comme le trafic web (80), le trafic web chiffré (443), la messagerie (25), etc. Résultat : un service ne peut fonctionner que sur un seul appareil si vous êtes derrière une passerelle NAT (comme le routeur de votre domicile). Si vous souhaitez accéder à deux appareils HTTP depuis l'extérieur (votre NAS et votre webcam), vous n'avez pas de chance et devez recourir à des solutions de contournement peu élégantes. La NAT est, à juste titre, considérée comme une solution de fortune, mais largement utilisée.

La véritable solution réside dans l'IPv6, qui offre un nombre d'adresses possibles supérieur au nombre d'atomes sur Terre. Cependant, son adoption est lente : actuellement, seulement 2 % environ du trafic Internet est en IPv6. C'est un cercle vicieux : les entreprises doivent prendre en charge l'IPv4 car la plupart des clients n'ont pas encore accès à l'IPv6, et les clients n'ont aucun intérêt à adopter l'IPv6 car toutes les entreprises sont encore tenues de prendre en charge l'IPv4. Des progrès sont néanmoins constatés (Comcast Link), et l'Internet des objets pourrait tirer un tel profit de l'IPv6 que la demande des consommateurs augmentera.

Il est essentiel que les entreprises se sentent obligées de prendre en charge IPv6 et qu'elles assument pleinement leurs responsabilités. C'est ce que nous faisons, et depuis la semaine dernière, les dernières parties de nos applications sont accessibles via IPv6.

Découvrez l'extension Chrome IPv6 Notificator pour vérifier si votre fournisseur et le site web que vous visitez font leur part !

SPDY

Ces dernières années, vous avez peut-être entendu parler d'HTTP 2.0 ou de SPDY. SPDY est une initiative de Google visant à améliorer le protocole HTTP sans attendre les comités officiels. Quel est le problème avec HTTP 1.1 ? Pas grand-chose, en réalité, si ce n'est que les exigences ont considérablement augmenté. Pour afficher un site web, le navigateur doit effectuer de nombreuses requêtes. En moyenne, on en compte une quarantaine lors d'une première visite. Aux débuts d'Internet, il n'y en avait qu'une seule : un document HTML. Pour gérer cela, les navigateurs ouvrent un pool de sockets vers le serveur web. Avec SPDY, ce n'est plus nécessaire, car les requêtes peuvent être multiplexées dans une seule connexion TCP. Vous pouvez facilement visualiser le nombre de connexions utilisées grâce à la commande `netstat` sur les systèmes *nix.

Il y a eu de nombreuses améliorations :
* déduplication des en-têtes
* compression
* Demande de multiplexage
* push du serveur

Comme nous utilisons NGINX, nous sommes toujours liés à spdy2 ; nous devrons attendre que spdy3.1 soit accepté dans une version stable.

Équilibrage de charge TCP

Les fournisseurs IaaS comme Rackspace et Linode permettent de créer des équilibreurs de charge TCP, que nous utilisons fréquemment. Par défaut, ces équilibreurs sont configurés en mode round robin. Cela semble logique, jusqu'à ce qu'un client se connecte à un serveur web différent pour chaque connexion HTTPS. Dans ce cas, la reprise de session SSL est impossible et la négociation SSL doit être relancée. Cela engendre un coût supplémentaire : le temps d'un aller-retour (le temps nécessaire pour un cycle complet requête/réponse).

Pour garantir qu'un client se connecte toujours au même serveur web (tout en assurant une haute disponibilité), vous pouvez activer la persistance de session dans la configuration de votre équilibreur de charge.

Cependant, si votre navigateur prend en charge SPDY, ce n'est pas un problème majeur puisque vous n'utilisez déjà qu'une seule connexion TCP.

Chiffrements TLS

Ces dernières années, plusieurs attaques ciblant SSL/TLS, comme BEAST, sont apparues. Pour contrer ces vulnérabilités, il est essentiel de définir l'ordre des suites de chiffrement privilégiées sur le serveur web et d'exclure les suites de chiffrement non sécurisées. Cela représente un véritable défi, car il faudra néanmoins assurer la compatibilité avec tous les navigateurs et systèmes d'exploitation.

Il semblerait que nous ayons résolu ce problème avec succès, du moins d'après le test SSL disponible à l'adresse https://www.ssllabs.com/ssltest/analyze.html.

Confidentialité de la transmission

Lorsqu'il est impossible de déchiffrer un canal de communication chiffré, une bonne solution consiste à capturer toutes les données chiffrées afin de pouvoir les déchiffrer ultérieurement. Avec certains algorithmes de chiffrement, une fois la clé privée découverte, il est possible de déchiffrer toute communication sécurisée enregistrée précédemment. Les algorithmes utilisant la confidentialité persistante rendent cette opération pratiquement impossible. Même après avoir déchiffré la clé d'une session, il faut répéter l'opération pour toutes les autres sessions enregistrées.

Comme tout ce qui est mentionné dans cet article, nous le soutenons. Consultez le statut de votre application sur https://www.ssllabs.com/ssltest/analyze.html

Sécurité stricte des transports : évitez l’intermédiaire

Si vous saisissez une URL comme mail.google.com dans votre navigateur web, vous arrivez sur https://mail.google.com/, ce qui représente un trafic non sécurisé. Cela signifie que vos données peuvent être interceptées et manipulées sur n'importe quel appareil entre vous et le serveur de Google. Dans ce cas, https://mail.google.com/ vous redirige vers https://mail.google.com/ et, à partir de là, votre connexion est sécurisée. Imaginons cependant qu'une personne intercepte cette redirection et se fasse passer pour un proxy : elle reçoit vos requêtes HTTP en clair et les envoie à https://mail.google.com/. Lorsqu'elle reçoit une réponse de https://mail.google.com, elle la déchiffre et vous la renvoie en clair. De cette manière, l'intercepteur peut écouter et manipuler toutes vos données, et vous ne vous apercevrez de rien. C'est ce qu'on appelle une attaque de l'homme du milieu.

Il n'existe pas de solution miracle, mais l'en-tête HTTP Strict Transport Security indique à votre navigateur qu'il ne doit plus jamais accéder au site en HTTP simple. Nous utilisons cette méthode pour limiter la période de vulnérabilité à la première visite de la page.

Depuis quelques semaines, nous envoyons l'en-tête HSTS sur toutes nos URL HTTPS.