Les Classic Load Balancers, les équilibreurs de charge d'application et les Network Load Balancers prennent-ils en charge la reprise de séance SSL/TLS ?

Date de la dernière mise à jour : 26/05/2020

Les Classic Load Balancers, les équilibreurs de charge d'application et les Network Load Balancers prennent-ils en charge la reprise de séance SSL/TLS (Secure Sockets Layer/Transport Layer Security) ?

Résolution

Tous les types d'équilibreurs de charge prennent en charge la reprise de séance SSL/TLS. Néanmoins, les méthodes de connexion qu'ils prennent en charge varient.

Méthodes de connexion SSL/TLS

Il existe deux types de liaison TLS, notamment la liaison complète et la liaison abrégée. La liaison complète se fait une seule fois. Après la liaison, le client établit une séance SSL/TLS avec le serveur. Sur les connexions suivantes, la liaison abrégée est utilisée pour reprendre la séance précédemment négociée plus rapidement.

Il existe deux façons d'établir ou de reprendre une connexion TLS :

  • ID de séance SSL : cette méthode est basée sur le fait que le client et le serveur conservent les paramètres de sécurité de la séance pendant un certain temps après la fin d'une connexion entièrement négociée. Un serveur qui prévoit d'utiliser la reprise de séance attribue un identifiant unique à la séance. Cet identifiant est appelé ID de séance. Le serveur renvoie ensuite l'ID de séance au client dans le message ServerHello. Pour reprendre une séance précédente, le client doit soumettre l'ID de séance approprié dans son message ClientHello. Si le serveur trouve la séance correspondante dans son cache et accepte la demande de reprise de séance, le serveur renvoie le même identifiant de séance et continue avec la liaison SSL abrégée. S'il ne la trouve pas, il émet un nouvel identifiant de séance et passe à une liaison complète.
  • Ticket de séance SSL : cette méthode ne nécessite pas de stockage côté serveur. Le serveur collecte toutes les données de séance, les chiffre, puis les renvoie au client sous la forme d'un ticket. Lors des connexions suivantes, le client renvoie le ticket au serveur. Le serveur vérifie alors l'intégrité du ticket, en déchiffre le contenu et utilise les informations qu'il contient pour reprendre la séance. Si le serveur ou le client ne prend pas en charge cette extension, vous pouvez revenir au mécanisme d'identifiant de séance intégré dans SSL.

Méthodes de connexion SSL/TLS prises en charge pour chaque type d'équilibreur de charge

  • Les Classic Load Balancers prennent en charge la reprise de séance SSL/TLS basée sur un ID de séance, mais pas la reprise de séance SSL basée sur un ticket de séance. La mise en cache de séance SSL est prise en charge au niveau du nœud. La liaison SSL revient à une liaison complète si un client se connecte au nœud B à l'aide de l'ID de séance SSL reçu du nœud A. Ensuite, un nouvel ID de séance SSL est généré par le nœud B.
  • Les équilibreurs de charge d'application prennent en charge l'ID de séance et la reprise de séance SSL basée sur les tickets de séance. Les ID de séances et les tickets de séance sont pris en charge au niveau du nœud. La liaison SSL revient à une liaison complète si un client se connecte au nœud B à l'aide de l'ID de séance SSL ou du ticket de séance reçu du nœud A. Un nouvel ID de séance SSL et un nouveau ticket de séance sont ensuite générés par le nœud B.
  • Les Network Load Balancers prennent en charge uniquement les tickets de séance pour la reprise de séance. La reprise à l'aide de tickets de séance est prise en charge au niveau régional. Les clients peuvent reprendre des séances TLS avec un Network Load Balancer en utilisant l'une de ses adresses IP.

Cet article vous a-t-il été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d'aide ?