Nous avons une discussion engagée (mais amicale) entre collègues sur la durée de vie de la session SSL sous-jacente à une communication HTTPS.
Lorsque j'étaise une connexion HTTPS à un serveur à l'aide d'un navigateur normal, la SSL sous-jacente crée une session (y compris un secret partagé) à l'aide de cryptage asymétrique, le reste de la communication est crypté à l'aide d'un cryptage symétrique (plus rapide).
La question est la suivante: sur les demandes HTTPS ultérieures (cliquez sur un lien) sur le même serveur, est l'ancienne session SSL utilisée à nouveau, en évitant la surcharge du cryptage asymétrique pour établir une clé de session? Ou est une nouvelle poignée de main SSL cryptée asymétrique pour établir une session SSL nécessaire?
ou pour le mot il différemment: une session SSL reste-t-elle en vie entre les demandes HTTPS ou se termine-t-elle à la fin de la demande HTTPS?
Puisque nous sommes un groupe de nitpicks ici une référence à une source autorisée serait apirée.
3 Réponses :
Voir la section 2.2 de http://www.ietf.org/rfc/rfc2818.txt et section 8.1 de http://www.ietf.org/rfc/rfc2616. txt
Essentiellement, la session SSL doit être maintenue pendant que le client maintient une connexion persistante.
Pour plus d'informations sur la mise en œuvre de connexions persistantes dans les navigateurs populaires Voir http: // fr. wikipedia.org/wiki/http_persistent_connection#use_in_web_browser
La session SSL est-elle utilisée dans la création d'une nouvelle session HTTP?
Si votre navigateur prend en charge la session de reprise et que le serveur a mis en cache la session, vous pourrez peut-être poursuivre une session entre les connexions, GNUTLS prend en charge cela et vous pouvez voir une démo ici:
Ce serveur n'est plus disponible.
Testé ceci avec chrome:
naviguer vers https://www.americanexpress.com . NetStat montre: p> sur la navigation sur d'autres liens sur le site Web, des spectacles netstat: p> La session a été conservée en vie . Lorsque j'ai fermé l'onglet Navigateur et j'ai rouvert l'onglet, une autre connexion a été ouverte: p> $ netstat -n -p tcp|grep 184.86.149.155
tcp4 0 0 10.177.78.58.50398 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50311 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50310 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50309 184.86.149.155.443 ESTABLISHED