optimisations HTTPS

Le TLS (Transport Layer Security) chiffre le trafic d'un site Web empêchant d'autres entités de surveiller ses communications. Cependant, l'ajout de cette protection introduit plus de complexité sur un site Web et sa façon de communiquer avec vos visiteurs. Le TLS peut donc ralentir le chargement de vos pages web et affecter négativement l'expérience de l'utilisateur. Dans cet article, nous allons vous présenter les optimisations mises en place par Fasterize au niveau de la couche de sécurisation TLS pour garder un site rapide et garantir le maximum de sécurité.

HTTP vs HTTPS
NB : Il existe quelques bonnes pratiques pour bien configurer son serveur pour HTTPS. Ces bonnes pratiques sont déjà activées pour tous les sites branchés à Fasterize et nous veillons à mettre à jour régulièrement notre configuration serveur pour être conforme au PCI DSS.

Meilleure sécurisation : pas de SSL3 et du TLS 1.2 avec Forward Secrecy

En janvier 2015, nous avons effectué un audit sécurité de notre connexion TLS. Le but de cet audit était d’obtenir le niveau de sécurisation maximum « A » sur le test SSLLABS.

Capture d’écran 2015-03-02 à 18.31.26

Au niveau sécurité, Fasterize a désactivé la gestion du protocole SSL3 en juin 2014. Le protocole SSL3 a depuis été considéré comme non sécurisé. La mise à jour continue de la version d’openssl utilisée sur nos serveurs permet de prévenir nos clients des attaques connues : HEARTBLEED, CRIME, BEAST attack...

Suite à l’audit, nous avons revu la suite de ciphers utilisés pour chiffrer les communications.

Le changement de la suite de ciphers a permis d’assurer la propriété de Forward Secrecy pour l'ensemble des navigateurs supportant le protocole TLS 1.2. Le Forward Secrecy permet à une information chiffrée aujourd’hui de rester confidentielle en cas de compromission future de la clef privée d’un correspondant. Plus d’informations sur le Forward Secrecy sont disponibles sur internet.

2017 : l’avènement de TLS 1.3

TLS 1.3 n'est pas encore finalisé. Mais nous savons que cette révision majeure présentera deux avantages principaux par rapport aux versions précédentes:

  • Sécurité renforcée
  • Vitesse améliorée

En savoir +

Reprise de la session TLS

Fasterize a mis en place la réutilisation des session TLS qui est l’un des mécanismes les plus importants pour améliorer les performances de TLS. Le client peut effectuer une connexion raccourcie en soumettant, dès sa seconde connexion, une donnée présentée précédemment par le serveur, permettant ainsi de réduire la latence et les temps de calcul. Il existe deux mécanismes distincts à cet effet : les identifiants de session et les tickets de session.

a9f8b2fc9a180c48e6d4a20e906243d6
a2132472ba0281fe662b8d507e98f057

Utilisation du session cache (identifiants de session) :

Le navigateur stocke cet identifiant et le présente dans le message « Client Hello » lors du prochain handshake TLS. Fasterize consulte alors son cache pour trouver la session correspondante à cet identifiant et embraye sur un handshake raccourcie.

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 chiffré et protégé par une clef connue de Fasterize.

L’OCSP stapling

Un des problèmes les moins connus qui affecte la performance du HTTPS est la vérification de la validité des certificats grâce au protocole OCSP/CRL. Cette vérification effectuée par le navigateur compte pour environ 30% du temps total du surcoût du HTTPS. C’est énorme !

OCSP/CRL sont les deux protocoles actuels de révocation des certificats TLS. OCSP est préféré par les navigateurs modernes au protocole CRL car il est moins couteux en terme de traitement. Celui-ci permet en effet de vérifier la validité d'un certificat en temps réel en interrogeant l’autorité de certification.
Le principal problème lié à l'OSCP est que cette requête est faite par le navigateur. Or, celle-ci se situe sur le chemin critique du rendu de la page.

f7ff512caf807b735f00216156bbe760
f59a930b42df1d053b7221f2fab55a6a

En d’autre terme, le navigateur attend la réponse pour continuer le traitement de la page.

L’idée de l’OCSP stapling est de déplacer cette requête au niveau du serveur.
Avec l’OCSP stapling, le serveur qui a envoyé le certificat ajoute 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é de ces certificats. Cette information ne peut pas être falsifiée puisque la réponse OCSP est chiffrée lors du handshake TLS.

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 n’avoir qu'un aller-retour pour l’établissement des nouvelles connexions TLS.

d98e17842939b719914fe0645cf6b404
En pratique, les navigateurs n’activent cette extension que si le serveur supporte l’extension TLS NPN/ALPN qui est activée sur Fasterize ainsi qu’une suite cipher supportant le Forward Secrecy.

Conclusion

Fasterize accélère considérablement votre site en HTTPS en optimisant la couche TLS avec différentes optimisations : une cipher suite gérant le Forward Secrecy, l'OCSP Stapling, le support des identifiants de session TLS, des tickets de session TLS ainsi que du TLS False Start. Cela impacte le ressenti utilisateur et votre SEO.

Notre prochaine étape sera d'activer l'ensemble des optimisations Front-End pour les pages en HTTPS.

Vous souhaitez accélérer votre site en HTTPS ?

VOUS AIMEREZ PEUT-ÊTRE AUSSI...