La durée de vie de la session SSL https

Nous avons engagé (mais sympathique) discussion entre collègues au sujet de la durée de vie de la session SSL sous-jacents à la communication https.

Quand je établir une connexion https sur un serveur à l'aide d'un navigateur sous-jacents ssl crée une session (y compris un secret partagé) à l'aide d'un chiffrement asymétrique, le reste de la communication est cryptée à l'aide de (plus rapide) de chiffrement symétrique.

La question est: À la suite des demandes https (cliquez sur un lien) vers le même serveur, est l'ancienne session ssl utilisé à nouveau, en évitant la surcharge du chiffrement asymétrique pour l'établissement d'une clé de session? Ou est une nouvelle asymétrique crypté ssl handshake pour l'établissement d'une session ssl nécessaire?

Ou pour l'exprimer différemment: une session SSL reste en vie entre les requêtes https, ou prend-elle fin à la fin de la requête https?

Puisque nous sommes un groupe de nitpicks ici une référence à certains faisant autorité de la source serait aprécié.

InformationsquelleAutor Jens Schauder | 2010-01-05
  1. 4

    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 essence, la session SSL DOIT être conservé, même si le client utilise une connexion persistante.

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

    • Est la session SSL utilisé dans la création d'une nouvelle session HTTP?
    InformationsquelleAutor Andrew McGregor
  2. 10

    Testé avec Chrome:

    accédez à https://www.americanexpress.com. netstat affiche:

    $ 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 vers d'autres liens sur le site, la commande netstat affiche:

    $ 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. Lorsque j'ai fermé l'onglet du navigateur, et ré-ouvert 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 la même keep-alive délais d'attente comme http. Ces délais d'attente peuvent être consultées ici:

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

    InformationsquelleAutor PressingOnAlways
  3. 3

    Si votre navigateur prend en charge la séance de la reprise et le serveur a mis en cache de la session, vous pouvez être en mesure de poursuivre une session entre les connexions, GNUTLS prend en charge ce et vous pouvez voir une démo ici:

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

    • Ce serveur n'est plus disponible.
    InformationsquelleAutor MarkR