Le TLS (Transport Layer Security) chiffre le trafic d'un site web, empêchant ainsi d'autres entités d’intercepter, surveiller et modifier ses communications. Cependant, l'ajout de cette protection introduit une certaine complexité dans les échanges entre le serveur et le navigateur. TLS peut donc ralentir le chargement de vos pages web et affecter l'expérience de l'utilisateur, mais il est possible d’y remédier ! Voyons comment les optimisations de Fasterize et son CDN vous permettent d’assurer à la fois la sécurité de votre site et la vitesse de vos pages en HTTPS.
Une sécurisation de bout en bout : TLS 1.3 avec Forward Secrecy
Sécurisation entre le navigateur et le CDN
Nos connexions entre le navigateur et notre CDN sont sécurisées via TLS 1.3, avec des ciphers récents. Comme on le voit dans les résultats de ce test SSLLABS, le niveau de sécurisation est au maximum (A).
Cette configuration de notre CDN avec TLS 1.3 est nécessaire pour être aux normes PCI DSS, et nous mettons à jour régulièrement la suite de ciphers utilisés pour chiffrer les communications.
La suite de ciphers permet d’assurer la propriété de Forward Secrecy pour l'ensemble des navigateurs supportant le protocole TLS 1.3. Le Forward Secrecy permet à une information chiffrée de rester confidentielle en cas de compromission de la clé privée d’un correspondant.
Sécurisation entre le CDN et notre plateforme d’optimisation
Par ailleurs, la connexion entre le CDN et notre plateforme d’optimisation est également sécurisée en TLS 1.3.
Notre plateforme supporte un large champ de version TLS et de cipher pour se connecter à votre origine. La validité du certificat à l’origine peut aussi être assurée pour toute connexion.
Maintenant que nous avons vu les aspects sécurité, passons aux aspects vitesse et performance.
La reprise de session TLS
Fasterize assure la reprise des sessions TLS, une technique essentielle pour en améliorer les performances. Le client peut ainsi éviter une négociation complète en présentant directement le détail de la précédente négociation au serveur. La latence et les temps de calcul sont alors réduits.
Ce gain de temps est possible grâce à deux mécanismes : les identifiants de session et les tickets de session.
L’UTILISATION DU CACHE DE SESSION (IDENTIFIANTS DE SESSION)
Le navigateur stocke l’identifiant de session et le présente dans le message “Client Hello” lors de la prochaine négociation TLS (TLS handshake). Fasterize consulte alors son cache pour trouver la session correspondant à cet identifiant et passe à la négociation TLS qui est alors raccourcie.
L’UTILISATION DES TICKETS DE SESSION
Dans le dernier échange d’un handshake complet, Fasterize inclut un message “New Session Ticket” (non représenté dans le handshake illustré ci-dessus). Ce message comprend un état complet de la session TLS incluant le secret partagé et les algorithmes de chiffrement à utiliser, le tout protégé par une clé connue seulement de Fasterize.
Nous concilions ainsi sécurité et vitesse… jusque dans les moindres détails, même les moins évidents.
L’OCSP Stapling
Un des problèmes les moins connus qui affecte la performance d’un site HTTPS est le temps nécessaire pour la vérification de la validité des certificats grâce au protocole OCSP/CRL, dit OCSP Stapling.
Cette vérification effectuée par le navigateur représente environ 30 % du temps total du surcoût du HTTPS en termes de vitesse de chargement. C’est énorme !
Mais qu’est ce qu’OCSP/CRL ? Ce sont deux protocoles de révocation des certificats TLS. OCSP est préféré par les navigateurs modernes au protocole CRL car il est plus simple à traiter. Il permet de vérifier la validité d'un certificat en temps réel en interrogeant l’autorité de certification, sur la base d’une liste blanche (à l’inverse de CRL qui s’appuie sur une liste noire).
Le principal problème lié à l'OSCP est que cette requête est faite par le navigateur, et qu’elle se situe sur le chemin critique du rendu de la page.
En d’autres termes, le navigateur attend la réponse pour continuer le traitement de la page, et tant qu’il ne l’a pas, le rendu est bloqué.
L’idée derrière l’OCSP Stapling est de confier le traitement de cette requête non plus au navigateur, mais au serveur.
Ainsi, le serveur qui a envoyé le certificat ajoute (“agrafe”) l’indication de la validité du certificat directement dans la réponse TLS. Fasterize requête périodiquement l’autorité de certificat pour mettre à jour les informations de validité - information qui ne peut pas être falsifiée puisque la réponse OCSP est chiffrée lors du handshake TLS.
Voyons à présent la dernière technique derrière notre moteur pour sécuriser et accélérer les pages HTTPS.
Le TLS False Start
Le TLS False Start est une extension du protocole qui permet au navigateur d’envoyer les données de la page avant la fin du handshake TLS. Celui-ci ne modifie pas le handshake TLS, mais change le début de l’envoi des données chiffrées. En résumé, le TLS False Start permet de se limiter à un seul aller-retour pour l’établissement des nouvelles connexions TLS.
En pratique, les navigateurs n’exploitent cette extension que si le serveur supporte l’extension TLS NPN/ALPN. Et elle est justement activée sur Fasterize, ainsi qu’une suite cipher supportant le Forward Secrecy, comme nous l’avons vu plus tôt.
En somme, Fasterie vous permet d'accélérer considérablement votre site en HTTPS, en optimisant la couche TLS avec différentes techniques :
- une suite de ciphers gérant le Forward Secrecy,
- l'OCSP Stapling,
- le support des identifiants de session TLS et des tickets de session TLS,
- ainsi que le TLS False Start.
Toutes ces optimisations vous permettent d’améliorer la vitesse de votre site perçue par vos utilisateurs, mais aussi de faciliter le crawl Google pour contribuer à un meilleur référencement. Vous y gagnez sur tous les plans : sécurité, UX et SEO, et donc taux de conversion !
Vous souhaitez savoir ce que vous pourriez faire pour
accélérer votre site en HTTPS ?
