Forum Discussion

boneyard's avatar
boneyard
Icon for MVP rankMVP
Mar 10, 2013

ssl::renegotiate changes SSL session ID and makes it impossible to resume?

when calling ssl::renegotiate (in v11.2 / 11.3) it seems that the SSL session ID changes (very slightly, gets +1 somewhere near 2/3s) and can't be used anymore by new resume requests that request in my opinion correctly the new SSL session ID. so the client is aware of a new session ID, but when using it in Client Hello is denied and gets a totally different one in Server Hello.

 

have others experienced this behaviour? is this documented somewhere?

 

application delivery
dev
devops
iRules

5 Replies

Sort By
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Mar 11, 2013
    When you call SSL::renegotiate, do you also by chance call SSL::authenticate with a value of "always", or not call it at all?

     

     

    I've noticed that if you have the frequency set to "once" in the client SSL profile (the default setting), and you don't specify 'once' in your iRule, it will (sort of) behave as if always was selected (as in not storing session IDs across TCP sessions). In my testing, with 'SSL::authenticate once' in the iRule just before 'SSL::renegotiate', upon the server's HelloRequest message, the server will immediately send a new session ID that the client will honor. Without the 'once' setting, the session ID will disappear across TCP sessions.
  • boneyard's avatar
    boneyard
    Icon for MVP rankMVP
    Mar 13, 2013
    the code surrounding it is:

     

    
      SSL::authenticate once
      SSL::authenticate depth 9
      SSL::cert mode request
      SSL::renegotiate
      return

     

     

    the client honors the new session ID, although the change in it is very small, but afterwards the F5 doesn't want to use it anymore for new TCP sessions.
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Mar 13, 2013
    I haven't gotten my head completely around this one yet, but I'm leaning toward an issue/behavior of RFC 5077 "Transport Layer Security (TLS) Session Resumption without Server-Side State".

     

     

    In the meantime, aside from avoiding the additional (complete) renegotiation, can you elaborate on what are you trying to achieve that this behavior is preventing?
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Mar 14, 2013

    I haven't gotten my head completely around this one yet, but I'm leaning toward an issue/behavior of RFC 5077 "Transport Layer Security (TLS) Session Resumption without Server-Side State".

     

     

    In the meantime, aside from avoiding the additional (complete) renegotiation, can you elaborate on what are you trying to achieve that this behavior is preventing?

     

  • boneyard's avatar
    boneyard
    Icon for MVP rankMVP
    Mar 21, 2013
    im doing the usual requesting a client certificate from the irule without having the put the ssl client side profile on request.

     

     

    because of the failure to request the new SSL session id certain tcp session are using a different SSL session id which isn't authorized within the irule to access the protected resources.

     

     

    this can be solved with using a cookie, but i just want to understand why the F5 doesn't honor the request for an, in my opinion, valid SSL session id.