Les Classic Load Balancers, Application Load Balancers, et Network Load Balancers prennent-ils en charge la reprise de session SSL/TLS ?

Lecture de 4 minute(s)
0

Je souhaite savoir si les Classic Load Balancers, Application Load Balancers, et Network Load Balancers prennent en charge la reprise de session Secure Sockets Layer/Transport Layer Security (SSL/TLS).

Résolution

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

Méthodes de connexion SSL/TLS

Il existe deux types de négociations TLS : complètes et abrégées. La négociation complète s’effectue une seule fois. Après la négociation, le client établit une session SSL/TLS avec le serveur. Lors des prochaines connexions, la négociation abrégée sera utilisée pour reprendre plus rapidement la session précédemment négociée.

Il existe deux manières d'établir ou de reprendre une connexion TLS :

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

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

Classic Load Balancers

Les Classic Load Balancers prennent en charge la reprise de session SSL/TLS basée sur l'identifiant de session, et non la reprise de session SSL basée sur un ticket de session. La mise en cache des sessions SSL est prise en charge au niveau du nœud. Supposons par exemple qu'un client se connecte au nœud B à l'aide de l'ID de session SSL reçu du nœud A. Dans ce cas, la négociation SSL redevient une négociation complète. Ensuite, un nouvel ID de session SSL est généré par le nœud B.

Application Load Balancers

Les Application Load Balancers prennent en charge à la fois l'ID de session et la reprise de session SSL basée sur un ticket de session. Les ID de session et les tickets de session sont pris en charge au niveau du nœud. Supposons par exemple qu'un client se connecte au nœud B à l'aide de l'ID de session SSL ou du ticket de session reçu du nœud A. Dans ce cas, la négociation SSL redevient une négociation complète. Ensuite, le nœud B génère un nouvel ID de session SSL et un nouveau ticket de session.

Network Load Balancers

Les Network Load Balancers prennent uniquement en charge les tickets de session pour la reprise de session. La reprise à l'aide de tickets de session est prise en charge au niveau régional. Les clients peuvent reprendre les sessions TLS avec un Network Load Balancers à l'aide d'une de ses adresses IP.

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an