Comment juger de la qualité de la connectivité d’un site Web ?

Souvent, les seules contraintes que nous nous fixons lors de la réalisation d’un site Web se situent au niveau de la conformité de son affichage quant à un design préétabli sur les trois principaux navigateurs du moment, et au respect des fonctionnalités demandées. Avec des projets plus avancés, nous pouvons aller jusqu’à l'implémentation de tests automatisés validant des pans plus ou moins complets de l'applicatif.

Malheureusement, on oublie souvent de prendre en compte dans nos critères de réussite, l’infrastructure même rendant notre site accessible au monde entier.
Pourtant, une mauvaise configuration ou l’utilisation de protocoles obsolètes peut nuire de façon très concrète à l’expérience utilisateur (par exemple en rallongent les temps de chargement), voir carrément en rendant le site inaccessible. L’idée de cet article est donc de présenter des notions propres à ce domaine, impersonnelles et suffisamment globales pour pouvoir s’appliquer à tout projet Web.

Notez également que nous nous limitons ici à la partie de l’infrastructure effectuant la connectivité avec l’extérieur. Nous ne parlerons pas de résilience aux pannes ni de politiques de sauvegardes.

IPv6

Dans cette catégorie, le premier élément auquel nous pensons est bien sûr le support d’IPv6. Il faut savoir que bien que la plupart des fournisseurs d’accès à Internet proposent encore un lien direct à l’Internet depuis une IPv4, c’est de moins en moins le cas. Les opérateurs mettent donc en place des systèmes complexes pour maintenir une connectivité sur ces réseaux qui peuvent s’avérer coûteux en performance, car ils nécessitent plus d’intermédiaires et des traitements de routage plus longs. Implémenter IPv6 directement permettra à vos clients de s’affranchir de cette lourdeur.

Un outil comme ipv6-test.com peut être utilisé pour vérifier à la fois la connectivité de votre propre accès à Internet, mais aussi celui de n’importe quel site Web.

HTTP/2

Il s’agit d’une version améliorée de HTTP 1.1 qui reste encore principalement utilisé aujourd’hui. Il se démarque notamment par deux aspects : c’est un protocole binaire (en opposition à HTTP 1.1 qui communique en mode texte), et permet avec une même connexion de récupérer plusieurs requêtes HTTP (le multiplexage de flux). Ce qui en soit, apporte des performances sensiblement meilleures (surtout avec HTTPS qui est bien plus lourd lors de l’établissement des connexions).

Ce protocole possède néanmoins un troisième avantage dont il est certes plus difficile de tirer parti, mais qui permet encore une fois de diminuer les temps d’accès : le préchargement. Il peut concerner des ressources présentes dans la page courante (comme un style CSS, ou des Javascripts dont le client n'a pas encore conscience d'en avoir besoin) ou alors pour charger de façon prévisionnelle une page sur laquelle l’utilisateur ira probablement (par exemple, la page de redirection après la soumission d’un formulaire). Malheureusement, pour tirer parti de cette fonctionnalité, il faudra soit que l’applicatif ait été conçu pour, soit faire une configuration au niveau du serveur Web relativement avancé.

Comparatif temps de chargement

Comparatif du temps de chargement d'une même page, avec plusieurs technologies, par smashingmagazine.com.

À noter que HTTP/2 compresse automatiquement l’intégralité de la communication, y compris les en-têtes. Il n’est donc plus nécessaire de gérer cela manuellement.

HTTPS

Probablement la notion la plus complexe, il s’agit aussi de la plus importante aujourd’hui, tant la sécurité du Web est devenue nécessaire. Ce protocole est une surcouche à HTTP (1.1 ou 2) qui permet au visiteur de vérifier l’identité réelle du site qu’il contacte, ainsi que la confidentialité et l’intégrité de ces échanges avec celui-ci. Il se compose en fait de différents acteurs :

Les composants d’HTTPS

Les protocoles de communications supportés. Il s’agit ici de SSL ou de TLS, c’est l’élément central qui se greffe à HTTP pour établir le lien entre le client et le serveur. En 2018, toutes les versions de SSL sont considérées comme obsolètes. Il en est de même pour TLS v1.0. Utiliser ces protocoles est donc nuisible, car ils peuvent procurer un faux sentiment de sécurité.

La paire de clés privée/publique employée par le serveur Web pour gérer les connexions. HTTPS se base sur du chiffrement asymétrique pour le partage des identités. De nos jours, c’est TLS ou ECDSA qui est utilisé. Attention, il faut savoir qu’une clé trop longue nuira aux performances de votre site, notamment par des lenteurs au niveau de l’initialisation des connexions. Si elle est trop petite, elle entraînera par contre des faiblesses au niveau de la sécurité.

Le certificat X509. Il s’agit probablement de la notion la plus controversée du processus, mais qui, en attente de démocratisation de systèmes de certification plus sain, comme DANE, restera nécessaire. Il s’agit ici de définir (et de payer, en général grassement) une société qui, en tant qu’autorité de certification, servira d’intermédiaire entre vos utilisateurs et vous. Elle confirmera que la clé TLS ou ECDSA fournie à un client pour communiquer avec votre infrastructure vous appartient bien, et n'est pas celle d'un usurpateur.

Ici, il faut donc prendre soin à bien choisir cet intermédiaire. Pour cela, les critères employés sont assez arbitraires, mais on peut quand même noter certains points auxquels faire attention :

  • Vérifier la reconnaissance de l’autorité à travers le monde. En effet, chaque navigateur Web ou application gère de façon indépendante la liste des autorités auxquelles ils font confiance. Il faut donc s’assurer que notre choix se portera sur une entité considérée comme fiable par la plus grosse majorité de vos utilisateurs (en général, l'autorité doit au moins être acceptée pour Firefox, Chrome et Edge).
  • Vérifier le niveau technique et la part du chiffre d’affaires que représente la vente de certificats X509 de votre futur prestataire : plus celle-ci est importante, plus il mettra de moyens en œuvre pour assurer la sécurité de son infrastructure. En effet, les autorités de certification sont une cible de prédilection pour un gros nombre de pirates informatiques. Réussir à compromettre l'une d'entre elles permettrait de délivrer des certificats usurpés et de piéger les internautes. Sauf à implémenter HPKP, ça ne protégera pas votre domaine des faux, mais ça vous évitera au moins de devoir changer de prestataire une fois la compromission établie.

En plus de l’autorité de certification en elle-même, il faut aussi faire attention à l’algorithme de hachage utilisé pour l’élaboration du certificat. En ce début d’année 2018, il est conseillé d’opter pour cette étape, SHA256.

Les algorithmes de chiffrement symétriques supportés. Il s’agit là de la façon à travers laquelle nous communiquons une fois l’authentification validée. En effet, il serait trop coûteux de continuer à utiliser RSA ou ECDSA à ce niveau, car le chiffrement asymétrique demande beaucoup plus de ressources. Des protocoles de chiffrement symétrique comme DES (aujourd’hui obsolète, mais très connu) ou AES sont employé à la place.

Les suites cryptographiques supportées. Comme nous venons de le voir, beaucoup de combinaisons existent concernant les technologies à utiliser pour l'authentification, la communication et le partage réel de messages. Pour établir un dialogue fonctionnel entre un serveur et un client, il faut que les deux acteurs se mettent d'accord sur les suites technologiques à utiliser. C'est pour cela que la notion de suite cryptographique a été inventée.

À l'établissement d'une connexion, le client envoie toutes les suites cryptographiques qu'il supporte. Le serveur en choisira une parmi celles-ci pour les opérations futures.
Pour savoir quelles suites accepter, je vous conseille de vous référer au site : Cipherli.st. C'est en effet une façon fiable d'exclure d’emblée toutes technologies obsolètes.

Ce que HTTPS permet aussi

Interdire le contenu mixte (HSTS). Concrètement parlant, il se caractérise par l’ajout du drapeau Strict-Transport-Security au sein de l'en-tête de la réponse HTTP. Cela indiquera aux navigateurs Web de vos clients de simplement ignorer toutes les ressources non-HTTPS présentes sur la page. Cela signifie naturellement que l’intégralité de vos images, CSS, Javascripts (y compris ceux de vos partenaires commerciaux) soient également délivrés en HTTPS.

Utiliser des cookies sécurisés. Il s’agit ici de ne pas oublier de configurer au niveau de l’applicatif le drapeau secure sur les cookies créés, qui indiquera aux navigateurs Web de vos clients de refuser de les transmettre lors de futures communications si celles-ci n’utilisent pas HTTPS.

Utiliser le Public Key Pinning (HPKP) ? Attention, il s’agit ici d’une technologie dangereuse pouvant rendre votre site inutilisable. C’est donc à vous de voir si elle devrait néanmoins être mise en œuvre. En général, seuls les sites ayant besoin d’un très haut niveau de sécurité implémentent cette technologie. L’idée ici est de se prémunir contre les falsifications de certificats X509 qui pourraient être émis par d’autres autorités dont la victime fait confiance (voici un exemple). À la première connexion au site, HPKP permet au navigateur Web du client de sauvegarder l’empreinte du certificat actuel, ainsi que l’intégralité des autres pouvant authentifier la clé publique utilisée. C’est-à-dire qu’à une prochaine connexion de ce client sur le site, celui-ci bloquera directement l’accès si aucune de ces clés n’est employée, même si elles sont émises par une autorité envers laquelle le navigateur Web aurait confiance.

Le Content Security Policy (CSP) ne concerne pas à proprement parlé une technologie qui nécessite HTTPS, mais reste caduque sans celui-ci. Il s’agit ici d’une solution permettant de lutter contre les attaques de type XSS en établissant une liste blanche des ressources extérieures pouvant être chargées au sein de la page Web (comme la localisation précise des Javascripts externes et des images de tracking). Pour en savoir plus, vous pouvez vous référer à la documentation de Mozilla.

Vous l’aurez compris, il est très complexe de gérer ça correctement. Du coup, comment faire pour s’assurer d’une bonne implémentation d’HTTPS sur votre site ? Vous pouvez vous référer au testeur de SSLLabs qui est plutôt complet sur la question. Je vous conseille aussi la lecture de leur guide sur la question, dont ce paragraphe a été fortement inspiré.

Conclusion

Cette petite check-list touche à sa fin. Peut-être ai-je oublié d’autres éléments qui mériteraient d’être renseignés ici ? Si c’est le cas, n’hésitez pas à m’en dire plus dans les commentaires de ce billet !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.