Durée de vie de la session SSL dans https

Question

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'établis une connexion https à un serveur en utilisant un navigateur normal, le ssl sous-jacent crée une session (y compris un secret partagé) en utilisant un cryptage asymétrique, le reste de la communication est crypté en utilisant un cryptage symétrique (plus rapide). La question est la suivante: Lors d'une requête https suivante (cliquez sur un lien) sur le même serveur, l'ancienne session ssl est-elle utilisée à nouveau, évitant le surdébit du chiffrement asymétrique pour l'établissement d'une clé de session? Ou est-ce qu'une nouvelle négociation asymétrique ssl cryptée pour établir une session ssl est nécessaire?

Ou pour le dire différemment: Une session SSL reste-t-elle active entre les demandes https, ou se termine-t-elle avec la fin de la requête https?

Puisque nous sommes un tas de nitpicks ici, une référence à une source autoritaire serait appréciée.

Answer 1

Voir la section 2.2 de http://www.ietf.org/rfc/rfc2818.txt et l'article 8.1 de http://www.ietf.org/rfc/rfc2616.txt

En substance, la session SSL devrait être maintenu alors que le client maintient une connexion permanente.

Pour plus d'informations sur la mise en œuvre des connexions persistantes dans les navigateurs populaires voir http://en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsers

Answer 2

Si votre navigateur prend en charge reprise de la session et le serveur a mis en cache la session, alors vous pourriez être en mesure de poursuivre une session entre les connexions, supports gnutls cela et vous pouvez voir une démo ici:

https://test.gnutls.org:5556/

Answer 3

testé ce avec Chrome:

ànaviguer. netstat montre:

$ netstat -n -p tcp|grep 184.86.149.155 
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 

sur la navigation à d'autres liens sur le site, des spectacles netstat:

$ netstat -n -p tcp|grep 184.86.149.155 
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 

La session a été maintenu en vie. Quand je fermais l'onglet du navigateur, et ROUVERT l'onglet, une autre connexion a été ouverte:

$ 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 

Il semblerait que les navigateurs modernes utilisent les mêmes délais d'attente keep-alive comme http. Ces délais d'attente peuvent être consultés ici:

http://gabenell.blogspot.com/2010/11/connection-keep-alive-timeouts-for.html