comment réduire le temps ssl du site web
J'ai un site Web HTTPS et je souhaite réduire le temps SSL de ce site Web. Le certificat SSL a été installé sur AWS ELB.
Si j'accède au site depuis les Pays-Bas, le délai SSL est élevé, mais si j'accède au même site depuis d'autres pays, le délai SSL est faible. Pourquoi donc?
J'essaie essentiellement de minimiser le temps qui s'affiche sur cette page
http://tools.pingdom.com/fpt/#!/ed9oYJ/https://www.google.com/index.html
Beaucoup de choses influencent le temps SSL, notamment:
Infrastructure (cela n'affectera pas seulement SSL mais [~ # ~] tout [~ # ~] le trafic réseau):
- Problèmes de réseau standard (à quelle distance votre serveur est-il du client, à quelle vitesse le réseau se trouve-t-il entre les deux, etc.), car la prise de contact SSL/TLS prend plusieurs allers-retours. Vous avez peu de contrôle sur ces derniers, sauf en changeant de fournisseur d'hébergement et/ou en utilisant un CDN. D'après mon expérience, AWS est rapide et vous ne demandez qu'à améliorer SSL plutôt que les temps d'accès généraux, alors ignorez peut-être celui-ci pour l'instant.
- Temps de réponse du serveur. Le serveur est-il sous-alimenté en CPU, Ram ou disque? Partagez-vous cet hôte? Encore une fois, un problème général peut être ignoré, mais SSL/TLS prend cependant une certaine puissance de traitement, avec les serveurs modernes, il est à peine perceptible de nos jours.
- OS du serveur. Plus récent, c'est mieux. Donc, si vous exécutez Red Hat Linux 4 par exemple, attendez-vous à ce qu'il soit considérablement plus lent que le dernier Red Hat Linux 7, avec une pile réseau améliorée et des versions plus récentes de logiciels clés comme OpenSSL.
Configuration SSL (exécutez votre site via https://www.ssllabs.com/ssltest et vous devriez en obtenir un état de santé):
- Chiffres utilisés. Il existe des chiffrements plus anciens et plus lents, ainsi que de nouveaux et plus rapides. Peut se compliquer ici très rapidement, mais en général, vous devriez rechercher des chiffrements ECDHE pour la plupart des clients (et ceux ECDHE ... GCM préférables) et vous souhaitez spécifier que l'ordre du serveur doit être utilisé afin de choisir le chiffrement utilisé plutôt que le client .
- Certificat utilisé. Vous voudrez un cert RSA 2048. Quelque chose de plus est excessif et lent. Certains sites (et certains outils d'analyse) choisissent les certificats RSA 4096, mais ceux-ci ont un impact notable sur la vitesse sans augmentation réelle de la sécurité (à l'heure actuelle - cela peut changer). Il existe des certificats ECDSA plus récents (généralement présentés sous la forme d'un certificat 256 EC dans le rapport ssllabs), mais ces certificats ECDSA plus rapides ne sont pas fournis par toutes les autorités de certification et ne sont pas universellement pris en charge par tous les clients, de sorte que les visiteurs sur du matériel et des logiciels plus anciens peuvent ne pas être en mesure de se connecter avec leur. Apache ( et très récemment Nginx à partir de la v 1.11. ) prend en charge les certificats doubles pour avoir le meilleur des deux mondes, mais au détriment de deux certificats et d'une certaine complexité de leur configuration.
- Chaîne de certificats. Vous aurez besoin d'une chaîne de certificats courte (idéal 3 cert long: votre serveur, intermédiaire et le certificat racine des autorités de certification). Votre serveur doit renvoyer tout sauf le dernier certificat (qui est déjà dans le magasin de certificats des navigateurs). Si l'une des chaînes est manquante, certains navigateurs tenteront de rechercher ceux qui rêvent, mais cela prend du temps.
- Fournisseur de cert fiable. Outre des chaînes de certificats plus courtes, de meilleurs répondeurs OCSP, leurs intermédiaires sont également généralement mis en cache dans les navigateurs des utilisateurs car ils sont susceptibles d'être utilisés par d'autres sites.
- L'agrafage OCSP enregistre le trajet réseau pour vérifier que le cert est valide, en utilisant OCSP ou CRL. L'activer ne fera aucune différence pour Chrome car ils ne vérifient pas la révocation (principalement mais les certificats EV sont vérifiés). Cela peut faire une différence notable pour IE doit donc être activé si votre serveur les prend en charge, mais soyez conscient de certains problèmes d'implémentation - en particulier la première demande de nginx après redémarrage échoue toujours lorsque l'agrafage OCSP est activé.
- TLSv1.2 doit être utilisé et éventuellement TLSv1 .0 pour les clients plus anciens, mais pas SSLv2 et SSLv3. TLSv1.1 est un peu inutile (à peu près tout le monde qui prend en charge prend également en charge le TLSv1.2 plus récent et meilleur). TLSv1.3 est en cours d'élaboration et présente de bonnes améliorations de performances, mais n'a pas encore été entièrement normalisé car il existe des problèmes de compatibilité connus. Espérons que ces problèmes seront bientôt résolus afin qu'ils puissent être utilisés. Notez que la conformité PCI (si vous utilisez des cartes de crédit sur votre site) exige TLSv1.2 ou supérieur sur les nouveaux sites et sur tous les sites d'ici le 30 juin 2018.
Visites répétées - bien que ce qui précède aidera à la connexion initiale, la plupart des sites nécessitent le téléchargement de plusieurs ressources et, avec une mauvaise configuration, il faudra peut-être passer par une poignée de main à chaque fois (cela devrait être évident si vous voyez des configurations de connexion SSL répétées pour chaque requête lors de l'exécution de choses comme webpagetest.org):
- HTTP Keep-Alives doit être activé pour que la connexion ne soit pas interrompue après chaque requête HTTP (ce doit être la valeur par défaut pour les implémentations HTTP/1.1).
- La mise en cache SSL et les tickets devraient être activés à mon avis. Certains sont en désaccord pour certaines raisons de sécurité obscures qui devraient être corrigées dans TLSv1. mais pour des raisons de performances, elles devraient être activées. Les sites contenant des informations très sensibles peuvent choisir la sécurité plus complète que les performances, mais à mon avis, les problèmes de sécurité sont assez complexes à exploiter et le gain de performances est perceptible.
- HTTP/2 doit être pris en compte, car il n'ouvre qu'une seule connexion (et donc une seule configuration SSL/TLS) et présente d'autres améliorations de performances.
J'aurais vraiment besoin de connaître votre site pour voir lequel, le cas échéant (le cas échéant) peut être amélioré. Si vous ne souhaitez pas donner cela, je vous suggère d'exécuter le test ssllabs et de demander de l'aide pour tout ce qu'il soulève que vous ne comprenez pas, car cela peut nécessiter beaucoup de connaissances détaillées pour comprendre.
Je lance un blog personnel expliquant certains de ces concepts plus en détail si cela aide: https://www.tunetheweb.com/security/https/
Vous pouvez essayer les certificats ECDSA: https://scotthelme.co.uk/ecdsa-certificates/
Mais le coût de https n'est visible que sur les premières demandes: les tickets de session évitent ce coût pour toutes les autres demandes. Sont-ils activés? (vous pouvez le vérifier avec ssllabs.com)
Si vous le pouvez, vous devez utiliser SPDY ou http2, cela peut également améliorer la vitesse.
Les clés ECDSA, SPDY et http2 réduisent le nombre d'aller-retour nécessaire, ce qui devrait réduire la différence entre les deux emplacements.
Vous dites que vous n'utilisez pas un CDN, mais je crois que vous devriez être. Voici pourquoi:
La connexion via TLS/SSL implique l'établissement d'une connexion sécurisée, ce qui nécessite une communication supplémentaire entre le client et le serveur avant que toutes les données puissent commencer à circuler. Ce lien contient un schéma pratique de la prise de contact SSL , et ce lien explique les premières millisecondes d'une connexion HTTPS .
Jordan Sissel a écrit sur ses expériences avec la latence de prise de contact SSL :
J'ai commencé à étudier les différences de latence pour des demandes similaires entre HTTP et HTTPS. ... Tout est dans la poignée de main. ... Le fait est que, quelle que soit la vitesse de vos accélérateurs SSL (équilibreur de charge matériel, etc.), si vos points de terminaison SSL ne sont pas à proximité de l'utilisateur, votre première connexion sera lente.
Si vous utilisez un CDN, la négociation peut être effectuée entre le client et l'emplacement Edge le plus proche, ce qui améliore considérablement la latence.