ralentissements HTTPS par rapport à HTTP

Ah, ces fameux ralentissements des sites en HTTPS qui font que les propriétaires de ces sites veulent rester en HTTP…

Certains vous diront qu’ils ont observé des temps de chargement des pages allant de 1 à 3 en passant en HTTPS. D’autres vous diront que cette augmentation est de 1 à 1,01.

Qu’est-ce qui est vrai là-dedans ? Tout.

Ah bon ? Et qu’est-ce que je dois faire, alors ? Garder mon site en HTTP ?

Vos clients, vos visiteurs, sont assurés que c’est votre site Web qu’ils consultent, et non pas le site Web de quelqu’un qui se fait passer pour vous. Votre image de marque est préservée, car personne ne va pouvoir parler en votre nom. On voit tellement de sites Web défigurés (« defacement » en anglais) ou de comptes Twitter usurpés par des pirates informatiques, ce serait dommage que votre site fasse partie de la liste.

En HTTPS, quand vous envoyez des informations (vos pages Web) à vos visiteurs, alors vous êtes assurés qu’elles arrivent intactes et identiques. Il n’y a personne qui pourrait se mettre au milieu, entre votre site Web et vos visiteurs, puis qui pourrait intercepter vos pages pour les modifier et les renvoyer à vos visiteurs.

Les informations qui sont échangées entre vos visiteurs et votre site Web restent privées. Personne ne peut les écouter.

« Oui, mais mon site Web ne contient que des données publiques, je ne propose pas de paiement avec saisie de numéros de cartes bancaires ! » Tu as raison, tes données sont publiques. Pour toi. Dans ta configuration géopolitique. Dans certains pays, ce blog que vous lisez pourrait être interdit car « il fait l’apologie du terrorisme car il parle de chiffrement et que si on chiffre des communications alors l’État ne peut pas surveiller les discussions des futurs poseurs de bombes et les arrêter avant leur forfait ».

« Oui, mais moi je n’ai rien à cacher ! » Hum… Comme dirait E. Snowden, ne crache pas sur la vie privée sous prétexte que tu n’as rien à cacher, car cela reviendrait à cracher sur la liberté d’expression sous prétexte que tu n’as rien à dire.

Google favorise les sites en HTTPS dans son calcul de ranking pour l’affichage de résultats. Certes, aujourd’hui c’est encore un signal faible (par rapport au contenu des pages Web), mais vu l’évolution du marché, nul doute que ce critère va vite évoluer.

Ça rame. Et ça bouffe du CPU.

Un rapide rappel du protocole TCP. Comment les échanges se font-ils sur Internet, comment le client discute-t’il avec le serveur ? C’est très simple, il se passe ça :

« _ Bonjour, Serveur.
_ Bonjour, Client.
_ Serveur, puis-je te poser une question ? Alors voilà… (la question)
_ (réponse du Serveur)
_ (éventuelles autres questions du Client)
_ (réponses du Serveur)
_ Merci Serveur, au revoir.
_ Au revoir, Client. »

On voit qu’avant de poser une question, le Client et le Serveur établissent une connexion. On appelle ça le handshake TCP (poignée de main).

Il existe en plus un second handshake dans le protocole SSL/TLS. Voici ce que le Client et le Serveur s’échangent :

« _ Bonjour Serveur, je voudrais chiffrer notre conversation.
_ D’accord Client. Voici mon certificat.
_ J’ai bien reçu ton certificat. Moi, je sais utiliser les méthodes de chiffrement xxx, yyy et zzz.
_ D’accord Client, on va utiliser la méthode xxx.
_ (première requête chiffrée du Client vers le Serveur) »

On voit donc que la poignée de main SSL/TLS rajoute des échanges « protocolaires » avant de s’échanger l’information utile. Donc elle rajoute du temps. Les mesures habituelles donnent une moyenne de 100 ms rajoutées, pour un accès Internet via un PC sur une ligne ADSL (moyenne couramment adoptée aujourd’hui). Et comme l’a signalé Amazon, 100 ms rajoutées diminuent de 1 % les ventes : quand le site Web est lent, les client se découragent et vont voir ailleurs.

Quand le client se connecte à Internet depuis un réseau WiFi bien chargé, des paquets réseau sont perdus. Lorsqu’il s’agit des paquets liés à la poignée de main SSL/TLS, les réémissions de ces paquets ne fonctionnent pas toujours très bien (le chiffrement se base entre autres sur l’heure locale, et des paquets trop lents se retrouvent bloqués). Du coup, la connexion HTTPS ne se fait pas, ou bien se perd rapidement. Le même phénomène peut être observé sur le réseau 3G, ou à moindre mesure sur le 4G.

Pour ce qui est du protocole, on ne peut pas faire grand-chose. À part se rendre compatible avec la future version TLS v1.3, qui devrait sortir avant la fin 2017. Cette nouvelle version du protocole divise par deux les échanges lors de la poignée de main, donc elle l’accélère d’un facteur 2 ! Cette nouvelle version du protocole fonctionne ainsi :

« _ Bonjour Serveur, je voudrais chiffrer notre conversation. Au fait, je sais chiffrer avec les méthodes xxx, yyy et zzz.
_ Bonjour Client. Voici mon certificat. J’ai vu tes capacités techniques. Alors on va chiffrer avec la méthode xxx.
_ (première requête chiffrée du Client vers le Serveur) »

Chiffrer et déchiffrer, ça prend du temps, ce sont des opérations supplémentaires.

Oui c’est vrai, ça prend du temps. Ça prend davantage de temps que si on ne le faisait pas. Mais c’est tout ! Il y a 15 ans, nos processeurs ne calculaient pas très rapidement, et on pouvait observer à l’œil nu le temps mis à chiffrer et déchiffrer quand on consultait un site HTTPS. Aujourd’hui, les CPU dont on dispose sont suffisamment puissants pour réaliser ces opérations à très grande vitesse. Certains CPU disposent même de fonctions spécifiques (directement dans le CPU ou alors dans un processeur de calcul annexe) qui optimisent et accélèrent les opérations de chiffrement et déchiffrement. Et ces accélérations sont également valables dans nos tablettes et téléphones portables.

Le surcoût pourrait éventuellement se sentir côté serveur, s’il doit gérer plusieurs centaines de connexions chiffrées à la seconde. Et auquel cas, il existe des accélérateurs matériels SSL/TLS.

Lorsqu’un client consulte un site Web, toutes les informations reçues par ce client sont mises en cache dans la mémoire tampon de son navigateur Internet. Ceci permet d’accélérer la navigation de manière globale, car lorsque ce même client reviendra sur ce site Web, alors il n’aura plus à charger toutes les images de décoration du site.

En HTTPS, les informations envoyées par le serveur ne sont pas mises en cache. Pour des raisons de sécurité. Car si vous réalisez un achat en ligne et que la page Web d’achat est stockée en cache, alors votre numéro de carte bancaire l’est aussi, et il suffit de pirater votre cache (facile, il n’est pas protégé) pour récupérer tout plein d’informations « intéressantes ». Donc a fortiori les fameuses images de décoration des sites Web ne sont pas stockées en cache, donc si le site Web dispose de beaucoup d’éléments statiques d’habillage alors il s’affichera plus lentement car le client devra télécharger ces éléments à chaque connexion.

Pour la mise en cache, contrairement à ce qu’on peut penser, le SSL/TLS ne l’interdit pas ! Il ne fait que l’interdire par défaut. Du coup, le développeur d’un site Web doit rajouter une information dans la configuration de son site Web, du genre « cet élément, je l’autorise à être mis en cache ».

Il suffit de rajouter l’entête HTTP Cache-Control: max-age=X, public pour les objets statiques (images, vidéos…) que le navigateur peut mettre en cache.

Attention toutefois au « mixed-content » ! Les navigateurs Web n’aiment pas avoir une page en HTTPS et qui contient des éléments (images…) appelés en HTTP. Et les moteurs de recherche non plus.

Vous prêterez attention à tous les liens présents sur votre site et qui pointent sur lui-même (liens à réécrire en « https:// » ou alors simplement en relatif et sans le nom du site ni le protocole). Les points les plus délicats sont les liens externes. On y trouve les hébergements sur des CDN (mais la plupart des fournisseurs de CDN sont compatibles HTTPS à présent), ainsi que les publicitaires (aussi étonnant que cela puisse paraître, il existe encore beaucoup de régies publicitaires non compatibles HTTPS ; si c’est le cas de la vôtre, changez-en).