Combien de frais généraux le SSL impose-t-il ?

Question

Je sais qu'il n'y a pas de réponse toute faite, mais y a-t-il un moyen générique de estimation de l'ordre de grandeur approximation de la surcharge de cryptage du SSL par rapport à une communication par socket non cryptée ? Je ne parle que du traitement de la communication et du temps de transmission, sans compter le traitement au niveau de l'application.

Mise à jour

Il y a une question sur HTTPS et HTTP mais je suis intéressé à regarder plus bas dans la pile.

(J'ai remplacé l'expression "ordre de grandeur" pour éviter toute confusion ; je l'utilisais comme un jargon informel plutôt que dans le sens formel de CompSci. Bien sûr, si je avait si je l'avais voulu formellement, en tant que vrai geek, j'aurais pensé en binaire plutôt qu'en décimal ! ;-)

Mise à jour

Conformément à la demande formulée dans le commentaire, supposez que nous parlons de messages de bonne taille (de l'ordre de 1k-10k) sur des connexions persistantes. Ainsi, l'établissement de la connexion et la surcharge des paquets ne sont pas des problèmes importants.

Answer 1

Ordre de grandeur : zéro.

En d'autres termes, vous ne verrez pas votre débit diminuer de moitié, ou quoi que ce soit d'autre, lorsque vous ajoutez TLS. Les réponses à la question "Question "duplicate se concentrent principalement sur les performances des applications et sur la façon dont elles sont comparées à l'overhead SSL. Cette question exclut spécifiquement le traitement des applications, et cherche à comparer le non-SSL au SSL uniquement. Bien qu'il soit logique d'avoir une vue globale des performances lors de l'optimisation, ce n'est pas ce que demande cette question.

La principale surcharge du SSL est la poignée de main. C'est là que se produit la coûteuse cryptographie asymétrique. Après la négociation, des chiffrages symétriques relativement efficaces sont utilisés. C'est pourquoi il peut être très utile d'activer les sessions SSL pour votre service HTTPS, où de nombreuses connexions sont établies. Pour une connexion de longue durée, cet "effet final" n'est pas aussi important, et les sessions ne sont pas aussi utiles.

---

Voici une anecdote intéressante. Lorsque Google a adopté le protocole HTTPS pour Gmail, aucune ressource supplémentaire n'a été nécessaire, ni matériel réseau, ni nouveaux hôtes. La charge du processeur n'a augmenté que d'environ 1 %.

Answer 2

Je suis d'accord avec @erickson : la pénalité en termes de vitesse de transfert des données est négligeable. Les processeurs modernes atteignent un débit crypto/AES de plusieurs centaines de MBit/s. Donc, à moins que vous ne soyez sur un système aux ressources limitées (téléphone portable), TLS/SSL est suffisamment rapide pour transférer des données.

Mais n'oubliez pas que le cryptage rend la mise en cache et l'équilibrage de la charge beaucoup plus difficiles. Cela peut entraîner une énorme pénalité de performance.

Mais la configuration de la connexion est vraiment un obstacle pour de nombreuses applications. Sur les connexions à faible bande passante, à forte perte de paquets et à latence élevée (appareil mobile à la campagne), les allers-retours supplémentaires requis par TLS peuvent transformer un appareil lent en un appareil inutilisable.

Par exemple, nous avons dû abandonner l'exigence de cryptage pour l'accès à certaines de nos applications web internes - elles étaient pratiquement inutilisables si elles étaient utilisées depuis la Chine.

Answer 3

En supposant que vous ne comptez pas l'établissement de la connexion (comme vous l'avez indiqué dans votre mise à jour), cela dépend fortement du chiffrement choisi. La surcharge du réseau (en termes de bande passante) sera négligeable. La surcharge du processeur sera dominée par la cryptographie. Sur mon Core i5 mobile, je peux crypter environ 250 Mo par seconde avec RC4 sur un seul cœur. (RC4 est ce que vous devriez choisir pour une performance maximale). AES est plus lent et ne fournit "que" 50 Mo/s environ. Donc, si vous choisissez les bons ciphers, vous ne parviendrez pas à occuper un seul cœur actuel avec la surcharge cryptographique, même si vous disposez d'une ligne 1 Gbit entièrement utilisée. [ Modifier : RC4 ne doit pas être utilisé car il n'est plus sécurisé. Cependant, le support matériel d'AES est maintenant présent dans de nombreux processeurs, ce qui rend le chiffrement AES vraiment rapide sur ces plateformes].

L'établissement de la connexion, cependant, est différent. Selon l'implémentation (par exemple, la prise en charge du faux départ TLS), il ajoutera des allers-retours, ce qui peut entraîner des retards notables. De plus, un cryptage coûteux a lieu lors du premier établissement de la connexion (le processeur mentionné ci-dessus ne peut accepter que 14 connexions par cœur et par seconde si vous utilisez des clés de 4096 bits et 100 si vous utilisez des clés de 2048 bits). Lors des connexions suivantes, les sessions précédentes sont souvent réutilisées, ce qui évite le cryptage coûteux.

Donc, pour résumer :

Transfert sur connexion établie :

• Retard : presque nul
• CPU : négligeable
• Largeur de bande : négligeable

Établissement de la première connexion :

• Retard : allers-retours supplémentaires
• Bande passante : plusieurs kilobytes (certificats)
• CPU sur le client : moyen
• CPU sur le serveur : élevé

Établissements de connexion ultérieurs :

• Retard : aller-retour supplémentaire (pas sûr qu'il y en ait un ou plusieurs, cela peut dépendre de l'implémentation).
• Largeur de bande : négligeable
• CPU : presque aucun

Answer 4

Anatomie et performance du traitement SSL http://www.cs.ucr.edu/~bhuyan/papers/ssl.pdf