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


168

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.


Vous pouvez jeter un oeil à cette question similaire .
Darin Dimitrov

1
Pouvez-vous caractériser un peu plus votre application? Par exemple, établit-il beaucoup de connexions de courte durée? Lorsqu'il est connecté, quelle est la taille d'un message individuel? (Par exemple, peut-être que vous videz chaque pression de touche avec Telnet sur un tunnel SSL, ou peut-être que vous copiez des fichiers journaux de 1 To.)
erickson

Réponses:


178

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%.


6
Comment «activer les sessions SSL pour votre service HTTPS»? Quelle est une bonne ressource pour en savoir plus?
Justin Vincent

1
L'activation des sessions SSL est spécifique au serveur. Lisez le manuel de votre serveur.
erickson

7
@Bart van Heukelom - Keep-alive aidera à garder une socket (et la connexion SSL) ouverte plus longtemps, ce qui aide. Mais les sessions SSL font que les paramètres cryptographiques négociés sont "mémorisés" d'un socket à l'autre. Ainsi, HTTP keep-alive serait utile pour charger une seule page Web avec son contenu référencé, mais après quelques secondes, cette connexion se fermera. Trois minutes plus tard, disons, lorsqu'une autre page est récupérée, une session SSL permet à la connexion SSL d'être rétablie sans répéter la prise de contact complète. En particulier, l' échange lent de clé avec la crypto à clé publique peut être ignoré.
erickson

2
@Tony avez-vous des exemples concrets où TLS ajoute plus de quelques pour cent de frais généraux? Ma réponse est aussi générale que la question. Si vous avez une prise différente, veuillez la partager.
erickson

3
@Tony J'ai vu des sockets simples surpasser les sockets SSL d'un facteur 42 en termes d'espace lors de l'écriture d'un seul octet à la fois, ce qui est le pire des cas. Jamais vu 250x. J'ai fait une expérience approfondie sur Internet avec 1700 points de données où le résultat général était que les sockets en clair n'étaient pas meilleurs que trois fois plus rapides que SSL, en utilisant une programmation pas plus sophistiquée que la mise en mémoire tampon et le vidage. JSSE, probablement Java 5 compte tenu de la date de l'expérience.
Marquis of Lorne

39

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.


20
Avec 4 ans de recul: la Chine aurait peut-être aussi simplement gâché intentionnellement tout le trafic SSL / TLS.
max

3
La Chine censure Internet et tente de renifler le trafic de tout le monde n'est pas vraiment une nouvelle. Avec 4 ans de recul cependant, vous penseriez que c'était la NSA MITMing sur le chemin de votre site.
Eugene Beresovsky

La clé avec des connexions irrégulières est de configurer le cryptage une fois, puis d'éviter les réégociations à moins que cela ne soit vraiment nécessaire, et de permettre aux deux côtés de changer leurs adresses IP à tout moment sans cligner des yeux. (OpenVPN prend en charge cela.) Les TI contribuent à rendre la fragmentation possible, car le MTU peut être très peu fiable et carrément malhonnête.
Evi1M4chine

12

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

Remarque importante: personne ne devrait plus jamais utiliser RC4. Le protocole doit être considéré comme cassé et la transmission RC4 qui l'accompagne doit être considérée comme équivalente à une transmission non cryptée à tout le moins pour la sécurité des organisations d'espionnage. De nos jours, quelque chose comme chacha20-poly1305 est fortement recommandé pour le cryptage en masse en raison de son indépendance par rapport à de telles organisations.
Evi1M4chine
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.