Quels sont les frais généraux imposés par SSL?

Je sais qu'il n'y a pas de réponse simple et rapide, mais y a-t-il une approximation générique d'estimation d'ordre de grandeur pour la surcharge de chiffrement de SSL par rapport à une communication socket non chiffrée? Je ne parle que du traitement des communications et du temps de connexion, sans compter le traitement au niveau de l'application.

Mettre à jour

Il y a une question sur HTTPS par rapport à 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 l' avais voulu dire formellement, en tant que vrai geek, j'aurais pensé binaire plutôt que décimal! ;-)

Mettre à jour

Par demande en commentaire, supposons que nous parlons de messages de bonne taille (plage de 1k-10k) sur des connexions persistantes. La configuration de la connexion et la surcharge des paquets ne sont donc pas des problèmes importants.

Ordre de grandeur: zéro.

En d'autres termes, vous ne verrez pas votre débit coupé de moitié, ou quoi que ce soit de ce genre, lorsque vous ajoutez TLS. Les réponses à la question «dupliquer» se concentrent fortement sur les performances des applications et sur la façon dont cela se compare à la surcharge SSL. Cette question exclut spécifiquement le traitement des applications et cherche à comparer le non-SSL à SSL uniquement. S'il est logique d'avoir une vision globale des performances lors de l'optimisation, ce n'est pas ce que pose cette question.

La principale surcharge de SSL est la poignée de main. C'est là que se produit la cryptographie asymétrique coûteuse. Après négociation, des chiffrements symétriques relativement efficaces sont utilisés. C'est pourquoi il peut être très utile d'activer des 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 changé Gmail pour utiliser HTTPS, aucune ressource supplémentaire n'était nécessaire; pas de matériel réseau, pas de nouveaux hôtes. Cela n'a augmenté la charge du processeur que d'environ 1%.

Je seconde @erickson: la pénalité de vitesse de transfert de données pure 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 à ressources limitées (téléphone mobile), TLS / SSL est suffisamment rapide pour transmettre des données.

Mais gardez à l'esprit que le chiffrement rend la mise en cache et l'équilibrage de charge beaucoup plus difficiles. Cela peut entraîner une énorme pénalité de performances.

Mais la configuration de la connexion est vraiment un frein pour de nombreuses applications. Sur une bande passante faible, une perte de paquets élevée, des connexions à latence élevée (appareil mobile à la campagne), les allers-retours supplémentaires requis par TLS peuvent rendre quelque chose de lent en quelque chose d'inutilisable.

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

En supposant que vous ne comptiez pas la configuration 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 mobile Core i5, je peux chiffrer environ 250 Mo par seconde avec RC4 sur un seul cœur. (RC4 est ce que vous devriez choisir pour des performances maximales.) AES est plus lent, fournissant "seulement" environ 50 Mo / s. Ainsi, si vous choisissez des chiffrements corrects, vous ne parviendrez pas à garder un seul cœur actuel occupé avec la surcharge cryptographique, même si vous avez une ligne de 1 Gbit pleinement utilisée. [ Modifier : RC4 ne doit pas être utilisé car il n'est plus sécurisé. Cependant, la prise en charge matérielle AES est désormais présente dans de nombreux processeurs, ce qui rend le chiffrement AES très rapide sur ces plates-formes.]

L'établissement de la connexion, cependant, est différent. En fonction de l'implémentation (par exemple, prise en charge du faux départ TLS), il ajoutera des allers-retours, ce qui peut entraîner des retards notables. De plus, une crypto coûteuse a lieu lors du premier établissement de connexion (le processeur mentionné ci-dessus ne peut accepter que 14 connexions par cœur par seconde si vous utilisez bêtement 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, évitant la crypto coûteuse.

Donc, pour résumer:

Transfert sur connexion établie:

• Retard: presque aucun
• CPU: négligeable
• Bande passante: négligeable

Premier établissement de connexion:

• Retard: aller-retour supplémentaires
• Bande passante: plusieurs kilo-octets (certificats)
• CPU sur client: moyen
• CPU sur serveur: élevé

Établissements de connexion ultérieurs:

• Délai: aller-retour supplémentaire (je ne sais pas si un ou plusieurs, peut dépendre de la mise en œuvre)
• Bande passante: négligeable
• CPU: presque aucun