Session SSL billets vs id de session

Pour améliorer la communication SSL performance pour ne pas conserver la(courte) connexions il y a deux fonctions distinctes largement connus:

  • TLS id de session
  • Tickets de session TLS

Dans le cas de très nombreuses courtes sessions de connexion du mécanisme en termes de surcharge de performance est souhaitable et devrait être utilisé?

Je sais serveur de cacher de l'id de session, aussi les tickets de session sont facilement partageables dans le cas de l'équilibrage de la charge, mais supposons qu'il existe un seul serveur qui écoute sur un port unique(pas de l'équilibrage de la charge) et il reçoit de très nombreux COURTS entrant TLS sessions de connexion.

Donc qui approche (sessions ou des billets) est préférable compte tenu de ce scénario?

  • Je vais ajouter ma réponse, mais en même temps, je ne pense pas que ce est une SORTE de question.
  • Pourquoi? C'est de la pure programmation du réseau de question, rien à voir avec le matériel dans mon cas. Aussi je ne vois pas votre réponse)
  • IMO ce n'est pas seulement adapté SI question, mais méritant plus d'attention qu'il a reçu à ce point.
InformationsquelleAutor Hovhannes Grigoryan | 2013-11-12
  1. 18

    Lorsque le serveur envoie le Serveur “Bonjour” du message, il peut inclure un identifiant de session. Le client se doit de le stocker et de le présenter au Client “Bonjour” message de la prochaine session. Si le serveur trouve la session correspondante dans son cache et qui accepte de reprendre la session, il renverra le même identifiant de session et se poursuivra avec la présentation abrégée de la connexion SSL. Sinon, il sera question d'un nouvel identifiant de session et passer à une pleine poignée de main. Ce mécanisme est détaillé dans la RFC 5246. C'est le mécanisme le plus commun car il existe depuis des versions antérieures de SSL.

    Dans le dernier échange d'une pleine négociation SSL, le serveur peut inclure un “Nouveau Ticket de Session” message (non représenté dans la poignée de main est décrit sur la photo) qui va contenir la session complète de l'état (y compris le maître secret négocié entre le client et le serveur et de la suite de chiffrement utilisé). Par conséquent, cet état est chiffrés et protégés par une clé connue seulement par le serveur. Ce opaque datum est connu comme un ticket de session. Les détails de mensonge dans la RFC 5077, qui annule et remplace la RFC 4507.

    Le mécanisme du ticket est une extension TLS. Le client peut faire la publicité de son soutien par l'envoi d'un vide “Ticket de Session” extension du Client “Bonjour” message. Le serveur répond avec un vide “Ticket de Session” extension de son Serveur “Bonjour” message si il la prend en charge. Si l'un d'eux ne prend pas en charge cette extension, ils peuvent secours à l'identifiant de session mécanisme intégré dans le protocole SSL.

    RFC 5077 identifie les situations où les billets sont souhaitables sur des identifiants de session. La principale amélioration est d'éviter la nécessité de maintenir un serveur de cache de session depuis l'ensemble de l'état de session est rappelé par le client, et non sur le serveur. Un cache de session peut être coûteux en termes de mémoire, et peut être difficile à partager entre plusieurs hôtes à la demande d'un équilibrage de charge sur les serveurs.

    • Cela semble être en grande partie une régurgitation de ce que les séances et les billets sont. Pour recevoir la prime une réponse spécifique de l'adressage de l'OP avec un qualitatives recommandation est nécessaire.
    • Source Possible de cette réponse du contenu et pour davantage de lecture: vincent.bernat.im/fr/blog/2011-ssl-session-réutiliser-rfc5077
    InformationsquelleAutor Dharmesh Hadiyal
  2. 12

    Avec session-id, le serveur a besoin de garder une trace des sessions précédentes qui pourrait être poursuivie à un certain point dans le temps. Il en résulte un travail supplémentaire que le serveur a à faire.

    La session de billet, en revanche, n'est pas un identificateur, mais la séance de données cryptées par le serveur (et seul le serveur peut le décrypter). Lorsqu'un client souhaite donc de continuer une session, il sait encore le secret pré-maître, mais le serveur n'est pas plus. Si le client envoie la session de billet pour le serveur et le serveur est capable de déchiffrer son contenu. Toutes les informations nécessaires pour continuer la séance est inclus dans y, de sorte que le serveur puisse reprendre la session sans garder aucune information. Le chargement se fait sur le client (en gardant le secret pré-maître et la session de billet).

    InformationsquelleAutor Brian Pfretzschner
  3. -1

    Vous avez seulement besoin de l'Id de session dans cette situation, et ils sont intégrés dans la plupart des implémentations SSL, contrairement à la RFC 5077 de billetterie, ce qui est encore une extension TLS.

    • Pouvez-vous expliquer pourquoi j'ai besoin d'utiliser des id de session? Je n'ai pas les soins à ce sujet est juste une extension, nous allons assum je contrôle à la fois le serveur et le client, j'ai donc besoin de choisir la plus efficace. J'ai besoin d'evaluation de la performance des deux, lequel est le plus rapide? et POURQUOI?
    • Je n'ai pas dit que vous besoin pour l'utilisation des IDENTIFIANTS de session, j'ai dit que vous que besoin d'utiliser des Identifiants de session, que vous n'avez pas besoin d'installations supplémentaires fournies par les billets. Je ne vois pas pourquoi soit devrait être plus rapide. Il me semble que votre problème sera plus au sujet de la faisabilité de la performance.
    • Je ne comprends pas les downvotes pour votre réponse qui semble correct.
    InformationsquelleAutor user207421